{"type":"rich","version":"1.0","title":"Nadav Ivgi [ARCHIVE] wrote","author_name":"Nadav Ivgi [ARCHIVE] (npub1f2…ydpll)","author_url":"https://yabu.me/npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpll","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-04-25\n📝 Original message:darosior via bitcoin-dev wrote:\n\n\u003e CTV advocates have been presenting vaults as the flagship usecase.\nAlthough as someone who've been trying to\n\u003e implement practical vaults for the past 2 years i doubt CTV is necessary\nnor sufficient for this (but still\n\u003e useful!), using APO-AS covers it. And it's not a couple dozen more\nvirtual bytes that are going to matter for\n\u003e a potential vault user.\n\nSome potential vault users looking to store funds for long time periods\n(say of decades) might have quantumphobia and prefer to avoid Taproot for\nthat reason.\n\nOne of the arguments presented for not using pubkey hashes in Taproot is\nthat quantumphobic people could choose to continue using non-Taproot\noutputs. Making a feature that's targeted for long-term cold-storage vaults\navailable on Taproot only might be less ideal in that view.\n\nCheers\nshesek\n\nOn Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I would like to know people's sentiment about doing (a very slightly\n\u003e tweaked version of) BIP118 in place of\n\u003e (or before doing) BIP119.\n\u003e\n\u003e SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for\n\u003e over 6 years. It presents proven and\n\u003e implemented usecases, that are demanded and (please someone correct me if\n\u003e i'm wrong) more widely accepted than\n\u003e CTV's.\n\u003e\n\u003e SIGHASH_ANYPREVOUTANYSCRIPT, if its \"ANYONECANPAY\" behaviour is made\n\u003e optional [0], can emulate CTV just fine.\n\u003e Sure then you can't have bare or Segwit v0 CTV, and it's a bit more\n\u003e expensive to use. But we can consider CTV\n\u003e an optimization of APO-AS covenants.\n\u003e\n\u003e CTV advocates have been presenting vaults as the flagship usecase.\n\u003e Although as someone who've been trying to\n\u003e implement practical vaults for the past 2 years i doubt CTV is necessary\n\u003e nor sufficient for this (but still\n\u003e useful!), using APO-AS covers it. And it's not a couple dozen more virtual\n\u003e bytes that are going to matter for\n\u003e a potential vault user.\n\u003e\n\u003e If after some time all of us who are currently dubious about CTV's stated\n\u003e usecases are proven wrong by onchain\n\u003e usage of a less efficient construction to achieve the same goal, we could\n\u003e roll-out CTV as an optimization.  In\n\u003e the meantime others will have been able to deploy new applications\n\u003e leveraging ANYPREVOUT (Eltoo, blind\n\u003e statechains, etc..[1]).\n\u003e\n\u003e\n\u003e Given the interest in, and demand for, both simple covenants and better\n\u003e offchain protocols it seems to me that\n\u003e BIP118 is a soft fork candidate that could benefit more (if not most of)\n\u003e Bitcoin users.\n\u003e Actually i'd also be interested in knowing if people would oppose the\n\u003e APO-AS part of BIP118, since it enables\n\u003e CTV's features, for the same reason they'd oppose BIP119.\n\u003e\n\u003e\n\u003e [0] That is, to not commit to the other inputs of the transaction (via\n\u003e `sha_sequences` and maybe also\n\u003e `sha_amounts`). Cf\n\u003e https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message\n\u003e .\n\u003e\n\u003e [1] https://anyprevout.xyz/ \"Use Cases\" section\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220425/598ecaae/attachment.html\u003e"}