Date: Mon, 03 Jun 2019 01:49:15 +0000
To: Rusty Russell <rusty@rustcorp.com.au>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: rhavar@protonmail.com
Reply-To: rhavar@protonmail.com
Message-ID: <Ol3079c4eDHk0jCv6RMogcx3QPl-bZOr_AQL9siAOCtXSriqZjVhFf53iaJQbaFML0urBNmOaRVJrH848oFWs6ekCW58l4mg1hDXGjiM2WE=@protonmail.com>
In-Reply-To: <871s0c1tvg.fsf@rustcorp.com.au>
References: <871s0c1tvg.fsf@rustcorp.com.au>
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: Matt Corallo <matt@chaincode.com>
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
Precedence: list

+1

From an incentive-compatible point of view, miners should be accepting tran=
sactions that increase the amount of fees that can achieved with 4M weight =
of transactions, so it seems like a pretty sane plan.

One common problem I've run into with RBF is since you're using RBF you pro=
bably want to low ball fees. With good coin selection (*cough* coinsayer.co=
m *cough*), it'll use that opportunity to consolidate inputs. But now let's=
 say fees suddenly spike (pretty common), you might want to fee bump your n=
ow stuck transaction. But now that fees are high, it doesn't make sense to =
be consolidating so ideally you'd just replace it with a much smaller trans=
action (that pays higher fee rate).


So if anything, I think your proposal doesn't go far enough. I think even i=
n "non-emergency" cases, we could get away with removing the requirement to=
 increase the absolute fee (as long as the fee rate is increased); which al=
so makes it incentive compatible if you assume a reasonable fee-market.

I realize it does open potential DoS vectors, but they seem reasonably smal=
l.


-Ryan

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Saturday, June 1, 2019 9:41 PM, Rusty Russell via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> I want to propose a modification to rules 3, 4 and 5 of BIP 125:
>
> To remind you of BIP 125:
> 3. The replacement transaction pays an absolute fee of at least the sum
> paid 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.
>
> 5. The number of original transactions to be replaced and their
> descendant transactions which will be evicted from the mempool must not
> exceed a total of 100 transactions.
>
> The new "emergency RBF" rule:
>
> 6. If the original transaction was not in the first 4,000,000 weight
> units of the fee-ordered mempool and the replacement transaction is,
> rules 3, 4 and 5 do not apply.
>
> This means:
>
> 1.  RBF can be used in adversarial conditions, such as lightning
>     unilateral closes where the adversary has another valid transaction
>     and can use it to block yours. This is a problem when we allow
>     differential fees between the two current lightning transactions
>     (aka "Bring Your Own Fees").
>
> 2.  RBF can be used without knowing about miner's mempools, or that the
>     above problem is occurring. One simply gets close to the required
>     maximum height for lightning timeout, and bids to get into the next
>     block.
>
> 3.  This proposal does not open any significant new ability to RBF spam,
>     since it can (usually) only be used once. IIUC bitcoind won't
>     accept more that 100 descendents of an unconfirmed tx anyway.
>
> 4.  This proposal makes RBF miner-incentive compatible. Currently the
>     protocol tells miners they shouldn't accept the highest bidding tx
>     for the good of the network. This conflict is particularly sharp
>     in the case where the replacement tx would be immediately minable,
>     which this proposal addresses.
>
>     Unfortunately I haven't found time to code this up in bitcoin, but if
>     there's positive response I can try.
>
>     Thanks for reading!
>     Rusty.
>
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev