path: root/11/aa8ac3fd3da7b1d22e99b77d9fcbcd3796a33c

Return-Path: <tensiam@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id ECBD5AF1D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  1 Aug 2019 10:18:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from EUR02-AM5-obe.outbound.protection.outlook.com
	(mail-oln040092067071.outbound.protection.outlook.com [40.92.67.71])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8B7EB7ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  1 Aug 2019 10:17:58 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
	b=ah1r/P19ZwCfy9Ug5noJY4m+wL9iik1Q5YH1lTJrjVvmpAAKKrZab5d0ANAJfvMbmZijMrRO+sMirFE0XXbD9b3P2OedwTYSF8vWz5fozXBLQD7GxmMVQTKG+CqjNGaPS0IOL0fG7yWV+UxXoGKoZrBni55b3uvsnvVwHYW6TiMH6Yg6bBybCcd4IRkRID+Q1mXqlXbCh0q35n4uTSz52tKaU+FDLe2H6UsbnSHF0wDa5/eT3fZjKu7v1K4rbe70yJX6mFxv27IgudHTmdBPVHLfen3jx9HQLe7vTgFxtqNb4yfVLACzvtdDT2yN7AC4RIBKzPOSVdJImeTBMtPLEQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
	s=arcselector9901;
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
	bh=VOnxR96x/sPBT3WtAEQFZmS03j6nQ6vZvIypz7OiyJY=;
	b=YkkINRtN8SiUgpKv3Aqg+QBjtu090m5F7wDas380EuuTvYGAk4gik1+YSSIzI/V8inM1auPeKNspYhGAJfDxBMHpQhQyxAiYZcvJvnVJo7nDLRttB+mCx55bDQxGMrFk9AePTKflKdMNBYGQb0YPgN5AAmenjjn3P0zHrsF+3eaY71KyndZYR2zijrgQIuxjubB286K3DWQfvomfxqs12jqeX8NO+GEsyjRvv7Y5QB3Z8XCCD8ifMaloL8PZBCiCI8PeJY3J6BhJ2MEFKpDtlBB38tNNVB9zv8iTYhjn+yT9ImFtKRU95aZJbm8zs64iFLMOTK/17rOfUzmaB0hfQQ==
ARC-Authentication-Results: i=1; mx.microsoft.com
	1;spf=none;dmarc=none;dkim=none;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com;
	s=selector1;
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
	bh=VOnxR96x/sPBT3WtAEQFZmS03j6nQ6vZvIypz7OiyJY=;
	b=Z2T0guORtHxIQQDtyFgKje/a0i0e7VxreaWL4utt4oTwYTzPMm+zaDsOhHy5Yf61FnmXKbeYOB/tqM43iYWwl7Sd2NZajXprT/o5DXFRwSh/XlJiHytvpj/gTjgR6w+VLz57xeduSZFxvlebntCeatsP6q1qA3w67M/Nhrsr7+5+0bG5pFKtvDGmVPahmJJoqvxQgf2po6jbuE+boUPbRYcWELAsCxCPKRWKIWrx4/nMcuFjfb8rN4lRULl39BVDRB/g7zgNwQltOy/fmzvIKsZLY+fC/AV1a3/RgQ1xnKyrKqj7mxZSeCzFa8YJRdYxzltR38s4WLve06DI2FW2Wg==
Received: from AM5EUR02FT016.eop-EUR02.prod.protection.outlook.com
	(10.152.8.59) by AM5EUR02HT153.eop-EUR02.prod.protection.outlook.com
	(10.152.9.244) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2136.14;
	Thu, 1 Aug 2019 10:17:56 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.8.57) by
	AM5EUR02FT016.mail.protection.outlook.com (10.152.8.90) with Microsoft
	SMTP
	Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
	15.20.2136.14 via Frontend Transport; Thu, 1 Aug 2019 10:17:56 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
	([fe80::cc12:47f0:aa33:6b70]) by
	DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
	([fe80::cc12:47f0:aa33:6b70%3]) with mapi id 15.20.2115.005;
	Thu, 1 Aug 2019 10:17:56 +0000
