đź“… Original date posted:2017-03-25
📝 Original message:One of the purported benefits of a soft-forking change (a tightening of the consensus rule set) is the reduced risk of a blockchain split compared to a loosening of the consensus rule set. The way this works is that miners who fail to upgrade to the new tighter ruleset will have their non-compliant blocks orphaned by the hash power majority. This is a strong incentive to upgrade and has historically worked well. If a minority subset of the network didn’t want to abide by the new restricted rule set, a reasonable solution would be for them to change the proof-of-work and start a spin-off from the existing Bitcoin ledger (https://bitcointalk.org/index.php?topic=563972.0).
In the case of the coming network upgrade to larger blocks, a primary concern of both business such as Coinbase and Bitpay, and most miners, is the possibility of a blockchain split and the associated confusion, replay risk, etc. By applying techniques that are known to be successful for soft-forking changes, we can likewise benefit in a way that makes a split less likely as we move towards larger blocks. Two proposed techniques to reduce the chances of a split are:
1. That miners begin to orphan the blocks of non-upgraded miners once a super-majority of the network hash power has upgraded. This would serve as an expensive-to-ignore reminder to upgrade.
2. That, in the case where a minority branch emerges (unlikely IMO), majority miners would continually re-org that minority branch with empty blocks to prevent transactions from confirming, thereby eliminating replay risk.
Just like after a soft forking change, a minority that does not want to abide by the current ruleset enforced by the majority could change the proof-of-work and start a spin-off from the existing Bitcoin ledger, as suggested by Emin.
Best regards,
Peter R
> On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> I don't know what "Time is running short I fear" stands for and when 50%
>> is supposed to be reached
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
> "Time is running short I fear" stands for and when 50% > is supposed
> to be reached
>
> According to current hashrate distribution tracking site coin.dance,
> very likely within less than four weeks according to current hashrate
> takeover rate.
>
> While a fork is very likely, that I dont really fear because worst
> case scenario is that bitcoin still survives and the invalid chain
> becomes an alt. My fear is the centralized mining power being used
> to attack the valid chain with intentions on killing it. [1]
>
> Shouldn't this 50% attack they are threatening be a concern? If it
> is a concern, what options are on the table. If it is not a concern
> please enlightent me as to why.
>
>
> [1] Source:
> https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_to_force_a_hard_fork_by/
>
> Text:
>
> The attack quoted from his article:
> https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
>
> [Level 2] Anti-split protection  Miners will orphan the
> blocks of non-compliant miners prior to the first larger block
> to serve as a reminder to upgrade. Simply due to the possibility
> of having blocks orphaned, all miners would be motivated to
> begin signalling for larger blocks once support definitively
> passes 51%. If some miners hold out (e.g., they may not be
> paying attention regarding the upgrade), then they will begin
> to pay attention after losing approximately $15,000 of revenue
> due to an orphaned block.
>
> [Level 3] Anti-split protection  In the scenario where Levels
> 1 and 2 protection fails to entice all non-compliant miners to
> upgrade, a small-block minority chain may emerge. To address the
> risk of coins being spent on this chain (replay risk), majority
> miners will deploy hash power as needed to ensure the minority
> chain includes only empty blocks after the forking point. This
> can easily be accomplished if the majority miners maintain a
> secret chain of empty blocks  built off their last empty
> block  publishing only as much of this chain as necessary
> to orphan any non-empty blocks produced on the minority chain.
>
>
>
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon at cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
> eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
> h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
> gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
> VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
> TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
> j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
> NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
> YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
> ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
> 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
> /T93MuZgmvSCry5MlccA
> =R71g
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Peter R [ARCHIVE] /
npub1vx…lz2gn
2023-06-07 17:57:47
in reply to nevent1q…nchm
Author Public Key
npub1vxzlqg5f7ykqr3hheqxdcqe35q02a8rr2mez30sjaldhlvu4hsvsqlz2gnPublished at
2023-06-07 17:57:47Event JSON
{
"id": "6d075f3adf85b55b57de6d418d3927c442fe151fc34312efe98e7f4e57cc83ed",
"pubkey": "6185f02289f12c01c6f7c80cdc0331a01eae9c6356f228be12efdb7fb395bc19",
"created_at": 1686160667,
"kind": 1,
"tags": [
[
"e",
"8f27b0f2ce427ef28fdd158930556a4af440f4d5d3a81eefc4fcbd02c81912c0",
"",
"root"
],
[
"e",
"2c9fd649866296c9a1a3ea0e49b3152db6214916f709dbaffc6ec6c96f8f4830",
"",
"reply"
],
[
"p",
"ad1d8f6d807066d10d62301530404bbcc05c02b6c04de9bbf53f00b2244e7cf7"
]
],
"content": "📅 Original date posted:2017-03-25\n📝 Original message:One of the purported benefits of a soft-forking change (a tightening of the consensus rule set) is the reduced risk of a blockchain split compared to a loosening of the consensus rule set. The way this works is that miners who fail to upgrade to the new tighter ruleset will have their non-compliant blocks orphaned by the hash power majority. This is a strong incentive to upgrade and has historically worked well. If a minority subset of the network didn’t want to abide by the new restricted rule set, a reasonable solution would be for them to change the proof-of-work and start a spin-off from the existing Bitcoin ledger (https://bitcointalk.org/index.php?topic=563972.0).\n\nIn the case of the coming network upgrade to larger blocks, a primary concern of both business such as Coinbase and Bitpay, and most miners, is the possibility of a blockchain split and the associated confusion, replay risk, etc. By applying techniques that are known to be successful for soft-forking changes, we can likewise benefit in a way that makes a split less likely as we move towards larger blocks. Two proposed techniques to reduce the chances of a split are:\n\n1. That miners begin to orphan the blocks of non-upgraded miners once a super-majority of the network hash power has upgraded. This would serve as an expensive-to-ignore reminder to upgrade.\n\n2. That, in the case where a minority branch emerges (unlikely IMO), majority miners would continually re-org that minority branch with empty blocks to prevent transactions from confirming, thereby eliminating replay risk.\n\nJust like after a soft forking change, a minority that does not want to abide by the current ruleset enforced by the majority could change the proof-of-work and start a spin-off from the existing Bitcoin ledger, as suggested by Emin. \n\nBest regards,\nPeter R\n\n\n\u003e On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e On 03/24/2017 07:00 PM, Aymeric Vitte wrote:\n\u003e\u003e I don't know what \"Time is running short I fear\" stands for and when 50%\n\u003e\u003e is supposed to be reached\n\u003e \n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA512\n\u003e \n\u003e On 03/24/2017 07:00 PM, Aymeric Vitte wrote: \u003e I don't know what\n\u003e \"Time is running short I fear\" stands for and when 50% \u003e is supposed\n\u003e to be reached\n\u003e \n\u003e According to current hashrate distribution tracking site coin.dance,\n\u003e very likely within less than four weeks according to current hashrate\n\u003e takeover rate.\n\u003e \n\u003e While a fork is very likely, that I dont really fear because worst\n\u003e case scenario is that bitcoin still survives and the invalid chain\n\u003e becomes an alt. My fear is the centralized mining power being used\n\u003e to attack the valid chain with intentions on killing it. [1]\n\u003e \n\u003e Shouldn't this 50% attack they are threatening be a concern? If it\n\u003e is a concern, what options are on the table. If it is not a concern\n\u003e please enlightent me as to why.\n\u003e \n\u003e \n\u003e [1] Source:\n\u003e https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_to_force_a_hard_fork_by/\n\u003e \n\u003e Text:\n\u003e \n\u003e The attack quoted from his article:\n\u003e https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8\n\u003e \n\u003e [Level 2] Anti-split protection  Miners will orphan the\n\u003e blocks of non-compliant miners prior to the first larger block\n\u003e to serve as a reminder to upgrade. Simply due to the possibility\n\u003e of having blocks orphaned, all miners would be motivated to\n\u003e begin signalling for larger blocks once support definitively\n\u003e passes 51%. If some miners hold out (e.g., they may not be\n\u003e paying attention regarding the upgrade), then they will begin\n\u003e to pay attention after losing approximately $15,000 of revenue\n\u003e due to an orphaned block.\n\u003e \n\u003e [Level 3] Anti-split protection  In the scenario where Levels\n\u003e 1 and 2 protection fails to entice all non-compliant miners to\n\u003e upgrade, a small-block minority chain may emerge. To address the\n\u003e risk of coins being spent on this chain (replay risk), majority\n\u003e miners will deploy hash power as needed to ensure the minority\n\u003e chain includes only empty blocks after the forking point. This\n\u003e can easily be accomplished if the majority miners maintain a\n\u003e secret chain of empty blocks  built off their last empty\n\u003e block  publishing only as much of this chain as necessary\n\u003e to orphan any non-empty blocks produced on the minority chain.\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e - --\n\u003e Cannon\n\u003e PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832 \n\u003e Email: cannon at cannon-ciota.info\n\u003e \n\u003e NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD \n\u003e BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE. \n\u003e If this matters to you, use PGP.\n\u003e -----BEGIN PGP SIGNATURE-----\n\u003e \n\u003e iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM\n\u003e eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH\n\u003e h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu\n\u003e gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK\n\u003e VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B\n\u003e TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj\n\u003e j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw\n\u003e NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u\n\u003e YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN\n\u003e ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa\n\u003e 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S\n\u003e /T93MuZgmvSCry5MlccA\n\u003e =R71g\n\u003e -----END PGP SIGNATURE-----\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "b6a990563bebde52710674c53eb238387d6a36c728dd6274d2bdc8bddc8e555b71b516e4a20f4e38ff8355a756e6b429a5981bff8be3131175bbf58829325d86"
}