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 854E9103E for ; Fri, 4 Oct 2019 08:21:33 +0000 (UTC) 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 69B19709 for ; Fri, 4 Oct 2019 08:21:32 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1iGIqB-0003SX-DL; Fri, 04 Oct 2019 04:21:31 -0400 Date: Thu, 3 Oct 2019 22:20:31 -1000 From: "David A. Harding" To: Braydon Fuller , Bitcoin Protocol Discussion Message-ID: <20191004082031.ns3pgzwh2zz2mxyc@ganymede> References: <42cd5ffd-63e8-b738-c4ea-13d0699b1268@purse.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42cd5ffd-63e8-b738-c4ea-13d0699b1268@purse.io> 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 Subject: Re: [bitcoin-dev] Chain width expansion 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: Fri, 04 Oct 2019 08:21:33 -0000 On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev wrote: > This paper describes a solution [to DoS attacks] that does not > require enabling or maintaining checkpoints and provides improved security. > [...] > The paper is available at: > https://bcoin.io/papers/bitcoin-chain-expansion.pdf Hi Braydon, Thank you for researching this important issue. An alternative solution proposed some time ago (I believe originally by Gregory Maxwell) was a soft fork to raise the minimum difficulty. You can find discussion of it in various old IRC conversations[1,2] as well as in related changes to Bitcoin Core such as PR #9053 addining minimum chain work[3] and the assumed-valid change added in Bitcoin Core 0.14.0[4]. [1] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html#l-121 [2] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.log.html#l-57 [3] https://github.com/bitcoin/bitcoin/pull/9053/commits/fd46136dfaf68a7046cf7b8693824d73ac6b1caf [4] https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks The solutions proposed in section 4.2 and 4.3 of your paper have the advantage of not requiring any consensus changes. However, I find it hard to analyze the full consequences of the throttling solution in 4.3 and the pruning solution in 4.2. If we assume a node is on the most-PoW valid chain and that a huge fork is unlikely, it seems fine. But I worry that the mechanisms could also be used to keep a node that synced to a long-but-lower-PoW chain on that false chain (or other false chain) indefinitely even if it had connections to honest peers that tried to tell it about the most-PoW chain. For example, with your maximum throttle of 5 seconds between `getheaders` requests and the `headers` P2P message maximum of 2,000 headers per instance, it would take about half an hour to get a full chain worth of headers. If a peer was disconnected before sending enough headers to establish they were on the most-PoW chain, your pruning solution would delete whatever progress was made, forcing the next peer to start from genesis and taking them at least half an hour too. On frequently-suspended laptops or poor connections, it's possible a node could be be operational for a long time before it kept the same connection open for half an hour. All that time, it would be on a dishonest chain. By comparison, I find it easy to analyze the effect of raising the minimum difficulty. It is a change to the consensus rules, so it's something we should be careful about, but it's the kind of basically-one-line change that I expect should be easy for a large number of people to review directly. Assuming the choice of a new minimum (and what point in the chain to use it) is sane, I think it would be easy to get acceptance, and I think it would further be easy increase it again every five years or so as overall hashrate increases. -Dave