path: root/2f/82fea3810ef0e3b2421907ed2b9c01d3445422

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 09A62C59
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jul 2019 09:30:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from EUR01-VE1-obe.outbound.protection.outlook.com
	(mail-oln040092066093.outbound.protection.outlook.com [40.92.66.93])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BB2E3224
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jul 2019 09:30:48 +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=4YKJ6gvnwGGiqOz+IzcF6E7ZnexXUbJ6fRkzT33Arns=;
	b=Y30RRaQoO8bSUGYFDcJd9PtI+XNWYPvC6LZCd7/ErzX+6LYhTiMuX5Epxgrf0loS2I5nwnj/wBpzzprN6eaFrH/xLcUWv0QNaBaUsnH69bQYz5NxHPGAn0QYGCYXGh0sHxpwTtAgfp394+/bqLuH/wDqpuNY2w0hWr0l8xIYpauFcTldlhCEATn5UKa3g9YdcqpMilHC9iw8Bax43B0O899QNy+JYo/DlAIu+L9+JL+LDre0IJc4bkRmETWjd6nFrEhC54aDj6sywweS0rn5wLYzYBb+pv1eWhUELKknRW6f4zdXdnGXrhgR+lVpq2NzsClU/Dr9a5B7BkJeSR0V9Q==
Received: from HE1EUR01FT006.eop-EUR01.prod.protection.outlook.com
	(10.152.0.57) by HE1EUR01HT213.eop-EUR01.prod.protection.outlook.com
	(10.152.1.203) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18;
	Wed, 24 Jul 2019 09:30:46 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.0.59) by
	HE1EUR01FT006.mail.protection.outlook.com (10.152.1.228) with Microsoft
	SMTP
	Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
	15.20.2052.18 via Frontend Transport; Wed, 24 Jul 2019 09:30:46 +0000
Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
	([fe80::cc12:47f0:aa33:6b70]) by
	DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM
	([fe80::cc12:47f0:aa33:6b70%3]) with mapi id 15.20.2115.005;
	Wed, 24 Jul 2019 09:30:46 +0000
From: "Kenshiro []" <tensiam@hotmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabN5JoAgAC5YAiAACE9gIAA3P6AgACGGbuAAFRKgIAABaLjgADcq4CAAFRgVoABC80AgACX1OmAABXgAIAAH579gAW2bQCAAE7sbQ==
Date: Wed, 24 Jul 2019 09:30:46 +0000
Message-ID: <DB6PR10MB1832D32D7EFD4BB5A5969C6BA6C60@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>
	<DB6PR10MB183268A7D3C744B1269E46EAA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<-FVjDC_47DKPnkjAvcOAh3XMnIBIKspnLWrbpNlgE043OsEAJx9ZT5I3m7XWgwbsVps3QlwP7XSDu5yZ5JWSLxGiJM99T1ycjqqP7AUrtzo=@protonmail.com>
	<DB6PR10MB1832C21C602126F797132A4AA6C80@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<hv2EyhKHfNd-TmH2j-8jLFWw6nUMYHOsNF_5Vy-eZLQLessR9Quy4uXn8ZVYLK4dZrwcVq3QeCcEXdCHPOJ0tgya5P34S1seEAGSRyPYpks=@protonmail.com>
	<DB6PR10MB1832EF2ACF6539E03494A381A6CB0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<zs4_imeOmpTHJLNyl90kuY8HWoLEjgmCcims6fESt2Fg5goLfUdcKdcPIsKCWRfojPifaNfg5XKi24fwAIRW_LUnAz-yzwOA6S362R4g5RA=@protonmail.com>
	<DB6PR10MB1832F6395C1E6337FD896235A6CA0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<LDVRsI_WqicA9u8WYrBo71H0Xkw7FgwZbjvkWCh_aycSY2awgRdlYsoba2Vf0cRLiye3Sh5ISR2pVI1mUcceVDP0sLukRbrEgYM3ngIza9o=@protonmail.com>
	<DB6PR10MB18329E1B30FF6521B31FCC81A6CA0@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>,
	<uKu7MYCqmshtGrlC26M73Mdi85p5-rc5DCdSnDhpDiw2wArzvRNyId054oQFCcinQER3PTr_nJCYTtCnqxtVOYvdTtSzoKpZmQwOjaF8kUU=@protonmail.com>
In-Reply-To: <uKu7MYCqmshtGrlC26M73Mdi85p5-rc5DCdSnDhpDiw2wArzvRNyId054oQFCcinQER3PTr_nJCYTtCnqxtVOYvdTtSzoKpZmQwOjaF8kUU=@protonmail.com>
Accept-Language: en-US, es-ES
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:27D34E62AF294D675382B8C69B0B9ADC5DBC635E8244E96E32A07305B5F737A1;
	UpperCasedChecksum:C833ED0DCA74DA7E7D2FF84E2D3EB3E010F2A86BF286FBE82FD0A9A7CF2E88DA;
	SizeAsReceived:8458; Count:43
x-tmn: [WeofqQNRswxwtIv5U1E035YaELwdxm4Z]
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)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045);
	SRVR:HE1EUR01HT213; 
