From: Peter Todd <pete@petertodd•org>
To: Nadav Ivgi <nadav@shesek•info>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs
Date: Tue, 7 Feb 2023 07:50:13 -0500 [thread overview]
Message-ID: <Y+JJBXsgJGSRZR29@petertodd.org> (raw)
In-Reply-To: <CAGXD5f3Bu3+BsbRQNcA=eugW7FDdgR0xQdpn66925b4DjRyJeQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]
On Tue, Feb 07, 2023 at 11:36:58AM +0200, Nadav Ivgi via bitcoin-dev wrote:
> > Since Taproot (more generally any kind of MAST) spends have variable size
>
> Isn't this the case with any arbitrary script execution? Non-taproot
This is even been true for P2PKH inputs: you can double the space of your
scriptSigs by using uncompressed pubkeys instead of compressed pubkeys.
> If the goal is to only allow registering simple singlesig-encumbered UTXOs
> like P2(W)PKH, the participants could be asked to prove that their P2TR
> output commits to an unspendable script path [0].
Technically, only the last person to sign needs to prove this in advance.
Everyone else can prove it with their signatures.
This distinction could be useful to support coinjoin participants spending
complex P2TR outputs into coinjoins, a perfectly valid use-case in theory so
long as they're paying appropriate fees. Though due to how difficult it is to
validate scripts reliably outside the consensus code base, allowing this for
arbitrary scripts could lead to DoS attacks where someone takes advantage of a
bug in script execution to create an invalid transaction.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-02-07 12:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 2:49 Yuval Kogman
2023-02-07 4:38 ` Lloyd Fournier
2023-02-07 9:36 ` Nadav Ivgi
2023-02-07 12:50 ` Peter Todd [this message]
2023-02-07 13:46 ` Andrew Poelstra
2023-02-07 18:10 ` Andrew Poelstra
2023-02-07 18:35 ` Russell O'Connor
2023-02-07 19:04 ` Peter Todd
2023-02-08 9:34 ` Michael Folkson
2023-02-08 14:00 ` Andrew Poelstra
2023-02-08 14:04 ` Russell O'Connor
2023-02-11 5:14 ` Anthony Towns
2023-02-11 14:40 ` Russell O'Connor
2023-02-12 6:47 ` Anthony Towns
2023-02-07 18:12 ` Peter Todd
2023-02-08 0:56 ` Antoine Riard
2023-02-10 19:35 ` Yuval Kogman
2023-02-15 3:33 ` Antoine Riard
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=Y+JJBXsgJGSRZR29@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nadav@shesek$(echo .)info \
/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