Ideas on how to construct sidechains for chains that have covenant capabilities

covenant-based-sidechains.md

Note: Throughout this paper all references to covenants should be interpreted to refer to generalized covenants, in opposition to the heavily restricted covenants such as the one proposed in OP_SECURETHEBAG & Co.

Drivechains

Drivechains would be easily implementable if covenants are possible, as they would enable the creation of a 2-way peg that would be enforced at the transaction level through scripts that would force the funds being withdrawn from the sidechain to be sent through a chain of N transactions, each one of these being in a different block. More specifically, this would be implemented by creating N scripts that would contain an integer constant and would only be spendable to another copy of the same script with the constant increased or decreased by one, with the exception of the script where the constant reaches the value N, in which case the UTXO would be spendable only to a specific address provided in the beginning of the process. Furthremore, these scripts would prevent the possibility of several of them being chained in the same block through the use of OP_CSV.

Thus the protocol would look like this:

1. Users that want to peg money into the drivechain would send their funds to address_X. address_X's script would only allow the spending of coins to a ScriptPubKey that would follow the template DCScript(any_address, 1), where any_address is any bitcoin address
2. Users that then want to retrieve money from the sidechain would start that process by creating a UTXO that would transfer some of the funds in address_X to an address created by computing DCScript(our_address, 1) where our_address is an address that would be spendable on a payout to the group of users that created this request (enforced through covenants)
3. Users would need to start sending transactions spending UTXOs locked in DCScript(our_address, i) to DCScript(our_address, i+1) until reaching DCScript(our_address, N) at which point they could finally send the funds to our_address. The rationale behind drivechain also applies here, compelling miners to monitor these withdrawals and make sure that they are legal.
4. The funds could also be transferred from DCScript(our_address, i) to DCScript(our_address, i-1) and from DCScript(our_address, 1) back to adress_X, reversing the process. Users along with miners may want to do that in order to prevent an illegal withdrawal.

Pseudocode of DCScript(address_arg, i):

OP_CSV 1 //Prevent several scripts from being chained in the same block
IF i <= 0 && output.address == address_X:
  SUCCEED
IF i >= N && output.address == address_arg:
  SUCCEED
IF output.address == DCScript(address_arg, i+1) || output.address == DCScript(address_arg, i-1):
  SUCCEED
FAIL

Alternative scheme: Creating something like that in the current state of Bitcoin is possible through the use of a trusted setup that would create transactions spending from the multisig associated with DCScript(our_address, i) to the multisigs of DCScript(our_address, i+1) and DCScript(our_address, i-1) but such an scheme has quite a lot of problems, among them the fact that the number of transactions that would need to be created in order to recreate the protocol is infinite (this can somewhat solved by changing the protocol slightly) and that the set of possible addresses to use as our_address must be finite and picked in the trusted setup phase.

Covenants based on SIGHASH_NOINPUT/ANYPREVOUTS would remove the need for a trusted setup and infinite transactions, but the set of possible addresses where the money could be sent would remain finite.

SPV-based trustless sidechains

Given that covenants make it possible to extend Bitcoin Script into a turing complete language (loops can be implemented across transactions) it is also possible to do away with the drivechains and verify SPV proofs directly inside Script. This has clear benefits but the main problem is that, because now fund redeeming is gated by proof-of-work and SPV proofs don't verify block validity, this makes it impossible to use Blind Merged Mining, as it's trivial to create an valid spv proof of an invalid block.

Nevertheless, it's possible to just use normal mining or classic merged mining and the scheme would work, with the only caveats being that you'd need miners to provide PoW for your chain and it's quite probable that it may be more profitable for miners to steal all the money locked in the sidechain than to receive the mining rewards from it.

Fraud-proofs?

A good solution to several of the problems that arise in this area would be mechanisms that guarantee the validity of blocks, such as:

• Fraud proofs
• Rollups, such as the zero-knowledge-proof ones used in ETH
• Truebit verification games

The main problem with using these is that any implementation based on Script will be extremely inefficient, thus a Script-friendly verification mechanism is needed.

Note: See bitcoincovenants.com for a survey of methods that can be used to construct covenants in Bitcoin-like cryptocurrencies.