The proposed use case for the ANYSCRIPT part of APOAS explicitly doesn't commit to amount, so I'd also assume it not be re-added or at least be able to be opened out.
On Sat, Apr 30, 2022, 4:47 AM Nadav Ivgi via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi darosior, > > It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY > behaviour and without covering the spent input index) has some interesting > uses for cases where the covenant only needs to restrict a single output > (so useful for e.g. vaults or spacechains, but not for batch channels or > congestion control). > > For example in the vault use-case, it makes it possible to bump fees on > the unvault tx by adding more inputs and a change output, as well as > unvault multiple vaulted outputs in a single transaction. > > For spacechains, it makes it possible to add the spaceblock hash OP_RETURN > and pay fees directly in the tx chain, instead of having to use an > additional tx to prepare an output that gets spent in the tx chain (see > the diagram in [0]). > > > via `sha_sequences` and maybe also `sha_amounts` > > CTV does not commit to the input amounts. This has some practical > implications: > > 1. If it is committed, sending an even slightly incorrect amount will make > the covenant-encumbered spend path unusable. > > With CTV, sending a slightly lower amount results in slightly lower fees, > while any extra gets spent/burned on fees. The covenant spend path only > becomes unusable if the amount is too low to cover for the outputs (+relay > fee for it to also be standard). > > 2. The ability to allow for additional inputs with unknown amounts makes > it possible to fee-bump the covenant spending transaction (with whole utxos > and no change). You can have one tapleaf for spending the covenant output > alone, and another one for attaching an extra fee input to it. > > This also makes it possible to resolve the under-payment issue described > in (1), by adding an input that covers the original intended amount. > > So my suggestion would be to either not cover `sha_amounts` in the msg > hash, or to make it optional behind a flag. > > shesek > > [0] https://github.com/fiatjaf/simple-ctv-spacechain > > On Fri, Apr 22, 2022 at 2:23 PM darosior via bitcoin-dev < > bitcoin-dev@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
