rich1.0Nadav Ivgi [ARCHIVE] (npub1f2…ydpll)https://yabu.me/npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpllnjumphttps://yabu.me📅 Original date posted:2022-04-25 📝 Original message:darosior via bitcoin-dev wrote: > i doubt CTV is necessary nor sufficient for this I would be interested to hear more on this. Is it not necessary because you can exchange and store pre-signed transactions instead? What purpose is it not sufficient for? There are some vault designs out there that are able to achieve interesting properties with CTV, like James O'Beirne's simple-ctv-vault: https://github.com/jamesob/simple-ctv-vault (the basic design expressed in Minsc: https://min.sc/nextc/#gist=001cf1fcb0e24ca9f3614c4db9bfe57d:4) On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > I would like to know people's sentiment about doing (a very slightly > tweaked version of) BIP118 in place of > (or before doing) BIP119. > > SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for > over 6 years. It presents proven and > implemented usecases, that are demanded and (please someone correct me if > i'm wrong) more widely accepted than > CTV's. > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made > optional [0], can emulate CTV just fine. > Sure then you can't have bare or Segwit v0 CTV, and it's a bit more > expensive to use. But we can consider CTV > an optimization of APO-AS covenants. > > CTV advocates have been presenting vaults as the flagship usecase. > Although as someone who've been trying to > implement practical vaults for the past 2 years i doubt CTV is necessary > nor sufficient for this (but still > useful!), using APO-AS covers it. And it's not a couple dozen more virtual > bytes that are going to matter for > a potential vault user. > > If after some time all of us who are currently dubious about CTV's stated > usecases are proven wrong by onchain > usage of a less efficient construction to achieve the same goal, we could > roll-out CTV as an optimization. In > the meantime others will have been able to deploy new applications > leveraging ANYPREVOUT (Eltoo, blind > statechains, etc..[1]). > > > Given the interest in, and demand for, both simple covenants and better > offchain protocols it seems to me that > BIP118 is a soft fork candidate that could benefit more (if not most of) > Bitcoin users. > Actually i'd also be interested in knowing if people would oppose the > APO-AS part of BIP118, since it enables > CTV's features, for the same reason they'd oppose BIP119. > > > [0] That is, to not commit to the other inputs of the transaction (via > `sha_sequences` and maybe also > `sha_amounts`). Cf > https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message > . > > [1] https://anyprevout.xyz/ "Use Cases" section > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/cd6fa22e/attachment-0001.html>