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 09A62C59 for ; 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 ; 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 []" To: ZmnSCPxj 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: References: <207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>, , <-FVjDC_47DKPnkjAvcOAh3XMnIBIKspnLWrbpNlgE043OsEAJx9ZT5I3m7XWgwbsVps3QlwP7XSDu5yZ5JWSLxGiJM99T1ycjqqP7AUrtzo=@protonmail.com> , , , , In-Reply-To: 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 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, 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 Sent: Wednesday, July 24, 2019 6:14 To: Kenshiro [] Cc: Eric Voskuil ; Bitcoin Protocol Discussion 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
Hi ZmnSCPxj,

Thank you for your apologies.

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

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.

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

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:

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.

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 Discussi= on <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on B= itcoin
 
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_--