By Sergio Demian Lerner, IOV Labs Chief Innovation Scientist

[TL;DR] We invented a new type of merge-mined sidechain we call SyncChain, which enables fast peg-ins and peg-out (between Bitcoin and RSK, this is as low as 30 minutes for peg-ins and as low as 2 hours for peg-outs) and can be parametrized to unconditionally protect the peg from double-spends. This is a huge improvement from existing sidechains that require hundreds of block confirmations and whose security is based only on cryptoeconomic assumptions. The SyncChain protocol, which was built over some ideas we published in 2016, is orthogonal to the method used to unlock peg-outs, one interesting design is to create a Federated SyncChain. Finally we discuss the pros and cons for RSK to migrate from a Bitcoin SPV-sidechain to a Bitcoin SyncChain, and we lay down a tentative plan for a SyncChain network upgrade. 

Introduction

When RSK was initially designed, one of the design goals was to keep RSK independent of Bitcoin as much as possible to prevent any failure in Bitcoin from affecting RSK. During the 2015-2016 period Bitcoin was under continuous pressure and threats of contentious hard forks, and transaction fees rose considerably, preventing the use of Bitcoin for financial inclusion, which requires cheap payments. For these reasons RSK adopted a merge-mining consensus over being a counterparty-like overlay protocol. Merge-mining provides complete independence (including from Bitcoin block reversals) while the overlays do not. We used SPV proofs for proving foreign consensus, for exactly the same reason. 

The risk of Bitcoin being torn apart has diluted over time. We can therefore re-consider the requirements for the two-way-peg and reexamine the design space searching for better alternatives.

The SPV Bridge Security

 In several previous blog posts we analyzed how the RSK peg works. One of the properties of the RSK peg is that the reversal of the bitcoin blockchain does not imply the reversal of the RSK blockchain. Therefore, to prevent a double-spend, RSK requires the highest assurance that the Bitcoin blockchain will not revert past the peg-out transaction, such as waiting for 100 Bitcoin block confirmations. Let’s assume that the merge-mining engagement is around 50%, and there is one large malicious mining pool we’ll call Mallory, that has 51% of the RSK hashrate (25% of Bitcoin’s hashrate). Mallory could try to use all her hashrate to create a false header-only blockchain and feed it to the bridge, causing the bridge to accept whatever fake transaction Mallory asserts. This fake header-chain would not be a valid Bitcoin blockchain, and therefore Mallory would not disrupt the Bitcoin blockchain, but she wouldn’t be able to collect block rewards during the preparation of the attack. RSK is currently protected from this attack because federation functionaries will not issue a peg-in registration message if their local best chain does not match the Bitcoin best chain loaded in the bridge contract. However, we can think that if the SPV-based peg-in was maximally decentralized removing intervention from the federation, then the attack could succeed. We’ll call this a “fake peg-in” attack. The cost to perform a fake peg-in for Mallory in an unprotected variant of RSK is about 10M USD in electricity. Although the fake peg-in attack seems easily attributable to the “missing miner” by looking at the bitcoin coinbases, Mallory could claim her systems were hacked, and shift the blame to an unknown party. 

Also there is the peg-in double-spend attack. That attack requires informing an alternate best chain to the bridge contract and at the same time isolating federation functionaries to make them believe that this alternate best chain is the only one in existence. The cost of attack is still 10M USD in electricity, plus hacking the functionaries but the plunder now is not arbitrary bitcoin creation, but just to double the initially invested amount.

The opposite attack is the peg-out double-spend. In this attack Mallory performs a peg-out and then reverts the RSK blockchain to the point where the transaction that commands the peg-out is located. Again, the attack has a high cost in electricity, but, if the amount of bitcoins to be stolen is high enough, then the risk exists. Note that RSK has a network monitoring tool called Armadillo that enables decentralized alerts to prevent “free” merge-mining attacks, but this attack is still possible.

Another downside of the SPV bridge is that it requires 100 Bitcoin block confirmations (or equivalent RSK blocks for the same cumulative difficulty) for peg-ins and peg-outs. This impairs usability. Can we do better than the SPV Bridge in terms of security and usability ?

The Security of Two Way Pegs

