On Tue, Feb 15, 2022 at 1:57 PM Jeremy Rubin <jeremy.l.ru...@gmail.com> wrote:
> Hi Rusty, > > Please see my post in the other email thread > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html > > The differences in this regard are several, and worth understanding beyond > "you can iterate CTV". I'd note a few clear examples for showing that "CTV > is just as powerful" is not a valid claim: > > 1) CTV requires the contract to be fully enumerated and is non-recursive. > For example, a simple contract that allows n participants to take an action > in any order requires factorially many pre-computations, not just linear or > constant. For reference, 24! is about 2**80. Whereas for a more > interpretive covenant -- which is often introduced with the features for > recursion -- you can compute the programs for these addresses in constant > time. > 2) CTV requires the contract to be fully enumerated: For example, a simple > contract one could write is "Output 0 script matches Output 1", and the set > of outcomes is again unbounded a-priori. With CTV you need to know the set > of pairs you'd like to be able to expand to a-priori > 3) Combining 1 and 2, you could imagine recursing on an open-ended thing > like creating many identical outputs over time but not constraining what > those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output > 2. > > I think for your point the inverse seems to hold: for the limited > situations we might want to set up, CTV often ends up being sufficient > because usually we can enumerate all the possible outcomes we'd like (or at > least find a mapping onto such a construction). CTV is indeed very > powerful, but as I demonstrated above, not powerful in the same way > ("Complexity Class") that OP_TX or TXHASH might be. > Just to be clear, if OP_TXHASH is restricted to including the flags for the values to be hashed (at least for OP_TXHASH0), we don't appear to enter recursive covenant territory, as long as we remain without OP_CAT. > At the very least we should clearly understand *what* and *why* we are > advocating for more sophisticated designs and have a thorough understanding > of the protocol complexity we are motivated to introduce the expanded > functionality. Further, if one advocates for TX/TXHASH on a featureful > basis, it's at least a technical ACK on the functionality CTV is > introducing (as it is a subset) and perhaps a disagreement on project > management, which I think is worth noting. There is a very wide gap between > "X is unsafe" and "I prefer Y which X is a subset of ''. > I'm certainly of the opinion we should have some feature to enable the commitment of outputs. It seems quite useful in various protocols.
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
