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
|
Return-Path: <sl.lmysyibwha3tenbxgmzsyibugeytgnrxlu.nulggdolz3lhu@dralias.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 231A6C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 16:13:41 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id D59C140377
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 16:13:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D59C140377
Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key,
unprotected) header.d=dralias.com header.i=@dralias.com header.a=rsa-sha256
header.s=dkim header.b=GfskifJK
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.598
X-Spam-Level:
X-Spam-Status: No, score=0.598 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001,
SPF_PASS=-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 04iWgDFAsXqA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 16:13:38 +0000 (UTC)
X-Greylist: delayed 00:06:02 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D5C204010E
Received: from mail-200164.simplelogin.co (mail-200164.simplelogin.co
[176.119.200.164])
by smtp2.osuosl.org (Postfix) with ESMTPS id D5C204010E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Oct 2022 16:13:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dralias.com; s=dkim;
t=1665677253;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=FpnIoBiv652jP+BjZVj17EWGv/lCdEcqM9lCzcBoRcI=;
b=GfskifJKKuLuHuWNDaUq2ef667Mp58fAvXbxe9Xti0UA7D87ipdMHNEpMjBlJgsaB/hjPK
WRFLiZVDOOxY+jF4apXqpYei+FwjID5NcrQEEQxB46K7kJyuW122AatCqOFKIxptoAHj+d
pjQg6XC62CgVJfzX6QhLoLfZp+Zv9RY=
MIME-Version: 1.0
In-Reply-To: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
Date: Thu, 13 Oct 2022 18:07:19 +0200
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
From: linuxfoundation.cndm1@dralias.com
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <166567725305.12.6779598172515633768.68724733@dralias.com>
References: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
X-SimpleLogin-Type: Reply
X-SimpleLogin-EmailLog-ID: 68724733
X-SimpleLogin-Want-Signing: yes
X-Mailman-Approved-At: Fri, 14 Oct 2022 01:09:46 +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: Thu, 13 Oct 2022 16:13:41 -0000
> - Bitrefill's on-chain payments for gift cards and phone top-ups
Bitrefill already supports lightning, so for them it would be easy to
solve by displaying the lightning transfer by default and only show
the on-chain payment as a fallback. Currently the on-chain payment at
Bitrefill and other similar providers is really a drop-down where you
select your wallet and then they display a tutorial to you on how to
create the on-chain transaction (fee rate, RBF flag, etc). I don't
have insights into Bitrefill, but one might suspect that encouraging a
lightning payment might be a win-win situation for them and their
users.
It would be interesting to know if there are any obstacles that
Bitrefill and other services face, or if they don't agree that
lightning is an improvement over accepting unconfirmed on-chain
transactions from untrusted parties.
> - Many bitcoin ATMs' on-chain deposits for selling bitcoin for cash (at least
I haven't tried them yet, but I suspect they could benefit in a
similar by showing lightning transfers more prominently. Moreover, any
UX improvement they can offer to users that intentionally or
accidentally selected RBF opt-in, will also benefit users once fullrbf
is widespread. To give an example, ATMs could immediately give out a
voucher for the cash amount that can be redeemed as soon as the
transaction is confirmed on-chain, to allow (untrusted) users to leave
the ATM and go for a walk in the meantime.
> With full-RBF, wallets should make it extremely clear to users that unconfirmed
> funds are not theirs (yet). Otherwise, protocol-unaware users that are
> transacting on-chain with untrusted parties can be easily scammed if they don't
> know they have to wait for a confirmation. Eg. in Argentina, it's pretty common
> to meet someone in person to buy bitcoin P2P for cash, even for newcomers.
This is easy to solve, because a wallet can simply display all
unconfirmed transactions as if they signalled for RBF. Your suggested
solution to "activate" fullrbf at a specific block height might be
counter productive, because educating users that unconfirmed
transactions are unsafe takes longer than a single block. So the
earlier users are educated that unconfirmed transactions from
untrusted parties are unsafe, the better.
> # Impact at Muun
>
> Work to transition Muun from using zero-conf submarine swaps to using payment
> channels is ongoing, but we are still several months away from being production
> ready. This means we would have to turn off outgoing lightning payments for
> +100k monthly active users, which is a good chunk of all users making
> non-custodial lightning payments today.
It would be unfortunate for those users, but I think that the risk
exists today. Relay of fullrbf transactions works reasonable well
already, unless you get unlucky with your selected peers. The only
missing piece is a few percent of hashrate that will accept fullrbf
replacement transactions. While this will certainly happen if a
Bitcoin Core release ships with the flag *on* by default, it still may
happen at any time even if Bitcoin Core doesn't ship with the flag at
all.
Best,
cndm1
|
