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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YqJPu-0006Ob-PQ
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 10:52:34 +0000
Received: from mail-wi0-f181.google.com ([209.85.212.181])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YqJPt-0003mr-1l
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 10:52:34 +0000
Received: by wiun10 with SMTP id n10so54877182wiu.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 07 May 2015 03:52:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=qgIsyukOI6Y9bdaaMLWS0o/kJXjCVTdnUXD+HztHsoM=;
b=Edw2Vipj78GszpNIq8bR7tfpH6iNgcjW9Qp77p19AWBQTvuZgqSyE6MeiWTjL2A2F2
bkQCvAefyMEic0la+w8KoVlyUaHjPxcNP6dRdXioQIj2Rwums1hMcSqdLhwoJ1o35G6o
mOa/6JgXJmMSe+0X1oTuaBtbbce5pLttj+CzOOEmv0snj92+UBbd9o6L3s98mXR01DPW
EEJ5JgLu4Shh3GiZmPhL7IXkT7IJE39ZJjFeGi/wjohbXWGrqbPG9BZSW+PFRYIzQ8yM
yAXsEa5G20QIaS1FiTWKC5kQk2tpYHK5s4N1NUl+aaBLm6LPtwSC1brxyoi/8loA9IKi
YKbA==
X-Gm-Message-State: ALoCoQm0wmIl10McCLXBuPd/0JpO2U6vPWoFc8wsyDFusCVbG6rCHUt9KPljjcH8f3j/S9t9KrnX
MIME-Version: 1.0
X-Received: by 10.180.188.193 with SMTP id gc1mr5455992wic.7.1430995946911;
Thu, 07 May 2015 03:52:26 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Thu, 7 May 2015 03:52:26 -0700 (PDT)
In-Reply-To: <CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
References: <554A91BE.6060105@bluematt.me>
<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>
Date: Thu, 7 May 2015 12:52:26 +0200
Message-ID: <CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YqJPt-0003mr-1l
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
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: Thu, 07 May 2015 10:52:34 -0000
On Thu, May 7, 2015 at 11:25 AM, Mike Hearn <mike@plan99.net> wrote:
> I observed to Wladimir and Gavin in private that this timeline meant a ch=
ange to the block size was unlikely to get into 0.11, leaving only 0.12, wh=
ich would give everyone only a few months to upgrade in order to fork the c=
hain by the end of the winter growth season. That seemed tight.
Can you please elaborate on what terrible things will happen if we
don't increase the block size by winter this year?
I assume that you are expecting full blocks by then, have you used any
statistical technique to come up with that date or is it just your
guess?
Because I love wild guesses and mine is that full 1 MB blocks will not
happen until June 2017.
> What we need to see right now is leadership and a plan, that fits in the
> available time window.
>
>>
>> Certainly a consensus in this kind of technical community should be a
>> basic requirement for any serious commitment to blocksize increase.
>
>
> I'm afraid I have come to disagree. I no longer believe this community ca=
n
> reach consensus on anything protocol related. Some of these arguments hav=
e
> dragged on for years. Consensus isn't even well defined - consensus of wh=
o?
> Anyone who shows up? And what happens when, inevitably, no consensus is
> reached? Stasis forever?
We've successfully reached consensus for several softfork proposals already=
.
I agree with others that hardfork need to be uncontroversial and there
should be consensus about them.
If you have other ideas for the criteria for hardfork deployment all I'm ea=
rs.
I just hope that by "What we need to see right now is leadership" you
don't mean something like "when Gaving and Mike agree it's enough to
deploy a hardfork" when you go from vague to concrete.
>> Long-term incentive compatibility requires that there be some fee
>> pressure, and that blocks be relatively consistently full or very nearly
>> full.
>
>
> I disagree. When the money supply eventually dwindles I doubt it will be =
fee
> pressure that funds mining, but as that's a long time in the future, it's
> very hard to predict what might happen.
Oh, so your answer to "bitcoin will eventually need to live on fees
and we would like to know more about how it will look like then" it's
"no bitcoin long term it's broken long term but that's far away in the
future so let's just worry about the present".
I agree that it's hard to predict that future, but having some
competition for block space would actually help us get more data on a
similar situation to be able to predict that future better.
What you want to avoid at all cost (the block size actually being
used), I see as the best opportunity we have to look into the future.
>> What we see today are
>> transactions enjoying next-block confirmations with nearly zero pressure
>> to include any fee at all (though many do because it makes wallet code
>> simpler).
>
>
> Many do because free transactions are broken - the relay limiter means
> whether a free transaction actually makes it across the network or not is
> basically pot luck and there's no way for a wallet to know, short of eith=
er
> trying it or actually receiving every single transaction and repeating th=
e
> calculations. If free transactions weren't broken for all non-full nodes
> they'd probably be used a lot more.
Free transactions are a gift from miners that run an altruistic policy.
That's great but we shouldn't rely on them for the future. They will
likely disappear at some point and that's ok.
In any case, he's not complaining about the lack of free transactions,
more like the opposite.
He is saying that's very easy to get free transactions in the next
block and blocks aren't full so there's no incentive to include fees
to compete for the space.
We can talk a lot about "a fee market" and build a theoretically
perfect fee estimator but we won't actually have a fee market until
there's some competition for space.
Nobody will pay for space that's abundant just like people don't pay
for the air they breath.
> What I don't see from you yet is a specific and credible plan that fits
> within the next 12 months and which allows Bitcoin to keep growing. Not s=
ome
> vague handwave like "let's all use the Lightning network" (which does not
> exist), or "let's do more research" (Gavin has done plenty of research), =
or
> "but what about the risks" (Bitcoin is full of risks). A plan, with dates
> attached, and a strong chance of actually being deployed in time.
Ok, this is my plan: we wait 12 months, hope that your estimations are
correct (in case that my guess was better than yours, we keep waiting
until June 2017) and start having full blocks and people having to
wait 2 blocks for their transactions to be confirmed some times.
That would be the beginning of a true "fee market", something that
Gavin used to say was his #1 priority not so long ago (which seems
contradictory with his current efforts to avoid that from happening).
Having a true fee market seems clearly an advantage.
What are supposedly disastrous negative parts of this plan that make
an alternative plan (ie: increasing the block size) so necessary and
obvious.
I think the advocates of the size increase are failing to explain the
disadvantages of maintaining the current size. It feels like the
explanation are missing because it should be somehow obvious how the
sky will burn if we don't increase the block size soon.
But, well, it is not obvious to me, so please elaborate on why having
a fee market (instead of just an price estimator for a market that
doesn't even really exist) would be a disaster.
|
