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
|
Return-Path: <john@synonym.to>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B6AF3C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Nov 2023 08:58:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 84DCF4EFFA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Nov 2023 08:58:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 84DCF4EFFA
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=synonym-to.20230601.gappssmtp.com
header.i=@synonym-to.20230601.gappssmtp.com header.a=rsa-sha256
header.s=20230601 header.b=dzWf387e
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id om3oxKhIPsbg
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Nov 2023 08:58:49 +0000 (UTC)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
[IPv6:2607:f8b0:4864:20::b31])
by smtp4.osuosl.org (Postfix) with ESMTPS id 05A224F02A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Nov 2023 08:58:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 05A224F02A
Received: by mail-yb1-xb31.google.com with SMTP id
3f1490d57ef6-d9c7bba32beso695324276.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 02 Nov 2023 01:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=synonym-to.20230601.gappssmtp.com; s=20230601; t=1698915527; x=1699520327;
darn=lists.linuxfoundation.org;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=SPAngvt89vF/2azbAEZzBt8/kgajwrxfOzF3wNFE6b0=;
b=dzWf387eq6Cu3Fbj+n27KZYeqaXMgt2heB1Ej6niSPhKhCP0sy8Ed2Y5WpgC3gl8vp
oayLxsWc3l9Krk151l52qqdqism0V9k7q5tOulVjRksDdln1J3QDDsdK+bH760QkUznF
MVs4LT8Eh6Z6ILf1gMP8BkmkG4auybvltOxcVbbB0v7tQLvTxv4HoOPTRMj8/Ee9ZpHm
A055l/1+ec70EHu1OWLeYQyWlLfidjlDx6n2FKUbCOcQGfk6RH04sgijGce4EJr3soGl
NczF0dt/Qy4u30lTYHa8rTNJgBoFvJSysL5vQfFk5edOb5hvQ4vz9/+uzD7LN80IMF+y
z3Kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1698915527; x=1699520327;
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=SPAngvt89vF/2azbAEZzBt8/kgajwrxfOzF3wNFE6b0=;
b=vHTj6bNv7/8X50ViA/FFrWbm+3brWu2D9qW78TSUh+S0amAw6hGK386lS9cDK3aMqX
FQD2D8FuwXR5FA7p3oj4CjBxooFX1q0i/hU9iCgc/KFEvE65CLzxYR1rkIg5PoJP20Jo
V4fgqYG5a8biSGcD5gnH1TG+BeZ1tEPnUpKqHT/eSYbTHTQa4o73FoE5v3o7yWFJgn//
KNDehWD5hK5WN855jf1XU7IyHfHPbPmun+147eE8kRIsfqFsagxoK0OK6/1vTsX44IBY
m/LKoVtu6joMs9nxgdEVUpFU3ZGfmK/azgnrhtiTT20Tssrpt+6AnNnPP0Rpv3CKjp+H
u82Q==
X-Gm-Message-State: AOJu0Ywg77oD2hSasXR62iAgtz6iQ9JsXcXSeaGWAr66PNxmhD3ug9Jx
ClvxKRj9heRVCm5MRIMKJkWEr4QI25yDzSGRjGk4xHs3ew9KjMH2EUU=
X-Google-Smtp-Source: AGHT+IEhJs0apq61cwewi7i4qEzivs3VuuNTJ3QCkNZzWVgFPyIcVM3OrFs/dgo/LTFAYqJrtKeNXhPlxq8/bjInyNc=
X-Received: by 2002:a25:30d:0:b0:d15:7402:f7cd with SMTP id
13-20020a25030d000000b00d157402f7cdmr19141608ybd.27.1698915527366; Thu, 02
Nov 2023 01:58:47 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.10748.1698911611.1202.lightning-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.10748.1698911611.1202.lightning-dev@lists.linuxfoundation.org>
From: John Carvalho <john@synonym.to>
Date: Thu, 2 Nov 2023 08:58:36 +0000
Message-ID: <CAHTn92z9RhrHd=quYwfbj9y9gvA4aGX=JGNv9UggR4cWSZE9Xw@mail.gmail.com>
To: Bitcoin-Dev Mailing List <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000832e3006092798ab"
X-Mailman-Approved-At: Thu, 02 Nov 2023 11:36:06 +0000
Subject: [bitcoin-dev] The Pinning & Replacement Problem Set
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: Thu, 02 Nov 2023 08:58:53 -0000
--000000000000832e3006092798ab
Content-Type: text/plain; charset="UTF-8"
Good morning,
All layers and technologies "on" Bitcoin will fail in situations where
miners misbehave or the blocks & mempool remain consistently, overly full.
Consider this as a "law" of Bitcoin/blockchains.
In hindsight (for you, not me) it was very unwise to start messing with
mempool policies, like with RBF, mempoolfullrbf. First-seen policy brought
a fragile harmony and utility to Bitcoin, which we were lucky to have for
as long as we could.
The engineers intentionally broke this. Mempoofullrbf washes away the
ability for users to express their intent on whether to pin or replace a
transaction, and now Lightning has BOTH pinning and replacement problems.
You could argue this was inevitable. The point here is that layers have
mempool and miner problems.
Core has a few choices here, as I see it:
1. They can try to revert mempoolfullrbf and re-establish first-seen
policy. Hard to say whether this would work, or whether it would be
enough...
2. They can create additional policies that are enforced by default that
allow people to flag how they want their txn handled, as in, a "pin this"
vs "replace this" aspect to every txn. This is probably the best option, as
it allows miners to know what people want and give it to them. This is
utility, thus incentive-compatible.
3. Remove all policy and let the market evolve to deal with the chaos.
Which is similar to the next option: do nothing.
4. Do nothing and allow a fractured mempool environment to evolve where
large businesses form private contracts with miners and pools to support
their own unsupported policies, so they can provide better experiences to
customers and users.
5. Invent some miracle magical crypto cure that I am not capable of
imagining at this time.
I disclaim some ignorance to details of how other mempool research might
affect these options and problems, but I am skeptical the dynamics
discussed here can be removed entirely.
--John Carvalho
CEO, Synonym.to <http://synonym.to/>
--000000000000832e3006092798ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr" class=3D"gmail_signature=
"><div dir=3D"ltr"><div dir=3D"ltr" style=3D""><div dir=3D"ltr" style=3D"">=
Good morning,=C2=A0</div><div dir=3D"ltr" style=3D""><br></div><div dir=3D"=
ltr" style=3D"">All layers and technologies "on" Bitcoin will fai=
l in situations where miners misbehave or the blocks & mempool remain c=
onsistently, overly full. Consider this as a "law" of Bitcoin/blo=
ckchains.=C2=A0</div><div dir=3D"ltr" style=3D""><br></div><div dir=3D"ltr"=
style=3D"">In hindsight (for you, not me) it was very unwise to start mess=
ing with mempool policies, like with RBF, mempoolfullrbf. First-seen policy=
brought a fragile harmony and utility to Bitcoin, which we were lucky to h=
ave for as long as we could.=C2=A0</div><div dir=3D"ltr" style=3D""><br></d=
iv><div dir=3D"ltr" style=3D"">The engineers intentionally broke this. Memp=
oofullrbf washes away the ability for users to express their intent on whet=
her to pin or replace a transaction, and now Lightning has BOTH pinning and=
replacement problems. You could argue this was inevitable. The point here =
is that layers have mempool and miner problems.</div><div dir=3D"ltr" style=
=3D""><br></div><div dir=3D"ltr" style=3D"">Core has a few choices here, as=
I see it:=C2=A0</div><div dir=3D"ltr" style=3D""><br></div><div dir=3D"ltr=
" style=3D"">1. They can try to revert mempoolfullrbf and re-establish firs=
t-seen policy. Hard to say whether this would work, or whether it would be =
enough...=C2=A0</div><div dir=3D"ltr" style=3D""><br></div><div dir=3D"ltr"=
style=3D"">2. They can create additional policies that are enforced by def=
ault that allow people to flag how they want their txn handled, as in, a &q=
uot;pin this" vs "replace this" aspect to every txn. This is=
probably the best option, as it allows miners to know what people want and=
give it to them. This is utility, thus incentive-compatible.=C2=A0</div><d=
iv dir=3D"ltr" style=3D""><br></div><div dir=3D"ltr" style=3D"">3. Remove a=
ll policy and let the market evolve to deal with the chaos. Which is simila=
r to the next option: do nothing.=C2=A0</div><div dir=3D"ltr" style=3D""><b=
r></div><div dir=3D"ltr" style=3D"">4. Do nothing and allow a fractured mem=
pool environment to evolve where large businesses form private contracts wi=
th miners and pools to support their own unsupported policies, so they can =
provide better experiences to customers and users.=C2=A0</div><div dir=3D"l=
tr" style=3D""><br></div><div dir=3D"ltr" style=3D"">5. Invent some miracle=
magical crypto cure that I am not capable of imagining at this time.</div>=
<div dir=3D"ltr" style=3D""><br></div><div style=3D"">I disclaim some ignor=
ance to details of how other mempool research might affect these options an=
d problems, but I am skeptical the dynamics discussed here can be removed e=
ntirely.</div><div dir=3D"ltr" style=3D""><br>--John Carvalho</div><div dir=
=3D"ltr" style=3D"color:rgb(34,34,34)">CEO,=C2=A0<a href=3D"http://synonym.=
to/" style=3D"color:rgb(17,85,204)" target=3D"_blank">Synonym.to</a></div><=
/div></div></div></div></div>
--000000000000832e3006092798ab--
|
