Date: Thu, 23 Apr 2020 12:46:59 +0000
To: Matt Corallo <lf-lists@mattcorallo.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>
In-Reply-To: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>
 <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties
	and Competing Interest
Precedence: list


Good morning Matt,

> > -   C directly contacts miners with an out-of-band proposal to replace =
its transaction with an alternative that is much smaller and has a low fee,=
 but much better feerate.
>
> Or they can just wait. For example in today=E2=80=99s mempool it would no=
t be strange for a transaction at 1 sat/vbyte to wait a day but eventually =
confirm.

That introduces the possibility that the entire tree (with high total fee, =
remember) gets confirmed, so it would be better for C to replace it with an=
 alternative to a different address C still controls, with a slightly bette=
r fee rate but smaller (no child transactions) and lower total fee, so an e=
conomically-rational C will make that effort (and if there are still other =
transactions in the mempool, an economically-rational miner will accept thi=
s proposal).

But in any case this is a minor detail and the attack will work either way.

>
> > -   Miners, being economically rational, accept this proposal and inclu=
de 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 hashloc=
k 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 an=
d B queries the peer for this transaction, extracting the preimage and clai=
ming the A->B HTLC.
>
> Note that no query is required. The problem has been solved and the preim=
age-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?

Regards,
ZmnSCPxj