< * luke-jr> would like to know real reasons for NACKs on #15861 rather than unsubstantiated claims that it doesn't work… (it's even tested, so it sure does seem to work)
< gribble> https://github.com/bitcoin/bitcoin/issues/15861 | Restore warning for individual unknown version bits, as well as unknown version schemas by luke-jr · Pull Request #15861 · bitcoin/bitcoin · GitHub
< gmaxwell> I don't think having warings that we know are going to false trigger with non-trivial probablity is worth it.
< gmaxwell> the false alarms undermine the ability to have good warnings in the future.
< luke-jr> there's no reason to expect false alarms with these
< luke-jr> wouldn't that take 100% of miners abusing ASICBoost?
< luke-jr> I guess I'm assuming the bogus bits are 50/50 - is that not the case?
< echeveria> "abusing"
< echeveria> you should just assume that 100% of people will use an obvious optimisation.
< luke-jr> I guess echeveria unanimously represents consensus for adopting a patented exploit into the Bitcoin protocol
< echeveria> using heavily loaded adjectives to describe everything isn't helping your case particularly.
< gmaxwell> luke-jr: if someone is doing 2-way AB, you'll get each bit set 50% of the time and trigger. If someone is doing 4-way with bit aligned versions each bit will be set 50% of the time.. and trigger. If a large portion but not all hashpower is using it, it'll still false trigger... just less often.
< luke-jr> gmaxwell: what threshold would you be comfortable with? surely not 95% is needed?
< sipa> luke-jr: you don't need to personally agree with a protocol choice to see that it's in the best interest of users of your software to not warn about something you know is harmless
< sipa> the reality is that miners are using AB, and that isn't going to change, with or without a warning
< gmaxwell> And not false triggering a warning doesn't mean that it's approved.
< gmaxwell> If anything, not acting to block it is the only kind of "approval" that matters in any case.
< luke-jr> sipa: users can still be informed that miners are violating the protocol; but that's beside the point I think, as the intent here is to warn for real deployments
< gmaxwell> luke-jr: I'd be comfortable with taking two or three bits and just ignoring them.
< gmaxwell> There is no reason that we'd need to use all the bits for intentional upgrades.
< luke-jr> hmm
< gmaxwell> Ignoring them doesn't mean that they're magically free for asicboost use either... they're just ignored, and shouldn't be used for intentional bip9 upgrades.
< echeveria> luke-jr: I've watched the results of this, users come to #bitcoin and you try to panic them about how "miners are exploiting bitcoin". this is deeply unhelpful and doesn't achieve what you think it does.
< luke-jr> gmaxwell: it will certainly be interpreted that way - see OP_RETURN
< luke-jr> gmaxwell: but perhaps leaving the 95% in place is sufficient to deter that? dunno
< luke-jr> gmaxwell: happen to know off-hand which bits are being abused? are they the ones btcdrak wrote up in a PR?
< echeveria> warnings in debug.log are not deterring anybody from their actions, especially when what is creating those warnings is profit motivated.
< gmaxwell> luke-jr: dunno, would have to look. though also if there were a reason to use different ones I expect we could get people to move
< luke-jr> eh, in that case couldn't they just all pick random bits to avoid triggering 50% on any one?
< echeveria> the bits are baked into miner firmware. you'd really struggle to get anybody to change them, especially when the motivation is something as invisible as not causing warnings in sotware that nobody can see.
< luke-jr> echeveria: it's plainly displayed in the GUI
< echeveria> if it's displayed in my copy of bitcoin-qt I've literally never noticed it.
< luke-jr> looks like for the past 6562 blocks, we have bit 13=379(5%) 14=465(7%) 15=475(7%) 16=499(7%) 17=501(7%) 18=503(7%) 19=490(7%) 20=494(7%) 21=489(7%) 22=1695(25%) 23=1639(24%) 24=497(7%) 25=493(7%) 26=499(7%) 27=504(7%) 28=363(5%) 29=6562(100%) 30=5(0%)
< luke-jr> (BIP9 signature is 29=1, 30=0, 31=0)
< luke-jr> so nowhere near triggering 50%, but if we want to be safe, it looks like sticking to bits 0-11 would be clear, maybe 0-21 if we want more
< bitcoin-git> [bitcoin] IntegralTeam opened pull request #15873: Rpc removemempoolentry (master...rpc-removemempoolentry) https://github.com/bitcoin/bitcoin/pull/15873
< darosior> Hi, in this comment (https://github.com/bitcoin/bitcoin/blob/08bd21a3bda9f621948c535e951880d7e318caa5/src/qt/bitcoingui.cpp#L1228) does decrypt means unlocking the wallet for the session or decrypt forever ?
< bitcoin-git> [bitcoin] 251Labs opened pull request #15874: Resolve the qt/guiutil <-> qt/optionsmodal CD (master...patch/resolve-guiutil-optionsmodel-cd) https://github.com/bitcoin/bitcoin/pull/15874
< bitcoin-git> [bitcoin] Sjors opened pull request #15876: 2019/04/signerbumpfee (master...2019/04/signerbumpfee) https://github.com/bitcoin/bitcoin/pull/15876
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/08bd21a3bda9...caceff55465e
< bitcoin-git> bitcoin/master fa465e4 MarcoFalke: test: Add missing syncwithvalidationinterfacequeue to wallet_import_rescan
< bitcoin-git> bitcoin/master caceff5 MarcoFalke: Merge #15866: test: Add missing syncwithvalidationinterfacequeue to wallet...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15866: test: Add missing syncwithvalidationinterfacequeue to wallet_import_rescan (master...1904-testSync) https://github.com/bitcoin/bitcoin/pull/15866
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/caceff55465e...2d5419feed48
< bitcoin-git> bitcoin/master c9e6e7e Karl-Johan Alm: wallet: add cachable amounts for caching credit/debit values
< bitcoin-git> bitcoin/master 2d5419f Wladimir J. van der Laan: Merge #15780: wallet: add cachable amounts for caching credit/debit values...
< bitcoin-git> [bitcoin] laanwj merged pull request #15780: wallet: add cachable amounts for caching credit/debit values (master...cachable-accounts) https://github.com/bitcoin/bitcoin/pull/15780
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2d5419feed48...cd14d210c415
< bitcoin-git> bitcoin/master 710a713 João Barbosa: rpc: Speedup getaddressesbylabel
< bitcoin-git> bitcoin/master cd14d21 MarcoFalke: Merge #15463: rpc: Speedup getaddressesbylabel
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15463: rpc: Speedup getaddressesbylabel (master...2019-02-fix-15447) https://github.com/bitcoin/bitcoin/pull/15463
< bitcoin-git> [bitcoin] keepkeyjon opened pull request #15877: Fix argument docs grammar (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15877
< jonasschnelli> [bitcoin-dev] Improving Pre and Post Merging Abilities With Rewriting Core In Python
< jonasschnelli> ^^
< wumpus> of course, in python !
< sdaftuar> so, humor aside, i was curious about what "improving pre and post merging abilities" could mean to someone
< sdaftuar> (though it was hard for me to put the humor aside)
< wumpus> good question
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cd14d210c415...e9e777e21b42
< bitcoin-git> bitcoin/master fa1c8e2 251: Resolve the qt/guiutil <-> qt/optionsmodal CD
< bitcoin-git> bitcoin/master e9e777e Jonas Schnelli: Merge #15874: Resolve the qt/guiutil <-> qt/optionsmodel CD
< bitcoin-git> [bitcoin] jonasschnelli merged pull request #15874: Resolve the qt/guiutil <-> qt/optionsmodel CD (master...patch/resolve-guiutil-optionsmodel-cd) https://github.com/bitcoin/bitcoin/pull/15874
< sipa> sdaftuar: it seems python is also faster
< sdaftuar> sipa: of course. it has C support.
< luke-jr> lol
< ryanofsky> would guess something to do with pre and post-merge code reviews
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e9e777e21b42...4bd7187da817
< bitcoin-git> bitcoin/master 6dd469a practicalswift: Disconnect BlockNotifyGenesisWait and RPCNotifyBlockChange properly. Remov...
< bitcoin-git> bitcoin/master 4bd7187 MarcoFalke: Merge #15699: Remove no-op CClientUIInterface::[signal_name]_disconnect. D...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15699: Remove no-op CClientUIInterface::[signal_name]_disconnect. Disconnect BlockNotifyGenesisWait and RPCNotifyBlockChange properly. (master...remove-CClientUIInterface-signal_name_disconnect) https://github.com/bitcoin/bitcoin/pull/15699
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4bd7187da817...40a720acb847
< bitcoin-git> bitcoin/master faca95e MarcoFalke: qa: Make swap_magic_bytes in p2p_invalid_messages atomic
< bitcoin-git> bitcoin/master 40a720a MarcoFalke: Merge #15697: qa: Make swap_magic_bytes in p2p_invalid_messages atomic
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15697: qa: Make swap_magic_bytes in p2p_invalid_messages atomic (master...1904-qaMagicAtomic) https://github.com/bitcoin/bitcoin/pull/15697
< bitcoin-git> [bitcoin] hebasto opened pull request #15880: utils and libraries: Replace deprecated Boost Filesystem functions (master...20190423-boost-coding-guidelines) https://github.com/bitcoin/bitcoin/pull/15880
< tryphe> anyone running core on windows? someone in #bitcoin is saying that the ::system() call for -blocknotify= and others pops up a shell window while the command is running. this makes sense, as it's the default functionality of cmd.exe when spawned by system(). anyways, i have a proposed fix if someone can compile on windows *sic*, which the user can't
< molz> tryphe, i compile my own windows bitcoin, let me pm you
< tryphe> molz, ok, thanks!
< ElePHPhant> molz: How long did you wait?
< ElePHPhant> It takes anywhere from a few minutes to hours for that thing to run to me (seemingly).
< ElePHPhant> *for me
< ElePHPhant> And that's from 5 years ago...
< promag> is rc4 the last?
< jonasschnelli> promag: lets hope
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15881: net: Send txs without delay on regtest (master...1904-txRelayRegtest) https://github.com/bitcoin/bitcoin/pull/15881
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15858: Faster tests with topological mempool rpc sync 🚀 (master...1904-qaSync) https://github.com/bitcoin/bitcoin/pull/15858