summaryrefslogtreecommitdiff
path: root/a0/14937cc38beacc5be6902af20f173e05ddbc6d
blob: 202238b86dc00e5bf6f9f9bea67ee6e54e2fde87 (plain)
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
Return-Path: <1240902@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C3B2BB1E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Jun 2017 18:01:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com
	[209.85.213.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 670D0183
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Jun 2017 18:01:46 +0000 (UTC)
Received: by mail-vk0-f49.google.com with SMTP id y70so56491087vky.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 19 Jun 2017 11:01:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:from:date:message-id:subject:to;
	bh=nur+4Sg+VwPvr0+Br+y8mE32QCO7d2XYHKqHnwDULdo=;
	b=QqCy3gKBHQabwv6PptN5xn7CGyxoqzdnprsxYJAqIMQTYD626Vq93fu0TgIzm2qOm9
	fbX4HxdcIJUlP0dGbXMyf+QAnuMa7oV1zLfacoLK9+alS2uGfoHnFSaW4IkzOOqsCxS/
	D/OwlhiUoHo4LGbHQoyqO1rZ0yZbYXuxUX9+oGekTWPRjBx43HrDjkvxlurIYq27CRJW
	CVzIPr1mBK3HIMZDqDtft4Np6xUhNGYN3ELYtnwkSaRSvFDg6udMNUomixPKtjyA5TbG
	+HydzwJQNfAMgTvpbx/dzZNBCTI/uaFQBz14s5HJf33T5Q49ybA0JC7JzEBOm5RZbFam
	2r5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=nur+4Sg+VwPvr0+Br+y8mE32QCO7d2XYHKqHnwDULdo=;
	b=pHFXFL2b4b0Yt2Tp4wvcpGhfIIX0L2u2P8/XeGE3u33Fo4A4eWKSpwtEojvuqt1sBZ
	iqiTOzOa7RBKikgEYmDpXj6zgh+BoSgLLSrk4i99yLbgzBQwDXOVijgtj2fql5qEGpl+
	itInbtzfcAXADeODOG74Fu7EGMk80sKEqbsGYZktNIBNavSX9JupMOP+bhLCI3qyxWH2
	evFIx+NSSfODccNJKOLZH4nEoTCP1xUSte8eHyNrpCtW1Ly7sbZyC8BiyMaR//fN6slD
	cmffzjbZPDZiskDy1uLQmjwzg9zZU0AIrlbPXfghIS4I446ceBiD0xiWqRbahlEtb5Db
	2yXQ==
X-Gm-Message-State: AKS2vOxJ+jTE0oRCHtYbqnkOb4scb2ESL7GEbn/eBpbJGGgyvpIw6Xec
	YCd3kW+JTGV/35XxjUMVY7YOrjpEsJsr
X-Received: by 10.31.150.195 with SMTP id y186mr13693144vkd.149.1497895305326; 
	Mon, 19 Jun 2017 11:01:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.70.100 with HTTP; Mon, 19 Jun 2017 11:01:45 -0700 (PDT)
From: Wang Chun <1240902@gmail.com>
Date: Tue, 20 Jun 2017 02:01:45 +0800
Message-ID: <CAFzgq-woP3kWC9wYm=YxA_W=jMoL0AegTtUhTX3kEdMaB3m1rA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a1141deda95b844055253ed50"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [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:01:46 -0000

--001a1141deda95b844055253ed50
Content-Type: text/plain; charset="UTF-8"

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:
* It protects existing multi-billion dollar investments from innocent
mining users,
* 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,
* We'll suddenly have 5 times of block space, that solves the scaling
problem,
* 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.

--001a1141deda95b844055253ed50
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>There has been proposal to change=
 the PoW in case of potential 51% attacks from malicious miners during a fo=
rk. But such a change in PoW renders multi-billion-dollar of ASIC into wort=
hless. 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 sa=
me double sha256 PoW but mix it with PoS features. Such a PoW+PoS system ha=
s several advantages:<br></div>* It protects existing multi-billion dollar =
investments from innocent mining users,<br></div>* A malicious miner cannot=
 launch attacks and rewrite the blockchain with 51% or even more hashrate,<=
br></div>* If we insert 4 PoS blocks between 2 PoW blocks, we&#39;ll have 2=
-minute block time span, that solves the long confirmation time problem,<br=
></div><div>* We&#39;ll suddenly have 5 times of block space, that solves t=
he scaling problem,<br></div><div>* The PoS blocks only mine transaction fe=
es, so the 21M cap remains,<br></div>* With careful design, the PoW+PoS tra=
nsition _might_ be able to deploy with a soft fork.<br></div></div>

--001a1141deda95b844055253ed50--