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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
|
Return-Path: <darosior@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 902DEC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Mar 2022 18:08:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 7959C813DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Mar 2022 18:08:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001,
RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
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 VJDP4gGQ4d_w
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Mar 2022 18:08:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by smtp1.osuosl.org (Postfix) with ESMTPS id A98F8813A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 12 Mar 2022 18:08:44 +0000 (UTC)
Date: Sat, 12 Mar 2022 18:08:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1647108521;
bh=uT9rw3HBaSrifK4LGsLd83XEggx+GBbDUknLxYirNeE=;
h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc:Date:Subject:
Reply-To:Feedback-ID:Message-ID;
b=DtNXmvrR3dn4XmL1lXsKX57cRIBS1IVU67GVcL6vXANLXELHArzBpMTBDOdy5AjOK
2Hs8j/unwnVv9ZzYiu5em0c9oz8bd6b1UHfPTXcoWBGzGbOyM35YjWtcFrR8D7U1/d
ak+K1yaZkm2Mci7Vd2sTI46PVfVzNNUOAY0cumgiqBlrBtWujkpUHRG9yYWrio077g
eQ9WvAwNNfDyGbC7boBJ8MVyK0y2/P2n3dq/mzVzZ8ND5HeLMTTP/sduGlYdbqDnLX
laBDvMqP2bODNjiPnZjddljO5c+UPgEDCfWhTgqggKXwHCXLG7E2oVMH0XYQ1/2abX
5XZ0tGTpP/Xjg==
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <Udzkz8ZPM4na6yNcGnINLCskodTve66hhpoXevwYuVVgfWfbJnLH70Btmp_dmvk8X8sNXqywBVviG3OzFzeoXQanPb8KkWNGjKG2mxxDsAo=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 12 Mar 2022 18:33:48 +0000
Subject: [bitcoin-dev] Covenants and feebumping
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: Sat, 12 Mar 2022 18:08:46 -0000
The idea of a soft fork to fix dynamic fee bumping was recently put back on=
the table. It might
sound radical, as what prevents today reasonable fee bumping for contracts =
with presigned
transactions (pinning) has to do with nodes' relay policy. But the frustrat=
ion is understandable
given the complexity of designing fee bumping with today's primitives. [0]
Recently too, there was a lot of discussions around covenants. Covenants (c=
onceptually, not talking
about any specific proposal) seem to open lots of new use cases and to be d=
esired by (some?) Bitcoin
application developers and users.
I think that fee bumping using covenants has attractive properties, and it =
requires a soft fork that
is already desirable beyond (trying) to fix fee bumping. However i could no=
t come up with a solution
as neat for other protocols than vaults. I'd like to hear from others about=
1) taking this route for
fee bumping 2) better ideas on applying this to other protocols.
In a vault construction you have a UTxO which can only be spent by an Unvau=
lting transaction, whose
output triggers a timelock before the expiration of which a revocation tran=
saction may be confirmed.
The revocation transaction being signed in advance (typically before sharin=
g the signature for the
Unvault transaction) you need fee bumping in order for the contract to actu=
ally be enforceable.
Now, with a covenant you could commit to the revocation tx instead of presi=
gning it. And using a
Taproot tree you could commit to different versions of it with increasing f=
eerate. Any network
monitor (the brooadcaster, a watchtower, ..) would be able to RBF the revoc=
ation transaction if it
doesn't confirm by spending using a leaf with a higher-feerate transaction =
being committed to.
Of course this makes for a perfect DoS: it would be trivial for a miner to =
infer that you are using
a specific vault standard and guess other leaves and replace the witness to=
use the highest-feerate
spending path. You could require a signature from any of the participants. =
Or, at the cost of an
additional depth, in the tree you could "salt" each leaf by pairing it with=
-say- an OP_RETURN leaf.
But this leaves you with a possible internal blackmail for multi-party cont=
racts (although it's less
of an issue for vaults, and not one for single-party vaults).
What you could do instead is attaching an increasing relative timelock to e=
ach leaf (as the committed
revocation feerate increases, so does the timelock). You need to be careful=
to note wreck miner
incentives here (see [0], [1], [2] on "miner harvesting"), but this enables=
the nice property of a
feerate which "adapts" to the block space market. Another nice property of =
this approach is the
integrated anti fee sniping protection if the revocation transaction pays a=
non-trivial amount of
fees.
Paying fees from "shared" funds instead of a per-watchtower fee-bumping wal=
let opened up the
blackmail from the previous section, but the benefits of paying from intern=
al funds shouldn't be
understated.
No need to decide on an amount to be refilled. No need to bother the user t=
o refill the fee-bumping
wallet (before they can participate in more contracts, or worse before a de=
adline at which all
contracts are closed). No need for a potentially large amount of funds to j=
ust sit on a hot wallet
"just in case". No need to duplicate this amount as you replicate the numbe=
r of network monitors
(which is critical to the security of such contracts).
In addition, note how modifying the feerate of the revocation transaction i=
n place is less expensive
than adding a (pair of) new input (and output), let alone adding an entire =
new transaction to CPFP.
Aside, and less importantly, it can be made to work with today's relay rule=
s (just use fee thresholds
adapted to the current RBF thresholds, potentially with some leeway to acco=
unt for policy changes).
Paying from shared funds (in addition to paying from internal funds) also p=
revents pervert
incentives for contracts with more than 2 parties. In case one of the parti=
es breaches it, all
remaining parties have an incentive to enforce the contract.. But only one =
would otherwise pay for
it! It would open up the door to some potential sneaky techniques to wait f=
or another party to pay
for the fees, which is at odd with the reactive security model.
Let's examine how it could be concretely designed. Say you have a vault wal=
let software for a setup
with 5 participants. The revocation delay is 144 blocks. You assume revocat=
ion to be infrequent (if
one happens it's probably a misconfigured watchtower that needs be fixed be=
fore the next
unvaulting), so you can afford infrequent overpayments and larger fee thres=
holds. Participants
assume the vault will be spent within a year and assume a maximum possible =
feerate for this year of
10ksat/vb.
They create a Taproot tree of depth 7. First leaf is the spending path (ope=
n to whomever the vault
pays after the 144 blocks). Then the leaf `i` for `i` in `[1, 127]` is a co=
venant to the revocation
transaction with a feerate `i * 79` sats/vb and a relative timelock of `i -=
1` blocks.
Assuming the covenant to the revocation transaction is 33 bytes [3], that's=
a witness of:
1 + 33 + 1 + 33 + 7 * 32 =3D 292 WU (73 vb)
^^^^^^ ^^^^^^^^^^^^^^
witscript control block
for any of the revocation paths. The revocation transaction is 1-input 1-ou=
tput, so in total it's
10.5 + 41 + 73 + 43 =3D 167.5 vb
^^^^ ^^^^^^^^^^^ ^^^^
header input|witness output
The transaction size is not what you'd necessarily want to optimize for fir=
st, still, it is smaller
in this case than using other feebumping primitives and has a smaller footp=
rint on the UTxO set. For
instance for adding a feebumping input and change output assuming all Tapro=
ot inputs and outputs
(CPFP is necessarily even larger):
5 * 64 + 1 + 5 * (32 + 1) + 1 + 33 =3D 520 WU (105 vb)
^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^
witness witscript control
10.5 + 41 + 105 + 41 + 16.5 + 2 * 43 =3D 300 vb
^^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
header input|witness fb input|witness outputs
From there, you can afford more depths at the tiny cost of 8 more vbytes ea=
ch. You might want them
for:
- more granularity (if you can afford large enough timelocks)
- optimizing for the spending path rather than the revocation one
- adding a hashlock to prevent nuisance (with the above script a third part=
y could malleate a
spending path into a revocation one). You can use the OP_RETURN trick fro=
m above to prevent that.
Unfortunately, the timelocked-covenant approach to feebumping only applies =
to bumping the first
transaction of a chain (you can't pay for the parent with a timelock) so fo=
r instance it's not
usable for HTLC transactions in Lightning to bump the parent commitment tx.=
The same goes for
bumping the update tx in Coinpool.
It could be worked around by having a different covenant per participant (p=
aying the fee from either
of the participants' output) behind a signature check. Of course it require=
s funds to already be in
the contract (HTLC, Coinpool leaf) to pay for your own unilateral close, bu=
t if you don't have any
fund in the contract it doesn't make sense to try to feebump it in the firs=
t place. The same goes
for small amounts: you'd only allocate up to the value of the contract (min=
us a dust preference) in
fees in order to enforce it.
This is less nice for external monitors as it requires a private key (or an=
other secret) to be
committed to in advance) to be able to bump [4] and does not get rid of the=
"who's gonna pay for the
enforcement" issue in >2-parties contracts. Still, it's more optimal and us=
able than CPFP or adding
a pair of input/output for all the reasons mentioned above.
Thoughts?
Antoine
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/0=
19614.html
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/0=
19615.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/0=
19627.html
[3] That's obviously close to the CTV construction. But using another more =
flexible (and therefore
less optimized) construction would not be a big deal. It might in fact =
be necessary for more
elaborated (realistic?) usecases than the simple one detailed here.
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/0=
19879.html
|
