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

BIP100: Dynamic maximum block size by miner vote #1

Open
wants to merge 10 commits into
base: 0.12
from

Conversation

@dgenr8
Copy link
Member

@dgenr8 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
Copy link

@jameshilliard 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
Copy link
Member Author

@dgenr8 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
Copy link

@jameshilliard 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
Copy link
Member Author

@dgenr8 dgenr8 commented Mar 14, 2017

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

@jameshilliard
Copy link

@jameshilliard 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
Copy link
Member

@dagurval 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
Copy link

@jameshilliard 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
Copy link
Member

@dagurval dagurval commented Mar 15, 2017

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

@dgenr8
Copy link
Member Author

@dgenr8 dgenr8 commented Mar 21, 2017

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

@dgenr8
Copy link
Member Author

@dgenr8 dgenr8 commented Mar 23, 2017

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

@dgenr8
Copy link
Member Author

@dgenr8 dgenr8 commented Mar 26, 2017

Pushed coinbaseaux support from @dagurval.

dgenr8 and others added 7 commits Jan 7, 2017
With Dagur Johannsson <dagurval@pvv.ntnu.no>
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>
Max sigops calculation changed to use actual block size
rather than hardLimit
This adds BIP100 votes to blocks generated by miner software that
uses the rpc call getblocktemplate.
A vote of zero in either B or EB is distinct from garbage.
@dgenr8 dgenr8 force-pushed the dgenr8:core-0.12-bip100 branch to f4d66fd May 2, 2017
@dgenr8
Copy link
Member Author

@dgenr8 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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.