{"type":"rich","version":"1.0","author_name":"Braydon Fuller [ARCHIVE] (npub1fx…xxtaa)","author_url":"https://nostr.ae/npub1fx2eyw7avet7dut0slazcehwvrrlhjp2u9jc9zd92l7nexpxeahs4xxtaa","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-11\n📝 Original message:On 10/4/19 1:20 AM, David A. Harding wrote:\n\n\u003e On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev wrote:\n\u003e\u003e This paper describes a solution [to DoS attacks] that does not\n\u003e\u003e require enabling or maintaining checkpoints and provides improved security.\n\u003e\u003e [...] \n\u003e\u003e The paper is available at:\n\u003e\u003e https://bcoin.io/papers/bitcoin-chain-expansion.pdf\n\u003e Hi Braydon,\n\u003e\n\u003e Thank you for researching this important issue.  An alternative solution\n\u003e proposed some time ago (I believe originally by Gregory Maxwell) was a\n\u003e soft fork to raise the minimum difficulty.  You can find discussion of\n\u003e it in various old IRC conversations[1,2] as well as in related changes\n\u003e to Bitcoin Core such as PR #9053 addining minimum chain work[3] and the\n\u003e assumed-valid change added in Bitcoin Core 0.14.0[4].\n\u003e\n\u003e [1] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html#l-121\n\u003e [2] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.log.html#l-57\n\u003e [3] https://github.com/bitcoin/bitcoin/pull/9053/commits/fd46136dfaf68a7046cf7b8693824d73ac6b1caf\n\u003e [4] https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks\n\u003e\nOkay, here is an overview of what I have found for the minimum\ndifficulty proposal:\n\nIt describes having a new consensus rule to not fork or accept headers\nprior to, or below, a minimum difficulty once the best chain work is\nachieved at release time of the software. This would be instead of the\nrule to not fork before the last checkpoint, as checkpoints are removed.\n\nIt has an advantage to the existing checkpoint solution as it does not\nrequire checkpoints to be enabled. This is not a surprise as the\nproposal was to remove checkpoints entirely. It would increase the cost\nof the attack without checkpoints. Long header chains would need to be\nbuilt using this minimum difficulty, instead of the current lowest\ndifficulty of the genesis block. The exact cost of that is not yet\ncalculated.\n\nThere are a few caveats with the approach mentioned; nodes are\nvulnerable if the initial loader peer is the attacker, it could leave\nminority hashpower without an ability to softfork away during a\ncontentious hardfork, and requires period consensus changes to continue\nto maintain:\n  - Nodes are vulnerable during the initial sync when joining the\nnetwork until the minimum chainwork is achieved. This is possible if the\nloader peer is the attacker. To mitigate this there would need to be a\nminimum chainwork defined based on the current chainwork. However, such\ncould also be used to prevent nodes from joining the network as it's\nrejecting rather that throttling.\n  - A contentious hardfork could leave a minority hashpower without an\nability to softfork away without agreeing on a hardfork. This was the\nreason why the minimum difficulty was about 10 devices instead of 10,000.\n  - It's technically a consensus change each time the minimum difficulty\nor best chainwork is updated. It is a similar consensus change as\nmaintaining the last checkpoint, as it's used to prevent forking prior\nto the last checkpoint.\n\nI think the solution proposed in the Bitcoin Chain Width Expansion paper\nsolves those issues by limiting chain width and throttling based on\nchainwork, instead of rejecting blocks based on the minimum difficulty."}