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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
