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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Yr3On-00071F-In
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 11:58:29 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.169 as permitted sender)
client-ip=209.85.217.169; envelope-from=gavinandresen@gmail.com;
helo=mail-lb0-f169.google.com;
Received: from mail-lb0-f169.google.com ([209.85.217.169])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yr3Ol-0008WG-9B
for bitcoin-development@lists.sourceforge.net;
Sat, 09 May 2015 11:58:29 +0000
Received: by lbcga7 with SMTP id ga7so68502262lbc.1
for <bitcoin-development@lists.sourceforge.net>;
Sat, 09 May 2015 04:58:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.97.202 with SMTP id ec10mr1779755lbb.4.1431172700820;
Sat, 09 May 2015 04:58:20 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Sat, 9 May 2015 04:58:20 -0700 (PDT)
In-Reply-To: <CAAS2fgQRS7w7RRNXVK_+=4CQ7=AWxWQQ7+Tf4tNUPTTZOf7rEQ@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CAOG=w-szbLgc1jLpkE_uMa3bkFTi-RiBEaQ6Y-u5aKLBC2HvUg@mail.gmail.com>
<CAAS2fgQRS7w7RRNXVK_+=4CQ7=AWxWQQ7+Tf4tNUPTTZOf7rEQ@mail.gmail.com>
Date: Sat, 9 May 2015 07:58:20 -0400
Message-ID: <CABsx9T0Y84CSb-RohV1Cy=qYyFK0LYN0t-wbhkTt4wqhD5GpgQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133b1c471d9e80515a4dc1a
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: 1Yr3Ol-0008WG-9B
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
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: Sat, 09 May 2015 11:58:29 -0000
--001a1133b1c471d9e80515a4dc1a
Content-Type: text/plain; charset=UTF-8
RE: fixing sigop counting, and building in UTXO cost: great idea! One of
the problems with this debate is it is easy for great ideas get lost in all
the noise.
RE: a hard upper limit, with a dynamic limit under it:
I like that idea. Can we drill down on the hard upper limit?
There are lots of people who want a very high upper limit, right now (all
the big Bitcoin companies, and anybody who thinks as-rapid-as-possible
growth now is the best path to long-term success). This is the "it is OK if
you have to run full nodes in a data center" camp.
There are also lots of people who want an upper limit low enough that they
can continue to run Bitcoin on the hardware and Internet connection that
they have (or are concerned about centralization, so want to make sure
OTHER people can continue to run....).
Is there an upper limit "we" can choose to make both sets of people mostly
happy? I've proposed "must be inexpensive enough that a 'hobbyist' can
afford to run a full node" ...
Is the limit chosen once, now, via hard-fork, or should we expect multiple
hard-forks to change it "when necessary" ?
The economics change every time the block reward halves, which make me
think that might be a good time to adjust the hard upper limit. If we have
a hard upper limit and a lower dynamic limit, perhaps adjusting the hard
upper limit (up or down) to account for the block reward halving, based on
the dynamic limit....
RE: the lower dynamic limit algorithm: I REALLY like that idea.
--
--
Gavin Andresen
--001a1133b1c471d9e80515a4dc1a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">RE: fixing sigop counting, and building in UTXO cost: grea=
t idea! One of the problems with this debate is it is easy for great ideas =
get lost in all the noise.<div><br></div><div>RE: a hard upper limit, with =
a dynamic limit under it:</div><div><br></div><div>I like that idea. Can we=
drill down on the hard upper limit?</div><div><br></div><div>There are lot=
s of people who want a very high upper limit, right now (all the big Bitcoi=
n companies, and anybody who thinks as-rapid-as-possible growth now is the =
best path to long-term success). This is the "it is OK if you have to =
run full nodes in a data center" camp.</div><div><br></div><div>There =
are also lots of people who want an upper limit low enough that they can co=
ntinue to run Bitcoin on the hardware and Internet connection that they hav=
e (or are concerned about centralization, so want to make sure OTHER people=
can continue to run....).</div><div><br></div><div>Is there an upper limit=
"we" can choose to make both sets of people mostly happy? I'=
ve proposed "must be inexpensive enough that a 'hobbyist' can =
afford to run a full node" ...</div><div><br></div><div>Is the limit c=
hosen once, now, via hard-fork, or should we expect multiple hard-forks to =
change it "when necessary" ?</div><div><br></div><div>The economi=
cs change every time the block reward halves, which make me think that migh=
t be a good time to adjust the hard upper limit. If we have a hard upper li=
mit and a lower dynamic limit, perhaps adjusting the hard upper limit (up o=
r down) to account for the block reward halving, based on the dynamic limit=
....</div><div><br></div><div><br></div><div><br></div><div>RE: the lower d=
ynamic limit algorithm: =C2=A0I REALLY like that idea.</div><div><br></div>=
<div class=3D"gmail_extra">-- <br><div class=3D"gmail_signature">--<br>Gavi=
n Andresen<br></div>
</div></div>
--001a1133b1c471d9e80515a4dc1a--
|
