+Return-Path: <lf-lists@mattcorallo.com>

+Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])

+ by lists.linuxfoundation.org (Postfix) with ESMTP id 3FC77C0175;

+ Thu, 23 Apr 2020 22:47:51 +0000 (UTC)

+Received: from localhost (localhost [127.0.0.1])

+ by hemlock.osuosl.org (Postfix) with ESMTP id 31ACB88688;

+ Thu, 23 Apr 2020 22:47:51 +0000 (UTC)

+X-Virus-Scanned: amavisd-new at osuosl.org

+Received: from hemlock.osuosl.org ([127.0.0.1])

+ by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)

+ with ESMTP id qr3VY47c8PJr; Thu, 23 Apr 2020 22:47:50 +0000 (UTC)

+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6

+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6

+Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])

+ by hemlock.osuosl.org (Postfix) with ESMTPS id 8AA46876A0;

+ Thu, 23 Apr 2020 22:47:50 +0000 (UTC)

+Received: from [IPv6:2620:6e:a007:233::100] (unknown

+ [IPv6:2620:6e:a007:233::100])

+ by mail.as397444.net (Postfix) with ESMTPSA id BE1112346FB;

+ Thu, 23 Apr 2020 22:47:47 +0000 (UTC)

+To: ZmnSCPxj <ZmnSCPxj@protonmail.com>

+References: <PtYNeePySy_thDHm8FwIIGEk32EjJpSmiwPctyEg0hOrLZEHjO1IBghm4MWY88g51K-XF2pf_JDnW0UdTL6QSbACEj21h9U1s5ITc_N3I6Q=@protonmail.com>

+ <67334082-5ABA-45C7-9C09-FF19B119C80D@mattcorallo.com>

+ <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>

+From: Matt Corallo <lf-lists@mattcorallo.com>

+Message-ID: <4c4f3a06-0078-ef6a-7b06-7484f0f9edf1@mattcorallo.com>

+Date: Thu, 23 Apr 2020 18:47:46 -0400

+User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101

+ Thunderbird/68.7.0

+MIME-Version: 1.0

+In-Reply-To: <62P_3wvv8z7AVCdKPfh-bs30-LliHkx9GI9Og3wqIK6hadIG0d6MJJm077zac1erpPUy31FqgZjkAjEl9AQtrOCg4XA5cxozBb7-OIbbgvE=@protonmail.com>

+Content-Type: text/plain; charset=utf-8

+Content-Language: en-US

+Content-Transfer-Encoding: 7bit

+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

+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org

+X-Mailman-Version: 2.1.15

+Precedence: list

+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>

+X-List-Received-Date: Thu, 23 Apr 2020 22:47:51 -0000

+

+

+

+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.

+