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
200
201
202
|
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 55C988A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 21:18:52 +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 564A3128
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 21:18:51 +0000 (UTC)
Received: by wicne3 with SMTP id ne3so77077967wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 14:18:50 -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=tNMjxhXdAuT00LJOgZ0yZv1UJsZOODs030EjkLGaGMU=;
b=WZRQgmWb2K6nTNmPoDzvv/FijLfvmN7HMelU28YgDXlMDhk34EBPPKxzIDL8TU5jVt
O1oh07E2sOqR2rX6O6ToR+HmVPTiHwPX6ewgPc8AVM2qF8X/jUSbHzRkA9EmqW/f9yWg
SYOZFJJMZ1ESXNRLA6MIw659mHRwRuETEY2vYKRYAEaoM/S1tR2tPAZyDahYUMi3yy26
gTrF9/wgVMzQCKUlMuSTTtTmLupacrp0rY8tezGVBIcxWICBfTCc9eVPWKTNEvgp1xxt
bdiBqSkWuUEbHcdBObr88b+85WI0o/HGppWf70BT9LgrLYg+TtGNM+6j+CufZnmqF81G
tbvQ==
MIME-Version: 1.0
X-Received: by 10.194.83.70 with SMTP id o6mr59842183wjy.44.1439327930119;
Tue, 11 Aug 2015 14:18:50 -0700 (PDT)
Received: by 10.27.78.207 with HTTP; Tue, 11 Aug 2015 14:18:49 -0700 (PDT)
In-Reply-To: <CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@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>
<CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
Date: Tue, 11 Aug 2015 16:18:49 -0500
Message-ID: <CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bb04adefd7ec9051d0fa533
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:18:52 -0000
--047d7bb04adefd7ec9051d0fa533
Content-Type: text/plain; charset=UTF-8
The only reason why Bitcoin has grown the way it has, and in fact the only
reason why we're all even here on this mailing list talking about this, is
because Bitcoin is growing, since it's "better money than other money". One
of the key characteristics toward that is Bitcoin being inexpensive to
transact. If that characteristic is no longer true, then Bitcoin isn't
going to grow, and in fact Bitcoin itself will be replaced by better money
that is less expensive to transfer.
So the importance of this issue cannot be overstated -- it's compete or die
for Bitcoin -- because people want to transact with global consensus at
high volume, and because technology exists to service that want, then it's
going to be met. This is basic rules of demand and supply. I don't
necessarily disagree with your position on only wanting to support
uncontroversial commits, but I think it's important to get consensus on the
criticality of the block size issue: do you agree, disagree, or not take a
side, and why?
On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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.
>>
>
> The question is not what the technology can deliver. The question is what
> price we're willing to pay for that. It is not a boolean "at this size,
> things break, and below it, they work". A small constant factor increase
> will unlikely break anything in the short term, but it will come with
> higher centralization pressure of various forms. There is discussion about
> whether these centralization pressures are significant, but citing that
> it's artificially constrained under the limit is IMHO a misrepresentation.
> It is constrained to aim for a certain balance between utility and risk,
> and neither extreme is interesting, while possibly still "working".
>
> Consensus rules are what keeps the system together. You can't simply
> switch to new rules on your own, because the rest of the system will end up
> ignoring you. These rules are there for a reason. You and I may agree about
> whether the 21M limit is necessary, and disagree about whether we need a
> block size limit, but we should be extremely careful with change. My
> position as Bitcoin Core developer is that we should merge consensus
> changes only when they are uncontroversial. Even when you believe a more
> invasive change is worth it, others may disagree, and the risk from
> disagreement is likely larger than the effect of a small block size
> increase by itself: the risk that suddenly every transaction can be spent
> twice (once on each side of the fork), the very thing that the block chain
> was designed to prevent.
>
> My personal opinion is that we should aim to do a block size increase for
> the right reasons. I don't think fear of rising fees or unreliability
> should be an issue: if fees are being paid, it means someone is willing to
> pay them. If people are doing transactions despite being unreliable, there
> must be a use for them. That may mean that some use cases don't fit
> anymore, but that is already the case.
>
> --
> Pieter
>
>
--047d7bb04adefd7ec9051d0fa533
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The only reason why Bitcoin has grown the way it has, and =
in fact the only reason why we're all even here on this mailing list ta=
lking about this, is because Bitcoin is growing, since it's "bette=
r money than other money". One of the key characteristics toward that =
is Bitcoin being inexpensive to transact. If that characteristic is no long=
er true, then Bitcoin isn't going to grow, and in fact Bitcoin itself w=
ill be replaced by better money that is less expensive to transfer.<div><br=
></div><div>So the importance of this issue cannot be overstated -- it'=
s compete or die for Bitcoin -- because people want to transact with global=
consensus at high volume, and because technology exists to service that wa=
nt, then it's going to be met. This is basic rules of demand and supply=
. I don't necessarily disagree with your position on only wanting to su=
pport uncontroversial commits, but I think it's important to get consen=
sus on the criticality of the block size issue: do you agree, disagree, or =
not take a side, and why?</div><div><br></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Tue, Aug 11, 2015 at 2:51 PM, Pieter =
Wuille <span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" tar=
get=3D"_blank">pieter.wuille@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Tue, Aug 11, 2015 =
at 9:37 PM, Michael Naber via bitcoin-dev <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>></span> wrote:<br></span><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D""><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div><div>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 o=
nly we should not, but that we could not even if we wanted to, since compet=
ition will deliver capacity for global consensus whether it's in Bitcoi=
n or in some other product / fork.=C2=A0</div></div></blockquote><div><br><=
/div></span><div>The question is not what the technology can deliver. The q=
uestion is what price we're willing to pay for that. It is not a boolea=
n "at this size, things break, and below it, they work". A small =
constant factor increase will unlikely break anything in the short term, bu=
t it will come with higher centralization pressure of various forms. There =
is discussion about whether these centralization pressures are significant,=
but citing that it's artificially constrained under the limit is IMHO =
a misrepresentation. It is constrained to aim for a certain balance between=
utility and risk, and neither extreme is interesting, while possibly still=
"working".<br><br></div><div>Consensus rules are what keeps the =
system together. You can't simply switch to new rules on your own, beca=
use the rest of the system will end up ignoring you. These rules are there =
for a reason. You and I may agree about whether the 21M limit is necessary,=
and disagree about whether we need a block size limit, but we should be ex=
tremely careful with change. My position as Bitcoin Core developer is that =
we should merge consensus changes only when they are uncontroversial. Even =
when you believe a more invasive change is worth it, others may disagree, a=
nd the risk from disagreement is likely larger than the effect of a small b=
lock size increase by itself: the risk that suddenly every transaction can =
be spent twice (once on each side of the fork), the very thing that the blo=
ck chain was designed to prevent.<br><br></div><div>My personal opinion is =
that we should aim to do a block size increase for the right reasons. I don=
't think fear of rising fees or unreliability should be an issue: if fe=
es are being paid, it means someone is willing to pay them. If people are d=
oing transactions despite being unreliable, there must be a use for them. T=
hat may mean that some use cases don't fit anymore, but that is already=
the case.<span class=3D"HOEnZb"><font color=3D"#888888"><br><br>-- <br></f=
ont></span></div><span class=3D"HOEnZb"><font color=3D"#888888"><div>Pieter=
<br><br></div></font></span></div></div></div>
</blockquote></div><br></div>
--047d7bb04adefd7ec9051d0fa533--
|
