public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt.org>
To: Braydon Fuller <braydon@purse.io>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Chain width expansion
Date: Thu, 3 Oct 2019 22:20:31 -1000	[thread overview]
Message-ID: <20191004082031.ns3pgzwh2zz2mxyc@ganymede> (raw)
In-Reply-To: <42cd5ffd-63e8-b738-c4ea-13d0699b1268@purse.io>

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


  reply	other threads:[~2019-10-04  8:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04  0:38 [bitcoin-dev] Chain width expansion Braydon Fuller
2019-10-04  8:20 ` David A. Harding [this message]
2019-10-04 19:51   ` Braydon Fuller
2019-10-11 21:24   ` Braydon Fuller
2019-10-04 23:31 ` Tier Nolan
2019-10-10 16:16   ` Braydon Fuller
2019-10-12 16:27     ` Tier Nolan
2019-10-12 17:56       ` Joachim Strömbergson
2019-10-12 20:46         ` Tier Nolan
2019-10-16 19:07           ` Braydon Fuller
2019-10-15  0:42         ` Braydon Fuller
2019-10-15  7:20           ` Joachim Strömbergson
2019-10-15  8:12             ` Braydon Fuller
2019-10-15 15:50               ` Joachim Strömbergson
2019-10-16 19:25                 ` Braydon Fuller
2019-10-15 18:30           ` Tier Nolan
2019-10-15  0:38       ` Braydon Fuller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191004082031.ns3pgzwh2zz2mxyc@ganymede \
    --to=dave@dtrt.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=braydon@purse.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox