Author: Erik Aronesty 2022-02-18 13:53:09
Published on: 2022-02-18T13:53:09+00:00
In a bitcoin-dev post, ZmnSCPxj proposes `OP_EVICT` as an alternative to `OP_TAPLEAFUPDATEVERIFY`. The proposed opcode, OP_EVICT, is a new Taproot opcode that allows for the eviction of participants in a CoinPool or offchain variant. ZmnSCPxj suggests that a solution for scaling Bitcoin would be to promise that some output can appear on-chain at some point in the future without requiring it to be shown right now. In this way, transactional cut-through can be performed on spends of promised outputs, without expensive on-chain activity. The use of Merkle tree paths in `OP_TLUV` would require O(log N) hash revelations to reach a particular tapleaf, which is why ZmnSCPxj started thinking about alternative representations of sets of promised outputs that avoid the tree structure. ZmnSCPxj also introduces the concept of "N-of-N with Eviction" construction, which avoids the not-your-keys-not-your-coins problem of K-of-N constructions and provides a way to advance the state without the full participant set being online.To commit to each of the individual promised outputs, each participant signs their own expected promised output, and shares the signature for their promised output. When a participant is to be evicted, the other participants take the signature for the promised output of the to-be-evicted participant and show it on-chain. Then, the on-chain mechanism should then allow the rest of the funds to be controlled by the N-of-N set minus the evicted participant.Finally, ZmnSCPxj proposes the `OP_EVICT` opcode, which accepts a variable number of arguments. The stack top is either the constant `1` or an SECP256K1 point. The next stack item is a number equal to the number of outputs that were promised and which will now be evicted. The next stack items will alternate between a number indicating an output index and a signature for that output. After that is another signature, which is checked using `OP_CHECKSIG` semantics.The security of this scheme is conjectured to be secure as long as key cancellation is protected against. To prevent signature replay, each update of an updateable scheme like CoinPool et al should use a different pubkey for each participant for each state. The eviction scheme proposed here is either all participants agree on some transfer or give me my funds and the rest of you can all go play with your funds however you want. It is possible to batch-validate, and as OP_EVICT must validate at least two signatures, it makes sense to use batch validation for OP_EVICT. Schnorr signatures allow for third-party half-aggregation, where the s components of multiple signatures are summed together, but the R components are not. Using half-aggregation can remove at least 32 weight units, but it depends on half-aggregation being secure.OP_CTV cannot be used as a direct alternative to OP_EVICT as it does other things than this opcode. This opcode seems largely in direct competition with OP_TLUV, with largely the same design goal. Its advantage is reduced number of eviction transactions, as multiple evictions, plus the revival of the CoinPool, can be put in a single transaction. It has the disadvantage relative to OP_TLUV of requiring point operations. It may be possible to implement OP_EVICT in terms of OP_TX/OP_TXHASH, OP_CSFS, and a point-subtraction operation. However, OP_EVICT allows for the trivial implementation of batch validation, whereas we expect multiple OP_CSFS to be needed to implement this, without any possibility of batch validation.
Updated on: 2023-06-15T17:00:05.269331+00:00