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 1AB6CEA5 for ; Tue, 16 Jul 2019 23:00:13 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE1FD886 for ; Tue, 16 Jul 2019 23:00:10 +0000 (UTC) Date: Tue, 16 Jul 2019 23:00:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1563318008; bh=3V4Wdr+aB+mt0BUbgPSMMVCXiBawTjTxkR54I0jua0Y=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=bc96g9Us+CwBq5qfzWhTEfX7M8itJv54usc5jqv1TkWb1nzXO9z2bAgvlGIcgflka wjqkPlMZRQ1cek9XZ+TRPPC7valY12NepSZQP9ov4+ECf1RBH37ItITUaA4W4tlvCi AL12SNF9B3s/K4GVGKixVEheBhI841xkO0m/VusI= To: "Kenshiro \\[\\]" , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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 23:00:13 -0000 Good morning Kenshiro, Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev wrote: > Hi, > > After studying several Proof of Stake implementations I think it's not on= ly an eco-friendly (and more ethical) alternative to Proof of Work, but cor= rectly implemented could be 100% secure against all 51% history rewrite att= acks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvemen= ts are required: Under the trust-minimization and uncensorability requirements that Bitcoin = has, nothing is more efficient than proof-of-work. The very idea of proof-of-stake labors under the assumption that unencumber= ed free-market payment for the consumption of energy is somehow not market-= efficient despite the well-known phenomenon of the invisible hand, and beli= eves that it is possible to get something for nothing. Please re-examine your assumptions. > - Hardcoded checkpoints:each Bitcoin Core release (each few months) shoul= d 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. While this is a developer list and made up of developers who would be quite= incentivized to agree to such a setup, note that this effectively trusts t= he developers. At least the proposed `assumeutxo` requires the operator to explicitly enab= le it, but I believe your "hardcoded checkpoints" cannot be disabled, much = less disabled-by-default. > This extra rule could be connecting to a block explorer to download the h= ash of the current block height, or ask some trusted source like a friend a= nd 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. Under the trust-minimization requirement of Bitcoin this is simply not acce= ptable. As there is no way to trust-minimally heal from a network split (and every = time a node is shut down, that is indistinguishable from a network split th= at isolates that particular node), this is not a trust-minimizing consensus= algorithm. > > 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 t= he network not creating his blocks, or censor transactions in his blocks. History rewrites are not the only attack possible. The worst attack is a censorship attack, and a 99% staker can easily censor= on the creation of new blocks. Censorship attacks cannot be prevented except by ensuring that no single en= tity can claim 51% control of new block creation. By ensuring this, we can ensure that at least some other entities are unlik= ely to keep a transaction out of the blockchain, and in particular that no = entity can make a short-ranged history rewrite if a censored transaction *d= oes* get into the blockchain from the efforts of another block producer. This is trivial under proof-of-work, and is the cost we accept in order to = achieve uncensorability, since it is non-trivial to acquire energy. Under proof-of-stake it is difficult to impossible to determine if some sin= gle entity controls >51% of stakeable coins, and thus has no way to protect= against censorship attack. Worse, under proof-of-stake it is often the case that stakers are awarded e= ven more coin with which they can stake. Depending on the PoS implementation, stake-grinding may allow a 49% staker = to achieve 51% and thereby the ability to censor transactions. Regards, ZmnSCPxj