< kanzure> ah wait, i didn't notice the flag comment. ok fine, then it's just a question of what's the default, a much less interesting question to me.
< sipa> if this would be introduced now, i think we'd add a naned argument to control this, rather than change the defaukt
< gmaxwell> Other than some historical artifacts I don't think it's correct to say we changed the default.
< gmaxwell> getblock returns the block. If there is segwit, there is segwit.
< gmaxwell> oh you mean that we have that argument.
< gmaxwell> The argument exists so that existing software which can't handle segwit blocks can be run _unmodified_, having a named argument wouldn't satisify this.
< gmaxwell> It's a compatibility measure.
< gmaxwell> And not one that anyone should be using except for a brief window to allow you to slot in a new node version.
< gmaxwell> Keep in mind our rational for avoiding softforks in major versions: we're trying hard to accomidate people upgrading to enforce the softfork without breaking any of their surrounding infrastructure.
< gmaxwell> If you could upgrade your software to emit the named argument, you'd just upgrade it to cope with the new serialization. It's hardly more work.
< kanzure> yes i didn't know about that extra argument mentioned in that issue ticket, (thus my "nevermind" and sudden disinterest). if they want the flag off then they should have kept it off, simple problem.
< phantomcircuit> luke-jr, it's because the m4 script looks for db5 but not db5.3
< phantomcircuit> and gentoo doesn't have a symlink
< phantomcircuit> hmm maybe not
< phantomcircuit> no yeah that's the issue
< phantomcircuit> hmm
< gmaxwell> aaee787a2a9090cb4f7159e2328f260343ae7fded220849e21a8519be61ebe37 message82.txt
< gmaxwell> eaab23579c6ccc0ed40de16aae51c3945359d9b6938d6a01c8094b98875678b4 message83.txt
< phantomcircuit> gmaxwell, chocolate chip cookies confirmed
< sipa> ...?
< luke-jr> where?
< phantomcircuit> luke-jr has the right question
< gmaxwell> Where?
< achow101> food?
< gmaxwell> I think the cookies are a lie.
< goatpig> how is "food" a proper reply to "where"?
< sipa> i always accept cookies from this domain
< luke-jr> lol
< phantomcircuit> anybody know why there's a warning about nStart possibly being uninitialized ?
< phantomcircuit> i dont see how it's possible
< BlueMatt> lol, no one notice dbcrash is failing on master-travis?
< morcos> BlueMatt: I think it's fixed in #10704
< gribble> https://github.com/bitcoin/bitcoin/issues/10704 | [tests] nits in dbcrash.py by jnewbery · Pull Request #10704 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] practicalswift opened pull request #10714: Avoid printing incorrect block indexing time due to uninitialized variable (master...avoid-uninitialized-nStart) https://github.com/bitcoin/bitcoin/pull/10714
< BlueMatt> cool, though whats up with the blockchain.py crashes?
< jnewbery> BlueMatt: blockchain.py crashes? Do you have a link?
< BlueMatt> a day or two ago it did
< BlueMatt> sec
< jnewbery> can't see it in recent master runs on travis
< MarcoFalke> BlueMatt: I think this should be fixed after #10659
< gribble> https://github.com/bitcoin/bitcoin/issues/10659 | [qa] blockchain: Pass on closed connection during generate call by MarcoFalke · Pull Request #10659 · bitcoin/bitcoin · GitHub
< jnewbery> yes - I think you're right
< jnewbery> last failure on Travis was 6 days ago, so I think we're good
< BlueMatt> ah, cool :)
< BlueMatt> figured someone was fixing it :)
< bitcoin-git> [bitcoin] practicalswift opened pull request #10715: scripted-diff: Prefer x.empty() over x.size() == 0 or x.length() == 0 (master...empty) https://github.com/bitcoin/bitcoin/pull/10715
< achow101> What is it with these trolls in the issues tracker?