< 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
< 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
< 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