path: root/8f/04fe608d7af3add883d80c3b5603c905af56ac

Return-Path: <lloyd.fourn@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5EFE4C002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Feb 2023 04:38:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 1E38681D18
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Feb 2023 04:38:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1E38681D18
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=CO7tIIPr
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
 tests=[ADVANCE_FEE_3_NEW=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Lqn7OhlPdEoZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Feb 2023 04:38:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C69CC81BC5
Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com
 [IPv6:2607:f8b0:4864:20::b30])
 by smtp1.osuosl.org (Postfix) with ESMTPS id C69CC81BC5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  7 Feb 2023 04:38:57 +0000 (UTC)
Received: by mail-yb1-xb30.google.com with SMTP id g2so17085079ybk.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 06 Feb 2023 20:38:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=QB496MwXFYtza0CcVFE8cFTbIyDsE3tAHzzVZWgZNnQ=;
 b=CO7tIIPr481JLUbBBn7yXPQLjbOF+qxqmU7+YLUdB+ZXHd4S1vl42ZRWGqb91nvsYs
 7WRBZCI5OMo8Qno125S5SqO5mWRKGe3CYOFIwwWnv1AwWDlKzeC1Mw6DmobLNw3btovl
 RH/c6UcpFs4rc0DObJbqgRiC+ZaIf4Z5eB+jFooAn6dPCPKlROksSHxRfIFg4W1p51qx
 tq57HfhJ0NbAEFVvkI97uqxvvPmOy9FVxZ18+2A3uzq8BrbPDZGuL7BkXXyKhvsNbjCI
 4psxJKTlyU3f6UuQhv2JJkWC8esmjP8SsjjLS/fJxso0MJpbdpiyO7feQOsOWu9n1wvl
 2wXQ==
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=QB496MwXFYtza0CcVFE8cFTbIyDsE3tAHzzVZWgZNnQ=;
 b=1Jgf6r4BNAjomV1LHMj4oPn5SQJlrv2AEjXqJQ4r/Jb9TUqI5Yzd5n/LIAtNsFyJbD
 i0nUpZni4GAdsPP+4UiV3xBIzVzp6aFGpVNW8kQ5PJYh+EOudg+yEUvSz5IOBZjWXLvC
 f+jHOjhM8iiehI7zNWZqBakmpBfuXmFBhvQKEMGazlFwPv/FsxjEieoMWCtKO8p7nalT
 EBKKlm9q/kdNZV7jxCrAAB3RI11c7uHHEorJx1ZdBYQAYHtQXm3VdVROblhXWC17C2Ze
 qwGruTbfjc7N9Cw/xgBBE4b366pMnxZ73F5nMdd0pKwWoG06nKRK0pJEhgn9UDhpaBzF
 V5yw==
X-Gm-Message-State: AO0yUKUYLZp0P0GBNIPCJUMZAKxLl2oAdDO7L7XqDd54f9cPRS3mUsrC
 QVfB749PDTbPahJtI0PDpD+gdDgZr2rIqEx3D8znm0Q/8+4=
X-Google-Smtp-Source: AK7set8WhA4HdSSbsKxTglcfAWy3Ftqp22QYaKpM/sdDt+ZjkYv7RAQZBNTZMs7iLu+wBEBG1VsV2hwoLPqAJc862XE=
X-Received: by 2002:a25:eb04:0:b0:7b4:6a33:d89f with SMTP id
 d4-20020a25eb04000000b007b46a33d89fmr168667ybs.543.1675744736576; Mon, 06 Feb
 2023 20:38:56 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
In-Reply-To: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
From: Lloyd Fournier <lloyd.fourn@gmail.com>
Date: Tue, 7 Feb 2023 15:38:30 +1100
Message-ID: <CAH5Bsr3FGakNoGDA2KZXtEJ8t=pMpLqEXDWDbd1sMQtkxY6FJQ@mail.gmail.com>
To: Yuval Kogman <nothingmuch@woobling.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c20adf05f414b956"
X-Mailman-Approved-At: Tue, 07 Feb 2023 09:26:17 +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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2023 04:38:59 -0000

--000000000000c20adf05f414b956
Content-Type: text/plain; charset="UTF-8"

Hi Yuval,

This is an interesting attack. Usually I think of spending with a big
weight witness in the context of slowing down a confirmation of a
transaction, especially a DLC creation tx. There you can delay its
confirmation past some time (i.e. see if your team won the game, and then
either trying to confirm it by providing the slimmed down witness or double
cancelling it by double spending). In this case you are not trying to delay
it but to dilute your portion of the fee.

