From: darosior <darosior@protonmail•com>
To: "Swambo, Jacob" <jacob.swambo@kcl•ac.uk>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Date: Tue, 03 May 2022 10:38:52 +0000 [thread overview]
Message-ID: <WIe3ejSEYdjcCskUKAAmPkGqGlNYeaAVtIU5M2lniXI2A4rPw9JQmIDLNc57GNnjfm5PX6hitj5-zrYTCwgDNm-gBfcl8yBEDT7pkSSyxxo=@protonmail.com> (raw)
In-Reply-To: <VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9@VI1PR03MB5103.eurprd03.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4429 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 6037 bytes --]
next prev parent reply other threads:[~2022-05-03 10:39 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-29 13:22 Swambo, Jacob
2022-05-03 10:38 ` darosior [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-05-03 16:40 Swambo, Jacob
2022-04-22 17:14 pushd
2022-04-22 13:35 pushd
2022-04-25 13:34 ` Hampus Sjöberg
2022-04-22 11:11 darosior
2022-04-22 11:44 ` rot13maxi
2022-04-22 11:54 ` darosior
2022-04-22 17:01 ` Luke Dashjr
2022-04-24 20:41 ` Richard Myers
2022-04-25 13:35 ` darosior
2022-04-25 16:35 ` darosior
2022-04-25 1:46 ` Erik Aronesty
2022-04-25 16:35 ` Nadav Ivgi
2022-04-25 16:57 ` Nadav Ivgi
2022-04-26 20:13 ` Jeremy Rubin
2022-04-29 5:08 ` Nadav Ivgi
2022-04-29 8:30 ` darosior
2022-04-29 10:21 ` Nadav Ivgi
2022-04-29 11:40 ` Nadav Ivgi
2022-05-01 23:35 ` Billy Tetrud
2022-04-30 8:09 ` Nadav Ivgi
2022-04-30 11:15 ` Greg Sanders
2022-05-01 14:25 ` Nadav Ivgi
2022-05-03 15:51 ` Jeremy Rubin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='WIe3ejSEYdjcCskUKAAmPkGqGlNYeaAVtIU5M2lniXI2A4rPw9JQmIDLNc57GNnjfm5PX6hitj5-zrYTCwgDNm-gBfcl8yBEDT7pkSSyxxo=@protonmail.com' \
--to=darosior@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jacob.swambo@kcl$(echo .)ac.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox