Message-ID: <42006209-4ea4-4008-b3b3-556a8461323c@murch.one>
Date: Sun, 28 Jan 2024 12:27:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <Zalsq+Nq7RRr/CAR@petertodd.org>
 <9a89eca8-61fd-4156-825d-c9b718dc3034@murch.one>
 <ZbSueoReTvEmm1s9@petertodd.org>
Content-Language: en-US
From: Murch <murch@murch.one>
In-Reply-To: <ZbSueoReTvEmm1s9@petertodd.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] One-Shot Replace-By-Fee-Rate
Precedence: list

Hi Peter,

Thanks you for investigate my concern and replicate the scenario I drafted.

On 27.01.24 02:19, Peter Todd wrote:
> I actually tried this attack out, and it fails at step #4 due to the Rule #6,
> PaysMoreThanConflicts, check.
> 
> While on stacker.news you stated that:
> 
>      tx_HS has 5000 vB and pays 21 s/vB, but since it spends an output from a
>      low-feerate parent, it’s mining score is only 1.95 s/vB.
> 
> and
> 
>      You RBF tx_LL and tx_HS with tx_LM that has 100,000 vB and pays 3.05 s/vB (fee:
>      305,000 s) by spending the outputs C1 and C2. This is permitted, since only
>      tx_LL is a direct conflict, so the feerate of tx_HS does not have to be beat
>      directly.
> 
> tx_HS _is_ considered to be a direct conflict, and its raw fee-rate _does_ have
> to be beat directly. While ts_HS does spend an unconfirmed output, it appears
> that the fee-rate PaysMoreThanConflicts uses to calculate if ts_HS can be
> beaten is ts_HS's raw fee-rate. So looks like your understanding was incorrect
> on these two points.

I agree in the detail, but not about the big picture. You are right that 
it’s a problem that `tx_LM` and `tx_HS` spend the same input and 
therefore are direct conflicts.

Luckily, it is unnecessary for my scenario that `tx_LM` and `tx_HS` 
conflict. The scenario only requires that `tx_LM` conflicts with `tx_LL` 
and `tx_RBFr`. `tx_HS` is supposed to get dropped indirectly per the 
conflict with `tx_LL`.

It seems to me that my example attack should work when a third confirmed 
input `c3` is introduced as follows:
`tx_LM` spends `c3` instead of `c2`, and `tx_RBFr` spends both `c2` and 
`c3`, which allows the following four conflicts:

- `tx_HS` and `tx_RBFr` conflict on spending `c2`
- `tx_HS` and `tx_LS` conflict on spending `tx_LL:0`
- `tx_LL` and `tx_LM` conflict on spending `c1`
- `tx_LM` and `tx_RBFr` conflict on spending `c3`

`tx_RBFr` would end up slightly bigger and therefore have a bigger fee, 
but otherwise the number should work out fine as they are.
I have not verified this yet (thanks for sharing your code), but I might 
be able to take another look in the coming week if you haven’t by then.

It seems to me that my main point stands, though: the proposed RBFr 
rules would enable infinite replacement cycles in combination with the 
existing RBF rules.

Murch