[prev in list] [next in list] [prev in thread] [next in thread]
List: bitcoin-dev
Subject: Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction introspection to stop RBF pinning
From: Greg Sanders via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date: 2022-05-12 13:31:02
Message-ID: CAB3F3DsGtqWo5ajc_iBGikFdTFqfMyA2y0-R1vcgFNht6Rb_Sw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="auto">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</div><div dir="auto">can send off N(25) weight-bound \
packages.<br><div dir="auto"><br></div><div dir="auto">A couple thoughts:</div><div \
dir="auto"><br></div><div>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</div><div>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.</div><div dir="auto">1) other usages of ANYONECANPAY like behavior may not have \
these issues, like vault structures. </div><div \
dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, May 12, 2022, 3:17 AM David A. Harding <<a \
href="mailto:dave@dtrt.org" rel="noreferrer noreferrer noreferrer noreferrer" \
target="_blank">dave@dtrt.org</a>> wrote:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">On 2022-05-10 08:53, Greg Sanders via bitcoin-dev \
wrote:<br> > We add OPTX_SELECT_WEIGHT(pushes tx weight to stack, my addition \
to<br> > the proposal) to the "state" input's script.<br>
> This is used in the update transaction to set the upper bound on the<br>
> final transaction weight.<br>
> In this same input, for each contract participant, we also<br>
> conditionally commit to the change output's scriptpubkey<br>
> via OPTX_SELECT_OUTPUT_SCRIPTPUBKEY and OPTX_SELECT_OUTPUTCOUNT==2.<br>
> This means any participant can send change back<br>
> to themselves, but with a catch. Each change output script possibility<br>
> in that state input also includes a 1 block<br>
> CSV to avoid mempool spending to reintroduce pinning.<br>
<br>
I like the idea! However, I'm not sure the `1 CSV` trick helps much. <br>
Can't an attacker just submit to the mempool their other eltoo state <br>
updates? For example, let's assume Bob and Mallory have a channel with <br>
>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.<br> <br>
If `OPTX_SELECT_WEIGHT OP_TX` limits each update'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'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. That's certainly an improvement---yay!---but <br>
I'm not sure it eliminates the underlying concern. 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't increase node memory/CPU DoS risk.<br>
<br>
I'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. <br>
Obviously there's a tradeoff here: making it smaller limits the amount <br>
of pinning possible (assuming mempool ancestor/descendant limits remain) <br>
but also limits the number and complexity of inputs that may be added. <br>
I don't think we want to discourage people too much from holding <br>
bitcoins in deep taproot trees or sophisticated tapscripts.<br>
</blockquote></div>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic