<oembed><type>rich</type><version>1.0</version><title>darosior [ARCHIVE] wrote</title><author_name>darosior [ARCHIVE] (npub1pj…x22xp)</author_name><author_url>https://yabu.me/npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xp</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2022-04-22&#xA;📝 Original message:I would like to know people&#39;s sentiment about doing (a very slightly tweaked version of) BIP118 in place of&#xA;(or before doing) BIP119.&#xA;&#xA;SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for over 6 years. It presents proven and&#xA;implemented usecases, that are demanded and (please someone correct me if i&#39;m wrong) more widely accepted than&#xA;CTV&#39;s.&#xA;&#xA;SIGHASH_ANYPREVOUTANYSCRIPT, if its &#34;ANYONECANPAY&#34; behaviour is made optional [0], can emulate CTV just fine.&#xA;Sure then you can&#39;t have bare or Segwit v0 CTV, and it&#39;s a bit more expensive to use. But we can consider CTV&#xA;an optimization of APO-AS covenants.&#xA;&#xA;CTV advocates have been presenting vaults as the flagship usecase. Although as someone who&#39;ve been trying to&#xA;implement practical vaults for the past 2 years i doubt CTV is necessary nor sufficient for this (but still&#xA;useful!), using APO-AS covers it. And it&#39;s not a couple dozen more virtual bytes that are going to matter for&#xA;a potential vault user.&#xA;&#xA;If after some time all of us who are currently dubious about CTV&#39;s stated usecases are proven wrong by onchain&#xA;usage of a less efficient construction to achieve the same goal, we could roll-out CTV as an optimization.  In&#xA;the meantime others will have been able to deploy new applications leveraging ANYPREVOUT (Eltoo, blind&#xA;statechains, etc..[1]).&#xA;&#xA;&#xA;Given the interest in, and demand for, both simple covenants and better offchain protocols it seems to me that&#xA;BIP118 is a soft fork candidate that could benefit more (if not most of) Bitcoin users.&#xA;Actually i&#39;d also be interested in knowing if people would oppose the APO-AS part of BIP118, since it enables&#xA;CTV&#39;s features, for the same reason they&#39;d oppose BIP119.&#xA;&#xA;&#xA;[0] That is, to not commit to the other inputs of the transaction (via `sha_sequences` and maybe also&#xA;`sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message.&#xA;&#xA;[1] https://anyprevout.xyz/ &#34;Use Cases&#34; section</html></oembed>