From: "David A. Harding" <dave@dtrt•org>
To: Greg Sanders <gsanders87@gmail•com>,
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
Date: Wed, 11 May 2022 21:17:05 -1000 [thread overview]
Message-ID: <6a73b36724e6134a1cd57ea9277f2779@dtrt.org> (raw)
In-Reply-To: <CAB3F3Dtp7YQBhLJQbCLpSKau8Hj=5gN4yuGCFN=u=6e1o6o=dA@mail.gmail.com>
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.
next prev parent reply other threads:[~2022-05-12 7:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 18:53 Greg Sanders
2022-05-12 7:17 ` David A. Harding [this message]
2022-05-12 13:31 ` Greg Sanders
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a73b36724e6134a1cd57ea9277f2779@dtrt.org \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gsanders87@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox