summaryrefslogtreecommitdiff
path: root/a4/868352d3aa02d288284af27564d950c7aea3e3
blob: 147b990ab426da5d7e29c6c9dbad1e99b40d3f5f (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
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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
Return-Path: <cheng@alephium.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2E07EC0881
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Dec 2019 09:48:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 1C8D587F8E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Dec 2019 09:48:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VmlrtsnemWCM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Dec 2019 09:48:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com
 [209.85.210.68])
 by hemlock.osuosl.org (Postfix) with ESMTPS id C105787F84
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  9 Dec 2019 09:48:01 +0000 (UTC)
Received: by mail-ot1-f68.google.com with SMTP id i4so11655939otr.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 09 Dec 2019 01:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=alephium-org.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=IumTk+mOnOh4x3eQZL0zunTkoSqCIgdWFpkhthNtjqQ=;
 b=WUWpSwx68xftbvsxUKwN2U0KirbeIz0UNQaUElCoYyzvsiR/012DOI1ESEgW58Rz9x
 LeXxuijcmswFVn8KHAJoSkjdN+cBvqhiHpEqnqA/UTb3KD9cedRbDHaTIok1wjNppfqa
 NP7mfjXwS7syxSDBYHkdxYjCSQLN7GpdBN34zBKjmMQDDoZFxoOmvua0J3jJmafywrgN
 jRKyiG3rkTgqB1qwfBwE/qbrnAdbSLp80UTdY8I0XoMA2SEMP7tNzzjU2XafLTKNzkV6
 SNCTTwc4TRNujNmsHttyQOJiuXXZxW1ywgJ6tqkBMRB58R40W/WfY4wxT/Q8BEXdvdO0
 9TCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=IumTk+mOnOh4x3eQZL0zunTkoSqCIgdWFpkhthNtjqQ=;
 b=tX3D3gRwpHISK4vlA2dy58QNfFRQ7788/oL3OsaUK1r7XqikXMhLGl7e3W770Hu2Ts
 z0iDfHgNgtkI80fMjRX1idenwTakivQtRq6FQiS8BJw8yznzQfbWfVGjaeCFo6aMR1Bv
 LG0eQ/dGVBes7V2liyNem3OgiBiH2vtVHmMuRfr1KOrUu7hhH0AgUUQpPtLQ8/VVr4cV
 9ru6QbJpopuw5nQgpineX196AkfdFP3eX1KlJk42DLqk8wbaP8V04ZG5qkuDrMgKqdyu
 KEsOfOeJKeCMBAXDncAU8QKIcYWu0C7fwskcjufZ0h/SYgzE6APpaByAzIaCUjGTl+aK
 4bCg==
X-Gm-Message-State: APjAAAWXkshBjL1BduLQMHvgUo18kJGX9fkeq4S30Is4wf2YJVj7GhOv
 5fJQbk+LlrHzZyvCAimsG/agqUJr5YCOumDAKTCtYw==
X-Google-Smtp-Source: APXvYqw8qXDr8aYs+eMSA5sB2rZ4zpS0BzSYnPGzhW9xOtf4jh2KKR8rLwG3GRRO1R/NNh+idRGghZf+B2j8CGYorg0=
X-Received: by 2002:a9d:6654:: with SMTP id q20mr20076709otm.284.1575884880665; 
 Mon, 09 Dec 2019 01:48:00 -0800 (PST)
MIME-Version: 1.0
References: <mailman.3482.1575825776.25512.bitcoin-dev@lists.linuxfoundation.org>
 <29C07E1A-DC6B-49F0-893B-A59E7BD8DB1C@monash.edu>
In-Reply-To: <29C07E1A-DC6B-49F0-893B-A59E7BD8DB1C@monash.edu>
From: Cheng Wang <cheng@alephium.org>
Date: Mon, 9 Dec 2019 10:47:49 +0100
Message-ID: <CAJgZxF4HMPf_Gmwd+KBZbsC7Yt+WdmcoF-Nfi9hF4oX8OBRKQA@mail.gmail.com>
To: Runchao Han <runchao.han@monash.edu>
Content-Type: multipart/alternative; boundary="00000000000084f42f0599424ad9"
X-Mailman-Approved-At: Mon, 09 Dec 2019 14:53:45 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Reducing energy consumption and increasing
 security at the same time
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 09 Dec 2019 09:48:03 -0000

