Return-Path: <peter_r@gmx.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B766941C for <bitcoin-dev@lists.linuxfoundation.org>; 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 <bitcoin-dev@lists.linuxfoundation.org>; 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 <peter_r@gmx.com> In-Reply-To: <CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com> 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> <f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info> <9C2A6867-470D-4336-8439-17F4E0CA4B17@gmx.com> <CAPWm=eV2aLJKMM_5T-jaXCm1umRFxy+vfirBqCGAvUKHtOphQg@mail.gmail.com> To: Alex Morcos <morcos@gmail.com> 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 <bitcoin-dev@lists.linuxfoundation.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 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 = <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 = <bitcoin-dev@lists.linuxfoundation.org = <mailto: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 = <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 = <bitcoin-dev@lists.linuxfoundation.org = <mailto: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/ = <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 = <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 <mailto: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 = <mailto:bitcoin-dev@lists.linuxfoundation.org> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = <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 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Hello Alex,<div class=3D""><br class=3D""></div><div = class=3D"">Thank you for the thoughtful reply. </div><div = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D"">Surely you are aware that what = you are proposing is vastly different from the way soft forks have = historically worked. </div></div></blockquote><div><br = class=3D""></div><div>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). = </div><div><br class=3D""></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 = produce orphaned, serving as a wake-up call to upgrade. = </div><div><br class=3D""></div><div>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.</div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"">First of all, the bar for miners = being on the new chain is extremely high, = 95%.</div></div></div></blockquote><div><br class=3D""></div><div>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. </div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"">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.</div></div></div></blockquote><div><br class=3D""></div><div>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: <a = href=3D"https://www.youtube.com/watch?v=3DpWnFDocAmfg" = class=3D"">https://www.youtube.com/watch?v=3DpWnFDocAmfg</a>)</div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"">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.</div></div></div></blockquote><div><br = class=3D""></div><div>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. </div><div><br = class=3D""></div><div>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). </div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">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.</div></div></div></blockquote><div><br = class=3D""></div>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!</div><div><br class=3D""></div><div>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). = </div><div><br class=3D""></div><div>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. </div><div><br = class=3D""></div><div>Best regards,</div><div>Peter R<br = class=3D""><div><br class=3D""></div><div><br class=3D""></div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = class=3D"gmail_extra"><br class=3D""><div class=3D"gmail_quote">On Sat, = Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <span dir=3D"ltr" = class=3D""><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = target=3D"_blank" = class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>></span> = wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 = 0 0 .8ex;border-left:1px #ccc solid;padding-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 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 (<a = href=3D"https://bitcointalk.org/index.php?topic=3D563972.0" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://bitcointalk.org/<wbr = class=3D"">index.php?topic=3D563972.0</a>).<br class=3D""> <br class=3D""> 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:<br = class=3D""> <br class=3D""> 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.<br class=3D""> <br class=3D""> 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.<br class=3D""> <br class=3D""> 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.<br class=3D""> <br class=3D""> Best regards,<br class=3D""> Peter R<br class=3D""> <div class=3D"HOEnZb"><div class=3D"h5"><br class=3D""> <br class=3D""> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <<a = href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a>> = wrote:<br class=3D""> ><br class=3D""> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:<br class=3D""> >> I don't know what "Time is running short I fear" stands for and = when 50%<br class=3D""> >> is supposed to be reached<br class=3D""> ><br class=3D""> > -----BEGIN PGP SIGNED MESSAGE-----<br class=3D""> > Hash: SHA512<br class=3D""> ><br class=3D""> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know = what<br class=3D""> > "Time is running short I fear" stands for and when 50% > is = supposed<br class=3D""> > to be reached<br class=3D""> ><br class=3D""> > According to current hashrate distribution tracking site = coin.dance,<br class=3D""> > very likely within less than four weeks according to current = hashrate<br class=3D""> > takeover rate.<br class=3D""> ><br class=3D""> > While a fork is very likely, that I dont really fear because = worst<br class=3D""> > case scenario is that bitcoin still survives and the invalid = chain<br class=3D""> > becomes an alt. My fear is the centralized mining power being = used<br class=3D""> > to attack the valid chain with intentions on killing it. [1]<br = class=3D""> ><br class=3D""> > Shouldn't this 50% attack they are threatening be a concern? If = it<br class=3D""> > is a concern, what options are on the table. If it is not a = concern<br class=3D""> > please enlightent me as to why.<br class=3D""> ><br class=3D""> ><br class=3D""> > [1] Source:<br class=3D""> > <a = href=3D"https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells= _miners_to_force_a_hard_fork_by/" rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://www.reddit.com/r/<wbr = class=3D"">Bitcoin/comments/6172s3/peter_<wbr = class=3D"">rizun_tells_miners_to_force_a_<wbr = class=3D"">hard_fork_by/</a><br class=3D""> ><br class=3D""> > Text:<br class=3D""> ><br class=3D""> > The attack quoted from his article:<br class=3D""> > <a = href=3D"https://medium.com/@peter_r/on-the-emerging-consensus-regarding-bi= tcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://medium.com/@peter_r/<wbr = class=3D"">on-the-emerging-consensus-<wbr = class=3D"">regarding-bitcoins-block-size-<wbr = class=3D"">limit-insights-from-my-visit-<wbr = class=3D"">with-2348878a16d8</a><br class=3D""> ><br class=3D""> > [Level 2] Anti-split protection=E2=80=8A=E2=80=8AMiners = will orphan the<br class=3D""> > blocks of non-compliant miners prior to the first = larger block<br class=3D""> > to serve as a reminder to upgrade. Simply due to the = possibility<br class=3D""> > of having blocks orphaned, all miners would be = motivated to<br class=3D""> > begin signalling for larger blocks once support = definitively<br class=3D""> > passes 51%. If some miners hold out (e.g., they may = not be<br class=3D""> > paying attention regarding the upgrade), then they = will begin<br class=3D""> > to pay attention after losing approximately $15,000 of = revenue<br class=3D""> > due to an orphaned block.<br class=3D""> ><br class=3D""> > [Level 3] Anti-split protection=E2=80=8A=E2=80=8AIn = the scenario where Levels<br class=3D""> > 1 and 2 protection fails to entice all non-compliant = miners to<br class=3D""> > upgrade, a small-block minority chain may emerge. To = address the<br class=3D""> > risk of coins being spent on this chain (replay risk), = majority<br class=3D""> > miners will deploy hash power as needed to ensure the = minority<br class=3D""> > chain includes only empty blocks after the forking = point. This<br class=3D""> > can easily be accomplished if the majority miners = maintain a<br class=3D""> > secret chain of empty blocks=E2=80=8A=E2=80=8Abuilt = off their last empty<br class=3D""> > block=E2=80=8A=E2=80=8Apublishing only as much of this = chain as necessary<br class=3D""> > to orphan any non-empty blocks produced on the = minority chain.<br class=3D""> ><br class=3D""> ><br class=3D""> ><br class=3D""> ><br class=3D""> > - --<br class=3D""> > Cannon<br class=3D""> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 = E832<br class=3D""> > Email: <a href=3D"mailto:cannon@cannon-ciota.info" = class=3D"">cannon@cannon-ciota.info</a><br class=3D""> ><br class=3D""> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP = SHOULD<br class=3D""> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br class=3D""> > If this matters to you, use PGP.<br class=3D""> > -----BEGIN PGP SIGNATURE-----<br class=3D""> ><br class=3D""> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai<wbr = class=3D"">9lH2mwOO0QANOWqGzPNlifWguc+<wbr class=3D"">Y5UQxQM<br = class=3D""> > eAiztAayQBoAyLcFE7/<wbr class=3D"">qdtSNlUxbIAHG17fM+<wbr = class=3D"">aNkehjYH2oN5ODJ+j7E2Yt6EoUH<br class=3D""> > h5t8MLhNRG/<wbr class=3D"">YGF1hJK8Io940EmdcjuNmohiZvrjIq<wbr = class=3D"">EOYggmLU3hR6J4gsuGsQQhu<br class=3D""> > gY3sMS/TtT+<wbr class=3D"">gZNH8w53ePGrsVhuQR7yEMMr91/<wbr = class=3D"">vM4+Q5abpwqLeYLnslaZDcd3XK<br class=3D""> > VB9vyyK08r34J1GQt/<wbr class=3D"">H4UvTvGs28MFKBkvueA/Sfyvnrih7+<wbr = class=3D"">WSQLuSvhiFr+cW1B<br class=3D""> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PM<wbr = class=3D"">YcaeLfI2TTbsD/MuVU5lK0kM/<wbr class=3D"">1JajP4eRj<br = class=3D""> > j+P03OipuQiy/<wbr class=3D"">dNU63w0Uka2PbdKhDC13hVtK/<wbr = class=3D"">ttBbNppbjnGeB9PYSJCzOpInGw<br class=3D""> > NwAyz0rVS/<wbr class=3D"">llGsdctcII7Z6AUMGuJXzsosY8vjUr<wbr = class=3D"">oU+KFRDqIbDfC53sH7DaPh7u<br class=3D""> > YawwId5S5RnZsAGCUJ+<wbr class=3D"">qNcg0s728J1eDjofN291IS5sOKMzpI<wbr= class=3D"">7KhaOhFxjnk1MpN<br class=3D""> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+<wbr class=3D"">jcqyVh0+<wbr = class=3D"">L01yB0K4VDi1YFJaSBOaYUELBXa<br class=3D""> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYc<wbr class=3D"">zy5VRZp2UsU+<wbr = class=3D"">HYeqLXlcN0a03yPpVQik9S<br class=3D""> > /T93MuZgmvSCry5MlccA<br class=3D""> > =3DR71g<br class=3D""> > -----END PGP SIGNATURE-----<br class=3D""> ><br class=3D""> > ______________________________<wbr class=3D"">_________________<br = class=3D""> > bitcoin-dev mailing list<br class=3D""> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br = class=3D""> > <a = href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://lists.linuxfoundation.<wbr = class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><br = class=3D""> <br class=3D""> ______________________________<wbr class=3D"">_________________<br = class=3D""> bitcoin-dev mailing list<br class=3D""> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" = class=3D"">bitcoin-dev@lists.<wbr class=3D"">linuxfoundation.org</a><br = class=3D""> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"= rel=3D"noreferrer" target=3D"_blank" = class=3D"">https://lists.linuxfoundation.<wbr = class=3D"">org/mailman/listinfo/bitcoin-<wbr class=3D"">dev</a><br = class=3D""> </div></div></blockquote></div><br class=3D""></div> </div></blockquote></div><br class=3D""></div></body></html>= --Apple-Mail=_7103F21E-D0D3-4CF7-B386-6B445963A6BE--