ECIP 1096: 51% Attack protection system based on Bitcoin Merged Mining

Abstract

We present a proposal for ETC to use blocks mined with SHA-256 in Bitcoin to detect blockchain branches that have been mined in private and rise alarms that can prevent double-spend attacks. The proposal enables full nodes to take local decision to prevent certain attacks, but also the existence of a public view of the different competing ETC branches enables the use a Fork Monitoring System that can provide more detailed alerts to full nodes and to the community.

Motivation

During August 2020, Ethereum Classic was the target of two successful 51% attacks. The events have shown that the current levels of security provided by the Ethash miners are not enough.

To make ETC more secure, this proposal presents an enhancement that allows full nodes to know if the best chain they have choosen was publicly available at the time of creation or it was hidden to the network. Two measures are computed by the node: the cumulative visibility score and the average visibility score over a period of 1000 blocks. The higher the cumulative score, the highest the amount of information that was timely made public about this blockchain. Alarms can be established when the average visibility score drops below a certain threshold, such as 70%. ETC users can buy visibility proofs using a trustless contract running on the RSK blockchain. A Visibility proof contains a checkpoint in the ETC blockchain that the user wants to be visible. The contract is queried by Bitcoin miners, which take the checkpointed block and publishes it in the coinbase of blocks.

By leveraging RSK network’s existing merged mining capabilities with Bitcoin, RSK can forward the ETC checkpoint information to Bitcoin miners in order to link it to a Bitcoin block and access Bitcoin SHA-256 security levels. The process that allows this is called Universal Merged Mining (UMM) and currently provides access to 100% of the Bitcoin Network Hashrate, at a frequency of one checkpoint every 20 minutes.

Specification

Changes must be done in different parts of the ETC protocol. A description of changes follows:

VisibilityProof

Every block can be referenced by zero, one or more than one VisibilityProof messages. A VisibilityProof message that references a block can be included in any of the following 256 blocks of the referenced block. A VisibilityProof message therefore attests that Bitcoin hashrate has confirmed the referenced block.

VisibilityProof messages are non-interactive SHA256 proofs-of-work and they can be verified by ETC without connecting to the Bitcoin network, similar to merge-mining proofs.

A VisibilityProof score is measured by sum of the scores of the Bitcoin headers that reference it, either from a single VisibilityProof message or from multiple messages. The score of a Bitcoin header is the difficulty of the block, specified in the header.

Each VisibilityProof message m contains P(m) merge-mining proofs. Each merge-mining proof contains a Bitcoin header. Each header must have a hash that matches the difficulty established by the header.

There are two types of Bitcoin headers: a hit and a hit confirmation. A hit must have a merge-mining proof that relates the header unequivocally to an ETC block. A hit confirmation is a child of a hit or a child of another hit confirmation. Hit confirmations are proven to not reference any other ETC block. Hit confirmations are “unclaimed” proof-of-work that ETC claims to protect from private miners. Hit confirmations must come after hits in the VisibilityProof message. Each hit confirmation must have the prior block header as parent. For example, the following is a valid VisibilityProof message (in brackets we show 16-byte truncated block hashes, merge-mining proofs are omitted):

1. **hit**:  hash=0000000000000000000017b25971a701, blockHeight=644735, parent =0000000000000000000d9e9adbe0d01
2. **conf**: hash=0000000000000000000a34ee53a217b6, blockHeight=644736,  Parent=0000000000000000000017b25971a701
3. **conf**: hash=0000000000000000000db9f0fb12c4e9, blockHeight=644737, Parent=0000000000000000000a34ee53a217b6
4. **hit**:  hash=0000000000000000000a7470181b940a2, blockHeight=644740, Parent=0000000000000000000a34ee53a217b6
5. **conf**: hash=000000000000000000025fdd6edcee338, blockHeight=644741, Parent=0000000000000000000a7470181b940a2

Hit Confirmations can prove not to contain the merge-mining tag and merge-mining tree root, or they can prove to contain the tree, but not an ETC block in the tree (proof of non-membership). To prove non-membership the Merge-Mining tree has nodes augmented with the minimum blockchain ID and maximum blockchain IDs of the contained children. ETC Blockchain ID is 61.

VisibilityProof Message Format

The format of a VisibilityProof message is the following:

VisibilityProof = { Payload , Signature } 
Payload = { ETC-Block-Height, list of Merge-Mining-Proof [, ETC-Address] }
Merge-Mining-Proof = {Bitcoin-Header, Transaction-Membership-Proof,Coinbase-Tail, SHA256-Mid-State [,MM-Proof] [,Armadillo-Data] }
MM-Proof = { MM-Path, Terminal-Hash }
Bitcoin-Header = array[0..79] of Byte
Transaction-Membership-Proof = List of Bitcoin-Block-Hash
Bitcoin-Block-Hash = Array[0..31] of Byte
SHA256-Mid-State = Array[0..63] of Byte
MM-Path = List of Aug-Node-Plus-Hash
Aug-Node-Plus-Hash = {LeftMinID, RightMaxID, MM-Hash }
MM-Hash = Array[0..19] of Byte
LeftMinID = Uint32
RightMaxID = UInt32
Terminal-Hash = Array[0..19] of Byte
Armadillo-Data = Commit-To-Parents-Vector, Total-Difficulty-Compressed
Commits-To-Parent-Vector = Array[0..7] of Uint16
Total-Difficulty-Compressed = Uint64

For Membership Proofs(“RSKBLOCK:”): Terminal-Hash = Keccack(ChainID | ETC-Block-Hash | ETC-Address | Armadillo-Data)[0..11]

Each Bitcoin header is associated with a its coinbase transaction by a Merkle membership proof for the Bitcoin Transaction Merkle Tree root. Not all the coinbase transaction needs to be presented, but only the tail, containing the merge-mining tag (“RSKBLOCK:”). The tail contains up to 128 bytes of coinbase transaction. To prove the tail corresponds to the coinbase transaction hash, a SHA256 mid-state is given. This mid-state is extender with the tail to finalize the coinabse and obtain the coinbase transaction hash. Since the believed bit-security of a SHA256 freestart colission attack is much higher than the proof-of-work established by the Bitcoin Header, the compression provided by the coinbase tail does not pose a security risk. For hits (membership proofs) the tail contains the merge-mining tag, followed by the hash digest of the root of a merge-mining tree of block hashes. For hit confirmations (non-membership proofs) the tail must not contain the tag or must contain the tag and the tree but without an ETC block in it. The Terminal-Hash is a 20-byte Keccak hash digest prefix of the ChaiID, the ETC-Block-Hash and the ETC-Address to pay the reward. This address can be the same as the miner address that includes the VisibilityProof or it can be a different address. Finally, for a Merkle membership proof of the ETC block hash in this new tree is added to the proof. The ETC-Block-Hash must match the block in the ETC blockchain at height ETC-Block-Height.

The ETC-Address is verified so that all blocks presented must belong to the same ETC-Address. If the miner address does not match the ETC-Address, then the ETC-Address fields must be present. The signature signs the Payload with the private key associated with the ETC-Address address. This ensures that the payload comes from the owner of the ETC-Address.

Armadillo Data Verification

The Armadillo Data allows a Fork Monitoring System to build a DAG of all the ETC forks in existence by connecting individual Bitcoin headers. The Armadillo Data is submitted along with the ETC-Address and ETC-Block-Hash to the Bitcoin mining system (through RSK). The ETC Blockchain consensus must verify that the Armadillo data is correct. Armadillo data contains 2 elements: the Commits-To-Parent-Vector and the Total-Difficulty-Compressed. The first element is an array of 8 element. Each element e(i) is an Uint16 that representsthe 16 less significant bits of the ETC block hash at position n-(n mod 32)-(i*32), where n is the height of the block being checkpointed. The total difficulty is compressed simply by taking the 64 most significative bits.

Proof Size

The size of a VisibilityProof message is variable. Normally it will contain a single Bitcoin block. However, it could contain more. We establish a maximum size of 10 Kilobytes per VisibilityProof proof. The additional bandwidth and storage space required by VisibilityProof messages is irrelevant to ETC.

Alarm Thresholds

We propose that for each window of 1000 blocks (with a delay of 256 blocks), the average visibility score is computed. If the visibility score decreases below 80% of the score of the previous interval, the node will enter a safe-mode and stop confirming transactions (in case of an exchange, it will not confirm an ETC deposit).

Because RSK handles the construction of the merge-mining tag to be included in Bitcoin blocks, the ETC community will be able to detect immediately if the Bitcoin network is producing VisibilityProof for a bock different from the ETC honest bestchain. Such event can trigger automatic notifications to exchanges and other economic actors.

Block Format

To avoid changing the ETC block header format, the VisibilityProof proof can be included as an uncle, with a specil magic prefix to distiguish it from normal uncles. It can also be added in the ExtraData field. Of course, a new special field visibilityProofs can be added to the ETC block header.

« The exact format will be specified later »

Inclusion of VisibilityProof Proofs

On a first version, EtHash miners will be the only ones that will have the possibility to add VisibilityProofs to their blocks.

In the future, the ETC network can propagate VisibilityProofs messages and we can let any user participate and collect fees from this system. This requires no changes to consensus.

Rewards