To compare two way peg designs we define 8 protections that prevent double-spend attacks or plain theft of bitcoins by the miners. We do not consider attacks from any other groups. These protections apply to any peg system S that accepts cross-chain transfers over two proof-of-work blockchains. The protections will be defined either based on a security assumption or on the cost to attack (an assumption on the budget of the attacker). The protections  are ordered from strongest (1) to weakest (8), but a system may offer more than one protection. A system S may not be fully characterized by a combination of the described protections because a system could use different protections for peg-ins and peg-outs. Since peg-out is always the weaker sub-protocol, we’ll focus on peg-out security for all protocols presented in this section, as attackers would choose the weakest spot to attack. Also a system may require different assumptions for soundness and liveness, but in this categorization we focus on soundness. Also for the sake of simplicity we’re ignoring other complementary attacks on the network, such as the feasibility to isolate a node. Note that generally a double-spend attack does not cause a loss of block rewards to the attacker: if an attacker reverts a blockchain to privately create a new best chain, this new chain will pay rewards to himself, so only other miners’  rewards are lost. The only exception to this rule is the protection provided by Armadillo, or some (generally broken) consensus algorithms that score blocks by time of reception [1][2][3].

Since Bitcoin cannot evaluate other sidechain’s cumulative proof of work, we assume the  existence of some form of static or dynamic multi-signing group to sign peg-outs and receive peg-ins. However,  we ignore any attack that involves malicious holders of the multi-signature that receives the pegged coins. We assume key holders are 100% honest or that they run Hardware Security Modules (HSMs) that prevent them from accessing the private keys, as RSK does.

In the following table we compare RSK to other types of two way pegs, but modifying them to connect Bitcoin with a merge-mined sidechain. This helps to achieve a fair comparison of protocols.

The first protection “Unconditional security”, which means that under the rules of the protocol for S, double-spends cannot occur. The next is  “Computational infeasibility” (2), which represents an impossibility to double-spend on S on the assumption that the attacker cannot perform a difficult computational task. The next protection is “Bitcoin M.A.D”  (3). M.A.D. stands for mutual assured destruction. A protocol is protected by Bitcoin M.A.D if to perform a double-spend the attacker is forced to revert the mainchain, which would impact the mainchain native token price, and therefore the long term miner incentives to maintain the mainchain unharmed apply to the peg also. The same concept can be applied to the sidechain as in (5). The protection “Long Attack Awareness” (4) is when the network can detect in advance malicious actions of a colluding group of miners. RSK plus the Armadillo monitoring system has a cryptoeconomic variant of Long Attack Awareness: the attacker either reveals he is preparing an attack or needs to renounce the block rewards for the blocks he produces in private. The next protection is “Loss of Bitcoin block rewards” (7), which represent all cryptoeconomic systems based on SPV proofs where the attacker needs to mine blocks with a fake transaction to fool the system into unlocking coins in a chain that weren’t locked in the opposite chain. The current RSK peg protocol (with the Armadillo monitoring system) has this protection, and also XCLAIM and TBTC do. The other categories self-explain.

The SyncChain Design 

A SyncChain provides a security guarantee that is much stronger than that provided by cryptoeconomics. It provides unconditional security to peg-ins and peg-outs. With a SyncChain we can eliminate the double-spend risk, and therefore do not overstress the merge-mining network. In this white paper we we described the design of the SyncChain in all its variants. In this shorter blogspot we’ll present only the ideas behind SynChain and the simplest of its variants. All variants are based on three components: delayed dual-parenting, peg transaction linking and coinbase anchoring. The root idea behind SyncChain (dual-parenting) is sketched in one of our blog posts in 2016. The idea is that sidechain blocks must specify both a sidechain parent and a mainchain parent. The inherited state prior to the processing of the sidechain block corresponds to a state after both parents have been processed, and the reversal of any of the parents causes the reversal of the sidechain child block. But this technique cannot be used for a sidechain with a higher block rate than the mainchain, as a reversal of the mainchain block may cause a reversal of many sidechain blocks. A new form of entanglement is needed that supports higher block rates but does not suffer from long reversals.

Delayed Dual-Parenting

