Re: [bitcoin-dev] On mempool policy consistency

From: Greg Sanders <gsanders87@gmail•com>
To: Suhas Daftuar <sdaftuar@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
Date: Thu, 27 Oct 2022 13:44:43 -0400	[thread overview]
Message-ID: <CAB3F3Du4-eQY9X93HXhEpuwfTwon+OAHU9TEakgoi+50sU-dsQ@mail.gmail.com> (raw)
In-Reply-To: <CAFp6fsHVdyK1xROa8jgq-cZFMrrXX-uZqkoNsS-C0B5AqG4KcA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3778 bytes --]

> For instance, the double-spend could be low-feerate and large, and
effectively pin any attempt to replace it.

Yes, this is the biggest hole left. You *could* replace it with RBF when
before you simply could not, so perhaps the pinning door is slightly
smaller in scenarios where going feerates are significantly higher than min.

> Or it could be higher feerate and confirm and B/C have to start all over.

Coinjoins have "blame rounds" exactly for this. Ruling out the above hole
where you don't want to pay the 100kvb rule#3 penalty, you can kick the
griefer out. Without replacement, you likely can not.

> Or, A could stall things in the signing phase and B/C have to figure out
when to give up on the channel with A.

Again, blame rounds solve this.

So to recap, it makes it *possible* to over-bid your griefer, vs simply not
able to and have funds tied up for weeks(or guess you're being pinned and
double-spend your input, which again looks blame-worthy).

Properly replacing rule#3 would give these protocols higher assurances, but
this is where we're at now.

On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> I have more to say on this broader topic, but since you've brought up this
> particular example I think it's worth commenting:
>
> On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid
>> a DoS issue when utxos are jointly funded by untrusting partners, and,
>> aiui, that's the main motivation for addressing this now.
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html
>>
>> The scenario he describes is: A, B, C create a tx:
>>
>>   inputs: A1, B1, C1 [opts in to RBF]
>>   fees: normal
>>   outputs:
>>     [lightning channel, DLC, etc, who knows]
>>
>> they all analyse the tx, and agree it looks great; however just before
>> publishing it, A spams the network with an alternative tx, double
>> spending her input:
>>
>>   inputs: A1 [does not opt in to RBF]
>>   fees: low
>>   outputs: A
>>
>> If A gets the timing right, that's bad for B and C because they've
>> populated their mempool with the 1st transaction, while everyone else
>> sees the 2nd one instead; and neither tx will replace the other. B and
>> C can't know that they should just cancel their transaction, eg:
>>
>>   inputs: B1, C1 [opts in to RBF]
>>   fees: 50% above normal
>>   outputs:
>>     [smaller channel, refund, whatever]
>>
>> and might instead waste time trying to fee bump the tx to get it mined,
>> or similar.
>>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>>
>
> I think this is not a real example of a DoS vector that is available
> because we support non-rbf signaling transactions. Even in a world where
> all transactions are replaceable, person A could double-spend their input
> in a way that is annoying for B and C.  For instance, the double-spend
> could be low-feerate and large, and effectively pin any attempt to replace
> it.  Or it could be higher feerate and confirm and B/C have to start all
> over.  Or, A could stall things in the signing phase and B/C have to figure
> out when to give up on the channel with A.
>
> So I find this example to be unconvincing.  Are there any other examples
> where having a non-replacement policy for some transactions causes problems
> for protocols people are trying to build?
>
> Thanks,
> Suhas
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5094 bytes --]