From: "Kenshiro []" <tensiam@hotmail.com>
To: Oscar Lafarga <otech47@gmail.com>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabNvC2AgAAIwng=
Date: Tue, 16 Jul 2019 21:28:01 +0000
Message-ID: <DB6PR10MB1832257D676DDA7B4F55E658A6CE0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>
In-Reply-To: <CAO7Y_eWDcFHWQMSL3h4Nz1a4FVsMq04YsGph5RR6khWzzdAyOg@mail.gmail.com>
Accept-Language: en-US, es-ES
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a3b074d-e5cd-4cec-3fbd-08d70a347b17
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 21:28:01.4883 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT239
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, 17 Jul 2019 07:52:04 +0000
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
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: Tue, 16 Jul 2019 21:28:05 -0000

--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Oscar,

Thank you for your answer. Just to clarify my proposal:

1 - It's a full change to Proof of Stake protocol to avoid the energy waste=
 and to prevent a 51% history rewrite attack, even if the attacker has 99% =
of coins.

2 - The hardcoded checkpoints could be set by each bitcoin node client, not=
 only Bitcoin Core. No matter if the checkpoints are different, only that t=
hey are frequent. They are there to prevent Long Range attacks. Checkpoints=
 are public just like the rest of the software, they don't require any trus=
t. A bad checkpoint would be detected by the community.

3 - There are several PoS coins working just now and as far as I know they =
don't have any problem. NXT coin implements the moving checkpoint system an=
d others the hardcoded checkpoints.

4 - In any given block, only one staker gets the authorization to create th=
at block, so other stakers can't spam the network with many different block=
s as they are illegal.

5 - The block explorer is only required during a 51% attack, and only for n=
odes that are updating blocks during the attack. Updated nodes are protecte=
d thanks to the moving checkpoints.

Regards,

________________________________
From: Oscar Lafarga <otech47@gmail.com>
Sent: Tuesday, July 16, 2019 22:35
To: Kenshiro []; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

Hi Kenshiro,

I don't think your proposal would require any changes to the Bitcoin Core i=
mplementation. This system you describe seems like it would operate as an i=
ndependent addition, rather than an alternative to the Proof of Work consen=
sus code that runs within Bitcoin now. It introduces security risk in the s=
election of block explorer and to the Bitcoin Core release dispatch system,=
 reducing the trustlessness of the current network. Also, without the const=
raints that PoW places on block creation, you increase the vector space for=
 attacks since it is trivial to spam blocks to node on the network (see Syb=
il attack<https://en.wikipedia.org/wiki/Sybil_attack#>).

I believe many other software projects have tried similar checkpointing sch=
emes that have resulted in hard forks or overall weakened consensus. I have=
n't dug too deeply, but I'm not aware of any cases where these schemes acco=
mplish anything useful to improve the bitcoin network.

Best,

On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrot=
e:

Hi,


After studying several Proof of Stake implementations I think it's not only=
 an eco-friendly (and more ethical) alternative to Proof of Work, but corre=
ctly implemented could be 100% secure against all 51% history rewrite attac=
ks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements=
 are required:


- Hardcoded checkpoints: each Bitcoin Core release (each few months) should=
 include a hardcoded checkpoint with the hash of the current block height i=
n that moment. This simple measure protects the blockchain up to the last c=
heckpoint, and prevents any Long-Range attack.


- Moving checkpoints: the nodes only allow chain reorgs not deeper than N b=
locks. If N is 10 blocks, then the nodes ignore any hard fork starting at a=
ny block under nodeBlockHeight - N. This fully protects nodes that are onli=
ne and updated. Nodes that are not fully updated need some extra rule to be=
 protected between the last hardcoded checkpoint and the current blockchain=
 height. This extra rule could be connecting to a block explorer to downloa=
d the hash of the current block height, or ask some trusted source like a f=
riend and enter the hash manually. After being fully updated, the user can =
always check that he is in the correct chain checking with a block explorer=
.


Someone could have 99% of the coins and still would be unable to use the co=
ins to do any history rewrite attack. The attacker could only slow down the=
 network not creating his blocks, or censor transactions in his blocks.


What do you think? :)


Regards

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--
Oscar Lafarga
https://www.setlife.network
<https://www.setdev.io/>

--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_
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);">
Hi Oscar,</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);">
Thank you for your answer. Just to clarify my proposal:</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);">
1 - It's a full change to Proof of Stake protocol to avoid the energy waste=
 and to prevent a 51% history rewrite attack, even if the attacker has 99% =
of coins.</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);">
2 - The hardcoded checkpoints could be set by each bitcoin node client, not=
 only Bitcoin Core. No matter if the checkpoints are different, only that t=
hey are frequent. They are there to prevent Long Range attacks. Checkpoints=
 are public just like the rest of
 the software, they don't require any trust. A bad checkpoint would be dete=
