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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C0B11C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 14:46:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 8BAA640CC6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 14:46:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 8BAA640CC6
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=tm/TGsmT
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no 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 6W8qkVyxjk9u
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 14:46:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B0EDE4060D
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com
[IPv6:2607:f8b0:4864:20::f35])
by smtp2.osuosl.org (Postfix) with ESMTPS id B0EDE4060D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 14:46:08 +0000 (UTC)
Received: by mail-qv1-xf35.google.com with SMTP id i9so11526124qvu.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 19 Oct 2022 07:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.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=SKxI1j9qpbi0X/I4HRaPvWBzycCO/MA2pAflyEYIhA8=;
b=tm/TGsmThk1fqnI2igWSIsfbewdfre9jIWsROKNDIriTWZTH1yaE3edkowv54oPONK
7DcQDcCz3tZXQliL3ftYyxVUdajR4MKU3B+qrE1oo0DLRQHH831sxDiYxGYd0fwpWxH/
UGE9+oZTLDuEyM5vMB66OdNFVSOEK/flJRY9ZV2sqNF+MMtyUOTDDeBbcXwYavGYiXNg
QjK6NUTEgQlIZqSdrF42d86qlmjtClFmYxEranCaX7hlspgyIEUmu1ErLRCEd3uk+3G2
bsGdOWswBh6sU7Ut8vWc1tom47ptva0o7uGc533Fz+RygrEasP/pErosC6HtkTA1u2TP
WluA==
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=SKxI1j9qpbi0X/I4HRaPvWBzycCO/MA2pAflyEYIhA8=;
b=XduOggpQoncCj/FUBRwSNGmXR+VWhwfeXMPgmaN/njs8vh3LR/uEo3wyglCQ0aexdA
jpiFsPXbXfzSG8QZh6ZHTfVdlf+OcmARFTrAUGt3LqBfV8ExvcvIPtVKSw7R9ln+8+fo
mo3R417YmumWA3wMBMBVLG9l5tf5+CGZtXNfNbbkv0IDyLZV5BpAaGn9Kzm4tt0gbigA
3b+YGFQHyeFUGK7rhHteKmTWHEl5BLdSuclTtcsGcDhKb7n1rdfX2YvWNwiumkDPrtIi
67XBwwtOxBrKBWrlT9rUoRcGNHkWW0wffjT5MUTA0xDXUIS1x3fO7zqZ5AXpuRc7yqfz
DoYg==
X-Gm-Message-State: ACrzQf3M36RVonMxc9fVLoOluNXL8vhXEbTBTqdTaD+IrggmP0qByhjo
uVEQcjnLhcW/AlWQdvEh1UHK4Zv445LGDN67WfOuSulXkpmBbZM=
X-Google-Smtp-Source: AMsMyM66ehwypr2YmBJitvJ8f+BqEkop6fHRuSqTPV0ypkGYWiHdttOU9mPI+mqBIV3/cRbjRrCp+g5FkXo1oZgqwp8=
X-Received: by 2002:a05:6102:3e88:b0:3a6:e709:108a with SMTP id
m8-20020a0561023e8800b003a6e709108amr4069459vsv.32.1666190756526; Wed, 19 Oct
2022 07:45:56 -0700 (PDT)
MIME-Version: 1.0
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
<CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
In-Reply-To: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 19 Oct 2022 10:45:44 -0400
Message-ID: <CAJowKg+Lp6NBm-H9_Gr6Zoj=-NCFVwpGZoqVOWhAkkw5TDwjYA@mail.gmail.com>
To: Sergej Kotliar <sergej@bitrefill.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002bbd9e05eb644434"
X-Mailman-Approved-At: Wed, 19 Oct 2022 14:53:13 +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: Wed, 19 Oct 2022 14:46:09 -0000
--0000000000002bbd9e05eb644434
Content-Type: text/plain; charset="UTF-8"
> Currently Lightning is somewhere around 15% of our total bitcoin
payments. This is very much not nothing, and all of us here want Lightning
to grow, but I think it warrants a serious discussion on whether we want
Lightning adoption to go to 100% by means of disabling on-chain commerce.
Is this about disabling "on-chain instant commerce"?
- Waiting for confirmation on-chain before shipping a product won't
change, normally it's 15 minutes or so. This doesn't change that.
- An easy way to cancel/rbf a transaction doesn't exist - like you said,
there's no UX for this now, and I don't anticipate one being broadly used
except by inter-exchange transfers, etc.
So what does this change?
- In the rare event that an RBF transaction is received where the fee
level means confirmation times will be slow a merchant will have to wait
very long for at least 1 confirmation, the merchant should alert the user
that the transaction may take longer than the BTC FX rate guarantee window,
and may require additional funds if FX rates change.
- Users with wallets that support RBF can now be encouraged to accelerate
the tx, with help and advice depending on their wallet, in order to lock in
the FX rates
- 0 conf is still viable strategy for releasing an order, as long as fees
are very high, and it's very likely to be included in the next block.
More fee analysis is needed to validate 0 conf and mitigate risks, but now
it is, at least, more "honest" to the true risks.
--0000000000002bbd9e05eb644434
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> Currently Lightning is somewhere around 15% of our to=
tal bitcoin payments. This is very much not nothing, and all of us here wan=
t Lightning to grow, but I think it warrants a serious discussion on whethe=
r we want Lightning adoption to go to 100% by means of disabling on-chain c=
ommerce.<br><div><br></div><div>Is this about disabling "on-chain inst=
ant commerce"?<br><br>=C2=A0- Waiting for confirmation on-chain before=
=C2=A0shipping a product won't change, normally it's 15 minutes or =
so.=C2=A0 This doesn't change that.</div><div><br></div><div>=C2=A0- An=
easy way to cancel/rbf a transaction doesn't exist - like you said, th=
ere's no UX for this now, and I don't anticipate one being broadly =
used except=C2=A0by inter-exchange transfers, etc.</div><div><br></div><div=
>So what does this change?</div><div><br></div><div>=C2=A0- In the rare eve=
nt that an RBF transaction is received where the fee level means confirmati=
on times will be slow a merchant will have to wait very long for at least 1=
confirmation, the merchant should alert the user that the transaction=C2=
=A0may take longer than the BTC FX rate guarantee window, and may require a=
dditional funds if FX rates change.</div><div><br></div><div>=C2=A0- Users =
with wallets that support RBF can now be encouraged to accelerate the tx, w=
ith help and advice depending on their wallet, in order to lock in the FX r=
ates</div><div><br></div><div>=C2=A0- 0 conf is still viable strategy for r=
eleasing an order, as long as fees are very high, and it's very likely =
to be included in the next block.=C2=A0 =C2=A0More fee analysis is needed t=
o validate 0 conf and mitigate risks, but now it is, at least, more "h=
onest" to the true risks.</div><div><br></div></div>
--0000000000002bbd9e05eb644434--
|