Dual-parenting is one technique of entangling the mainchain and the sidechain. The technique is based on having each sidechain block have two parents, one in the sidechain and the other on the mainchain. But we don’t use this technique as is, we use a variation of dual parenting that we call Delayed Dual-Parenting (DDP). First, to simplify our terminology, we’ll call the mainchain parent a “checkpoint” but the reader shouldn’t confuse a synchcain checkpoint with other checkpointing systems based on authorities [4][5]. With DDP, the checkpoint is set to lag by a number of blocks (K blocks on average) based both on timestamps and mainchain block confirmation count. For example, a realistic value for K is 3, forcing checkpoints to lag by an average of 30 minutes. The following diagram shows an example for K=3.

 

Delayed Dual-Parenting

As previously described, the problem with immediate entanglement is that the reversal of a Bitcoin block automatically causes the reversal of about 20 RSK blocks, which is not tolerable from a UX perspective, but more importantly it is a transaction settlement security risk. With the delayed checkpoint, the RSK blockchain is only reverted if more than K mainchain blocks are reverted. To simplify the explanations, throughout this blog post we’ll assume the RSK average block interval is 30 seconds and Bitcoin average block interval is 10 minutes. Then if the Bitcoin blockchain is reverted R blocks where R>K, then the RSK blockchain will be reverted (R-K)*20 blocks. In the following diagram we can see that there are no surprise removals in RSK if only a single Bitcoin block is reversed.

 

Reversal of a single Mainchain block does not cause reversal on the SyncChain

The minimum value for K is 1, which means that a block can only be checkpointed if it has one additional block for confirmation.

Dual Nodes

A SyncChain requires that each sidechain client runs both an instance of the mainchain node and the sidechain-specific node. The main reason we invented the SyncChain is to prevent an invalid Bitcoin blockchain branch to be presented to a SPV-based bridge contract as a valid SPV (header-only) chain, because a SPV proof can be hidden from the honest network, and that reduces M.A.D. tension. To maximize the tension, we want the transparency detect, judge and eventually punish miners as soon as they start mining block for an attack, and before the attack finishes. Therefore we must assure that whatever blocks the bridge accepts to validate a peg-in or peg-out, those blocks are fully exposed  (both header and transaction payload) and can those blocks can be included in the Bitcoin blockchain as defined by Bitcoin Core reference software. Therefore a SyncChain node should run the mainchain reference node, together with the sidechain-only node. In other words, a synchain node runs an instance of bitcoind, and an instance of rskj.

A user is still able to run only the sidechain-only node (rskj), but he will be unable to validate peg-ins and peg-outs. In that sense, it automatically becomes an SPV “lightweight” node, with the same security model as SPV clients get, as soon as there is a peg-in or peg-out transaction. 

To create a delayed dual-parent we need a Checkpoint Selection Algorithm (CSA). A CSA is a consensus algorithm that selects the mainchain checkpoint and validates if a checkpoint is correctly selected. A CSA must essentially base its decisions on the block timestamps. But block timestamps in Bitcoin do not reflect wall clock times and even less a global clock. A The SyncChain white paper presents two simple RTA algorithms (MedianTime11 and AdjustedTime), so we won’t discuss them again here. 

Checkpoints and Block Processing

In the sidechain block header the checkpoint is defined by a mainchain block number (checkPointBN) and a mainchain block hash (checkPointHash). It’s possible to use a reduced-size header of the hash digest to save space. 

Every sidechain node must run a mainchain node (bitcoind in case of RSK) to monitor the correctness of the checkpoints in RSK block headers. If the RSK checkpoint hash does not match with the Bitcoin block hash referenced by block number, then the RSK block is “temporarily invalid”. The RSK block could be reconsidered later if the Bitcoin best chain reorganizes.

Not every Bitcoin block will be a checkpoint: the checkPointBN values do not cover all blocks, and there will be gaps. When a block checkPointBN refers to a peg-in transaction in a Bitcoin block, or jumps over a peg-in transaction by skipping the block, then the RSK consensus dictates that the related RSK block MUST include a transaction sending a peg-in message to the bridge contract to release the associated coins pegged-in immediately. The consensus also mandates that the peg-in transactions take priority over the others, meaning that they precede them in the block. 

Peg Transaction Linking 

All Bitcoin peg-ins and peg-out transactions are linked together. This is done for several reasons. One is to avoid attacks where the attacker reorganizes the Bitcoin and RSK blockchains to double-spend funds from the peg multi-sig, where the attacker himself has pegged-in or out. Linking greatly reduces the attack surface. But a second reason relates to how peg-outs are secured,  and enables us to prove the infeasibility of peg-out double-spends. The following diagram depicts a peg-in and a peg-out for a federated sidechain such as RSK. The peg funds are protected by a federated multi-sig, and the parties that have the private keys of this multisig are called functionaries. In the chain shown, there are two additional internal transactions called link-in and link-out that we’ll explain later. The red line corresponds to a chain of references using “dummy” inputs/outputs. All transactions signed by functionaries are tied to this chain. Because each transaction consumes one dummy input and creates one dummy output, there is only one unspent transaction output at all times. We call this special UTXO the loken (short of link token). We use “loken chain” to refer to the chain of transactions that consume and create the loken. The value of the loken will be some small value above the Bitcoin dust limit.

The Locken Chain

Care must be taken when upgrading the federation functionaries by adding or removing members. This triggers, in RSK, a lengthy and forcibly delayed process where funds are automatically moved from an old federation multisig to a new one. We haven’t yet proposed a migration process adapted to a SyncChain, but we believe this can be done securely.

Peg-ins

The bridge smart contract, which controls all the peg-in and peg-out processes, automatically commands functionaries for the forwarding of the coins received in the peg-in transaction to a different UTXO, whose address can be the same or different from the one in the peg-in, but it is equally controlled by the same federation. This initial forwarding of coins received is performed in a Bitcoin transaction we call the link-in. The link-in transaction consumes the loken and creates a new loken. The following example diagram shows how a user-initiated transaction (“Peg-in Tx” in the diagram) in mainchain block 1 triggers actions from the bridge when the block 1 is checkpointed by sidechain block A. The first action is an initial wait period of 3 sidechain blocks, and afterward, in block B, the bridge commands the federation functionaries to sign and broadcast the Link-in transaction, which immediately consumes the peg-in funds, and move them to the final multi-signature peg address.

 

The peg-in process

The sidechain coins are released immediately in block A, but no peg out can occur until the link-in transaction is included in the mainchain. 

Peg-outs

We show in our previous article that a proof-of-work sidechain cannot provide full atomicity of peg-in and peg-outs without the collaboration of the miners in the peg in/out process. The attacker can revert alternatively the mainchain, then the sidechain and afterward the mainchain again, and finally succeed in keeping both the mainchain tokens and the sidechain tokens. Now we’ll show how cryptoeconomic protection can be achieved without the help of the miners, and how full unconditional protection can be achieved with the help of the miners.

We note that a fully federated sidechain system such as Liquid, possibly based on PBFT-type consensus cannot provide full atomicity of peg-outs because it has settlement finality. Once a transaction in Liquid is settled, even if Bitcoin reverts the sidechain won’t revert to match the net Bitcoin bestchain.

Peg-out Protocols

We found three different protocols to achieve a M.A.D. and unconditional guarantees, based on different assumptions to add to standard Nakamoto consensus. In the following sections we briefly describe each one.

• Peg-out for a More-Populous-Chain-Wins (MPCW) SyncChain
• Peg-out for T-Synchronized (TS) SyncChain
• Peg-out for a GHOST-CSC (not T-synchronized) SyncChain

In our white paper we discuss all three variants. In this article we’ll show only the TS SynChain. To move tokens back from an account in RSK to Bitcoin, an RSK transaction called a Peg-out Request is created which transfers the RBTC to the bridge smart-contract. In the following figure, this transaction has been included in the block labeled A. After a short number of RSK block confirmations (such as 3), the bridge creates a Link-out transaction Template containing placeholders for federation functionaries to insert their signatures. This template can use the Partially Signed Bitcoin Transaction (PSBT) standard. Then the bridge requests federation functionaries to sign it and this event is called a Link-out Request. This occurs in the RSK block B in the figure. The Link-out transaction must contain a special data output that comprises an OP_RETURN, the block hash for block A, and the block number of A. We call this data payload the sidechain checkpoint slot. This slot may contain one or more actual sidechain checkpoints. We note that sidechain checkpoints together with mainchain checkpoints produce reciprocal checkpointing references.

 

Peg-out Process

