< phantomcircuit> gmaxwell, the fuzzer was one binary because i couldn't figure out how to do it right in the build system
< gmaxwell> phantomcircuit: Sure, I don't know that it matters much. also-- that concern could be addressed by making the fuzzer take a commandline parameter that forces a particular mode.
< phantomcircuit> gmaxwell, iirc there's a nonce per compile or something too
< phantomcircuit> gmaxwell, it does actully make things a bit easier since a number of things share vaguely similar data structures
< phantomcircuit> so the first run can kind of piggy back on the
< bitcoin-git> [bitcoin] gkrizek closed pull request #15022: Build: Upgrade Travis OS to Xenial (master...xenial) https://github.com/bitcoin/bitcoin/pull/15022
< jonasschnelli> cfields: osx sigs for 0.17.1 are up: https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/21
< fanquake> \o/ thanks jonasschnelli
< jonasschnelli> ...and sorry for the delay
< fanquake> np. It's meant to be holidays
< gmaxwell> jonasschnelli: thanks!
< luke-jr> any ideas why suddenly I can't build Core? :/
< luke-jr> /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: univalue/.libs/libunivalue.a(libunivalue_la-univalue.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
< wumpus> gmaxwell: after build of the code-signed binaries: creating and signing SHA256sums, uploading the binaries everywhere, seeding the torrent, release annoucements (mail, twitter, etc), PR and merge release metadata on bitcoincore.org and bitcoin.org, copying and committing the historical release notes to master, ehh and probably some other things I forgot :<
< bitcoin-git> [bitcoin] canselcik opened pull request #15031: Removing unnecessary comparison of size_t maxConfirms (master...maxConfirms) https://github.com/bitcoin/bitcoin/pull/15031
< wumpus> ah yes: adding the release on github.com/bitcoin
< harding> wumpus: 0.17.1 PR for BitcoinCore.org: https://github.com/bitcoin-core/bitcoincore.org/pull/633
< wumpus> harding: awesome, thank you!
< bitcoin-git> [bitcoin] MeshCollider pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/e2dfeb0146da...f8a3ab3b29fe
< bitcoin-git> bitcoin/master bdacbda Pieter Wuille: Overhaul importmulti logic...
< bitcoin-git> bitcoin/master eacff95 Pieter Wuille: Add release notes
< bitcoin-git> bitcoin/master f8a3ab3 MeshCollider: Merge #14565: Overhaul importmulti logic...
< bitcoin-git> [bitcoin] MeshCollider closed pull request #14565: Overhaul importmulti logic (master...201810_refactor_importmulti) https://github.com/bitcoin/bitcoin/pull/14565
< bitcoin-git> [bitcoin] MeshCollider pushed 2 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/ef70f9b52b85...a057cc08fddd
< bitcoin-git> bitcoin/0.17 ae1b675 Gregory Sanders: importmulti: Don't add internal addresses to address book...
< bitcoin-git> bitcoin/0.17 a057cc0 MeshCollider: Merge #14900: [backport] #14679 importmulti: Don't add internal addresses to address book...
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/a057cc08fddd...e11856515e7c
< bitcoin-git> bitcoin/0.17 46c162d MarcoFalke: rpc: Avoid creating non-standard raw transactions...
< bitcoin-git> bitcoin/0.17 e118565 MarcoFalke: Merge #14893: 0.17 [Backport 14890] rpc: Avoid creating non-standard raw transactions...
< bitcoin-git> [bitcoin] MeshCollider opened pull request #15032: Nit fixes for PR 14565 (master...201812_pr_14565_nits) https://github.com/bitcoin/bitcoin/pull/15032
< cfields> gitian builders: detached sigs for 0.17.1 are pushed
< wumpus> nice!
< cfields> Had to sneak away for a bit to tag :)
< cfields> Happy holidays everyone!
< wumpus> happy holidays!
< sipa> wumpus: you too!
< wumpus> sipa: thank you!
< gkrizek> Happy holidays!
< \\\\> hello world
< Dizzle> yo, did any of you work on the Bitcoin Core implementation of getblocktemplate?
< sipa> maybe
< Dizzle> sipa: do you know if a miner using Core as a gbt service can expect that the size of transaction data + a typical generation tx will be likely to fit within the block size limit?
< Dizzle> transaction data given in the template, that is
< luke-jr> Dizzle: afaik it should, but it's not guaranteed
< Dizzle> alright, thanks, luke-jr. So an ideal miner or mining pool implementation should check, and possibly mutate the tx set if would exceed the size after adding a generation tx?
< luke-jr> iirc there's 250 or 1000 bytes left for it by default
< luke-jr> Dizzle: yes
< Dizzle> rockin
< luke-jr> (or just use libblkmaker.. :P)
< sipa> luke-jr: how is it not guaranteed?
< sipa> Dizzle: yes, the gbt result will always fit in a block; i believe it leaves 1 kb under so you can add things to the coinbase
< sipa> sorry, 1000 vbytes