MIME-Version: 1.0
References: <CAB3F3Dtp7YQBhLJQbCLpSKau8Hj=5gN4yuGCFN=u=6e1o6o=dA@mail.gmail.com>
 <6a73b36724e6134a1cd57ea9277f2779@dtrt.org>
In-Reply-To: <6a73b36724e6134a1cd57ea9277f2779@dtrt.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 12 May 2022 09:31:02 -0400
Message-ID: <CAB3F3DsGtqWo5ajc_iBGikFdTFqfMyA2y0-R1vcgFNht6Rb_Sw@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000532cb005ded092b8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction
 introspection to stop RBF pinning
Precedence: list

--000000000000532cb005ded092b8
Content-Type: text/plain; charset="UTF-8"

Great point in this specific case I unfortunately didn't consider! So
basically the design degenerates to the last option I gave, where the
counterparty
can send off N(25) weight-bound packages.

A couple thoughts:

0) Couldn't we relative-time lock update transactions's state input by 1
block as well to close the vector off? People are allowed
one "update transaction package" at a time in mempool, so if detected
in-mempool it can be RBF'd, or in-block can be immediately responded to.
1) other usages of ANYONECANPAY like behavior may not have these issues,
like vault structures.


On Thu, May 12, 2022, 3:17 AM David A. Harding <dave@dtrt.org> wrote:

> On 2022-05-10 08:53, Greg Sanders via bitcoin-dev wrote:
> > We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to
> > the proposal) to the "state" input's script.
> > This is used in the update transaction to set the upper bound on the
> > final transaction weight.
> > In this same input, for each contract participant, we also
> > conditionally commit to the change output's scriptpubkey
> > via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2.
> > This means any participant can send change back
> > to themselves, but with a catch. Each change output script possibility
> > in that state input also includes a 1 block
> > CSV to avoid mempool spending to reintroduce pinning.
>
> I like the idea!   However, I'm not sure the `1 CSV` trick helps much.
> Can't an attacker just submit to the mempool their other eltoo state
> updates?  For example, let's assume Bob and Mallory have a channel with
>  >25 updates and Mallory wants to prevent update[-1] from being committed
> onchain before its (H|P)TLC timeout.  Mallory also has at least 25
> unencumbered UTXOs, so she submits to the mempool update[0], update[1],
> update[...], update[24]---each of them with a different second input to pay
> fees.
>
> If `OPTX_SELECT_WEIGHT OP_TX` limits each update's weight to 1,000
> vbytes[1] and the default node relay/mempool policy of allowing a
> transaction and up to 24 descendants remains, Mallory can pin the
> unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of
> what she can pin under current mempool policies.
>
> Alice can't RBF update[0] without paying for update[1..24] (BIP125 rule
> #3), and an RBF of update[24] will have its additional fees divided by
> its size plus the 24,000 vbytes of update[1..24].
>
> To me, that seems like your proposal makes escaping the pinning at most
> 75% cheaper than today.  That's certainly an improvement---yay!---but
> I'm not sure it eliminates the underlying concern.  Also depending on
> the mempool ancestor/descendant limits makes it harder to raise those
> limits in the future, which is something I think we might want to do if
> we can ensure raising them won't increase node memory/CPU DoS risk.
>
> I'd love to hear that my analysis is missing something though!
>
> Thanks!,
>
> -Dave
>
> [1] 1,000 vbytes per update seems like a reasonable value to me.
> Obviously there's a tradeoff here: making it smaller limits the amount
> of pinning possible (assuming mempool ancestor/descendant limits remain)
> but also limits the number and complexity of inputs that may be added.
> I don't think we want to discourage people too much from holding
> bitcoins in deep taproot trees or sophisticated tapscripts.
>

