summaryrefslogtreecommitdiff
path: root/39/c211f9b2af251f34293efb383e07e808b6fb7b
blob: abfcd4ede2050fe01899f79e7eb59ec98b9b56d4 (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
Return-Path: <nullius@nym.zone>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 57304EDC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Jan 2018 00:11:00 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 02FA3124
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Jan 2018 00:10:58 +0000 (UTC)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mx2.mailbox.org (Postfix) with ESMTPS id 52C61411E0;
	Tue, 16 Jan 2018 01:10:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240])
	by hefe.heinlein-support.de (hefe.heinlein-support.de [91.198.250.172])
	(amavisd-new, port 10030)
	with ESMTP id Eyzw3xkiAw3D; Tue, 16 Jan 2018 01:10:53 +0100 (CET)
Date: Tue, 16 Jan 2018 00:10:38 +0000
From: nullius <nullius@nym.zone>
To: Enrique =?iso-8859-1?Q?Ariz=F3n?= Benito <enrique.arizonbenito@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <5e93f4b0e82ddf4eba5f1f54923e153f@nym.zone>
References: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="3kvnteadjxh7ktr3"
Content-Disposition: inline
In-Reply-To: <CAD-msxHyN+psv5p94_pUzNMFfZjMX4Jie2=PCt0CeO1cuuCz2A@mail.gmail.com>
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
X-Mailman-Approved-At: Tue, 16 Jan 2018 00:35:36 +0000
Subject: Re: [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: Tue, 16 Jan 2018 00:11:00 -0000


--3kvnteadjxh7ktr3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2018-01-15 at 22:47:54 +0000, Enrique Ariz=C3=B3n Benito=20
<enrique.arizonbenito@gmail.com> wrote:
>Hi all,
>
>just new to the list and curious to know if next proposal (or similar)=20
>for reducing mining-power consumption has already been discussed.
>
>The objective is to reduce the power consumption required while keeping=20
>the network safe and the miners "motivated" and cooperative to continue=20
>mining:
>
>The global idea is to introduce the concept of "next-coinbase" for=20
>miners. This will work something like as follow:
>
>- Any miner submitting a block will submit the "next-coinbase" for any=20
>new block mined by itself. (This address can be the same one or=20
>different from the just mined block). The miner keeps the private key=20
>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,=20
>will have to match up to N bits for the next "next-coinbase" from the=20
>next block to be valid.
>
> That means that for the next block only 1/2^N bitcoin addresses will=20
>be accepted from the previously submitted "next-coinbase" list.
>
>Since the last previous block hash can be considered random, miners=20
>know in advance whether they will be able to participate or not in the=20
>next block depending on the just submited "next-coinbase". And since=20
>the "punishment" is distributed uniformely random to all miners no one=20
>has any advantage over the other. But the global miner netwok will=20
>consume much less power.
>
>A detail rest: New miners are not allowed in such scheme so next=20
>addition is needed:
>
>- A miner with no previous "next-coinbase" will need to first mine an=20
>special block, "new-miner-block", that instead of normal transactions=20
>will register the new miner and submit a "next-coinbase". This special=20
>block will not be rewarded with new bitcoins. The only reward will be=20
>the permission to mine in following blocks. No reward is applied so=20
>only new miners wanting to "enter" the mining network are expected to=20
>create such block.

Observation:  This totally destroys Bitcoin=E2=80=99s transaction-ordering=
=20
security.  A =E2=80=9C51% attack=E2=80=9D could be executed by any miner wh=
o has >50% of=20
the hashpower *proportionate to miners who are allowed to mine a=20
particular block*, rather than >50% of *global* hashpower.  (I infer=20
that this could be done retroactively, and wave my hands over some of=20
the details since you did not talk about reorgs.)  The same applies as=20
for attacks requiring 33% or 25% of total hashpower.

Potential attack, assuming that N *must* be based partly or wholly on=20
the existing set of =E2=80=9Cnext-coinbase=E2=80=9D addresses:  A large min=
er could=20
gradually push N higher, by progressively committing new =E2=80=9Cnext-coin=
base=E2=80=9D=20
addresses which differ in the next bit for all previously seen=20
combinations of bits.  Large miners would have a vast advantage over=20
small miners, insofar as deliberately incrementing N by one more bit=20
could only be done by a miner who creates 2^(N+1) blocks (=3D 2 * 2^N). =20
By such means, it may be possible for a very large miner to eventually=20
lock out all other miners altogether, and monopolize all Bitcoin mining.

Now, questions:

How is N determined?  By a wave of the hands?

What part of which block hash is matched against N bits?  You were quite=20
unclear about this, and other important details.  (Much of what I say=20
here is based on assumptions and inferences necessary to fill in the=20
blanks.)

How, exactly, are reorgs handled?

How does this interact with the difficulty adjustment algorithm? =20
Indeed, how is difficulty determined at all under your scheme?

What happens to coinbase fees from a =E2=80=9Cnew-miner-block=E2=80=9D?  Th=
e way I read=20
your scheme, the =E2=80=9Cnew-miner-block=E2=80=9D must necessarily have no=
 payout=20
whatsoever.  But you discuss only =E2=80=9Cnew bitcoins=E2=80=9D, which are=
 a=20
diminishing portion of the block reward, and will eventually reach zero. =
=20
Coinbase from fees must go somewhere; but under your scheme, a =E2=80=9Cnew=
=20
miner=E2=80=9D has no payable address.

What if no existing =E2=80=9Cnext-coinbase=E2=80=9D address matches?  Is N =
constrained=20
to be sufficiently short that a match is guaranteed from the existing=20
set, then that makes it trivial for large mining farms to collect=20
addresses and further dominate (or even monopolize) the network in the=20
attack described above.  If it isn=E2=80=99t, then the network could sudden=
ly=20
halt when nobody is allowed to mine the next block; and that would=20
enable *this* attack:

What stops a malicious miner (including a =E2=80=9Cnew miner=E2=80=9D creat=
ing a=20
=E2=80=9Cnew-miner block=E2=80=9D) from deliberately working to create a bl=
ock with a=20
hash which does not have N bits matching any of the existing=20
=E2=80=9Cnext-coinbase=E2=80=9D addresses?  Contra what you say, block hash=
es can=E2=80=99t be=20
=E2=80=9Cconsidered random=E2=80=9D.  Indeed, partial preimage bruteforcing=
 of block=20
hashes is the entire basis of mining POW.

Asking here more generally than as for the attack described above, what=20
stops mining farms with large hashpower from submitting many different=20
=E2=80=9Cnext-coinbase=E2=80=9D addresses in many different blocks?  If N b=
e small, then=20
it should be feasible for a large mining farm to eventually register a=20
set of =E2=80=9Cnext-coinbase=E2=80=9D addresses which match any N.  **This=
 increases=20
mining centralization.**  If N be large, then this creates the=20
possibility (or raises the probability) that no address will match, and=20
nobody will be allowed to mine the next block.

How could miner anonymity be preserved under a scheme whereby each=20
=E2=80=9Cnext-coinbase=E2=80=9D address can be linked to a previous =E2=80=
=9Cnext-coinbase=E2=80=9D=20
address?  The only way to start fresh would be with a prohibitively=20
expensive no-payout block.  Mining can be totally anonymous at present,=20
and must so remain.  Miners are only identified by certain information=20
they choose to put in a block header, which they could choose to change=20
or omit=E2=80=94or by IP address, which is trivially changed and is never a=
=20
reliable identifier.

How does this even save electricity, when there is much mining equipment=20
(especially on large mining farms) which cannot be easily shut down and=20
restarted?  (Allegedly, this is one reason why some big miners=20
occasionally mine empty blocks.)  Though I suppose that difficulty would=20
drop by unspecified means.

Further observations:

This scheme drastically increases the upfront investment required for a=20
new miner to start mining.  To mine even one new block all by oneself,=20
without a pool, already requires a huge investment.  Add to that the=20
uncompensated energy cost of mining that first block with *no* payout,=20
and I expect that the bar would be prohibitive to almost all new=20
entrants.  Mining costs and incentives are delicately balanced by the=20
design of the network.  Whereas incumbents are much favoured by your=20
scheme, further increasing miner centralization.  Large incumbents could=20
also use this to produce a mining permissions market, by selling the=20
private keys to committed =E2=80=9Cnext-coinbase=E2=80=9D addresses.

I have not even tried to imagine what oddball attacks might be possible=20
for any miner with sufficient hashpower to deliberately cause a small=20
reorg.

--=20
nullius@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
=E2=80=9C=E2=80=98If you=E2=80=99re not doing anything wrong, you have noth=
ing to hide.=E2=80=99
No!  Because I do nothing wrong, I have nothing to show.=E2=80=9D =E2=80=94=
 nullius

--3kvnteadjxh7ktr3
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQSNOMR84IlYpr/EF5vEJ5MVn575SQUCWl1C/AAKCRDEJ5MVn575
STV+AQDr2NzDH1j3EEJCtIiWzkDDxIF+hX7XBwK47QImIjurnAEAitS6t0843n0H
vgj9yBkg2kF3zA9UUwd8CAJuO0oZSA4=
=mrcU
-----END PGP SIGNATURE-----

--3kvnteadjxh7ktr3--