Hi Jacob,
I think you are a bit confused about how CTV and (tweaked) APO covenants
compare. Both would commit to the
same template, so one isn't "safer" than the other. Just more efficient in how
it commits to the template.
Replies on the specifics inline.
> While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS
> in lieu of CTV in the short-term (given the additional benefit of enabling
> Eltoo), there's a point to add in favour of CTV (or similar) in the long-term
> beyond as an optimisation.
In the long term, we'd hopefully have more powerful covenants to enable more
interesting applications. At this
point CTV would be an optimisation for these covenant constructions instead of
an APO one.
My request for feedback was more about the short term, where some are
requesting the activation of CTV to
start playing with covenants before we settle on the way forward to more useful
covenant. Not that i'm in
favour of it, but if it gains sufficient traction then i believe there is a
case for instead doing a tweaked
APO that would optionally commit to the input index, nSequences, etc..[0] I
think this addresses the technical
debt concerns of CTV once we have more interesting covenants, as no covenant
can entirely emulate a signature
hash type.
> With APOAS-based covenants, the signature message algorithm is tied to both
> the covenant commitment and transaction validation. Coupling these things
> introduces a trade-off between safety and flexibility with covenant-based
> applications.
What do you mean "tied to the transaction validation"? To me "transaction
validation" is what a node does to
check whether a block is valid, but you probably mean something else here.
With APOAS-based covenants, the signature message *is* the covenant commitment.
I don't see how it is coupled
to anything else. I also don't see how it could ever differ in safety or
flexibility with another
hashed-template approach (CTV) if the template is the same.
> E.g. the maximally safe and restricted covenant commits to all inputs and
> outputs of the transaction (using SIGHASH ALL). However, a less restricted
> covenant commits to, for example, a single input and a single output (using
> ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction
> malleability and signature replay.
Indeed the APO approach is more flexible as sighash types may be combined. You
can opt-in to more
malleability. I don't think it's a bad thing. Now, sure, the commitment may be
replayed, but it's inherent to
any commitment that doesn't commit to the prevout (whether it is CTV or APO, or
any other type of templated
covenant that you'd place in the ScriptPubKey) otherwise you'd have a circular
hash dependency.
If you are talking about the "half spend" by which two coins with the same
covenant get spent in the same
transaction, then committing to the input index fixes this. Interestingly the
instance you give *does* commit
to the input index without any tweak to the current APO proposal.
> If instead we separate the covenant commitment from the signatures to
> validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we
> by-pass this trade-off.
CTV doesn't "separate the signature and the commitment", it doesn't need a
signature. Sure one can be added to
further restrict a spending path, but it isn't necessary since the transaction
is pre-defined and can't be
malleated. It also sounds like you imply the APO covenant is using a "real"
signature. It's not. The pubkey
may well be G. The signature is just a roundabout way to access the hash. So if
you wanted to have, say, a
covenant only available to a participant you'd go the same way with either CTV
or APO covenants:
<covenant sig> <0x01 G> OP_CHECKSIGVERIFY <Alice pubkey> OP_CHECKSIG
<tx hash> OP_CTV OP_VERIFY <Alice pubkey> OP_CHECKSIG
> The flexibility of additional templates with new CTV versions or with the
> TXHASH primitive seems to me to enable significantly more utility for
> covenant-based applications.
TXHASH would definitely enable more utility. Additional templates with new CTV
versions would require a new
soft fork for new (hardcoded) usecases. But i'm not going to restart the
conversation around the benefits of
slightly more general covenant primitives [1]. :-)
Antoine
[0] See the OP for rationale[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
[0] Cf the OP for the rationale
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
