rich1.0Braydon Fuller [ARCHIVE] (npub1fx…xxtaa)https://nostr.ae/npub1fx2eyw7avet7dut0slazcehwvrrlhjp2u9jc9zd92l7nexpxeahs4xxtaanjumphttps://nostr.ae📅 Original date posted:2019-10-11 📝 Original message:On 10/4/19 1:20 AM, David A. Harding wrote: > 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 > Okay, here is an overview of what I have found for the minimum difficulty proposal: It describes having a new consensus rule to not fork or accept headers prior to, or below, a minimum difficulty once the best chain work is achieved at release time of the software. This would be instead of the rule to not fork before the last checkpoint, as checkpoints are removed. It has an advantage to the existing checkpoint solution as it does not require checkpoints to be enabled. This is not a surprise as the proposal was to remove checkpoints entirely. It would increase the cost of the attack without checkpoints. Long header chains would need to be built using this minimum difficulty, instead of the current lowest difficulty of the genesis block. The exact cost of that is not yet calculated. There are a few caveats with the approach mentioned; nodes are vulnerable if the initial loader peer is the attacker, it could leave minority hashpower without an ability to softfork away during a contentious hardfork, and requires period consensus changes to continue to maintain:   - Nodes are vulnerable during the initial sync when joining the network until the minimum chainwork is achieved. This is possible if the loader peer is the attacker. To mitigate this there would need to be a minimum chainwork defined based on the current chainwork. However, such could also be used to prevent nodes from joining the network as it's rejecting rather that throttling.   - A contentious hardfork could leave a minority hashpower without an ability to softfork away without agreeing on a hardfork. This was the reason why the minimum difficulty was about 10 devices instead of 10,000.   - It's technically a consensus change each time the minimum difficulty or best chainwork is updated. It is a similar consensus change as maintaining the last checkpoint, as it's used to prevent forking prior to the last checkpoint. I think the solution proposed in the Bitcoin Chain Width Expansion paper solves those issues by limiting chain width and throttling based on chainwork, instead of rejecting blocks based on the minimum difficulty.