diff options
| author | Peter R <peter_r@gmx.com> | 2017-03-25 13:28:44 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-03-25 20:33:55 +0000 |
| commit | 36b911088684b9443d4f8ba184af162db78cdd2e (patch) | |
| tree | 2309f292e7247598d7bce27d96dba865493210c1 | |
| parent | a5973f651571b8521dd80c99d2c36e3fc2c50baf (diff) | |
| download | pi-bitcoindev-36b911088684b9443d4f8ba184af162db78cdd2e.tar.gz pi-bitcoindev-36b911088684b9443d4f8ba184af162db78cdd2e.zip | |
Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
| -rw-r--r-- | 18/ce423bf2445213a664e8c72d5170c8f78c8908 | 202 |
1 files changed, 202 insertions, 0 deletions
diff --git a/18/ce423bf2445213a664e8c72d5170c8f78c8908 b/18/ce423bf2445213a664e8c72d5170c8f78c8908 new file mode 100644 index 000000000..1420ce9ba --- /dev/null +++ b/18/ce423bf2445213a664e8c72d5170c8f78c8908 @@ -0,0 +1,202 @@ +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 CC1974A6 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 25 Mar 2017 20:33:55 +0000 (UTC) +X-Greylist: delayed 00:05:04 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 6357118A + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 25 Mar 2017 20:33:54 +0000 (UTC) +Received: from [192.168.50.29] ([24.86.172.170]) by mail.gmx.com (mrgmx001 + [212.227.17.184]) with ESMTPSA (Nemesis) id 0LqylH-1cDqW43kzj-00eblM; + Sat, 25 Mar 2017 21:28:48 +0100 +Content-Type: text/plain; charset=utf-8 +Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) +From: Peter R <peter_r@gmx.com> +In-Reply-To: <f4849cef-3c40-31a4-e323-6a731bb52bc2@cannon-ciota.info> +Date: Sat, 25 Mar 2017 13:28:44 -0700 +Content-Transfer-Encoding: quoted-printable +Message-Id: <9C2A6867-470D-4336-8439-17F4E0CA4B17@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> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +X-Mailer: Apple Mail (2.2104) +X-Provags-ID: V03:K0:VjSSe95/B1INjwMMhfQZYHKiqyhZ5lUZCziF5ietTg2irVFYWSG + UkJzdSHyBeA2if+AN8uOj6UghWUXq38Dchzawd/3zbyMY9qJpd2Ki905aqLUo+wHGFl/KKN + LudCEFsjO2Bntc2lcSv3NkEbrPGoNWqTvSTP5TrHG9h01BdmxnRB37Wb4LLGZzQuOS0Ocwk + mUCsmWkx46jjOGK0WH4dQ== +X-UI-Out-Filterresults: notjunk:1;V01:K0:Q1B3TRxz1AY=:JjXAye0BLc/hecCkgU78Ke + YflUJjMYOsqjRIe0UVp5x7Jct0HQjn8m+QGcaAc2n3J8X2r8g/GNh+ULsU26KKkBtYgt3JEyT + c0hnf6fc5nAoI5+7zrmulxcK03O97wbXva42xrj8SiXW/3WDe9X/riotBr0C6i20KXWaIfCAT + d06CjWiNcTR15z0X4+wRAZhQInoz6enX3DANxedpy/7mmyF9AsmMgvPgzbLqu7ekM7j0UWKHb + tUqMoZcZ5zSSlBX6/jbPdW7W3ThdNfdbVTbHG5+NQOQKl7rv8OuQy87f2+6pD7ABNsDDLOFwL + tZKidxy7OO7MLUW0b3MDJ2hQDqFwjxq164r/CgObLZovvOoOnp/pmf8RKzgGox9uoYD1niJFT + 2iAQSEo5r8zIHLEbOD/rjvyMw1FP/RZMhAf/H7oDBkVsxLyO1IvaMko1SFpgLZJNh0CyEtqMy + Nqv278gZktaV6YnXZAguFi5d4KkL9IzkAqpas833XRvu71G9PO8eyohvP1PrmMhBWso+qfnXk + VyWndj0Gsy05C0w22HuGg4dqmMp44hkAHu8Pm2gjHjduarbnvREeGews6rLVrYT6lo0khRvJQ + Dr5YhWncn0dbdQIhnAe2Wyof89CIeqxCEjtWU+Nto1/TbcmQHI8TahVUwqAc7kEyceMOLjr7M + C5/bP9B6ax5+ISHSfMfoJpL28ikOQMM+kCRk0O0AFO6IV556UzT3ePOdtJYvWlWn9wdzVWsyO + /2dbLU4GuHEcxm/1dwcifhT6v/iQA0bFw1j8j9iEcHC/HRGcx0buD1Tb9MCoPeHISIJloEisP + p7MweUD +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, + LOTS_OF_MONEY, 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: Sat, 25 Mar 2017 22:54:17 +0000 +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: Sat, 25 Mar 2017 20:33:55 -0000 + +One of the purported benefits of a soft-forking change (a tightening of = +the consensus rule set) is the reduced risk of a blockchain split = +compared to a loosening of the consensus rule set. The way this works = +is that miners who fail to upgrade to the new tighter ruleset will have = +their non-compliant blocks orphaned by the hash power majority. This is = +a strong incentive to upgrade and has historically worked well. If a = +minority subset of the network didn=E2=80=99t want to abide by the new = +restricted rule set, a reasonable solution would be for them to change = +the proof-of-work and start a spin-off from the existing Bitcoin ledger = +(https://bitcointalk.org/index.php?topic=3D563972.0). + +In the case of the coming network upgrade to larger blocks, a primary = +concern of both business such as Coinbase and Bitpay, and most miners, = +is the possibility of a blockchain split and the associated confusion, = +replay risk, etc. By applying techniques that are known to be = +successful for soft-forking changes, we can likewise benefit in a way = +that makes a split less likely as we move towards larger blocks. Two = +proposed techniques to reduce the chances of a split are: + +1. That miners begin to orphan the blocks of non-upgraded miners once a = +super-majority of the network hash power has upgraded. This would serve = +as an expensive-to-ignore reminder to upgrade. + +2. That, in the case where a minority branch emerges (unlikely IMO), = +majority miners would continually re-org that minority branch with empty = +blocks to prevent transactions from confirming, thereby eliminating = +replay risk. + +Just like after a soft forking change, a minority that does not want to = +abide by the current ruleset enforced by the majority could change the = +proof-of-work and start a spin-off from the existing Bitcoin ledger, as = +suggested by Emin. =20 + +Best regards, +Peter R + + +> On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev = +<bitcoin-dev@lists.linuxfoundation.org> wrote: +>=20 +> 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 +>=20 +> -----BEGIN PGP SIGNED MESSAGE----- +> Hash: SHA512 +>=20 +> 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 +>=20 +> According to current hashrate distribution tracking site coin.dance, +> very likely within less than four weeks according to current hashrate +> takeover rate. +>=20 +> 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] +>=20 +> 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. +>=20 +>=20 +> [1] Source: +> = +https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun_tells_miners_= +to_force_a_hard_fork_by/ +>=20 +> Text: +>=20 +> 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 +>=20 +> [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. +>=20 +> [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. +>=20 +>=20 +>=20 +>=20 +> - -- +> Cannon +> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832=20 +> Email: cannon@cannon-ciota.info +>=20 +> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD=20= + +> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.=20 +> If this matters to you, use PGP. +> -----BEGIN PGP SIGNATURE----- +>=20 +> 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----- +>=20 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |