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 ECEBE9E7; Mon, 28 Oct 2019 17:16: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 8A07E8A0; Mon, 28 Oct 2019 17:16:33 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1iP8d5-0004PH-3T; Mon, 28 Oct 2019 13:16:31 -0400 Date: Mon, 28 Oct 2019 07:14:38 -1000 From: "David A. Harding" To: Johan =?utf-8?B?VG9yw6Vz?= Halseth Message-ID: <20191028171416.7owxqblz3ttsvw5r@ganymede> References: <6728FF51-E378-4AED-99BA-ECB83688AA9C@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-attached: none User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00, DOS_RCVD_IP_TWICE_B, KHOP_HELO_FCRDNS autolearn=no version=3.3.1 X-Spam-Level: * 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: Mon, 28 Oct 2019 17:16:34 -0000 On Mon, Oct 28, 2019 at 10:45:39AM +0100, Johan Torås Halseth wrote: > Relay cost is the obvious problem with just naively removing all limits. > Relaxing the current rules by allowing to add a child to each output as > long as it has a single unconfirmed parent would still only allow free > relay of O(size of parent) extra data (which might not be that bad? Similar > to the carve-out rule we could put limits on the child size). A parent transaction near the limit of 100,000 vbytes could have almost 10,000 outputs paying OP_TRUE (10 vbytes per output). If the children were limited to 10,000 vbytes each (the current max carve-out size), that allows relaying 100 mega-vbytes or nearly 400 MB data size (larger than the default maximum mempool size in Bitcoin Core). As Matt noted in discussion on #lightning-dev about this issue, it's possible to increase second-child carve-out to nth-child carve-out but we'd need to be careful about choosing an appropriately low value for n. For example, BOLT2 limits the number of HTLCs to 483 on each side of the channel (so 966 + 2 outputs total), which means the worst case free relay to support the current LN protocol would be approximately: (100000 + 968 * 10000) * 4 = ~39 MB Even if the mempool was empty (as it sometimes is these days), it would only cost an attacker about 1.5 BTC to fill it at the default minimum relay feerate[1] so that they could execute this attack at the minimal cost per iteration of paying for a few hundred or a few thousand vbytes at slightly higher than the current mempool minimum fee. Instead, with the existing rules (including second-child carve-out), they'd have to iterate (39 MB / 400 kB = ~100) times more often to achieve an equivalent waste of bandwidth, costing them proportionally more in fees. So, I think these rough numbers clearly back what Matt said about us being able to raise the limits a bit if we need to, but that we have to be careful not to raise them so far that attackers can make it significantly more bandwidth expensive for people to run relaying full nodes. -Dave [1] Several developers are working on lowering the default minimum in Bitcoin Core, which would of course make this attack proportionally cheaper.