From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C52D61AF5 for ; Sat, 3 Aug 2019 10:35:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-oln040092064060.outbound.protection.outlook.com [40.92.64.60]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1CC49832 for ; Sat, 3 Aug 2019 10:35:53 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gWvWt39JzLhPtzq/ZttII50PTngkVTm5mNNyI470bTija4onBN4jbx9JoE3zFLZ6BYKXV5kwchbl45q4zAPjJLJ+B2aHfgfAAX2AJYJGPiwddn65K3HQBEfCAj24lATeGoFAfLqYxagwPKDEoWEo6JfG88xFglt6/95lfRi/RRqaiXSZwbuWTu3ljAJntfMwQiix4WzNL2IXzg0fIIev9sazyjU9oBN7ft/FA/yCQqiTYdpcJgFDFH7QVpBkx2gLzV5CriG++F0iHM5pQP6OISp0YjHGcWmvLK8iLyZHSl+H6eUwSOEGr6EmbbHMB4l9mbXNRENomq98ZWC2LAea+Q== 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=zoFA0UbTNNmlPQQLKfNqEjD6VglHEeqqzlrFh4BONTE=; b=Sei9gy7880aik7TAaltIJ5EJARhA3kV3xAtZxDwQkJM/JiW7zkgwU4S35km1mkoNwJQpQpT0zfCEap4Gi5xT3qj+R87PKz7Wb6Ysl0nTFPz/emmBWCDFik3u2mNpPNL/TRIfir5ssRb/Or5q/fvJUZaoezwCh/UkEriAyjWgIeFXSEH7iD6+DtMuOBFRQZaRG6KZPvLEDSo3FIIr3N1PaK5m6X4pbK8dSxEb4e9EaF6G9r5V+mQSOGo7e0bP4/bPk1fPkznK+BKMNwLsBATJYhIiDRNFwKNq9Q18+c41jtdV+5Clx6UbKUa5eMsX9ucj/63/s9dLP6XsPaCsncPUaA== 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=zoFA0UbTNNmlPQQLKfNqEjD6VglHEeqqzlrFh4BONTE=; b=st8jknZ/hpy/D3TUoaUIXPXGsGKWVmgJhcJYUqx7tZlvb91Ef95qDkO+6Rugpi8qnEX3H3A/jmOYeamJO89aAmfYC3+9/4l0Cakb0Vf38pfkvDBZGBl2Igb5WsEd95O/J1up3ITaTQ1xtU4VSR1ovDd5b1nOj1E79sR8z9Ovbh0d2kj3pFLVGkcM6bUgfaJN8VfsUL/dy2+tV4Cik+pb2UsFXO1FQcCm5mMzpUP6S44a14MlWkcstjlb0vdlhHV2jNVRRF9oMmsn1DTKiZnwEgYsN8f9cCy1YY6J/AS+SHDpJOA4GUc67odFNJZvAsv+8RMAj3ERlk5DFynYu6CBbA== Received: from DB5EUR01FT019.eop-EUR01.prod.protection.outlook.com (10.152.4.54) by DB5EUR01HT110.eop-EUR01.prod.protection.outlook.com (10.152.5.178) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2136.14; Sat, 3 Aug 2019 10:35:51 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.4.51) by DB5EUR01FT019.mail.protection.outlook.com (10.152.4.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.14 via Frontend Transport; Sat, 3 Aug 2019 10:35:51 +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; Sat, 3 Aug 2019 10:35:51 +0000 From: "Kenshiro []" To: LORD HIS EXCELLENCY JAMES HRMH , Ethan Heilman , Bitcoin Dev Thread-Topic: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Thread-Index: AQHVR5sdyaW9NUkjL067/8euo+yr/KbkwSWAgAAJxaeAAAS0t4AC+h2AgAAG9aGAAMoOK4AAoGqV Date: Sat, 3 Aug 2019 10:35:51 +0000 Message-ID: References: <28454621.Lge63Ifvux@dprfs-d5766> , , , In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:67812D7658CA6C76B30B5946F4370AD4E79C92E9AFE1CD53993A018542DD5996; UpperCasedChecksum:D03A4D53EC403047DC9081C4B922EDB90E2A66072BC8548E5DF586E96DAA0104; SizeAsReceived:7354; Count:42 x-tmn: [+ApgAsIgTC1UZLzF+ENknpvxcbsr1IOn] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-ms-exchange-slblob-mailprops: =?iso-8859-1?Q?M9gwXUYrltzRFme5h3KRKBalSwDKU8BqfKXUP7h26tC3do6mPo8eYwvU7e?= =?iso-8859-1?Q?K3BlOrSax2Rf2OdhMQWQbumBgjWHP1QIKFfWzX2RNif2uf+MzDt2RSBBAu?= =?iso-8859-1?Q?SKjwTpdXLoGXKou94pTIUEh2nd3T3rnhKQT56XFuWCbaKs669WPJYL75DJ?= =?iso-8859-1?Q?5DSj4cbFUM0D1PgnwD+5YyznxT4JXy37VL0jpjb7OPID0WCtpfeYLfzuNQ?= =?iso-8859-1?Q?9sztwfZfDj6zg0Yc14d36IUyebAxVGslUz3HdTFvRMXyfsxAz4aK7zXiej?= =?iso-8859-1?Q?c51XK2thkPqh6jXu/8rKqAhbyIa/1S9T1LO5/6bsAdjb1eao/HD401rYmF?= =?iso-8859-1?Q?YIQw+JvlO4JDXINLmmUGSXUC5xAFaG8+Oh6OLr3Xwwjy/IdBu65rZHZ8wl?= =?iso-8859-1?Q?glOdpC//QYz4scgVqMSXwz20DCAypdkLSmG3hotwDlaCG2JCXuWurL0tD1?= =?iso-8859-1?Q?mpQvRizKr0pV7je0jpiktVpstYPTu+nHGuwmmf6DvDp2GTfr4wCHLvuL1p?= =?iso-8859-1?Q?Ulkn180fvKrAQ7pcXQiKaXPrOluKg+dVIuth98KjcnDt4vThkC6Ct6gRFY?= =?iso-8859-1?Q?7jNgC75LKuo52DBFS4iuZc72H4MlIMcu+FqXB5Mb7PtuJQhfKTLBUnxqCC?= =?iso-8859-1?Q?ciyU8Mu81Me8sOiOL+KMnkmf6Ir6NUR6hwc1q5NDMkkCVxpLfUI0yLn5PO?= =?iso-8859-1?Q?02WZzLDisBMKDbXDhAZuuwojgg+tEM1dCXW+h7EzhFROsh/jSe8KryQksY?= =?iso-8859-1?Q?iA4aKPeJZSniZsZUOcWUJzMrSjTvudrM2n3BKsDGZIHRskkIJWC2UtZT69?= =?iso-8859-1?Q?CpJPa+TTfzuFj9R1/AgyLXTrl8Ay0S9WWb4lWPRuGu2dx9VmiUnKU5ws+O?= =?iso-8859-1?Q?fJhun5L9+16uZeMU6XEFG4xrVaqqSBKqjjrcdtuU7jtthMafIH806xFHCT?= =?iso-8859-1?Q?VoI3RW++We9P3zcwGaxVD2wIM26un3Wk8UKl8Mmfs4w/YbSVMu0CIAs4DA?= =?iso-8859-1?Q?OTeSyxMHXkT5ZuoGJqXZTQxEgdT4zMcvSuD84WhM9c2Vo7I488NtgynD8j?= =?iso-8859-1?Q?9aoEt+bojUGw?= x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(201702181274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:DB5EUR01HT110; x-ms-traffictypediagnostic: DB5EUR01HT110: x-ms-exchange-purlcount: 2 x-microsoft-antispam-message-info: Ifuf56kOWDGY80EiZgmX1BVtY3C0YOD5Iz43Go7DTynEes/Ay4dqmMq60YSnk8PCeiyA3EN+IqECiR9grvbkYOE0RAyKebXYG+uDxgabW01RkkGl2zHfDDdSLpw6C3DEG/wx9nlFUPylNDg3FTqQ1LzGcRuNaXE6QrPrymoRO7H6NwDpv2J6x/vbQRJjNJPz Content-Type: multipart/alternative; boundary="_000_DB6PR10MB18326F80886EFE159176893DA6D80DB6PR10MB1832EURP_" 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: 90abc0ba-29b4-4feb-cd2f-08d717fe5b00 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2019 10:35:51.0756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT110 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: Sat, 03 Aug 2019 13:05:52 +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: Sat, 03 Aug 2019 10:35:54 -0000 --_000_DB6PR10MB18326F80886EFE159176893DA6D80DB6PR10MB1832EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good point, for the moving checkpoint a number of blocks (or maybe a timest= amp) could be enough, but for the block limit of X blocks to decide if the = moving checkpoint is ignored or not, as we have to compare two chains (main= chain and fork) maybe is much better to measure the blockchain lengths as = numberOfBlocks * averageBlockDifficulty, so if a difficulty adjustment happ= ens in that time interval, it's taken into account. Regards ________________________________ From: LORD HIS EXCELLENCY JAMES HRMH Sent: Saturday, August 3, 2019 2:51 To: Ethan Heilman ; Bitcoin Dev ; Kenshiro [] Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol I have but one point to make in a brief catch-up read over. With the current protocol the fix to a network split is simple, the longest= chain win. But with the moving checkpoint I'm proposing we have a problem = if both chains began to differ more than N blocks ago, the forks are perman= ent. So we need an additional rule to ignore the moving checkpoint, a limit= of X blocks: It is not to be considered the longest chain, it is to be considered the lo= ngest chain with the most proof of work. Regards, LORD HIS EXCELLENCY JAMES HRMH ________________________________ From: bitcoin-dev-bounces@lists.linuxfoundation.org on behalf of Kenshiro [] via bitcoin-dev Sent: Friday, 2 August 2019 11:08 PM To: Ethan Heilman ; Bitcoin Dev Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Hi all, Very good points. I did some clarifications in a private conversation, the = new rule is making the moving checkpoint valid only if the difference in bl= ocks between the main chain and the new fork is smaller than X blocks, like= for example 3 days of blocks, so after a long network split everyone can f= inally follow the longest chain: With the current protocol the fix to a network split is simple, the longest= chain win. But with the moving checkpoint I'm proposing we have a problem = if both chains began to differ more than N blocks ago, the forks are perman= ent. So we need an additional rule to ignore the moving checkpoint, a limit= of X blocks: If a node sees a fork longer than his main chain, and the fork has at least= X blocks more than the main chain, then the node ignore the moving checkpo= int rule, and it follows the fork, the longest chain. So as an example, the moving checkpoint could be 24 hours of blocks, and th= e limit of X blocks, the blocks of 3 days. So we have 2 possible situations to consider: - 51% attack: the blocks older than 24 hours are protected against a histo= ry rewrite during at least 3 days, in that time developers could release an= emergency release with another mining algorithm to stop the attack. - Network split: if the network split is older than N blocks, we have 2 per= manent forks (or chains), but in 3 days (or more) the blockchain heights wi= ll differ in more than X blocks (the blocks of 3 days) because there will b= e more miners in one chain than in the other so finally the loser chain wil= l be abandoned and everyone will follow the longest chain. It could be even more conservative, like 48 hours for the moving checkpoint= and a block limit of 7 days of blocks. Regards, ________________________________ From: Ethan Heilman Sent: Friday, August 2, 2019 14:19 To: Kenshiro [] ; Bitcoin Dev Cc: Alistair Mann Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol Attack 1: I partition (i.e. eclipse) a bunch of nodes from the network this partition= contains no mining power . I then mine 145 blocks for this partition. I do= n't even need 51% of the mining power because I'm not competing with any ot= her miners. Under this rule this partition will hardfork from the network p= ermanently. Under current rules this partition will be able to rejoin the n= etwork as the least weight chain will be orphaned. Attack 2: I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I = feed it 145 blocks which fork off from the consensus chain. I have 24+24 ho= urs to mine these 145 blocks so I should be able to do this with 25% of the= current hash rate at the time the node went offline. Under your rule each = of these offline-->online nodes I attack this way will hardfork themselves = from the rest of the network. I believe a moving-checkpoint rule as describe above would make Bitcoin mor= e vulnerable to 51% attacks. A safer rule would be if a node detects a fork with both sides of the split= having length > 144 blocks, it halts and requests user intervention to de= termine which chain to follow. I don't think 144 blocks is a great number = to use here as 24 hours is very short. I suspect you could improve the secu= rity of the rule by making the number of blocks a fork most reach to halt t= he network proportional to the difference in time between the timestamp in = the block prior to the fork and the current time. I am **NOT** proposing Bi= tcoin adopt such a rule. NXT has a fundamentally different security model as it uses Proof-of-stake = rather than Proof-of-Work. On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev > wrot= e: P.S.: To be clearer, in this example I set an N value of 144 blocks, which = is approximately 24 hours. ________________________________ From: Kenshiro [] > Sent: Wednesday, July 31, 2019 16:40 To: Alistair Mann >; Bitcoin Protocol Dis= cussion > Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin protocol >>> 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_000_DB6PR10MB18326F80886EFE159176893DA6D80DB6PR10MB1832EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good point, for the moving checkpoint a number of blocks (or maybe a timest= amp) could be enough, but for the block limit of X blocks to decide if the = moving checkpoint is ignored or not, as we have to compare two chains (main= chain and fork) maybe is much better to measure the blockchain lengths as numberOfBlocks * averageBlockDifficulty, so= if a difficulty adjustment happens in that time interval, it's taken into account.

Regards

From: LORD HIS EXCELLENCY J= AMES HRMH <willtech@live.com.au>
Sent: Saturday, August 3, 2019 2:51
To: Ethan Heilman <eth3rs@gmail.com>; Bitcoin Dev <bitcoin-= dev@lists.linuxfoundation.org>; Kenshiro [] <tensiam@hotmail.com><= br> Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr= otocol
 
I have but one point to make in a brief catch-up read over.

With the current protocol the fix to a network split is simple, the long= est chain win. But with the moving checkpoint I'm proposing we have a p= roblem if both chains began to differ more than N blocks ago, the forks are= permanent. So we need an additional rule to ignore the moving checkpoint, a limit of X blocks:
 
It is not to be considered the longest chain, it is to be considered the lo= ngest chain with the most proof of work.

Regards,
LORD HIS EXCELLENCY JAMES HRMH


From: bitcoin-dev-bounces= @lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.or= g> on behalf of Kenshiro [] via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.org>
Sent: Friday, 2 August 2019 11:08 PM
To: Ethan Heilman <eth3rs@gmail.com>; Bitcoin Dev <bitcoin-= dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr= otocol
 
Hi all,

Very good points. I did some clarifications in a private conversation, the = new rule is making the moving checkpoint valid only if the difference in bl= ocks between the main chain and the new fork is smaller than X blocks, like= for example 3 days of blocks, so after a long network split everyone can finally follow the longest chain:<= /div>

With the current protocol the fix to a network split is simple, the longest= chain win. But with the moving checkpoint I'm proposing we have a problem = if both chains began to differ more than N blocks ago, the forks are perman= ent. So we need an additional rule to ignore the moving checkpoint, a limit of X blocks:

If a node sees a fork longer than his main chain, and the fork has at = least X blocks more than the main chain, then the node ignore the moving ch= eckpoint rule, and it follows the fork, the longest chain.

So as an example, the moving checkpoint could be 24 hours of blocks, a= nd the limit of X blocks, the blocks of 3 days.

So we have 2 possible situations to consider:

- 51% attack:  the blocks older than 24 hours are protected again= st a history rewrite during at least 3 days, in that time developers could = release an emergency release with another mining algorithm to stop the atta= ck.

- Network split: if the network split is older than N blocks, we have= 2 permanent forks (or chains), but in 3 days (or more) the blockchain heig= hts will differ in more than X blocks (the blocks of 3 days) because there = will be more miners in one chain than in the other so finally the loser chain will be abandoned and everyon= e will follow the longest chain.

It could be even more conservative, like 48 hours for the moving checkpoint= and a block limit of 7 days of blocks.

Regards,



From: Ethan Heilman <= ;eth3rs@gmail.com>
Sent: Friday, August 2, 2019 14:19
To: Kenshiro [] <tensiam@hotmail.com>; Bitcoin Dev <bitcoin= -dev@lists.linuxfoundation.org>
Cc: Alistair Mann <al@pectw.net>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr= otocol
 
Attack 1:
I partition (i.e. eclipse) a bunch of nodes from the network this partition= contains no mining power . I then mine 145 blocks for this partition. I do= n't even need 51% of the mining power because I'm not competing with any ot= her miners. Under this rule this partition will hardfork from the network permanently. Under current rules = this partition will be able to rejoin the network as the least weight chain= will be orphaned.

Attack 2:
I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I = feed it 145 blocks which fork off from the consensus chain. I have 24+2= 4 hours to mine these 145 blocks so I should be able to do this with 25% of= the current hash rate at the time the node went offline. Under your rule each of these offline-->online nodes= I attack this way will hardfork themselves from the rest of the network.
I believe a moving-checkpoint rule as describe above would make Bitcoin mor= e vulnerable to 51% attacks.

A safer rule would be if a node detects a fork with both sides of the split= having  length > 144 blocks, it halts and requests user interventi= on to determine which chain to follow.  I don't think 144 blocks is a = great number to use here as 24 hours is very short. I suspect you could improve the security of the rule by making the = number of blocks a fork most reach to halt the network proportional to the = difference in time between the timestamp in the block prior to the fork and= the current time. I am **NOT** proposing Bitcoin adopt such a rule.

NXT has a fundamentally different security model as it uses Proof-of-stake = rather than Proof-of-Work.

On Wed, Jul 31, 2019 at 2:37 PM= Kenshiro [] via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org> wrote:
P.S.: To be clearer, in this example I set an N value of 144 blocks, which = is approximately 24 hours.

From: Kenshiro [] <tensiam@hotmail.com>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann <al@pectw.net>; Bitcoin Protocol Discussion &l= t;bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr= otocol
 
>>> 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 D= iscussion <bitcoin-dev@lists.linuxfoundation.org&= gt;
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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--_000_DB6PR10MB18326F80886EFE159176893DA6D80DB6PR10MB1832EURP_--