MIME-Version: 1.0
Date: Wed, 11 May 2022 21:17:05 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Greg Sanders <gsanders87@gmail.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAB3F3Dtp7YQBhLJQbCLpSKau8Hj=5gN4yuGCFN=u=6e1o6o=dA@mail.gmail.com>
References: <CAB3F3Dtp7YQBhLJQbCLpSKau8Hj=5gN4yuGCFN=u=6e1o6o=dA@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.10
Message-ID: <6a73b36724e6134a1cd57ea9277f2779@dtrt.org>
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Bringing a nuke to a knife fight: Transaction
 introspection to stop RBF pinning
Precedence: list

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.