From ZmnSCPxj at protonmail.com Thu Apr 23 12:46:59 2020 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Thu, 23 Apr 2020 12:46:59 +0000 Subject: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest In-Reply-To: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com> References: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com> Message-ID: <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com> 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?s mempool it would not 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 better fee rate but smaller (no child transactions) and lower total fee, so an economically-rational C will make that effort (and if there are still other transactions in the mempool, an economically-rational miner will accept this 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 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? Regards, ZmnSCPxj