--00000000000084f42f0599424ad9
Content-Type: text/plain; charset="UTF-8"

Hi Runchao,

- 1st question regarding double spending:

We won't allow a miner to sacrifice coinbase reward as much as possible for
a practical system. This will be achieved by setting a dynamic upper bound
for the number of rewards the miner could sacrifice. The upper bound would
be related to the actual mining difficulty (not the weighted one) of the
recent mining epoch.

In Section 8 of the paper, I discussed quite a lot about how to select
system parameters and how to transition the current PoW systems to PoLW.
Just for an example, for Bitcoin, we might transition from giving up 0
coinbase reward to giving up maximal 10% coinbase reward. In the long term,
if the value of Bitcoin goes as comparable to gold, we could allow the
miners to give up more rewards. The network could adjust these bounds
solely based on the internal state (i.e. the actual mining difficulty).

In short, PoLW could reduce the energy consumption of Bitcoin in
equilibrium from coinbase reward to even sub-linear. Still, the absolute
energy consumption would be kept at a sufficiently high level.

- 2nd question regarding tx fees:

We could simply reduce this problem to purely coinbase reward by adding tx
fees into the maximal coinbase reward. When the tx fees dominant miner's
profits, we could simply allow negative coinbase reward (i.e. miners spend
coins for the coinbase transaction).

Note that, using PoLW, we could remove the halving mechanism, as PoLW is
adaptive already.

Best, Cheng!

On Mon, Dec 9, 2019 at 1:45 AM Runchao Han <runchao.han@monash.edu> wrote:

> Hi Cheng,
>
> This is an interesting proposal!
> While the incentive analysis is sound, I have two concerns:
>
> ## What if a guy keeps mining easy blocks to launch 51% attacks?
>
> With PoLW, a miner can sacrifice the coinbase reward as much as possible
> to mine blocks faster.
> If the blockchain follows the longest chain rule, PoLW may make
> 51% attacks much easier.
> An easy way of fixing this is to choose the chain with most work rather
> than most blocks.
>
> ## What if the coinbase tx is no longer the majority of mining reward, but
> the fx fee?
>
> This might happen in the future.
> A possible solution is to limit the number of txs for easy blocks.
> For example, if a miner chooses to mine blocks N times easier, he can only
> include txs of which the total size is <= (block_size - metadata_size) / N.
>
> Best regards,
> Runchao
>
> Date: Sun, 8 Dec 2019 11:43:49 +0100
> From: Cheng Wang <cheng@alephium.org>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] Reducing energy consumption and increasing
> security at the same time
> Message-ID:
> <CAJgZxF4G_BjJ=OhuzhjfZtkePnEc2hz8DMZzFzWKBNh17XhBeQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Everyone,
>
> I would like to share my serious work on reducing the energy consumption of
> PoW without sacrificing security. My new type of algorithm is called PoLW.
> For a practical system where mining is profitable, PoLW could actually
> improve the security of the system.
>
> The idea is to shift part of the external cost of mining in the physical
> world (mainly energy consumption) to the internal cost of the network. In
> PoLW, the miners are able to give up part of the coinbase reward so as to
> get weight (> 1) for the block hash they produce. The total cost of
> generating a new block would still be equal to maximal coinbase reward in
> equilibrium.
>
> I analyzed two algorithms in the paper: linear PoLW and exponential PoLW.
> Linear PoLW could reduce energy consumption by a factor close to 1/2 in
> equilibrium, while exponential PoLW could reduce energy consumption by an
> arbitrary factor in equilibrium.
>
> In a practical system, mining is usually (if not always) profitable. If we
> transition from PoW to PoLW, the external costs of mining would decrease
> and the internal costs will increase. However, the decrease in external
> costs would be less than the increase in internal costs since mining is
> profitable. The total cost of block generation would get higher, therefore,
> the security will increase.
>
> Of course, we could not decrease the external costs of any existing system
> by a factor close to zero immediately. There is a section in my paper
> discussing this particularly. The principle of applying PoLW is that
> keeping the absolute external cost increasing all the time, but the
> percentage of external cost in the total cost gets lower eventually.
>
> This work is based on solid math calculation, and I am looking forward to
> feedback and discussions. My paper is available at:
> https://github.com/alephium/research/raw/master/polw.pdf
>
> It's inspired by the recent great paper of Itay, Alexander, and Ittay:
> https://arxiv.org/abs/1911.04124
>
> Best,
> Cheng Wang
>
>
>

