📅 Original date posted:2016-02-07
📝 Original message:On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> The stated reasoning for 75% versus 95% is "because it gives "veto power"
> to a single big solo miner or mining pool". But if a 20% miner wants to
> "veto" the upgrade, with a 75% threshold, they could instead simply use
> their hashpower to vote for an upgrade, but then not mine anything on
> the new chain. At that point there'd be as little as 55% mining the new
> 2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
> minute blocks versus 22 minute blocks, which doesn't seem like much of
> a difference in practice, and at that point hashpower could plausibly
> end up switching almost entirely back to the original consensus rules
> prior to the grace period ending.
Keep in mind that within a single difficulty adjustment period, the difficulty of mining a block on either chain will be identical. Even if the value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is 100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the first adjustment period) is to mine on the 2 MB branch, because the miner would earn 1% more on that branch.
So you're assuming that 25% of the hashrate chooses to remain on the minority version during the grace period, and that 20% chooses to switch back to the minority side. The fork happens. One branch has 1 MB blocks every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The first branch cannot handle the pre-fork transaction volume, as it only has 45% of the capacity that it had pre-fork. The second one can, as it has 111% of the pre-fork capacity. This makes the 1 MB branch much less usable than the 2 MB branch, which in turn causes the market value of newly minted coins on that branch to fall, which in turn causes miners to switch to the more profitable 2MB branch. This exacerbates the usability difference, which exacerbates the price difference, etc. Having two competing chains with equal hashrate using the same PoW function and nearly equal features is not a stable state. Positive feedback loops exist to make the vast majority of the users and the hashrate join one side.
Basically, any miners who stick to the minority branch are going to lose a lot of money.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/d2b9d665/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/d2b9d665/attachment-0001.sig>;
Jonathan Toomim [ARCHIVE] /
npub1pl…yj0hj
2023-06-07 17:48:44
in reply to nevent1q…9vst
Author Public Key
npub1pl6kcz00s7wgn6syh73dta0qm9sqpmtw4adv8rnm2w9fmynkw45sayj0hjPublished at
2023-06-07 17:48:44Event JSON
{
"id": "dc7c709721329aeca8a01f8f826ff07f08a90075ab10a2d8803dddec9d17732c",
"pubkey": "0ff56c09ef879c89ea04bfa2d5f5e0d96000ed6eaf5ac38e7b538a9d92767569",
"created_at": 1686160124,
"kind": 1,
"tags": [
[
"e",
"299dc342b2928a854d3cdebebdfa1b5d7d113553560926ba6670328be5b1c1ce",
"",
"root"
],
[
"e",
"b529378e94e0d1360df5db97fc3bc07cfa834f992a7e755245dea21bbb70a1e0",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2016-02-07\n📝 Original message:On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The stated reasoning for 75% versus 95% is \"because it gives \"veto power\"\n\u003e to a single big solo miner or mining pool\". But if a 20% miner wants to\n\u003e \"veto\" the upgrade, with a 75% threshold, they could instead simply use\n\u003e their hashpower to vote for an upgrade, but then not mine anything on\n\u003e the new chain. At that point there'd be as little as 55% mining the new\n\u003e 2MB chain with 45% of hashpower remaining on the old chain. That'd be 18\n\u003e minute blocks versus 22 minute blocks, which doesn't seem like much of\n\u003e a difference in practice, and at that point hashpower could plausibly\n\u003e end up switching almost entirely back to the original consensus rules\n\u003e prior to the grace period ending.\n\n\nKeep in mind that within a single difficulty adjustment period, the difficulty of mining a block on either chain will be identical. Even if the value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is 100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the first adjustment period) is to mine on the 2 MB branch, because the miner would earn 1% more on that branch.\n\nSo you're assuming that 25% of the hashrate chooses to remain on the minority version during the grace period, and that 20% chooses to switch back to the minority side. The fork happens. One branch has 1 MB blocks every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The first branch cannot handle the pre-fork transaction volume, as it only has 45% of the capacity that it had pre-fork. The second one can, as it has 111% of the pre-fork capacity. This makes the 1 MB branch much less usable than the 2 MB branch, which in turn causes the market value of newly minted coins on that branch to fall, which in turn causes miners to switch to the more profitable 2MB branch. This exacerbates the usability difference, which exacerbates the price difference, etc. Having two competing chains with equal hashrate using the same PoW function and nearly equal features is not a stable state. Positive feedback loops exist to make the vast majority of the users and the hashrate join one side.\n\nBasically, any miners who stick to the minority branch are going to lose a lot of money.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/d2b9d665/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/d2b9d665/attachment-0001.sig\u003e",
"sig": "c376573a236c486ff5383e9265920a24125356bf51e45262db06c1fb8f0ab2b6d68bd8c21b5a2546503e4ce5e6cb637b843ab1b5c4b5f3eb86c6a112230fba11"
}