path: root/01/6666ac865742305094a411311c7a94ef00a0af

Return-Path: <tensiam@hotmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F2C921444
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 []" <tensiam@hotmail.com>
To: Eric Voskuil <eric@voskuil.org>, ZmnSCPxj <ZmnSCPxj@protonmail.com>
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: <DB6PR10MB183268A7D3C744B1269E46EAA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
	<DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>,
	<brBQhROvRWwcPjdOBU0_7e0_dpBN4Noy1gP9TaEB6bEiOWTa3Huumz242_pjVI27u_G_edcTX7Ko6aD6pi6ta1vdQMzHCAli5Q_-55HD2SU=@protonmail.com>
In-Reply-To: <brBQhROvRWwcPjdOBU0_7e0_dpBN4Noy1gP9TaEB6bEiOWTa3Huumz242_pjVI27u_G_edcTX7Ko6aD6pi6ta1vdQMzHCAli5Q_-55HD2SU=@protonmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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: 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 <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 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

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<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 all,</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);">
&gt;&gt;&gt;<span>1. &nbsp;A network split (maybe better term is &quot;netw=
ork partition&quot;?) wherein some number of nodes are temporarily unable t=
o contact the rest of the network.<br>
</span><span>&nbsp; &nbsp; This has the degenerate but very common case whe=
re a single node is temporarily unable to communicate with the rest of the =
network.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>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:</s=
pan></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>-PoS: Burn the funds of the attacker with a hard fork</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>-PoW: Change the PoW algorithm with a hard fork</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>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.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>&gt;&gt;&gt;&nbsp;2. &nbsp;A node being shut down, then brought back =
online again.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>It's the same as above.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span>&gt;&gt;&gt;<span>To expand on this: by censoring ***all*** transacti=
ons one is able to prevent spending of all funds.<br>
</span><span>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.</span></span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><span><br>
</span></span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><span>Yes but I think this can be solved in PoS, because there should=
 be only 2 possible cases:</span></span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><span><br>
</span></span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><span>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</span></span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><span>2 - The attacker does a 51% attack stopping doing blocks in the=
 main chain, so the longest chain is his &quot;private&quot; 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.</span></span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span><br>
</span></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)">
&gt;&gt;&gt;&nbsp;Aside from that, this is possible to evade by running 100=
00 masternodes and splitting your staking funds among them.</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
stakingWeight =3D numberOfCoins ^ 1000</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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:</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
honestValidatorStakingWeight =3D 2 ^ 1000 =3D Very big number</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
attackerStakingWeightPerAddress =3D 1 ^ 1000 =3D 1</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
totalAttackerWeight =3D 1 * 98 =3D 98</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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.</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
&gt;&gt;&gt;&nbsp;Basically: &quot;never base consensus rules on mempool st=
ate&quot; is a good rule of thumb for ensuring that consensus can be mainta=
ined.</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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.</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
&gt;&gt;&gt;&nbsp;<span>Another thing is that Ethereum itself is going to P=
oS next year, but with a different implementation that I'm proposing here.<=
br>
</span>
<div><br>
</div>
<div>&gt;&gt;&gt;Just another nail in the coffin.<br>
</div>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Do you think Ethereum PoS will fail?</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Regards,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</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> ZmnSCPxj &lt;ZmnSCPxj=
@protonmail.com&gt;<br>
<b>Sent:</b> Thursday, July 18, 2019 3:13<br>
<b>To:</b> Eric Voskuil<br>
<b>Cc:</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 class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt"=
>
<div class=3D"PlainText">Good morning all,<br>
<br>
&gt; &gt; &gt;&gt;&gt;Under the trust-minimization requirement of Bitcoin t=
his is simply not acceptable.<br>
&gt; &gt; 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.<br>
&gt;<br>
&gt; 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.<br>
<br>
I am uncertain what you mean here.<br>
<br>
What I am attempting to compare are:<br>
<br>
1.&nbsp; A network split (maybe better term is &quot;network partition&quot=
;?) wherein some number of nodes are temporarily unable to contact the rest=
 of the network.<br>
&nbsp;&nbsp;&nbsp; This has the degenerate but very common case where a sin=
gle node is temporarily unable to communicate with the rest of the network.=
<br>
<br>
AND<br>
<br>
2.&nbsp; A node being shut down, then brought back online again.<br>
<br>
Neither seems to match &quot;feature&quot; or &quot;bug&quot;, as both are =
simply accidents of deployment.<br>
<br>
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.<br>
Ideally, such an algorithm would place as little trust as possible on some =
other node, and would work even in adversarial conditions.<br>
<br>
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.<br>
<br>
<br>
&gt; &gt; &gt;&gt;&gt; History rewrites are not the only attack possible.<b=
r>
&gt; &gt; The worst attack is a censorship attack, and a 99% staker can eas=
ily censor on the creation of new blocks.<br>
&gt; &gt;<br>
&gt; &gt; I don't agree, history rewrite attacks are much worse than censor=
ship because they can be used to steal funds from people.<br>
&gt;<br>
&gt; Censorship can steal everybody=92s money.<br>
<br>
To expand on this: by censoring ***all*** transactions one is able to preve=
nt spending of all funds.<br>
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.<br>
<br>
<br>
&gt;<br>
&gt; &gt; In PoS staking addresses are public, so maybe it should be possib=
le to detect if some transaction in the mempool is repeatedly&nbsp;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.<br>
&gt;<br>
&gt; Political money.<br>
<br>
Aside from that, this is possible to evade by running 10000 masternodes and=
 splitting your staking funds among them.<br>
Rent from a botnet, and it appears the masternodes are geographically diver=
se.<br>
Then it becomes hard to accuse the network of actually being controlled str=
ongly by a single participant.<br>
(the ability to rent botnets means that even existing PoS coins might alrea=
dy be strongly controlled, but appear &quot;healthy&quot; because masternod=
es *appear* geographically diverse, but in actuality are controlled by a si=
ngle entity)<br>
<br>
Further, &quot;detect if some transaction in the mempool&quot; 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).<br>
I can generate a completely new transaction, then accuse the masternodes of=
 censoring it.<br>
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.<br>
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.<br>
But the masternodes would not agree, not having seen my transaction in thei=
r mempool, and thus is the network consensus destroyed.<br>
<br>
Basically: &quot;never base consensus rules on mempool state&quot; is a goo=
d rule of thumb for ensuring that consensus can be maintained.<br>
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.<br>
<br>
<br>
&gt; &gt; <a href=3D"https://www.coingecko.com/en/coins/nxt">https://www.co=
ingecko.com/en/coins/nxt</a><br>
&gt; &gt;<br>
&gt; &gt; Another thing is that Ethereum itself is going to PoS next year, =
but with a different implementation that I'm proposing here.<br>
&gt;<br>
&gt; Just another nail in the coffin.<br>
<br>
I agree.<br>
<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</div>
</span></font></div>
</div>
</body>
</html>

--_000_DB6PR10MB183268A7D3C744B1269E46EAA6C80DB6PR10MB1832EURP_--