summaryrefslogtreecommitdiff
path: root/a9/8a4a2bda666e46b2ca456a7309b34d55e6a235
blob: 0f1749aaf7d64e46b0a78e00893fb7c059db9703 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Return-Path: <al@pectw.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E5E2B4264
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 31 Jul 2019 23:28:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from pectw.vm.bytemark.co.uk (pectw.vm.bytemark.co.uk [80.68.92.123])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id EC4417ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 31 Jul 2019 23:28:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=pectw.net; 
	s=dkim_test;
	h=Content-Type:Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:
	Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
	Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
	List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=dnG3/LW7sal9PcyiMWK4N8UiVvRSgSMZMCAeVMB0B14=;
	b=XXYB8xpuE7DQubqvdLLMOgkQpu
	csKAV+4DQlXznks3+b0Y41P43LpfLSzw421bVAXB+CqfDHKbaFe1rArYMaydrf93p2mMQkKku2pYj
	QVUsvxC9So078NU0z0q3D0OQK;
Received: from host109-153-202-196.range109-153.btcentralplus.com
	([109.153.202.196] helo=svetlana.localhost)
	by pectw.vm.bytemark.co.uk with esmtpsa
	(TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1)
	(envelope-from <al@pectw.net>)
	id 1hsy1h-0000u4-3E; Wed, 31 Jul 2019 23:28:57 +0000
From: Alistair Mann <al@pectw.net>
To: "Kenshiro []" <tensiam@hotmail.com>
Date: Thu, 01 Aug 2019 00:28:56 +0100
Message-ID: <2084819.YBhD99MD1N@dprfs-d5766>
User-Agent: KMail/4.14.2 (Linux/4.4.0-18-generic; KDE/4.14.2; x86_64; ; )
In-Reply-To: <DB6PR10MB183271245AAE84FB9AC96474A6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB1832329BC8D151DC18F1E6CEA6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<DB6PR10MB1832F1E966CD83BC662985BDA6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<DB6PR10MB183271245AAE84FB9AC96474A6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 01 Aug 2019 02:12:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 23:29:00 -0000

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