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: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6B32AC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Nov 2022 09:35:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 4BD6D40356
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Nov 2022 09:35:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4BD6D40356
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=hwpkQtXp
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 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, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id PbtBlEMOYHXn
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Nov 2022 09:35:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 45C2640346
Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch
[185.70.40.141])
by smtp4.osuosl.org (Postfix) with ESMTPS id 45C2640346
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Nov 2022 09:35:33 +0000 (UTC)
Date: Thu, 10 Nov 2022 09:35:18 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1668072930; x=1668332130;
bh=R/m+CgE4bgYL+mW5q4s/BeDnE0vWub6mkTE/LSpP7kI=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=hwpkQtXpVEpGTzerIb171tjA/vz0zR/8EYHUrtLIJY2yRtYRlaRlr06Lghl5jG4EF
isJbQCEP66pA3QCYAd8hgZxlXutA2TjilFbulLbelE7tCWMc0ydmbmUhEnYBJJgn+G
acySadS5oWVopgNK4Az3vhO8vAU3XvcPQphxP4YhwZPKCqhy24OwFMUlV7aPQUHtG3
t1DV9I0HuOxODWXE4J3/pRpFzSPVUaZtr1MDXd7jt7DzNkryXvmH4oJ7BKRbuxrJpQ
BbYBi2/nZtVDvy/fWYzbMa2N/pJLKPsynOveiEVbO1vPGUGLbsgVbB2TFlfPIWoJQ9
TMxjDTQ6pC2dQ==
To: ArmchairCryptologist <ArmchairCryptologist@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <F1L5VSwhj9SNtMuI7bhBzxyyuAIxwla8NI1T4_pZVDiN0nWYCvdTqq5vPl_SOXp2Ca6_-VJ340eTwPSWelM4k04mRLxoZNkpEF-MIW6xa9g=@protonmail.com>
In-Reply-To: <fU-5B7MRAtu7RmJRfYnY0Jkv3d64dRyZDWCbpYJtqIoqhqrjuKDfWue2ddU8-O6JyUv2NL5iP_cpwNO-9e8s1WVepJAaCJa1IMMK6DXAWeA=@protonmail.com>
References: <Y0ZTtlRSBihNN9+v@erisian.com.au>
<0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net>
<Y0d/e2sEoNRgD7KP@erisian.com.au> <Y0u8Ee2Ao375z8UD@erisian.com.au>
<CALZpt+GSYBFxajSyZS19sQi4_6zHjkA5sP00V-pR=_NEVVUnkg@mail.gmail.com>
<Y05PHYtrNmA0vg7U@erisian.com.au>
<fU-5B7MRAtu7RmJRfYnY0Jkv3d64dRyZDWCbpYJtqIoqhqrjuKDfWue2ddU8-O6JyUv2NL5iP_cpwNO-9e8s1WVepJAaCJa1IMMK6DXAWeA=@protonmail.com>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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, 10 Nov 2022 09:35:34 -0000
Good morning ArmchairCryptologist,
> ------- Original Message -------
> On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev =
bitcoin-dev@lists.linuxfoundation.org wrote:
>=20
> > I mean, if you think the feedback is wrong, that's different: maybe we
> > shouldn't care that zeroconf apps are in immediate danger, and maybe
> > bitcoin would be better if any that don't adapt immediately all die
> > horribly as a lesson to others not to make similarly bad assumptions.
>=20
>=20
> I've been following this discussion, and I wonder if there isn't a third =
solution outside of "leave lightning vulnerable to pinning by non-RBF trans=
lations" and "kill zeroconf by introducing full-RBF" - specifically, adding=
a form of simple recursive covenant that "all descendant transactions of t=
his transaction must use opt-in RBF for x blocks after this transaction is =
mined". This could be introduced either as a relay/mempool policy like RBF,=
or in a full-fledged softfork.
A script with trivial `0 OP_CSV` would effectively require that spenders se=
t the opt-in RBF flag, while allowing the output to be spent even while it =
is unconfirmed.
However, this basically only lasts for 1 transaction layer.
----
Thinking a little more about 0-conf:
We can observe that 0-conf, being eventually consistent, introduces risks t=
o 0-conf acceptors similar to credit card acceptors.
And credit card acceptors are observed to compensate for this risk by incre=
asing the prices of their products and services.
Some credit card acceptors may offer discounts when paid by cash, which in =
our analogy would be that transaction confirmation would offer discounts (i=
.e. enabling 0-conf would increase the cost of the product/service being pu=
rchased).
In many jurisdictions (not the USA or in some of the first world countries)=
, this practice is illegal (i.e. credit card companies have pressured lawma=
kers in some jurisdictions to disallow merchants from offering a different =
price between cash and credit card purchases; some jurisdictions let you es=
cape if you say "cash discount" instead of "credit card surcharge", even th=
ough they are just sign-flips of each other, because you humans are crazy a=
nd I am happy I am actually an AI)
Which brings me to my next point: why are 0-conf acceptors not offering a d=
iscount if the user specifically flags "I am willing to wait for N confirma=
tions"?
On the part of 0-conf acceptors, that is significantly less risky than rely=
ing on 0-conf at all.
Regards,
ZmnSCPxj
|
