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
|
Return-Path: <gmkarl@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B2D35C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 May 2021 18:10:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 89088838FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 May 2021 18:10:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xRBVUs1NtsCf
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 May 2021 18:10:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com
[IPv6:2a00:1450:4864:20::133])
by smtp1.osuosl.org (Postfix) with ESMTPS id C1999838F0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 May 2021 18:10:16 +0000 (UTC)
Received: by mail-lf1-x133.google.com with SMTP id a2so5446604lfc.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 May 2021 11:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-transfer-encoding;
bh=EFBN0voS1iVbq80rCfjlMev/+GraYastXccDC2rJ7uM=;
b=BFNA1Med8bKMXUbDtYtQLeEnM9n6SnRHp8SPn/k+oA64PmMm5d9PffGR1g6P/yiWRd
MLosIu5s7sNfINzBnDDKUX+7eb64ApJ6kkVVFkAk0jNgmlmATZ/5dksviHl7zBnu7x+c
8/7tHFF1AAJqsQ1Z/A0Ei0lESMMXAJyczSB0wfunMzSuvGFaKt+13U+gGTirv7Fmqwba
8V35VaDdioKCHKADDt7QUwQNnYzlsPpVUhvzPm6q3oWXHijxH+Ni11c1ST1hibK9t9sJ
xkbM3ebES7fZFVfHQeTCGOYLTbL7bdomgZgHfOeC3yVGaCFM9Ra7QOVg78vwIAieqfbI
6+eQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:content-transfer-encoding;
bh=EFBN0voS1iVbq80rCfjlMev/+GraYastXccDC2rJ7uM=;
b=ACYvO2SvQgI1sSnMUsNBF5JyPeu0RNLuXXLFkL5a43ejA57hPBhQtdOTBZiBlFIYQ7
Q7uVVIKkso52/8am/4c+liwbQmKdsQ2QI5OIoQ+TQNODyxmhNjOGrzDyzulQK9H0+sLO
LET2282e/lM6VOM08HpE68QspVdEB24Xa6flk1PssBrK3va8H2ZHYWMXfcvF9EfJUCeR
CBG7/60AMNmnXYKfmibdBHTVAWGDeTIMdjMOvvy6GYzeiO8L/VmEG1lrM3hgCwl4p5RJ
ysIqlbC26KUKsFRlrwFrVMIqGSNGjo9MhPZi/Ym6Zf4bfwN3oaGp7VivhKSyKr5xEhh8
kmZw==
X-Gm-Message-State: AOAM533EtRKqVvQkxN/gMJ5xKCPtwl1QzYjlqUpdzmIpwWp13W8BprjM
QsvS3v7ELUgvNIJSVc5qt8ib1r9frx3exaJJd9FMn5MD
X-Google-Smtp-Source: ABdhPJz923o5r8xhBJApmQgECrzUtWSy3fuZQcgy00t5sUKFN3rVhWTGD2WEbx6hE34nVKnQVH0LcQUqyKq5ESSIAHg=
X-Received: by 2002:a05:6512:3592:: with SMTP id
m18mr5235117lfr.454.1621188614111;
Sun, 16 May 2021 11:10:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a05:651c:2109:0:0:0:0 with HTTP; Sun, 16 May 2021 11:10:12
-0700 (PDT)
In-Reply-To: <d35dee03-2d19-e80a-c577-2151938f9203@web.de>
References: <d35dee03-2d19-e80a-c577-2151938f9203@web.de>
From: Karl <gmkarl@gmail.com>
Date: Sun, 16 May 2021 14:10:12 -0400
Message-ID: <CALL-=e45Q_spVnFqVvGAK9c3QzZ=-c_WNwCO-y30q7z-j6orSA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 16 May 2021 19:02:14 +0000
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: Sun, 16 May 2021 18:10:17 -0000
[sorry if I haven't replied to the other thread on this, I get swamped
by email and don't catch them all]
This solution is workable but it seems somewhat difficult to me at this tim=
e.
The clock might be implementable on a peer network level by requiring
inclusion of a transaction that was broadcast after a 9 minute delay.
Usually a 50% hashrate attack is needed to reverse a transaction in
bitcoin. With this change, this naively appears to become a 5%
hashrate attack, unless a second source of truth around time and order
is added, to verify proposed histories with.
A 5% hashrate attack is much harder here, because the users of mining
pools would be mining only 10% of the time, so compromising mining
pools would not be as useful.
Historically, hashrate has increased exponentially. This means that
the difficulty of performing an attack, whether it is 5% or 50%, is
still culturally infeasible because it is a multiplicative, rather
than an exponential, change.
If this approach were to be implemented, it could be important to
consider how many block confirmations people wait for to trust their
transaction is on the chain. A lone powerful miner could
intentionally fork the chain more easily by a factor of 10. They
would need to have hashrate that competes with a major pool to do so.
> How would you prevent miners to already compute the simpler difficulty pr=
oblem directly after the block was found and publish their solution directl=
y after minute 9? We would always have many people with a finished / compet=
ing solution.
Such a chain would have to wait a longer time to add further blocks
and would permanently be shorter.
> Your proposal won=E2=80=99t save any energy because it does nothing to de=
crease the budget available to mine a block (being the block reward).
You are assuming this budget is directly related to energy
expenditure, but if energy is only expended for 10% of the same
duration, this money must now be spent on hardware. The supply of
bitcoin hardware is limited.
In the long term, it won't be, so a 10% decrease is a stop-gap
measure. Additionally, in the long term, we will have quantum
computers and AI-designed cryptography algorithms, so things will be
different in a lot of other ways too.
|
