From: "Swambo, Jacob" <jacob.swambo@kcl•ac.uk>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Date: Fri, 29 Apr 2022 13:22:14 +0000 [thread overview]
Message-ID: <VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9@VI1PR03MB5103.eurprd03.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
Hi,
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.
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. 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. 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. 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.
Best regards,
Jacob Swambo
[-- Attachment #2: Type: text/html, Size: 1555 bytes --]
next reply other threads:[~2022-04-29 13:22 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-29 13:22 Swambo, Jacob [this message]
2022-05-03 10:38 ` darosior
-- 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=VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9@VI1PR03MB5103.eurprd03.prod.outlook.com \
--to=jacob.swambo@kcl$(echo .)ac.uk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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