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
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
Return-Path: <dave@dtrt.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82CCE2F;
Sun, 27 Oct 2019 23:32:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 21D89786;
Sun, 27 Oct 2019 23:32:32 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1iOs1P-0002UW-EW; Sun, 27 Oct 2019 19:32:31 -0400
Date: Sun, 27 Oct 2019 12:54:02 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Johan =?utf-8?B?VG9yw6Vz?= Halseth <johanth@gmail.com>
Message-ID: <20191027225402.rfajp4j6itujq5av@ganymede>
References: <c3f68b73-84c6-7428-4bf6-b47802141392@mattcorallo.com>
<878t163qzi.fsf@rustcorp.com.au>
<725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com>
<87wonfem03.fsf@rustcorp.com.au>
<D072562F-5AD0-4B38-94D1-A0AEF04C3DEB@mattcorallo.com>
<87zhr0gvw0.fsf@rustcorp.com.au>
<CAD3i26AjhQ9VkCo_5y8aqZ_8YvSqKP2MCkdRv8YunjAhmmXz=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAD3i26AjhQ9VkCo_5y8aqZ_8YvSqKP2MCkdRv8YunjAhmmXz=Q@mail.gmail.com>
User-Agent: NeoMutt/20180716
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DOS_RCVD_IP_TWICE_B,
KHOP_HELO_FCRDNS autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction
Issues in Contracting Applications (eg Lightning)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sun, 27 Oct 2019 23:32:33 -0000
On Thu, Oct 24, 2019 at 03:49:09PM +0200, Johan Torås Halseth wrote:
> [...] what about letting the rule be
>
> The last transaction which is added to a package of dependent
> transactions in the mempool must:
> * Have no more than one unconfirmed parent.
> [... subsequent email ...]
> I realize these limits are there for a reason though, but I'm wondering if
> we could relax them.
Johan,
I'm not sure any of the other replies to this thread addressed your
request for a reason behind the limits related to your proposal, so I
thought I'd point out that---subsequent to your posting here---a
document[1] was added to the Bitcoin Core developer wiki that I think
describes the risk of the approach you proposed:
> Free relay attack:
>
> - Create a low feerate transaction T.
>
> - Send zillions of child transactions that are slightly higher feerate
> than T until mempool is full.
>
> - Create one small transaction with feerate just higher than T’s, and
> watch T and all its children get evicted. Total fees in mempool drops
> dramatically!
>
> - Attacker just relayed (say) 300MB of data across the whole network
> but only pays small feerate on one small transaction.
The document goes on to describe at a high level how Bitcoin Core
attempts to mitigate this problem as well as other ways it tries to
optimize the mempool in order to maximize miner profit (and so ensure
that miners continue to use public transaction relay).
I hope that's helpful to you and to others in both understanding the
current state and in thinking about ways in which it might be improved.
-Dave
[1] https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining
Content adapted from slides by Suhas Daftuar, uploaded and formatted
by Gregory Sanders and Marco Falke.
|
