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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Z5tOP-0004oL-0f
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 10:19:25 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.170 as permitted sender)
client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f170.google.com;
Received: from mail-wi0-f170.google.com ([209.85.212.170])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z5tON-0005Kq-MN
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 10:19:24 +0000
Received: by wicnd19 with SMTP id nd19so14495079wic.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 03:19:17 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.231.4 with SMTP id tc4mr5256991wic.27.1434709157711;
Fri, 19 Jun 2015 03:19:17 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.28.14.196 with HTTP; Fri, 19 Jun 2015 03:19:17 -0700 (PDT)
In-Reply-To: <CAOoPuRa2RRELMN4-1coe3ZDOHuxyp1YyX3t6aW+APhXJM8GpDw@mail.gmail.com>
References: <55828737.6000007@riseup.net>
<CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>
<55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator>
<CAOG=w-scXm-46sp2NgR2UUp20R5ujuaAzW-jU_Owh20C4Xc=9A@mail.gmail.com>
<CAJHLa0Mhnma8_ys2ckEA+dLT-EWnqO4j8YKMSaf3Tvv_K14czQ@mail.gmail.com>
<CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
<CANEZrP33GCiZHK1GV2Qt_R_AHK6SEjybGPtmORjqgvQ9MiYVZQ@mail.gmail.com>
<CAOoPuRa2RRELMN4-1coe3ZDOHuxyp1YyX3t6aW+APhXJM8GpDw@mail.gmail.com>
Date: Fri, 19 Jun 2015 12:19:17 +0200
X-Google-Sender-Auth: c8lTbh42Rv3Me8PTdnn-1OLn9mI
Message-ID: <CANEZrP0EHb_Nc+oYp4zTGPG9Cbjo5OcF59ZpS80iZQozqRhaxA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Benjamin <benjamin.l.cordes@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134cc28b395260518dc41be
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Z5tON-0005Kq-MN
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Gavin Andresen <gavin@bitcoinfoundation.org>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
to Remove Commit Access from Other Developers
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: Fri, 19 Jun 2015 10:19:25 -0000
--001a1134cc28b395260518dc41be
Content-Type: text/plain; charset=UTF-8
>
> Yeah, but increasing block-size is not a longterm solution.
Are you sure? That sort of statement is hard to answer because it doesn't
say what you think long term is, or how much you expect Bitcoin to grow.
Satoshi thought it was a perfectly fine long term solution because he
thought hardware would get cheaper as fast or faster than Bitcoin would
grow. You may disagree with him, but as we're talking about the future are
you 100% certain he was wrong? I did calculations a long time ago that
suggested even with today's hardware (+some software optimisations) it
would be feasible to keep up with Visa.
Hardware improvements can be unintuitive. There's a spreadsheet here that
lets you play with various parameters.
https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=1451669128
(note: the spreadsheet says avg txn size is 250 bytes, but if you check the
formula for the middle column, it does actually use 500 bytes as the
multiplier hard coded).
> Necessary higher fees are a logical consequence of lower subsidies.
> Bitcoin was basically free to use at the beginning because miners got paid
> with new coins at the expense of those who already hold coins.
> Eventually there needs to be a mechanism which matches supply and demand.
>
That's not clear either, I'm afraid.
Remember that there's an upper limit on how high Bitcoin fees can go. When
fees become higher than what the banking system charges, many users won't
use Bitcoin for moving money around anymore. Fees cannot really go much
higher than that even if you assume the currency is still attractive for
other reasons, because people would just sell their coins for fiat, move
the fiat, and buy back the coins the other side.
The way mining will be funded in future is an open question. There are
differing proposals. Still, even with a higher hard block size limit,
miners can always refuse to mine transactions that don't include a
particular fee. So if you're worried about this, miners aren't being forced
into any particular policy.
--001a1134cc28b395260518dc41be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">Yeah, but increasing block-size is not a longterm solution.</b=
lockquote><div><br></div><div>Are you sure? That sort of statement is hard =
to answer because it doesn't say what you think long term is, or how mu=
ch you expect Bitcoin to grow.</div><div><br></div><div>Satoshi thought it =
was a perfectly fine long term solution because he thought hardware would g=
et cheaper as fast or faster than Bitcoin would grow. You may disagree with=
him, but as we're talking about the future are you 100% certain he was=
wrong? I did calculations a long time ago that suggested even with today&#=
39;s hardware (+some software optimisations) it would be feasible to keep u=
p with Visa.</div><div><br></div><div>Hardware improvements can be unintuit=
ive. There's a spreadsheet here that lets you play with various paramet=
ers.=C2=A0</div><div><br></div><div><a href=3D"https://docs.google.com/spre=
adsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=3D14516691=
28">https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImz=
Afdeb6ajATEY/edit#gid=3D1451669128</a><br></div><div><br></div><div>(note: =
the spreadsheet says avg txn size is 250 bytes, but if you check the formul=
a for the middle column, it does actually use 500 bytes as the multiplier h=
ard coded).</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"> Necessary=C2=A0high=
er fees are a logical consequence of lower subsidies. Bitcoin was=C2=A0basi=
cally free to use at the beginning because miners got paid with=C2=A0new co=
ins at=C2=A0 the expense of those who already hold coins. Eventually=C2=A0t=
here needs to be a mechanism which matches supply and demand.<br></blockquo=
te><div><br></div><div>That's not clear either, I'm afraid.</div><d=
iv><br></div><div>Remember that there's an upper limit on how high Bitc=
oin fees can go. When fees become higher than what the banking system charg=
es, many users won't use Bitcoin for moving money around anymore. Fees =
cannot really go much higher than that even if you assume the currency is s=
till attractive for other reasons, because people would just sell their coi=
ns for fiat, move the fiat, and buy back the coins the other side.</div><di=
v><br></div><div>The way mining will be funded in future is an open questio=
n. There are differing proposals. Still, even with a higher hard block size=
limit, miners can always refuse to mine transactions that don't includ=
e a particular fee. So if you're worried about this, miners aren't =
being forced into any particular policy.</div></div></div></div>
--001a1134cc28b395260518dc41be--
|
