Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 621473D06 for ; Wed, 31 Jul 2019 14:40:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-oln040092072088.outbound.protection.outlook.com [40.92.72.88]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D94418BA for ; Wed, 31 Jul 2019 14:40:53 +0000 (UTC) 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=us/iVC9iTsHBWe2FNijYTfcPDEexHDkR77Iwo/0uqXg=; b=HTM5sR/E8XonxWi5fJfs/IJP4SosfcqRe59upfiSH97E+3BpxAgP3YacSRo78iKXUQ0SCSFjqp38U5Prd1H9S42prnxKKNnSoFEAUMl+VTI/9iCg20NSTJYqElSKH6EsidzKRpeWbnyovT60GYXc0yB24AOjMPx56gaQhibciSdEwy0yF5Z7Hfd2fM/y445avXPXe7nSl17+kDsG5vEQnpWpJo4/vnBHu6p+4/cifxlPqXWWkh063SduSQanQBU3ZIWcxk5cizSfgRCY6Iw6sJQj8Mihs3e0ys/RmxpQMrqlKHMXgHymMDSoGH0w6kAMSuGgguEIPHvknfve/cLk7g== Received: from DB5EUR03FT019.eop-EUR03.prod.protection.outlook.com (10.152.20.53) by DB5EUR03HT048.eop-EUR03.prod.protection.outlook.com (10.152.21.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18; Wed, 31 Jul 2019 14:40:50 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.20.55) by DB5EUR03FT019.mail.protection.outlook.com (10.152.20.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Wed, 31 Jul 2019 14:40:50 +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; Wed, 31 Jul 2019 14:40:50 +0000 From: "Kenshiro []" To: Alistair Mann , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Thread-Index: AQHVR5sdyaW9NUkjL067/8euo+yr/KbkwSWAgAAJxac= Date: Wed, 31 Jul 2019 14:40:50 +0000 Message-ID: References: , <28454621.Lge63Ifvux@dprfs-d5766> In-Reply-To: <28454621.Lge63Ifvux@dprfs-d5766> Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:225A9B3023BEB703012317AA1596356B3FF3C65E6350B3BA397AE3BA047607EB; UpperCasedChecksum:573B0A33DC9E5200D77DAFF7FE38FA1A0C853A9265AF13868FC0311BF1349A52; SizeAsReceived:6811; Count:42 x-tmn: [iy+GzXU1rXsZNfbyKuRHimlmzyLCtPqQ] x-ms-publictraffictype: Email x-incomingheadercount: 42 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:DB5EUR03HT048; x-ms-traffictypediagnostic: DB5EUR03HT048: x-microsoft-antispam-message-info: D9GWYD7Ms1qM2gBoPqbuXzKur1OXmvbIcdYvm+YAjOkxg6s3aWWF+eFYF/3y2fZDIBbeY3As2YzfVQYNEarnw6Afy1F9GVU/yw0zEkAc1CJrEbrAXxOYQpaeH9yhD8ckhk/zNjmysV7I6pZ64Tzj0sFs/IxLQCDZcfphMRu15nLG5mYrUeLK2VolvtI3WEH8 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1832F1E966CD83BC662985BDA6DF0DB6PR10MB1832EURP_" 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: 2ac47eb5-1648-4be5-4a41-08d715c5153d X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2019 14:40:50.4693 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR03HT048 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: Wed, 31 Jul 2019 18:20:06 +0000 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: Wed, 31 Jul 2019 14:40:55 -0000 --_000_DB6PR10MB1832F1E966CD83BC662985BDA6DF0DB6PR10MB1832EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >>> 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= . In the extreme case no one notice the network split during more than N bloc= ks (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 branc= h. Regards, ________________________________ From: Alistair Mann Sent: Wednesday, July 31, 2019 15:59 To: Kenshiro [] ; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote: > I would like to propose that a "moving checkpoint" is added to the Bitcoi= n > protocol. It's a very simple rule already implemented in NXT coin: > > - A node will ignore any new block under nodeBlockHeight - N, so the > blockchain becomes truly immutable after N blocks, even during a 51% atta= ck > which thanks to the moving checkpoint can't rewrite history older than th= e > last N blocks. How would a (potentially, state-sponsored) netsplit lasting longer than N b= e handled? -- Alistair Mann --_000_DB6PR10MB1832F1E966CD83BC662985BDA6DF0DB6PR10MB1832EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>>> 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. 

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, n= odes from one branch could delete their local history so they would join th= e other branch.

Regards,


From: Alistair Mann <al@= pectw.net>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] <tensiam@hotmail.com>; Bitcoin Protocol Discus= sion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr= otocol
 
On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via = bitcoin-dev wrote:

> I would like to propose that a "moving checkpoint" is added = to the Bitcoin
> protocol. It's a very simple rule already implemented in NXT coin:
>
> - A node will ignore any new block under nodeBlockHeight - N, so the > blockchain becomes truly immutable after N blocks, even during a 51% a= ttack
> which thanks to the moving checkpoint can't rewrite history older than= the
> last N blocks.

How would a (potentially, state-sponsored) netsplit lasting longer than N b= e
handled? 
--
Alistair Mann

--_000_DB6PR10MB1832F1E966CD83BC662985BDA6DF0DB6PR10MB1832EURP_--