1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
|
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.
|
