path: root/9c/1022a4201394fe36e5d6acac6ebccf1e9918e9

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 10B56CAB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 12:02:33 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com
	[209.85.214.194])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9648363D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 12:02:31 +0000 (UTC)
Received: by mail-pl1-f194.google.com with SMTP id c14so11846636plo.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Jul 2019 05:02:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=RStCNnNGWK9Mo1x9+NmVsaChP6fgVpcQ3LIqFqYceOw=;
	b=Xm9r/H+BE9gPB/1FBBM0guaoykOs/LklJNZqBInpoZqVkNYOHem21PHj2t2QkvPOJI
	gHgcxvlEVe8UgQhZFLj297OmFbIZS2onKUkPh63vRPKdz18sojok1LF8J2QoCaHM0UmT
	MdeAcGouB5A5f3R9jkKHAGETkZ3mwYLAs1HCSnnVIwDeNaxYLO7sYgu1cV9adSeu71jO
	zED8fiYErRpv/KdiKMDYbx0KNY7m53P7buNDytNEw2G2c1lH+9w/8X7rn3jrtir5IL0e
	mbdY7kyPw1bWjtLQzq57iBLd8v2zMHLan0xAAFOPQA8IQp9is+Mui50qSUZr87akbpTx
	lBJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=RStCNnNGWK9Mo1x9+NmVsaChP6fgVpcQ3LIqFqYceOw=;
	b=M1XGcMpaPztMvkBIpqKQVlveMHRvoi9JQFrJsqrFS6RqZleFKE45CspoVB5VCO3jVS
	hvuFMIJNX8qT4ZX5s2+6M2Iq0UswgCdVIzKa0XqdCq0JAWpdTb1Irmo+1GYGd1X+6mY5
	U/4KjqL6JY/1KsEaA4ApBnGbnufluVXCWJSsL9FVB2TCA3vAyvdvQ6jA0/Vgyrq13FSI
	4UwyZkKmufkiO7ghcEc99yAXsM+D64mbSxJTJnClsXDN8MG2t7Hw9kRscfzgJkkFM20u
	h5msUCrOc3/+uRaVu1hMBdCP779XoncAO5KTG0iLyj37I+CC/ihUHiUoHCT/TzN9YCAy
	iqcQ==
X-Gm-Message-State: APjAAAX/Crmg/brU2Zwd0mP5s38MjQ5vk4+qhhdRWyVQ3MOlYVx3PsN6
	I3mxrHvNfCPHYbn6SAQRa30=
X-Google-Smtp-Source: APXvYqzId7WmnmqJCuo3SV3kMDDeomEa0z+08R2dO1xNkk2WGp2amaYEefoC+OEl8TzjTOwZd6e6rw==
X-Received: by 2002:a17:902:7686:: with SMTP id
	m6mr42561713pll.239.1563364951090; 
	Wed, 17 Jul 2019 05:02:31 -0700 (PDT)
Received: from ?IPv6:2601:600:a080:16bb:e097:3618:bb96:d5dc?
	([2601:600:a080:16bb:e097:3618:bb96:d5dc])
	by smtp.gmail.com with ESMTPSA id
	h70sm17966162pgc.36.2019.07.17.05.02.30
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 17 Jul 2019 05:02:30 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-EE642197-63B8-436B-A0F3-46F4B9278B6D
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
Date: Wed, 17 Jul 2019 05:02:29 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
	<DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
To: "Kenshiro []" <tensiam@hotmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, LOTS_OF_MONEY, MIME_QP_LONG_LINE,
	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, 18 Jul 2019 01:18:50 +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: Wed, 17 Jul 2019 12:02:33 -0000


--Apple-Mail-EE642197-63B8-436B-A0F3-46F4B9278B6D
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


> On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>=20
> Hi ZmnSCPxj,
>=20
> I'm based on the more evolved implementation of PoS that I know, which is P=
oS v3.0 and it's currently implemented in several coins:
>=20
> http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-=
stake-version
>=20
> As far as I know the grinding attack is and old issue that is fixed in PoS=
 v3.0.
>=20
> >>>At least the proposed `assumeutxo` requires the operator to explicitly e=
nable it, but I believe your "hardcoded checkpoints" cannot be disabled, muc=
h less disabled-by-default.
>=20
> We don't trust the developers, the source code is public and anyone can ch=
eck it. With the hardcoded checkpoints is exactly the same, they are in the s=
ource code repository and everyone can check them. The checkpoints are the e=
asiest part to check. A user doesn't have any reason to remove the checkpoin=
ts, but as with anything in the source code, they could modify it to avoid t=
he checkpoints (and become vulnerable to Long Range attacks doing it)

