diff options
| author | Peter Todd <pete@petertodd.org> | 2017-06-19 14:31:54 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-19 18:32:04 +0000 |
| commit | 820d95f18ff1bd798e5dea6fe2a362bc99f4c03d (patch) | |
| tree | 6a87a74fde88e85d8ba8163aa7807a927c68f4d4 | |
| parent | 8b2de0a10e6d58634684f3368eaf676d5bf455c7 (diff) | |
| download | pi-bitcoindev-820d95f18ff1bd798e5dea6fe2a362bc99f4c03d.tar.gz pi-bitcoindev-820d95f18ff1bd798e5dea6fe2a362bc99f4c03d.zip | |
Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat
| -rw-r--r-- | 21/49e22eb07b7f18a27c74e1b8f4059519a12f66 | 166 |
1 files changed, 166 insertions, 0 deletions
diff --git a/21/49e22eb07b7f18a27c74e1b8f4059519a12f66 b/21/49e22eb07b7f18a27c74e1b8f4059519a12f66 new file mode 100644 index 000000000..a8f174810 --- /dev/null +++ b/21/49e22eb07b7f18a27c74e1b8f4059519a12f66 @@ -0,0 +1,166 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 72208B43 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <pete@petertodd.org> +To: Wang Chun <1240902@gmail.com> +Message-ID: <20170619183154.GB7003@fedora-23-dvm> +References: <CAFzgq-woP3kWC9wYm=YxA_W=jMoL0AegTtUhTX3kEdMaB3m1rA@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" +Content-Disposition: inline +In-Reply-To: <CAFzgq-woP3kWC9wYm=YxA_W=jMoL0AegTtUhTX3kEdMaB3m1rA@mail.gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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-- + |