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
|
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 A01728A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 20:56:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com
[209.85.212.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A757109
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 20:56:47 +0000 (UTC)
Received: by wicne3 with SMTP id ne3so76491769wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 13:56:46 -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=TLum7u5/xr97pgJX8DVU0jGLAB43z7bKpeiaq81cM4Q=;
b=rV6lVfb/0zTPkG8N6rCJiSy4Has7xebgg8m2cTiJYYgnKP+r7L3EbQI0IDGocn/51c
A0T2e98cV3dMtyMTElcCNKmON1pOua9+3FhvVR2JatVvXRSJXmdcUIP4hLrjCI8aQNI8
6wLmi853xvjEkI53+6iU34GeTO3BvuWjmVyYrwNavC4JzXH220CD48NmaDRdhcwQ//rv
o+dslAa878IsUB8CCBClb6b9TtF8iYzgMGEWgPq1Es9Awz4tnG/M9iS5NQDrHgbARkjV
d3s3VQDBOWbynj3/GWyIJV6PYbWPSpuutWor0WfMOJ2CEA+zPIrWD6/WnOW0Ov1lUuJi
CaYw==
MIME-Version: 1.0
X-Received: by 10.180.20.71 with SMTP id l7mr41004369wie.32.1439326606082;
Tue, 11 Aug 2015 13:56:46 -0700 (PDT)
Received: by 10.27.78.207 with HTTP; Tue, 11 Aug 2015 13:56:45 -0700 (PDT)
In-Reply-To: <CABm2gDr3ixS2pxfnuefU1VMn7Qf-4mxDGdG-6UEV0Nf28eigqA@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>
<CABm2gDq+2mXEN2hZY6_JYXAJX=Wxrxr6jm86P6g2YD4zzy-=Nw@mail.gmail.com>
<CALgxB7sLsod9Kb-pwxGwCtPpWXsUusDE1nJ7p4nbFMG8mDWFtg@mail.gmail.com>
<CABm2gDr3ixS2pxfnuefU1VMn7Qf-4mxDGdG-6UEV0Nf28eigqA@mail.gmail.com>
Date: Tue, 11 Aug 2015 15:56:45 -0500
Message-ID: <CALgxB7vw=yeEjnv7Eu96Etj_BdmwamH4dVZaJKaVviwFDtzhWw@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=bcaec53f2e27124d5f051d0f578c
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 20:56:48 -0000
--bcaec53f2e27124d5f051d0f578c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm not sure whether removing the limit at the protocol-level would lead to
government by miners who might reject blocks which were too big, but I
probably wouldn't want to take that risk. I think we should probably keep a
block size limit in the protocol, but that we should increase it to be as
high as "technology can provide." Toward that: I don't necessarily think
that node-count in and of itself should be the metric for evaluating what
technology can provide, as much as the goal that the chain be inexpensive
to validate given the capabilities of present technology -- so if I can
lease a server in a datacenter which can validate the chain and my total
cost to do that is just a few dollars, then we're probably ok.
Of course there's also the issue that we maintain enough geographic /
political distribution to keep the network reliable, but I think we're far
from being in danger on the reliability front. So maybe my criteria that
the chain be validated at low cost is the wrong focus, but if it is than
what's the appropriate criteria for deciding whether it's safe by standards
of "today's technology" to raise the limit at the protocol level?
On Tue, Aug 11, 2015 at 2:53 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>
> On Aug 11, 2015 9:37 PM, "Michael Naber" <mickeybob@gmail.com> wrote:
>
> > Hitting the limit in and of itself is not necessarily a bad thing. The
> question at hand is whether we should constrain that limit below what
> technology is capable of delivering. I'm arguing that not only we should
> not, but that we could not even if we wanted to, since competition will
> deliver capacity for global consensus whether it's in Bitcoin or in some
> other product / fork.
>
> You didn't answer the 2 questions...
> Anyway, if we don't care about centralization at all, we can just remove
> the limit: that's what "technology can provide".
> Maybe in that case it is developers who move to a decentralized
> competitor...
>
> > On Tue, Aug 11, 2015 at 2:27 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wr=
ote:
> >>
> >>
> >> On Aug 11, 2015 8:46 PM, "Michael Naber" <mickeybob@gmail.com> wrote:
> >> >
> >> > Hi Jorge: Many people would like to participate in a global consensu=
s
> network -- which is a network where all the participating nodes are aware
> of and agree upon every transaction. Constraining Bitcoin capacity below
> the limits of technology will only push users seeking to participate in a
> global consensus network to other solutions which have adequate capacity,
> such as BitcoinXT or others. Note that lightning / hub and spoke do not
> meet requirements for users wishing to participate in global consensus,
> because they are not global consensus networks, since all participating
> nodes are not aware of all transactions.
> >>
> >> Even if you are right, first fees will raise and that will be what
> pushes people to other altcoins, no?
> >> Can we agree that the first step in any potentially bad situation is
> hitting the limit and then fees rising as a consequence?
> >
> >
>
--bcaec53f2e27124d5f051d0f578c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm not sure whether removing the limit at the protoco=
l-level would lead to government by miners who might reject blocks which we=
re too big, but I probably wouldn't want to take that risk. I think we =
should probably keep a block size limit in the protocol, but that we should=
increase it to be as high as "technology can provide." Toward th=
at: I don't necessarily think that node-count in and of itself should b=
e the metric for evaluating what technology can provide, as much as the goa=
l that the chain be inexpensive to validate given the capabilities of prese=
nt technology -- so if I can lease a server in a datacenter which can valid=
ate the chain and my total cost to do that is just a few dollars, then we&#=
39;re probably ok.=C2=A0<div><br></div><div>Of course there's also the =
issue that we maintain enough geographic / political distribution to keep t=
he network reliable, but I think we're far from being in danger on the =
reliability front. So maybe my criteria that the chain be validated at low =
cost is the wrong focus, but if it is than what's the appropriate crite=
ria for deciding whether it's safe by standards of "today's te=
chnology" to raise the limit at the protocol level?</div></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 11, 2015 at =
2:53 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D"mailto:jtimon@jt=
imon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><span class=3D""><p dir=3D"ltr"><br>
On Aug 11, 2015 9:37 PM, "Michael Naber" <<a href=3D"mailto:mi=
ckeybob@gmail.com" target=3D"_blank">mickeybob@gmail.com</a>> wrote:</p>
<p dir=3D"ltr">> Hitting the limit in and of itself is not necessarily a=
bad thing. The question at hand is whether we should constrain that limit =
below what technology is capable of delivering. I'm arguing that not on=
ly we should not, but that we could not even if we wanted to, since competi=
tion will deliver capacity for global consensus whether it's in Bitcoin=
or in some other product / fork.</p>
</span><p dir=3D"ltr">You didn't answer the 2 questions...<br>
Anyway, if we don't care about centralization at all, we can just remov=
e the limit: that's what "technology can provide".<br>
Maybe in that case it is developers who move to a decentralized competitor.=
..</p><div class=3D"HOEnZb"><div class=3D"h5">
<p dir=3D"ltr">> On Tue, Aug 11, 2015 at 2:27 PM, Jorge Tim=C3=B3n <j=
timon@jtimon.cc> wrote:<br>
>><br>
>><br>
>> On Aug 11, 2015 8:46 PM, "Michael Naber" <<a href=3D"=
mailto:mickeybob@gmail.com" target=3D"_blank">mickeybob@gmail.com</a>> w=
rote:<br>
>> ><br>
>> > Hi Jorge: Many people would like to participate in a global c=
onsensus network -- which is a network where all the participating nodes ar=
e aware of and agree upon every transaction.=C2=A0Constraining Bitcoin capa=
city below the limits of technology will only push users seeking to partici=
pate in a global consensus network to other solutions which have adequate c=
apacity, such as BitcoinXT or others. Note that lightning / hub and spoke d=
o not meet requirements for users wishing to participate in global consensu=
s, because they are not global consensus networks, since all participating =
nodes are not aware of all transactions.=C2=A0<br>
>><br>
>> Even if you are right, first fees will raise and that will be what=
pushes people to other altcoins, no?<br>
>> Can we agree that the first step in any potentially bad situation =
is hitting the limit and then fees rising as a consequence?<br>
><br>
><br>
</p>
</div></div></blockquote></div><br></div>
--bcaec53f2e27124d5f051d0f578c--
|