Once a majority of functionary signatures are collected for the link-out transaction, the transaction is broadcast and is expected to be included in the Bitcoin blockchain soon. In the figure, this occurs in Bitcoin block 4. The link-out transaction must be part of the loken chain (it must consume the loken, and create a new loken).  After the link-out transaction is included in a Bitcoin block 4, block 4 should be referenced by the checkpoint of an RSK block (or skipped by a checkpoint, which causes the same effect). The checkpoint to block 4 will usually be delayed approximately 30 minutes. In the figure, block 4 is referenced in RSK block C. Afterward the bridge will wait for some blocks (166 in the figure). After the waiting period is over, the bridge will create the Peg-out Transaction Template and ask federation functionaries to sign it. The peg-out transaction is the final transaction that actually pays back to the Bitcoin user the required amount. As all the rest peg and link transactions signed by the federation, it links into the loken chain. The peg-out transaction will be included in a Bitcoin block, and this occurs in block 11 of the figure. After approximately 30 minutes, it will be referenced by an RSK checkpoint, and the loken will be available for other link-in or link-out transactions. The whole peg-out process on average 2 hours 10 minutes, requires two rounds of federation signatures and produces two Bitcoin transactions. If a peg-in transaction is confirmed while a transaction that consumes a loken is waiting to be included in the mainchain, the peg-in will be queued. In fact, many link-in and peg-out transactions could be joined in a batch, having a single loken creation and destruction input/outputs.

Peg-out Security

The following sections some theoretical attacks and we show how the SyncChain resists them. The most important attack to any cryptocurrency accepting system is the double-spend. To attempt a double-spend, the attacker could try to revert RSK, revert Bitcoin or revert both. Currently RSK is merge-mined by between 35% and 50% of the Bitcoin miners. In this article we assume that RSK hashrate is lower than Bitcoin, and therefore if an attacker reverts Bitcoin, because of merged-mining, he also gets the chance to revert both chains. 

Double-spending Peg-outs by Reverting only RSK 

Reverting RSK seems to be the easiest path to double-spend, as we assume RSK’s hashrate is lower than Bitcoin’s. We’ve seen how peg-in transactions are synchronized, because RSK blocks depend on Bitcoin blocks. However, in the other direction, synchronization is not guaranteed. Therefore, for peg-outs we force a link-out transaction to occur on Bitcoin. The timestamp of the link-out transaction establishes a horizon that RSK cannot surpass without performing the corresponding peg-out request.

Nakamoto consensus establishes clear rules for every aspect of blockchain handling except for when a transaction is considered settled. This is left to each user, and the only guidance that is given is that the more block confirmations the less the probability of reversal. To guarantee the infeasibility of peg-out double-spends we must add to the Nakamoto Consensus in the sidechain a condition that must be met to accept transactions. First, we introduce a definition: A network node is T-synchronized if its local best chain is up T seconds behind the current local time. To build a SyncChain we need that the sidechain meets the following new condition: nodes only accept a transaction as settled if they are T-synchronized. We could also accept the transaction W if it is confirmed by a huge amount of cumulative difficulty, but we’ll use the simplest possible definition now. 

Because of the T-synchronization property, we can see that any attack that reverts the sidechain must add at least one sidechain block with timestamp past the timestamp of block C, where block 4 is checkpointed.  Therefore, as long as the time between block 4 and block C is greater than T, the attacker chain (on the sidechain) can never confirm transactions. This is assuming the node local time did was not reverted. 

Double-spending Peg-outs by Reverting Bitcoin and RSK (but replaying later the peg-out tx)

One possible way to perform a double-spend attack is to try to revert the Bitcoin blockchain prior to the link-out transaction, and at the same time revert the RSK blockchain prior to the peg-out-request, creating a new Bitcoin branch that has both the link-out and peg-out transactions, but at a much later block. For example, the attacker reverts 10 Bitcoin blocks, and mines another 10 blocks without peg transactions, and finally adds an 11th block containing both the link-out and the peg-out. Assuming dishonest rational miners, a 10 block reversal is approximately costs 1.5M USD (1), and therefore that would be maximum amount the peg-out transaction can transfer. But if we want not unconditional security, then we must do better with anchoring. With anchoring we can prevent the link-out transaction to move be moved into future blocks.

Peg-out Anchoring

