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)
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] An alternative way to protect the network from
 51% attacks threat
Precedence: list


--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--