From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 337FFCAB;
	Fri, 25 Oct 2019 17:30:47 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [69.59.18.99])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 042F287B;
	Fri, 25 Oct 2019 17:30:45 +0000 (UTC)
Received: from [69.59.18.158] (unknown [69.59.18.158])
	by mail.bluematt.me (Postfix) with ESMTPSA id 44B27E242E;
	Fri, 25 Oct 2019 17:30:43 +0000 (UTC)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83
Content-Transfer-Encoding: 7bit
From: Matt Corallo <lf-lists@mattcorallo.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 25 Oct 2019 07:30:41 -1000
Message-Id: <6728FF51-E378-4AED-99BA-ECB83688AA9C@mattcorallo.com>
References: <CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com>
In-Reply-To: <CAD3i26Cf+QpbFXh63NiMig9eceeKaezZwk89A_h_76S_XKkQ9g@mail.gmail.com>
To: =?utf-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com>
X-Mailer: iPhone Mail (17A878)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	MIME_QP_LONG_LINE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction
	Issues in Contracting Applications (eg Lightning)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 25 Oct 2019 17:30:47 -0000


--Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I don=E2=80=99te see how? Let=E2=80=99s imagine Party A has two spendable ou=
tputs, now they stuff the package size on one of their spendable outlets unt=
il it is right at the limit, add one more on their other output (to meet the=
 Carve-Out), and now Party B can=E2=80=99t do anything.

> On Oct 24, 2019, at 21:05, Johan Tor=C3=A5s Halseth <johanth@gmail.com> wr=
ote:
>=20
> =EF=BB=BF
> It essentially changes the rule to always allow CPFP-ing the commitment as=
 long as there is an output available without any descendants. It changes th=
e commitment from "you always need at least, and exactly, one non-CSV output=
 per party. " to "you always need at least one non-CSV output per party. "
>=20
> I realize these limits are there for a reason though, but I'm wondering if=
 could relax them. Also now that jeremyrubin has expressed problems with the=
 current mempool limits.
>=20
>> On Thu, Oct 24, 2019 at 11:25 PM Matt Corallo <lf-lists@mattcorallo.com> w=
rote:
>> I may be missing something, but I'm not sure how this changes anything?
>>=20
>> If you have a commitment transaction, you always need at least, and
>> exactly, one non-CSV output per party. The fact that there is a size
>> limitation on the transaction that spends for carve-out purposes only
>> effects how many other inputs/outputs you can add, but somehow I doubt
>> its ever going to be a large enough number to matter.
>>=20
>> Matt
>>=20
>> On 10/24/19 1:49 PM, Johan Tor=C3=A5s Halseth wrote:
>> > Reviving this old thread now that the recently released RC for bitcoind=

>> > 0.19 includes the above mentioned carve-out rule.
>> >=20
>> > In an attempt to pave the way for more robust CPFP of on-chain contract=
s
>> > (Lightning commitment transactions), the carve-out rule was added in
>> > https://github.com/bitcoin/bitcoin/pull/15681. However, having worked o=
n
>> > an implementation of a new commitment format for utilizing the Bring
>> > Your Own Fees strategy using CPFP, I=E2=80=99m wondering if the special=
 case
>> > rule should have been relaxed a bit, to avoid the need for adding a 1
>> > CSV to all outputs (in case of Lightning this means HTLC scripts would
>> > need to be changed to add the CSV delay).
>> >=20
>> > Instead, what about letting the rule be
>> >=20
>> > The last transaction which is added to a package of dependent
>> > transactions in the mempool must:
>> >   * Have no more than one unconfirmed parent.
>> >=20
>> > This would of course allow adding a large transaction to each output of=

>> > the unconfirmed parent, which in effect would allow an attacker to
>> > exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is
>> > this a problem with the current mempool acceptance code in bitcoind? I
>> > would imagine evicting transactions based on feerate when the max
>> > mempool size is met handles this, but I=E2=80=99m asking since it seems=
 like
>> > there has been several changes to the acceptance code and eviction
>> > policy since the limit was first introduced.
>> >=20
>> > - Johan
>> >=20
>> >=20
>> > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <rusty@rustcorp.com.au
>> > <mailto:rusty@rustcorp.com.au>> wrote:
>> >=20
>> >     Matt Corallo <lf-lists@mattcorallo.com
>> >     <mailto:lf-lists@mattcorallo.com>> writes:
>> >     >>> Thus, even if you imagine a steady-state mempool growth, unless=
 the
>> >     >>> "near the top of the mempool" criteria is "near the top of the n=
ext
>> >     >>> block" (which is obviously *not* incentive-compatible)
>> >     >>
>> >     >> I was defining "top of mempool" as "in the first 4 MSipa", ie. n=
ext
>> >     >> block, and assumed you'd only allow RBF if the old package wasn'=
t
>> >     in the
>> >     >> top and the replacement would be.  That seems incentive
>> >     compatible; more
>> >     >> than the current scheme?
>> >     >
>> >     > My point was, because of block time variance, even that criteria
>> >     doesn't hold up. If you assume a steady flow of new transactions an=
d
>> >     one or two blocks come in "late", suddenly "top 4MWeight" isn't
>> >     likely to get confirmed until a few blocks come in "early". Given
>> >     block variance within a 12 block window, this is a relatively likel=
y
>> >     scenario.
>> >=20
>> >     [ Digging through old mail. ]
>> >=20
>> >     Doesn't really matter.  Lightning close algorithm would be:
>> >=20
>> >     1.  Give bitcoind unileratal close.
>> >     2.  Ask bitcoind what current expidited fee is (or survey your memp=
ool).
>> >     3.  Give bitcoind child "push" tx at that total feerate.
>> >     4.  If next block doesn't contain unilateral close tx, goto 2.
>> >=20
>> >     In this case, if you allow a simpified RBF where 'you can replace i=
f
>> >     1. feerate is higher, 2. new tx is in first 4Msipa of mempool, 3.
>> >     old tx isnt',
>> >     it works.
>> >=20
>> >     It allows someone 100k of free tx spam, sure.  But it's simple.
>> >=20
>> >     We could further restrict it by marking the unilateral close someho=
w to
>> >     say "gonna be pushed" and further limiting the child tx weight (say=
,
>> >     5kSipa?) in that case.
>> >=20
>> >     Cheers,
>> >     Rusty.
>> >     _______________________________________________
>> >     Lightning-dev mailing list
>> >     Lightning-dev@lists.linuxfoundation.org
>> >     <mailto:Lightning-dev@lists.linuxfoundation.org>
>> >     https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> >=20

--Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83
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=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">I don=E2=80=99te see how? L=
et=E2=80=99s imagine Party A has two spendable outputs, now they stuff the p=
ackage size on one of their spendable outlets until it is right at the limit=
, add one more on their other output (to meet the Carve-Out), and now Party B=
 can=E2=80=99t do anything.</div><div dir=3D"ltr"><br><blockquote type=3D"ci=
te">On Oct 24, 2019, at 21:05, Johan Tor=C3=A5s Halseth &lt;johanth@gmail.co=
m&gt; wrote:<br><br></blockquote></div><blockquote type=3D"cite"><div dir=3D=
"ltr">=EF=BB=BF<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">It essenti=
ally changes the rule to always allow CPFP-ing the commitment as long as the=
re is an output available without any descendants. It changes the commitment=
 from "you always need at least, and exactly, one non-CSV output per party. "=
 to "you always need at least one non-CSV output per party. "</div><div dir=3D=
"ltr"><br></div><div>I realize these limits are there for a reason though, b=
ut I'm wondering if could relax them. Also now that jeremyrubin has expresse=
d problems with the current mempool limits.</div></div></div><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 24, 2019 at 1=
1:25 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorallo.com">lf-list=
s@mattcorallo.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">I may be missing something, but I'm not sure how this changes a=
nything?<br>
<br>
If you have a commitment transaction, you always need at least, and<br>
exactly, one non-CSV output per party. The fact that there is a size<br>
limitation on the transaction that spends for carve-out purposes only<br>
effects how many other inputs/outputs you can add, but somehow I doubt<br>
its ever going to be a large enough number to matter.<br>
<br>
Matt<br>
<br>
On 10/24/19 1:49 PM, Johan Tor=C3=A5s Halseth wrote:<br>
&gt; Reviving this old thread now that the recently released RC for bitcoind=
<br>
&gt; 0.19 includes the above mentioned carve-out rule.<br>
&gt; <br>
&gt; In an attempt to pave the way for more robust CPFP of on-chain contract=
s<br>
&gt; (Lightning commitment transactions), the carve-out rule was added in<br=
>
&gt; <a href=3D"https://github.com/bitcoin/bitcoin/pull/15681" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/15681</a>. H=
owever, having worked on<br>
&gt; an implementation of a new commitment format for utilizing the Bring<br=
>
&gt; Your Own Fees strategy using CPFP, I=E2=80=99m wondering if the special=
 case<br>
&gt; rule should have been relaxed a bit, to avoid the need for adding a 1<b=
r>
&gt; CSV to all outputs (in case of Lightning this means HTLC scripts would<=
br>
&gt; need to be changed to add the CSV delay).<br>
&gt; <br>
&gt; Instead, what about letting the rule be<br>
&gt; <br>
&gt; The last transaction which is added to a package of dependent<br>
&gt; transactions in the mempool must:<br>
&gt; &nbsp; * Have no more than one unconfirmed parent.<br>
&gt; <br>
&gt; This would of course allow adding a large transaction to each output of=
<br>
&gt; the unconfirmed parent, which in effect would allow an attacker to<br>
&gt; exceed the MAX_PACKAGE_VIRTUAL_SIZE limit in some cases. However, is<br=
>
&gt; this a problem with the current mempool acceptance code in bitcoind? I<=
br>
&gt; would imagine evicting transactions based on feerate when the max<br>
&gt; mempool size is met handles this, but I=E2=80=99m asking since it seems=
 like<br>
&gt; there has been several changes to the acceptance code and eviction<br>
&gt; policy since the limit was first introduced.<br>
&gt; <br>
&gt; - Johan<br>
&gt; <br>
&gt; <br>
&gt; On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell &lt;<a href=3D"mailto:rus=
ty@rustcorp.com.au" target=3D"_blank">rusty@rustcorp.com.au</a><br>
&gt; &lt;mailto:<a href=3D"mailto:rusty@rustcorp.com.au" target=3D"_blank">r=
usty@rustcorp.com.au</a>&gt;&gt; wrote:<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcora=
llo.com" target=3D"_blank">lf-lists@mattcorallo.com</a><br>
&gt;&nbsp; &nbsp; &nbsp;&lt;mailto:<a href=3D"mailto:lf-lists@mattcorallo.co=
m" target=3D"_blank">lf-lists@mattcorallo.com</a>&gt;&gt; writes:<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt;&gt; Thus, even if you imagine a steady-stat=
e mempool growth, unless the<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt;&gt; "near the top of the mempool" criteria i=
s "near the top of the next<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt;&gt; block" (which is obviously *not* incent=
ive-compatible)<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt; I was defining "top of mempool" as "in the f=
irst 4 MSipa", ie. next<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt; block, and assumed you'd only allow RBF if t=
he old package wasn't<br>
&gt;&nbsp; &nbsp; &nbsp;in the<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt; top and the replacement would be.&nbsp; Tha=
t seems incentive<br>
&gt;&nbsp; &nbsp; &nbsp;compatible; more<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;&gt; than the current scheme?<br>
&gt;&nbsp; &nbsp; &nbsp;&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;&gt; My point was, because of block time variance, e=
ven that criteria<br>
&gt;&nbsp; &nbsp; &nbsp;doesn't hold up. If you assume a steady flow of new t=
ransactions and<br>
&gt;&nbsp; &nbsp; &nbsp;one or two blocks come in "late", suddenly "top 4MWe=
ight" isn't<br>
&gt;&nbsp; &nbsp; &nbsp;likely to get confirmed until a few blocks come in "=
early". Given<br>
&gt;&nbsp; &nbsp; &nbsp;block variance within a 12 block window, this is a r=
elatively likely<br>
&gt;&nbsp; &nbsp; &nbsp;scenario.<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;[ Digging through old mail. ]<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;Doesn't really matter.&nbsp; Lightning close algorit=
hm would be:<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;1.&nbsp; Give bitcoind unileratal close.<br>
&gt;&nbsp; &nbsp; &nbsp;2.&nbsp; Ask bitcoind what current expidited fee is (=
or survey your mempool).<br>
&gt;&nbsp; &nbsp; &nbsp;3.&nbsp; Give bitcoind child "push" tx at that total=
 feerate.<br>
&gt;&nbsp; &nbsp; &nbsp;4.&nbsp; If next block doesn't contain unilateral cl=
ose tx, goto 2.<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;In this case, if you allow a simpified RBF where 'yo=
u can replace if<br>
&gt;&nbsp; &nbsp; &nbsp;1. feerate is higher, 2. new tx is in first 4Msipa o=
f mempool, 3.<br>
&gt;&nbsp; &nbsp; &nbsp;old tx isnt',<br>
&gt;&nbsp; &nbsp; &nbsp;it works.<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;It allows someone 100k of free tx spam, sure.&nbsp; B=
ut it's simple.<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;We could further restrict it by marking the unilater=
al close somehow to<br>
&gt;&nbsp; &nbsp; &nbsp;say "gonna be pushed" and further limiting the child=
 tx weight (say,<br>
&gt;&nbsp; &nbsp; &nbsp;5kSipa?) in that case.<br>
&gt; <br>
&gt;&nbsp; &nbsp; &nbsp;Cheers,<br>
&gt;&nbsp; &nbsp; &nbsp;Rusty.<br>
&gt;&nbsp; &nbsp; &nbsp;_______________________________________________<br>
&gt;&nbsp; &nbsp; &nbsp;Lightning-dev mailing list<br>
&gt;&nbsp; &nbsp; &nbsp;<a href=3D"mailto:Lightning-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
&gt;&nbsp; &nbsp; &nbsp;&lt;mailto:<a href=3D"mailto:Lightning-dev@lists.lin=
uxfoundation.org" target=3D"_blank">Lightning-dev@lists.linuxfoundation.org<=
/a>&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;<a href=3D"https://lists.linuxfoundation.org/mailman=
/listinfo/lightning-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
&gt; <br>
</blockquote></div>
</div></blockquote></body></html>=

--Apple-Mail-A6774A8C-632A-4A79-AD73-EF0AE036EE83--