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 72208B43 for ; Mon, 19 Jun 2017 18:32:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149082.authsmtp.co.uk (outmail149082.authsmtp.co.uk [62.13.149.82]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46FD0E9 for ; Mon, 19 Jun 2017 18:32:02 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v5JIW0gC033126; Mon, 19 Jun 2017 19:32:01 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v5JIVwxA039752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Jun 2017 19:31:59 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 0F8BD4008A; Mon, 19 Jun 2017 18:31:58 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id E31DE20058; Mon, 19 Jun 2017 14:31:54 -0400 (EDT) Date: Mon, 19 Jun 2017 14:31:54 -0400 From: Peter Todd To: Wang Chun <1240902@gmail.com> Message-ID: <20170619183154.GB7003@fedora-23-dvm> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 95003c1f-551d-11e7-801f-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwsUEkAaAgsB AmEbWl1eU197WWM7 bghPaBtcak9QXgdq T0pMXVMcUgASeHpG Tm8eURB1cgcIcX92 ZwhrW3BbXxd7I1t4 R08ACGwHMGB9YGAe Bl1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXASId SwURIEgUSFoKADN0 WBkTVSkoVVUfQDk+ JABuNl4RVEAcLlo1 K1hpV0gfNldPU0A8 V0hRHCZSJEJJWyox AApGNQAA X-Authentic-SMTP: 61633532353630.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat 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: Mon, 19 Jun 2017 18:32:04 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 20, 2017 at 02:01:45AM +0800, Wang Chun via bitcoin-dev wrote: > There has been proposal to change the PoW in case of potential 51% attacks > from malicious miners during a fork. But such a change in PoW renders > multi-billion-dollar of ASIC into worthless. which hurts economy so much > and the average innocent mining users. I would propose, instead of PoW > change, we could change the system to the same double sha256 PoW but mix = it > with PoS features. Such a PoW+PoS system has several advantages: You have to specify what you mean by "PoS" - there's dozens of variations. Equally, existing pure PoS schemes probably don't make sense as a "bolt-on" add-on, as once you introduce PoW to it you should design something that us= es the capabilities of both systems. FWIW, I've heard that the Ethereum guys are leaning towards abandoning pure= PoS and are now trying to design a PoW + staking system instead. > * It protects existing multi-billion dollar investments from innocent > mining users, To be clear, you mean such a scheme would protect the multi-billion dollar investments non-malicious miners have made in SHA256^2 hardware by ensuring= it remains useful, right? > * A malicious miner cannot launch attacks and rewrite the blockchain with > 51% or even more hashrate, > * If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute blo= ck > time span, that solves the long confirmation time problem, Note that if those PoS blocks are *pure* PoS, you'll create a significant r= isk of double-spend attacks, as there's zero inherent cost to creating a pure-P= oS block. Such blocks can't be relied on for confirmations; even "slasher" sch= emes have significant problems with sybil attacks. > * We'll suddenly have 5 times of block space, that solves the scaling > problem, The scaling problem is one of scalability; PoS does nothing to improve scalability (though many in the ETH community have been making dishonest statements to the contrary). > * The PoS blocks only mine transaction fees, so the 21M cap remains, > * With careful design, the PoW+PoS transition _might_ be able to deploy > with a soft fork. As a sidechain yes, but in what you propose above the extra blocks wouldn't contain transactions that non-PoS-aware nodes could understand in a backwards-compatible way. All the above aside, I don't think it's inherently wrong to look at adding = PoS block *approval* mechanisms, where a block isn't considered valid without s= ome kind of coin owner approval. While pure-PoS is fundamentally broken in a decentralized setting, it may be possible to mitigate the reasons it's brok= en with PoW and get a system that has a stronger security model than PoW alone. FWIW there's some early discussions by myself and others about this type of approach on the #bitcoin-wizards IRC channels, IIRC from around 2014 or so. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZSBiZAAoJECSBQD2l8JH7xWYH/iePCP2tVasafFv9POg0D3N/ EmobxyYbL89qOWQSDow1/KmkghHQF6vnq4/oErdSAEA0cESOjx80/6HyWLMjXU+J SRIBhR6YuuhfpPW4KjXS9eW23tt0R6WcSpYfuVwTLYhcSoyZq904ZYKg1SrCLhUx cjpmCuv0V7d6O2KsgykpJOj6OqpyizQgZSqySbASTCWibLG/F2l8jain7Cc42LBO b7TKCww4TZ7h9C3vUCg/PUf0w0oHeTb2u9iF85RynlRFshH8r8zEzphGEMLkqkiI hlgRPkst1nPO37s8i3ocIxCGtZVJO8Yidh4EfrpzrGLJzHjgLfZvxjuWmurZHg4= =e364 -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC--