diff options
| author | David A. Harding <dave@dtrt.org> | 2019-10-27 12:54:02 -1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-10-27 23:32:33 +0000 |
| commit | 106f89387a10826874fb69059a3c17bf96f11a36 (patch) | |
| tree | 2e6a85365033db5b6b78d9b06b75cedb3d89f55e | |
| parent | 82a88e3273b9a449dd7cd5432b0e809651a1577d (diff) | |
| download | pi-bitcoindev-106f89387a10826874fb69059a3c17bf96f11a36.tar.gz pi-bitcoindev-106f89387a10826874fb69059a3c17bf96f11a36.zip | |
Re: [bitcoin-dev] [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)
| -rw-r--r-- | a2/83d991f68054ca978495bed24c8201bf0582cc | 98 |
1 files changed, 98 insertions, 0 deletions
diff --git a/a2/83d991f68054ca978495bed24c8201bf0582cc b/a2/83d991f68054ca978495bed24c8201bf0582cc new file mode 100644 index 000000000..8d113796a --- /dev/null +++ b/a2/83d991f68054ca978495bed24c8201bf0582cc @@ -0,0 +1,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. + + |