Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore warning for individual unknown version bits, as well as unknown version schemas #15861

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
7 participants
@luke-jr
Copy link
Member

commented Apr 20, 2019

Prior to #15471, we had a warning for 50% of versions being unexpected as a whole. Overt ASICBoost abuses broke that, so it was removed.

This restores the warning, but only looks for 50% of each version bit independently, or 50% with an unknown version schema. Hopefully this shouldn't get triggered by (or at least can be more practically avoided by) ASICBoost stuff.

Additionally, it changes the phrasing of the warning to reflect the uncertainty of the cause, and avoid searches from turning up "not to worry" responses (that were given to the now-removed warning).

@DrahtBot

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2019

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #13972 (Remove 16 bits from versionbits signalling system (BIP320) by btcdrak)

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.

@fanquake fanquake added the Validation label Apr 20, 2019

@gmaxwell

This comment has been minimized.

Copy link
Member

commented Apr 21, 2019

I think I'd rather (or additionally) ignore some bits for warning... the issue with bit-limiting it is that it could still false trigger.

@luke-jr

This comment has been minimized.

Copy link
Member Author

commented Apr 21, 2019

Only if a majority of miners violate the protocol. To set aside bits for ASICBoost is a protocol change, that hasn't had community support demonstrated for. Developers alone don't get to make that call.

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

Tend to NACK. Seems a lot of code for a feature that has no use case.

@gmaxwell

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

NAK. Doesn't actually fix the thing it intends to fix.

@luke-jr

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

The use case is to provide a proper warning that the protocol rules may be changing and the user should consider upgrading (either to the new rules, or a rule-blocking fork).

NAK. Doesn't actually fix the thing it intends to fix.

If there's a bug in it, report the bug...

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

If a future softfork is activated though versionbits on a single bit in less than 100 blocks, you might as well leave away signalling altogether. For other versionbits-activated (i.e. BIP-9 compatible) softforks we already warn appropriately before your change.

@luke-jr

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

BIP 9 does not require the expected 95% for the other warning, and we currently lack any warning for different schemas.

@MarcoFalke

This comment has been minimized.

Copy link
Member

commented Apr 22, 2019

currently lack any warning for different schemas

Indeed. And your code doens't offer a warning for any kind of schema either. So I'd prefer if we just embraced that fact and avoided any softfork deployments that are incompatible with the existing BIP9 warning mechanism.

@luke-jr

This comment has been minimized.

Copy link
Member Author

commented Apr 22, 2019

Yes, it does... And again, the other warning doesn't work for all potential BIP 9 deployments either (they can use a lower threshold). On top of that, it's generally accepted that BIP 9 was a failure, and it's pretty likely future deployments will use other mechanisms.

@Seccour

This comment has been minimized.

Copy link

commented Apr 25, 2019

Concept ACK. Miners not using the version numbers as intended should not be a reason to remove the warning.

Only if a majority of miners violate the protocol. To set aside bits for ASICBoost is a protocol change, that hasn't had community support demonstrated for. Developers alone don't get to make that call.

Setting aside bits for ASICBoost should have community support. I agree with Luke on that one.

@jnewbery

This comment has been minimized.

Copy link
Member

commented Apr 25, 2019

Concept NACK for the reasons @MarcoFalke gives

@luke-jr luke-jr force-pushed the luke-jr:restore_vbits_warning branch from 1e8361c to f7fa445 May 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.