From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Yuval Kogman <nothingmuch@woobling•org>,
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 13:46:22 +0000 [thread overview]
Message-ID: <Y+JWLsc80gxL4kpG@camus> (raw)
In-Reply-To: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3258 bytes --]
On Tue, Feb 07, 2023 at 04:49:28AM +0200, Yuval Kogman via bitcoin-dev wrote:
>
> Since Taproot (more generally any kind of MAST) spends have variable size which
> depends on the path being used, the last such input to be signed in a multiparty
> transaction can always use a larger than estimated signature to unfairly extract
> a fee contribution from the other parties to the transaction (keeping the
> absolute fees the same and reducing the feerate for the transaction).
>
Using Miniscript [1] it is possible for all participants to determine
the maximum witness size of the tree, which can bound the size of this
attack. In fact, they can bound the size *given that their own signature
is used*, or subject to other whatever other conditions they would like,
and only sign under those conditions.
Furthermore, under Taproot individual signatures have a maximum size of
65 bytes; an "attacker" can reduce this to 64 by not including a sighash
flag, but he has one byte of play. (Pre-Taproot signatures could take up
to 73 bytes with significant room to reduce this by using crypto tricks
and/or grinding).
Peter Todd also suggests in this thread that the use of uncompressed
keys can cause "surprise" witness inflation, but (a) since segwit
uncompressed keys are also banned, so keys are a fixed 33 bytes (32 in
Taproot), and (b) we expect users of Miniscript to always know all the
keys used in a script that they're signing. Except perhaps in obscure
cases where, say, the "victim" is a somewhat passive countersigner of
a transaction, e.g. BitGo, ... in which case they're not the one putting
up fees or with an interest in the transaction going through.
With Miniscript, the problem is narrower:
* There is some more-expensive branch that could be taken without
Alice's signature. In which case Alice is only signing at all to
optimistically reduce the witness size... but she cannot assume
that she is going to be successful!
Notably, in this case Alice does not really have any interest in the
coins, in the sense that they can move entirely without her consent,
so it's hard to imagine that she has an interest in the transaction's
speedy confirmation.
* There is some more-expensive branch that could be taken by moving
Alice's signature. This is the case that you identify in the thread.
While the attack remains in both cases, fortunately Miniscript gives
Alice the tools to (a) determine which, if any, case applies to the
script under question, and (b) determine what the maximum witness size
might be, and just sign assuming that, treating any savings as "bonus".
[1] https://bitcoin.sipa.be/miniscript/
[2] In Taproot, if you want to prevent signatures migrating to another
branch or within a branch, you can use the CODESEPARATOR opcode
which was redisegned in Taproot for exactly this purpose... we
really did about witness malleation in its design!
If you want to prevent signatures from moving around *within* a
branch,
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2023-02-07 13:46 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
2023-02-07 13:46 ` Andrew Poelstra [this message]
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+JWLsc80gxL4kpG@camus \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=nothingmuch@woobling$(echo .)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