Bad precedent set by Bitcoin, just like retroactively hardcoding soft fork a=
ctivation checkpoints.

> >>>Under the trust-minimization requirement of Bitcoin this is simply not a=
cceptable.
> As there is no way to trust-minimally heal from a network split (and every=
 time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus a=
lgorithm.

That=E2=80=99s nonsense, one is a feature (systemic trust), the other is a b=
ug (code accident). But there is a way to minimize actual forks - try not to=
 change the consensus rules in the code you ship.

> The block explorer or other additional source of trust like a friend would=
 only be required in the extreme situation that the network is under a 51% a=
ttack, and only by the nodes that are updating blocks in that moment. Update=
d nodes are fully protected, and under normal circumstances new nodes can ju=
st follow the longest chain as always. The other extreme situation that coul=
d cause a hard fork is that the network is splitted more than N blocks, whic=
h should require some social consensus to fix it. So N should be long enough=
, like a few hours of blocks or even 1 day.

Consensus rules are the social consensus. If you have an objective way to do=
 this, write the rule.

> >>> History rewrites are not the only attack possible.
> The worst attack is a censorship attack, and a 99% staker can easily censo=
r on the creation of new blocks.
>=20
> I don't agree, history rewrite attacks are much worse than censorship beca=
use they can be used to steal funds from people.

Censorship can steal everybody=E2=80=99s money.

> In PoS staking addresses are public, so maybe it should be possible to det=
ect if some transaction in the mempool is repeatedly being ignored and what s=
taking deposit is repeatedly ignoring transactions. After some time, a hard f=
ork could burn the funds of the evil validator.

Political money.

> >>> Worse, under proof-of-stake it is often the case that stakers are awar=
ded even more coin with which they can stake.
>=20
> Sure, but in PoW the miners with more hash power earn more coins that can b=
e used to purchase more miners.

True, but this is at least limited proportionally.

> There is always the privilege of the rich guy, no matter if its PoW or PoS=
. The point is to design a protocol that don't allow the rich to destroy the=
 network.

The ability to introduce new power to the chain is the only way to evict a c=
ensor. In PoS a well capitalized individual or state can buy total control o=
ver the system forever at no ongoing cost. PoW allows any number of individu=
als to pay higher fees on censored txs and evict the censor, who must then m=
aintain the cost of subsidizing censorship.

> Let me put it in this way: NXT is a PoS coin that uses moving checkpoints w=
ith a market cap of 21 million dollars. If the current PoS protocols are so f=
lawed, how can you explain that a coin with this market cap is not being att=
acked?

The state doesn=E2=80=99t care because there is no material impact from it? I=
t hasn=E2=80=99t started attacking Bitcoin yet either.

> https://www.coingecko.com/en/coins/nxt
>=20
> Another thing is that Ethereum itself is going to PoS next year, but with a=
 different implementation that I'm proposing here.

Just another nail in the coffin.

Best,
Eric

> Regards,
>=20
> =20
> From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
> Sent: Wednesday, July 17, 2019 1:00
> To: Kenshiro \[\]; Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin=

> =20
> Good morning Kenshiro,
>=20
>=20
> Sent with ProtonMail Secure Email.
>=20
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M=
essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
>=20
> > Hi,
> >
> > After studying several Proof of Stake implementations I think it's not o=
nly an eco-friendly (and more ethical) alternative to Proof of Work, but cor=
rectly implemented could be 100% secure against all 51% history rewrite atta=
cks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements=
 are required:
>=20
> Under the trust-minimization and uncensorability requirements that Bitcoin=
 has, nothing is more efficient than proof-of-work.
> The very idea of proof-of-stake labors under the assumption that unencumbe=
red free-market payment for the consumption of energy is somehow not market-=
efficient despite the well-known phenomenon of the invisible hand, and belie=
ves that it is possible to get something for nothing.
>=20
> Please re-examine your assumptions.
>=20
> > - Hardcoded checkpoints:each Bitcoin Core release (each few months) shou=
ld 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 ch=
eckpoint, and prevents any Long-Range attack.
>=20
> While this is a developer list and made up of developers who would be quit=
e incentivized to agree to such a setup, note that this effectively trusts t=
he developers.
> At least the proposed `assumeutxo` requires the operator to explicitly ena=
ble it, but I believe your "hardcoded checkpoints" cannot be disabled, much l=
ess disabled-by-default.
>=20
> > This extra rule could be connecting to a block explorer to download the h=
ash of the current block height, or ask some trusted source like a friend an=
d enter the hash manually. After being fully updated, the user can always ch=
eck that he is in the correct chain checking with a block explorer.
>=20
> Under the trust-minimization requirement of Bitcoin this is simply not acc=
eptable.
> As there is no way to trust-minimally heal from a network split (and every=
 time a node is shut down, that is indistinguishable from a network split th=
at isolates that particular node), this is not a trust-minimizing consensus a=
lgorithm.
>=20
> >
> > Someone could have 99% of the coins and still would be unable to use the=
 coins to do any history rewrite attack. The attacker could only slow down t=
he network not creating his blocks, or censor transactions in his blocks.
>=20
> History rewrites are not the only attack possible.
> The worst attack is a censorship attack, and a 99% staker can easily censo=
r on the creation of new blocks.
>=20
> Censorship attacks cannot be prevented except by ensuring that no single e=
ntity can claim 51% control of new block creation.
> By ensuring this, we can ensure that at least some other entities are unli=
kely to keep a transaction out of the blockchain, and in particular that no e=
ntity can make a short-ranged history rewrite if a censored transaction *doe=
s* get into the blockchain from the efforts of another block producer.
>=20
> This is trivial under proof-of-work, and is the cost we accept in order to=
 achieve uncensorability, since it is non-trivial to acquire energy.
> Under proof-of-stake it is difficult to impossible to determine if some si=
ngle entity controls >51% of stakeable coins, and thus has no way to protect=
 against censorship attack.
> Worse, under proof-of-stake it is often the case that stakers are awarded e=
ven more coin with which they can stake.
>=20
> Depending on the PoS implementation, stake-grinding may allow a 49% staker=
 to achieve 51% and thereby the ability to censor transactions.
>=20
>=20
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-EE642197-63B8-436B-A0F3-46F4B9278B6D
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"></div><div dir=3D"ltr"><br=
></div><div dir=3D"ltr">On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><blockquote type=3D"ci=
te"><div dir=3D"ltr">

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-j=
p">



<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<span>Hi ZmnSCPxj,<br>
</span>
<div><br>
</div>
<div>I'm based on the more evolved implementation of PoS that I know, which i=
s PoS v3.0 and it's currently implemented in several coins:<br>
</div>
<div><br>
</div>
<div><a href=3D"http://earlz.net/view/2017/07/27/1904/the-missing-explanatio=
n-of-proof-of-stake-version">http://earlz.net/view/2017/07/27/1904/the-missi=
ng-explanation-of-proof-of-stake-version</a><br>
</div>
<div><br>
</div>
<div>As far as I know the grinding attack is and old issue that is fixed in P=
oS v3.0.<br>
</div>
<div><br>
</div>
<div>&gt;&gt;&gt;At least the proposed `assumeutxo` requires the operator to=
 explicitly enable it, but I believe your "hardcoded checkpoints" cannot be d=
isabled, much less disabled-by-default.<br>
</div>
<div><br>
</div>
<div>We don't trust the developers, the source code is public and anyone can=
 check it. With the hardcoded checkpoints is exactly the same, they are in t=
he source code repository and everyone can check them. The checkpoints are t=
he easiest part to check. A user
 doesn't have any reason to remove the checkpoints, but as with anything in t=
he source code, they could modify it to avoid the checkpoints (and become vu=
lnerable to Long Range attacks doing it)</div></div></div></blockquote><div>=
<br></div><div>Bad precedent set by Bitcoin, just like retroactively hardcod=
ing soft fork activation checkpoints.</div><br><blockquote type=3D"cite"><di=
v dir=3D"ltr"><div style=3D"font-family: Calibri, Helvetica, sans-serif; fon=
t-size: 12pt; color: rgb(0, 0, 0);">
<div>&gt;&gt;&gt;Under the trust-minimization requirement of Bitcoin this is=
 simply not acceptable.<br>
</div>
<div>As there is no way to trust-minimally heal from a network split (and ev=
ery time a node is shut down, that is indistinguishable from a network split=
 that isolates that particular node), this is not a trust-minimizing consens=
us algorithm.</div></div></div></blockquote><div><br></div><div>That=E2=80=99=
s nonsense, one is a feature (systemic trust), the other is a bug (code acci=
dent). But there is a way to minimize actual forks - try not to change the c=
onsensus rules in the code you ship.</div><br><blockquote type=3D"cite"><div=
 dir=3D"ltr"><div style=3D"font-family: Calibri, Helvetica, sans-serif; font=
-size: 12pt; color: rgb(0, 0, 0);">
<div>The block explorer or other additional source of trust like a friend wo=
uld only be required in the extreme situation that the network is under a 51=
% attack, and only by the nodes that are updating blocks in that moment. Upd=
ated nodes are fully protected,
 and under normal circumstances new nodes can just follow the longest chain a=
s always. The other extreme situation that could cause a hard fork is that t=
he network is splitted more than N blocks, which should require some social c=
onsensus to fix it. So N should
 be long enough, like a few hours of blocks or even 1 day.</div></div></div>=
</blockquote><div><br></div><div>Consensus rules are the social consensus. I=
f you have an objective way to do this, write the rule.</div><br><blockquote=
 type=3D"cite"><div dir=3D"ltr"><div style=3D"font-family: Calibri, Helvetic=
a, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div>&gt;&gt;&gt; History rewrites are not the only attack possible.<br>
</div>
<div>The worst attack is a censorship attack, and a 99% staker can easily ce=
nsor on the creation of new blocks.<br>
</div>
<div><br>
</div>
<div>I don't agree, history rewrite attacks are much worse than censorship b=
ecause they can be used to steal funds from people.</div></div></div></block=
quote><div><br></div><div>Censorship can steal everybody=E2=80=99s money.</d=
iv><br><blockquote type=3D"cite"><div dir=3D"ltr"><div style=3D"font-family:=
 Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><div=
>In PoS staking addresses are public, so maybe it should be possible to dete=
ct if some transaction in the mempool is repeatedly&nbsp;being
 ignored and what staking deposit is repeatedly ignoring transactions. After=
 some time, a hard fork could burn the funds of the evil validator.</div></d=
iv></div></blockquote><div><br></div><div>Political money.</div><br><blockqu=
ote type=3D"cite"><div dir=3D"ltr"><div style=3D"font-family: Calibri, Helve=
tica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<div>&gt;&gt;&gt; Worse, under proof-of-stake it is often the case that stak=
ers are awarded even more coin with which they can stake.<br>
</div>
<div><br>
</div>
<div>Sure, but in PoW the miners with more hash power earn more coins that c=
an be used to purchase more miners.</div></div></div></blockquote><div><br><=
/div><div>True, but this is at least limited proportionally.</div><br><block=
quote type=3D"cite"><div dir=3D"ltr"><div style=3D"font-family: Calibri, Hel=
vetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><div>There is alw=
ays the privilege of the rich guy, no matter if its PoW or PoS. The point is=
 to design a protocol that don't allow the rich to destroy
 the network.</div></div></div></blockquote><div><br></div><div>The ability t=
o introduce new power to the chain is the only way to evict a censor. In PoS=
 a well capitalized individual or state can buy total control over the syste=
m forever at no ongoing cost. PoW allows any number of individuals to pay hi=
gher fees on censored txs and evict the censor, who must then maintain the c=
ost of subsidizing censorship.</div><br><blockquote type=3D"cite"><div dir=3D=
"ltr"><div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 1=
2pt; color: rgb(0, 0, 0);">

<div>Let me put it in this way: NXT is a PoS coin that uses moving checkpoin=
ts with a market cap of 21 million dollars. If the current PoS protocols are=
 so flawed, how can you explain that a coin with this market cap is not bein=
g attacked?</div></div></div></blockquote><div><br></div><div>The state does=
n=E2=80=99t care because there is no material impact from it? It hasn=E2=80=99=
t started attacking Bitcoin yet either.</div><br><blockquote type=3D"cite"><=
div dir=3D"ltr"><div style=3D"font-family: Calibri, Helvetica, sans-serif; f=
ont-size: 12pt; color: rgb(0, 0, 0);">
<div><a href=3D"https://www.coingecko.com/en/coins/nxt">https://www.coingeck=
o.com/en/coins/nxt</a><br>
</div>
<div><br>
</div>
<div>Another thing is that Ethereum itself is going to PoS next year, but wi=
th a different implementation that I'm proposing here.</div></div></div></bl=
ockquote><div><br></div><div>Just another nail in the coffin.</div><div><br>=
</div><div>Best,</div><div>Eric</div><br><blockquote type=3D"cite"><div dir=3D=
"ltr"><div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 1=
2pt; color: rgb(0, 0, 0);">
<span>Regards,</span><br>
</div>
<div>
<div id=3D"appendonsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; colo=
r: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" col=
or=3D"#000000" style=3D"font-size:11pt"><b>From:</b> ZmnSCPxj &lt;<a href=3D=
"mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>&gt;<br>
<b>Sent:</b> Wednesday, July 17, 2019 1:00<br>
<b>To:</b> Kenshiro \[\]; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bi=
tcoin</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt">=

<div class=3D"PlainText">Good morning Kenshiro,<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Mes=
sage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br>
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfou=
ndation.org</a>&gt; wrote:<br>
<br>
&gt; Hi,<br>
&gt;<br>
&gt; After studying several Proof of Stake implementations I think it's not o=
nly an eco-friendly (and more ethical) alternative to Proof of Work, but cor=
rectly implemented could be 100% secure against all 51% history rewrite atta=
cks. Over a "standard" PoS protocol
 like PoS v3.0, only 2 extra improvements are required:<br>
<br>
Under the trust-minimization and uncensorability requirements that Bitcoin h=
as, nothing is more efficient than proof-of-work.<br>
The very idea of proof-of-stake labors under the assumption that unencumbere=
d free-market payment for the consumption of energy is somehow not market-ef=
ficient despite the well-known phenomenon of the invisible hand, and believe=
s that it is possible to get
 something for nothing.<br>
<br>
Please re-examine your assumptions.<br>
<br>
&gt; - Hardcoded checkpoints:each Bitcoin Core release (each few months) sho=
uld include a hardcoded checkpoint with the hash of the current block height=
 in that moment. This simple measure protects the blockchain up to the last c=
heckpoint, and prevents any Long-Range
 attack.<br>
<br>
While this is a developer list and made up of developers who would be quite i=
ncentivized to agree to such a setup, note that this effectively trusts the d=
evelopers.<br>
At least the proposed `assumeutxo` requires the operator to explicitly enabl=
e it, but I believe your "hardcoded checkpoints" cannot be disabled, much le=
ss disabled-by-default.<br>
<br>
&gt; 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 a=
nd enter the hash manually. After being fully updated, the user can always c=
heck that he is in the correct
 chain checking with a block explorer.<br>
<br>
Under the trust-minimization requirement of Bitcoin this is simply not accep=
table.<br>
As there is no way to trust-minimally heal from a network split (and every t=
ime a node is shut down, that is indistinguishable from a network split that=
 isolates that particular node), this is not a trust-minimizing consensus al=
gorithm.<br>
<br>
&gt;<br>
&gt; Someone could have 99% of the coins and still would be unable to use th=
e coins to do any history rewrite attack. The attacker could only slow down t=
he network not creating his blocks, or censor transactions in his blocks.<br=
>
<br>
History rewrites are not the only attack possible.<br>
The worst attack is a censorship attack, and a 99% staker can easily censor o=
n the creation of new blocks.<br>
<br>
Censorship attacks cannot be prevented except by ensuring that no single ent=
ity can claim 51% control of new block creation.<br>
By ensuring this, we can ensure that at least some other entities are unlike=
ly to keep a transaction out of the blockchain, and in particular that no en=
tity can make a short-ranged history rewrite if a censored transaction *does=
* get into the blockchain from
 the efforts of another block producer.<br>
<br>
This is trivial under proof-of-work, and is the cost we accept in order to a=
chieve uncensorability, since it is non-trivial to acquire energy.<br>
Under proof-of-stake it is difficult to impossible to determine if some sing=
le entity controls &gt;51% of stakeable coins, and thus has no way to protec=
t against censorship attack.<br>
Worse, under proof-of-stake it is often the case that stakers are awarded ev=
en more coin with which they can stake.<br>
<br>
Depending on the PoS implementation, stake-grinding may allow a 49% staker t=
o achieve 51% and thereby the ability to censor transactions.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</div>
</span></font></div>
</div>


</div></blockquote><blockquote type=3D"cite"><div dir=3D"ltr"><span>________=
_______________________________________</span><br><span>bitcoin-dev mailing l=
ist</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href=3D"https:=
//lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquot=
e></body></html>=

--Apple-Mail-EE642197-63B8-436B-A0F3-46F4B9278B6D--