From: Rusty Russell <rusty@rustcorp.com.au>
To: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com>
References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
	<878t163qzi.fsf@rustcorp.com.au>
	<725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com>
Date: Tue, 08 Jan 2019 16:20:20 +1030
Message-ID: <87wonfem03.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Cc: bitcoin-dev@lists.linuxfoundation.org,
	lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction
	Issues in Contracting Applications (eg Lightning)
Precedence: list

Matt Corallo <lf-lists@mattcorallo.com> writes:
> Ultimately, defining a "near the top of the mempool" criteria is fraught 
> with issues. While it's probably OK for the original problem (large 
> batched transactions where you don't want a single counterparty to 
> prevent confirmation), lightning's requirements are very different. 
> Instead is wanting a high probability that the transaction in question 
> confirms "soon", we need certainty that it will confirm by some deadline.

I don't think it's different, in practice.

> Thus, even if you imagine a steady-state mempool growth, unless the 
> "near the top of the mempool" criteria is "near the top of the next 
> block" (which is obviously *not* incentive-compatible)

I was defining "top of mempool" as "in the first 4 MSipa", ie. next
block, and assumed you'd only allow RBF if the old package wasn't in the
top and the replacement would be.  That seems incentive compatible; more
than the current scheme?

The attack against this is to make a 100k package which would just get
into this "top", then push it out with a separate tx at slightly higher
fee, then repeat.  Of course, timing makes that hard to get right, and
you're paying real fees for it too.

Sure, an attacker can make you pay next-block high fees, but it's still
better than our current "*always* overpay and hope!", and you can always
decide at the time based on whether the expiring HTLC(s) are worth it.

But I think whatever's simplest to implement should win, and I'm not in
a position to judge that accurately.

Thanks,
Rusty.