From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 618AA727 for ; Sun, 26 Mar 2017 20:20:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com [74.125.83.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7EABE223 for ; Sun, 26 Mar 2017 20:20:57 +0000 (UTC) Received: by mail-pg0-f48.google.com with SMTP id 81so5228116pgh.2 for ; Sun, 26 Mar 2017 13:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=87RlBhOajZ2WxfZnUI75Z4/ggLmrOGLWfGpVKIhqONI=; b=oFUHlsjv+AQSuozDenF5O+Z+iES+7gDSxZnEb0j2vB/Nbj1fWJyAZZ4TH9cG9jtr4K cDlq9/V/VMhlmIeeLeYb3cMguZbOGCOeGQCgE+/lXJCGASzXg/xi7dmTo8onz596eVU2 kf3fV0xMbsvwKUwJQ4MeuFkIL5FjOXbmtsk+BwMbuOjnekCAnqHnB0QytSiqNMd7Ggs8 0sQAQgTfzYtzeCYGOq+NHMQrTrFCRlGhdyHAmwftN+0Oeu8epGpPrjfx2PbC098LDTz8 JA4lXcGtoB0f0uB37z6O5+xDKEzy77Lomb5/FotcKHi1VRX0Rdoz/ROighhkDnFtdjsk zfLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=87RlBhOajZ2WxfZnUI75Z4/ggLmrOGLWfGpVKIhqONI=; b=cOwMoHBrtQ8vdBqkrOzZSjN+PAoqUKxPL+o4rkIRNAzYO8MKfD0WZbkRuTidKwZl0r Ttd8M/GDP8PmcakMQh9osfjta5rdt1T3pcKL5wM+121jqgxtxxJ5dZ8FOHGKUNfKp65s Uxeh1INUByT+nVcBT7YULkg7kVhUH8wlAmsFzVcVwkhopuKgSuxrV19nYjC2Ex6nn6AY 987bCIgSNa8RPHhjZ7DId5KvpyYTCXgb2c18S8X8ae5WdEeSV/6C3QY6w8amgsdikD8Z FpPx5XchUaY4F9eGWJqYeELEHUMqCKxLb4Sw9KC7DE+DJIu1Jk6/b83sBASXVzsO/I5v vc6A== X-Gm-Message-State: AFeK/H1JFX8IlZVl6Y+Zr9WuuqQxSA2JB/9iTsSDr8egiYWUB1qD4MlRJkF1JnG71NNe53zD1nnVHZGnJBnMag== X-Received: by 10.99.61.194 with SMTP id k185mr20433376pga.154.1490559657008; Sun, 26 Mar 2017 13:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.128.19 with HTTP; Sun, 26 Mar 2017 13:20:56 -0700 (PDT) In-Reply-To: <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> <9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com> From: Alphonse Pace Date: Sun, 26 Mar 2017 15:20:56 -0500 Message-ID: To: Peter R , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c0d9348df67a8054ba7f634 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, HTML_OBFUSCATE_05_10, LOTS_OF_MONEY, RCVD_IN_DNSWL_NONE, 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 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 20:20:59 -0000 --94eb2c0d9348df67a8054ba7f634 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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@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=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 hav= e > 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 potenti= al > confusion. The idea behind orphaning the blocks of non-upgraded miners w= as > to serve as a wake-up call to upgrade, to reduce the chances of a minorit= y > 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 ste= p > further to ensure that if a minority branch does emerge, that transaction= s > 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, especial= ly 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 miner= s > 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 siz= e > limit will likewise work well. All transactions types that are currently > valid will be valid after the upgrade, and no new types of transactions a= re > being created. The =E2=80=9Cblock-size-limit gene" of network nodes is s= imply > evolving to allow the network to continue to grow in the way it has alway= s > 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 wid= e > 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 fo= rk > 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 ta= ke > 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 lo= ve > 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=99= s future is one of > =E2=80=9Cgenetic diversity=E2=80=9D with multiple implementations, so tha= t 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 si= ze > 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 peopl= e 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 w= hich 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 compar= ed >> 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 str= ong >> 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, i= s >> the possibility of a blockchain split and the associated confusion, repl= ay >> 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 spli= t >> less likely as we move towards larger blocks. Two proposed techniques t= o >> 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 repl= ay >> 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-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@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 >> > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c0d9348df67a8054ba7f634 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a user, I would far prefer a split over any kind of man= datory change that would drastically harm the ecosystem.=C2=A0 Many users f= eel the same way.=C2=A0 Level 3 is a pure attack on users who do not confor= m to your beliefs.=C2=A0 Please do not put words in people's mouths cla= iming they wouldn't prefer a split when many would.=C2=A0 If you wish t= o fork off, please do so responsibly.

-Alphonse

On Sun, Mar 26= , 2017 at 2:05 PM, Peter R via bitcoin-dev <bitcoin-de= v@lists.linuxfoundation.org> wrote:
Hello Alex,

Thank you for the thoughtful reply. =C2=A0

Surely you are aware = that what you are proposing is vastly different from the way soft forks hav= e historically worked.=C2=A0

=
Yes, it is different.=C2=A0 It=E2=80=99s different because the future = network upgrade to larger blocks includes a loosening of the consensus rule= set whereas previous upgrades have included a tightening of the rule set. = =C2=A0(BTW=E2=80=94this is not my proposal, I am describing what I have rec= ently learned through my work with Bitcoin Unlimited and discussions with m= iners and businesses). =C2=A0

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 p= roduce orphaned, serving as a wake-up call to upgrade. =C2=A0
With a loosening of the consensus rule set, the situation is di= fferent: a hash power minority that has not upgraded will produce a minorit= y branch, that will also drag along non-upgraded node operators, leading to= potential confusion.=C2=A0 The idea behind orphaning the blocks of non-upg= raded miners was to serve as a wake-up call to upgrade, to reduce the chanc= es of a minority chain emerging in the first place, similar to what happens= automatically with a soft-forking change.=C2=A0 If one's worry is a ch= ain split, then this seems like a reasonable way to reduce the chances of t= hat worry materializing.=C2=A0 The Level 3 anti-split protection takes this= idea one step further to ensure that if a minority branch does emerge, tha= t transactions cannot be confirmed on that branch.
First of all, the ba= r for miners being on the new chain is extremely high, 95%.

I=E2=80=99m very confident that m= ost people do NOT want a split, especially the miners.=C2=A0 The upgrade to= larger blocks will not happen until miners are confident that no minority = chain will survive. =C2=A0

Second of all, soft forks make rule restrict= ions on classes of transactions that are already non-standard so that any n= on-upgraded miners are unlikely to be including txs in their blocks which w= ould violate the new rules and should not have their blocks orphaned even a= fter the fork.

I a= gree that the soft-fork mechanism usually works well.=C2=A0 I believe this = mechanism (or perhaps a modified version of it) to increase the block size = limit will likewise work well.=C2=A0 All transactions types that are curren= tly valid will be valid after the upgrade, and no new types of transactions= are being created.=C2=A0 The =E2=80=9Cblock-size-limit gene" of netwo= rk 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:=C2=A0https://www.youtube.com/watch?v= =3DpWnFDocAmfg)

Finally, soft forks are designed to only be used wh= en there is a very wide community consensus and the intention is not to ove= rrule anyone's choice to remain on the old rules but to ensure the secu= rity of nodes that may have neglected to upgrade.=C2=A0 Obviously it is imp= ossible to draw a bright line between users who intentionally are not upgra= ding due to opposition and users that are just being lazy.=C2=A0 But in the= case of a proposed BU hard fork it is abundantly clear that there is a ver= y significant fraction, in fact likely a majority of users who intentionall= y want to remain on the old rules.

<= /div>
My read is completely different.=C2=A0 I still have never = talked with a person in real life who doesn=E2=80=99t want the block size l= imit to increase.=C2=A0 Indeed, I have met people who worry that Bitcoin Un= limited 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.=C2=A0 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 adjus= t the size of blocks their nodes will accept, so that these node operators = can follow consensus through the upgrade if they choose to. =C2=A0

This is not a fight about =E2=80=9CCore vs. BU=E2=80=9D; B= itcoin=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.=C2=A0 To me it seems this is largely a fight about whe= ther node operators should be easily able to adjust the size of blocks thei= r nodes accept.=C2=A0 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). =C2=A0

