Author: ZmnSCPxj 2022-02-18 02:45:23
Published on: 2022-02-18T02:45:23+00:00
In late 2021, aj proposed OP_TAPLEAFUPDATEVERIFY to implement CoinPools and similar constructions. However, Jeremy observed that it would require O(log N) hash revelations to reach a particular tapleaf due to the use of Merkle tree paths and suggested utilizing OP_CTV trees instead. A solution for scaling Bitcoin could be to promise that an output can appear on-chain in the future without requiring that the output be shown on-chain right now. A CoinPool is a way to commit to promised outputs while a statechain is a CoinPool hosted inside a Decker-Wattenhofer or Decker-Russell-Osuntokun construction. Similarly, a channel factory is a statechain with 2-of-2 channels. The base CoinPool usage should be enough as other mechanisms (OP_CTV+OP_CSFS, SIGHASH_NOINPUT) can be used to implement statechains and channels and channel factories.An issue with using an N-of-N construction is that if any single participant is offline, the construction cannot advance its state. This has led to some people proposing to instead use K-of-N once N reaches much larger than 2 participants for CoinPools/statechains/channel factories. However, even so, K-of-N still requires that K participants remain online. Therefore, an OP_EVICT scheme is proposed to deal with offline participants.The proposal introduces a new opcode, OP_EVICT, which enables the eviction of a participant from an updateable scheme like CoinPool. The eviction will force the owned funds of the evicted participant to be instantiated. To prevent signature replay, each update of an updateable scheme should use a different pubkey for each participant for each state. The eviction scheme proposed here is that 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.A "pure SCRIPT contract" is a Taproot contract where the keyspend path is not desired, and the contract is composed of Tapscript branches. In such a case, the expected technique would be for the contract participants to agree on a NUMS point where none of the participants can know the scalar behind the point, and to use that as the internal Taproot pubkey.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. This half-aggregation is third-party, meaning someone without any knowledge of any private keys can simply sum the s components of multiple signatures. Using half-aggregation can remove at least 32 weight units, and each additional promised output being evicted is another signature whose s can be added to the sum.OP_CTV does other things than this opcode, and cannot be used as a direct alternative. 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.
Updated on: 2023-05-22T17:34:19.846473+00:00