From: Alistair Mann <al@pectw•net>
To: "Kenshiro []" <tensiam@hotmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Date: Thu, 01 Aug 2019 00:28:56 +0100 [thread overview]
Message-ID: <2084819.YBhD99MD1N@dprfs-d5766> (raw)
In-Reply-To: <DB6PR10MB183271245AAE84FB9AC96474A6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
On Wednesday 31 Jul 2019 14:53:25 Kenshiro [] wrote:
>> How would a (potentially, state-sponsored) netsplit lasting longer than
>> N be handled?
>
> It would be detected by the community much before reaching the reorg limit
> of N blocks (it's 24 hours) so nodes could stop until the netsplit is
> fixed.
A netsplit cannot be detected but merely be suspected where the p2p protocol
does allow arbitrary connecting/disconnecting of any peer: there's no
difference between a remote net being split off, that net having nothing to
say, and that net choosing to disconnect. Detection then mandates manual, out-
of-band communications, which is error prone and centralising.
I also observe 'stopping nodes' during netsplits introduces several attack
vectors. Among them: create a netsplit, which stops the nodes, turn off the
netsplit, repeat. A sequence of 365 actors causing their own small netsplits
could effectively stop Bitcoin at the cost (to them) of no Internet for one
day a year as the rolling netsplit could never be fixed.
> In the extreme case no one notice the network split during more than N
> blocks (24 hours) and there are 2 permanent forks longer than N, nodes from
> one branch could delete their local history so they would join the other
> branch.
>
> P.S.: To be clearer, in this example I set an N value of 144 blocks, which
> is approximately 24 hours.
I've seen estimates of China hosting more than 51% of hashpower. Say they
conduct a netsplit. Does your suggestion mean that it's the rest of the world
that has to delete their local history because they lack the hashpower to
assert themselves as the proper branch? If so, I think having to delete actual
history everywhere across the globe but China is not a price worth paying to
limit reorgs to 24 hours.
I am unconvinced that the moving checkpoint you describe would improve
Bitcoin.
--
Alistair Mann
next prev parent reply other threads:[~2019-07-31 23:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-31 12:28 Kenshiro []
2019-07-31 13:59 ` Alistair Mann
2019-07-31 14:40 ` Kenshiro []
2019-07-31 14:53 ` Kenshiro []
2019-07-31 23:28 ` Alistair Mann [this message]
2019-08-01 10:17 ` Kenshiro []
2019-08-02 12:19 ` Ethan Heilman
2019-08-02 13:08 ` Kenshiro []
2019-08-03 0:51 ` LORD HIS EXCELLENCY JAMES HRMH
2019-08-03 10:35 ` Kenshiro []
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=2084819.YBhD99MD1N@dprfs-d5766 \
--to=al@pectw$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tensiam@hotmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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