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
|
Return-Path: <michaelfolkson@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9BE3BC0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jan 2024 19:27:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 6481F84691
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jan 2024 19:27:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6481F84691
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=JaObX/HQ
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,
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 nfO7yNsd5-WC
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jan 2024 19:27:47 +0000 (UTC)
Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com
[51.77.79.158])
by smtp1.osuosl.org (Postfix) with ESMTPS id B2EFD84690
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 19 Jan 2024 19:27:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B2EFD84690
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1705692457; x=1705951657;
bh=VEjd0Kxu3v+OJIzzm1L5r/pYxwhPYQ3qPujPusiIi5E=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=JaObX/HQeRTkMPbc7yVOvKccWW9+vYzIK5FRNTTNFkt2nztjaxHKZD240Hm4B90Bz
pQkd/1kftY/ycXxG3WfJgYCTj5jWuoTR1Xyl9GbWwa0NACyTn3zzDYFfG0y7mF/EYo
XYdzWGu6n0G5EzaE6Aw91x/T8lJknVK/RwWABjtwpN7rr95c31cbYufectpzq3Qwdv
chRyrcUJgDlqzqM2Gwrd+i0gsCPXSBMRyDtQLyZiQLqcciOSAI9pQcz9QabG+RodQD
hSngIMYgMhzN6FOPpNLjnrq7ePyH3hKYPvX0vy2pjr3cHJfIJF7AYirZuEDm70p0wW
0wMFO8MuenMSA==
Date: Fri, 19 Jan 2024 19:27:30 +0000
To: Peter Todd <pete@petertodd.org>
From: Michael Folkson <michaelfolkson@protonmail.com>
Message-ID: <WBjioXYlG8LU31KNQAn_r2g7kDGuH4OPUzOhpUqvCM1W43sz70L2KcvHjmFzeBihDTRkXvDGUswJCAZlWitw5ChJYOj3CxW9f-cMmCX33cg=@protonmail.com>
In-Reply-To: <ZalnQqvbxhxm8UG2@petertodd.org>
References: <Zac+rMC/c+qTmSxY@erisian.com.au>
<CACrqygDJRtZN4Oo30=DaFO2KYkn1H+Daxh5cinHKz66Uvn9BVg@mail.gmail.com>
<030e09b8-3831-45ff-92ad-9531ae277f80@dashjr.org>
<6ZZYFympMLvwZ3otE_ebPh3wAuPFYb1BKL_3O_NrlQYKfsAJNlobGrZQjK23BxNeIdJ_8x_SAhgF_po1qO68MI_XONG7aPsnEL45y8SNndQ=@protonmail.com>
<ZalnQqvbxhxm8UG2@petertodd.org>
Feedback-ID: 27732268:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 23 Jan 2024 13:46:37 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP process friction
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: Fri, 19 Jan 2024 19:27:48 -0000
Thanks for this Peter, really helpful.=20
> It is a much more fundamental
standard than Ordinals or Taproot Assets, in the sense that transaction
replacement is expected to be used by essentially all wallets as all wallet=
s
have to deal with fee-rate fluctuations; I do not think that Ordinals or
Taproot assets are appropriate BIP material due to their niche use-case.
Yes I'd personally lean towards this view too. Certainly when you go into a=
lternative asset territory (e.g. Counterparty, Liquid (Network) assets, Tap=
root assets) it is moving away from what you can do with the Bitcoin asset/=
currency and into building a new ecosystem with a different asset/currency.=
I would agree that that should probably be out of scope for *Bitcoin* Impr=
ovement Proposals without having any particular opinion on the utility of a=
ny of those ecosystems.
> just the other day I ran into someone
that didn't know RBF Rule #6 existed, which Core added on top of BIP-125, a=
nd
had made a mistake in their safety analysis of a protocol due to that.
I suspected this might be the case but to actually have a data point to bac=
k that up (beyond I personally find it unnecessarily confusing and hard to =
follow) is helpful, thanks.
> Finally, I think the lesson to be learned here is that mempool policy is =
better
served by *living* documentation that gets updated to reflect the real worl=
d.
There's no easy way for someone to get up to speed on what mempool policy i=
s
actually implemented, and more importantly, *why* it is implemented and wha=
t
trade-offs were made to get there. It's quite possible that this "living
documentation" requirement rules out the BIP process.
I get the "living", evolving point. Policy proposals are definitely differe=
nt to say consensus proposals where assuming they are ever activated you'd =
expect them to stay static for the rest of Bitcoin's existence barring mino=
r cleanups, clarifications etc. However, one possible addition in a new BIP=
3 process would be the introduction of versioning for a particular BIP e.g=
. BIP 789 version 2 which would be more conducive to these evolving proposa=
ls such as policy proposals. You could then update a BIP without needing a =
new BIP number for every material update.
I'll wait to hear what Luke thinks on this. Beyond the friction concern I t=
hink improving the BIP process for consensus and policy proposals would be =
the biggest potential win for a BIP 3 update.
Thanks also to Kalle too for his 18 month stint as a BIP editor :)
--
Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
On Thursday, 18 January 2024 at 18:00, Peter Todd <pete@petertodd.org> wrot=
e:
> On Wed, Jan 17, 2024 at 05:29:48PM +0000, Michael Folkson via bitcoin-dev=
wrote:
>=20
> > Hey Luke
> >=20
> > I'd be happy to pick up working on BIP 3 again ([0], [1]) in light of t=
his issue and others that are repeatedly cropping up (e.g. confusion on the=
recommended flow for working on proposed consensus changes, when to open a=
pull request to bitcoin-inquisition, when to open a pull request to Core, =
when to include/exclude activation params etc).
> >=20
> > I don't think there is much I personally disagree with you on with rega=
rds to BIPs but one issue where I do think there is disagreement is on whet=
her proposed default policy changes can/should be BIPed.
> >=20
> > I previously drafted this on proposed default policy changes [2]:
> >=20
> > "To address problems such as pinning attacks on Lightning and multipart=
y protocols (e.g. vaults) there are and will continue to be draft proposals=
on changing the default policy rules in Bitcoin Core and/or alternative im=
plementations. As these proposals are for default policy rules and not cons=
ensus rules there is absolutely no obligation for Bitcoin Core and/or alter=
native implementations to change their default policy rules nor users to ru=
n any particular policy rules (default or otherwise). The authors of these =
draft proposals are clearly recommending what they think the default policy=
rules should be and what policy rules users should run but it is merely a =
recommendation. There are a lot of moving parts, subtleties and complexitie=
s involved in designing default policy rules so any recommendation(s) to si=
gnificantly upgrade default policy rules would benefit from being subject t=
o a spec process. This would also aid the review of any policy related pull=
requests in Bitcoin Core and/or alternative implementations. An interestin=
g recent case study washttps://github.com/bitcoin/bitcoin/pull/22665and Bit=
coin Core not implementing the exact wording of BIP 125 RBF. In this case (=
for various reasons) as a response Bitcoin Core just removed references to =
BIP 125 and started documenting the replacement to BIP 125 rules in the Bit=
coin Core repo instead. However, it is my view that recommendations for def=
ault policy rules should be recommendations to all implementations, reviewe=
d by Lightning and multiparty protocol developers (not just Bitcoin Core) a=
nd hence they would benefit from being standardized and being subject to a =
specification process. I will reiterate once again though that policy rules=
are not consensus rules. Consensus rules are much closer to an obligation =
as divergences from consensus rules risk the user being forked off the bloc=
kchain and could ultimately end up in network splits. This does not apply t=
o policy rules."
> >=20
> > Are you open to adjusting your stance on proposed policy changes being =
BIPed? I do think it really stunts work on proposed default policy changes =
and people's ability to follow work on these proposals when the specificati=
ons for them are littered all over the place. I've certainly struggled to f=
ollow the latest state of V3 policy proposals without clear reference point=
s for the latest state of these proposals e.g. [3]. In addition some propos=
ed consensus change BIPs are starting to want to include sections on policy=
(e.g. BIP345, OP_VAULT [4]) where it would be much better if they could ju=
st refer to a separate policy BIP rather than including proposals for both =
policy and consensus in the same BIP.
>=20
>=20
> BIP-125 is I think an interesting case study. It is a much more fundament=
al
> standard than Ordinals or Taproot Assets, in the sense that transaction
> replacement is expected to be used by essentially all wallets as all wall=
ets
> have to deal with fee-rate fluctuations; I do not think that Ordinals or
> Taproot assets are appropriate BIP material due to their niche use-case.
>=20
> The V3 proposal, and ephemeral anchors, would be expected to be used by a=
wide
> range of contracting protocols, most notably lightning. This isn't quite =
as
> broad usage as BIP-124 RBF. But it is close. And yes, Core making changes=
to
> what is essentially BIP125 has an impact: just the other day I ran into s=
omeone
> that didn't know RBF Rule #6 existed, which Core added on top of BIP-125,=
and
> had made a mistake in their safety analysis of a protocol due to that.
>=20
> Meanwhile, engineering documentation on V3 is extremely lacking, with bas=
ics
> like worked through use-case examples not being available. We don't even =
have
> solid agreement let alone documentation on how Lightning channels are mea=
nt to
> use V3 transactions and what the trade-offs are. And that has lead to mis=
taken
> claims, such as overstating(1) the benefit V3 transactions in their curre=
nt
> form have for transaction pinning.
>=20
> I don't think V3 necessarily needs a formal BIP. But it would benefit fro=
m a
> proper engineering process where use-cases are actually worked out and an=
alyzed
> properly.
>=20
> Finally, I think the lesson to be learned here is that mempool policy is =
better
> served by living documentation that gets updated to reflect the real worl=
d.
> There's no easy way for someone to get up to speed on what mempool policy=
is
> actually implemented, and more importantly, why it is implemented and wha=
t
> trade-offs were made to get there. It's quite possible that this "living
> documentation" requirement rules out the BIP process.
>=20
> 1) https://petertodd.org/2023/v3-txs-pinning-vulnerability
>=20
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
|