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
|
Return-Path: <luke@dashjr.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id D3651C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:04:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id A7E1340136
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:04:22 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A7E1340136
Authentication-Results: smtp2.osuosl.org;
dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org
header.a=rsa-sha256 header.s=zinan header.b=KawJb3mR
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 cdJbqN0NF8Mb
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:04:22 +0000 (UTC)
X-Greylist: delayed 00:07:29 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D7837400AF
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp2.osuosl.org (Postfix) with ESMTP id D7837400AF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Oct 2022 21:04:21 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.151.133.18])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 6B2F338A3113;
Fri, 7 Oct 2022 20:56:23 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1665176211; bh=uUfVnuZTe53h5/SMa7fHbNof30J3KL3vT6hCNryPJKs=;
h=From:To:Subject:Date:References:In-Reply-To;
b=KawJb3mRQBU5ztNjIMX2NJtOatfbyqilTqKcJbwAre6ILJ7tPEqkQRPrP7vyTjpaF
uJFLSzwaR8XICDH6ZdhFWZk69FUA77st7elJEGwOCQoiFEvu6v7QOmOcu29Sx6sZ0G
uA8qqIh/532lxRUkVKYubu6rX+dVba5wl/nrAxeE=
X-Hashcash: 1:25:221007:bitcoin-dev@lists.linuxfoundation.org::44gX2xzZmM7P3SVf:azktN
X-Hashcash: 1:25:221007:dario@muun.com::vC7u8==GkNEwyT4x:bBfZR
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Dario Sneidermanis <dario@muun.com>
Date: Fri, 7 Oct 2022 20:56:21 +0000
User-Agent: KMail/1.9.10
References: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
In-Reply-To: <CAKiPDnTPyduCm2Db0v51m_hbCSGbZcUcCwg9=hwJGKeiFeTWBg@mail.gmail.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202210072056.22296.luke@dashjr.org>
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, 07 Oct 2022 21:04:22 -0000
On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote:
> At the time, we understood we had at least a year from the initial opt-in
> deployment until opt-out was deployed, giving us enough time to adapt Muun
> to the new policies.
Policies are a per-node decision, and cannot be relied on in general.
Full RBF has been the default in Bitcoin Knots for years, and de facto viable
for use on the network even longer.
> However, when reviewing the 24.0 release candidate just
> a few days ago, we realized that zero-conf apps (like Muun) must
> *immediately turn off* their zero-conf features.
RBF deals with UNconfirmed transactions, not zero-confirmed (Lightning).
> I understand this wasn't the intention when designing the opt-in deployment
> mechanism. Given this new information, do you see a path where we can delay
> the opt-in deployment and find a safer way to deploy full-RBF?
Full RBF has been available for users on an opt-in basis since at least 2013,
long before BIP 125 was even conceived of.
> We call zero-conf applications to entities that accept on-chain payments
> from
> *untrusted parties* and will sometimes deliver the paid-for product or
> service
> without waiting for the transaction to be included in a block.
This is unsafe period. RBF does not make it any less unsafe.
> All of these applications are receiving incoming on-chain transactions for
> which
> they don't control the inputs, and performing a risk analysis to decide
> whether
> they are ok with accepting the payment without confirmation.
This is nothing but a false sense of security.
Luke
|
