Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 81931E39 for ; Tue, 16 Jul 2019 20:35:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8DC208A1 for ; Tue, 16 Jul 2019 20:35:34 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id v24so21329263ljg.13 for ; Tue, 16 Jul 2019 13:35:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6D/YTKiAjf0i3dk0zfTtmiE6zXpybK2vEF7BvnTNXg8=; b=kROBvnaTDoknSTUkyDTMck1K8cVme6jAjMZwHFRLpVYRSbn3A3eJi0iDNF2Mm+WoqP Q/PHAYTd/uNEsmWVOROwtNlX1K3Lm+0t4fXRVmVjmLt5FOrGJJUGvbidoa9nO3YqknAr FF3EnzqJQdRLeL3L8SPwU7kA7xRsyXODJYtsbLB/MiiRy5VvLqoPaTbvE+ruv3bkumhj 5XQirANwwjPduaIJZfISkxr17dNCrly9H6KgI3AHH2P1lsxoJ61eyOvFjI3nIEkfYd6W FJShT6nQ5MvgYSzFyG1UVCeb4XqeAtw6ptLd3E/corUr6mtH5BeM9sbbOKWjawdgUhsl U4/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6D/YTKiAjf0i3dk0zfTtmiE6zXpybK2vEF7BvnTNXg8=; b=XU4p4+wpyHh53ymgrYZtOVgRIOYubOZZYPiufU4GF95D8A3GW0KSB/Tc09dIxHvSyK +r1MXF0G3VU8DBgZSxCYGnOaJgdJ90bdzNBmpHKzcurl/w4+cpMXvmy1uJ6cPvrm75Rc 1LphZYXX43Y0BlIXYBUgBnGVF3DN70TRR+1OhsC+Igoyn2/+5rFfr6AyRIFW46rsj7em DNEBTtx1h8Q3ErwjLN8oDaTDLPuppTPKtYL/DT0leHwXgiccU53UPdaGyB6hlQbbzhbw HHWolQvGATobBZIt+Nd6fbTWJkmHne1a3KaTClgBScVM6mqt6fGhYKDH9Mav7swK5CbT WZhg== X-Gm-Message-State: APjAAAVgF6DhigYKkgVp+sHzxm5GsTBAZUMZhctu2ACqVH/wnB6uxEZg vzZO3AXekfHdLQ6d4ZxkaM9lw1494tao/CFsn3c= X-Google-Smtp-Source: APXvYqwUbclcJ5cg2yPh4WJxuYZxv7DGwA19IIa5ylajJGIT0g34UYVrQT1Od1BCUwThlPn3RnG/TB5gn9ETbs9q0zw= X-Received: by 2002:a2e:a415:: with SMTP id p21mr18609932ljn.111.1563309332730; Tue, 16 Jul 2019 13:35:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Oscar Lafarga Date: Tue, 16 Jul 2019 13:35:21 -0700 Message-ID: To: "Kenshiro []" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000739964058dd25125" X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, HTTPS_HTTP_MISMATCH, RCVD_IN_DNSWL_NONE autolearn=no 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 20:35:35 -0000 --000000000000739964058dd25125 Content-Type: text/plain; charset="UTF-8" Hi Kenshiro, I don't think your proposal would require any changes to the Bitcoin Core implementation. This system you describe seems like it would operate as an independent addition, rather than an alternative to the Proof of Work consensus 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 the current network. Also, without the constraints 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 Sybil attack ). I believe many other software projects have tried similar checkpointing schemes that have resulted in hard forks or overall weakened consensus. I haven't dug too deeply, but I'm not aware of any cases where these schemes accomplish anything useful to improve the bitcoin network. Best, On Tue, Jul 16, 2019 at 5:33 AM Kenshiro [] 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 > correctly implemented could be 100% secure against all 51% history rewrite > attacks. 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 in that moment. This simple 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 protects nodes that are > online 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 download the hash of the current block height, or ask some trusted > source like a friend 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 > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -- Oscar Lafarga https://www.setlife.network --000000000000739964058dd25125 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kenshiro,

I don't think your proposal would = require any changes to the Bitcoin Core implementation. This system you des= cribe seems like it would operate as an independent addition, rather than a= n alternative to the Proof of Work consensus 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 the= current network. Also, without the constraints that PoW places on block cr= eation, you increase the vector space for attacks since it is trivial to sp= am blocks to node on the network (see Sybil attack).

I believe many other software = projects have tried similar checkpointing schemes that have resulted in har= d forks or overall weakened consensus. I haven't dug too deeply, but I&= #39;m not aware of any cases where these schemes accomplish anything useful= to improve the bitcoin network.

Best,

On Tue, Jul 16, 2019 at 5:33 A= M Kenshiro [] 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 c= orrectly implemented could be 100% secure against all 51% history rewrite a= ttacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvements are required:


- Hardcoded checkpoints:=C2=A0each 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 wo= uld be unable to use the coins to do any history rewrite attack. The attack= er 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


--
--000000000000739964058dd25125--