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
|
Return-Path: <john@synonym.to>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5EFF3C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Oct 2022 10:03:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 31B4940606
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Oct 2022 10:03:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 31B4940606
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com
header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=XO6vZ6yB
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, 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 smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NdKN9OHDpXHG
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Oct 2022 10:03:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CAF6640439
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com
[IPv6:2607:f8b0:4864:20::82e])
by smtp2.osuosl.org (Postfix) with ESMTPS id CAF6640439
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Oct 2022 10:03:33 +0000 (UTC)
Received: by mail-qt1-x82e.google.com with SMTP id c23so3324321qtw.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Oct 2022 03:03:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=synonym-to.20210112.gappssmtp.com; s=20210112;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=x8IE200q9VQ+W6eGU8NTmww6ZIBMd9GubwVBSnfhGpA=;
b=XO6vZ6yBPQjlBBU4c3TBen6RSkTLyyE52Qzo/8W+7BRp19I/3JyRRCiEccCS94+dQw
AqN6SVV15ncDzZy2tuqRPlc8Il7nhwZn8+Gq7pe5u8wizhYJha0zNPZVFySAH3XY3lJk
hwHO5OCOz/Hx44OFfRlJRjxeUBMuGX7X+mYkI75b2nRjGfW7A/bwE65tRTY0xYG1Z9E+
PzJ/3hLE2EfDrUN6tSCyzRn0kbCwQIkytflsNltVVMDuDhQ/4qbc0XPIKW0WOy9dM2TL
7co17BIBpHeRAlMPRVW3pNn94Vf1ZBRMnHrUSbL+lLK8n4DjeBcfRgZPDp5+EUye1/tG
r68Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
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=x8IE200q9VQ+W6eGU8NTmww6ZIBMd9GubwVBSnfhGpA=;
b=xiKic5CA6BUk3k3OTCB4XSJNz9aZGYBh1TYK5BDljtyjTjS3txj99ol6k157nNrfwq
jXCyyY3dcHrZqjTKP7h5mYMggkX1ntI2q5BakvS58e+0iyDgy9PR+dy8GDCSNuJQbOR+
2reWGERLjWcOibZFAXJ0cBkneHtchT5fFR0Q9DqCi7axr7hE58IF4er4f5IohqqBQdsC
kg+Er5KwS+4TkeNMjoojg7ymf/hfBO4eYFgdga+gW1T+BWQNRSVws8oq3mpouvxq4+s0
yXyY+0g+7cEi4jLgTv0+KFzx4pXeWeoVYgmty819JWJY5KVq7Ca0o2pVnxjHeJUATqfx
XlXQ==
X-Gm-Message-State: ACrzQf01BgekHdAvy4CENeb2Hf3TWynR0NNhwxzBqTVPtn/pvAdRxS8E
q5VGhBUKIUNSMfctPbTbKPdwyNZUiwv6rlIa306jgciyab7owCRfFDM=
X-Google-Smtp-Source: AMsMyM6WVqoa9WBXOj4sdWATdcUV5hLvw30QoclSafyBZKeBz24bxLheViUjVykAn5IQdO8k6IYSUt39BXcX8Z7ht/I=
X-Received: by 2002:ac8:5e12:0:b0:35c:bd2e:9ccd with SMTP id
h18-20020ac85e12000000b0035cbd2e9ccdmr3374464qtx.522.1665741812254; Fri, 14
Oct 2022 03:03:32 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.7.1665662404.16405.bitcoin-dev@lists.linuxfoundation.org>
From: John Carvalho <john@synonym.to>
Date: Fri, 14 Oct 2022 12:03:21 +0200
Message-ID: <CAHTn92x8-20SjMRs=+vbtvbvocSUM9gVEmHkhuifXeApANFXfg@mail.gmail.com>
To: "Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000001e16b05eafbbd48"
X-Mailman-Approved-At: Fri, 14 Oct 2022 11:08:20 +0000
Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate
danger
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, 14 Oct 2022 10:03:35 -0000
--00000000000001e16b05eafbbd48
Content-Type: text/plain; charset="UTF-8"
In support of Dario's concern, I feel like there is a degree of gaslighting
happening with the advancement of RBF somehow being okay, while merchants
wanting to manage their own 0conf risk better being not okay.
The argument against 0conf acceptance seems to be "miners can facilitate
doublespends anyway, and are incentivized to do so if the fees are higher"
as this is just how Bitcoin works.
But RBF proponents seem to be taking what is actually a much rarer, and
less useful, use case of replacing txns that lowball feerates, or actually
undoing/doublespending previously signed payments... and threaten the use
case of onchain bitcoin being useful at the point-of-sale for merchants and
consumers.
I can tell you right now where this leads. It leads to miners, merchants
and consumers creating alternative fee mechanisms and trusted/exclusive
mempools where first-seen txns are respected.
The truth is that doublespending is not a certain process, and in many
commercial situations, too risky to attempt without real-world consequences.
0conf payment acceptance comes with highly *manageable* risks, which means
that if best practices and methods are used by merchants, and *gasp*
advanced by engineers with better tools and specs, that we can have fast
and valuable commercial payments with merchants that meet user
expectations. In fact, we may even be able to do so with less complexity
than Lightning and with similar results and overhead...
That said, we are (myself and a group of builders and merchants) moving
forward with demonstrating, protecting, and advancing this use case,
to contrast the trend of making the mempool less predictable and easier to
replace.
RBF causes more problems than it resolves, and if your argument is that
0conf was never safe, then mine is that RBF was never needed. We should not
pretend that the mempool is enforceable for either cause, and should
respect that incentives will always prevail eventually.
To me, use cases for spending Bitcoin are more important to protect than
features for pretending you can enforce mempool behaviors or pretending you
can reliably provide replacement features.
If anyone is interested in research, specs, and tools and assisting our
group, you can contact me directly, or join the public chat at
https://t.me/bitcoinandlightningspecs
Thanks,
--
John Carvalho
CEO, Synonym.to <http://synonym.to/>
>
>
--00000000000001e16b05eafbbd48
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">In support of Dario's concern, I feel=
like there is a degree of gaslighting happening with the advancement of RB=
F somehow being okay, while merchants wanting to manage their own 0conf ris=
k better being not okay.=C2=A0</div><div dir=3D"ltr"><br></div><div dir=3D"=
ltr">The argument against 0conf acceptance seems to be "miners can fac=
ilitate doublespends anyway, and are incentivized to do so if the fees are =
higher" as this is just how Bitcoin works.</div><div dir=3D"ltr"><br><=
/div><div dir=3D"ltr">But RBF proponents seem to be taking what is actually=
a much rarer, and less useful, use case of replacing txns that lowball fee=
rates, or actually undoing/doublespending previously signed payments... and=
threaten the use case of onchain bitcoin being useful at the point-of-sale=
for merchants and consumers.</div><div dir=3D"ltr"><br></div><div dir=3D"l=
tr">I can tell you right now where=C2=A0this leads. It leads to miners, mer=
chants and consumers creating alternative fee mechanisms and trusted/exclus=
ive mempools where first-seen txns are respected.</div><div dir=3D"ltr"><br=
></div><div dir=3D"ltr">The truth is that doublespending=C2=A0is not a cert=
ain process, and in many commercial situations, too risky to attempt withou=
t real-world consequences.</div><div dir=3D"ltr"><br></div><div dir=3D"ltr"=
>0conf payment acceptance comes with highly *manageable* risks, which means=
that if best practices and methods are used by merchants, and *gasp* advan=
ced by engineers with better tools and specs, that we can have fast and val=
uable commercial payments with merchants that meet user expectations. In fa=
ct, we may even be able to do so with less complexity than Lightning and wi=
th similar results and overhead...=C2=A0</div><div dir=3D"ltr"><br></div><d=
iv>That said, we are (myself and a group of builders and merchants) moving =
forward with demonstrating, protecting, and advancing this use case, to=C2=
=A0contrast the trend of making the mempool less predictable and easier to =
replace.=C2=A0</div><div><br></div><div>RBF causes more problems than it re=
solves, and if your argument is that 0conf was never safe, then mine is tha=
t RBF was never needed. We should not pretend that the mempool is enforceab=
le for either cause, and should respect that incentives will always prevail=
eventually.=C2=A0</div><div><br></div><div>To me, use cases for spending B=
itcoin are more important to protect than features for pretending you can e=
nforce mempool behaviors or pretending you can reliably provide replacement=
features.</div><div><br></div><div>If anyone is interested in research, sp=
ecs, and tools and assisting our group, you can contact me directly, or joi=
n the public chat at=C2=A0<a href=3D"https://t.me/bitcoinandlightningspecs"=
>https://t.me/bitcoinandlightningspecs</a></div><div><br></div><div>Thanks,=
</div><div dir=3D"ltr"><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gma=
il_signature"><div dir=3D"ltr"><span style=3D"color:rgb(34,34,34)">--</span=
><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" style=3D"color:rgb(34,3=
4,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D"ltr">CEO,=C2=A0<a hr=
ef=3D"http://synonym.to/" style=3D"color:rgb(17,85,204)" target=3D"_blank">=
Synonym.to</a><br></div></div></div></div></div></div><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>
--00000000000001e16b05eafbbd48--
|
