rich1.0Jeremy Rubin [ARCHIVE] (npub1xu…fzef0)https://yabu.me/npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0njumphttps://yabu.me📅 Original date posted:2022-04-26 📝 Original message:I can't find all of my earlier references around this, I thought I made a thread on it, but as a reminder, my thoughts for mild tweaks to APO that make it a bit less hacky are as follows: - Remove OP_1 key punning and replace it with OP_GENERATOR and OP_INTERNALKEY (maybe OP_EXTERNALKEY too?). The key punning is useful generically, because I may want to reuse the internal key in conjunction with a script path in some circumstances. - Add an additional sequence field that is specific to a signature with no other consensus meaning, so APO can be used with absolute timelocks. For example, this makes it impossible for more than one ratchet to be aggregated within a single transaction under any circumstance if their sequences differ (not sure this is a good example, but an example nonetheless). - Replace tagged keys for APO with either a Checksig2 or a separate feature flag that enables or disables APO behavior so that we can have programmatic control over if APO is allowed for a given key (e..g., OP_IF <N> CSV DROP CHECKSIG2 OP_ELSE CHECKSIG OP_ENDIF enables APO to be turned on after a certain time, perhaps for a pre-approved backup transaction). Overall, this would make eltoo ratchets look something like this: <sig> <seq> OP_1 OP_INTERNALKEY OP_CHECKSIG2VERIFY <N> OP_GREATERTHAN where checksig2 leaves seq on the stack which can be used to enforce the ratchet. and covenants like: <sig> OP_1 OP_1 OP_GENERATOR OP_CHECKSIG2VERIFY On Fri, Apr 22, 2022 at 4:23 AM 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/20220426/8de4425a/attachment-0001.html>