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 10B56CAB for ; 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 ; Wed, 17 Jul 2019 12:02:31 +0000 (UTC) Received: by mail-pl1-f194.google.com with SMTP id c14so11846636plo.0 for ; 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 X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Wed, 17 Jul 2019 05:02:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: <207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org> References: To: "Kenshiro []" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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 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
On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-d= ev <bitcoin-dev@= lists.linuxfoundation.org> wrote:

Hi ZmnSCPxj,

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:


As far as I know the grinding attack is and old issue that is fixed in P= oS v3.0.

>>>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.

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)
=
Bad precedent set by Bitcoin, just like retroactively hardcod= ing soft fork activation checkpoints.

>>>Under the trust-minimization requirement of Bitcoin this is= simply not acceptable.
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.

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.

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.
=

Consensus rules are the social consensus. I= f 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 ce= nsor on the creation of new blocks.

I don't agree, history rewrite attacks are much worse than censorship b= ecause 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 dete= ct if some transaction in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. After= some time, a hard fork could burn the funds of the evil validator.

Political money.

>>> Worse, under proof-of-stake it is often the case that stak= ers are awarded even more coin with which they can stake.

Sure, but in PoW the miners with more hash power earn more coins that c= an be used to purchase more miners.

<= /div>
True, but this is at least limited proportionally.

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.

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.

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?

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 dir=3D"ltr">

Another thing is that Ethereum itself is going to PoS next year, but wi= th a different implementation that I'm proposing here.

Just another nail in the coffin.

=
Best,
Eric

Regards,

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 Bi= tcoin
 
=
Good morning Kenshiro,


Sent with ProtonMail Secure Email.

=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
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.org> wrote:

> 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:

Under the trust-minimization and uncensorability requirements that Bitcoin h= as, nothing is more efficient than proof-of-work.
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.

Please re-examine your assumptions.

> - 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.

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.
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.

> 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.

Under the trust-minimization requirement of Bitcoin this is simply not accep= table.
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.

>
> 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.
History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily censor o= n the creation of new blocks.

Censorship attacks cannot be prevented except by ensuring that no single ent= ity can claim 51% control of new block creation.
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.

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.
Under proof-of-stake it is difficult to impossible to determine if some sing= le entity controls >51% of stakeable coins, and thus has no way to protec= t against censorship attack.
Worse, under proof-of-stake it is often the case that stakers are awarded ev= en more coin with which they can stake.

Depending on the PoS implementation, stake-grinding may allow a 49% staker t= o achieve 51% and thereby the ability to censor transactions.


Regards,
ZmnSCPxj
________= _______________________________________
bitcoin-dev mailing l= ist
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-EE642197-63B8-436B-A0F3-46F4B9278B6D--