summaryrefslogtreecommitdiff
path: root/e5/7a6246d9dffb73277f8e397808916bf9bc4c72
blob: 0f8d6e5d928dee6f4f634e09a4c9f33e5322a7a6 (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
Return-Path: <enrique.arizonbenito@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 053C91177
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 15 Jan 2018 22:47:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com
	[209.85.214.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 937FC47C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 15 Jan 2018 22:47:55 +0000 (UTC)
Received: by mail-it0-f51.google.com with SMTP id 196so2612087iti.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 15 Jan 2018 14:47:55 -0800 (PST)
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=TcVe8fTxnpSnNS9csuIliaU77Z/6HNLjSl3tcWTXoWk=;
	b=FthVwRgvZGe2SofyGCo93Ss88X/9kZplKhdtrzhqox+RB+McukMenctVHpmp73Gv3b
	aAp/zOB6GWpUtVOq/00TE1IxOwUy4vYV+xjbSS+2nHmRLhSX9zb9WznL5O8THNbf9FJR
	owVbijyLp4q+/wBp8O3uDs41BrZAOBQxayniosDH4RRp3HuScC8pAwLxJgUUbdGf38Ab
	XL64v5FDGKXyQIVohenpMx4LLWfD+bLP8ItmKFXovMs0l5h0IxM2QCyCR2EyVLwFuMq+
	uKeg6kJm71/G7SJd6VVGBMlR42cgabawgVyHislF8k2pN1DHWsNTJddOZo0SW64ulcNk
	rrQQ==
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=TcVe8fTxnpSnNS9csuIliaU77Z/6HNLjSl3tcWTXoWk=;
	b=BWl9DMqt3t3a7UR23QbiH/TdtTtYUWR40BSa/SunXAKG7ksQG04jAzsmpiQJ809TDu
	2VMjFCWhJsRqzBQt9ZOmHn/r2uptnPfyM7MRTnMfS7BJaYX+SLUu76UDqOxasmXOuJ1c
	gxk7hX6yAwQLf/xmQWt31VjAo07bjcVqZ9c+QDQiaiUWgN68oOfZkkkbj37X4367fQeS
	zz6AAMZSvsITwOqrOCEOOQT0BGahLW2nNb3oNGOjiDNLKQHCLqM8GyCfBPuyUyZkkwau
	6qSsjGGCSm1fEYY9YWkFiArdTs/6TMO/5WYfeFCMQo1wyNoCPKpgV/Wb6Qdeaj4M64oa
	AsAA==
X-Gm-Message-State: AKwxyteQqPX4FoRLkeZC0tIvDGihlYUzEtUE/3DGRkhHHYnURTMyGecT
	yH653HvdEUUqyl+kcoSUmd0/uIZ4z2xMlT2D+sDutQ==
X-Google-Smtp-Source: ACJfBosQYfQtJKjwr14KijJpVJgCfeyd/52o/expOX9JpegnC0e8Jy6Chta1wumh060cJZJVgHQfyLrGqUODO7buyhQ=
X-Received: by 10.36.104.210 with SMTP id v201mr14776611itb.64.1516056474725; 
	Mon, 15 Jan 2018 14:47:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.73.69 with HTTP; Mon, 15 Jan 2018 14:47:54 -0800 (PST)
From: =?UTF-8?Q?Enrique_Ariz=C3=B3n_Benito?= <enrique.arizonbenito@gmail.com>
Date: Mon, 15 Jan 2018 23:47:54 +0100
Message-ID: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a1143ab62a2b2520562d8670d"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 15 Jan 2018 22:49:44 +0000
Subject: [bitcoin-dev] Proposal to reduce mining power bill
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, 15 Jan 2018 22:47:56 -0000

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

Hi all,

just new to the list and curious to know if next proposal (or similar) for
reducing mining-power consumption has already been discussed.

The objective is to reduce the power consumption required while keeping the
network safe and the miners "motivated" and cooperative to continue mining:

The global idea is to introduce the concept of "next-coinbase" for miners.
This will work something like as follow:

- Any miner submitting a block will submit the "next-coinbase" for any new
block mined by itself. (This address can be the same one or different from
the just mined block). The miner keeps the private key associated with the
"next-coinbase" secret.

- The consensus algorithm will add next checks:
 A hash from, for example, the just mined block and the previous one, will
have to match up to N bits for the next "next-coinbase" from the next block
to be valid.

 That means that for the next block only 1/2^N bitcoin addresses will be
accepted from the previously submitted "next-coinbase" list.

Since the last previous block hash can be considered random, miners know in
advance whether they will be able to participate or not in the next block
depending on the just submited "next-coinbase". And since the "punishment"
is distributed uniformely random to all miners no one has any advantage
over the other. But the global miner netwok will consume much less power.

A detail rest: New miners are not allowed in such scheme so next addition
is needed:

- A miner with no previous "next-coinbase" will need to first mine an
special block, "new-miner-block", that instead of normal transactions will
register the new miner and submit a "next-coinbase". This special block
will not be rewarded with new bitcoins. The only reward will be the
permission to mine in following blocks. No reward is applied so only new
miners wanting to "enter" the mining network are expected to create such
block.

Best Regards,

E. Ariz=C3=B3n Benito

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

<div dir=3D"ltr"><div></div><div>Hi all,</div><div><br></div><div>just new =
to the list and curious to know if next proposal (or similar) for reducing =
mining-power consumption has already been discussed.</div><div><br></div><d=
iv>The objective is to reduce the power consumption required while keeping =
the network safe and the miners &quot;motivated&quot; and cooperative to co=
ntinue mining:<br></div><div><br></div><div>The global idea is to introduce=
 the concept of &quot;next-coinbase&quot; for miners. This will work someth=
ing like as follow:<br></div><div><br></div><div></div><div>- Any miner sub=
mitting a block will submit the &quot;next-coinbase&quot; for any new block=
 mined by itself. (This address can be the same one or different from the j=
ust mined block). The miner keeps the private key associated with the &quot=
;next-coinbase&quot; secret.<br></div><div><br></div><div></div><div>- The =
consensus algorithm will add next checks:<br></div><div>=C2=A0A hash from, =
for example, the just mined block and the previous one, will have to match =
up to N bits for the next &quot;next-coinbase&quot; from the next block to =
be valid. <br></div><div><br></div><div>=C2=A0That means that for the next =
block only 1/2^N bitcoin addresses will be accepted from the previously sub=
mitted &quot;next-coinbase&quot; list.</div><div><br></div><div>Since the l=
ast previous block hash can be considered random, miners know
 in advance whether they will be able to participate or not in the next blo=
ck depending on the just submited &quot;next-coinbase&quot;. And since the =
&quot;punishment&quot; is distributed uniformely random to all miners no on=
e has any advantage over the other. But the global miner netwok will consum=
e much less power. <br></div><div><br></div><div>A detail rest: New miners =
are not allowed in such scheme so next addition is needed:<br><br></div><di=
v>- A miner with no previous &quot;next-coinbase&quot; will need to first m=
ine an special block, &quot;new-miner-block&quot;, that instead of normal t=
ransactions will register the new miner and submit a &quot;next-coinbase&qu=
ot;. This special block will not be rewarded with new bitcoins. The only re=
ward will be the permission to mine in following blocks. No reward is appli=
ed so only new miners wanting to &quot;enter&quot; the mining network are e=
xpected to create such block.</div><div><br></div><div>Best Regards,</div><=
div><br></div><div>E. Ariz=C3=B3n Benito</div><br></div>

--001a1143ab62a2b2520562d8670d--