< sturles>
gmaxwell: I have been running the following for a few days, after reading your tip to sdaftuar about listing segwit transactions on top of the mempool: while sleep 10; do bitcoin-cli getblocktemplate | jq '.transactions | .[] | select(.hash != .txid) | .txid' >> swtxlog; done
< sturles>
swtxlog is still empty. I haven't seen a single one. Not even my own.
< sturles>
Does it work?
< sturles>
I have set blockmaxwight=4000000 and blockmaxsize is unset. blockmintxfee=0
< sturles>
The highest total size I have seen in the CreateNewBlock() lines in debug.log is 998231, and the highest block weight is 3992816.
< sipa>
sturles: you need to tell GBT that you're segwit capable
< sipa>
bitcoin core supports non-segwit capable mining software; it just won't include any segwit txn for them
< sturles>
How?
< arubi>
sturles, add '{"rules": ["csv","segwit"]}' to the getblocktemplate call
< arubi>
you should be also getting a 'default_witness_commitment' field that wasn't there before
< sturles>
That's better!
< sturles>
Lots of transactions and total size > 1000000.
< bitcoin-git>
[bitcoin] theuni opened pull request #11227: RFC: switch to libevent for node socket handling (master...minimal-libevent3) https://github.com/bitcoin/bitcoin/pull/11227
< meshcollider>
gmaxwell: sounds like it to me, achow101 when you tested it on windows, does the thumbnail that pop up from the taskbar look as described or does it still show the window?
< meshcollider>
I would guess that windows just takes what the window currently looks like which is nothing if its not onscreen, but im not sure
< achow101>
gmaxwell: yes
< achow101>
meshcollider: yes
< gmaxwell>
::sigh::
< meshcollider>
if we're getting this many issues with it, maybe we do need to get the fix into 0.15.0
< gmaxwell>
it isn't a new issue at least, as far as I can tell.
< gmaxwell>
it's just obnoxious that such a low value feature (saving the window position across starts) results in such a serious bug.
< meshcollider>
achow101 have you got any further with the mem access violation crash in #11171?
< achow101>
meshcollider: not really.
< achow101>
see the comment I made which is about as far as I got with it
< achow101>
I think it has to do with a weird string for the proxy which is causing it to get all messed up
< meshcollider>
So it's probably a once off incident, not going to be reproduced without deliberate tampering?
< meshcollider>
Btw can someone rerun Travis on #11178, failure in unrelated test
< achow101>
meshcollider: done
< meshcollider>
Thanks :)
< meshcollider>
sipa: sorry what does your comment on #11210 mean?
< sipa>
meshcollider: you're thinking that i would suggest having a single catch around the whole block - i'm pointing out that i won't suggest that, because it would be incorrect