Remove 16 bits from versionbits signalling system (BIP320)#13972
Remove 16 bits from versionbits signalling system (BIP320)#13972btcdrak wants to merge 2 commits into
Conversation
|
Code df4b187 looks good and corresponds to BIP proposal. I have no particular opinion about whether or not the concept is a good idea (but I don't see why it wouldn't be). |
|
Prior discussion: #12633 I have not seen consensus for this protocol change, nor any notable effort to gain consensus for it. I don't think it's a good precedent to set, to make protocol changes in Core simply as a result of miners violating the protocol without consensus. |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
Potentially superseded by entirely removing this warning in #15471. |
|
Concept ACK. I really don't know whether this one or #15471 is preferable, but I think something needs to be done against the false positives soon as this seems to be more controversial than removing the warning. Can still be done later, if wanted. |
|
Concept ACK. |
maflcko
changed the title
|
Updated pull request title with assigned BIP number https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki |
|
@TheBlueMatt does BIP-320 assign the same version bits as your BetterHash draft BIP? If so, maybe that's useful to point out in BIP-320 and/or vice versa. |
|
Concept ACK |
|
Rebased. |
|
FWIW, this still seems to confuse our users: see issue #16343 ("warning='45 of last 100 blocks have unexpected version"). |
|
Concept ACK, but to answer @luke-jr concerns, perhaps this deserves a BIP. |
|
Continued confusion for our users: see issue #17295 :( |
| The last travis run for this pull request was 293 days ago and is thus outdated. To trigger a fresh travis build, this pull request should be closed and re-opened. |
|
Given the author is no longer active, and one of the last comments on the issue from @laanwj in #15471:
I'm going to close this. However given this has 4 Concept ACKs, I'll mark it as "up for grabs". |
|
Note that Stratum V2 also supports BIP-310 / BIP-320 version bit rolling and claims it is "extremely common and widely adopted". In any case, now that we suppress spurious notifications I suppose we can kick this discussion can down the road until we actually need bit 13 in the year 2050 or so :-) I'd be curious to know if that's all the bits realistically needed - for the next 50 years - given some reasonable assumptions about thermodynamic limits to mining. But this is more of a bitcoin-dev mailinglist thing. To answer my own question from two years ago:
BIP-310 describes a negotiation process where the miner indicates which bits it can roll, how many bits it wants to roll, and then the pool answers which bits it permits (taking into account ongoing softfork signalling and such). |
11 participants
Over 5% of the hashpower is currently using version-rolling which consumes bits from the nVersion in the blockheader. Miners are generally using the the bits within the range 0x1fffe000 as per recommendation in the reserved bits proposal as well as the BIP 310 stratum-extension for version-rolling.
Before this pull request the BIP9/versionbits system will emit false warnings for unknown softforks when version-rolling is used. This pull request removes the bits in the range 0x1fffe000 so version-rolling, or other miner use of those bits, will not falsely trigger the warning system or interfere with soft forks.
False positive warnings are toxic because it leads to node operators ignoring warning messages, thus defeating the purpose of a warning system.