Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
BIP100: Dynamic max block size by miner vote #398
This is a Bitcoin Unlimited port of the reference implementation of the BIP100 specification.
As anticipated in BUIP002 Multi-BIP Scaling Enabler, a
In BIP100 mode, at each difficulty retargeting, miners' block size votes are tallied and EB is automatically moved toward the size that 75% of miners will accept immediately, in 5% change increments. The first such increase will lead to a hard fork, so miners are advised to signal 1MB until ready, just as with pure EC. Subsequent increases or decreases will be followed by all BIP100 nodes without disagreement.
The operation of AD is not altered by
Full nodes need no configuration to follow the network sizelimit as determined by BIP100. Miners may set their coinbase /B vote using
Several RPC's are enhanced to return the bip100 sizelimit as of the current tip, regardless of whether
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.
Built on #385 which helps the operation of the bip100-sizelimit.py test.
Known TODOs: Update Unlimited GUI as anticipated in BUIP002.
pushed a commit
this pull request
Apr 2, 2017
@deadalnix My feeling is that BU is about giving the choice to users of our software. I don't think you have to support BIP100 to support giving uses the option of using it. We're all about developers getting out of the business of telling users (i.e. miners, full nodes) what to do. As far as I'm aware, this approach was agreed in BUIP002.
@dgenr8 This is good work. Do you have a reference implementation for BIP100 somewhere?
Also I have been do a bit of QT/GUI work on BU Lately and would welcome the opportunity to build a GUI for BIP100. If you have not started on this I would like to help.
I think there is an expectation from contributing reviewers that code review is one activity, and thorough testing is another.
And to a large extent, I agree with this view and think that they are two separate activities, and the testing activity needs to be done as @gandrewstone points out, but I think we need to appreciate all review contributions, and arrange testing formally to ensure it's done.
That applies to all feature PRs.
I certainly don't know what the in place "signoff" procedures are, and maybe that's the case for others here too. In that case we should document how we want this to work. Apologies if I missed some existing documentation that explains the procedure - feel free to point me to it.
My suggestion would be to coordinate on the required level of verification as soon as a PR is submitted, and make it explicit here in Github, e.g. through "Assigned" field and labels.