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 0C4314EB2 for ; Thu, 11 Jul 2019 15:18:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-oln040092072076.outbound.protection.outlook.com [40.92.72.76]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0819F891 for ; Thu, 11 Jul 2019 15:18:41 +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=+pBc5zdYVs0MWRDDrMc7dx6LD7LUosjtY7qzGKWuJqY=; b=gfZPl8S+ue4o2vXllPjlwrPRpeHwCSmzByiJ24COUpq1oOo6+tl9sRvoT++g9U63e9O+cytBm4FqvKJcp+p2PUGjKRA0vBh/LKyZfaT0BkyPZaUEBxkGkyFSCqTZ3+4m78zRxBfBNmiGK74zIWcsAzUqXWy9V0kWt1G0J82cdB1RFeo+j15okg8f4siVJ03kEDweaFa4iLjdtnfF4EAIHF+1VRm78Qm+Ljg41zRTiUbYW5I/DG27eUXIH2g0EuTYyPt8V8v+XkrkfGmObXyEtrOCH0FQpO3uJuzzwdUCkV8vzYgB6Ce0q5mlq2tOyP+YYIALHcdubWhF/lPEXO9CnQ== Received: from AM5EUR03FT041.eop-EUR03.prod.protection.outlook.com (10.152.16.54) by AM5EUR03HT067.eop-EUR03.prod.protection.outlook.com (10.152.17.237) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18; Thu, 11 Jul 2019 15:16:41 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.16.53) by AM5EUR03FT041.mail.protection.outlook.com (10.152.17.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18 via Frontend Transport; Thu, 11 Jul 2019 15:16:41 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM ([fe80::812a:1018:bec7:74ab]) by DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM ([fe80::812a:1018:bec7:74ab%3]) with mapi id 15.20.2052.020; Thu, 11 Jul 2019 15:16:41 +0000 From: "Kenshiro []" To: "bitcoin-dev@lists.linuxfoundation.org" Thread-Topic: Secure Proof Of Stake implementation on Bitcoin Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LQ== Date: Thu, 11 Jul 2019 15:16:40 +0000 Message-ID: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:3CAA443FD75F23F24E4DC180BA7F9C940032E704E5D9916D8370096A1ED2F4BD; UpperCasedChecksum:8810D7811EFC9B2C9ED8A333D192D7906930D0A45D407563232EB066A355B9D0; SizeAsReceived:6595; Count:40 x-tmn: [pB4Cqe4JfEmPV9s6A+9mAD4shUocA/tC] x-ms-publictraffictype: Email x-incomingheadercount: 40 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:AM5EUR03HT067; x-ms-traffictypediagnostic: AM5EUR03HT067: x-microsoft-antispam-message-info: 2PNsi88QNtClCpOxxSRi+nH9g9zYea9/uoxfIOUDfzdjYERyUOCJ3nVN0s7+xeAZt0gsBUg046MpJfKqWq49J2xyBLOWczuaLzdt/63Wbf2IGFzWyc6VWAxPdwrB9Yl2xJQMzNDiAlvLFhhlkVcaHllcxjuoBcyjUvY+XpZpKOtT0IA3v7krFQJpz3FH0StA Content-Type: multipart/alternative; boundary="_000_DB6PR10MB183264613ED0D61F2FBC6524A6F30DB6PR10MB1832EURP_" 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: b0fce93f-b8d6-4aa3-dbe5-08d70612c6c8 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 15:16:40.8086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT067 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: Tue, 16 Jul 2019 12:31:38 +0000 Subject: [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, 11 Jul 2019 15:18:43 -0000 --_000_DB6PR10MB183264613ED0D61F2FBC6524A6F30DB6PR10MB1832EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 corre= ctly implemented could be 100% secure against all 51% history rewrite attac= ks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements= are required: - Hardcoded checkpoints: each Bitcoin Core release (each few months) should= include a hardcoded checkpoint with the hash of the current block height i= n that moment. This simple measure protects the blockchain up to the last c= heckpoint, and prevents any Long-Range attack. - Moving checkpoints: the nodes only allow chain reorgs not deeper than N b= locks. If N is 10 blocks, then the nodes ignore any hard fork starting at a= ny block under nodeBlockHeight - N. This fully protects nodes that are onli= ne and updated. Nodes that are not fully updated need some extra rule to be= protected between the last hardcoded checkpoint and the current blockchain= height. This extra rule could be connecting to a block explorer to downloa= d the hash of the current block height, or ask some trusted source like a f= riend and 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= . Someone could have 99% of the coins and still would be unable to use the co= ins to do any history rewrite attack. The attacker could only slow down the= network not creating his blocks, or censor transactions in his blocks. What do you think? :) Regards --_000_DB6PR10MB183264613ED0D61F2FBC6524A6F30DB6PR10MB1832EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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


- Hardcoded checkpoints: each Bitcoin Core release (each few months) should include a hardcoded ch= eckpoint with the hash of the current block height in that moment. This sim= ple measure protects the blockchain up to the last checkpoint, and prevents any Long-Range attack.


- Moving checkpoints: the nodes only allow chain= reorgs not deeper than N blocks. If N is 10 blocks, then the nodes ignore = any hard fork starting at any block under nodeBlockHeight - N. This fully p= rotects nodes that are online and updated. Nodes that are not fully updated need some extra rule to be prote= cted between the last hardcoded checkpoint and the current blockchain heigh= t. This extra rule could be connecting to a block explorer to download the = hash of the current block height, or ask some trusted source like a friend and enter the hash manually. Afte= r being fully updated, the user can always check that he is in the correct = chain checking with a block explorer.


Someone could have 99% of the coins an= d still would be unable to use the coins to do any history rewrite attack. = The attacker could only slow down the network not creating his blocks, or censor transactions in his blocks.


What do you think? :)


Regards


--_000_DB6PR10MB183264613ED0D61F2FBC6524A6F30DB6PR10MB1832EURP_--