Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

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

On 4/23/20 8:46 AM, ZmnSCPxj wrote:
>>> -   Miners, being economically rational, accept this proposal and include this in a block.
>>>
>>> The proposal by Matt is then:
>>>
>>> -   The hashlock branch should instead be:
>>> -   B and C must agree, and show the preimage of some hash H (hashlock branch).
>>> -   Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs:
>>> -   Normal payment to C.
>>> -   Hook output to B, which B can use to CPFP this transaction.
>>> -   Hook output to C, which C can use to CPFP this transaction.
>>> -   B can still (somehow) not maintain a mempool, by:
>>> -   B broadcasts its timelock transaction.
>>> -   B tries to CPFP the above hashlock transaction.
>>> -   If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC.
>>
>> Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.
> 
> Ah, right, so it gets confirmed and the `blocksonly` B sees it in a block.
> 
> Even if C hooks a tree of low-fee transactions on its hook output or normal payment, miners will still be willing to confirm this and the B hook CPFP transaction without, right?

Correct, once it makes it into the mempool we can CPFP it and all the regular sub-package CPFP calculation will pick it
and its descendants up. Of course this relies on it not spending any other unconfirmed inputs.