x-ms-traffictypediagnostic: HE1EUR01HT213:
x-microsoft-antispam-message-info: /5FrJdjeJFTjDChtFnFB3J1YUj3G7E5p6fBRQtjfPQP8KEqf/1bR7u6162qwqwcjRQlzWELh907hwGCcZ9eIF8LXjrEFoHfmDlAOGeBd6f4DI1guGlPkvwhttEcgZrQ90VSEW6z0w/Yhi5jQjoTDKAcsRwssTcyv895o/jCcs1scYBKpsc0N/jDkFu3jlA59
Content-Type: multipart/alternative;
	boundary="_000_DB6PR10MB1832D32D7EFD4BB5A5969C6BA6C60DB6PR10MB1832EURP_"
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: 25c144ad-4fda-4ddf-27a7-08d710199b62
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 09:30:46.1093 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT213
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: Wed, 24 Jul 2019 11:37:03 +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: Wed, 24 Jul 2019 09:30:50 -0000

--_000_DB6PR10MB1832D32D7EFD4BB5A5969C6BA6C60DB6PR10MB1832EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi ZmnSCPxj,

Thank you for your apologies.

>>> Just to be clear, I do not think your additions to the base proof-of-st=
ake can fix the issues introduced by proof-of-stake.

No problem. After thinking about my experimental idea to use a formula to g=
ive more weight to coins together in a single address I think it wouldn't w=
ork as I expected.

But what I'm defending here is the standard PoS v3.0 which as far I know is=
 something like a "gold standard" in PoS.

There are also more "modern" techniques not included in PoS v3.0 that could=
 be added like evaluating blockchain density to detect possible attacks whi=
ch could also be used to improve security:

i.e.: as far I know, a 51% history rewrite attack can't be done in PoS if t=
he attacker doesn't stop creating his 51% of blocks in the main chain to ma=
ke it shorter than his private fork, and that can be detected:

If nodes detect a hard fork starting in block N (and N has a minimum depth =
like 10 blocks or whatever), and the main chain has a dangerous low block d=
ensity between the tip of the blockchain and block N, instead of following =
the longest chain, the nodes could start some emergency protocol like ignor=
ing the new fork.

Regards,

________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Wednesday, July 24, 2019 6:14
To: Kenshiro [] <tensiam@hotmail.com>
Cc: Eric Voskuil <eric@voskuil.org>; Bitcoin Protocol Discussion <bitcoin-d=
ev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

Good morning Kenshiro and list,

I apologize for the unnecessarily toxic words I used in replies to you, Ken=
shiro.
I also apologize to subscribers of the list for this behavior.
Such behavior should not be tolerated and should be called out.

Just to be clear, I do not think your additions to the base proof-of-stake =
can fix the issues introduced by proof-of-stake.
A general heuristic in designing anything is that additional mechanisms can=
not improve efficiency.

However, it seems I cannot argue the point without becoming rude or introdu=
cing irrelevant arguments.
Thus, I will no longer respond to this thread.

Regards,
ZmnSCPxj

--_000_DB6PR10MB1832D32D7EFD4BB5A5969C6BA6C60DB6PR10MB1832EURP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<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 ZmnSCPxj,</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);">
Thank you for your apologies.</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;&nbsp;<span style=3D"color: rgb(0, 0, 0); font-family: Calibri,=
 Helvetica, sans-serif; font-size: 12pt;">Just to be clear, I do not think =
your additions to the base proof-of-stake can fix the issues introduced by =
proof-of-stake.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;">No problem. After thinking about my experimental id=
ea to use a formula to give more weight to coins together in a single addre=
ss I think it wouldn't work as I expected.</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;">But what I'm defending here is the standard PoS v3.=
0 which as far I know is something like a &quot;gold standard&quot; in PoS.
<br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;">There are also more &quot;modern&quot; techniques n=
ot included in PoS v3.0 that could be added like evaluating blockchain dens=
ity to detect possible attacks which could also
 be used to improve security:</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;">i.e.: as far I know, a 51% history rewrite attack c=
an't be done in PoS if the attacker doesn't stop creating his 51% of blocks=
 in the main chain to make it shorter
 than his private fork, and that can be detected:</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;"><br>
</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;">If nodes detect a hard fork starting in block N (an=
d N has a minimum depth like 10 blocks or whatever), and the main chain has=
 a dangerous low block density between
 the tip of the blockchain and block N, instead of following the longest ch=
ain, the nodes could start some emergency protocol like ignoring the new fo=
rk.</span></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);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;">Regards,</span></div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-s=
erif; font-size: 12pt;"><br>
</span></div>
<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> Wednesday, July 24, 2019 6:14<br>
<b>To:</b> Kenshiro [] &lt;tensiam@hotmail.com&gt;<br>
<b>Cc:</b> Eric Voskuil &lt;eric@voskuil.org&gt;; Bitcoin Protocol Discussi=
on &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<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 Kenshiro and list,<br>
<br>
I apologize for the unnecessarily toxic words I used in replies to you, Ken=
shiro.<br>
I also apologize to subscribers of the list for this behavior.<br>
Such behavior should not be tolerated and should be called out.<br>
<br>
Just to be clear, I do not think your additions to the base proof-of-stake =
can fix the issues introduced by proof-of-stake.<br>
A general heuristic in designing anything is that additional mechanisms can=
not improve efficiency.<br>
<br>
However, it seems I cannot argue the point without becoming rude or introdu=
cing irrelevant arguments.<br>
Thus, I will no longer respond to this thread.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</div>
</span></font></div>
</div>
</body>
</html>

--_000_DB6PR10MB1832D32D7EFD4BB5A5969C6BA6C60DB6PR10MB1832EURP_--