From: "Kenshiro []" <tensiam@hotmail.com>
To: Alistair Mann <al@pectw.net>
Thread-Topic: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol
Thread-Index: AQHVR5sdyaW9NUkjL067/8euo+yr/KbkwSWAgAAJxaeAAAS0t4AAkJ0AgACw6+k=
Date: Thu, 1 Aug 2019 10:17:56 +0000
Message-ID: <DB6PR10MB1832679F3A195358D234111CA6DE0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB1832329BC8D151DC18F1E6CEA6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<DB6PR10MB1832F1E966CD83BC662985BDA6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<DB6PR10MB183271245AAE84FB9AC96474A6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<2084819.YBhD99MD1N@dprfs-d5766>
In-Reply-To: <2084819.YBhD99MD1N@dprfs-d5766>
Accept-Language: en-US, es-ES
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:EAC73B54A9B3EF46BC3E480D6BDBCD4B73EC5A61590C55E0900352218EC83AD1;
	UpperCasedChecksum:33F5B82B420A3B6489BB34CFE07AB006DC141969866D702DBAA09A9EDCC9394F;
	SizeAsReceived:7010; Count:43
x-tmn: [pc22gdheW9WeJc/r4RnqzwjggmZ85JGd]
x-ms-publictraffictype: Email
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0;
	RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045);
	SRVR:AM5EUR02HT153; 
x-ms-traffictypediagnostic: AM5EUR02HT153:
x-microsoft-antispam-message-info: WUbY6/Z7KTXSnCTqLkCBiJTZhawlEETZgl3pqRiKb9iX8q3Yh+clBfktZmmPW23HD9WYviaHzryBmwcMdIN3iCizZGGNOwXiXQoS2RztLsM1hyzeH7IhcoasNmdUxzvJBTMvMjbn/yysFR43ePLkz3Ms8+POaOEhcfKQG55kZ1RRoErb2vi9Ob8yIqPjrhNL
Content-Type: multipart/alternative;
	boundary="_000_DB6PR10MB1832679F3A195358D234111CA6DE0DB6PR10MB1832EURP_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 048da7ac-825a-4fe7-8d90-08d7166985a8
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2019 10:17:56.5298 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT153
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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 14:26:02 +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: Thu, 01 Aug 2019 10:18:01 -0000

--_000_DB6PR10MB1832679F3A195358D234111CA6DE0DB6PR10MB1832EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

mm you are right, then the "moving checkpoint" rule needs to have some limi=
ts to allow the network self-heal instead of requiring humans detecting the=
 splits or stopping nodes.

Let's suppose than a 51% attack can be detected and the developers can rele=
ase a new version of the software with a new mining protocol in about 3 day=
s. Then the complementary rule could be something like this:

- If 2 forks have a block height difference of 432 blocks (about 3 days) or=
 more, then the moving checkpoint rule is ignored and everything works as w=
ith the current protocol. With this rule, the network can self-heal in a 10=
0% automated way.

This would prevent a history rewrite of more than 24 hours during a 51% att=
ack during 3 days, which should give enough time to change the protocol. If=
 instead of a 51% attack what happens is a network split, then nodes should=
 converge to the longest chain in a few days.

But maybe I'm missing something here, I'm still learning.

Regards,



________________________________
From: Alistair Mann <al@pectw.net>
Sent: Thursday, August 1, 2019 1:28
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

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 limi=
t
> 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 protoco=
l
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, o=
ut-
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 netsplit=
s
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 fr=
om
> 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, whic=
h
> 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 wor=
ld
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 act=
ual
history everywhere across the globe but China is not a price worth paying t=
o
limit reorgs to 24 hours.

I am unconvinced that the moving checkpoint you describe would improve
Bitcoin.
--
Alistair Mann

--_000_DB6PR10MB1832679F3A195358D234111CA6DE0DB6PR10MB1832EURP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
mm you are right, then the &quot;moving checkpoint&quot; rule needs to have=
 some limits to allow the network self-heal instead of requiring humans det=
ecting the splits or stopping nodes.&nbsp;</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
Let's suppose than a 51% attack can be detected and the developers can rele=
ase a new version of the software with a new mining protocol in about 3 day=
s. Then the complementary rule could be something like this:</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important">- If 2 forks have a bloc=
k height difference of 432 blocks
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important">
(about 3 days)&nbsp;</span>or more, then the moving checkpoint rule is igno=
red and everything works as with the current protocol. With this rule, the =
network can self-heal in a 100% automated way.</span><br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important">This would prevent a his=
tory rewrite of more than 24 hours during a 51% attack during 3 days, which=
 should give enough time to change
 the protocol. If instead of a 51% attack what happens is a network split, =
then nodes should converge to the longest chain in a few days.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important">But maybe I'm missing so=
mething here, I'm still learning.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"font-family: Calibri, Helvetica, sans-serif; background-colo=
r: rgb(255, 255, 255); display: inline !important">Regards,</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" co=
lor=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Alistair Mann &lt;al@=
pectw.net&gt;<br>
<b>Sent:</b> Thursday, August 1, 2019 1:28<br>
<b>To:</b> Kenshiro [] &lt;tensiam@hotmail.com&gt;<br>
<b>Cc:</b> Bitcoin Protocol Discussion &lt;bitcoin-dev@lists.linuxfoundatio=
n.org&gt;<br>
<b>Subject:</b> Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr=
otocol</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">On Wednesday 31 Jul 2019 14:53:25 Kenshiro [] wrot=
e:<br>
&gt;&gt; How would a (potentially, state-sponsored) netsplit lasting longer=
 than<br>
&gt;&gt; N be handled?<br>
&gt;<br>
&gt; It would be detected by the community much before reaching the reorg l=
imit<br>
&gt; of N blocks (it's 24 hours) so nodes could stop until the netsplit is<=
br>
&gt; fixed.<br>
<br>
A netsplit cannot be detected but merely be suspected where the p2p protoco=
l <br>
does allow arbitrary connecting/disconnecting of any peer: there's no <br>
difference between a remote net being split off, that net having nothing to=
 <br>
say, and that net choosing to disconnect. Detection then mandates manual, o=
ut-<br>
of-band communications, which is error prone and centralising.<br>
<br>
I also observe 'stopping nodes' during netsplits introduces several attack =
<br>
vectors. Among them: create a netsplit, which stops the nodes, turn off the=
 <br>
netsplit, repeat. A sequence of 365 actors causing their own small netsplit=
s <br>
could effectively stop Bitcoin at the cost (to them) of no Internet for one=
 <br>
day a year as the rolling netsplit could never be fixed.<br>
<br>
&gt; In the extreme case no one notice the network split during more than N=
<br>
&gt; blocks (24 hours) and there are 2 permanent forks longer than N, nodes=
 from<br>
&gt; one branch could delete their local history so they would join the oth=
er<br>
&gt; branch.<br>
&gt;<br>
&gt; P.S.: To be clearer, in this example I set an N value of 144 blocks, w=
hich<br>
&gt; is approximately 24 hours.<br>
<br>
I've seen estimates of China hosting more than 51% of hashpower. Say they <=
br>
conduct a netsplit. Does your suggestion mean that it's the rest of the wor=
ld <br>
that has to delete their local history because they lack the hashpower to <=
br>
assert themselves as the proper branch? If so, I think having to delete act=
ual <br>
history everywhere across the globe but China is not a price worth paying t=
o <br>
limit reorgs to 24 hours.<br>
<br>
I am unconvinced that the moving checkpoint you describe would improve <br>
Bitcoin.<br>
-- <br>
Alistair Mann<br>
</div>
</span></font></div>
</div>
</body>
</html>

--_000_DB6PR10MB1832679F3A195358D234111CA6DE0DB6PR10MB1832EURP_--