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 50AF0D99 for ; Tue, 16 Jul 2019 21:28:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-oln040092071038.outbound.protection.outlook.com [40.92.71.38]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E6F28892 for ; Tue, 16 Jul 2019 21:28:03 +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=xAxtJaFgSM7j/OJJwiDPRu9WbpkdBkjcXuRcwoks4xU=; b=KiieSMBfOdsr5RQjUJOtlcSJ3jUAFecKcZi1ykynm32uTDH9rprfR0IyloXftbo3jgIj6Hqj3H4CQESLybodStWZh6g48NP2gi0jizvC1nF+wDgoEJ2gyAIEGdlevMTU+uzffndKNfwo9nWtiWMEqDEmdlGUd40lU/ZuB3lN4ciYm3bayv+jsRDEXRz0MwakSw4H3j39q0bq5rvq04Nhiy9glvlyDqTJpicMjwrrjrX39sHhj8SAylG7z2W8IkPYWvJzir/5cy3UdTkM6R6P3DANs2LNKXws/+MPgeAnpiigT0AaaeW1gsPVy14OV/TNPAQjz2P/gZDCWI0/kxhDyQ== Received: from AM5EUR03FT008.eop-EUR03.prod.protection.outlook.com (10.152.16.51) by AM5EUR03HT239.eop-EUR03.prod.protection.outlook.com (10.152.16.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2052.18; Tue, 16 Jul 2019 21:28:02 +0000 Received: from DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM (10.152.16.52) by AM5EUR03FT008.mail.protection.outlook.com (10.152.16.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18 via Frontend Transport; Tue, 16 Jul 2019 21:28:01 +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; Tue, 16 Jul 2019 21:28:01 +0000 From: "Kenshiro []" To: Oscar Lafarga , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Thread-Index: AQHVN+X3lOGGRtlWh0GqqwNnOoz9LabNvC2AgAAIwng= Date: Tue, 16 Jul 2019 21:28:01 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, es-ES Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:6DB4DFC73963C7B0DD91341B8F32F87D926DABD85236F6BE85AC9D9F0B13BB81; UpperCasedChecksum:69E551AEC4AB3A9D11A665CD375E0649A40A8AAAE183E0872DA2567414821694; SizeAsReceived:6901; Count:42 x-tmn: [v9KVNw9LFshfb7O9SqLSoAN9R0C60YMJ] x-ms-publictraffictype: Email x-incomingheadercount: 42 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:AM5EUR03HT239; x-ms-traffictypediagnostic: AM5EUR03HT239: x-ms-exchange-purlcount: 3 x-microsoft-antispam-message-info: of85H1nZGLp/b8GB4bTo8ZGvBiSg20g6R51bakH/7CFtyljMKbUEolJDCZko48RhPEzbLWkHf4sFkt/NWbqTZDz9ppnDpOSxumQEYcrJbGJbALuAMQsQ4inSNt6BPi8GLzpxh2jnWFecMXeA96pPcMbkISSR5Pu5umNXz6B/We7Ih+3s6/9liS9DqyE6i0mJ Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_" 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: 0a3b074d-e5cd-4cec-3fbd-08d70a347b17 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2019 21:28:01.4883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT239 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, 17 Jul 2019 07:52:04 +0000 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: Tue, 16 Jul 2019 21:28:05 -0000 --_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Oscar, Thank you for your answer. Just to clarify my proposal: 1 - It's a full change to Proof of Stake protocol to avoid the energy waste= and to prevent a 51% history rewrite attack, even if the attacker has 99% = of coins. 2 - The hardcoded checkpoints could be set by each bitcoin node client, not= only Bitcoin Core. No matter if the checkpoints are different, only that t= hey are frequent. They are there to prevent Long Range attacks. Checkpoints= are public just like the rest of the software, they don't require any trus= t. A bad checkpoint would be detected by the community. 3 - There are several PoS coins working just now and as far as I know they = don't have any problem. NXT coin implements the moving checkpoint system an= d others the hardcoded checkpoints. 4 - In any given block, only one staker gets the authorization to create th= at block, so other stakers can't spam the network with many different block= s as they are illegal. 5 - The block explorer is only required during a 51% attack, and only for n= odes that are updating blocks during the attack. Updated nodes are protecte= d thanks to the moving checkpoints. Regards, ________________________________ From: Oscar Lafarga Sent: Tuesday, July 16, 2019 22:35 To: Kenshiro []; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin Hi Kenshiro, I don't think your proposal would require any changes to the Bitcoin Core i= mplementation. This system you describe seems like it would operate as an i= ndependent addition, rather than an alternative to the Proof of Work consen= sus code that runs within Bitcoin now. It introduces security risk in the s= election of block explorer and to the Bitcoin Core release dispatch system,= reducing the trustlessness of the current network. Also, without the const= raints that PoW places on block creation, you increase the vector space for= attacks since it is trivial to spam blocks to node on the network (see Syb= il attack). I believe many other software projects have tried similar checkpointing sch= emes that have resulted in hard forks or overall weakened consensus. I have= n't dug too deeply, but I'm not aware of any cases where these schemes acco= mplish anything useful to improve the bitcoin network. Best, On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] via bitcoin-dev > wrot= e: 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Oscar Lafarga https://www.setlife.network --_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Oscar,

Thank you for your answer. Just to clarify my proposal:

1 - It's a full change to Proof of Stake protocol to avoid the energy waste= and to prevent a 51% history rewrite attack, even if the attacker has 99% = of coins.

2 - The hardcoded checkpoints could be set by each bitcoin node client, not= only Bitcoin Core. No matter if the checkpoints are different, only that t= hey are frequent. They are there to prevent Long Range attacks. Checkpoints= are public just like the rest of the software, they don't require any trust. A bad checkpoint would be dete= cted by the community.

3 - There are several PoS coins working just now and as far as I know they = don't have any problem. NXT coin implements the moving checkpoint system an= d others the hardcoded checkpoints. 

4 - In any given block, only one staker gets the authorization to create th= at block, so other stakers can't spam the network with many different block= s as they are illegal. 

5 - The block explorer is only required during a 51% attack, and only for n= odes that are updating blocks during the attack. Updated nodes are protecte= d thanks to the moving checkpoints.

Regards,

From: Oscar Lafarga <ote= ch47@gmail.com>
Sent: Tuesday, July 16, 2019 22:35
To: Kenshiro []; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on B= itcoin
 
Hi Kenshiro,

I don't think your proposal would require any changes to the Bitcoin Core i= mplementation. This system you describe seems like it would operate as an i= ndependent addition, rather than an alternative to the Proof of Work consen= sus code that runs within Bitcoin now. It introduces security risk in the selection of block explorer and to= the Bitcoin Core release dispatch system, reducing the trustlessness of th= e current network. Also, without the constraints that PoW places on block c= reation, you increase the vector space for attacks since it is trivial to spam blocks to node on the networ= k (see Sybil attack).<= br>
I believe many other software projects have tried similar checkpointing sch= emes that have resulted in hard forks or overall weakened consensus. I have= n't dug too deeply, but I'm not aware of any cases where these schemes acco= mplish anything useful to improve the bitcoin network.

Best,

On Tue, Jul 16, 2019 at 5:33 AM Ken= shiro [] via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

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 and still = would be unable to use the coins to do any history rewrite attack. The atta= cker could only slow down the network not creating his blocks, or censor transactions in his blocks.


What do you think? :)


Regards


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--
--_000_DB6PR10MB1832257D676DDA7B4F55E658A6CE0DB6PR10MB1832EURP_--