Generalized covenant to implement side chains embedded into the bitcoin block chain

Summary:

In a recent bitcoin-dev post, Tamas Blummer introduced the concept of a generalized covenant. He demonstrated this concept using a more generic use-case. The covenant would put a coin under the alternative control of a Transfer and Exit key together with the script in control of the current owner. Additional transaction level validations of transactions spending input with covenants apply. If the exit key is owned by a trusted arbiter other than the federation governing the unchained platform then one has the option to cut losses at some point by presenting the arbiter a chain of valid transactions and asking to sign the exit. The result is a federated side chain embedded into the Bitcoin block chain. The transfer and exit signatures could be threshold signatures of a federation, whereby members decide if the proposed transfer transaction complies with whatever unique rules they impose. Participants in the unchained platform would also be interested to regularly snapshot the economic effect of offchain transactions with cut-through transactions as such cut-through shortens the chain of transactions they would need to get on-chain if choosing the exit without consent of the federation governing the transfers. The most important question for someone who trusts his coins to some unchained platform is probably the question of how exit is guaranteed if one is unhappy with what one gets.ZmnSCPxj suggests that covenants for some kind of debt tool may be mildly interesting and an appropriate solution. However, he wonders about this particular use-case. It seems to him that, as either the `Transfer` signers or `Exit` signers are always involved, that the `Transfer` signers can be constrained so as to ensure that the rules are followed correctly, without requiring that covenants be used on the Bitcoin layer. The "sidechain" here is not a sidechain; the "sidechain" transaction graph is published on the Bitcoin blockchain. Instead, the `Transfer` signers simply validate some smart contract, most likely embedded as a pay-to-contract in the `pk(Alice)`/`pk(Bob)` public keys, and ensure that the smart contract is correctly executed. In that case, it may be useful to consider Smart Contracts Unchained.

Updated on: 2023-06-13T20:00:07.485237+00:00