Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ECBD5AF1D for ; 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 ; 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 []" To: Alistair Mann 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: References: , <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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Sent: Thursday, August 1, 2019 1:28 To: Kenshiro [] Cc: Bitcoin Protocol Discussion 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
mm you are right, then the "moving checkpoint" rule needs to have= some limits to allow the network self-heal instead of requiring humans det= ecting 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 bloc= k height difference of 432 blocks (about 3 days) 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.

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.

But maybe I'm missing so= mething 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.linuxfoundatio= n.org>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr= otocol
 
On Wednesday 31 Jul 2019 14:53:25 Kenshiro [] wrot= e:
>> 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 l= imit
> of N blocks (it's 24 hours) so nodes could stop until the netsplit is<= br> > 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= from
> one branch could delete their local history so they would join the oth= er
> branch.
>
> P.S.: To be clearer, in this example I set an N value of 144 blocks, w= hich
> is approximately 24 hours.

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
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
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_--