Another mitigation is to aggresively RBF double spend your input any time a
counterparty doesn't use the spending path they said they would and don't
deal with them again. Of course, various pinning attacks may prevent this
depending on how your joint tx is structured.

LL

On Tue, 7 Feb 2023 at 13:59, 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
>

--000000000000c20adf05f414b956
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Yuval,</div><div><br></div><div>This is an interes=
ting attack. Usually I think of spending with a big weight witness in the c=
ontext of slowing down a confirmation of a transaction, especially a DLC cr=
eation tx. There you can delay its confirmation past some time (i.e. see if=
 your team won the game, and then either trying to confirm it by providing =
the slimmed down witness or double cancelling it by double spending). In th=
is case you are not trying to delay it but to dilute your portion of the fe=
e.</div><div><br></div><div>Another mitigation is to aggresively RBF double=
 spend your input any time a counterparty doesn&#39;t use the spending path=
 they said they would and don&#39;t deal with them again. Of course, variou=
s pinning attacks may prevent this depending on how your joint tx is struct=
ured.</div><div><br></div><div>LL<br></div></div><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 7 Feb 2023 at 13:59, Yuv=
al Kogman via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">## Summary<br>
<br>
Since Taproot (more generally any kind of MAST) spends have variable size w=
hich<br>
depends on the path being used, the last such input to be signed in a multi=
party<br>
transaction can always use a larger than estimated signature to unfairly ex=
tract<br>
a fee contribution from the other parties to the transaction (keeping the<b=
r>
absolute fees the same and reducing the feerate for the transaction).<br>
<br>
## Attack Scenario<br>
<br>
Alice et al wish to perform a multiparty transaction, such as a CoinJoin or=
<br>
lightning dual funding at a relatively high feerate.<br>
<br>
Mallory has a P2TR output with a large script spend path, e.g. an ordinal<b=
r>
inscription commitment transaction output.<br>
<br>
Mallory registers this coin as an input into the multiparty transaction wit=
h a<br>
fee obligation calculated on the basis of a key spend. When all other<br>
participants have provided signatures, the script spend path can be used.<b=
r>
<br>
Since the absolute fee amount is already committed to by the provided<br>
(`SIGHASH_ALL`) signatures but the total transaction weight is not, Mallory=
 can<br>
broadcast any valid signatures up to the maximum standard weight and minimu=
m<br>
relay fees, or in collusion with a miner, up to consensus limits.<br>
<br>
This effectively steals a fee from Alice et al, as their signatures do not<=
br>
commit to a feerate directly or indirectly.<br>
<br>
## Mitigations<br>
<br>
### RBF<br>
<br>
All parties could negotiate a (series of) transaction(s) ahead of time at a=
<br>
lower feerate, giving a lower bound minimum feerate that Mallory can force.=
<br>
<br>
### Minimum Weight Before Signing<br>
<br>
Enforcing a minimal weight for all non-witness data in the transaction befo=
re<br>
the transaction is considered fully constructed can limit the effectiveness=
 of<br>
this attack, since the difference between the predicted weight and the maxi=
mum<br>
weight decreases.<br>
<br>
### Trusted Coordinator<br>
<br>
In the centralized setting if BIP-322 ownership proofs are required for<br>
participation and assuming the server can be trusted not to collude with<br=
>
Mallory, the server can reject signatures that do not exercise the same spe=
nd<br>
path as the ownership proof, which makes the ownership proof a commitment t=
o the<br>
spend weight of the input.<br>
<br>
### Reputation<br>
<br>
Multiparty protocols with publicly verifiable protocol transcripts can be<b=
r>
provided as weak evidence of a history of honest participation in multipart=
y<br>
transactions.<br>
<br>
A ring signature from keys used in the transaction or its transcript commit=
ting<br>
to the new proposed transaction can provide weak evidence for the honesty o=
f the<br>
peer.<br>
<br>
Such proofs are more compelling to an entity which has participated in (one=
 of)<br>
the transcripts, or proximal transactions. Incentives are theoretically ali=
gned<br>
if public coordinators publish these transcripts as a kind of server reputa=
tion.<br>
<br>
### Increasing Costliness<br>
<br>
A minimum feerate for the previous transaction or a minimum confirmation ag=
e<br>
(coindays destroyed implies time value, analogous to fidelity bonds) can be=
<br>
required for inputs to be added, in order to make such attacks less lucrati=
ve<br>
(but there is still a positive payoff for the attacker).<br>
<br>
### Signature Ordering<br>
<br>
Signatures from potentially exploitative inputs can be required ahead of le=
gacy<br>
or SegWit v0 ones. The prescribed order can be determined based on reputati=
on or<br>
costliness as described in the previous paragraphs.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c20adf05f414b956--