Published on: 2022-09-30T02:00:30+00:00
In a recent email exchange, Antoine Riard and Jeremy Rubin discussed the use of covenant-based drivechain designs and recursive-covenant "embedded" sidechains as a solution to double-spending issues. They explored the possible security bounds and impacts on funds, along with variants of pegging mechanisms that influence the soundness of game-theory backing up functionaries' execution.Riard shared an entry he started for the ZmnSCPxj design on Github. In his post, Rubin showed techniques that could accomplish something similar using ANYPREVOUT with a one-time trusted setup ceremony. Rubin presented general techniques that could be applied to many different types of covenants. He started by building a Peano counter graph, which was a simple 1 to 5 counter that had inc / dec. To handle arbitrary deposits/withdrawals, Rubin suggested dividing the deposit amount into a counter UTXO per bit. To enforce that only one vote per block mined is allowed, Rubin ensured that all signatures set the input sequence to 1 block. When a counter reaches the Nth state, it represents a certain amount of accumulated work over a period where progress was agreed on for some outcome. Rubin also discussed several setup variants, including xpubs, single-party pre-signing, MuSig Multi-Party, unaggregated multi-party, and soft forking away trust. The advantage of such an optimization is theoretically nice because it means that only the non-destructuring recursive part of the computation is subject to the one-time-setup trust assumption, which might be of use in various other protocols.The email thread discusses a covenant model that relies on one-time setup and minimizes costs until the graph is a Directed Acyclic Graph (DAG), consisting of one or more components. The model defines covenants as a set of sets of transaction intents, potentially recursive or co-recursive, and a verifier generator function that generates a function that accepts an intent that is any element of one member of the family of intents and a proof for it and rejects others. It also includes a prover generator function that generates a function that takes an intent that is any element of one member of the family and some extra data and returns either a new prover function, a finished proof, or a rejection if not a valid intent. The covenant is verified under certain assumptions, including multi-sig covenant with at least 1-n honesty, Sha256 collision resistance, Discrete Log Hardness, and a SGX module being correct. In addition, there is perfect impedance match between the Prover, Verifier, and a set of intents. Composability is also possible as the Terminal State can pay out into a pre-specified covenant from any other family of covenants.The article discusses the concept of Terminal States/Thresholds in blockchain technology. These states represent accumulated work over a period and should have viable state transitions. The author suggests having the money sent to an OP_TRUE output, which would prevent the miner from swerving the car to a different output. This approach is not exactly like Drivechains but similar. The "ultimate threat" in Drivechains is everyone upgrading sidechain rules to mainchain rules. Still, there are concerns about using this approach in Spookchains. Alternatively, the administrator key/federation with a block timeout could be used for convenience, similar to Blockstream's separation of block-signing functionaries from money-keeping functionaries.The article presents a technique for creating drivechains with recursive covenants using ANYPREVOUT and a trusted setup ceremony. The Peano counter graph is used in this process to build a simple 1 to 5 counter that has an inc/dec feature, using a key instead of sha-256. For each Ki, when i < N in Rule Increment, the first signature should cover specified inputs, while for each Ki, when i > 1 in Rule Decrement, the second signature should cover the same inputs. To handle arbitrary deposits or withdrawals, the protocol can be instantiated for every amount or divided using base 2 or another base. Splitting and joining can also be accomplished by pre-signing. All signatures set the input sequence to one block to enforce that only one vote per block is allowed. When a counter reaches the Nth state, there should be some viable state transition at this point, such as sending the money to an OP_TRUE output that the miner incrementing that state is responsible for following the rules of the spookchain. From any K^i_1 state, the transaction transitioning to K^i_2 can be treated as “special,” and the OP_RETURN output type can be used to commit to the outputs that must be created when the Terminal State is reached.The article clarifies the issue of "what is being voted on." Instead of using randomly generated keys for each state, xpubs can be defined and derived for each state/satoshi amount.
Updated on: 2023-08-02T07:23:19.347457+00:00