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
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5C531C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 15:08:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 3E74B61013
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 15:08:21 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.698
X-Spam-Level:
X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jvR_buSkTuOV
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 15:08:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com
[IPv6:2a00:1450:4864:20::532])
by smtp3.osuosl.org (Postfix) with ESMTPS id 0CFF06101D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 8 Oct 2021 15:08:19 +0000 (UTC)
Received: by mail-ed1-x532.google.com with SMTP id z20so37404303edc.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 08 Oct 2021 08:08:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=zOkIQuX+UGm2zanZyXOdRILv1wr2pa8ZoVqb07SVx8w=;
b=S4OrCw5YYHggu68smb9EHpcaqaoPIz48F7tHNp/r0TAFQt/pXWY59MtALEek4hDCaj
TbP4hLH+FWAC+KAlDOtOdbJflNjGD3b1KVR8yTkB+bgfUo22jyIow0PwrryC/w2SLZBo
+Fz64YxVjVFAjNuq7b4Z/H+QueL5mtYHDn1tv7Gm5qxpO1wY+1LCZWspSJJocKEAUDPk
j1bwwIMQHH75/3LlYdRu2LwSocnJyxqedIyI4RnfPMx8/g4VRNCcMNPzAnHUOZPm97tW
fEQRoQOb7UuNSk0nbrtMTGkfCmNAXWmeI/ex+clxPqt2k1vFwG4+79SvAuGt6VEbAiLX
4HWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=zOkIQuX+UGm2zanZyXOdRILv1wr2pa8ZoVqb07SVx8w=;
b=B/srzzcvNVfjI9r81iti5/3MJjFULhNUMpAD3tllKA3SNl7Mr1fjnbTef7a6/P739k
9cRnnLqbs/zSLN5a4chQXBZLmfNRoEUVKI+MgjbYgOSlEq1hTYG7WnHIezQwFQMI4210
0lIDW/ICx+4wKTAxpmBmmEC6aqU62RlHcyMViecP7qFbbt2NQQK6Ol1lPSozS4FChefL
8zYQmfCZj/WVFiVwlTM1tO3Q0OdbS08psvdNEjjdhIKdwMaRb0LRcYSbQ8NctAoQT+iD
iXo9h75pTwzpRb+8+ph4vUM0rzHKav1le00Mnod+4hm574ovlZP7WRH9AO5ygOUpIqHA
m2NA==
X-Gm-Message-State: AOAM531xy7rj1oLU1VraIZDmSok2b0XzfGFuPX0L7Yxfg824YVKRurwC
SoPlNvlmkF0jx/Lh8vr4lKMHIZkwwD4xEkQ9Tjp224n/Sl7bSw==
X-Google-Smtp-Source: ABdhPJybBGytB3MoVxW5DNa8LeKPpSSkM8n6GOqjb32pZf4UHBA6e4Hca3zHWkc2Nm6JtZheggE0IYyyXqqcwnIEnhE=
X-Received: by 2002:a05:6402:319a:: with SMTP id
di26mr16461826edb.84.1633705698101;
Fri, 08 Oct 2021 08:08:18 -0700 (PDT)
MIME-Version: 1.0
References: <f867f949-9a04-329b-ea1b-26201f46d2ab@nathanalexander.net>
<CAPv7TjZA2KYeVnT6PE6UHXwPy__E-VOvjmYD1207f1CgBRhLZg@mail.gmail.com>
In-Reply-To: <CAPv7TjZA2KYeVnT6PE6UHXwPy__E-VOvjmYD1207f1CgBRhLZg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 8 Oct 2021 11:08:02 -0400
Message-ID: <CAGpPWDax_Ht0H-Ct_SfaFF7AD-nUH-T1Sfo9+c7M6ptUK8ifzw@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cd8c4605cdd8bf88"
X-Mailman-Approved-At: Fri, 08 Oct 2021 19:20:25 +0000
Cc: Nathan T Alexander <nta@nathanalexander.net>
Subject: Re: [bitcoin-dev] Question- must every mining rig attempt every
block?
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: Fri, 08 Oct 2021 15:08:21 -0000
--000000000000cd8c4605cdd8bf88
Content-Type: text/plain; charset="UTF-8"
Proof of stake systems attempt to create red light - green light types of
things with non-gameable attributes (eg collaborative random numbers). This
can't be done with mining because mining is completely random - its not
possible to know which miner will mine a block. If it were, it wouldn't be
proof of work, but something else. What you describe sounds like proof of
identity, which isn't possible in a decentralized adversarial environment.
In fact, one of the primary achievements of the Proof of Work consensus
mechanism is to work around the Sybil issue, where (like ZmnSCPxj
mentioned) a single user can have many identities.
There can be hybrid systems that use both proof of work and proof of stake,
but my conclusion after having done a lot of research and thinking about it
([1]
<https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity>,
[2] <https://github.com/fresheneesz/proofOfTimeOwnership>) is that the
security mostly boils down to the weakest piece of the hybrid system, and
so its not very effective to have hybrid systems like you mentioned.
On Tue, Oct 5, 2021 at 10:43 AM Ruben Somsen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Nathan,
>
> That's a fair question, but note that we've already had a bunch of "green
> mining" related posts a few months ago, so I suspect you'll be able to find
> many criticisms to this idea in the following thread:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018937.html
>
> It also looks like you'll be able to find some related answers on Bitcoin
> Stack Exchange:
>
> https://bitcoin.stackexchange.com/questions/106308/decreasing-energy-consumption-of-bitcoins-pow-with-paired-mining-rounds
>
> And generally speaking these types of discussions don't end up being very
> fruitful for bitcoin-dev, because these are the types of changes that are
> unlikely to ever be seriously considered for Bitcoin.
>
> Cheers,
> Ruben
>
> On Tue, Oct 5, 2021 at 4:09 PM Nathan T Alexander via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> For purposes of conserving energy, couldn't each mining rig have some
>> non-gameable attribute which would be used to calculate if a block would
>> be accepted by that rig?
>>
>> Don't the mining rigs have to be able to identify themselves to the
>> network somehow, in order to claim their block reward? Could their
>> bitcoin network ID be used as a non-gameable attribute?
>>
>> Essentially a green light / red light system. In order for a block to be
>> accepted by the network, it must have all attributes of a successful
>> block today, and it must also have come from a rig that had a green light.
>>
>> Perhaps hash some data from the last successful block, along with the
>> miners non-gameable attribute, and if it's below a certain number set by
>> algorithm, the miner gets a green light to race to produce a valid block.
>>
>> Nathan Alexander
>>
>> Arlington, TX
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000cd8c4605cdd8bf88
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Proof of stake systems attempt to create red light - green=
light types of things with non-gameable attributes (eg collaborative rando=
m numbers). This can't be done with mining because mining is completely=
random - its not possible to know which miner will mine a block. If it wer=
e, it wouldn't be proof of work, but something else. What you describe =
sounds like proof of identity, which isn't possible in a decentralized =
adversarial environment. In fact, one of the primary achievements of the Pr=
oof of Work consensus mechanism is to work around the Sybil issue, where (l=
ike=C2=A0ZmnSCPxj mentioned) a single user can have many identities.=C2=A0<=
div><br></div><div>There can be hybrid systems that use both proof of work =
and proof of stake, but my conclusion after having done a lot of research a=
nd thinking about it (<a href=3D"https://github.com/fresheneesz/quantificat=
ionOfConsensusProtocolSecurity">[1]</a>, <a href=3D"https://github.com/fres=
heneesz/proofOfTimeOwnership">[2]</a>) is that the security mostly boils do=
wn to the weakest piece of the hybrid system, and so its not very effective=
to have hybrid systems like you mentioned.</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 5, 2021 at 10:=
43 AM Ruben Somsen via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
Hi Nathan,<div><br></div><div>That's a fair question, but note that we&=
#39;ve already had a bunch of "green mining" related posts a few =
months ago, so I suspect you'll be able to find many criticisms to this=
idea in the following thread:</div><div><br></div><div><a href=3D"https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018937.html" targe=
t=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-M=
ay/018937.html</a></div><div><br></div><div>It also looks like you'll b=
e able to find some related answers on Bitcoin Stack Exchange:</div><div><a=
href=3D"https://bitcoin.stackexchange.com/questions/106308/decreasing-ener=
gy-consumption-of-bitcoins-pow-with-paired-mining-rounds" target=3D"_blank"=
>https://bitcoin.stackexchange.com/questions/106308/decreasing-energy-consu=
mption-of-bitcoins-pow-with-paired-mining-rounds</a><br></div><div><br></di=
v><div>And generally speaking these types of discussions don't end up b=
eing very fruitful for bitcoin-dev, because these are the types of changes =
that are unlikely to ever be seriously considered for Bitcoin.</div><div><b=
r></div><div>Cheers,</div><div>Ruben</div></div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 5, 2021 at 4:09 PM Na=
than T Alexander via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">F=
or purposes of conserving energy, couldn't each mining rig have some <b=
r>
non-gameable attribute which would be used to calculate if a block would <b=
r>
be accepted by that rig?<br>
<br>
Don't the mining rigs have to be able to identify themselves to the <br=
>
network somehow, in order to claim their block reward? Could their <br>
bitcoin network ID be used as a non-gameable attribute?<br>
<br>
Essentially a green light / red light system. In order for a block to be <b=
r>
accepted by the network, it must have all attributes of a successful <br>
block today, and it must also have come from a rig that had a green light.<=
br>
<br>
Perhaps hash some data from the last successful block, along with the <br>
miners non-gameable attribute, and if it's below a certain number set b=
y <br>
algorithm, the miner gets a green light to race to produce a valid block.<b=
r>
<br>
Nathan Alexander<br>
<br>
Arlington, TX<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--000000000000cd8c4605cdd8bf88--
|