Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F2C921444 for ; Thu, 18 Jul 2019 09:59:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-oln040092069095.outbound.protection.outlook.com [40.92.69.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9729A12E for ; Thu, 18 Jul 2019 09:59:01 +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=IalJE98YOcxb1yEdCRFfurGjATpe03xy+Hmnz9CXZT0=; b=fGd5BwTD5hE54JxsLpjeh9idPz/Dz8CS8fr1LhqFEenUKz4gR9XnGt78ZdNQFYtf1oDAQY/x2zw38VWpnEzMtOQ+hEI1sKlMQq4NJFuvVzjXG5joudgK0cDlQc15WYXZd5NL0i7hkEq0LcuwKhVN/LZh0txb0QzNcvDhQDRH1fGMdrD3hPUowJHK7wT6K5mjeDGTLcxtj1304ppjUrL3mXa9XXzDcIX2NOz+R3kp+tmjSpaBmz8c1KGSTEdYHMY+Jb4dAulgRXYwP1U9qRjrRtXACCUxhvaEJB0YCiQZZmhKwj1sv0GXjh5ciru1Xq9FIWtnYchJxQRKZ9dWsOACYg== Received: from AM5EUR02FT054.eop-EUR02.prod.protection.outlook.com (10.152.8.54) by AM5EUR02HT069.eop-EUR02.prod.protection.outlook.com (10.152.9.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19; Thu, 18 Jul 2019 09:58:59 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.8.58) by AM5EUR02FT054.mail.protection.outlook.com (10.152.8.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.19 via Frontend Transport; Thu, 18 Jul 2019 09:58:59 +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; Thu, 18 Jul 2019 09:58:59 +0000 From: "Kenshiro []" To: Eric Voskuil , ZmnSCPxj Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabN5JoAgAC5YAiAACE9gIAA3P6AgACGGbs= Date: Thu, 18 Jul 2019 09:58:59 +0000 Message-ID: References: <207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>, In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A4C6B15E721E54CDDD53C0E2D6C65B695B5A3B59A608E64CDC1358988423FEF1; UpperCasedChecksum:9B5C7CBA9B21F2579B2C6F65EAFC4FA3697F7BC6E4F8630C685121537B2CD532; SizeAsReceived:7340; Count:43 x-tmn: [SaYxPuc5BqjvaeTC7ZJovLErUzvZAjQc] x-ms-publictraffictype: Email x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:AM5EUR02HT069; x-ms-traffictypediagnostic: AM5EUR02HT069: x-ms-exchange-purlcount: 1 x-microsoft-antispam-message-info: D9sRF/3lfecGJA4k+aeSL5zuwOaBEZHwhkYWTV5+k2nvkrHjylcSqi0q+zsiPj9eEa4uxOhu5zbyKaHbiEY2XcuccGDFcg2AE6/a0a1JkQOqWuPhSrmXOx9qWlYakp6QrKHcjE3P64dMnQEecv+9HxHEfy0GLuQOaYWVJsUIKW1hEjPYyeq4H2i2tCOY6Rqq Content-Type: multipart/alternative; boundary="_000_DB6PR10MB183268A7D3C744B1269E46EAA6C80DB6PR10MB1832EURP_" 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: 5131755d-a3b6-4ccb-b884-08d70b668dec X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2019 09:58:59.0646 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT069 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, 18 Jul 2019 11:19:58 +0000 Cc: Bitcoin Protocol Discussion 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: Thu, 18 Jul 2019 09:59:05 -0000 --_000_DB6PR10MB183268A7D3C744B1269E46EAA6C80DB6PR10MB1832EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, >>>1. A network split (maybe better term is "network partition"?) wherein = some number of nodes are temporarily unable to contact the rest of the netw= ork. This has the degenerate but very common case where a single node is tem= porarily unable to communicate with the rest of the network. I think there is some misunderstanding here. A single node can be isolated = from the rest of the network any time and when it reconnects it only has to= follow the longest chain as always. Checking with a block-explorer or a fr= iend's node is only required under the extreme situation of being under a 5= 1% attack, but that is also a problem for Proof Of Work. Both protocols req= uire manual intervention: -PoS: Burn the funds of the attacker with a hard fork -PoW: Change the PoW algorithm with a hard fork The other extreme situation would be if the network or internet itself is s= plitted more than N blocks. If that happens, it should require manual inter= vention to merge both chains. But in PoW it's much worse because the longes= t chain wins and it erases all history of the losing chain. Are you sure th= at's better? All transactions of one day (or more) could be erased forever. >>> 2. A node being shut down, then brought back online again. It's the same as above. >>>To expand on this: by censoring ***all*** transactions one is able to pr= event spending of all funds. This will crash the value of the staked funds also, but note that the stake= r could use techniques like short options to leverage this and potentially = earn more than the value of their staked funds, effectively stealing the en= tire marketcap of the attacked coin. Yes but I think this can be solved in PoS, because there should be only 2 p= ossible cases: 1 - The attacker doesn't stop making blocks in the main chain an he only ce= nsors transactions in his blocks: in this case, there is always some honest= block so he can only slow the network 2 - The attacker does a 51% attack stopping doing blocks in the main chain,= so the longest chain is his "private" chain which only has his blocks: the= n he can censor every transaction, but that attack is very evident and a ha= rd fork could burn his funds. >>> Aside from that, this is possible to evade by running 10000 masternodes= and splitting your staking funds among them. It's possible to give more staking weight to coins together in a single add= ress than splitted coins like with this formula (or some improved version) stakingWeight =3D numberOfCoins ^ 1000 So imagine Bitcoin has only 100 coins in 2 wallets, the honest wallet has 2= coins in a single address, and the attacker wallet splits his 98 coins in = 98 addresses: honestValidatorStakingWeight =3D 2 ^ 1000 =3D Very big number attackerStakingWeightPerAddress =3D 1 ^ 1000 =3D 1 totalAttackerWeight =3D 1 * 98 =3D 98 So X coins together always have more weight than any bigger amount of coins= splitted in amounts smaller than X. The attacker needs to have at least on= e address with X coins. >>> Basically: "never base consensus rules on mempool state" is a good rule= of thumb for ensuring that consensus can be maintained. Yep it's only an idea, if a big number of transactions is being censored it= should be possible to detect it. After some time an increasing number of n= odes will see that they have very old transactions in their mempools even i= f blocks are not full. >>> 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. Do you think Ethereum PoS will fail? Regards, ________________________________ From: ZmnSCPxj Sent: Thursday, July 18, 2019 3:13 To: Eric Voskuil Cc: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Good morning all, > > >>>Under the trust-minimization requirement of Bitcoin this is simply n= ot 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 spli= t that isolates that particular node), this is not a trust-minimizing conse= nsus algorithm. > > That=92s nonsense, one is a feature (systemic trust), the other is a bug = (code accident). But there is a way to minimize actual forks - try not to c= hange the consensus rules in the code you ship. I am uncertain what you mean here. What I am attempting to compare are: 1. A network split (maybe better term is "network partition"?) wherein som= e number of nodes are temporarily unable to contact the rest of the network= . This has the degenerate but very common case where a single node is tem= porarily unable to communicate with the rest of the network. AND 2. A node being shut down, then brought back online again. Neither seems to match "feature" or "bug", as both are simply accidents of = deployment. The point (as I understand it) of a consensus algorithm is to be able to ge= t all nodes into agreement about the global state, even after a network par= tition. Ideally, such an algorithm would place as little trust as possible on some = other node, and would work even in adversarial conditions. To my understanding, the proposal from Kenshiro is not able to get all node= s into agreement about global state after a network partition, without trus= t in some node, when in adversarial conditions. > > >>> 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=92s money. To expand on this: by censoring ***all*** transactions one is able to preve= nt spending of all funds. This will crash the value of the staked funds also, but note that the stake= r could use techniques like short options to leverage this and potentially = earn more than the value of their staked funds, effectively stealing the en= tire marketcap of the attacked coin. > > > In PoS staking addresses are public, so maybe it should be possible to = detect if some transaction in the mempool is repeatedly being ignored and w= hat staking deposit is repeatedly ignoring transactions. After some time, a= hard fork could burn the funds of the evil validator. > > Political money. Aside from that, this is possible to evade by running 10000 masternodes and= splitting your staking funds among them. Rent from a botnet, and it appears the masternodes are geographically diver= se. Then it becomes hard to accuse the network of actually being controlled str= ongly by a single participant. (the ability to rent botnets means that even existing PoS coins might alrea= dy be strongly controlled, but appear "healthy" because masternodes *appear= * geographically diverse, but in actuality are controlled by a single entit= y) Further, "detect if some transaction in the mempool" cannot provide a proof= , as no construct ever precommits to the state of the mempool at a particul= ar time (if it did, the mempool would cease to be a mempool and would be pa= rt of the block). I can generate a completely new transaction, then accuse the masternodes of= censoring it. Other nodes may not believe me, as they have not seen my transaction on the= ir mempool, but note that the mempools of nodes are ***not*** strongly sync= hronized. By careful timing and control of the connectivity of the network, it become= s possible to effectively split the consensus algorithm by showing my trans= action to some non-masternode nodes but keeping my transaction away from ma= sternodes, then have the non-masternode nodes accuse the masternodes of cen= soring my transaction and hereby penalizing them. But the masternodes would not agree, not having seen my transaction in thei= r mempool, and thus is the network consensus destroyed. Basically: "never base consensus rules on mempool state" is a good rule of = thumb for ensuring that consensus can be maintained. Consensus rules should consider only data that is committed to some block, = and the mempool is not intended to be committed to in every block. > > https://www.coingecko.com/en/coins/nxt > > > > 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. I agree. Regards, ZmnSCPxj --_000_DB6PR10MB183268A7D3C744B1269E46EAA6C80DB6PR10MB1832EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi all,

>>>1.  A network split (maybe better term is "netw= ork partition"?) wherein some number of nodes are temporarily unable t= o contact the rest of the network.
    This has the degenerate but very common case whe= re a single node is temporarily unable to communicate with the rest of the = network.

I think there is some misunderstanding here. A single node can be iso= lated from the rest of the network any time and when it reconnects it only = has to follow the longest chain as always. Checking with a block-explorer o= r a friend's node is only required under the extreme situation of being under a 51% attack, but that is also = a problem for Proof Of Work. Both protocols require manual intervention:

-PoS: Burn the funds of the attacker with a hard fork
-PoW: Change the PoW algorithm with a hard fork

The other extreme situation would be if the network or internet itsel= f is splitted more than N blocks. If that happens, it should require manual= intervention to merge both chains. But in PoW it's much worse because the = longest chain wins and it erases all history of the losing chain. Are you sure that's better? All transacti= ons of one day (or more) could be erased forever.

>>> 2.  A node being shut down, then brought back = online again.

It's the same as above.

>>>To expand on this: by censoring ***all*** transacti= ons one is able to prevent spending of all funds.
This will crash the value of the staked funds also, but note t= hat the staker could use techniques like short options to leverage this and= potentially earn more than the value of their staked funds, effectively st= ealing the entire marketcap of the attacked coin.

Yes but I think this can be solved in PoS, because there should= be only 2 possible cases:

1 - The attacker doesn't stop making blocks in the main chain a= n he only censors transactions in his blocks: in this case, there is always= some honest block so he can only slow the network
2 - The attacker does a 51% attack stopping doing blocks in the= main chain, so the longest chain is his "private" chain which on= ly has his blocks: then he can censor every transaction, but that attack is= very evident and a hard fork could burn his funds.

>>> Aside from that, this is possible to evade by running 100= 00 masternodes and splitting your staking funds among them.

It's possible to give more staking weight to coins together in a single add= ress than splitted coins like with this formula (or some improved version)<= /div>

stakingWeight =3D numberOfCoins ^ 1000

So imagine Bitcoin has only 100 coins in 2 wallets, the honest wallet has 2= coins in a single address, and the attacker wallet splits his 98 coins in = 98 addresses:

honestValidatorStakingWeight =3D 2 ^ 1000 =3D Very big number

attackerStakingWeightPerAddress =3D 1 ^ 1000 =3D 1
totalAttackerWeight =3D 1 * 98 =3D 98

So X coins together always have more weight than any bigger amount of coins= splitted in amounts smaller than X. The attacker needs to have at least on= e address with X coins.

>>> Basically: "never base consensus rules on mempool st= ate" is a good rule of thumb for ensuring that consensus can be mainta= ined.

Yep it's only an idea, if a big number of transactions is being censored it= should be possible to detect it. After some time an increasing number of n= odes will see that they have very old transactions in their mempools even i= f blocks are not full.

>>> Another thing is that Ethereum itself is going to P= oS next year, but with a different implementation that I'm proposing here.<= br>

>>>Just another nail in the coffin.

Do you think Ethereum PoS will fail?

Regards,


From: ZmnSCPxj <ZmnSCPxj= @protonmail.com>
Sent: Thursday, July 18, 2019 3:13
To: Eric Voskuil
Cc: Kenshiro []; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on B= itcoin
 
Good morning all,

> > >>>Under the trust-minimization requirement of Bitcoin t= his is simply not acceptable.
> > 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 networ= k split that isolates that particular node), this is not a trust-minimizing= consensus algorithm.
>
> That=92s 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 t= o change the consensus rules in the code you ship.

I am uncertain what you mean here.

What I am attempting to compare are:

1.  A network split (maybe better term is "network partition"= ;?) wherein some number of nodes are temporarily unable to contact the rest= of the network.
    This has the degenerate but very common case where a sin= gle node is temporarily unable to communicate with the rest of the network.=

AND

2.  A node being shut down, then brought back online again.

Neither seems to match "feature" or "bug", as both are = simply accidents of deployment.

The point (as I understand it) of a consensus algorithm is to be able to ge= t all nodes into agreement about the global state, even after a network par= tition.
Ideally, such an algorithm would place as little trust as possible on some = other node, and would work even in adversarial conditions.

To my understanding, the proposal from Kenshiro is not able to get all node= s into agreement about global state after a network partition, without trus= t in some node, when in adversarial conditions.


> > >>> History rewrites are not the only attack possible. > > The worst attack is a censorship attack, and a 99% staker can eas= ily censor on the creation of new blocks.
> >
> > I don't agree, history rewrite attacks are much worse than censor= ship because they can be used to steal funds from people.
>
> Censorship can steal everybody=92s money.

To expand on this: by censoring ***all*** transactions one is able to preve= nt spending of all funds.
This will crash the value of the staked funds also, but note that the stake= r could use techniques like short options to leverage this and potentially = earn more than the value of their staked funds, effectively stealing the en= tire marketcap of the attacked coin.


>
> > In PoS staking addresses are public, so maybe it should be possib= le to detect if some transaction in the mempool is repeatedly being ig= nored and what staking deposit is repeatedly ignoring transactions. After s= ome time, a hard fork could burn the funds of the evil validator.
>
> Political money.

Aside from that, this is possible to evade by running 10000 masternodes and= splitting your staking funds among them.
Rent from a botnet, and it appears the masternodes are geographically diver= se.
Then it becomes hard to accuse the network of actually being controlled str= ongly by a single participant.
(the ability to rent botnets means that even existing PoS coins might alrea= dy be strongly controlled, but appear "healthy" because masternod= es *appear* geographically diverse, but in actuality are controlled by a si= ngle entity)

Further, "detect if some transaction in the mempool" cannot provi= de a proof, as no construct ever precommits to the state of the mempool at = a particular time (if it did, the mempool would cease to be a mempool and w= ould be part of the block).
I can generate a completely new transaction, then accuse the masternodes of= censoring it.
Other nodes may not believe me, as they have not seen my transaction on the= ir mempool, but note that the mempools of nodes are ***not*** strongly sync= hronized.
By careful timing and control of the connectivity of the network, it become= s possible to effectively split the consensus algorithm by showing my trans= action to some non-masternode nodes but keeping my transaction away from ma= sternodes, then have the non-masternode nodes accuse the masternodes of censoring my transaction and hereby penali= zing them.
But the masternodes would not agree, not having seen my transaction in thei= r mempool, and thus is the network consensus destroyed.

Basically: "never base consensus rules on mempool state" is a goo= d rule of thumb for ensuring that consensus can be maintained.
Consensus rules should consider only data that is committed to some block, = and the mempool is not intended to be committed to in every block.


> > https://www.co= ingecko.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.
>
> Just another nail in the coffin.

I agree.



Regards,
ZmnSCPxj
--_000_DB6PR10MB183268A7D3C744B1269E46EAA6C80DB6PR10MB1832EURP_--