As a Bitcoi= n user I find it abhorrent the way you are proposing to intentionally cripp= le the chain and rules I want to use instead of just peacefully splitting.<= /div>

Once again, this is not= my proposal.=C2=A0 I am writing about what I have come to learn over the p= ast several weeks.=C2=A0 When I first heard about these ideas, I was initia= lly against them too.=C2=A0 They seemed harsh and merciless.=C2=A0 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 conce= rn 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 looki= ng. People who believe that an important outcome of the upgrade to larger b= locks 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 spl= it), 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 informati= on in them? Sorry if I misunderstood). =C2=A0

But = if one's intention is to split and not follow the majority hash power w= hen blocks become larger, then why not change the proof-of-work?=C2=A0 This= would certainly result in a peaceful splitting, as you said you desire. = =C2=A0

Best regards,
<= div>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 s= plit compared to a loosening of the consensus rule set.=C2=A0 The way this = works is that miners who fail to upgrade to the new tighter ruleset will ha= ve their non-compliant blocks orphaned by the hash power majority.=C2=A0 Th= is is a strong incentive to upgrade and has historically worked well.=C2=A0= If a minority subset of the network didn=E2=80=99t want to abide by the ne= w restricted rule set, a reasonable solution would be for them to change th= e 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 conce= rn of both business such as Coinbase and Bitpay, and most miners, is the po= ssibility of a blockchain split and the associated confusion, replay risk, = etc.=C2=A0 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 l= ikely as we move towards larger blocks.=C2=A0 Two proposed techniques to re= duce the chances of a split are:

1. That miners begin to orphan the blocks of non-upgraded miners once a sup= er-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), majori= ty miners would continually re-org that minority branch with empty blocks t= o prevent transactions from confirming, thereby eliminating replay risk.
Just like after a soft forking change, a minority that does not want to abi= de by the current ruleset enforced by the majority could change the proof-o= f-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@li= sts.linuxfoundation.org> wrote:
>
> On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> I don't know what "Time is running short I fear" sta= nds 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 wha= t
> "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<= br> > 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.=C2=A0 My fear is the centralized mining power being us= ed
> 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_t= ells_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-f= rom-my-visit-with-2348878a16d8
>
>=C2=A0 =C2=A0 [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners w= ill orphan the
>=C2=A0 =C2=A0 blocks of non-compliant miners prior to the first larger = block
>=C2=A0 =C2=A0 to serve as a reminder to upgrade. Simply due to the poss= ibility
>=C2=A0 =C2=A0 of having blocks orphaned, all miners would be motivated = to
>=C2=A0 =C2=A0 begin signalling for larger blocks once support definitiv= ely
>=C2=A0 =C2=A0 passes 51%. If some miners hold out (e.g., they may not b= e
>=C2=A0 =C2=A0 paying attention regarding the upgrade), then they will b= egin
>=C2=A0 =C2=A0 to pay attention after losing approximately $15,000 of re= venue
>=C2=A0 =C2=A0 due to an orphaned block.
>
>=C2=A0 =C2=A0 [Level 3] Anti-split protection=E2=80=8A=E2=80=8AIn the s= cenario where Levels
>=C2=A0 =C2=A0 1 and 2 protection fails to entice all non-compliant mine= rs to
>=C2=A0 =C2=A0 upgrade, a small-block minority chain may emerge. To addr= ess the
>=C2=A0 =C2=A0 risk of coins being spent on this chain (replay risk), ma= jority
>=C2=A0 =C2=A0 miners will deploy hash power as needed to ensure the min= ority
>=C2=A0 =C2=A0 chain includes only empty blocks after the forking point.= This
>=C2=A0 =C2=A0 can easily be accomplished if the majority miners maintai= n a
>=C2=A0 =C2=A0 secret chain of empty blocks=E2=80=8A=E2=80=8Abuilt off t= heir last empty
>=C2=A0 =C2=A0 block=E2=80=8A=E2=80=8Apublishing only as much of this ch= ain as necessary
>=C2=A0 =C2=A0 to orphan any non-empty blocks produced on the minority c= hain.
>
>
>
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: c= annon@cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD<= br> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5U= QxQM
> eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6= EoUH
> h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGs= QQhu
> gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDc= d3XK
> VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+= cW1B
> TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP= 4eRj
> j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOp= InGw
> NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7Da= Ph7u
> YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk= 1MpN
> ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUE= LBXa
> 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQ= ik9S
> /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



__________________= _____________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--94eb2c0d9348df67a8054ba7f634--