summaryrefslogtreecommitdiff
path: root/99/6c9601330575be31c87159ea29b6cbb7155b89
blob: 87bab47e8f44d33ac6b3871838f46f10460a011a (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
Return-Path: <dscotese@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DED77C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Mar 2020 18:39:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id C94B420380
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Mar 2020 18:39:21 +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 SQIz61twij-s
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Mar 2020 18:39:20 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com
 [209.85.208.45])
 by silver.osuosl.org (Postfix) with ESMTPS id 2D15E20349
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Mar 2020 18:39:20 +0000 (UTC)
Received: by mail-ed1-f45.google.com with SMTP id bd14so3623410edb.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 23 Mar 2020 11:39:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=e87WuEefDDJEBNHlG1ENaNM45+6lS1ZweFJ10twIXWg=;
 b=QbmdhR1ke/9QiYTLb5uyONIXX2oxwxznHx+1bZOtp57xH9c63SlehsS+fmdNrtasSl
 WFhyTHQMCLr2v5N+o4IBHDXGjn2HlUQkOLj1QOTD7N3VfVMnk+EV/W4uS/9OfEt1vYPI
 OWref6MdeAl6t6Q/LxdIKImP8b0vvsiLqQIW9TONRAH2HcHLWwNGQmoiZasXHdcz1lU0
 FhY8eKnXgKWd438XNdxH8+EqY/YBKdYqiDaXtH0delCxqIeKzRVPExQn7N5cbp88DjNC
 LwB+nJLHvfXMw/sst+RkBOwU0blQEzaQ4KQcyq8Fav8FzJg18p8kFXCe8mkKXCEJLo0R
 qNgg==
X-Gm-Message-State: ANhLgQ2IGj2gg1X4oV2+NEu2M4CKjsC5BZJONCJZuryME5tUYdZu/dOP
 q4obweechc8c8hYRPuqLy4rMkw9hzfCwMGDqi+zVUGVe
X-Google-Smtp-Source: ADFU+vsnxjyha96fx59uE96EatoNgxP9xgIKgGrQYIalxPZ5DPmy6ksSJ/8aY+w9MByHc1IPiiccGr4mY/j/22YZvos=
X-Received: by 2002:a17:906:1ba1:: with SMTP id
 r1mr21303481ejg.297.1584988758449; 
 Mon, 23 Mar 2020 11:39:18 -0700 (PDT)
MIME-Version: 1.0
References: <PS2P216MB0179EC99BDE0E3388F2627F89DF30@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
 <F713CAAC-1997-4645-A166-57358E520594@voskuil.org>
 <CAGLBAhdTMbZPwqV9YLMyHdNzLbN2DLjiOe6cBUbkwR_x4cGRmQ@mail.gmail.com>
 <20200323125922.GA29881@canndrew.org>
In-Reply-To: <20200323125922.GA29881@canndrew.org>
From: Dave Scotese <dscotese@litmocracy.com>
Date: Mon, 23 Mar 2020 11:39:05 -0700
Message-ID: <CAGLBAhcUgTEWnraFem0YwODc61B4nwbzddHJtE0D7ZCjUNWfYg@mail.gmail.com>
To: Andrew Cann <shum@canndrew.org>
Content-Type: multipart/alternative; boundary="000000000000eba2f405a189f355"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 18:39:22 -0000

--000000000000eba2f405a189f355
Content-Type: text/plain; charset="UTF-8"

I believe this isn't something we need to address.  The fact is that every
byte stored in the blockchain is already valuable to everyone who downloads
the blockchain because of what it allows them to prove - by adding more
bytes to it.  Over time, the value per byte will increase.  Perhaps there
will be holding companies with specialized scripts that cost $500 - $1000
to add to the blockchain and allow those companies to handle transactions
for thousands of customers, kind of like a community lightning channel.

Anyway, yes, your idea is fundamentally broken because a zero block reward
happens because creating even one more satoshi will push the amount of
bitcoin over 21,000,0000, breaking the meaning of "bitcoin," or, if you
like, creating a fundamental contradiction in our use of the term.

On Mon, Mar 23, 2020 at 5:59 AM Andrew Cann <shum@canndrew.org> wrote:

> 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
>
>

-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

--000000000000eba2f405a189f355
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I believe this isn&#39;t something we need to address.=C2=
=A0 The fact is that every byte stored in the blockchain is already valuabl=
e to everyone who downloads the blockchain because of what it allows them t=
o prove - by adding more bytes to it.=C2=A0 Over time, the value per byte w=
ill increase.=C2=A0 Perhaps there will be holding companies with specialize=
d scripts that cost $500 - $1000 to add to the blockchain and allow those c=
ompanies to handle transactions for thousands of customers, kind of like a =
community lightning channel.<div><br></div><div>Anyway, yes, your idea is f=
undamentally broken because a zero block reward happens because creating ev=
en one more satoshi will push the amount of bitcoin over 21,000,0000, break=
ing the meaning of &quot;bitcoin,&quot; or, if you like, creating a fundame=
ntal contradiction in our use of the term.</div></div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 23, 2020 at 5:5=
9 AM Andrew Cann &lt;<a href=3D"mailto:shum@canndrew.org">shum@canndrew.org=
</a>&gt; wrote:<br></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">=
Hi, noob question here: Is there a long-term plan for if the block reward d=
rops<br>
too low to ensure the security of the network?<br>
<br>
IIUC miners only make profit from block rewards and transaction fees, and o=
nce<br>
the block reward drop to zero we&#39;re merely hoping that transaction fees=
 will<br>
keep mining expensive enough to stop a state actor or someone from buying<b=
r>
enough hash power to attack the network. If that&#39;s the case, should we =
start<br>
making plans now to change the protocol to allow an adjustable block reward=
?<br>
<br>
Here&#39;s a half-baked idea I had of how that could work: Since the block =
reward<br>
dilutes the value of the currency bitcoin holders have an incentive to keep=
 the<br>
reward low. However, since the block reward is also (partly) what incentivi=
zes<br>
mining, bitcoin holders also have an incentive to keep the reward high enou=
gh<br>
to keep the network secure. So if bitcoin holders were able to vote to deci=
de<br>
the block reward they &quot;should&quot;, hypothetically, reliably choose a=
 value that<br>
balances these two concerns. You could implement this voting by adding an<b=
r>
optional extra field to every txout that signals what the holder thinks the=
<br>
inflation rate should be. If the field is missing you just assume the defau=
lt<br>
value based on the current protocol. Then, whenever a new block is mined, y=
ou<br>
take the median inflation rate of all the pre-existing utxos, weighted by t=
he<br>
utxo value, to calculate the block&#39;s reward.<br>
<br>
Is this idea fundamentally broken somehow? Or are there already better idea=
s<br>
for how to tackle this problem (I don&#39;t follow this list very closely)?=
 Or is<br>
this actually a non-issue to start with?<br>
<br>
=C2=A0- Andrew<br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr">I like to provide some work at =
no charge to prove my value. Do you need a techie?=C2=A0 <br>I own <a href=
=3D"http://www.litmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=
=3D"http://www.memeracing.net" target=3D"_blank">Meme Racing</a> (in alpha)=
. <br>I&#39;m the webmaster for <a href=3D"http://www.voluntaryist.com" tar=
get=3D"_blank">The Voluntaryist</a> which now accepts Bitcoin.<br>I also co=
de for <a href=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar=
 Vigilante</a>.<br>&quot;He ought to find it more profitable to play by the=
 rules&quot; - Satoshi Nakamoto</div></div>

--000000000000eba2f405a189f355--