If a miner decides to add a VisibilityProof message in a slot, it will be rewarded by an extra subsidy. To prevent changing the ETC supply function, the extra subsidy will be obtained by diluting all remaining block subsidies by a fixed percentage. The exact amount is to be decided by the community but we propose this to be 10% of the current subsidy, starting at 1% and increasing until 10% during a period of 3 months. This will allow for EtHash miners to adapt and provides enough incentives for them to start using the RSK UMM system to obtain VisibilityProofs for their blocks.

To enable the creation of an independent and open VisibilityProofs market, a small percentage (i.e. 5%) of the Visibility subsidy is paid to the miner who included the VisibilityProof message. The remainder is paid to the ETC-Address (funds are directly added to the account balance without contract code execution). If the miner address matches the ETC-Address, then all reward will be paid to the same account.

Timestamp Validation

The timestamp of Bitcoin hit header must be not higher than 10 minutes and not lower than 10 minutes of thetimestamp of the ETC checkpoint referenced by the VisibilityProof. This prevents Bitcoin miners from creating visibility proofs for old or future branches of the ETC blockchain.

JSON-RPC Interface

Expose two new methods:

• getSHAWork: retrieves SHAsh to be used for merged mining with Bitcoin.
• submitSHAPoW: receives all the needed elements to validate the PoW and then create the UMM uncle block.

Rationale

The spirit of this proposal is to present a simple way to provide ETC with an otional system that can temporarily or permanently protect it from 51% attacks by establishing a strong deterrent. To achieve that:

• VisibilityProof messages are included as uncles so the system is the least invasive way as possible.
• In the current version, VisibilityProof messages are included by mining nodes. However, the system allows any user to participate in the VisibilityProof system. This extension requires adding a new message to the wire protocol the relay of VisibilityProof proofs.
• By having a non-mandatory addition of VisibilityProof messages, ETC blockchain can keep working normally even if with no VisibilityProof on the blocks.

Universal Merged Mining

Universal Merged Mining offers access to Bitcoin SHA-256 PoW by forwarding the to-be-validated information through smart-contracts deployed on the RSK blockchain.

In order to get the information validated, “merge-mining proof time” must be bought in advance. A smart-contract that runs a public blind auction exists in RSK for that purpose. The auction will be open for a fixed period of time and once finished the winner will get the right to include the information in all the merge-mined Bitcoin blocks for the time he bought. Initially the contract will auction one hour intervals, but this value can be chosen freely. The auction floor will be a value that covers the a number K of Bitcoin blocks that can be mined for the auctioned period of time (i.e K=12). A winner gets the chance to submit the ETC block Hash (that corresponds to a VisibilityProof) to the contract during the acquired interval. The auction contract monitors all Bitcoin blocks mined for the winner and counts the actual number of hit blocks and hit confirmations that occurred during the time interval bought by the buyer. If less than K blocks are mined during the interval, then the funds overpaid are immediately refunded to the buyer at the end of the period.

Internally, once the contract receives the data from the auction winner, RSK mining nodes start mining Bitcoin blocks with the given information in the merge-mining Merkle tree, whose root is specified in the coinbase transaction. Not all RSK blocks fulfill Bitcoin difficulty, and therefore the UMM system only focuses on the blocks that occur after the first hit (including the hit).

Detecting and Preventing Visible Double-Spend Attacks

An ad-hoc double-spend monitoring system similar to RSK’s Armadillo protection system should be deployed. This system can product succinct proofs that can convince any node that an attack is ongoing without the need for this node to connect to the Bitcoin network. This enables the creation of an alert system embedded into the ETC network that can propagate alerts and automatically protect nodes, increasing the soundness at the cost of availability. However, the sole existence of the system is enough of a deterrent to prevent attacks and therefore availability is not normally affected. Exchanges can stop confirming deposits during attack periods to prevent being affected by double-spend attacks.

Detecting and Preventing Hidden Double-Spend Attacks

We’ve shown that the VisibilityProof system provides monetary incentives to include visibility proofs, but the incentives are too low to guarantee protection against a hidden attacker that double-spends against an online exchange. We must ensure that there are stronger incentives for VisibilityProofs to exists, forcing the malicious fork to be become public. Once the fork is public, the Armadillo monitoring system can produce useful alerts. Since several methods are possible to increase the need of VisibilityProofs, we think the method chosen should be specified in a separate ECIP.

However, here we present some possibilities:

• Request at least 33% of the Bitcoin hashrate providing visibility proofs with at least one visibility proof every 3 hours, in order to consider the fork valid. The forked chain can achieve this by including a single VisibilityProof hit every 3 hours.

• Using a system such as PirlGuard to penalize forks that do not provide visibility proofs. Our suggestion is that a fixed visibility threshold is chosen, and penalization either occurs or not (boolean). It’s also possible to penalize in inverse proportion to the visibility of a fork, but the effects on the stability of the blockchain in this case must be further studied.

Copyright/Licensing

GNU Lesser General Public License v3.0.