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 D955DCD3 for ; Wed, 17 Jul 2019 10:10:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-oln040092069108.outbound.protection.outlook.com [40.92.69.108]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 44A3071C for ; Wed, 17 Jul 2019 10:10:26 +0000 (UTC) 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=9iw7I4G+kdQHv+Y3vNzKDMxc42AbfZs/YU1+nOooYaU=; b=kRygxrzRjoLC98UZ+5Nqr+tkhWnReW2aMcPyO0YIi31I9eFjWb4WnShqV2+f6CPsPycrQPYvLgeO591HksRdaZh+9sk95U1EC404/zchTtZv9weL9RXeitAhb7jZTjKx2wsrtu/Bp9j7ue0suakboGtgvwiP7/7uFSzbfrASNxCU8SuL1Fg9dh4QTK4XP7nKdjsC4UFiB63IuKI4ZLd5xJ9vCrjLtcbSV8p6k1wP40QmhLS6u28Q7NGRoNIzLIcGM1Pmb1XUkJrxTb63jqBeTOyMcsm5neIkcTghYs1SkOX0pkOob3UeErh6QW9TMnyfYN67TDNMMNSWEq4lWUaMEA== Received: from VE1EUR02FT053.eop-EUR02.prod.protection.outlook.com (10.152.12.52) by VE1EUR02HT040.eop-EUR02.prod.protection.outlook.com (10.152.13.247) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19; Wed, 17 Jul 2019 10:10:23 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.12.56) by VE1EUR02FT053.mail.protection.outlook.com (10.152.13.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19 via Frontend Transport; Wed, 17 Jul 2019 10:10:23 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5ee:488e:37fb:4be5]) by DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5ee:488e:37fb:4be5%4]) with mapi id 15.20.2073.012; Wed, 17 Jul 2019 10:10:23 +0000 From: "Kenshiro []" To: Bitcoin Protocol Discussion , ZmnSCPxj Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabN5JoAgAC5YAg= Date: Wed, 17 Jul 2019 10:10:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:7FC67997B5D5839612AEADEE9ED386AB9659C9ABBD6565BC2AC82C2A691F2F82; UpperCasedChecksum:61448249A0A2C5935749066CA2B4C4CBD126155A98FB828261926926897CE67F; SizeAsReceived:6991; Count:42 x-tmn: [9NjXFxtGgnuLl0Rhnzdcp8OfokP8i8jH] x-ms-publictraffictype: Email x-incomingheadercount: 42 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:VE1EUR02HT040; x-ms-traffictypediagnostic: VE1EUR02HT040: x-microsoft-antispam-message-info: /o7UsI9hy3nEL4CDEivICGmHDlYSlk4odM16C1ZjC31HJLayDZrrZAWErvemF8vkXWjyaS/dAy0m7/naJ1Eh2EaBj9Vc3diwCdAVlNsnMWeo6/hZ/1gK+wn/YtwINfnOI0ytOy9UxAvSTzcnHCMF0WursHbPvCXllDVxmVx/m2/UFPW48F3h5lUiwqg1Ham6 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_" 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: 0cb30bd7-1889-40fd-7a08-08d70a9efb9f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 10:10:23.8358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1EUR02HT040 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY, 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 10:49:15 +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 10:10:28 -0000 --_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi ZmnSCPxj, 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: http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-s= take-version As far as I know the grinding attack is and old issue that is fixed in PoS = v3.0. >>>At least the proposed `assumeutxo` requires the operator to explicitly e= nable it, but I believe your "hardcoded checkpoints" cannot be disabled, mu= ch less disabled-by-default. We don't trust the developers, the source code is public and anyone can che= ck it. With the hardcoded checkpoints is exactly the same, they are in the = source code repository and everyone can check them. The checkpoints are the= easiest part to check. A user doesn't have any reason to remove the checkp= oints, but as with anything in the source code, they could modify it to avo= id the checkpoints (and become vulnerable to Long Range attacks doing it) >>>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= algorithm. 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. Updat= ed nodes are fully protected, and under normal circumstances new nodes can = just follow the longest chain as always. The other extreme situation that c= ould cause a hard fork is that the network is splitted more than N blocks, = which should require some social consensus to fix it. So N should be long e= nough, like a few hours of blocks or even 1 day. >>> History rewrites are not the only attack possible. The worst attack is a censorship attack, and a 99% staker can easily censor= on the creation of new blocks. I don't agree, history rewrite attacks are much worse than censorship becau= se they can be used to steal funds from people. In PoS staking addresses ar= e public, so maybe it should be possible to detect if some transaction in t= he mempool is repeatedly being ignored and what staking deposit is repeated= ly ignoring transactions. After some time, a hard fork could burn the funds= of the evil validator. >>> Worse, under proof-of-stake it is often the case that stakers are award= ed even more coin with which they can stake. Sure, but in PoW the miners with more hash power earn more coins that can b= e used to purchase more miners. There is always the privilege of the rich g= uy, no matter if its PoW or PoS. The point is to design a protocol that don= 't allow the rich to destroy the network. 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= flawed, how can you explain that a coin with this market cap is not being = attacked? https://www.coingecko.com/en/coins/nxt Another thing is that Ethereum itself is going to PoS next year, but with a= different implementation that I'm proposing here. Regards, ________________________________ 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 Good morning Kenshiro, Sent with ProtonMail Secure Email. =1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev wrote: > Hi, > > After studying several Proof of Stake implementations I think it's not on= ly an eco-friendly (and more ethical) alternative to Proof of Work, but cor= rectly implemented could be 100% secure against all 51% history rewrite att= acks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvemen= ts are required: 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 unencumber= ed free-market payment for the consumption of energy is somehow not market-= efficient despite the well-known phenomenon of the invisible hand, and beli= eves that it is possible to get something for nothing. Please re-examine your assumptions. > - Hardcoded checkpoints:each Bitcoin Core release (each few months) shoul= d 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 = checkpoint, and prevents any Long-Range attack. While this is a developer list and made up of developers who would be quite= 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 enab= le it, but I believe your "hardcoded checkpoints" cannot be disabled, much = less disabled-by-default. > 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 a= nd 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. Under the trust-minimization requirement of Bitcoin this is simply not acce= ptable. 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= algorithm. > > 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. History rewrites are not the only attack possible. The worst attack is a censorship attack, and a 99% staker can easily censor= on the creation of new blocks. Censorship attacks cannot be prevented except by ensuring that no single en= tity can claim 51% control of new block creation. By ensuring this, we can ensure that at least some other entities are unlik= ely to keep a transaction out of the blockchain, and in particular that no = entity can make a short-ranged history rewrite if a censored transaction *d= oes* 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 = achieve uncensorability, since it is non-trivial to acquire energy. Under proof-of-stake it is difficult to impossible to determine if some sin= gle 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. Depending on the PoS implementation, stake-grinding may allow a 49% staker = to achieve 51% and thereby the ability to censor transactions. Regards, ZmnSCPxj --_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,

