From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B5EAFC0175 for ; Thu, 23 Apr 2020 12:47:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id A4D0C87E8C for ; Thu, 23 Apr 2020 12:47:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTbeN+us6YuQ for ; Thu, 23 Apr 2020 12:47:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch [185.70.40.137]) by whitealder.osuosl.org (Postfix) with ESMTPS id B164187E84 for ; Thu, 23 Apr 2020 12:47:02 +0000 (UTC) Date: Thu, 23 Apr 2020 12:46:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1587646020; bh=bdz4AmuE1kJNiY7sHfvMa99LyScR/zRqRrd7Ef4A79U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=s1TYmbFsNfT0exPAqASGXxrKe45jHbTZkItD32wVsGIo3Bf5Ck1uX17PMIXwug73t +aquqAATcwdIEuFdABTdauMyIeu3bgkm9PquXx6vCdluFNk0w7FTqXB3B38KFr6NG4 RHEhx5krKXj2wX34RvQJHWvPB0ns0VZ3Ad0XhYPc= To: Matt Corallo From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com> In-Reply-To: <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com> References: <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 , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2020 12:47:04 -0000 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