path: root/c7/8f6c7a2c5f62028778ee94ca2e83cab6eb9c1d

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 C52D61AF5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 []" <tensiam@hotmail.com>
To: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>, Ethan Heilman
	<eth3rs@gmail.com>, Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: <DB6PR10MB18326F80886EFE159176893DA6D80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB1832329BC8D151DC18F1E6CEA6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<28454621.Lge63Ifvux@dprfs-d5766>
	<DB6PR10MB1832F1E966CD83BC662985BDA6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<DB6PR10MB183271245AAE84FB9AC96474A6DF0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<CAEM=y+UCdW2__nmQhWuL2FYvL6WKdBsF31WDFZUSdXPvgM2bvg@mail.gmail.com>,
	<DB6PR10MB1832110D67FB7FBD1AF5E3EDA6D90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<PS2P216MB0179F9419B116F333EBF10799DD80@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PS2P216MB0179F9419B116F333EBF10799DD80@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
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 <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: 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 <willtech@live.com.au>
Sent: Saturday, August 3, 2019 2:51
To: Ethan Heilman <eth3rs@gmail.com>; Bitcoin Dev <bitcoin-dev@lists.linuxf=
oundation.org>; Kenshiro [] <tensiam@hotmail.com>
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
<https://earn.com/willtech>


________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Kenshiro [] via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org>
Sent: Friday, 2 August 2019 11:08 PM
To: Ethan Heilman <eth3rs@gmail.com>; Bitcoin Dev <bitcoin-dev@lists.linuxf=
oundation.org>
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 <eth3rs@gmail.com>
Sent: Friday, August 2, 2019 14:19
To: Kenshiro [] <tensiam@hotmail.com>; Bitcoin Dev <bitcoin-dev@lists.linux=
foundation.org>
Cc: Alistair Mann <al@pectw.net>
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 <bitcoin-dev@li=
sts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> 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 [] <tensiam@hotmail.com<mailto:tensiam@hotmail.com>>
Sent: Wednesday, July 31, 2019 16:40
To: Alistair Mann <al@pectw.net<mailto:al@pectw.net>>; Bitcoin Protocol Dis=
cussion <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.lin=
uxfoundation.org>>
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 <al@pectw.net<mailto:al@pectw.net>>
Sent: Wednesday, July 31, 2019 15:59
To: Kenshiro [] <tensiam@hotmail.com<mailto:tensiam@hotmail.com>>; Bitcoin =
Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-d=
ev@lists.linuxfoundation.org>>
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<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--_000_DB6PR10MB18326F80886EFE159176893DA6D80DB6PR10MB1832EURP_
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);">
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<span style=3D"font-family: Calibri, H=
elvetica, sans-serif; background-color: rgb(255, 255, 255); display: inline=
 !important"><span>&nbsp;</span>numberOfBlocks * averageBlockDifficulty, so=
 if a difficulty adjustment happens in
 that time interval, it's taken into account.</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);">
Regards</div>
<div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<span></span><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> LORD HIS EXCELLENCY J=
AMES HRMH &lt;willtech@live.com.au&gt;<br>
<b>Sent:</b> Saturday, August 3, 2019 2:51<br>
<b>To:</b> Ethan Heilman &lt;eth3rs@gmail.com&gt;; Bitcoin Dev &lt;bitcoin-=
dev@lists.linuxfoundation.org&gt;; Kenshiro [] &lt;tensiam@hotmail.com&gt;<=
br>
<b>Subject:</b> Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr=
otocol</font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
I have but one point to make in a brief catch-up read over.<br>
</div>
<blockquote style=3D"margin-top:0px; margin-bottom:0px">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<b>With the current protocol the fix to a network split is simple, the long=
est chain win.</b> 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:<br>
</div>
</blockquote>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
&nbsp;<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
It is not to be considered the longest chain, it is to be considered the lo=
ngest chain
<u>with the most proof of work</u>.<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div id=3D"x_Signature">
<div></div>
<div></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; fon=
t-size:12pt">
Regards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif,serif,EmojiFont; fon=
t-size:12pt">
LORD HIS EXCELLENCY JAMES HRMH</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div><a href=3D"https://earn.com/willtech" title=3D"https://earn.com/willte=
ch"></a></div>
<div><br>
</div>
</div>
<div>
<div id=3D"x_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"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> bitcoin-dev-bounces=
@lists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.or=
g&gt; on behalf of Kenshiro [] via bitcoin-dev &lt;bitcoin-dev@lists.linuxf=
oundation.org&gt;<br>
<b>Sent:</b> Friday, 2 August 2019 11:08 PM<br>
<b>To:</b> Ethan Heilman &lt;eth3rs@gmail.com&gt;; Bitcoin Dev &lt;bitcoin-=
dev@lists.linuxfoundation.org&gt;<br>
<b>Subject:</b> Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr=
otocol</font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Hi all,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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:<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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.
<br>
</div>
<div><br>
</div>
<div>So we have 2 possible situations to consider:<br>
</div>
<div><br>
</div>
<div>- 51% attack: &nbsp;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.<br>
</div>
<div><br>
</div>
<span>- 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.</span><br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<span><br>
</span></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
It could be even more conservative, like 48 hours for the moving checkpoint=
 and a block limit of 7 days of blocks.</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Regards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div>