I'm based on the more evolved implementation of PoS that I know, which= is PoS v3.0 and it's currently implemented in several coins:

http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof= -of-stake-version

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

>>>At least the proposed `assumeutxo` requires the operator t= o explicitly enable it, but I believe your "hardcoded checkpoints"= ; cannot be disabled, much less disabled-by-default.

We don't trust the developers, the source code is public and anyone ca= n check it. With the hardcoded checkpoints is exactly the same, they are in= the source code repository and everyone can check them. The checkpoints ar= e the easiest part to check. A user doesn't have any reason to remove the checkpoints, but as with anything in= the source code, they could modify it to avoid the checkpoints (and become= vulnerable to Long Range attacks doing it)

>>>Under the trust-minimization requirement of Bitcoin this i= s simply not acceptable.
As there is no way to trust-minimally heal from a network split (and e= very time a node is shut down, that is indistinguishable from a network spl= it that isolates that particular node), this is not a trust-minimizing cons= ensus algorithm.

The block explorer or other additional source of trust like a friend w= ould 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. = Updated nodes are fully protected, and under normal circumstances new nodes can just follow the longest chain= as always. The other extreme situation that could cause a hard fork is tha= t the network is splitted more than N blocks, which should require some soc= ial consensus to fix it. So N should be long enough, like a few hours of blocks or even 1 day.

>>> History rewrites are not the only attack possible.
The worst attack is a censorship attack, and a 99% staker can easily c= ensor on the creation of new blocks.

I don't agree, history rewrite attacks are much worse than censorship = because they can be used to steal funds from people. In PoS staking address= es are public, so maybe it should be possible to detect if some transaction= in the mempool is repeatedly being ignored and what staking deposit is repeatedly ignoring transactions. Afte= r some time, a hard fork could burn the funds of the evil validator.

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

Sure, but in PoW the miners with more hash power earn more coins that = can be used to purchase more miners. There is always the privilege of the r= ich guy, no matter if its PoW or PoS. The point is to design a protocol tha= t don't allow the rich to destroy the network.


Let me put it in this way: NXT is a PoS coin that uses moving checkpoi= nts with a market cap of 21 million dollars. If the current PoS protocols a= re so flawed, how can you explain that a coin with this market cap is not b= eing attacked?

https://www.coingecko.com/en/coins/nxt

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

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 B= itcoin
 
Good morning Kenshiro,


Sent with ProtonMail Secure Email.

=1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:

> 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 = correctly implemented could be 100% secure against all 51% history rewrite = attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements are required:

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 unencumber= ed free-market payment for the consumption of energy is somehow not market-= efficient despite the well-known phenomenon of the invisible hand, and beli= eves that it is possible to get something for nothing.

Please re-examine your assumptions.

> - Hardcoded checkpoints:each Bitcoin Core release (each few months) sh= ould include a hardcoded checkpoint with the hash of the current block heig= ht in that moment. This simple measure protects the blockchain up to the la= st checkpoint, and prevents any Long-Range attack.

While this is a developer list and made up of developers who would be quite= 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 enab= le it, but I believe your "hardcoded checkpoints" cannot be disab= led, much less disabled-by-default.

> This extra rule could be connecting to a block explorer to download th= e hash of the current block height, or ask some trusted source like a frien= d and enter the hash manually. After being fully updated, the user can alwa= ys check that he is in the correct chain checking with a block explorer.

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

>
> Someone could have 99% of the coins and still would be unable to use t= he coins to do any history rewrite attack. The attacker could only slow dow= n the 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= on the creation of new blocks.

Censorship attacks cannot be prevented except by ensuring that no single en= tity can claim 51% control of new block creation.
By ensuring this, we can ensure that at least some other entities are unlik= ely to keep a transaction out of the blockchain, and in particular that no = entity can make a short-ranged history rewrite if a censored transaction *d= oes* 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 = achieve uncensorability, since it is non-trivial to acquire energy.
Under proof-of-stake it is difficult to impossible to determine if some sin= gle entity controls >51% of stakeable coins, and thus has no way to prot= ect 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.

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


Regards,
ZmnSCPxj
--_000_DB6PR10MB1832BAAB9D194B6AA61C2573A6C90DB6PR10MB1832EURP_--