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
|
Return-Path: <michaelfolkson@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B6BCCC000E;
Tue, 29 Jun 2021 09:44:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id B28F1607B1;
Tue, 29 Jun 2021 09:44:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
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 atjYD1P1SD2Z; Tue, 29 Jun 2021 09:44:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com
[IPv6:2607:f8b0:4864:20::230])
by smtp3.osuosl.org (Postfix) with ESMTPS id 8B296606ED;
Tue, 29 Jun 2021 09:44:23 +0000 (UTC)
Received: by mail-oi1-x230.google.com with SMTP id t3so2670209oic.5;
Tue, 29 Jun 2021 02:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=j+CIhZJf/CF+cF8sHsE5BE+RpKYyRFLDynbEL5LGtOo=;
b=PHuJVFbQYnUjwSzklKjWJtdE/K2gyFY5Syp/O0T/XP+/Po1NodwSEF1uNSZmMoAWQo
69Acz9eH1fOUH7Gsy5pGxN4E2fItnb2eKS5I+NDqDq6dIe2w7X6LAUfPZmwLvKDMKF+0
zbtKPc7WlajvQCzILb4/2DHf4Ia5ru4lq4hw6rsRy9XMPhOBAaAXXRnobMfTZdSVBx5X
C1s/HLSWdZCnt46h3s/iCzr/gZ9eALaCF7KP7Rdsa9sg9rFIbwz7GYgtaVuGIBBRL2vj
8G78V7y4Py1iCbr6w6IZUeJ2JoAzsvEDHeYHmA9W9gYrbuv7P1G8MOloFUGXjkeN9oi6
aUCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to
:content-transfer-encoding;
bh=j+CIhZJf/CF+cF8sHsE5BE+RpKYyRFLDynbEL5LGtOo=;
b=KAk92JGh3AmjQLiNb6ACJHXI5YfCJd/0JD5YSHXVLiwPYpd0vhoGqmoDJG6UAWQ6SC
nKWnEeYMy50AsubXTbtPk41Tk9uF3siBmF4KB6OcgFcgvUN9mZEPoPXjtKcelziVArin
zY2bkBCSBmRBvWOOzIEVi7cwF+B5ChL8T0aTX1JHQHVM2HMXgo3ZWJXi1WkmMZ12yzns
JkINF7kf/a7R4IkhYB9/UvSa/bj3dAyt+MY4k9pJNi7p+tDOqc/vjuVWUaVtAYpD92v4
W7oHJwW6EJRB8DP+tJ3NFavc51aj3vZRKfBsnpCKFfDBSHEXCbFeIgVwrNndRTWcoV1Z
qrHA==
X-Gm-Message-State: AOAM531a9WlglGyf1f/DGQEiLvgEW9DLjUS026I8d4iUM97O+jqbmnIX
yZhzDEQwJZA0xCJUlSIIk1jSK+9bBshMhrfs4B6haFWWsPY=
X-Google-Smtp-Source: ABdhPJwjnStLmSex2/hbB3cg6EqafU6hBj4IVfBbkAnqj+CXdKfVQ4X3foJMNd5xi9o1F74TaXmDs97O/5oM1Y0LNfY=
X-Received: by 2002:a05:6808:13c5:: with SMTP id
d5mr20373160oiw.163.1624959862386;
Tue, 29 Jun 2021 02:44:22 -0700 (PDT)
MIME-Version: 1.0
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Tue, 29 Jun 2021 10:44:11 +0100
Message-ID: <CAFvNmHSs0V8M8wjonoXKmBF6pgdtzQdgK-apsvd80+0k8WWZMg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 29 Jun 2021 10:10:38 +0000
Subject: [bitcoin-dev] Last week's second IRC workshop on L2 onchain support
and wrap up
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, 29 Jun 2021 09:44:24 -0000
A summary of the first workshop is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.ht=
ml
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
https://github.com/ariard/L2-zoology/blob/master/workshops/package-relay-an=
d-friends.md
The conversation log for the second workshop is here:
https://gist.github.com/ariard/32b51ecceccc5c6f647bae86d083c442
Package relay background
Package relay is potentially useful for L2 protocols to address the
inherent unpredictability of future fees. CPFP (child-pays-for-parent)
seeks to ensure say a justice transaction, in Lightning=E2=80=99s case, wit=
h a
lower fee, gets confirmed in a more timely manner because miners are
incentivized to include the child transaction in a block. To do so
they must include the parent transaction in that block or a preceding
block. By =E2=80=9Cpackaging=E2=80=9D the parent and the child the initiato=
r of the
transaction(s) can ensure the miner=E2=80=99s mempool doesn=E2=80=99t initi=
ally reject
the parent transaction for having a too low fee.
There has been prior work done in previous years on package relay,
mainly by Suhas Daftuar.
Draft BIP: https://gist.github.com/sdaftuar/8756699bfcad4d3806ba9f3396d4e66=
a
Package relay design questions: https://github.com/bitcoin/bitcoin/issues/1=
4895
Recently Gloria Zhao has been advancing package relay in Bitcoin Core:
https://gist.github.com/glozow/7064717e727a3eb27fad4f8504513add
Package relay implementation
Attendees seemed in agreement that enabling 2 transaction packages
would be sufficient (at least for now) for Lightning and DLCs. A L2
protocol should always be able to design a two step process where the
first transaction has an effective zero fee rate and the second
transaction sets the fee. Restricting the size of the package to 2 may
have the cost of slightly longer confirmation times and/or slightly
higher fees (t-bast) but it compares well to the increased
implementation complexity of larger package sizes. Two generation:
multi parent, single child shouldn=E2=80=99t introduce material implementat=
ion
complexity over two generation: single parent, single child (glozow).
Package RBF (replace-by-fee) is possible where there are two competing
packages with competing Lightning commitment transactions in them and
the second package is given a higher fee to attempt to get it
confirmed before the first package. However, supporting RBF within a
package (ie replacing a transaction in a package with a higher fee
transaction) increases implementation complexity and makes it harder
to reason about (glozow).
rgrant raised the possibility of using two packages {A,B} and {B,C} if
three transaction packages e.g. {A,B,C} weren=E2=80=99t supported but it wa=
s
suggested it is perhaps better to just broadcast a high fee CPFP
transaction for the {A,B} package rather than creating two packages.
If the first package has been evicted from the mempool the {B,C}
package wouldn=E2=80=99t propagate because it would be an orphan package
(t-bast).
glozow suggested that only hints (wtxids of transactions you think
should be package validated) could be communicated rather than
relaying the transaction themselves but there were concerns from
others on whether these hints would successfully propagate across the
network. Instead fee rate hints could be sent to inform a peer=E2=80=99s
decision on whether it makes sense to fetch the rest of the package
(t-bast).
darosior suggested the idea of a package based CBlockPolicyEstimator
in Bitcoin Core if CPFP is going to be increasingly used on the
network.
Witness replacement and Taproot
Tapscripts can be unlimited in size so with current Taproot rules you
could in theory go from a 100,000 vbyte witness to an empty witness.
L2 protocols may have a UTXO shared by two parties where Alice=E2=80=99s
witness for her branch is say 1,000 vbytes and Bob=E2=80=99s witness is onl=
y
say 250 vbytes. Replacing Alice=E2=80=99s larger witness with Bob=E2=80=99s=
smaller
witness could reduce transaction fees. For Lightning the best case is
a Taproot key path spend (16 vbyte witness) and the worst case is
going to be a 150 vbyte witness. Miniscript can tell you your worst
case transaction size and this can be used to assess the transaction
pinning risk of a bloated witness (all harding).
A future soft fork could give meaning to the annex in Taproot
(darosior) which could be used for inflating the fee rate of a
witness. Then you could have a same-txid-different-wtxid coming after
with a lower fee rate but higher vbytes size to override package
limits (ariard). But fee rate is purely a policy concept and the annex
operates at the consensus level. In addition the annex can only
increase the weight of a transaction, it cannot decrease it (harding).
Wrap up and initial goals
With regards to the goals of the workshops that were initially
announced here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002=
.html
1) 2 transactions packages sounds enough to support currently deployed
L2 protocols
2) There are ongoing discussions in the ecosystem regarding
deprecation of opt in RBF and implementation of full RBF:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.ht=
ml
3) Generally status quo and ad hoc security incident response policy
in the case of cross-layer security issues
4) Generally status quo on L2 security philosophy design. L2 protocol
designers should seek to minimize assumptions on the base layer.
--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
|