Moved to https://github.com/bitcoin/bips/blob/master/bip-0105.mediawiki
Last active
July 2, 2021 21:16
-
-
Save btcdrak/1c3a323100a912b605b5 to your computer and use it in GitHub Desktop.
Since hashing produces uniformly distributed pseudorandom numbers half the block hashes of blocks that meet the target are actually below half the target, a third below a third the target, and 90% below 90% of the target. Doesn't that mean that miners get almost free votes in favour of a 10% increase?
@mmeijeri I agree it's better to use binary votes. I'm just more concerned about the other details as the format of the votes is relatively minor.
Regarding your comments on miner luck, it doesnt matter because they cant mine and then cast their vote, as they commit to the vote in the coinbase before solving the PoW hash. Some votes will get a lucky hash, some will be unlucky.
@rubensayshi Ensures most of the mining power is on the same page regarding blocksize.
How does having to cast a vote first help? Wouldn't they simply set all their votes to the maximum value?
Some votes will get a lucky hash, some will be unlucky.
Wouldn't 90% of them be lucky hashes?
@mmeijeri they are paying for voting up by giving up subsidy. See this writeup for details:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008017.html
OK I've reworked quite a bit of the text and reduced complexity, and saved some bytes in the coinbase field. I'm going to transfer this over to my bips fork and open a pull request.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using a decimal rather than a binary multiplication factor might lead to subtle rounding errors. It would be very unfortunate if that led to unintentional forks...