diff options
| author | Alphonse Pace <alp.bitcoin@gmail.com> | 2017-03-26 15:20:56 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-03-26 20:20:59 +0000 |
| commit | 34f9866989a876ebd2dfe3172499497e9f15bffb (patch) | |
| tree | c97277ad78cff107e66540d4789b9e0a9d0e6354 /61/ea49d84aa4ae5df977c39c9412513112dd4c0e | |
| parent | 31d61c4a14d7d05ee0bbf34cc96b347455e90577 (diff) | |
| download | pi-bitcoindev-34f9866989a876ebd2dfe3172499497e9f15bffb.tar.gz pi-bitcoindev-34f9866989a876ebd2dfe3172499497e9f15bffb.zip | |
Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
Diffstat (limited to '61/ea49d84aa4ae5df977c39c9412513112dd4c0e')
| -rw-r--r-- | 61/ea49d84aa4ae5df977c39c9412513112dd4c0e | 704 |
1 files changed, 704 insertions, 0 deletions
diff --git a/61/ea49d84aa4ae5df977c39c9412513112dd4c0e b/61/ea49d84aa4ae5df977c39c9412513112dd4c0e new file mode 100644 index 000000000..fc5a7eefc --- /dev/null +++ b/61/ea49d84aa4ae5df977c39c9412513112dd4c0e @@ -0,0 +1,704 @@ +Return-Path: <alp.bitcoin@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 618AA727 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 26 Mar 2017 20:20:57 +0000 (UTC) +Received: by mail-pg0-f48.google.com with SMTP id 81so5228116pgh.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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> + <f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info> + <9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com> + <CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com> + <9EB5050D-E54E-4E8B-84C6-95CC1FAC4081@gmx.com> +From: Alphonse Pace <alp.bitcoin@gmail.com> +Date: Sun, 26 Mar 2017 15:20:56 -0500 +Message-ID: <CAMBsKS9YMeHUsSRkGU2ef5vFrFgOTSsAhkHApdnU9ygqX_qDNw@mail.gmail.com> +To: Peter R <peter_r@gmx.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + +<div dir=3D"ltr">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.<div><br></div><div>-Alphonse</div></d= +iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, Mar 26= +, 2017 at 2:05 PM, Peter R via bitcoin-dev <span dir=3D"ltr"><<a href=3D= +"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de= +v@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"g= +mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= +eft:1ex"><div style=3D"word-wrap:break-word">Hello Alex,<div><br></div><div= +>Thank you for the thoughtful reply. =C2=A0</div><div><br><div><span class= +=3D""><blockquote type=3D"cite"><div><div dir=3D"ltr">Surely you are aware = +that what you are proposing is vastly different from the way soft forks hav= +e historically worked.=C2=A0</div></div></blockquote><div><br></div></span>= +<div>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</div><div><br></div><div>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</div><div><br= +></div><div>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.</div><span class=3D""><b= +r><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>First of all, the ba= +r for miners being on the new chain is extremely high, 95%.</div></div></di= +v></blockquote><div><br></div></span><div>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</div><span class=3D""><br><blockquote type=3D"ci= +te"><div><div dir=3D"ltr"><div>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.</div></div></div></blockquote><div><br></div></span><div>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=A0<a href=3D"https://www.youtube.com/wat= +ch?v=3DpWnFDocAmfg" target=3D"_blank">https://www.youtube.com/<wbr>watch?v= +=3DpWnFDocAmfg</a>)</div><span class=3D""><br><blockquote type=3D"cite"><di= +v><div dir=3D"ltr"><div>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></div></div></blockquote><div><br><= +/div></span><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</div><di= +v><br></div><div>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</div><span clas= +s=3D""><br><blockquote type=3D"cite"><div><div dir=3D"ltr"><div>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></div></div></blockquote><div><br></div></span>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!</div><div><br></div><div>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</div><div><br></div><div>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</div><div><div class=3D"h5"><div><br></div><div>Best regards,</div><= +div>Peter R<br><div><br></div><div><br></div><br><blockquote type=3D"cite">= +<div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Mar = +25, 2017 at 3:28 PM, Peter R via bitcoin-dev <span dir=3D"ltr"><<a href= +=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= +-dev@lists.<wbr>linuxfoundation.org</a>></span> wrote:<br><blockquote cl= +ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p= +adding-left:1ex">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 (<a h= +ref=3D"https://bitcointalk.org/index.php?topic=3D563972.0" rel=3D"noreferre= +r" target=3D"_blank">https://bitcointalk.org/index<wbr>.php?topic=3D563972.= +0</a>).<br> +<br> +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:<br> +<br> +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.<br> +<br> +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.<br= +> +<br> +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.<br> +<br> +Best regards,<br> +Peter R<br> +<div class=3D"m_-102974887459783682HOEnZb"><div class=3D"m_-102974887459783= +682h5"><br> +<br> +> On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <<a href=3D"mai= +lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li= +sts.linuxfounda<wbr>tion.org</a>> wrote:<br> +><br> +> On 03/24/2017 07:00 PM, Aymeric Vitte wrote:<br> +>> I don't know what "Time is running short I fear" sta= +nds for and when 50%<br> +>> is supposed to be reached<br> +><br> +> -----BEGIN PGP SIGNED MESSAGE-----<br> +> Hash: SHA512<br> +><br> +> On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know wha= +t<br> +> "Time is running short I fear" stands for and when 50% > = +is supposed<br> +> to be reached<br> +><br> +> According to current hashrate distribution tracking site coin.dance,<b= +r> +> very likely within less than four weeks according to current hashrate<= +br> +> takeover rate.<br> +><br> +> While a fork is very likely, that I dont really fear because worst<br> +> case scenario is that bitcoin still survives and the invalid chain<br> +> becomes an alt.=C2=A0 My fear is the centralized mining power being us= +ed<br> +> to attack the valid chain with intentions on killing it. [1]<br> +><br> +> Shouldn't this 50% attack they are threatening be a concern? If it= +<br> +> is a concern, what options are on the table. If it is not a concern<br= +> +> please enlightent me as to why.<br> +><br> +><br> +> [1] Source:<br> +> <a href=3D"https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizu= +n_tells_miners_to_force_a_hard_fork_by/" rel=3D"noreferrer" target=3D"_blan= +k">https://www.reddit.com/r/Bitco<wbr>in/comments/6172s3/peter_rizun<wbr>_t= +ells_miners_to_force_a_hard_<wbr>fork_by/</a><br> +><br> +> Text:<br> +><br> +> The attack quoted from his article:<br> +> <a href=3D"https://medium.com/@peter_r/on-the-emerging-consensus-regar= +ding-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8" re= +l=3D"noreferrer" target=3D"_blank">https://medium.com/@peter_r/on<wbr>-the-= +emerging-consensus-regard<wbr>ing-bitcoins-block-size-limit-<wbr>insights-f= +rom-my-visit-with-<wbr>2348878a16d8</a><br> +><br> +>=C2=A0 =C2=A0 [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners w= +ill orphan the<br> +>=C2=A0 =C2=A0 blocks of non-compliant miners prior to the first larger = +block<br> +>=C2=A0 =C2=A0 to serve as a reminder to upgrade. Simply due to the poss= +ibility<br> +>=C2=A0 =C2=A0 of having blocks orphaned, all miners would be motivated = +to<br> +>=C2=A0 =C2=A0 begin signalling for larger blocks once support definitiv= +ely<br> +>=C2=A0 =C2=A0 passes 51%. If some miners hold out (e.g., they may not b= +e<br> +>=C2=A0 =C2=A0 paying attention regarding the upgrade), then they will b= +egin<br> +>=C2=A0 =C2=A0 to pay attention after losing approximately $15,000 of re= +venue<br> +>=C2=A0 =C2=A0 due to an orphaned block.<br> +><br> +>=C2=A0 =C2=A0 [Level 3] Anti-split protection=E2=80=8A=E2=80=8AIn the s= +cenario where Levels<br> +>=C2=A0 =C2=A0 1 and 2 protection fails to entice all non-compliant mine= +rs to<br> +>=C2=A0 =C2=A0 upgrade, a small-block minority chain may emerge. To addr= +ess the<br> +>=C2=A0 =C2=A0 risk of coins being spent on this chain (replay risk), ma= +jority<br> +>=C2=A0 =C2=A0 miners will deploy hash power as needed to ensure the min= +ority<br> +>=C2=A0 =C2=A0 chain includes only empty blocks after the forking point.= + This<br> +>=C2=A0 =C2=A0 can easily be accomplished if the majority miners maintai= +n a<br> +>=C2=A0 =C2=A0 secret chain of empty blocks=E2=80=8A=E2=80=8Abuilt off t= +heir last empty<br> +>=C2=A0 =C2=A0 block=E2=80=8A=E2=80=8Apublishing only as much of this ch= +ain as necessary<br> +>=C2=A0 =C2=A0 to orphan any non-empty blocks produced on the minority c= +hain.<br> +><br> +><br> +><br> +><br> +> - --<br> +> Cannon<br> +> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832<br> +> Email: <a href=3D"mailto:cannon@cannon-ciota.info" target=3D"_blank">c= +annon@cannon-ciota.info</a><br> +><br> +> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD<= +br> +> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br> +> If this matters to you, use PGP.<br> +> -----BEGIN PGP SIGNATURE-----<br> +><br> +> iQIcBAEBCgAGBQJY1pbaAAoJEAYDai<wbr>9lH2mwOO0QANOWqGzPNlifWguc+Y5U<wbr>= +QxQM<br> +> eAiztAayQBoAyLcFE7/qdtSNlUxbIA<wbr>HG17fM+aNkehjYH2oN5ODJ+<wbr>j7E2Yt6= +EoUH<br> +> h5t8MLhNRG/YGF1hJK8Io940Emdcju<wbr>NmohiZvrjIqEOYggmLU3hR6J4gsuGs<wbr>= +QQhu<br> +> gY3sMS/TtT+gZNH8w53ePGrsVhuQR7<wbr>yEMMr91/vM4+<wbr>Q5abpwqLeYLnslaZDc= +d3XK<br> +> VB9vyyK08r34J1GQt/H4UvTvGs28MF<wbr>KBkvueA/Sfyvnrih7+WSQLuSvhiFr+<wbr>= +cW1B<br> +> TmSVYrB2DzyHN27jDCI2ty3ryNE4PM<wbr>YcaeLfI2TTbsD/MuVU5lK0kM/1JajP<wbr>= +4eRj<br> +> j+P03OipuQiy/dNU63w0Uka2PbdKhD<wbr>C13hVtK/ttBbNppbjnGeB9PYSJCzOp<wbr>= +InGw<br> +> NwAyz0rVS/llGsdctcII7Z6AUMGuJX<wbr>zsosY8vjUroU+<wbr>KFRDqIbDfC53sH7Da= +Ph7u<br> +> YawwId5S5RnZsAGCUJ+qNcg0s728J1<wbr>eDjofN291IS5sOKMzpI7KhaOhFxjnk<wbr>= +1MpN<br> +> ZAlQeTlvG+sAdn61QMQK1NbFt0km+j<wbr>cqyVh0+L01yB0K4VDi1YFJaSBOaYUE<wbr>= +LBXa<br> +> 8a6WhZf5nrl5UIpH7rRcPzzqchcdYc<wbr>zy5VRZp2UsU+HYeqLXlcN0a03yPpVQ<wbr>= +ik9S<br> +> /T93MuZgmvSCry5MlccA<br> +> =3DR71g<br> +> -----END PGP SIGNATURE-----<br> +><br> +> ______________________________<wbr>_________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= +r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br> +<br> +______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-d<wbr>ev</a><br> +</div></div></blockquote></div><br></div> +</div></blockquote></div><br></div></div></div></div><br>__________________= +____________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<br></blockquote></div><br></div> + +--94eb2c0d9348df67a8054ba7f634-- + |