< * 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/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).