-- 
Cheng Wang
# Love math and coding
# Founder of Alephium; Proposed BlockFlow algorithm
# Proposed the first linear-time asynchronous Byzantine consensus algorithm

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

<div dir=3D"ltr"><div>Hi Runchao,</div><div><br></div>- 1st question regard=
ing double spending:<div><br></div><div>We won&#39;t allow a miner to sacri=
fice coinbase reward as much as possible for a practical system. This will =
be achieved=C2=A0by setting a dynamic upper bound for the number of rewards=
 the miner could sacrifice. The upper bound would be related to the actual =
mining difficulty (not the weighted one) of the recent mining epoch.</div><=
div><br></div><div>In Section 8 of the paper, I discussed quite a lot about=
 how to select system parameters and how to transition the current PoW syst=
ems to PoLW. Just for an example, for Bitcoin, we might transition from giv=
ing up 0 coinbase reward to giving up maximal 10% coinbase reward. In the l=
ong term, if the value of Bitcoin goes as comparable to gold, we could allo=
w the miners to give up more rewards. The network could adjust these bounds=
 solely based on the internal state (i.e. the actual mining difficulty).</d=
iv><div><br></div><div>In short, PoLW could reduce the=C2=A0energy consumpt=
ion of Bitcoin in equilibrium from coinbase reward to even sub-linear. Stil=
l, the absolute energy consumption would be kept at a sufficiently high lev=
el.</div><div><br></div><div>- 2nd question regarding tx fees:</div><div><b=
r></div><div>We could simply reduce this problem to purely coinbase reward =
by adding tx fees into the maximal coinbase reward. When the tx fees domina=
nt miner&#39;s profits, we could simply allow negative coinbase reward (i.e=
. miners spend coins for the coinbase transaction).</div><div><br></div><di=
v>Note that, using PoLW, we could remove the halving mechanism, as PoLW is =
adaptive=C2=A0already.</div><div><br></div><div>Best, Cheng!</div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, D=
ec 9, 2019 at 1:45 AM Runchao Han &lt;<a href=3D"mailto:runchao.han@monash.=
edu">runchao.han@monash.edu</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div style=3D"overflow-wrap: break-word;"><div>H=
i Cheng,</div><div><br></div>This is an interesting proposal!<div>While the=
 incentive analysis is sound, I have two concerns:</div><div><br></div><div=
>##=C2=A0<span style=3D"font-family:&quot;Helvetica Neue&quot;;font-size:13=
px">What if a guy keeps mining easy blocks to launch 51% attacks?</span></d=
iv><div><span style=3D"font-family:&quot;Helvetica Neue&quot;;font-size:13p=
x"><br></span></div><div><font face=3D"Helvetica Neue" size=3D"2">With PoLW=
, a miner can sacrifice the coinbase reward as much as possible to mine blo=
cks faster.</font></div><div><font face=3D"Helvetica Neue" size=3D"2">If th=
e blockchain follows the=C2=A0longest chain rule, PoLW may make 51%=C2=A0at=
tacks much easier.</font></div><div><font face=3D"Helvetica Neue" size=3D"2=
">An easy way of fixing this is to choose the chain with most work rather t=
han most blocks.</font></div><div><br></div><div>## What if the coinbase tx=
 is no longer the majority of mining reward, but the fx fee?</div><div><br>=
