Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

[Matt Corallo <lf-lists@mattcorallo.com>]

Sorry for the late reply.

Hmm, I included the old RBF-pinning proposal as a comparison. 
Personally, I find it both less clean and less convincingly secure.

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.

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), its easy to see 
how the package would fail to confirm within a handful of blocks given 
block time variance. Giving up the ability to RBF/CPFP more than once in 
case the fee moves away from us seems to be a rather significant 
restriction.

THe original proposal is somewhat of a hack, but its a hack on the 
boundary condition where packages meet our local anti-DoS rules in 
violation of the "incentive compatible" goal anyway (essentially, though 
miners also care about anti-DoS). This proposal is very different and, 
similar to how it doesn't work if blocks randomly come in a bit slow for 
an hour or two, isn't incentive compatible if blocks come in a bit fast 
for an hour or two, as all of a sudden that "near the top of the 
mempool" criteria makes no sense and you should have accepted the new 
transaction(s).

As for package relay, indeed, we can probably do soemthing simpler for 
this specific case, but itdepends on what the scope of that design is. 
Suhas opened an issue to try to scope it out a bit more at 
https://github.com/bitcoin/bitcoin/issues/14895

Matt

> On Dec 3, 2018, at 22:33, Rusty Russell <rusty@rustcorp.com.au> wrote:
> 
> Matt Corallo <lf-lists@mattcorallo.com> writes:
>> As an alternative proposal, at various points there have been 
>> discussions around solving the "RBF-pinning" problem by allowing 
>> transactors to mark their transactions as "likely-to-be-RBF'ed", which 
>> could enable a relay policy where children of such transactions would be 
>> rejected unless the resulting package would be "near the top of the 
>> mempool". This would theoretically imply such attacks are not possible 
>> to pull off consistently, as any "transaction-delaying" channel 
>> participant will have to place the package containing A at an effective 
>> feerate which makes confirmation to occur soon with some likelihood. It 
>> is, however, possible to pull off this attack with low probability in 
>> case of feerate spikes right after broadcast.
> 
> I like this idea.
> 
> Firstly, it's incentive-compatible[1]: assuming blocks are full, miners
> should always take a higher feerate tx if that tx would be in the
> current block and the replaced txs would not.[2]
> 
> Secondly, it reduces the problem that the current lightning proposal
> adds to the UTXO set with two anyone-can-spend txs for 1000 satoshis,
> which might be too small to cleanup later.  This rule would allow a
> simple single P2WSH(OP_TRUE) output, or, with IsStandard changed,
> a literal OP_TRUE.
> 
>> Note that this clearly relies on some form of package relay, which comes 
>> with its own challenges, but I'll start a separate thread on that.
> 
> Could be done client-side, right?  Do a quick check if this is above 250
> satoshi per kweight but below minrelayfee, put it in a side-cache with a
> 60 second timeout sweep.  If something comes in which depends on it
> which is above minrelayfee, then process them as a pair[3].
> 
> Cheers,
> Rusty.
> [1] Miners have generally been happy with Defaults Which Are Good For The
>    Network, but I feel a long term development aim should to be reduce
>    such cases to smaller and smaller corners.
> [2] The actual condition is subtler, but this is a clear subset AFAICT.
> [3] For Lightning, we don't care about child-pays-for-grandparent etc.