David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-12 📝 Original message:On 2022-05-10 08:53, Greg ...

📅 Original date posted:2022-05-12
📝 Original message: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.