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