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
|
Return-Path: <mickeybob@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7F1688D8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 21:31:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 82C1B109
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 21:31:50 +0000 (UTC)
Received: by wicja10 with SMTP id ja10so1787817wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 14:31:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=RwqZ0sUxccSfpE3j/M+xFhIhJUjtgscnhTfu7O/rCAE=;
b=qCNqEST03UJQxZzGcsyIseS1o8oGXdIlHjP4FjH+DyquVhy5/zH8jbv4quNfwiQ+6k
0nDJOygzFjc97jJeipZ0w2Uk5XFsxF+rgAMDAGpTKJI/WTU944ORRNydzlzAaH15E3UW
w1NI44JLWtqI9/1BfGuwWwyBIn4ZHT2F1X7mLuV4GXruWeW4APsauWk1DgiTnryYI4+b
P1L+Dowx7/PIh1PJqAvUCmhOPMUcgeFteYw5snKL0qlIrrRqPMwt6f2ySRPZEVofrQrr
FxgngsycYuOGdpiPgxqcuMJAv9QFN6qa0wuy+fWYZhmi5zEyuMiqOcnDqSRGTLZHZLSL
OM8w==
MIME-Version: 1.0
X-Received: by 10.194.118.197 with SMTP id ko5mr60141068wjb.58.1439328709335;
Tue, 11 Aug 2015 14:31:49 -0700 (PDT)
Received: by 10.27.78.207 with HTTP; Tue, 11 Aug 2015 14:31:49 -0700 (PDT)
In-Reply-To: <CABm2gDpLNLp=SxfaR8vJUm1KMwBK0jZS1sABVOZw+N5v8t55eQ@mail.gmail.com>
References: <CABsx9T16fH+56isq95m4+QWsKwP==tf75ep8ghnEcBoV4OtZJA@mail.gmail.com>
<CABm2gDpwMQzju+Gsoe3qMi60MPr7OAiSuigy3RdA1xh-SwFzbw@mail.gmail.com>
<CABm2gDoz4NMEQuQj6UHCYYCwihZrEC4Az8xDvTBwiZDf9eQ7-w@mail.gmail.com>
<8181630.GdAj0CPZYc@coldstorage>
<CABm2gDp2svO2G5bHs5AcjjN8dmP6P5nv0xriWez-pvzs2oBL5w@mail.gmail.com>
<CALgxB7sQM5ObxyxDiN_BOyJrgsgfQ6PAtJi52dJENfWCRKywWg@mail.gmail.com>
<CAOG=w-u61dDpa+QrPfku_TCUW7TJLmKekYPbJrF2onsKXAmWdA@mail.gmail.com>
<CALgxB7sdUag_26rKbFYNyRxkS2G6sRZ_GOwPF5U8ri2pobNtcA@mail.gmail.com>
<CABm2gDpLNLp=SxfaR8vJUm1KMwBK0jZS1sABVOZw+N5v8t55eQ@mail.gmail.com>
Date: Tue, 11 Aug 2015 16:31:49 -0500
Message-ID: <CALgxB7swhJe62L=nwzmWmOvxPXJiV59ihbPGNDY7FJ5YP_vj2w@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=089e0122aec86f6032051d0fd40e
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,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] Fees and the block-finding process
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: Tue, 11 Aug 2015 21:31:51 -0000
--089e0122aec86f6032051d0fd40e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Re: "In my opinion the main source of disagreement is that one: how the
maximum block size limits centralization."
I generally agree with that, but I would add that centralization is only a
goal insofar as it serves things like reliability, transaction integrity,
capacity, and accessibility. More broadly: how do you think that moving the
block size from 1MB to 8MB would materially impact these things?
Re: "That's why I cannot understand the urgency to rise the maximum size."
This issue is urgent because the difference between bitcoin being a success
and it being forgotten hinges on it being "better money" than other money.
If people want a money that can process lots and lots of transactions at
low cost, they're going to get it so long as technology can give it to
them. While it's not critical we raise the block size this very moment
since we're not hitting the capacity wall right now, based on the way
growth spikes in Bitcoin have occurred in the past we, may hit that
capacity wall soon and suddenly. And the moment we do, then Bitcoin may no
longer be "better money" since there's a big opportunity for other money
with higher throughput and lower fees to take its place.
On Tue, Aug 11, 2015 at 2:45 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>
> On Aug 11, 2015 8:55 PM, "Michael Naber" <mickeybob@gmail.com> wrote:
> >
> > It generally doesn't matter that every node validate your coffee
> transaction, and those transactions can and will probably be moved onto
> offchain solutions in order to avoid paying the cost of achieving global
> consensus. But you still don't get to set the cost of global consensus
> artificially. Market forces will ensure that supply will meet demand ther=
e,
> so if there is demand for access to global consensus, and technology exis=
ts
> to meet that demand at a cost of one cent per transaction -- or whatever
> the technology-limited cost of global consensus happens to be -- then
> that's what the market will supply.
>
> Assuming we maintain any block size maximum consensus rule, the market
> will adapt to whatever maximum size is imposed by the consensus rules.
> For example, with the current demand and the current consensus block size
> maximum, the market has settled on a minimum fee of zero satoshis per
> transaction. That's why I cannot understand the urgency to rise the maxim=
um
> size.
>
> In any case, yhe consensus maximum shouldn't be based on current or
> projected demand, only on centralization concerns, which is what the
> consensus rule serves for (to limit centralization).
> For example, Gavin advocates for 20 MB because he is not worried about ho=
w
> that could increase centralization because he believes it won't.
> I can't agree with that because I believe 20 MB could make mining
> centralization (and centralization in general) much worse.
>
> But if I have to chose between 2 "centralization safe" sizes, sure, the
> bigger the better, why not.
> In my opinion the main source of disagreement is that one: how the maximu=
m
> block size limits centralization.
>
--089e0122aec86f6032051d0fd40e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Re: "<span style=3D"font-size:12.8000001907349px=
">In my opinion the main source of disagreement is that one: how the maximu=
m block size limits centralization."</span></div><div><br></div><div>I=
generally agree with that, but I would add that centralization is only a g=
oal insofar as it serves things like reliability, transaction integrity, ca=
pacity, and accessibility. More broadly: how do you think that moving the b=
lock size from 1MB to 8MB would materially impact these things?</div><div><=
br></div><div>Re: "<span style=3D"font-size:12.8000001907349px">That&#=
39;s why I cannot understand the urgency to rise the maximum size."</s=
pan></div><div><br></div><div>This issue is urgent because the difference b=
etween bitcoin being a success and it being forgotten hinges on it being &q=
uot;better money" than other money. If people want a money that can pr=
ocess lots and lots of transactions at low cost, they're going to get i=
t so long as technology can give it to them. While it's not critical we=
raise the block size this very moment since we're not hitting the capa=
city wall right now, based on the way growth spikes in Bitcoin have occurre=
d in the past we, may hit that capacity wall soon and suddenly. And the mom=
ent we do, then Bitcoin may no longer be "better money" since the=
re's a big opportunity for other money with higher throughput and lower=
fees to take its place.<br></div></div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">On Tue, Aug 11, 2015 at 2:45 PM, Jorge Tim=C3=B3n <s=
pan dir=3D"ltr"><<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">j=
timon@jtimon.cc</a>></span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><sp=
an class=3D""><p dir=3D"ltr"><br>
On Aug 11, 2015 8:55 PM, "Michael Naber" <<a href=3D"mailto:mi=
ckeybob@gmail.com" target=3D"_blank">mickeybob@gmail.com</a>> wrote:<br>
><br>
> It generally doesn't matter that every node validate your coffee t=
ransaction, and those transactions can and will probably be moved onto offc=
hain solutions in order to avoid paying the cost of achieving global consen=
sus. But you still don't get to set the cost of global consensus artifi=
cially. Market forces will ensure that supply will meet demand there, so if=
there is demand for access to global consensus, and technology exists to m=
eet that demand at a cost of one cent per transaction -- or whatever the te=
chnology-limited cost of global consensus happens to be -- then that's =
what the market will supply.</p>
</span><p dir=3D"ltr">Assuming we maintain any block size maximum consensus=
rule, the market will adapt to whatever maximum size is imposed by the con=
sensus rules.<br>
For example, with the current demand and the current consensus block size m=
aximum, the market has settled on a minimum fee of zero satoshis per transa=
ction. That's why I cannot understand the urgency to rise the maximum s=
ize.</p>
<p dir=3D"ltr">In any case, yhe consensus maximum shouldn't be based on=
current or projected demand, only on centralization concerns, which is wha=
t the consensus rule serves for (to limit centralization).<br>
For example, Gavin advocates for 20 MB because he is not worried about how =
that could increase centralization because he believes it won't.<br>
I can't agree with that because I believe 20 MB could make mining centr=
alization (and centralization in general) much worse.</p>
<p dir=3D"ltr">But if I have to chose between 2 "centralization safe&q=
uot; sizes, sure, the bigger the better, why not.<br>
In my opinion the main source of disagreement is that one: how the maximum =
block size limits centralization.<br></p>
</blockquote></div><br></div>
--089e0122aec86f6032051d0fd40e--
|