cted by the community.</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);">
3 - There are several PoS coins working just now and as far as I know they =
don't have any problem. NXT coin implements the moving checkpoint system an=
d others the hardcoded checkpoints.&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);">
4 - In any given block, only one staker gets the authorization to create th=
at block, so other stakers can't spam the network with many different block=
s as they are illegal.&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);">
5 - The block explorer is only required during a 51% attack, and only for n=
odes that are updating blocks during the attack. Updated nodes are protecte=
d thanks to the moving checkpoints.</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 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> Oscar Lafarga &lt;ote=
ch47@gmail.com&gt;<br>
<b>Sent:</b> Tuesday, July 16, 2019 22:35<br>
<b>To:</b> Kenshiro []; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Secure Proof Of Stake implementation on B=
itcoin</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">Hi Kenshiro,<br>
<br>
I don't think your proposal would require any changes to the Bitcoin Core i=
mplementation. This system you describe seems like it would operate as an i=
ndependent addition, rather than an alternative to the Proof of Work consen=
sus code that runs within Bitcoin
 now. It introduces security risk in the selection of block explorer and to=
 the Bitcoin Core release dispatch system, reducing the trustlessness of th=
e current network. Also, without the constraints that PoW places on block c=
reation, you increase the vector
 space for attacks since it is trivial to spam blocks to node on the networ=
k (see
<a href=3D"https://en.wikipedia.org/wiki/Sybil_attack#">Sybil attack</a>).<=
br>
<br>
I believe many other software projects have tried similar checkpointing sch=
emes that have resulted in hard forks or overall weakened consensus. I have=
n't dug too deeply, but I'm not aware of any cases where these schemes acco=
mplish anything useful to improve
 the bitcoin network.<br>
<br>
Best,</div>
<br>
<div class=3D"x_gmail_quote">
<div dir=3D"ltr" class=3D"x_gmail_attr">On Tue, Jul 16, 2019 at 5:33 AM Ken=
shiro [] via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-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)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<p style=3D"margin:0px; padding:0px 0px 0.25em; font-size:14px; font-family=
:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(255,255,255)">
Hi,</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
After studying several Proof of Stake implementations I think it's not only=
 an eco-friendly (and more ethical) alternative to Proof of Work, but corre=
ctly implemented could be 100% secure against all 51% history rewrite attac=
ks. Over a &quot;standard&quot; PoS protocol
 like PoS v3.0, only 2 extra improvements are required:</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<span style=3D"margin:0px">- Hardcoded checkpoints:</span><span>&nbsp;</spa=
n>each Bitcoin Core release (each few months) should include a hardcoded ch=
eckpoint with the hash of the current block height in that moment. This sim=
ple measure protects the blockchain up
 to the last checkpoint, and prevents any Long-Range attack.</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<span style=3D"margin:0px">- Moving checkpoints: the nodes only allow chain=
 reorgs not deeper than N blocks. If N is 10 blocks, then the nodes ignore =
any hard fork starting at any block under nodeBlockHeight - N. This fully p=
rotects nodes that are online and
 updated. Nodes that are not fully updated need some extra rule to be prote=
cted between the last hardcoded checkpoint and the current blockchain heigh=
t. This extra rule could be connecting to a block explorer to download the =
hash of the current block height,
 or ask some trusted source like a friend and enter the hash manually. Afte=
r being fully updated, the user can always check that he is in the correct =
chain checking with a block explorer.</span></p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<span style=3D"color:rgb(26,26,27); font-family:&quot;Noto Sans&quot;,Arial=
,sans-serif; font-size:14px"><br>
</span></p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<span style=3D"color:rgb(26,26,27); font-family:&quot;Noto Sans&quot;,Arial=
,sans-serif; font-size:14px">Someone could have 99% of the coins and still =
would be unable to use the coins to do any history rewrite attack. The atta=
cker could only slow down the network not creating
 his blocks, or censor transactions in his blocks.</span><br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px; font-size:14px; font-family:&qu=
ot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-color:=
rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=
:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(255,255,255)">
What do you think? :)</p>
<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=
:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(255,255,255)">
<br>
</p>
<p style=3D"margin:0px; padding:0.25em 0px 0px; font-size:14px; font-family=
:&quot;Noto Sans&quot;,Arial,sans-serif; color:rgb(26,26,27); background-co=
lor:rgb(255,255,255)">
Regards</p>
<br>
</div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
<br clear=3D"all">
<div><br>
</div>
-- <br>
<div dir=3D"ltr" class=3D"x_gmail_signature">
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">
<div>
<div dir=3D"ltr">
<div dir=3D"ltr">
<div dir=3D"ltr"><span style=3D"font-size:12.8px">Oscar Lafarga</span>
<div style=3D"font-size:12.8px"><a href=3D"https://www.setdev.io/" target=
=3D"_blank">https://www.setlife.network<br>
</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_--