[bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
peter_r at gmx.com
Sat Mar 25 20:28:44 UTC 2017
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’t 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=563972.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.
> On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <bitcoin-dev at 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. 
> 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.
>  Source:
> The attack quoted from his article:
> [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.
> - --
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon at 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-----
> -----END PGP SIGNATURE-----
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
More information about the bitcoin-dev