Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B766941C for ; Sun, 26 Mar 2017 19:05:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27FCF2A5 for ; Sun, 26 Mar 2017 19:05:47 +0000 (UTC) Received: from [192.168.50.29] ([24.86.172.170]) by mail.gmx.com (mrgmx003 [212.227.17.184]) with ESMTPSA (Nemesis) id 0MYg42-1cfeit422E-00VQBc; Sun, 26 Mar 2017 21:05:42 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE" From: Peter R In-Reply-To: Date: Sun, 26 Mar 2017 12:05:38 -0700 Message-Id: <9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com> References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info> <35ba77db-f95a-4517-c960-8ad42a633ba0@gmail.com> <9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com> To: Alex Morcos X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:q+1Zl1/R+ZBgXnGHxaheqex3lZpNK0iOhVBHwrGSR+onT/85j9u VDloCl5QWmFE2sryN9DPLKgZJwf70HHijKn5eulXmx+vJrhtBC2cA/Z9vEBE2J38W8iGR4n FmICsO3GsSEhGuG7Ck99w+v3EwvWoT2wRiCwp7hA22KtwCVdFend8bZ0NklUtvGzPtvcxga FjqPTZLXlhv6CpZUeefqw== X-UI-Out-Filterresults: notjunk:1;V01:K0:/SIuuA1SBh8=:B0+YJ/OdO+AcfEyFqf1Udw qC6WBYWFbF0mMn0L5Nuk3L/wCKM4iEc3dByPAbM1Z/cgYoZy+7Dj0IkNfOOic5iKAVfzJXt0q nCmKRy94sPpMZ9W0ZreCqC1zxHsiVYh3gjCek0ARZpvFrmqi3+W7rgEqLHgcznUsZ/m+cUnN5 SA92232U2rHkT+T4BQh1rTQo3BxsRDLSxfOG1pX4HwI0a/yd+k6bqWZ70FxwwHXCHWE4YQSgM gZ9kGOR3jgQOo88wjFNT4nASFNOJ9kcliyjvhOEzhgWi6wa/2t33Z6LI1Wq8iieGIct+cjHfJ 9HUhuVQTigo5fbfBzi+liXqlasd+WS6+M1yARDvMCMocVmJhuj2zwmiCRL47Zh4EoLxxL+uW/ 0QSMDJZQfSG4mcgD4kAzIjHLaSY6OPCckGUkuY0toXUvIFMWGXRjGqlkxqfv8na8x5TIOpAPe m3q0w0KIP0/JbYa0wGYfIcrx6VsAVghrebagL+leLTewFWAZzLqFinq689Vt1BVGFfQaupx9X G1IStQaczQz86tWGnf0r6aifI1ItYFyGaJWBpdILORX3yWYpER5EbaGTHSWmoFP8ttqvC1zjs rDswrDyT0YiMpXU16a3hJi+pheQmG0gWEsXGZdmCqIGMp3B4zD49Rcy+cVLndb72ptSmaZ2BV oHz4sXrzoHKBTfDTtsK1KQTGVlFcH/LmVrE7lC7jT7HBLE7jTe4gTVJd6VXtp/DtFtY/EJHBo 4LsH+DWe1GGO4gyYfISgvOcXHH7/5Var5d4KXeRkV58xtCMQXIIo0WABY7HWJWzmCnMEl0GYB iznU6ek X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,LOTS_OF_MONEY,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW, T_MONEY_PERCENT autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 26 Mar 2017 20:16:00 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 19:05:50 -0000 --Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Alex, Thank you for the thoughtful reply. =20 > Surely you are aware that what you are proposing is vastly different = from the way soft forks have historically worked.=20 Yes, it is different. It=E2=80=99s 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=E2=80=94this is not my proposal, I am describing what I have = recently learned through my work with Bitcoin Unlimited and discussions = with miners and businesses). =20 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. =20 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=E2=80=99m 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. =20 > 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 =E2=80=9Cblock-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=E2=80=99re interested, here = is my talk at Coinbase where I discuss this: = https://www.youtube.com/watch?v=3DpWnFDocAmfg = ) > 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=E2=80=99t want the block size limit to = increase. Indeed, I have met people who worry that Bitcoin Unlimited is = =E2=80=9Ctrying to take over=E2=80=9D=E2=80=94and thus they are worried = for other reasons=E2=80=94but this couldn=E2=80=99t 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. =20 This is not a fight about =E2=80=9CCore vs. BU=E2=80=9D; Bitcoin=E2=80=99s= future is one of =E2=80=9Cgenetic diversity=E2=80=9D with multiple = implementations, so that a bug in one doesn=E2=80=99t 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=E2=80=99t believe users should have = this power (outside of recompiling from source, which few users can do). = =20 > 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=E2=80=99t 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 =E2=80=9Cethics=E2=80=9D 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=E2=80=99d rather split than accept blocks with more than = 1,000,000 bytes of transaction information in them? Sorry if I = misunderstood). =20 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. =20 Best regards, Peter R >=20 > On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev = > 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=E2=80=99t 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=3D563972.0 = ). >=20 > 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: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Best regards, > Peter R >=20 >=20 > > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev = > 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-b= lock-size-limit-insights-from-my-visit-with-2348878a16d8 = > > > > [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners 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=E2=80=8A=E2=80=8AIn 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=E2=80=8A=E2=80=8Abuilt off their = last empty > > block=E2=80=8A=E2=80=8Apublishing 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@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 > > =3DR71g > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org = > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >=20 --Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99s 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=E2=80=94this 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=E2=80=99= 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 =E2=80=9Cblock-size-lim= it gene" of network nodes is simply evolving to allow the network to = continue to grow in the way it has always grown. (If you=E2=80=99re = interested, here is my talk at Coinbase where I discuss this: https://www.youtube.com/watch?v=3DpWnFDocAmfg)

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=E2=80=99t want = the block size limit to increase.  Indeed, I have met people who = worry that Bitcoin Unlimited is =E2=80=9Ctrying to take over=E2=80=9D=E2=80= =94and thus they are worried for other reasons=E2=80=94but this = couldn=E2=80=99t 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 =E2=80=9CCore vs. BU=E2=80= =9D; Bitcoin=E2=80=99s future is one of =E2=80=9Cgenetic diversity=E2=80=9D= with multiple implementations, so that a bug in one doesn=E2=80=99t = 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=E2=80=99t 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=E2=80=99t 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 =E2=80=9Cethics=E2=80=9D 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=E2=80=99d 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@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=E2=80=99t 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=3D563972.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@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=E2=80=8A=E2=80=8AMiners = 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=E2=80=8A=E2=80=8AIn = 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=E2=80=8A=E2=80=8Abuilt = off their last empty
>    block=E2=80=8A=E2=80=8Apublishing 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@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
> =3DR71g
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


= --Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE--