From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D2FA4C002B for ; Tue, 7 Feb 2023 09:37:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9FF7F8125B for ; Tue, 7 Feb 2023 09:37:13 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 9FF7F8125B X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGHHr1dt6PcN for ; Tue, 7 Feb 2023 09:37:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D7F3981234 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by smtp1.osuosl.org (Postfix) with ESMTPS id D7F3981234 for ; Tue, 7 Feb 2023 09:37:11 +0000 (UTC) Received: by mail-ed1-x536.google.com with SMTP id ee13so8022949edb.5 for ; Tue, 07 Feb 2023 01:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shesek.info; s=shesek; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=1H/CDwrnOEMoedqA9LjSrYDbq90D3acKrJwj6qLozQ0=; b=PblOJju/Pj9qvb6myv4DvrUbtN0FJ/rxY0Y3XwSbu0EoMuXqtqMDMOgTQA0Na+g+2W ZdnB26uZjMgPOGxh0YOJMxDd52dpDIXBViu1kF6nW6fTXXewoQqFxg4AtZ0xKVt/57Tk 897pUIifZslBB3T+Vh4NveoIyZwjEm8eRw/Bg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1H/CDwrnOEMoedqA9LjSrYDbq90D3acKrJwj6qLozQ0=; b=dNC+hLaoLstRJk5jDHT+EO6rRwUCRmBltmSp+gAJtj9dWVzkOTSqOAH3fNZo0IyyGN axBJGPVTarvs+s012GJ0yRVRuNT+1fgeX3ziRvIWeyc7QsQ4bZ0zyKP8gxJIh5AG+3Bz DruqhP2JpSBjC58+YWVuYyXvLG92vJlaqeNtLGDxP+wTN5J6hKKdMya9j9bZuZxQOV4z mVCPlEboAF9NCYsf4IySN3YdLs2A837JqpiOEH/rsdA9nyhlmlzppmhvdOddvcaV5Gxp PKEbBDHC6fFiyeYKUBak6KhXN9GPYkexvOXPi0vptz1GKbAOyA47ORGHYUbHP8DDaTMg d1bg== X-Gm-Message-State: AO0yUKUMB7CO3Cx9x504F8s6GckDyQXR5j0RMIymAael+4uWe3BaE+0y LVxOifxMqk1hr/f8uDhIlhGUBq+t9vlHlns4igX+JljqpfM6lQvyFJ8= X-Google-Smtp-Source: AK7set/vlLBL9ragesC9GaNcrWpHjnwRjuAo052ggZaOFhdygrJzlyBGCNQbH0AW+vKdM24Q1+8JhoCxp8kMEtamVUg= X-Received: by 2002:a50:9e61:0:b0:49c:948d:e8ec with SMTP id z88-20020a509e61000000b0049c948de8ecmr405979ede.2.1675762629843; Tue, 07 Feb 2023 01:37:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nadav Ivgi Date: Tue, 7 Feb 2023 11:36:58 +0200 Message-ID: To: Yuval Kogman , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000047aba005f418e47e" X-Mailman-Approved-At: Tue, 07 Feb 2023 09:58:38 +0000 Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2023 09:37:13 -0000 --00000000000047aba005f418e47e Content-Type: text/plain; charset="UTF-8" > Since Taproot (more generally any kind of MAST) spends have variable size Isn't this the case with any arbitrary script execution? Non-taproot P2(W)SH can also have multiple (OP_IF-gated) script branches. For example with ` CHECKSIG IF SHA256 EQUALVERIFY ENDIF`, Mallory can initially demonstrate that she can spend with `FALSE `, then later switch to spending with ` TRUE `. (or I guess even `DROP CHECKSIG`, then just switch from DROPing a 0 length item to a larger one) It seems that supporting arbitrary scripts would require analyzing them and verifying that all spend paths are acceptable, with or without Taproot/MAST. 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]. shesek [0] https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_ref-23-0 On Tue, Feb 7, 2023 at 4:59 AM Yuval Kogman via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > ## Summary > > 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). > > ## Attack Scenario > > Alice et al wish to perform a multiparty transaction, such as a CoinJoin or > lightning dual funding at a relatively high feerate. > > Mallory has a P2TR output with a large script spend path, e.g. an ordinal > inscription commitment transaction output. > > Mallory registers this coin as an input into the multiparty transaction > with a > fee obligation calculated on the basis of a key spend. When all other > participants have provided signatures, the script spend path can be used. > > Since the absolute fee amount is already committed to by the provided > (`SIGHASH_ALL`) signatures but the total transaction weight is not, > Mallory can > broadcast any valid signatures up to the maximum standard weight and > minimum > relay fees, or in collusion with a miner, up to consensus limits. > > This effectively steals a fee from Alice et al, as their signatures do not > commit to a feerate directly or indirectly. > > ## Mitigations > > ### RBF > > All parties could negotiate a (series of) transaction(s) ahead of time at a > lower feerate, giving a lower bound minimum feerate that Mallory can force. > > ### Minimum Weight Before Signing > > Enforcing a minimal weight for all non-witness data in the transaction > before > the transaction is considered fully constructed can limit the > effectiveness of > this attack, since the difference between the predicted weight and the > maximum > weight decreases. > > ### Trusted Coordinator > > In the centralized setting if BIP-322 ownership proofs are required for > participation and assuming the server can be trusted not to collude with > Mallory, the server can reject signatures that do not exercise the same > spend > path as the ownership proof, which makes the ownership proof a commitment > to the > spend weight of the input. > > ### Reputation > > Multiparty protocols with publicly verifiable protocol transcripts can be > provided as weak evidence of a history of honest participation in > multiparty > transactions. > > A ring signature from keys used in the transaction or its transcript > committing > to the new proposed transaction can provide weak evidence for the honesty > of the > peer. > > Such proofs are more compelling to an entity which has participated in > (one of) > the transcripts, or proximal transactions. Incentives are theoretically > aligned > if public coordinators publish these transcripts as a kind of server > reputation. > > ### Increasing Costliness > > A minimum feerate for the previous transaction or a minimum confirmation > age > (coindays destroyed implies time value, analogous to fidelity bonds) can be > required for inputs to be added, in order to make such attacks less > lucrative > (but there is still a positive payoff for the attacker). > > ### Signature Ordering > > Signatures from potentially exploitative inputs can be required ahead of > legacy > or SegWit v0 ones. The prescribed order can be determined based on > reputation or > costliness as described in the previous paragraphs. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000047aba005f418e47e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Since Taproot (more generally any kind of MAST) = spends have variable size

Isn't this the case = with any arbitrary script execution? Non-taproot P2(W)SH can also have mult= iple (OP_IF-gated) script branches. For example with `<pk> CHECKSIG I= F SHA256 <hash> EQUALVERIFY ENDIF`, Mallory can initially demonstrate= that she can spend with `FALSE <sig>`, then later switch to spending= with `<some large preimage> TRUE <sig>`. (or I guess even `DRO= P <pk> CHECKSIG`, then just switch from DROPing a 0 length item to a = larger one)

It seems that supporting arbitrary scr= ipts would require analyzing them and verifying that all spend paths are ac= ceptable, with or without Taproot/MAST.

If the goa= l is to only allow registering simple singlesig-encumbered UTXOs like P2(W)= PKH, the participants could be asked to prove that their P2TR output commit= s to an unspendable script path [0].

sh= esek


On Tue, Feb = 7, 2023 at 4:59 AM Yuval Kogman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
## S= ummary

Since Taproot (more generally any kind of MAST) spends have variable size w= hich
depends on the path being used, the last such input to be signed in a multi= party
transaction can always use a larger than estimated signature to unfairly ex= tract
a fee contribution from the other parties to the transaction (keeping the absolute fees the same and reducing the feerate for the transaction).

## Attack Scenario

Alice et al wish to perform a multiparty transaction, such as a CoinJoin or=
lightning dual funding at a relatively high feerate.

Mallory has a P2TR output with a large script spend path, e.g. an ordinal inscription commitment transaction output.

Mallory registers this coin as an input into the multiparty transaction wit= h a
fee obligation calculated on the basis of a key spend. When all other
participants have provided signatures, the script spend path can be used.
Since the absolute fee amount is already committed to by the provided
(`SIGHASH_ALL`) signatures but the total transaction weight is not, Mallory= can
broadcast any valid signatures up to the maximum standard weight and minimu= m
relay fees, or in collusion with a miner, up to consensus limits.

This effectively steals a fee from Alice et al, as their signatures do not<= br> commit to a feerate directly or indirectly.

## Mitigations

### RBF

All parties could negotiate a (series of) transaction(s) ahead of time at a=
lower feerate, giving a lower bound minimum feerate that Mallory can force.=

### Minimum Weight Before Signing

Enforcing a minimal weight for all non-witness data in the transaction befo= re
the transaction is considered fully constructed can limit the effectiveness= of
this attack, since the difference between the predicted weight and the maxi= mum
weight decreases.

### Trusted Coordinator

In the centralized setting if BIP-322 ownership proofs are required for
participation and assuming the server can be trusted not to collude with Mallory, the server can reject signatures that do not exercise the same spe= nd
path as the ownership proof, which makes the ownership proof a commitment t= o the
spend weight of the input.

### Reputation

Multiparty protocols with publicly verifiable protocol transcripts can be provided as weak evidence of a history of honest participation in multipart= y
transactions.

A ring signature from keys used in the transaction or its transcript commit= ting
to the new proposed transaction can provide weak evidence for the honesty o= f the
peer.

Such proofs are more compelling to an entity which has participated in (one= of)
the transcripts, or proximal transactions. Incentives are theoretically ali= gned
if public coordinators publish these transcripts as a kind of server reputa= tion.

### Increasing Costliness

A minimum feerate for the previous transaction or a minimum confirmation ag= e
(coindays destroyed implies time value, analogous to fidelity bonds) can be=
required for inputs to be added, in order to make such attacks less lucrati= ve
(but there is still a positive payoff for the attacker).

### Signature Ordering

Signatures from potentially exploitative inputs can be required ahead of le= gacy
or SegWit v0 ones. The prescribed order can be determined based on reputati= on or
costliness as described in the previous paragraphs.
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000047aba005f418e47e--