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
|
Return-Path: <luke@dashjr.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id D77A8C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 02:58:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id BFFBD401D6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 02:58:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level:
X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=dashjr.org
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id aTsZWEvrarak
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 02:58:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
by smtp4.osuosl.org (Postfix) with ESMTP id 82A7B401D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 17 May 2021 02:58:54 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.190.236.203])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id D280638A001F;
Mon, 17 May 2021 02:58:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1621220332; bh=nPMt9oTnajV5R7ofVTTeQcsi89N28NvpXFQbfM6b7NQ=;
h=From:To:Subject:Date:References:In-Reply-To;
b=VH5sj/oKIAB+kb1bO8FsD6/kZhaK1F84KVrVAjnlCvL/Uyzra6+1unc1yCpstFW2F
y2c3b4l0bTqwOaZkXxSsbkWC1ZrRN2VQQPACoBTKO2lY9fl73uDM5frG5Ocx9PMexc
6P0qUehLa+TNDPSjOHH6Kg9Mnd98uC/ry0dgP6eo=
X-Hashcash: 1:25:210517:fuhmic@web.de::gdk0R3ywuG9ADHsb:aoqH
X-Hashcash: 1:25:210517:bitcoin-dev@lists.linuxfoundation.org::mjnanh2WA0idcRf3:b4Hvc
X-Hashcash: 1:25:210517:gmkarl@gmail.com::N3zhZ3Xctoglgw23:aIY1s
X-Hashcash: 1:25:210517:anton@etc-group.com::VwfheQP7iLUA=1pg:aC5rW
From: Luke Dashjr <luke@dashjr.org>
To: Michael Fuhrmann <fuhmic@web.de>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Karl <gmkarl@gmail.com>, Anton Ragin <anton@etc-group.com>
Date: Mon, 17 May 2021 02:58:12 +0000
User-Agent: KMail/1.9.10
References: <d35dee03-2d19-e80a-c577-2151938f9203@web.de>
In-Reply-To: <d35dee03-2d19-e80a-c577-2151938f9203@web.de>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202105170258.13233.luke@dashjr.org>
Subject: Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes
to save 90% of mining energy
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, 17 May 2021 02:58:56 -0000
On Friday 14 May 2021 21:41:23 Michael Fuhrmann via bitcoin-dev wrote:
> Bitcoin should create blocks every 10 minutes in average. So why do
> miners need to mine the 9 minutes after the last block was found? It's
> not necessary.
It increases security, and is unavoidable anyway.
> Problem: How to prevent "pre-mining" in the 9 minutes time window?
You can't.
> Possible ideas for discussion:
>
> - (maybe most difficult) global network timer sending a salted hash time
> code after 9 minutes. this enables validation by nodes.
PoW *is* the global network timer.
> - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just
> high enough) times higher difficulty. so everyone can mine any time but
> before to 9 minutes are up there will be a too high downside. It is more
> efficient to wait then paying high bills. The bitcoin will get a "puls".
There's no timestamp at this stage of consensus.
On Sunday 16 May 2021 18:10:12 Karl via bitcoin-dev wrote:
> The clock might be implementable on a peer network level by requiring
> inclusion of a transaction that was broadcast after a 9 minute delay.
That requires a centralised authority.
On Sunday 16 May 2021 20:31:47 Anton Ragin via bitcoin-dev wrote:
> 1. Has anyone considered that it might be technically not possible to
> completely 'power down' mining rigs during this 'cool-down' period of time?
> While modern CPUs have power-saving modes, I am not sure about ASICs used
> for mining.
That would be miners' problem, not the network's... New ASICs would no doubt
be made to work more efficiently.
> 2. I am not a huge data-center specialist, but it was my understanding that
> they charge per unit of installed (maximum) electricity consumption. It
> would mean that if the miner needs X kilowatts-hour within that 1 minute
> when they are allowed to mine, he/she will have to pay for the same X for
> the remaining 9 minutes - and as such would have no economic incentive not
> to draw that power when idling.
Actually, this would be a good thing: it would heavily discourage datacentre
use (which is very harmful to mining decentralisation).
> 4. My counter-proposal to the community to address energy consumption
> problems would be *to encourage users to allow only 'green miners' process
> their transaction.* In particular:
>...
> (b) Should there be some non-profit organization(s) certifying green miners
> and giving them cryptographic certificates of conformity (either usage of
> green energy or purchase of offsets), users could encrypt their
> transactions and submit to mempool in such a format that *only green miners
> would be able to decrypt and process them*.
Hello centralisation. Might as well just have someone sign miner keys, and get
rid of PoW entirely...
|
