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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A470CB2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 21:24:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com
[209.85.213.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DC34BED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 21:24:39 +0000 (UTC)
Received: by mail-vk0-f42.google.com with SMTP id y187so34732494vka.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 13:24:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=iT7jhLlLTSik4kcFBfINoHvloeWVAwXVeY0DzMqybnI=;
b=qjDp5KERQGnyvHO6cGus++6Ee1sy2rL6KnmrsEBrvG7oew+tYbZs86iRBQEe2vI/Fh
bY1f+eL7kxW+onTI0RnmzgL/IjmS6bEyMJ+DJEIn27+wNEtb6cPc7xA0u0J0+yX/HEIl
BPKniuPbRfYlwae/nFQyPIC78HvUAPMvjSrULWHeZRibFkVvdAwHGN2tJnw+s7Ukqcts
f5jcT1BoSqyJ/Ra1OaNAGYd2g2QmA3+Dl+rrLPdRuj+DjHmSz7SKcXWAZ7BZ5MYX+3hF
ToDcQaDq122JPjQdMdINyHhDo3GuvacA4cqOrIKPg0OM+RI5jA6AD/AdelZ+JjDhAl5V
f3JQ==
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;
bh=iT7jhLlLTSik4kcFBfINoHvloeWVAwXVeY0DzMqybnI=;
b=hC4NiKnChKDmYO1my8/YC/rStZW2rnXpuMYWopMehQQdHovPWRQJUAn5srD+oF7yRz
iEnfimM+Vy4IlbH44L2740xD5EixfQn6W/R0vlsVqjWd25wcrhG0KPujWz47qZ+9Vgn+
XZLfnbKXN0m6tehgIh9uo8O3orugJMJ2Dpm8y8koDIXCx6T/fBlMJ6l0GDTCGODBbL8v
NrZrRjr/OPuAVUX/enZT/otQWW5pUyBLDGE059S4aTRQx4YPNY5xTIoYpBowtiQR1L7q
iBOs7ni9Tk637ssVueW6d6aZ2YHhH72LCn4rBINc5MFwklPFM+GLUwErugTWXpZHKHwP
c67A==
X-Gm-Message-State: ALoCoQmKPWSFcgxUk9mAbwgO7vDtEVtLqVzssDlFQ2zEKmrn6RphC6Ziuj2LU4nFDn/IXCPfin+adRJ6RxLIF3KvSctRrVdxpw==
MIME-Version: 1.0
X-Received: by 10.31.149.10 with SMTP id x10mr9472863vkd.144.1450301079012;
Wed, 16 Dec 2015 13:24:39 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Wed, 16 Dec 2015 13:24:38 -0800 (PST)
Received: by 10.31.236.70 with HTTP; Wed, 16 Dec 2015 13:24:38 -0800 (PST)
In-Reply-To: <CADm_Wcae7OK7kyXkfh+7XFrc2WYsv7T1Va3_E=5om+XYrL9pOw@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
<CADm_Wcae7OK7kyXkfh+7XFrc2WYsv7T1Va3_E=5om+XYrL9pOw@mail.gmail.com>
Date: Wed, 16 Dec 2015 22:24:38 +0100
Message-ID: <CABm2gDrQ8X70RGVmboyBzaLmd1ZJ77+-Hdr8PG153FcFJmJ29g@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: multipart/alternative; boundary=001a11408b14a1d82f05270a88b7
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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] Block size: It's economics & user preparation &
moral hazard
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: Wed, 16 Dec 2015 21:24:40 -0000
--001a11408b14a1d82f05270a88b7
Content-Type: text/plain; charset=UTF-8
On Dec 16, 2015 10:08 PM, "Jeff Garzik via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
>>
>> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> > 2) If block size stays at 1M, the Bitcoin Core developer team should
sign a
>> > collective note stating their desire to transition to a new economic
policy,
>> > that of "healthy fee market" and strongly urge users to examine their
fee
>> > policies, wallet software, transaction volumes and other possible User
>> > impacting outcomes.
>>
>> You present this as if the Bitcoin Core development team is in charge
>> of deciding the network consensus rules, and is responsible for making
>> changes to it in order to satisfy economic demand. If that is the
>> case, Bitcoin has failed, in my opinion.
>
>
> This circles back to Problem #1: Avoidance of a choice is a still a
choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very real
Economic Change Event risk.
Unless the community is going to always avoid this "economic change event"
forever (effectively eliminating MAX_BLOCK_SIZE), this is going to happen
at some point. I assume those concerned with the "economic change" are only
scared about it because "nitcoin is still very young" of something like
that.
Since you advocate for delaying this event from happening, can you be
clearer about when do you think it would be ok to let the event happen?
What other event makes this event ok?
> Hitting a Fee Event is market changing, potentially reshuffling economic
actors to a notable degree. Maintaining a short term economic policy of
fixed 1M supply in the face of rising transaction volume carries risks that
should be analyzed and communicated.
Assuming we adopt bip102, eventually you will be able to say exactly the
same about 2 MB. When does this "let's not change the economics" finishes
(if ever)?
--001a11408b14a1d82f05270a88b7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Dec 16, 2015 10:08 PM, "Jeff Garzik via bitcoin-dev" <<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linux=
foundation.org</a>> wrote:<br>
><br>
> On Wed, Dec 16, 2015 at 1:34 PM, Pieter Wuille <<a href=3D"mailto:p=
ieter.wuille@gmail.com">pieter.wuille@gmail.com</a>> wrote:<br>
>><br>
>> On Wed, Dec 16, 2015 at 3:53 PM, Jeff Garzik via bitcoin-dev<br>
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>> wrote:<br>
>> > 2) If block size stays at 1M, the Bitcoin Core developer team=
should sign a<br>
>> > collective note stating their desire to transition to a new e=
conomic policy,<br>
>> > that of "healthy fee market" and strongly urge user=
s to examine their fee<br>
>> > policies, wallet software, transaction volumes and other poss=
ible User<br>
>> > impacting outcomes.<br>
>><br>
>> You present this as if the Bitcoin Core development team is in cha=
rge<br>
>> of deciding the network consensus rules, and is responsible for ma=
king<br>
>> changes to it in order to satisfy economic demand. If that is the<=
br>
>> case, Bitcoin has failed, in my opinion.<br>
><br>
><br>
> This circles back to Problem #1: =C2=A0 Avoidance of a choice is a sti=
ll a choice - failing to ACK a MAX_BLOCK_SIZE increase still creates very r=
eal Economic Change Event risk.</p>
<p dir=3D"ltr">Unless the community is going to always avoid this "eco=
nomic change event" forever (effectively eliminating MAX_BLOCK_SIZE), =
this is going to happen at some point. I assume those concerned with the &q=
uot;economic change" are only scared about it because "nitcoin is=
still very young" of something like that.<br>
Since you advocate for delaying this event from happening, can you be clear=
er about when do you think it would be ok to let the event happen?<br>
What other event makes this event ok?</p>
<p dir=3D"ltr">> Hitting a Fee Event is market changing, potentially res=
huffling economic actors to a notable degree.=C2=A0 Maintaining a short ter=
m economic policy of fixed 1M supply in the face of rising transaction volu=
me carries risks that should be analyzed and communicated.</p>
<p dir=3D"ltr">Assuming we adopt bip102, eventually you will be able to say=
exactly the same about 2 MB. When does this "let's not change the=
economics" finishes (if ever)?<br>
</p>
--001a11408b14a1d82f05270a88b7--
|
