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
Content-Type: multipart/alternative;
	boundary="_000_DB6PR10MB1832679F3A195358D234111CA6DE0DB6PR10MB1832EURP_"
MIME-Version: 1.0
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_--