From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A1730C000B for ; 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 ; 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 ; 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 ; 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 To: Bastien TEINTURIER Message-ID: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 = considering they rely on policy that cannot be enforced?

> For starters, let me quickly exp= lain why the current rules are hard to work with in the context of lightnin= g

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.=

> 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

Not sure I understa= nd this part because if a transaction is on-chain it can't be replaced.&nbs= p;

> The second b= iggest pain point is rule 3. It prevents me from efficiently using my capit= al while it's unconfirmed

> I'm curious to hear other people's thoughts on that. If it makes sen= se, I would propose the following very simple rules
=
Looks interesting however not sure about X and = Y.


--
Prayank

A3B1 E430 229= 8 178F
------=_Part_420031_359499758.1643683638261--