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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1YsClq-0000qo-MX
for bitcoin-development@lists.sourceforge.net;
Tue, 12 May 2015 16:11:02 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.43 as permitted sender)
client-ip=209.85.215.43; envelope-from=gavinandresen@gmail.com;
helo=mail-la0-f43.google.com;
Received: from mail-la0-f43.google.com ([209.85.215.43])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YsClo-0002C7-Dm
for bitcoin-development@lists.sourceforge.net;
Tue, 12 May 2015 16:11:02 +0000
Received: by lagv1 with SMTP id v1so9660477lag.3
for <bitcoin-development@lists.sourceforge.net>;
Tue, 12 May 2015 09:10:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.97.202 with SMTP id ec10mr2567898lbb.4.1431447054031;
Tue, 12 May 2015 09:10:54 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Tue, 12 May 2015 09:10:53 -0700 (PDT)
In-Reply-To: <555210AF.3090705@electrum.org>
References: <5550D8BE.6070207@electrum.org>
<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
<5551F376.4050008@electrum.org>
<CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
<555210AF.3090705@electrum.org>
Date: Tue, 12 May 2015 12:10:53 -0400
Message-ID: <CABsx9T3AxM3et7hgXx3+Rn3BvhQkF-Cn797sHcyztkMpD1UQmA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Thomas Voegtlin <thomasv@electrum.org>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133b1c42ba2790515e4bd2d
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YsClo-0002C7-Dm
Subject: Re: [Bitcoin-development] Long-term mining incentives
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 16:11:02 -0000
--001a1133b1c42ba2790515e4bd2d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Added back the list, I didn't mean to reply privately:
Fair enough, I'll try to find time in the next month or three to write up
four plausible future scenarios for how mining incentives might work:
1) Fee-supported with very large blocks containing lots of tiny-fee
transactions
2) Proof-of-idle supported (I wish Tadge Dryja would publish his
proof-of-idle idea....)
3) Fees purely as transaction-spam-prevention measure, chain security via
alternative consensus algorithm (in this scenario there is very little
mining).
4) Fee supported with small blocks containing high-fee transactions moving
coins to/from sidechains.
Would that be helpful, or do you have some reason for thinking that we
should pick just one and focus all of our efforts on making that one
scenario happen?
I always think it is better, when possible, not to "bet on one horse."
On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin <thomasv@electrum.org>
wrote:
> Le 12/05/2015 15:44, Gavin Andresen a =C3=A9crit :
> > Ok, here's my scenario:
> >
> > https://blog.bitcoinfoundation.org/a-scalability-roadmap/
> >
> > It might be wrong. I welcome other people to present their road maps.
> >
>
> [answering to you only because you answered to me and not to the list;
> feel free to repost this to the list though]
>
> Yes, that's exactly the kind of roadmap I am asking for. But your blog
> post does not say anything about long term mining incentives, it only
> talks about scalability. My point is that we need the same kind of thing
> for miners incentives.
>
--=20
--
Gavin Andresen
--001a1133b1c42ba2790515e4bd2d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Added back the list, I didn't mean to reply priva=
tely:</div><div><br></div>Fair enough, I'll try to find time in the nex=
t month or three to write up four plausible future scenarios for how mining=
incentives might work:<div><br></div><div>1) Fee-supported with very large=
blocks containing lots of tiny-fee transactions</div><div>2) Proof-of-idle=
supported (I wish Tadge Dryja would publish his proof-of-idle idea....)</d=
iv><div>3) Fees purely as transaction-spam-prevention measure, chain securi=
ty via alternative consensus algorithm (in this scenario there is very litt=
le mining).</div><div>4) Fee supported with small blocks containing high-fe=
e transactions moving coins to/from sidechains.</div><div><br></div><div>Wo=
uld that be helpful, or do you have some reason for thinking that we should=
pick just one and focus all of our efforts on making that one scenario hap=
pen?</div><div><br></div><div>I always think it is better, when possible, n=
ot to "bet on one horse."</div><div><br></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Tue, May 12, 2015 at 10:39 AM, Th=
omas Voegtlin <span dir=3D"ltr"><<a href=3D"mailto:thomasv@electrum.org"=
target=3D"_blank">thomasv@electrum.org</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><span class=3D"">Le 12/05/2015 15:44, Gavin Andresen a=
=C3=A9crit :<br>
> Ok, here's my scenario:<br>
><br>
> <a href=3D"https://blog.bitcoinfoundation.org/a-scalability-roadmap/" =
target=3D"_blank">https://blog.bitcoinfoundation.org/a-scalability-roadmap/=
</a><br>
><br>
> It might be wrong. I welcome other people to present their road maps.<=
br>
><br>
<br>
</span>[answering to you only because you answered to me and not to the lis=
t;<br>
feel free to repost this to the list though]<br>
<br>
Yes, that's exactly the kind of roadmap I am asking for. But your blog<=
br>
post does not say anything about long term mining incentives, it only<br>
talks about scalability. My point is that we need the same kind of thing<br=
>
for miners incentives.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--001a1133b1c42ba2790515e4bd2d--
|
