From: Peter Todd <pete@petertodd•org>
To: Wang Chun <1240902@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] An alternative way to protect the network from 51% attacks threat
Date: Mon, 19 Jun 2017 14:31:54 -0400 [thread overview]
Message-ID: <20170619183154.GB7003@fedora-23-dvm> (raw)
In-Reply-To: <CAFzgq-woP3kWC9wYm=YxA_W=jMoL0AegTtUhTX3kEdMaB3m1rA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]
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 uses
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 block
> time span, that solves the long confirmation time problem,
Note that if those PoS blocks are *pure* PoS, you'll create a significant risk
of double-spend attacks, as there's zero inherent cost to creating a pure-PoS
block. Such blocks can't be relied on for confirmations; even "slasher" schemes
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 some
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 broken
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2017-06-19 18:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-19 18:01 Wang Chun
2017-06-19 18:31 ` Peter Todd [this message]
2017-06-19 20:32 ` Moral Agent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170619183154.GB7003@fedora-23-dvm \
--to=pete@petertodd$(echo .)org \
--cc=1240902@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox