Date: Mon, 12 Feb 2018 12:30:04 -0500
To: Russell O'Connor <roconnor@blockstream.io>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <7zJRAGZXWFiiXu-S3UliZqtP1crDG6s8MDEOurJrXXJc0BkZxw8o0zcGh7DthtvczMxoQHKZ6PwQsZJ0s403noMah26S2xAdGBX2NNL1OfI=@protonmail.com>
In-Reply-To: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
References: <CAMZUoKnGx3p7=Kg96E3EEyJ8aFC7ezsvec_pAnN7oJz7-VbyLA@mail.gmail.com>
Feedback-ID: RdfuD--Ffc-FNb_4UIG1XA3s5stj1f6Yt84KENdha_3WoiW3STYpu7X5uGR72LvTfQZpxEhSRHGSlNfV5XM5RA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting BIP 125 RBF policy.
Precedence: list

Thank you very much for writing this up.=C2=A0 It's worth noting that there=
 can be multiple roots for the transactions that are getting replaced.

So for rule 3, you probably want a feeRate >=3D the max "package fee rate" =
of all replaced roots.


I am very happy with this proposal in general, as it's clearly a step in th=
e right direction for making transaction replacement practically usable for=
 todays services.


However, I think your new rule 4 is a bit weak. The logical extension of yo=
ur proposal would be to allow a transaction (say B) be able to replace tran=
sactions (say A) by purely paying a higher fee rate, /even if it's less abs=
olute fee/. In this simple example of B replacing A -- B should pay at leas=
t:   (a.FeeRate * b.size) + relayFeeRate*(a.size + b.size)


=E2=80=8B-Ryan

=E2=80=8B

-------- Original Message --------
 On February 12, 2018 10:52 AM, Russell O'Connor via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:

>I think it is worth revisiting BIP 125's replace-by-fee policy for when to=
 replace transactions.
>The current policy can be problematic. As noted earlier by Rhavar, sometim=
es one's transaction becomes pinned making it infeasible to fee bump with R=
BF.=C2=A0 This happens when one makes a normal payment to a large commercia=
l service, and, while the transaction remains unconfirmed, the commercial s=
ervice creates a low-fee-rate sweep of one's payment, among a collection of=
 others.=C2=A0 If one wants to RBF this original payment, for example to ge=
t confirmation of the change output for use in further transactions, the cu=
rrent BIP 125 rules require that you make a fee bump that exceeds the combi=
ned total fees of the original transaction and the low-fee-rate sweep of th=
e commercial service.
>
>The problem is that, while the fee rate of the sweep is low, the absolute =
size of the fee can still be large, making it infeasible to RBF the origina=
l transaction.=C2=A0 BIP 125 was defined back in 2015, when perhaps rationa=
l miners did care about absolute fee amounts. However, today we are in an e=
ra where rational miners care about fee-rates more than absolute fees.=
=C2=A0 The fee-rate of the large sweep transaction is low enough that we do=
 not expect that miners will be mining it in the same block as the original=
 transaction.=C2=A0 Today, a rational miner will prefer a fee-bumped versio=
n of original transaction without consideration of the low-fee sweep transa=
ction (or at least discounting the low-fee sweep in proportion to the miner=
's hash-rate fraction).
>
>Let me quote the five rules that define the current BIP 125 policy:
>
>>
>>One or more transactions currently in the mempool (original
>>transactions) will be replaced by a new transaction (replacement
>>transaction) that spends one or more of the same inputs if,
>>
>>
>>1. The original transactions signal replaceability explicitly or through =
inheritance as described in the above Summary section.
>>
>>2. The
>> replacement transaction does not contain any new unconfirmed inputs=20
>>that did not previously appear in the mempool. (Unconfirmed inputs are=20
>>inputs spending outputs from currently unconfirmed transactions.)
>>
>>3. The replacement transaction pays an absolute fee of at least the sum p=
aid by the original transactions.
>>
>>4. The
>> replacement transaction must also pay for its own bandwidth at or above
>> the rate set by the node's minimum relay fee setting.  For example, if=
=20
>>the minimum relay fee is 1 satoshi/byte and the replacement transaction=
=20
>>is 500 bytes total, then the replacement must pay a fee at least 500=20
>>satoshis higher than the sum of the originals.
>>
>>5. The number of=20
>>original transactions to be replaced and their descendant transactions=20
>>which will be evicted from the mempool must not exceed a total of 100=20
>>transactions.
>>
>>To address the new reality of rational miners' consideration, I propose c=
hanging rules 3 and 4 to something like the following.
>3'. The replacement transaction pays a fee rate of at least the effective =
fee rate of any chain of transactions from the set of original transactions=
 that begins with the root of the original transaction set.
>
>4'. The
> replacement transaction must also pay for replacing the original transact=
ions at or above
> the rate set by the node's minimum relay fee setting.  For example, if=20
>the minimum relay fee is 1 satoshi/byte and the replacement transaction an=
d the original transactions are 1000 bytes total, then the replacement must=
 pay a fee at least 1000=20
>satoshis higher than the fee of the root transaction of the original trans=
actions.
>Rule 3' is a fancy way of saying that the replacement transaction must hav=
e a fee rate that is larger than the package fee rate of the root of the se=
t of transactions it replaces, where the package fee rate is the fee rate i=
mplied by considering CPFP.
>Rule 4' is an amended anti-spam rule that is intended to avoid DOS attacks=
 from churning the mempool. I don't know if it is really necessary to pay f=
or the size of the original transactions being evicted, but some people I c=
hatted with thought it could be important.
>
>Other people on the mailing list have been thinking about RBF policy for f=
ar longer than I have, so I wouldn't be surprised if my proposal above is n=
aive.=C2=A0 However, I think it can start a conversation about addressing t=
he problems with the current RBF policy.
>