--000000000000532cb005ded092b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto">Great point in this specific case I unfo=
rtunately didn&#39;t consider! So basically the design degenerates to the l=
ast option I gave, where the counterparty</div><div dir=3D"auto">can send o=
ff N(25) weight-bound packages.<br><div dir=3D"auto"><br></div><div dir=3D"=
auto">A couple thoughts:</div><div dir=3D"auto"><br></div><div>0) Couldn=
9;t we relative-time lock update transactions&#39;s state input by 1 block =
as well to close the vector off? People are allowed</div><div>one &quot;upd=
ate transaction package&quot; at a time in mempool, so if detected in-mempo=
ol it can be RBF&#39;d, or in-block can be immediately responded to.</div><=
div dir=3D"auto">1) other usages of ANYONECANPAY=C2=A0like behavior may not=
 have these issues, like vault structures.=C2=A0</div><div dir=3D"auto"><br=
></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Thu, May 12, 2022, 3:17 AM David A. Harding &lt;<a href=3D"=
mailto:dave@dtrt.org" rel=3D"noreferrer noreferrer noreferrer noreferrer" t=
arget=3D"_blank">dave@dtrt.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">On 2022-05-10 08:53, Greg Sanders via bitcoin=
-dev wrote:<br>
&gt; We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition to<br=
>
&gt; the proposal) to the &quot;state&quot; input&#39;s script.<br>
&gt; This is used in the update transaction to set the upper bound on the<b=
r>
&gt; final transaction weight.<br>
&gt; In this same input, for each contract participant, we also<br>
&gt; conditionally commit to the change output&#39;s scriptpubkey<br>
&gt; via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT=3D=3D2=
.<br>
&gt; This means any participant can send change back<br>
&gt; to themselves, but with a catch. Each change output script possibility=
<br>
&gt; in that state input also includes a 1 block<br>
&gt; CSV to avoid mempool spending to reintroduce pinning.<br>
<br>
I like the idea!=C2=A0 =C2=A0However, I&#39;m not sure the `1 CSV` trick he=
lps much.=C2=A0 <br>
Can&#39;t an attacker just submit to the mempool their other eltoo state <b=
r>
updates?=C2=A0 For example, let&#39;s assume Bob and Mallory have a channel=
 with <br>
=C2=A0&gt;25 updates and Mallory wants to prevent update[-1] from being com=
mitted onchain before its (H|P)TLC timeout.=C2=A0 Mallory also has at least=
 25 unencumbered UTXOs, so she submits to the mempool update[0], update[1],=
 update[...], update[24]---each of them with a different second input to pa=
y fees.<br>
<br>
If `OPTX_SELECT_WEIGHT OP_TX` limits each update&#39;s weight to 1,000 <br>
vbytes[1] and the default node relay/mempool policy of allowing a <br>
transaction and up to 24 descendants remains, Mallory can pin the <br>
unsubmitted update[-1] under 25,000 vbytes of junk---which is 25% of <br>
what she can pin under current mempool policies.<br>
<br>
Alice can&#39;t RBF update[0] without paying for update[1..24] (BIP125 rule=
 <br>
#3), and an RBF of update[24] will have its additional fees divided by <br>
its size plus the 24,000 vbytes of update[1..24].<br>
<br>
To me, that seems like your proposal makes escaping the pinning at most <br=
>
75% cheaper than today.=C2=A0 That&#39;s certainly an improvement---yay!---=
but <br>
I&#39;m not sure it eliminates the underlying concern.=C2=A0 Also depending=
 on <br>
the mempool ancestor/descendant limits makes it harder to raise those <br>
limits in the future, which is something I think we might want to do if <br=
>
we can ensure raising them won&#39;t increase node memory/CPU DoS risk.<br>
<br>
I&#39;d love to hear that my analysis is missing something though!<br>
<br>
Thanks!,<br>
<br>
-Dave<br>
<br>
[1] 1,000 vbytes per update seems like a reasonable value to me.=C2=A0 <br>
Obviously there&#39;s a tradeoff here: making it smaller limits the amount =
<br>
of pinning possible (assuming mempool ancestor/descendant limits remain) <b=
r>
but also limits the number and complexity of inputs that may be added.=C2=
=A0 <br>
I don&#39;t think we want to discourage people too much from holding <br>
bitcoins in deep taproot trees or sophisticated tapscripts.<br>
</blockquote></div>

--000000000000532cb005ded092b8--