1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
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--
|
