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"
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF Policy
Precedence: list

------=_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">&gt=
; 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">&gt; 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">&gt; 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">&gt; 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=
">&gt; 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--