< bitcoin-git> [bitcoin] CryptAxe opened pull request #11098: [Qt] Add spend all button to the SendCoinsDialog (master...spendall) https://github.com/bitcoin/bitcoin/pull/11098
< marek_> I wanna ask question. If I build bicoind with shared libraries, the version of the libraries is 0.0.0...is it wanted?
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/262167393d05...a8532299d8b9
< bitcoin-git> bitcoin/master c1470a0 Wladimir J. van der Laan: test: Increase initial RPC timeout to 60 seconds...
< bitcoin-git> bitcoin/master a853229 Wladimir J. van der Laan: Merge #11091: test: Increase initial RPC timeout to 60 seconds...
< bitcoin-git> [bitcoin] laanwj closed pull request #11091: test: Increase initial RPC timeout to 60 seconds (master...2017_08_test_wait_for_rpc) https://github.com/bitcoin/bitcoin/pull/11091
< bitcoin-git> [bitcoin] greenaddress opened pull request #11099: [RPC][mempool]: add rpc command to dump the mempool to disk (master...dump_mempool_rpc) https://github.com/bitcoin/bitcoin/pull/11099
< * luke-jr> prods #10595
< luke-jr> #11026 seems merge-ready
< BlueMatt> luke-jr: does it make sense to support non-segwit miners in 0.16? why not just remove some code instead?
< luke-jr> BlueMatt: I don't think we should force miners to support Segwit. Wait until they all do so by choice IMO.
< luke-jr> BlueMatt: also, bugfixes should go into 0.15 too
< luke-jr> (even if the related code is removed in 0.16)
< BlueMatt> 10595 is not gonna make 15, its wayyyy too late (and is not a regression, even if you call it a bugfix)
< luke-jr> it's 2 months old now :p
< BlueMatt> I mean I dont disagree, but they could just as easily run pre-0.13.1 with 0.14/15 proxies
< promag> luke-jr: move comment https://github.com/bitcoin/bitcoin/pull/11026#issuecomment-322063440 to PR description?
< BlueMatt> ok, well I apologize I missed it until now
< luke-jr> BlueMatt: it has no practical effect, so 0.15.1 is fine
< BlueMatt> well my point is segwit is gonna activate by then, so we can see if its even needed at that point :p
< luke-jr> promag: k
< luke-jr> BlueMatt: 0.15.1 shouldn't remove features
< gmaxwell> sensible 0.15.1 thing.
< luke-jr> BlueMatt: note that #10595 isn't about Segwit active or not, but about whether the GBT client supports it
< BlueMatt> I'm aware, yes
< gmaxwell> luke-jr: I think matt's point is that it won't matter much if thats supported if it's virtually unused.
< luke-jr> it doesn't matter much either way
< BlueMatt> well other question, do any gbt clients actually care about those fields?
< luke-jr> just would be nice to get fixed so long as we support it
< BlueMatt> it was my impression they ignored them entirely and just used the txn selected by bitcoind
< luke-jr> BlueMatt: no, that's why it doesn't matter much
< BlueMatt> yea, ok
< luke-jr> there might be some edge cases for p2pool or Eligius since they make large generation txns
< luke-jr> but hopefully they'll just upgrade to Segwit if they haven't yet
< luke-jr> (and until then, a workaround is to set maxblocksize lower)
< gmaxwell> on that subject can we please stop setting irrational defaults for the maximum size.
< BlueMatt> what default do we have for max size?
< luke-jr> so reduce it?
< gmaxwell> we default to a maximum weight of 3million.
< BlueMatt> is it not just max_block_weight - sensible overhead of generation tx?
< BlueMatt> wtf whyyyyy
< BlueMatt> yea, lets fix that, please
< gmaxwell> because luke-jr
< luke-jr> because 1 MB blocks are not safe
< gmaxwell> -makemelosemoneyplease=1
< luke-jr> if we're going to go this road, we should softfork the block size limit down.
< BlueMatt> luke-jr: irrespective if they're ideal for the network or not, they are locally non-optimal for miners/users, something we should (and historically have always tried to) try to avoid
< BlueMatt> luke-jr: ok, go find consensus for that change then we'll make it happen!
< gmaxwell> the only effect these settings have is showing the world that we're idiots who don't care about the software working in reasonable ways.
< gmaxwell> Personally opting to use a lower size just makes to lose money, unless you're controlling hashpower for other people, in which case it makes them lose money.
< luke-jr> BlueMatt: no, historically we have tried to do what is best for the network. changing that has been an unfortunate campaign of some devs.
< gmaxwell> That is much of the reason that "have an infinite max blocksize and hope people will set it sensibly" doesn't work.
< BlueMatt> luke-jr: er, no, weve done things that are good for the network at very small difference for miners/users, we do not do things which are significantly non-optimal to the point that ~every user just changes the default
< gmaxwell> luke-jr: having a consistenct size is best for the network, smaller sizes make fee estimation less reliable, and hardly improve anything. Lower _limits_ are another matter.
< luke-jr> only if the fee estimation logic is broken
< gmaxwell> no, there is nothing broken.
< bitcoinreminder> does anyone has a bitcoin-org email address? I created a impersonation-request on twitter for the fake https://twitter.com/BcoreProject account, but they told me that someone with a bitcoin-org email address has to create the request
< gmaxwell> occasional blocks with mysteriously lower size makes the network capacity less predictable.
< luke-jr> bitcoinreminder: bitcoin.org isn't even Bitcoin Core..
< gmaxwell> no use in educating twitter on that.
< bitcoinreminder> sorry, I meant bitcoin-core.org
< gmaxwell> bitcoinreminder: email domain@bitcoin.org
< gmaxwell> thats cobra.
< gmaxwell> feel free to CC me or wladimir.
< BlueMatt> oh, @bitcoincore.org? I assume someone does...
< luke-jr> bitcoinreminder: or do you mean bitcoincore.org ? just copy/paste what you mean :/
< bitcoinreminder> no sorry, I was talking about bitcoin-core
< bitcoinreminder> :P
< gmaxwell> hm.
< gmaxwell> do we even have email working there.. BlueMatt
< BlueMatt> gmaxwell: dunno, i see that there is an mx record, and there are at least aliases to send to it
< luke-jr> I'd expect btcdrak to be the one to know
< bitcoinreminder> just want to tell you, feel free do keep it in mind or ignore it :D
< bitcoinreminder> its just sad to see so much fud/lies spread there
< BlueMatt> yea, I assume btcdrak can figure out how to make it send
< gmaxwell> bitcoinreminder: sounds super useful. yea, we'll get btcdrak to handle it.
< bitcoinreminder> ok cool :)
< bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11100: Use a sensible default for blockmax{size,weight} (master...2017-08-sane-default-limits) https://github.com/bitcoin/bitcoin/pull/11100
< BlueMatt> gmaxwell: there you go ^
< * sipa> just wrote an 8-way AVX2 SHA256
< BlueMatt> sipa: PR plox
< sipa> it seems to work
< sipa> BlueMatt: where would we use it?
< sipa> merkle root calculation perhaps
< BlueMatt> sipa: yes, taht
< BlueMatt> that
< gmaxwell> sipa: is it faster than anything
< sipa> gmaxwell: haven't benchmarked
< BlueMatt> sipa: it would also be kinda nice to use that during block deserialization to set the hashes of the txn, but that would be a nontrivial change to serialization code :/
< sipa> yes...
< BlueMatt> but, yea, I'd be super excited to see something that makes merkle root calculation any faster
< BlueMatt> its one of my bigger bottlenecks
< gmaxwell> BlueMatt: I really want changes that let us NOT hash the transactions, so we can use that for rescan...
< sipa> and block serving
< BlueMatt> gmaxwell: yea, that too
< sipa> BlueMatt: all good as long as you don't PR that :p
< BlueMatt> heh, fair
< * luke-jr> ponders reopening #3229 since garzik and hearn shot it down, and it remains a good idea
< kanzure> luke-jr: what about providing a 'transitional' config for miners (based on the previous values), including big warning in the release notes, and then next release deprecate that extra config example file?
< kanzure> (for #3229)
< luke-jr> kanzure: what do you mean example? just a snippet in the release notes?
< kanzure> uhh maybe. that might satisfy the concern from wumpus.