{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-10-04\n📝 Original message:On Thu, Oct 03, 2019 at 05:38:36PM -0700, Braydon Fuller via bitcoin-dev wrote:\n\u003e This paper describes a solution [to DoS attacks] that does not\n\u003e require enabling or maintaining checkpoints and provides improved security.\n\u003e [...] \n\u003e The paper is available at:\n\u003e https://bcoin.io/papers/bitcoin-chain-expansion.pdf\n\nHi Braydon,\n\nThank you for researching this important issue.  An alternative solution\nproposed some time ago (I believe originally by Gregory Maxwell) was a\nsoft fork to raise the minimum difficulty.  You can find discussion of\nit in various old IRC conversations[1,2] as well as in related changes\nto Bitcoin Core such as PR #9053 addining minimum chain work[3] and the\nassumed-valid change added in Bitcoin Core 0.14.0[4].\n\n[1] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html#l-121\n[2] http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-02-19.01.log.html#l-57\n[3] https://github.com/bitcoin/bitcoin/pull/9053/commits/fd46136dfaf68a7046cf7b8693824d73ac6b1caf\n[4] https://bitcoincore.org/en/2017/03/08/release-0.14.0/#assumed-valid-blocks\n\nThe solutions proposed in section 4.2 and 4.3 of your paper have the\nadvantage of not requiring any consensus changes.  However, I find it\nhard to analyze the full consequences of the throttling solution in\n4.3 and the pruning solution in 4.2.  If we assume a node is on the\nmost-PoW valid chain and that a huge fork is unlikely, it seems fine.\nBut I worry that the mechanisms could also be used to keep a node that\nsynced to a long-but-lower-PoW chain on that false chain (or other false\nchain) indefinitely even if it had connections to honest peers that\ntried to tell it about the most-PoW chain.\n\nFor example, with your maximum throttle of 5 seconds between\n`getheaders` requests and the `headers` P2P message maximum of 2,000\nheaders per instance, it would take about half an hour to get a full\nchain worth of headers.  If a peer was disconnected before sending\nenough headers to establish they were on the most-PoW chain, your\npruning solution would delete whatever progress was made, forcing the\nnext peer to start from genesis and taking them at least half an hour\ntoo.  On frequently-suspended laptops or poor connections, it's possible\na node could be be operational for a long time before it kept the same\nconnection open for half an hour.  All that time, it would be on a\ndishonest chain.\n\nBy comparison, I find it easy to analyze the effect of raising the\nminimum difficulty.  It is a change to the consensus rules, so it's\nsomething we should be careful about, but it's the kind of\nbasically-one-line change that I expect should be easy for a large\nnumber of people to review directly.  Assuming the choice of a new\nminimum (and what point in the chain to use it) is sane, I think it\nwould be easy to get acceptance, and I think it would further be easy\nincrease it again every five years or so as overall hashrate increases.\n\n-Dave"}