The easiest way to anchor a transaction to a specific block would be by adding to Bitcoin a new opcode OP_CHECK_INPUT_BLOCK_HASH, which receives a block hash as argument in the stack and invalidates the block if the block hash given does not match the hash of the block where the input being spent was created. We don’t believe this new opcode would be accepted by the Bitcoin community because it may produce Bitcoins that are less fungible than others. An alternative opcode that can do the same trick is OP_CHECK_INPUT_BLOCK_TIME. This opcode would invalidate the transaction if the block corresponding to the input being spent has a timestamp higher than the opcode argument. In contrast, this opcode alters much less fungibility. However, without any new opcode, there is still a way to achieve the same result and that is by consuming in the peg-out transactions an output from a coinbase transaction that exists in a block B between the link-out and the peg-out transactions blocks. The peg-out transaction would be invalid if B is reverted, and the only way to remove the link-out would be to revert B. The downside is that because the coinbase transaction outputs have a 100-block maturity period, this binding introduces a 100-block delay for the peg-out. While the peg-out transaction won’t be able to be included before the 100-block period, the peg-out transaction can be signed and published much earlier and therefore the user has a very strong guarantee that the peg-out transaction will occur. To bind the peg-out to a coinbase, RSK can request that RSK merge-miners include an extra output paying an amount 1 satoshi (2) to a specific federation address, and that satoshi is consumed in the peg-out transaction.

Note 1: According to crypto51.app website.

Note 2: There is no need to overpass the “dust” limit because coinbase transactions are not forwarded over the network prior inclusion in a block.

Peg-out process with coinbase anchoring

Migrating RSK to a SyncChain

Although SyncChain provides many benefits over an SPV Sidechain, it is too early to say when and how RSK could transition to become a SyncChain. There are benefits but also there are migration risks. Coding, testing, simulations and security audits must validate each design decision. However having such a clean design that provides so many benefits both from usability and security is comforting. As soon as all the R&D stages have been concluded, we’ll open the discussion for a migration to a SyncChain, and hopefully, with the feedback of the RSK community, we may see the migration in 2020 or 2021. 

Summary

In this post we presented SyncChain, a new type of sidechain that enables a 32x reduction in the time of peg-in from 16 hours to 30 minutes. The time for peg-out can be reduced also from 16 hours to about 1.6 hours, if we keep a rate limiter so no more than 38 BTCs are transferred per hour. We also presented a variant that uses coinbase anchoring to provide unconditional peg-out security, with a peg-out time of 16 hours, which is less than what RSK currently requires with only cryptoeconomic security. We also proposed a new opcode OP_CHECK_INPUT_BLOCK_HASH for Bitcoin that enables peg-outs with unconditional security in a matter of hours and without any rate limiter. 

Even if the current RSK SPV peg could also achieve lower peg-out and peg-in block confirmations, if the merge-mining engagement increased, the SyncChain offers a lower number of confirmations for the same level of engagement. 

The synchain also provides other secondary benefits such as : 

1. It reduces the amount of code RSK runs in consensus in rskj: some of that code functionality is now provided directly by bitcoind. 
2. Depending on the protocol selected, it provides unconditional security or it forces an attack on RSK to become an attack on Bitcoin: the M.A.D. property in game theory.
3. It allows cross-address peg-ins, such as investing in a crowd-fund directly from Bitcoin

 The SyncChain also has some minor downsides. For example, SyncChain cannot provide short settlement finality. Considering pros and cons, SyncChain is certainly a superior protocol for Bitcoin sidechains.

 

References

[1] Ren Zhang and Bart Preneel. Publish or perish: A backward-compatible defense against selfish mining in bitcoin. In Cryptographers’ Track at the RSA Conference, pages 277–292. Springer, 2017

[2] A Proposal to Modify Satoshi Consensus to Enhance Protection Against 51% Attacks. A Penalty system for Delayed Block Submission.

https://www.horizen.global/assets/files/A-Penalty-System-for-Delayed-Block-Submission-by-Horizen.pdf

[3] Delaying chain reorgs.

 https://bitslog.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/

[4] Transaction Finality through Ledger Checkpoints (https://ieeexplore.ieee.org/document/8975825 or https://github.com/MuhammadNurYanhaona/checkpoint-paper/blob/master/checkpoint-paper-reviewed.pdf)

[5] Securing Proof-of-Work Ledgers via Checkpointing  (https://eprint.iacr.org/2020/173.pdf)