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
|
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 DD67EE54
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 07:56:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f179.google.com (mail-io0-f179.google.com
[209.85.223.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6AF88122
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Dec 2015 07:56:59 +0000 (UTC)
Received: by mail-io0-f179.google.com with SMTP id q126so81688597iof.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 Dec 2015 23:56:59 -0800 (PST)
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=COCVhbTy3+d8GoE6H7F78XrhJZ6GKgzBk73zz5IUxy8=;
b=Ihz0zjK97Bqz6z/xPu0bC3BaOVETn0yY8xgXQvmARJYIB6QKglWHi1MxVaAPHrmFYR
43wq/AoqgnaqRmNfDMhir80tFv3nQfnEiGLqMDaPFKf06jbtQUidctXz1tXHNQyxFf1h
2w7mUFQAAJcqf9ejDoHHfeTeaGn+JKc/wMucLQt0R8YJTmsAhRYcPSQS6awcLsi5o9KL
oq2fDQ0kuIaWkjk6QNXisQlnH171+TmxtC5tj3enrfVVj08ROsO1GRg/Jg8JWomStxgB
LjCQ1Sf8Cd7ri2jYScjQmKyeLVJ4AjNWTbjvpLze3b5jpEF+zuhRu49AYiwMv7ND48Jx
1lzg==
MIME-Version: 1.0
X-Received: by 10.107.165.197 with SMTP id o188mr3186326ioe.132.1450425418876;
Thu, 17 Dec 2015 23:56:58 -0800 (PST)
Received: by 10.36.80.6 with HTTP; Thu, 17 Dec 2015 23:56:58 -0800 (PST)
In-Reply-To: <CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
References: <CADm_WcasDuBsop55ZWcTb2FvccaoREg8K032rUjgQUQhQ3g=XA@mail.gmail.com>
<CAPg+sBi=Mw7UnxG1-0-0ZTRqxrS5+28VmowyYrGP2MAvYiu_pA@mail.gmail.com>
<CADm_WcbrMyk-=OnQ-3UvnF_8brhn+X2NqRPbo5xUXsbcZpc0=Q@mail.gmail.com>
Date: Fri, 18 Dec 2015 08:56:58 +0100
Message-ID: <CAPg+sBjbATqf8DXGF7obw9a=371zQ_S0EgTapnUmukAVenTneQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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 development mailing list <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: Fri, 18 Dec 2015 07:57:00 -0000
On Fri, Dec 18, 2015 at 6:11 AM, Jeff Garzik <jgarzik@gmail.com> wrote:
>> 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.
>
> Diverging from the satoshi block size change plan[1] and current economics
> would seem to require a high level of months-ahead communication to users.
I don't see any plan, but will you say the same thing when the subsidy
dwindles, and mining income seems to become uncertain? It will equally
be an economic change, which equally well will have been predictable,
and it will equally well be treatable with a hardfork to increase the
subsidy.
Yes, I'm aware the argument above is a straw man, because there was
clear expectation that the subsidy would go down asymptotically, and
much less an expectation that the blocksize would remain fixed
forever.
But I am not against a block size increase hard fork. My talk on
segregated witness even included proposed pursuing a hard fork at a
slightly later stage.
But what you're arguing for is that - despite being completely
expected - blocks grew fuller, and people didn't adapt to block size
pressure and a fee market, so the Core committee now needs to kick the
can down the road, because we can't accept the risk of economic
change. That sounds very much like a bailout to me.
Again. I am not against growth, but increasing in response to fear of
economic change is the wrong approach. Economic change is inevitable.
> Segregated Witness does not kick the can, it solves none of the problems #1,
> #3 - #8 explicitly defined and listed in email #1.
>
> 1) A plan of "SW + no hard fork" is gambling with ECE risk, gambling there
> will be no Fee Event, because the core block size is still heavily contended
> -- 100% contended at time out SW rollout.
That is an assumption. I expect demand for transactions at a given
feerate to stop growing at a certain contention level (and we've
reached some level of contention already, with mempools not being
cleared for significant amounts of time already).
> SW mitigates this
> - only after several months
That is assuming a hard fork consensus forming, deployment,
activation, ... goes faster than a softfork.
> - only assuming robust adoption rates by up-layer ecosystem software, and
That's not required. Everyone who individually switches to new
transactions gets to do 1.75x more transactions for the same price
(and at the same time gets safer contracts, better script
upgradability, and more security models at their disposal), completely
independent of whether anyone else in the ecosystem does the same.
> - only assuming transaction volume growth is flat or sub-linear
The only question is how many transactions for what price. Contention
always happens at a specific feerate level anyway.
> Those conditions must go as planned to fulfill "SW kicked the can" -- a lot
> of if's.
>
> As stated, SW is orthogonal to the drift-into-uncharted-waters problem
> outlined in email #1, which a short term bump does address.
Both SW and a short bump (which is apparently not what BIP102 does
anymore?) increase capacity available per price, and yes, they are
completely orthogonal.
My only disagreement is the motivation (avoiding economic change, as
opposed to aiming for safe growth) and the claim that a capacity
increase hardfork is easier and safe(r) to roll out quickly than
sortfork SW.
Apart from that, we clearly need to do both at some point.
--
Pieter
|
