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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AEDA87AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 19:52:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com
[209.85.213.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2BF83123
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 19:52:00 +0000 (UTC)
Received: by igbpg9 with SMTP id pg9so99186129igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 11 Aug 2015 12:51:59 -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=A725Nl85ZYViPYG6HIMAXa3ed5GegorM1+5aqQGV67Y=;
b=ht2S2efJ98GuashC7Imf0LwRbvgq6mN+mh7tIJWSYjag7hUUcpOMNMcKxksCABfJa7
+MTKMTUAJujF6Kt9Q76Y1aP4mn87XwcXmoTwhRPApgkoEcQ8kbykW/PPRJ87z0fC3xOB
W6E502fSyUR0PgT7KO8/1czChLDGx5wu9PVqJDHvcRmyu/LJSQS9/VMUlO7DL4+EX3Ci
jcmcS+c0Dg8bqv5w64xvktwZjptFOZXZXIdJocsnTjEBljfvPpnxyzWKgX6d84D8yBk3
mGb8ehlsKAP52oS9L+HDnrUTWtFlkcR09lCUYMuU8ibBdb5JhG1/JyY34AzdDRD/HC/O
bdXw==
MIME-Version: 1.0
X-Received: by 10.50.88.41 with SMTP id bd9mr12861341igb.4.1439322719645; Tue,
11 Aug 2015 12:51:59 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Tue, 11 Aug 2015 12:51:59 -0700 (PDT)
In-Reply-To: <CALgxB7sLsod9Kb-pwxGwCtPpWXsUusDE1nJ7p4nbFMG8mDWFtg@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>
Date: Tue, 11 Aug 2015 21:51:59 +0200
Message-ID: <CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Michael Naber <mickeybob@gmail.com>
Content-Type: multipart/alternative; boundary=089e013cb9846bf57a051d0e6fda
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 19:52:00 -0000
--089e013cb9846bf57a051d0e6fda
Content-Type: text/plain; charset=UTF-8
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
--089e013cb9846bf57a051d0e6fda
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">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.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></s=
pan> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><block=
quote 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 no=
t necessarily a bad thing. The question at hand is whether we should constr=
ain that limit below what technology is capable of delivering. I'm argu=
ing 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&#=
39;s in Bitcoin or in some other product / fork.=C2=A0</div></div></blockqu=
ote><div><br></div><div>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 t=
erm, but it will come with higher centralization pressure of various forms.=
There is discussion about whether these centralization pressures are signi=
ficant, but citing that it's artificially constrained under the limit i=
s IMHO a misrepresentation. It is constrained to aim for a certain balance =
between utility and risk, and neither extreme is interesting, while possibl=
y still "working".<br><br></div><div>Consensus rules are what kee=
ps the system together. You can't simply switch to new rules on your ow=
n, 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 nec=
essary, and disagree about whether we need a block size limit, but we shoul=
d be extremely careful with change. My position as Bitcoin Core developer i=
s that we should merge consensus changes only when they are uncontroversial=
. Even when you believe a more invasive change is worth it, others may disa=
gree, and the risk from disagreement is likely larger than the effect of a =
small block size increase by itself: the risk that suddenly every transacti=
on can be spent twice (once on each side of the fork), the very thing that =
the block chain was designed to prevent.<br><br></div><div>My personal opin=
ion 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 peopl=
e 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.<br><br>-- <br></div><div>Pieter<br><br></div></div></div>=
</div>
--089e013cb9846bf57a051d0e6fda--
|