</div><div>This might happen in the future.</div><div>A possible solution i=
s to limit the number of txs for easy blocks.</div><div>For example, if a m=
iner chooses to mine blocks N times easier, he can only include txs of whic=
h the total size is &lt;=3D (block_size - metadata_size) / N.</div><div><br=
></div><div>Best regards,</div><div>Runchao</div><div><br></div><div><div><=
blockquote type=3D"cite"><div><div>Date: Sun, 8 Dec 2019 11:43:49 +0100<br>=
From: Cheng Wang &lt;<a href=3D"mailto:cheng@alephium.org" target=3D"_blank=
">cheng@alephium.org</a>&gt;<br>To: <a href=3D"mailto:bitcoin-dev@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</=
a><br>Subject: [bitcoin-dev] Reducing energy consumption and increasing<br>=
<span style=3D"white-space:pre-wrap">	</span>security<span style=3D"white-s=
pace:pre-wrap">	</span>at the same time<br>Message-ID:<br><span style=3D"wh=
ite-space:pre-wrap">	</span>&lt;<a href=3D"mailto:CAJgZxF4G_BjJ=3DOhuzhjfZt=
kePnEc2hz8DMZzFzWKBNh17XhBeQ@mail.gmail.com" target=3D"_blank">CAJgZxF4G_Bj=
J=3DOhuzhjfZtkePnEc2hz8DMZzFzWKBNh17XhBeQ@mail.gmail.com</a>&gt;<br>Content=
-Type: text/plain; charset=3D&quot;utf-8&quot;<br><br>Hi Everyone,<br><br>I=
 would like to share my serious work on reducing the energy consumption of<=
br>PoW without sacrificing security. My new type of algorithm is called PoL=
W.<br>For a practical system where mining is profitable, PoLW could actuall=
y<br>improve the security of the system.<br><br>The idea is to shift part o=
f the external cost of mining in the physical<br>world (mainly energy consu=
mption) to the internal cost of the network. In<br>PoLW, the miners are abl=
e to give up part of the coinbase reward so as to<br>get weight (&gt; 1) fo=
r the block hash they produce. The total cost of<br>generating a new block =
would still be equal to maximal coinbase reward in<br>equilibrium.<br><br>I=
 analyzed two algorithms in the paper: linear PoLW and exponential PoLW.<br=
>Linear PoLW could reduce energy consumption by a factor close to 1/2 in<br=
>equilibrium, while exponential PoLW could reduce energy consumption by an<=
br>arbitrary factor in equilibrium.<br><br>In a practical system, mining is=
 usually (if not always) profitable. If we<br>transition from PoW to PoLW, =
the external costs of mining would decrease<br>and the internal costs will =
increase. However, the decrease in external<br>costs would be less than the=
 increase in internal costs since mining is<br>profitable. The total cost o=
f block generation would get higher, therefore,<br>the security will increa=
se.<br><br>Of course, we could not decrease the external costs of any exist=
ing system<br>by a factor close to zero immediately. There is a section in =
my paper<br>discussing this particularly. The principle of applying PoLW is=
 that<br>keeping the absolute external cost increasing all the time, but th=
e<br>percentage of external cost in the total cost gets lower eventually.<b=
r><br>This work is based on solid math calculation, and I am looking forwar=
d to<br>feedback and discussions. My paper is available at:<br><a href=3D"h=
ttps://github.com/alephium/research/raw/master/polw.pdf" target=3D"_blank">=
https://github.com/alephium/research/raw/master/polw.pdf</a><br><br>It&#39;=
s inspired by the recent great paper of Itay, Alexander, and Ittay:<br><a h=
ref=3D"https://arxiv.org/abs/1911.04124" target=3D"_blank">https://arxiv.or=
g/abs/1911.04124</a><br><br>Best,<br>Cheng Wang<br></div></div></blockquote=
></div><br></div></div></blockquote></div><br clear=3D"all"><div><br></div>=
-- <br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div><di=
v dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"=
ltr"><div dir=3D"ltr"><div>Cheng Wang</div><div># Love math and coding</div=
><div># Founder of Alephium; Proposed BlockFlow algorithm</div><div># Propo=
sed the first linear-time asynchronous Byzantine consensus algorithm<br></d=
iv></div></div></div></div></div></div></div></div></div></div></div>

--00000000000084f42f0599424ad9--