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

BIP100: Dynamic maximum block size by miner vote #1

Open
wants to merge 10 commits into
base: 0.12
from

Conversation

Projects
None yet
6 participants
@dgenr8
Member

dgenr8 commented Mar 13, 2017

These changes are for Bitcoin Core 0.12. For the XT version, see bitcoinxt/bitcoinxt#188.

Implementation of the BIP100 specification as published.

Full nodes need no configuration to follow the network sizelimit as determined by BIP100. Miners may set their coinbase /B vote using

-maxblocksizevote=<n> Set vote for maximum block size in megabytes (default: network sizelimit)

Most RPC's return the sizelimit as of the current tip, consistent with the other attributes. getblocktemplate returns the sizelimit for a block built on the current tip, which may change by a factor of up to 1.05 at the start of a difficulty interval, per the specification.

On first run, block index entries starting at the activation height (449568, which was in January 2017) are updated to track miner size votes and sizelimit history. Use -debug=reindex (NOT -reindex) to see the progress of this update.

The current network sizelimit is published in the user agent string as EB.

This implementation does not lift the 32MB physical MAX_SIZE limit. File buffer sizes, sanity checks in bitcoin-tx, verifytxoutproof, outbound bandwidth limiting (core version only), and merkle blocks also continue to reference MAX_BLOCK_SIZE as a general scale indicator.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Mar 14, 2017

What's the reason for doing this on top of 0.12(which is a year out of date at this point)? We are currently on version 0.14.

jameshilliard commented Mar 14, 2017

What's the reason for doing this on top of 0.12(which is a year out of date at this point)? We are currently on version 0.14.

@dgenr8

This comment has been minimized.

Show comment
Hide comment
@dgenr8

dgenr8 Mar 14, 2017

Member

@jameshilliard Two reasons. We aren't the best people to port these changes to segwit, and most miners currently would rather not run segwit.

Member

dgenr8 commented Mar 14, 2017

@jameshilliard Two reasons. We aren't the best people to port these changes to segwit, and most miners currently would rather not run segwit.

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Mar 14, 2017

@dgenr8 Not sure what segwit has to do with it, most changes between 0.12 and 0.14 don't have anything to do with segwit, 0.12 isn't really suitable for mining anymore since there are known DoS vectors in addition to not supporting compact blocks for connecting to the relay network or CPFP.

jameshilliard commented Mar 14, 2017

@dgenr8 Not sure what segwit has to do with it, most changes between 0.12 and 0.14 don't have anything to do with segwit, 0.12 isn't really suitable for mining anymore since there are known DoS vectors in addition to not supporting compact blocks for connecting to the relay network or CPFP.

@dgenr8

This comment has been minimized.

Show comment
Hide comment
@dgenr8

dgenr8 Mar 14, 2017

Member

@jameshilliard What are the PR numbers of the DoS fixes?

Member

dgenr8 commented Mar 14, 2017

@jameshilliard What are the PR numbers of the DoS fixes?

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Mar 14, 2017

@dgenr8 I probably shouldn't list them in case someone ends up wanting to try and exploit them. Even if the fixes were backported 0.12 would still not be suitable for mining.

jameshilliard commented Mar 14, 2017

@dgenr8 I probably shouldn't list them in case someone ends up wanting to try and exploit them. Even if the fixes were backported 0.12 would still not be suitable for mining.

@dagurval

This comment has been minimized.

Show comment
Hide comment
@dagurval

dagurval Mar 15, 2017

Member

@jameshilliard CPFP and CB good additions but are not required for mining. Could you send me an e-mail at dagurval@pvv.ntnu.no with your DoS conserns?

Member

dagurval commented Mar 15, 2017

@jameshilliard CPFP and CB good additions but are not required for mining. Could you send me an e-mail at dagurval@pvv.ntnu.no with your DoS conserns?

@jameshilliard

This comment has been minimized.

Show comment
Hide comment
@jameshilliard

jameshilliard Mar 15, 2017

@dagurval They are effectively required at this point in order to be competitive, I don't think cherry picking from upstream is a good idea as the fix for at least one DoS would be quite obvious from the commit and could then be used against any 0.12 nodes that haven't updated yet.

jameshilliard commented Mar 15, 2017

@dagurval They are effectively required at this point in order to be competitive, I don't think cherry picking from upstream is a good idea as the fix for at least one DoS would be quite obvious from the commit and could then be used against any 0.12 nodes that haven't updated yet.

@dagurval

This comment has been minimized.

Show comment
Hide comment
@dagurval

dagurval Mar 15, 2017

Member

Thanks for your concerns @jameshilliard. Too bad that you could not contribute.

Member

dagurval commented Mar 15, 2017

Thanks for your concerns @jameshilliard. Too bad that you could not contribute.

@dgenr8

This comment has been minimized.

Show comment
Hide comment
@dgenr8

dgenr8 Mar 21, 2017

Member

Pushed a parser bugfix from @dagurval. We'll squash these after a while.

Member

dgenr8 commented Mar 21, 2017

Pushed a parser bugfix from @dagurval. We'll squash these after a while.

@dgenr8

This comment has been minimized.

Show comment
Hide comment
@dgenr8

dgenr8 Mar 23, 2017

Member

Pushed changes to support specification update jgarzik/bip100#20.

Member

dgenr8 commented Mar 23, 2017

Pushed changes to support specification update jgarzik/bip100#20.

@dgenr8

This comment has been minimized.

Show comment
Hide comment
@dgenr8

dgenr8 Mar 26, 2017

Member

Pushed coinbaseaux support from @dagurval.

Member

dgenr8 commented Mar 26, 2017

Pushed coinbaseaux support from @dagurval.

dgenr8 and others added some commits Jan 7, 2017

BIP100: Dynamic max block size by miner vote
With Dagur Johannsson <dagurval@pvv.ntnu.no>
BIP100: Unit and regression tests
Unit tests for GetNextMaxBlockSize and FindVote.
Multi-node voting regression test.

With Tom Harding <tomh@thinlink.com>
Includes regtest routines by Gavin Andresen <gavinandresen@gmail.com>
Specification update - max sigops calc
Max sigops calculation changed to use actual block size
rather than hardLimit
Add BIP100 string to getblocktemplate
This adds BIP100 votes to blocks generated by miner software that
uses the rpc call getblocktemplate.
Implement spec update: vote search edge cases
A vote of zero in either B or EB is distinct from garbage.
@dgenr8

This comment has been minimized.

Show comment
Hide comment
@dgenr8

dgenr8 May 2, 2017

Member

Pushed vote search edge cases and some squashes.

Member

dgenr8 commented May 2, 2017

Pushed vote search edge cases and some squashes.

@dgenr8 dgenr8 closed this Sep 19, 2018

@dgenr8 dgenr8 deleted the dgenr8:core-0.12-bip100 branch Sep 19, 2018

@dgenr8 dgenr8 restored the dgenr8:core-0.12-bip100 branch Sep 19, 2018

@dgenr8 dgenr8 reopened this Sep 19, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment