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.
Regarding the 8MB cap, I only suggested it because Chinese miners seemed reluctant to go above it. However, it might make sense to place the limit at 32MB (or just under) because that is the limit of the p2p messaging system and anything bigger will require another hard fork there anyway.
Doesn't this suffer from a Tragedy of Commons scenario where even if there is a real need to increase blocksize, miners refuse to do it and hope someone else will do it?
@GamerSg When the blocksize must be increased miners are likely to communicate out of band to reach an agreement. We have already seen pools are willing to worth together and forge consensus. What is does ensure however is the blocksize will actually grow according to demand. Increasing blocksize is in the interest of miners to claim transaction fees.
@hoffmabc I removed the 8MB limit because there is a natural limit of 32MB anyhow. I am assuming miners are not going to raise blocksize to levels that hurt their interests.
can you explain why you'd make it 'free' to downvote?
The 32mb p2p message limit is something I've forgotten about of late! It's similar to having soft-forked the size downwards. We've had this before - having an artificial limit of 0.5mb, which was increased when miners changed the setting.
I had initially hoped that any hard fork would do away with this, and give us some means of arriving at the figure by consensus, so I'm glad to see the change from 8 to 32mb. It's one less hard-fork to worry about.
I'm now almost convinced there should be a cost to down-voting the size.
The argument against giving miners the ability to indefinitely raise the block size is it can lead to mining centralization. I believe a similar argument exists for lowering the size, since it increases fee pressure, centralizing the ability to participate in the network to fewer and fewer institutions.
I liken this to institutional centralization. Setting up a regulated fiat payment processing service involves licensing, legal fee's, ongoing costs that can make innovation prohibitive.
This isn't possible with a static size, as although a cartel can agree to use only 0.5Mb, any miner can break ranks and mine a 1Mb block. Consensus enforced limiting of the blocksize is a departure from this reality, so I think there should be a cost to a negative size vote - incurring the same cost as raising the limit by the same amount.
Wouldn't the median be a better yardstick than the average?
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...
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
Biggest issue is that 8MB cap. I think the numbers could be adjusted here, but probably one of the most compelling early pitches to come to consensus.