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
|
Return-Path: <anthony.j.towns@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 33B1F409
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 15:44:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com
[209.85.212.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35226102
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 15:44:44 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so53283282wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 08:44:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=IJPibZLq3mUtqt8/3zeWDDOrRLsx7bhR3qmbpabMBsY=;
b=Z74j2W48aCibAKo7VAHnuaIgLB/M+3JcDUZ/K8ROiOGZys2MGIhRVX2duqN/+LE+ET
meitLDI5Bn4tz3Mw8oOgVinxCv5JWZh+UceVPodngsi6u5M/HcQcbsHt1ROb7r10JIvH
mjF3s3HJLTVziV1ZjIfNbryDthvPXGuoQBtiC5sXHMq4UyxWTdaIkqbOmTPKlrrK4R/0
S2+2I0+NxLiSwZqgcCQwMZRrUCy10f/ehtoCOl7hRyRfn9nI8NNk45heGlxxAgP8QIV6
Sheml0uKR09DTDDDc49WhqpWnz72ne71UNlEQrqkKyd27stbOAyJ7Q2quuBDMuMptFfT
QOzA==
MIME-Version: 1.0
X-Received: by 10.180.231.40 with SMTP id td8mr26802589wic.9.1439739882805;
Sun, 16 Aug 2015 08:44:42 -0700 (PDT)
Sender: anthony.j.towns@gmail.com
Received: by 10.28.176.69 with HTTP; Sun, 16 Aug 2015 08:44:42 -0700 (PDT)
In-Reply-To: <CA+w+GKQ_RnKULgCfvWJ_MyAKLAz9JMBizidDFhT5e6DB_Fvb_Q@mail.gmail.com>
References: <CA+w+GKT7t5OahS-+P=QAmOyFzPnOs4J6KSo+mhSrC0YggmMupg@mail.gmail.com>
<E7866FD5-9CEC-400F-8270-407499E0B012@gmail.com>
<CA+w+GKQ_RnKULgCfvWJ_MyAKLAz9JMBizidDFhT5e6DB_Fvb_Q@mail.gmail.com>
Date: Sun, 16 Aug 2015 17:44:42 +0200
X-Google-Sender-Auth: OwbIr4fMAaa4BPAJ94B-9GkLKrk
Message-ID: <CAJS_LCW+Q69+tXya+QsMj7jWM9H=LypFAOsDBgsNO6nYkTNErw@mail.gmail.com>
From: Anthony Towns <aj@erisian.com.au>
To: Mike Hearn <hearn@vinumeris.com>
Content-Type: multipart/alternative; boundary=001a1134cc5048a06e051d6f9097
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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 Aug 2015 15:44:45 -0000
--001a1134cc5048a06e051d6f9097
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Sorry you feel that way. I devoted a big part of the article to trying to
> fairly represent the top 3 arguments made, but ultimately I can't link to=
a
> clear statement of what Bitcoin Core thinks because there isn't one. Some
> people think the block size should increase, but not now, or not by much.
> Others think it should stay at 1mb forever, others think everyone should
> migrate to Lightning, people who are actually *implementing* Lightning
> think it's not a replacement for an increase ..... I think one or two
> people even suggested shrinking the block size!
>
=E2=80=8BThat's been really unclear to me. Personally, I'd love to see a vo=
te from
the core and XT developers on:
- what should the block size soft limit be in 12 months (min and max)
- what should the block size hard limit be in 12 months (min and max)
- at what rate should the hard limit grow over the next 10 years=E2=80=8B =
(min and
max)
- what mechanism should be used to update the soft limit
(manual code change, time based, blockchain history, something else)
=E2=80=8B - what me=E2=80=8Bchanism should be used to update the hard limit
(hard fork code change, time based, blockchain history, something else)
Bonus:
=E2=80=8B - what should the
=E2=80=8Btransaction =E2=80=8B
fee level be in 12 months (after the reward halves)?=E2=80=8B
- what's a good measure of "(de)centralisation" and what value should
everyone aim for in 12 months?
As an interested newbie, I can't actually tell what most people think the
answers to most of those questions are. FWIW, mine would be:
- soft limit in 12 months: 1MB-4MB
- hard limit in 12 months: 2MB-20MB
- hard limit grows at 17-40% a year (and should be >4x average txn volume)
- update the soft limit by code changes or blockchain history
- update the hardlimit by (1) fee level, (2) miner vote, (3) hard coded
time updates at a conservative (low) rate, (4) hard fork every couple of
years
- transaction fees should in 12months should be lower per kB than today's
defaults, say 20%-50% of today's defaults in USD
- number of bitcoin nodes, should be 20% higher in 12 months than it is no=
w
=E2=80=8BCheers,
aj
--=20
Anthony Towns <aj@erisian.com.au>
--001a1134cc5048a06e051d6f9097
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e"><span style=3D"font-family:arial,sans-serif">On 16 August 2015 at 15:49,=
Mike Hearn via bitcoin-dev </span><span dir=3D"ltr" style=3D"font-family:a=
rial,sans-serif"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span><s=
pan style=3D"font-family:arial,sans-serif"> wrote:</span><br></div><div cla=
ss=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>Sorry you feel that way. I devoted a big part of th=
e article to trying to fairly represent the top 3 arguments made, but ultim=
ately I can't link to a clear statement of what Bitcoin Core thinks bec=
ause there isn't one. Some people think the block size should increase,=
but not now, or not by much. Others think it should stay at 1mb forever, o=
thers think everyone should migrate to Lightning, people who are actually <=
i>implementing</i>=C2=A0Lightning think it's not a replacement for an i=
ncrease ..... I think one or two people even suggested shrinking the block =
size!</div></div></blockquote><div><br></div><div><div class=3D"gmail_defau=
lt" style=3D"font-family:monospace">=E2=80=8BThat's been really unclear=
to me. Personally, I'd love to see a vote from the core and XT develop=
ers on:</div><div class=3D"gmail_default" style=3D"font-family:monospace"><=
br></div><div class=3D"gmail_default" style=3D"font-family:monospace">=C2=
=A0- what should the block size soft limit be in 12 months (min and max)</d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace">=C2=A0- wha=
t should the block size hard limit be in 12 months (min and max)</div><div =
class=3D"gmail_default" style=3D"font-family:monospace"><br></div><div clas=
s=3D"gmail_default" style=3D"font-family:monospace">=C2=A0- at what rate sh=
ould the hard limit grow over the next 10 years=E2=80=8B (min and max)</div=
><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:monospace">=C2=A0- what mech=
anism should be used to update the soft limit</div><div class=3D"gmail_defa=
ult" style=3D"font-family:monospace">=C2=A0 =C2=A0(manual code change, time=
based, blockchain history, something else)</div><div class=3D"gmail_defaul=
t" style=3D"font-family:monospace">=E2=80=8B - what me=E2=80=8Bchanism shou=
ld be used to update the hard limit</div><div class=3D"gmail_default" style=
=3D"font-family:monospace">=C2=A0 =C2=A0(hard fork code change, time based,=
blockchain history, something else)</div><div class=3D"gmail_default" styl=
e=3D"font-family:monospace"><br></div><div class=3D"gmail_default" style=3D=
"font-family:monospace">Bonus:</div><div class=3D"gmail_default" style=3D"f=
ont-family:monospace"><br></div><span style=3D"font-family:monospace">=E2=
=80=8B - what should the <div class=3D"gmail_default" style=3D"font-family:=
monospace;display:inline">=E2=80=8Btransaction =E2=80=8B</div>fee level be =
in 12 months (after the reward halves)?=E2=80=8B</span><div class=3D"gmail_=
default" style=3D"font-family:monospace">=C2=A0- what's a good measure =
of "(de)centralisation" and what value should everyone aim for in=
12 months?</div><div class=3D"gmail_default" style=3D"font-family:monospac=
e"><br></div></div><div><div class=3D"gmail_default" style=3D"font-family:m=
onospace">As an interested newbie, I can't actually tell what most peop=
le think the answers to most of those questions are. FWIW, mine would be:</=
div><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:monospace">=C2=A0- soft l=
imit in 12 months: 1MB-4MB</div><div class=3D"gmail_default" style=3D"font-=
family:monospace">=C2=A0- hard limit in 12 months: 2MB-20MB</div><div class=
=3D"gmail_default" style=3D"font-family:monospace">=C2=A0- hard limit grows=
at 17-40% a year (and should be >4x average txn volume)</div><div class=
=3D"gmail_default" style=3D"font-family:monospace">=C2=A0- update the soft =
limit by code changes or blockchain history</div><div class=3D"gmail_defaul=
t" style=3D"font-family:monospace">=C2=A0- update the hardlimit by (1) fee =
level, (2) miner vote, (3) hard coded time updates at a conservative (low) =
rate, (4) hard fork every couple of years</div><div class=3D"gmail_default"=
style=3D"font-family:monospace">=C2=A0- transaction fees should in 12month=
s should be lower per kB than today's defaults, say 20%-50% of today=
9;s defaults in USD</div><div class=3D"gmail_default" style=3D"font-family:=
monospace">=C2=A0- number of bitcoin nodes, should be 20% higher in 12 mont=
hs than it is now</div><br></div><div><div class=3D"gmail_default" style=3D=
"font-family:monospace">=E2=80=8BCheers,<br></div></div><div><div class=3D"=
gmail_default" style=3D"font-family:monospace">aj</div></div></div><div><br=
></div>-- <br><div class=3D"gmail_signature">Anthony Towns <<a href=3D"m=
ailto:aj@erisian.com.au" target=3D"_blank">aj@erisian.com.au</a>></div>
</div></div>
--001a1134cc5048a06e051d6f9097--
|
