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
|
Return-Path: <prayank@tutanota.de>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id A1730C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 02:47:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 8CDAA40954
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 02:47:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 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, HTML_MESSAGE=0.001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=tutanota.de
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 Kl7Z-pd39XM5
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 02:47:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
by smtp2.osuosl.org (Postfix) with ESMTPS id 3565940952
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Feb 2022 02:47:20 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
by w1.tutanota.de (Postfix) with ESMTP id 433E2FBF642;
Tue, 1 Feb 2022 02:47:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1643683638;
s=s1; d=tutanota.de;
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender;
bh=juT206Ov6xnOBC4XYd2UbU9JSJGTflrnm6o2Hj82wqE=;
b=aY/27bmC2G7kl15tTVL+mSMqOg5/TtorKwNuW5wC3Lb2S8ft4YwxwE01kmeom+xk
16D4emUldLjShA/zvBoB3TJNwLPgttFN4iZ4AR1yg+1EaKXu0+bd1J4ZPVXEqgXXbKt
R34lhunccStaNPPmeEm08LR9kUqPUqY/qwjv6yPa9b4IqM6rdczv1tgqJK6tAce6Xgj
1qcHAx7q/5kgUk+0eD3X3T1+2kY7ylF7mOzT3tljDDlNulGYTv2LU/+IJ7zTw8iqJtx
ASjoFedarjWlNYhYfBG6Br1wZW7Cm7vyzmcuo2guVl1y+hPcEuFodCp4Qn1l9VmU5bW
9+g3E/iD+w==
Date: Tue, 1 Feb 2022 03:47:18 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Bastien TEINTURIER <bastien@acinq.fr>
Message-ID: <MunATIf--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_420031_359499758.1643683638261"
X-Mailman-Approved-At: Tue, 01 Feb 2022 09:13:31 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF Policy
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: Tue, 01 Feb 2022 02:47:22 -0000
------=_Part_420031_359499758.1643683638261
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Bastein,
> This work will highly improve the security of any multi-party contract tr=
ying to build on top of bitcoin
Do you think such multi party contracts are vulnerable by design considerin=
g they rely on policy that cannot be enforced?
> For starters, let me quickly explain why the current rules are hard to wo=
rk with in the context of lightning
Using the term 'rules' can be confusing sometimes because it's just a polic=
y and different from consensus rules. I wish we could change this in the BI=
P with something else.
> I'm actually paying a high fee twice instead of once (and needlessly usin=
g on-chain space, our scarcest asset, because we could have avoided that ad=
ditional transaction
Not sure I understand this part because if a transaction is on-chain it can=
't be replaced.=C2=A0
> The second biggest pain point is rule 3. It prevents me from efficiently =
using my capital while it's unconfirmed
> I'm curious to hear other people's thoughts on that. If it makes sense, I=
would propose the following very simple rules
Looks interesting however not sure about X and Y.
--=20
Prayank
A3B1 E430 2298 178F
------=_Part_420031_359499758.1643683638261
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body>
<div>Hi Bastein,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">>=
; This work will highly improve the security of any multi-party contract tr=
ying to build on top of bitcoin</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Do you think such multi party contracts are vulnerable by design =
considering they rely on policy that cannot be enforced?<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">> For starters, let me quickly exp=
lain why the current rules are hard to work with in the context of lightnin=
g</div><div dir=3D"auto"><br></div><div dir=3D"auto">Using the term 'rules'=
can be confusing sometimes because it's just a policy and different from c=
onsensus rules. I wish we could change this in the BIP with something else.=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">> I'm actually p=
aying a high fee twice instead of once (and needlessly using on-chain space=
, our scarcest asset, because we could have avoided that additional transac=
tion</div><div dir=3D"auto"><br></div><div dir=3D"auto">Not sure I understa=
nd this part because if a transaction is on-chain it can't be replaced.&nbs=
p;<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">> The second b=
iggest pain point is rule 3. It prevents me from efficiently using my capit=
al while it's unconfirmed</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">> I'm curious to hear other people's thoughts on that. If it makes sen=
se, I would propose the following very simple rules</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Looks interesting however not sure about X and =
Y.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div>-- <br=
></div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 229=
8 178F<br></div> </body>
</html>
------=_Part_420031_359499758.1643683638261--
|
