From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 ) 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" To: Johan =?utf-8?B?VG9yw6Vz?= Halseth Message-ID: <20191027225402.rfajp4j6itujq5av@ganymede> References: <878t163qzi.fsf@rustcorp.com.au> <725fc55a-6263-a9fc-74a5-1017cb1cc885@mattcorallo.com> <87wonfem03.fsf@rustcorp.com.au> <87zhr0gvw0.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 , lightning-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.