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
|
Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 015D0C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 07:22:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id B9D7940165
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 07:22:45 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org B9D7940165
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
UNPARSEABLE_RELAY=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 WNd0yvXr0sTZ
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 07:22:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4AB3E4014A
Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193])
by smtp2.osuosl.org (Postfix) with ESMTPS id 4AB3E4014A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Oct 2022 07:22:44 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
id 1olPt1-00041d-AR; Thu, 20 Oct 2022 17:22:41 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Thu, 20 Oct 2022 17:22:34 +1000
Date: Thu, 20 Oct 2022 17:22:34 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Sergej Kotliar <sergej@bitrefill.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <Y1D3OkdsCq2pLduG@erisian.com.au>
References: <CABZBVTC5kh7ca3KhVkFPdQjnsPhP4Kun1k3K6cPkarrjUiTJpA@mail.gmail.com>
<CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABZBVTCgiQFtxEyeOU=-SGDQUDthyy7sOgPwiT+OVi35LVivyA@mail.gmail.com>
X-Spam-Score-int: -18
X-Spam-Bar: -
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: Thu, 20 Oct 2022 07:22:46 -0000
On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> The
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed),
You mean "it's quite easily managed, provided the transaction doesn't
opt-in to rbf", right? At least, that's what I understood you saying last
time; ie that if the tx signals rbf, then you just don't do zeroconf no
matter what other trustworthy signals you might see:
https://twitter.com/ziggamon/status/1435863691816275970
(rbf txs seem to have increased from 22% then to 29% now)
> it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end.
> But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
> abused. A risk of X% loss on many payments that's easy to systematically
> abuse is more scary than a rare risk of losing 100% of one occasional
> payment. It's already possible to execute this form of abuse with opt-in
> RBF,
If someone's going to systematically exploit your store via this
mechanism, it seems like they'd just find a single wallet with a good
UX for opt-in RBF and lowballing fees, and go to town -- not something
where opt-in rbf vs fullrbf policies make any difference at all?
It's not like existing wallets that don't let you set RBF will suddenly
get a good UX for replacing transactions just because they'd be relayed
if they did, is it?
> To successfully fool (non-RBF)
> zeroconf one needs to have access to mining infrastructure and probability
> of success is the % of hash rate controlled.
I thought the "normal" avenue for fooling non-RBF zeroconf was to create
two conflicting txs in advance, one paying the merchant, one paying
yourself, connect to many peers, relay the one paying the merchant to
the merchant, and the other to everyone else.
I'm just basing this off Peter Todd's stuff from years ago:
https://np.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytlhh0/
https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
> Currently Lightning is somewhere around 15% of our total bitcoin payments.
So, based on last year's numbers, presumably that makes your bitcoin
payments break down as something like:
5% txs are on-chain and seem shady and are excluded from zeroconf
15% txs are lightning
20% txs are on-chain but signal rbf and are excluded from zeroconf
60% txs are on-chain and seem fine for zeroconf
> 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.
If the numbers above were accurate, this would just mean you'd go from 60%
zeroconf/25% not-zeroconf to 85% not-zeroconf; wouldn't be 0% on-chain.
> For me
> personally it would be an easier discussion to have when Lightning is at
> 80%+ of all bitcoin transactions.
Can you extrapolate from the numbers you've seen to estimate when that
might be, given current trends? Or perhaps when fine-for-zeroconf txs
drop to 20%, since opt-in-RBF txs and considered-unsafe txs would still
work the same in a fullrbf world.
> The benefits of Lightning are many and obvious,
> we don't need to limit onchain to make Lightning more appealing.
To be fair, I think making lightning (and coinjoins) work better is
exactly what inspired this -- not as a "make on-chain worse so we look
better in comparison", but as a "making lightning work well is a bunch
of hard problems, here's the next thing we need in order to beat the
next problem".
> Sidenote: On the efficacy of RBF to "unstuck" stuck transactions
> After interacting with users during high-fee periods I've come to not
> appreciate RBF as a solution to that issue. Most users (80% or so) simply
> don't have access to that functionality, because their wallet doesn't
> support it, or they use a custodial (exchange) wallet etc. Of those that
> have the feature - only the power users understand how RBF works, and
> explaining how to do RBF to a non-power-user is just too complex, for the
> same reason why it's complex for wallets to make sensible non-power-user UI
> around it. Current equilibrium is that mostly only power users have access
> to RBF and they know how to handle it, so things are somewhat working. But
> rolling this out to the broad market is something else and would likely
> cause more confusion.
> CPFP is somewhat more viable but also not perfect as it would require lots
> of edge case code to handle abuse vectors: What if users abuse a generous
> CPFP policy to unstuck past transactions or consolidate large wallets. Best
> is for CPFP to be done on the wallet side, not the merchant side, but there
> too are the same UX issues as with RBF.
I think if you're ruling out both merchants and users being able to add
fees to a tx to get it to confirm, then you're going to lose either way.
Txs will either expire because they've been stuck for more than a week,
and be vulnerable to replacement at that point anyway, or they'll be
dropped from mempools because they've filled up and they were the lowest
fee tx, and be vulnerable to replacement for that reason. In the expiry
case, the merchant can rebroadcast the original transaction to keep it
alive, perhaps with a good chance of beating an attacker to the punch,
but in the full mempool case, you could only do that if you were also
CPFPing it, which you already ruled out.
Cheers,
aj
|
