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
|
Return-Path: <shum@canndrew.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 00970C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 13:21:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id E3494204A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 13:21:02 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id dgIccIyNqybJ
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 13:21:01 +0000 (UTC)
X-Greylist: delayed 00:21:36 by SQLgrey-1.7.6
Received: from canndrew.org (canndrew.org [199.167.29.165])
by silver.osuosl.org (Postfix) with ESMTPS id 62F2020337
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 13:21:01 +0000 (UTC)
Received: from shum by canndrew.org with local (Exim 4.84_2)
(envelope-from <shum@canndrew.org>)
id 1jGMfq-00084L-JD; Mon, 23 Mar 2020 08:59:22 -0400
Date: Mon, 23 Mar 2020 08:59:22 -0400
From: Andrew Cann <shum@canndrew.org>
To: Dave Scotese <dscotese@litmocracy.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200323125922.GA29881@canndrew.org>
References: <PS2P216MB0179EC99BDE0E3388F2627F89DF30@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
<F713CAAC-1997-4645-A166-57358E520594@voskuil.org>
<CAGLBAhdTMbZPwqV9YLMyHdNzLbN2DLjiOe6cBUbkwR_x4cGRmQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+"
Content-Disposition: inline
In-Reply-To: <CAGLBAhdTMbZPwqV9YLMyHdNzLbN2DLjiOe6cBUbkwR_x4cGRmQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Thu, 26 Mar 2020 04:32:22 +0000
Subject: Re: [bitcoin-dev] Block solving slowdown question/poll
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, 23 Mar 2020 13:21:03 -0000
--mYCpIKhGyMATD0i+
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Hi, noob question here: Is there a long-term plan for if the block reward drops
too low to ensure the security of the network?
IIUC miners only make profit from block rewards and transaction fees, and once
the block reward drop to zero we're merely hoping that transaction fees will
keep mining expensive enough to stop a state actor or someone from buying
enough hash power to attack the network. If that's the case, should we start
making plans now to change the protocol to allow an adjustable block reward?
Here's a half-baked idea I had of how that could work: Since the block reward
dilutes the value of the currency bitcoin holders have an incentive to keep the
reward low. However, since the block reward is also (partly) what incentivizes
mining, bitcoin holders also have an incentive to keep the reward high enough
to keep the network secure. So if bitcoin holders were able to vote to decide
the block reward they "should", hypothetically, reliably choose a value that
balances these two concerns. You could implement this voting by adding an
optional extra field to every txout that signals what the holder thinks the
inflation rate should be. If the field is missing you just assume the default
value based on the current protocol. Then, whenever a new block is mined, you
take the median inflation rate of all the pre-existing utxos, weighted by the
utxo value, to calculate the block's reward.
Is this idea fundamentally broken somehow? Or are there already better ideas
for how to tackle this problem (I don't follow this list very closely)? Or is
this actually a non-issue to start with?
- Andrew
--mYCpIKhGyMATD0i+
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJeeLKqAAoJEJQq94U5BTTONZEQAKaa+1oOsGDAoyMSrfeSWpAQ
Nl/vd0W2ykPrINhq7XpLZJhRpYpZDWnOV/d5C327QuYM0kUduVz2d8C/5KWv1gj/
8nsONKbdJyOSdTItGPnVs3GKWWUgPr7zL5YH29SnoHQNBWFEODOFZ6fZbJnWKi/g
0kBX2UwfcS8TE+ETeMePcBTpfPDOOv93QiLXQluE/Gb97XRTlON26DiJQLIRWhDZ
CASQSs1YXtYlMtwb/hOV1fOQ17eMEvnnImWG3vlKezmXIJSUhQy4BDyC3XO2p9LI
aKssXNS12NiLYz6lu+dO2/hw8fc+i+BWuhtXE1hvwy1YLhJF76VT3v1uwOJIsHS2
njSOlnAz6izDKchWK//606dwbUZFKKlrt4bIv18vz8dZPc1I5e2i8djlBlkZ1VlK
pjhgJ8RezJ1HkCxlB0V00eoa7FZZ7Fy3pzs+T4XE2vF653C8dxSjAdzL+eT/ZmN9
0SqDU6sfrCvZLJ11UYMrQ9Y2N2dqWhJNSs7X/xfvKMNcDSXk4TXyIjDGGos3tmhs
rxubX9dMNwLZXw3wKl7NSpG8Q5a3oqyOP61bPJkHe8JnN3hZQT23MO371pu0lc9L
7IzoX2NGJP60kpByuGvv/sNVezGBfkS5BAgsS9NPgEF/PtZ2qiaYv81yo6jQgzVf
RWZ2toLnuj01MM9sFt7p
=wAaC
-----END PGP SIGNATURE-----
--mYCpIKhGyMATD0i+--
|
