đź“… Original date posted:2017-03-26
đź“ť Original message:As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem. Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
Please do not put words in people's mouths claiming they wouldn't prefer a
split when many would. If you wish to fork off, please do so responsibly.
-Alphonse
On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Alex,
>
> Thank you for the thoughtful reply.
>
> Surely you are aware that what you are proposing is vastly different from
> the way soft forks have historically worked.
>
>
> Yes, it is different. It’s different because the future network upgrade
> to larger blocks includes a loosening of the consensus ruleset whereas
> previous upgrades have included a tightening of the rule set. (BTW—this is
> not my proposal, I am describing what I have recently learned through my
> work with Bitcoin Unlimited and discussions with miners and businesses).
>
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
> With a loosening of the consensus rule set, the situation is different: a
> hash power minority that has not upgraded will produce a minority branch,
> that will also drag along non-upgraded node operators, leading to potential
> confusion. The idea behind orphaning the blocks of non-upgraded miners was
> to serve as a wake-up call to upgrade, to reduce the chances of a minority
> chain emerging in the first place, similar to what happens automatically
> with a soft-forking change. If one's worry is a chain split, then this
> seems like a reasonable way to reduce the chances of that worry
> materializing. The Level 3 anti-split protection takes this idea one step
> further to ensure that if a minority branch does emerge, that transactions
> cannot be confirmed on that branch.
>
> First of all, the bar for miners being on the new chain is extremely high,
> 95%.
>
>
> I’m very confident that most people do NOT want a split, especially the
> miners. The upgrade to larger blocks will not happen until miners are
> confident that no minority chain will survive.
>
> Second of all, soft forks make rule restrictions on classes of
> transactions that are already non-standard so that any non-upgraded miners
> are unlikely to be including txs in their blocks which would violate the
> new rules and should not have their blocks orphaned even after the fork.
>
>
> I agree that the soft-fork mechanism usually works well. I believe this
> mechanism (or perhaps a modified version of it) to increase the block size
> limit will likewise work well. All transactions types that are currently
> valid will be valid after the upgrade, and no new types of transactions are
> being created. The “block-size-limit gene" of network nodes is simply
> evolving to allow the network to continue to grow in the way it has always
> grown. (If you’re interested, here is my talk at Coinbase where I discuss
> this: https://www.youtube.com/watch?v=pWnFDocAmfg)
>
> Finally, soft forks are designed to only be used when there is a very wide
> community consensus and the intention is not to overrule anyone's choice to
> remain on the old rules but to ensure the security of nodes that may have
> neglected to upgrade. Obviously it is impossible to draw a bright line
> between users who intentionally are not upgrading due to opposition and
> users that are just being lazy. But in the case of a proposed BU hard fork
> it is abundantly clear that there is a very significant fraction, in fact
> likely a majority of users who intentionally want to remain on the old
> rules.
>
>
> My read is completely different. I still have never talked with a person
> in real life who doesn’t want the block size limit to increase. Indeed, I
> have met people who worry that Bitcoin Unlimited is “trying to take
> over”—and thus they are worried for other reasons—but this couldn’t be
> further from the truth. For example, what most people within BU would love
> to see is a simple patch to Bitcoin Core 0.14 that allows node operators to
> adjust the size of blocks their nodes will accept, so that these node
> operators can follow consensus through the upgrade if they choose to.
>
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one of
> “genetic diversity” with multiple implementations, so that a bug in one
> doesn’t threaten the network as a whole. To me it seems this is largely a
> fight about whether node operators should be easily able to adjust the size
> of blocks their nodes accept. BU makes it easy for node operators to
> accept larger blocks; Core doesn’t believe users should have this power
> (outside of recompiling from source, which few users can do).
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> Once again, this is not my proposal. I am writing about what I have come
> to learn over the past several weeks. When I first heard about these
> ideas, I was initially against them too. They seemed harsh and merciless.
> It wasn’t until I got out their and started talking to more people in the
> community that the rationale started to make sense to me: the biggest
> concern people had was a chain split!
>
> So I guess the “ethics” here depend on the lens through which one is
> looking. People who believe that an important outcome of the upgrade to
> larger blocks is to avoid a blockchain split may be more favourable to
> these ideas than people who want the upgrade to result in a split (or are
> OK with a split), as it sounds like you do (is this true that you’d rather
> split than accept blocks with more than 1,000,000 bytes of transaction
> information in them? Sorry if I misunderstood).
>
> But if one's intention is to split and not follow the majority hash power
> when blocks become larger, then why not change the proof-of-work? This
> would certainly result in a peaceful splitting, as you said you desire.
>
> Best regards,
> Peter R
>
>
>
>
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> 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-regard
>> ing-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
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/88bf8628/attachment-0001.html>;
Alphonse Pace [ARCHIVE] /
npub1xd…lkyw0
2023-06-07 17:57:50
in reply to nevent1q…mpnx
Author Public Key
npub1xddusuj8cyeqaqalq0zklafvdgr26pt32t0tvquw5mmwwwm3dehsqlkyw0Published at
2023-06-07 17:57:50Event JSON
{
"id": "062ebeb1b444e8147b0fab4674349c7f7d2c3970967f0f607a7b06d477b4dcc9",
"pubkey": "335bc87247c1320e83bf03c56ff52c6a06ad057152deb6038ea6f6e73b716e6f",
"created_at": 1686160670,
"kind": 1,
"tags": [
[
"e",
"8f27b0f2ce427ef28fdd158930556a4af440f4d5d3a81eefc4fcbd02c81912c0",
"",
"root"
],
[
"e",
"df33901a0ec98647c2da59acb742a005b9dde8acada93205bcef7810189737f6",
"",
"reply"
],
[
"p",
"6185f02289f12c01c6f7c80cdc0331a01eae9c6356f228be12efdb7fb395bc19"
]
],
"content": "📅 Original date posted:2017-03-26\n📝 Original message:As a user, I would far prefer a split over any kind of mandatory change\nthat would drastically harm the ecosystem. Many users feel the same way.\nLevel 3 is a pure attack on users who do not conform to your beliefs.\nPlease do not put words in people's mouths claiming they wouldn't prefer a\nsplit when many would. If you wish to fork off, please do so responsibly.\n\n-Alphonse\n\nOn Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hello Alex,\n\u003e\n\u003e Thank you for the thoughtful reply.\n\u003e\n\u003e Surely you are aware that what you are proposing is vastly different from\n\u003e the way soft forks have historically worked.\n\u003e\n\u003e\n\u003e Yes, it is different. It’s different because the future network upgrade\n\u003e to larger blocks includes a loosening of the consensus ruleset whereas\n\u003e previous upgrades have included a tightening of the rule set. (BTW—this is\n\u003e not my proposal, I am describing what I have recently learned through my\n\u003e work with Bitcoin Unlimited and discussions with miners and businesses).\n\u003e\n\u003e With a tightening of the rule set, a hash power minority that has not\n\u003e upgraded will not produce a minority branch; instead they will simply have\n\u003e any invalid blocks they produce orphaned, serving as a wake-up call to\n\u003e upgrade.\n\u003e\n\u003e With a loosening of the consensus rule set, the situation is different: a\n\u003e hash power minority that has not upgraded will produce a minority branch,\n\u003e that will also drag along non-upgraded node operators, leading to potential\n\u003e confusion. The idea behind orphaning the blocks of non-upgraded miners was\n\u003e to serve as a wake-up call to upgrade, to reduce the chances of a minority\n\u003e chain emerging in the first place, similar to what happens automatically\n\u003e with a soft-forking change. If one's worry is a chain split, then this\n\u003e seems like a reasonable way to reduce the chances of that worry\n\u003e materializing. The Level 3 anti-split protection takes this idea one step\n\u003e further to ensure that if a minority branch does emerge, that transactions\n\u003e cannot be confirmed on that branch.\n\u003e\n\u003e First of all, the bar for miners being on the new chain is extremely high,\n\u003e 95%.\n\u003e\n\u003e\n\u003e I’m very confident that most people do NOT want a split, especially the\n\u003e miners. The upgrade to larger blocks will not happen until miners are\n\u003e confident that no minority chain will survive.\n\u003e\n\u003e Second of all, soft forks make rule restrictions on classes of\n\u003e transactions that are already non-standard so that any non-upgraded miners\n\u003e are unlikely to be including txs in their blocks which would violate the\n\u003e new rules and should not have their blocks orphaned even after the fork.\n\u003e\n\u003e\n\u003e I agree that the soft-fork mechanism usually works well. I believe this\n\u003e mechanism (or perhaps a modified version of it) to increase the block size\n\u003e limit will likewise work well. All transactions types that are currently\n\u003e valid will be valid after the upgrade, and no new types of transactions are\n\u003e being created. The “block-size-limit gene\" of network nodes is simply\n\u003e evolving to allow the network to continue to grow in the way it has always\n\u003e grown. (If you’re interested, here is my talk at Coinbase where I discuss\n\u003e this: https://www.youtube.com/watch?v=pWnFDocAmfg)\n\u003e\n\u003e Finally, soft forks are designed to only be used when there is a very wide\n\u003e community consensus and the intention is not to overrule anyone's choice to\n\u003e remain on the old rules but to ensure the security of nodes that may have\n\u003e neglected to upgrade. Obviously it is impossible to draw a bright line\n\u003e between users who intentionally are not upgrading due to opposition and\n\u003e users that are just being lazy. But in the case of a proposed BU hard fork\n\u003e it is abundantly clear that there is a very significant fraction, in fact\n\u003e likely a majority of users who intentionally want to remain on the old\n\u003e rules.\n\u003e\n\u003e\n\u003e My read is completely different. I still have never talked with a person\n\u003e in real life who doesn’t want the block size limit to increase. Indeed, I\n\u003e have met people who worry that Bitcoin Unlimited is “trying to take\n\u003e over”—and thus they are worried for other reasons—but this couldn’t be\n\u003e further from the truth. For example, what most people within BU would love\n\u003e to see is a simple patch to Bitcoin Core 0.14 that allows node operators to\n\u003e adjust the size of blocks their nodes will accept, so that these node\n\u003e operators can follow consensus through the upgrade if they choose to.\n\u003e\n\u003e This is not a fight about “Core vs. BU”; Bitcoin’s future is one of\n\u003e “genetic diversity” with multiple implementations, so that a bug in one\n\u003e doesn’t threaten the network as a whole. To me it seems this is largely a\n\u003e fight about whether node operators should be easily able to adjust the size\n\u003e of blocks their nodes accept. BU makes it easy for node operators to\n\u003e accept larger blocks; Core doesn’t believe users should have this power\n\u003e (outside of recompiling from source, which few users can do).\n\u003e\n\u003e As a Bitcoin user I find it abhorrent the way you are proposing to\n\u003e intentionally cripple the chain and rules I want to use instead of just\n\u003e peacefully splitting.\n\u003e\n\u003e\n\u003e Once again, this is not my proposal. I am writing about what I have come\n\u003e to learn over the past several weeks. When I first heard about these\n\u003e ideas, I was initially against them too. They seemed harsh and merciless.\n\u003e It wasn’t until I got out their and started talking to more people in the\n\u003e community that the rationale started to make sense to me: the biggest\n\u003e concern people had was a chain split!\n\u003e\n\u003e So I guess the “ethics” here depend on the lens through which one is\n\u003e looking. People who believe that an important outcome of the upgrade to\n\u003e larger blocks is to avoid a blockchain split may be more favourable to\n\u003e these ideas than people who want the upgrade to result in a split (or are\n\u003e OK with a split), as it sounds like you do (is this true that you’d rather\n\u003e split than accept blocks with more than 1,000,000 bytes of transaction\n\u003e information in them? Sorry if I misunderstood).\n\u003e\n\u003e But if one's intention is to split and not follow the majority hash power\n\u003e when blocks become larger, then why not change the proof-of-work? This\n\u003e would certainly result in a peaceful splitting, as you said you desire.\n\u003e\n\u003e Best regards,\n\u003e Peter R\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e One of the purported benefits of a soft-forking change (a tightening of\n\u003e\u003e the consensus rule set) is the reduced risk of a blockchain split compared\n\u003e\u003e to a loosening of the consensus rule set. The way this works is that\n\u003e\u003e miners who fail to upgrade to the new tighter ruleset will have their\n\u003e\u003e non-compliant blocks orphaned by the hash power majority. This is a strong\n\u003e\u003e incentive to upgrade and has historically worked well. If a minority\n\u003e\u003e subset of the network didn’t want to abide by the new restricted rule set,\n\u003e\u003e a reasonable solution would be for them to change the proof-of-work and\n\u003e\u003e start a spin-off from the existing Bitcoin ledger (\n\u003e\u003e https://bitcointalk.org/index.php?topic=563972.0).\n\u003e\u003e\n\u003e\u003e In the case of the coming network upgrade to larger blocks, a primary\n\u003e\u003e concern of both business such as Coinbase and Bitpay, and most miners, is\n\u003e\u003e the possibility of a blockchain split and the associated confusion, replay\n\u003e\u003e risk, etc. By applying techniques that are known to be successful for\n\u003e\u003e soft-forking changes, we can likewise benefit in a way that makes a split\n\u003e\u003e less likely as we move towards larger blocks. Two proposed techniques to\n\u003e\u003e reduce the chances of a split are:\n\u003e\u003e\n\u003e\u003e 1. That miners begin to orphan the blocks of non-upgraded miners once a\n\u003e\u003e super-majority of the network hash power has upgraded. This would serve as\n\u003e\u003e an expensive-to-ignore reminder to upgrade.\n\u003e\u003e\n\u003e\u003e 2. That, in the case where a minority branch emerges (unlikely IMO),\n\u003e\u003e majority miners would continually re-org that minority branch with empty\n\u003e\u003e blocks to prevent transactions from confirming, thereby eliminating replay\n\u003e\u003e risk.\n\u003e\u003e\n\u003e\u003e Just like after a soft forking change, a minority that does not want to\n\u003e\u003e abide by the current ruleset enforced by the majority could change the\n\u003e\u003e proof-of-work and start a spin-off from the existing Bitcoin ledger, as\n\u003e\u003e suggested by Emin.\n\u003e\u003e\n\u003e\u003e Best regards,\n\u003e\u003e Peter R\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e \u003e On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e On 03/24/2017 07:00 PM, Aymeric Vitte wrote:\n\u003e\u003e \u003e\u003e I don't know what \"Time is running short I fear\" stands for and when\n\u003e\u003e 50%\n\u003e\u003e \u003e\u003e is supposed to be reached\n\u003e\u003e \u003e\n\u003e\u003e \u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e\u003e \u003e Hash: SHA512\n\u003e\u003e \u003e\n\u003e\u003e \u003e On 03/24/2017 07:00 PM, Aymeric Vitte wrote: \u003e I don't know what\n\u003e\u003e \u003e \"Time is running short I fear\" stands for and when 50% \u003e is supposed\n\u003e\u003e \u003e to be reached\n\u003e\u003e \u003e\n\u003e\u003e \u003e According to current hashrate distribution tracking site coin.dance,\n\u003e\u003e \u003e very likely within less than four weeks according to current hashrate\n\u003e\u003e \u003e takeover rate.\n\u003e\u003e \u003e\n\u003e\u003e \u003e While a fork is very likely, that I dont really fear because worst\n\u003e\u003e \u003e case scenario is that bitcoin still survives and the invalid chain\n\u003e\u003e \u003e becomes an alt. My fear is the centralized mining power being used\n\u003e\u003e \u003e to attack the valid chain with intentions on killing it. [1]\n\u003e\u003e \u003e\n\u003e\u003e \u003e Shouldn't this 50% attack they are threatening be a concern? If it\n\u003e\u003e \u003e is a concern, what options are on the table. If it is not a concern\n\u003e\u003e \u003e please enlightent me as to why.\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e [1] Source:\n\u003e\u003e \u003e https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun\n\u003e\u003e _tells_miners_to_force_a_hard_fork_by/\n\u003e\u003e \u003e\n\u003e\u003e \u003e Text:\n\u003e\u003e \u003e\n\u003e\u003e \u003e The attack quoted from his article:\n\u003e\u003e \u003e https://medium.com/@peter_r/on-the-emerging-consensus-regard\n\u003e\u003e ing-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8\n\u003e\u003e \u003e\n\u003e\u003e \u003e [Level 2] Anti-split protection Miners will orphan the\n\u003e\u003e \u003e blocks of non-compliant miners prior to the first larger block\n\u003e\u003e \u003e to serve as a reminder to upgrade. Simply due to the possibility\n\u003e\u003e \u003e of having blocks orphaned, all miners would be motivated to\n\u003e\u003e \u003e begin signalling for larger blocks once support definitively\n\u003e\u003e \u003e passes 51%. If some miners hold out (e.g., they may not be\n\u003e\u003e \u003e paying attention regarding the upgrade), then they will begin\n\u003e\u003e \u003e to pay attention after losing approximately $15,000 of revenue\n\u003e\u003e \u003e due to an orphaned block.\n\u003e\u003e \u003e\n\u003e\u003e \u003e [Level 3] Anti-split protection In the scenario where Levels\n\u003e\u003e \u003e 1 and 2 protection fails to entice all non-compliant miners to\n\u003e\u003e \u003e upgrade, a small-block minority chain may emerge. To address the\n\u003e\u003e \u003e risk of coins being spent on this chain (replay risk), majority\n\u003e\u003e \u003e miners will deploy hash power as needed to ensure the minority\n\u003e\u003e \u003e chain includes only empty blocks after the forking point. This\n\u003e\u003e \u003e can easily be accomplished if the majority miners maintain a\n\u003e\u003e \u003e secret chain of empty blocks built off their last empty\n\u003e\u003e \u003e block publishing only as much of this chain as necessary\n\u003e\u003e \u003e to orphan any non-empty blocks produced on the minority chain.\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e - --\n\u003e\u003e \u003e Cannon\n\u003e\u003e \u003e PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832\n\u003e\u003e \u003e Email: cannon at cannon-ciota.info\n\u003e\u003e \u003e\n\u003e\u003e \u003e NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD\n\u003e\u003e \u003e BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.\n\u003e\u003e \u003e If this matters to you, use PGP.\n\u003e\u003e \u003e -----BEGIN PGP SIGNATURE-----\n\u003e\u003e \u003e\n\u003e\u003e \u003e iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM\n\u003e\u003e \u003e eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH\n\u003e\u003e \u003e h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu\n\u003e\u003e \u003e gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK\n\u003e\u003e \u003e VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B\n\u003e\u003e \u003e TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj\n\u003e\u003e \u003e j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw\n\u003e\u003e \u003e NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u\n\u003e\u003e \u003e YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN\n\u003e\u003e \u003e ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa\n\u003e\u003e \u003e 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S\n\u003e\u003e \u003e /T93MuZgmvSCry5MlccA\n\u003e\u003e \u003e =R71g\n\u003e\u003e \u003e -----END PGP SIGNATURE-----\n\u003e\u003e \u003e\n\u003e\u003e \u003e _______________________________________________\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\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\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170326/88bf8628/attachment-0001.html\u003e",
"sig": "4fe7eae12912073ea72f79e26d84a0be307ab7a9e203e9dc048a522e074d0a1de7c5c22db3f19abb4ac4790bfe4627368270e3b686247ff7d3ae925f05c47dbd"
}