Author: Antoine Riard 2022-02-18 18:09:07
Published on: 2022-02-18T18:09:07+00:00
In late 2021, ZmnSCPxj proposed implementing CoinPools and similar constructions with `OP_TAPLEAFUPDATEVERIFY`. However, Jeremy pointed out the use of Merkle tree paths would require O(log N) hash revelations to reach a particular tapleaf, which would then delete itself after spending only a specific amount of funds. To avoid this, an alternative representation of promised outputs that would not require O(log N) revelations by avoiding the tree structure was proposed.This approach presents a factorial complexity and appears as an intractable problem for high-number of pool users. A solution for scaling Bitcoin would be to promise that some output can appear on-chain at some point in the future without requiring that the output is shown on-chain right now.A CoinPool is a way to commit to promised outputs, and any participant can unilaterally close the CoinPool, instantiating the promised outputs, in case something really bad happens. A statechain is a CoinPool hosted inside a Decker-Wattenhofer or Decker-Russell-Osuntokun construction. Any participant can unilaterally shut it down, exposing the state of the inner CoinPool. A channel factory is a statechain where the promised outputs are not simple 1-of-N but instead 2-of-2.To prevent signature replay, each update of an updateable scheme like CoinPool should use a different pubkey for each participant for each state. The advantage of OP_EVICT is reduced number of eviction transactions, as multiple evictions, plus the revival of the CoinPool, can be put in a single transaction. However, it has the disadvantage relative to `OP_TLUV` of requiring point operations. It may be possible to design an `OP_CSFS` variant that allows batch validation, such as by extending the virtual machine with an accumulator for pending signature validations.The author proposes a way to commit to exposing a set of promised outputs without imposing any ordering during commitment. The proposed mechanism, called `OP_EVICT`, allows for an N-of-N With Eviction construction where, when a participant in the N-of-N is offline, but the remaining participants want to advance the state of the construction, they instead evict the offline participant, creating a smaller N-of-N where all participants are online and continue operating.The `OP_EVICT` opcode accepts a variable number of arguments and is used to attest to each individual's promised output. This eviction scheme proposed here is either all participants agree on some transfer, or give me my funds and the rest can go play with their funds however they want. The signature that commits to a promised output is then the agreement that the particular participant believes they are entitled to a specific amount.A "pure SCRIPT contract" is a Taproot contract where the keyspend path is not desired, and the contract is composed of Tapscript branches. The proposed `OP_EVICT` opcode is meant to optimize the eviction of uncooperative participants in a Scriptless Script contract. The technique involves using the sum of N-of-N participants as the Taproot internal pubkey, ensuring none of them can unilaterally sign an alternate spend.This approach enables cooperative signing of the promised output while keeping it in an `OP_EVICT`-enforced UTXO. Signature Half-Aggregation is possible with Schnorr signatures, where the s components of multiple signatures are summed together, but the R components are not. However, there are no security proofs that half-aggregation is safe and should be approached with caution.`OP_EVICT` is in direct competition with `OP_TLUV`, having largely the same design goal. Its advantage is the reduced number of eviction transactions, as multiple evictions plus the revival of the CoinPool can be put in a single transaction. On the other hand, it has the disadvantage relative to `OP_TLUV` of requiring point operations. While it may be possible to implement `OP_EVICT` in terms of other opcodes like `OP_CSFS`, it would require multiple opcodes and not allow for batch validation.Overall, `OP_EVICT` offers a new approach to optimizing Scriptless Script contracts by enabling cooperative signing of promised outputs while reducing the number of eviction transactions required. The use of Schnorr signatures allows for signature half-aggregation, although its security is yet to be fully proven. The opcode is in direct competition with `OP_TLUV` but offers unique advantages and disadvantages.
Updated on: 2023-06-15T17:03:45.605448+00:00