<div id=3D"x_x_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"x_x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif=
" color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Ethan Heilman &lt=
;eth3rs@gmail.com&gt;<br>
<b>Sent:</b> Friday, August 2, 2019 14:19<br>
<b>To:</b> Kenshiro [] &lt;tensiam@hotmail.com&gt;; Bitcoin Dev &lt;bitcoin=
-dev@lists.linuxfoundation.org&gt;<br>
<b>Cc:</b> Alistair Mann &lt;al@pectw.net&gt;<br>
<b>Subject:</b> Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr=
otocol</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"auto">
<div dir=3D"ltr">Attack 1:<br>
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.<br>
<br>
Attack 2:<br>
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&#43;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--&gt;online nodes=
 I attack this way will hardfork themselves from the rest of the network.<b=
r>
<br>
I believe a moving-checkpoint rule as describe above would make Bitcoin mor=
e vulnerable to 51% attacks.<br>
<br>
A safer rule would be if a node detects a fork with both sides of the split=
 having&nbsp; length &gt; 144 blocks, it halts and requests user interventi=
on to determine which chain to follow.&nbsp; 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.<br>
<br>
NXT has a fundamentally different security model as it uses Proof-of-stake =
rather than Proof-of-Work.</div>
</div>
<br>
<div class=3D"x_x_x_gmail_quote">
<div dir=3D"ltr" class=3D"x_x_x_gmail_attr">On Wed, Jul 31, 2019 at 2:37 PM=
 Kenshiro [] via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br>
</div>
<blockquote class=3D"x_x_x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; =
border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
P.S.: To be clearer, in this example I set an N value of 144 blocks, which =
is approximately 24 hours.</div>
<div>
<div id=3D"x_x_x_m_-1010116091299868493gmail-m_6888503219858923550appendons=
end"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr style=3D"display:inline-block; width:98%">
<div id=3D"x_x_x_m_-1010116091299868493gmail-m_6888503219858923550divRplyFw=
dMsg" dir=3D"ltr">
<font face=3D"Calibri, sans-serif" color=3D"#000000" style=3D"font-size:11p=
t"><b>From:</b> Kenshiro [] &lt;<a href=3D"mailto:tensiam@hotmail.com" targ=
et=3D"_blank" rel=3D"noreferrer">tensiam@hotmail.com</a>&gt;<br>
<b>Sent:</b> Wednesday, July 31, 2019 16:40<br>
<b>To:</b> Alistair Mann &lt;<a href=3D"mailto:al@pectw.net" target=3D"_bla=
nk" rel=3D"noreferrer">al@pectw.net</a>&gt;; Bitcoin Protocol Discussion &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
<b>Subject:</b> Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin pr=
otocol</font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
&gt;&gt;&gt;&nbsp;<span>How would a (potentially, state-sponsored) netsplit=
 lasting longer than N be
<br>
</span><span>handled? &nbsp;</span></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<span><br>
</span></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<span>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.&nbsp;</span></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<span><br>
</span></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<span>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</span>=
odes from one branch could delete their local history so they would join th=
e other branch.</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Regards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div>
<div id=3D"x_x_x_m_-1010116091299868493gmail-m_6888503219858923550x_appendo=
nsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr style=3D"display:inline-block; width:98%">
<div id=3D"x_x_x_m_-1010116091299868493gmail-m_6888503219858923550x_divRply=
FwdMsg" dir=3D"ltr">
<font face=3D"Calibri, sans-serif" color=3D"#000000" style=3D"font-size:11p=
t"><b>From:</b> Alistair Mann &lt;<a href=3D"mailto:al@pectw.net" target=3D=
"_blank" rel=3D"noreferrer">al@pectw.net</a>&gt;<br>
<b>Sent:</b> Wednesday, July 31, 2019 15:59<br>
<b>To:</b> Kenshiro [] &lt;<a href=3D"mailto:tensiam@hotmail.com" target=3D=
"_blank" rel=3D"noreferrer">tensiam@hotmail.com</a>&gt;; Bitcoin Protocol D=
iscussion &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&=
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"x_x_x_m_-1010116091299868493gmail-m_6888503219858923550x_Body=
Fragment">
<font size=3D"2"><span style=3D"font-size:11pt">
<div class=3D"x_x_x_m_-1010116091299868493gmail-m_6888503219858923550x_Plai=
nText">On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote:=
<br>
<br>
&gt; I would like to propose that a &quot;moving checkpoint&quot; is added =
to the Bitcoin<br>
&gt; protocol. It's a very simple rule already implemented in NXT coin:<br>
&gt; <br>
&gt; - A node will ignore any new block under nodeBlockHeight - N, so the<b=
r>
&gt; blockchain becomes truly immutable after N blocks, even during a 51% a=
ttack<br>
&gt; which thanks to the moving checkpoint can't rewrite history older than=
 the<br>
&gt; last N blocks.<br>
<br>
How would a (potentially, state-sponsored) netsplit lasting longer than N b=
e <br>
handled?&nbsp; <br>
-- <br>
Alistair Mann<br>
<br>
</div>
</span></font></div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_DB6PR10MB18326F80886EFE159176893DA6D80DB6PR10MB1832EURP_--