1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Return-Path: <nothingmuch@woobling.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 17738C002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Feb 2023 02:49:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id E068A60DF4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Feb 2023 02:49:43 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E068A60DF4
Authentication-Results: smtp3.osuosl.org;
dkim=pass (1024-bit key) header.d=woobling.org header.i=@woobling.org
header.a=rsa-sha256 header.s=google header.b=Ynd/HIne
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id hIDMSvTDDu9X
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Feb 2023 02:49:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 13F6E60D56
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com
[IPv6:2a00:1450:4864:20::12f])
by smtp3.osuosl.org (Postfix) with ESMTPS id 13F6E60D56
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Feb 2023 02:49:41 +0000 (UTC)
Received: by mail-lf1-x12f.google.com with SMTP id x40so20458023lfu.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 06 Feb 2023 18:49:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=woobling.org; s=google;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=Sb9CzHxtsaNYRRNysMsKQFt5MwAx8bmUPDxPBB3xv1o=;
b=Ynd/HInevHqJdR3W2O5XbWM/V8icz2/3lJfk7i4/hmSBjXOe0MovL4yhX7J8+Kc+Bj
DiQC6fsXTD4go9HhxkfusfnWvQPuYIjW+sYdphRnd+k7RjRpRBbFJ6fgi27yiCj4XI+t
C9k1WnPuVxOh1LV4dyI/Y3o6mCJYwltN8IFrk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=Sb9CzHxtsaNYRRNysMsKQFt5MwAx8bmUPDxPBB3xv1o=;
b=VBbZwrOJabQZQBFgwrZ7BwES+p1Az38h+CMuu8pMUzs9s9T+XUmOhU8wdBJbkGJYB7
Q7MtoxxpCa8jLAhKLwDB92QNQ/baR0fRPCsE0VNXATOIMEtjEccP4Xzrm7nW4DWluUBV
sJ0wAoy6Rc89O0L+W/Gj547lrjd3Jh3gr7v8ynxYcAOofISfN48XsCbk8y0ogTnPisLl
nLSrQxHeC4INqS7UGqER7QaxMi6KM/LdEgUoSvbzyF7/dP/tJEmJpj4U0ots5gs5tcQ9
tMzxXCqzr4oOJMlokByM7Qp4GoWkRbLK1/MeExOpqmiFbhsBQPooZk/uE3FrZk1skP3g
Skfg==
X-Gm-Message-State: AO0yUKUDmEkwXrEv7NjuWe227t1a+G6EqSAur+VTBQt5BmNtbMPkHxLQ
Ht2F7zLLX04anjFKRYLbj4cyKb+cIGih2NFDNNz/OQWnz5zFYq/w
X-Google-Smtp-Source: AK7set8t17pOInCYdKTMcjyei4iI873UsnFBdnmPq977fJpJFk8Rd286sYK/zfaa2yhwsxBv5qhjmvbmMdF1taLsRXQ=
X-Received: by 2002:ac2:569b:0:b0:4af:ee74:aa5f with SMTP id
27-20020ac2569b000000b004afee74aa5fmr186416lfr.24.1675738179398; Mon, 06 Feb
2023 18:49:39 -0800 (PST)
MIME-Version: 1.0
From: Yuval Kogman <nothingmuch@woobling.org>
Date: Tue, 7 Feb 2023 04:49:28 +0200
Message-ID: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Tue, 07 Feb 2023 02:59:29 +0000
Subject: [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 02:49:44 -0000
## 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.
|
