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
|
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 029BA1151
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 20:41:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f49.google.com (mail-la0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B782F1FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 20:41:10 +0000 (UTC)
Received: by laba3 with SMTP id a3so50219901lab.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 13:41:08 -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;
bh=V16mLfKHpcSbcvN8vfGB46ZMfMSz4PRXLLRg/29swGE=;
b=S1dkBXHKcPbT6DOazPd23ziGKI/aDrLvL7OUtdU/YBzBy1hihkV10JqnlDkEPQbN46
pL8HW46MV0IbEzQSlAc2LfeEgksngadUN9HkIX/kCGV2DPVkCzQwuXKdA02HBMwf3dsi
JgRhqkMPQaup81fNBlM5nysfj0QrLnE0QTe3Da1PtC+dwwcpkgmK3kuvl6brD70uGbQM
bVoT/GuhpwSyLzX01ddkqzDFwA5siFsKKBz0jKxWopj9lKMwMBHczB416EeG6Gxe4aJ6
b8Fom5WZFPSVqrPBJ2EgKoVeUqGU5BjA6GhnH4rnt99cS58GpE//Bo0qNbO+QMlGZLK0
IPRA==
X-Gm-Message-State: ALoCoQmA7Zee0Z1WeNUcgzEIaNI+9kacYKD6C2Lzo0YiRT1/yvyN3rN5cQNoUHtnBJl+v5faakAc
MIME-Version: 1.0
X-Received: by 10.112.136.201 with SMTP id qc9mr7444242lbb.94.1440880868746;
Sat, 29 Aug 2015 13:41:08 -0700 (PDT)
Received: by 10.25.15.22 with HTTP; Sat, 29 Aug 2015 13:41:08 -0700 (PDT)
In-Reply-To: <CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
References: <CADJgMzvWKA79NHE2uFy1wb-zL3sjC5huspQcaDczxTqD_7gXOg@mail.gmail.com>
<CADr=VrQR6rYK4sJJsDpUdFJaWZqhv=AkMqcG64EhsOCg1tDxVg@mail.gmail.com>
<CADJgMzvkBDBD9_=53kaD_6_jWH=vbWOnNwOKK5GOz8Du-F08dQ@mail.gmail.com>
<2081355.cHxjDEpgpW@crushinator>
<A30CC2E3-A769-445C-95A2-35B963EFC283@gmail.com>
<CAB+qUq7ZzLHrFZ5FQazrcALA-b-jFh_bf-XX1GaJbGY1KQB5YA@mail.gmail.com>
<CAOG=w-vkOzGXosc=C7NwX5_ewaT0Sdrkw49gfO+a9hohYctLaw@mail.gmail.com>
<CABm2gDreJ1PwZu3WgZdj_RR0W9JoQTF9w-Qwyfoh6uk1EM0ajg@mail.gmail.com>
<CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@mail.gmail.com>
<CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
Date: Sat, 29 Aug 2015 22:41:08 +0200
Message-ID: <CABm2gDo66UzhLU3Dgc6Cj=0Au4xJNv-U9GUv8JaryakQFJ=VQA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] Consensus based block size retargeting algorithm
(draft)
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: Sat, 29 Aug 2015 20:41:12 -0000
On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak <btcdrak@gmail.com> wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Ah, then my mistake. It seemed so similar to an idea that was proposed
>> before on this mailing list:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>>
>> that my mind just filled in the gaps. I concur -- having miners -- or any
>> group -- vote on block size is not an intrinsically good thing. The the
>> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
>> but rather a feedback control that made the maximum block size that which
>> generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
Then I only care about the hard cap (for example, to me bip100 is
practically equivalent to just raise the limit to 32 MB directly).
Miners can always produce smaller blocks by modifying their local policy.
So if we need a maximum that cannot be altered by miners anyway, why
take the additional complexity of miners voting on a lower and
changing maximum size?
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?".
How expensive it is depends on the concrete function f(extra_nBits) =
extra_size_allowed
But the goal of that proposal is not to raise the size maximum
permanently, but rather temporarily allow bigger blocks when there are
spikes in demand (ie many fees to collect in unconfirmed
transactions).
Yes miners will ask that question to themselves, and the answer will
depend on the concrete function and on the fees of those extra
transactions.
The miner paying for the costs will get the gains: no tragedy of the
commons here.
> Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
I believe the tragedy of the commons actually happens with your
proposal. Why would I pay alone for something that benefits all
miners?
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
This seems to solve the tragedy of the commons problem with your
current proposal.
It would be like flexcap but instead of the change in size being
temporary, it affects the next maximum size permanently.
One thing to worry about is miners filling blocks with
pay-to-themselves garbage to avoid reducing the size when they don't
have enough attractive transactions to include (ie it may not be free
for the network for miners to vote on "maintain current size").
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
I still don't see the point in having a lower moving size maximum.
If 8 MB is mining-centralization-safe, let's move directly to 8 MB
without adding this seemingly useless extra complexity.
If it's not, mining voting on a lower moving maximum won't make it safer.
Once we have more objective tools (centralization metrics, simulators,
etc...) to determine whether or not a block size is
mining-centralization-safe for a given point in time (looking at
current centralization and current technology available), I don't see
the problem with repeating the equivalent of bip102 periodically
(every 2 years?) to adapt the size to better technology or lower
mining centralization.
It would be also helpful to have a tool to somehow measure "size
increase urgency" (ie right now free transactions get mined and blocks
aren't full or close to be full, I don't think the current general
sense of urgency on this matter is justified).
With all respect, I believe bip100 and this proposal are
over-engineering; and bip101 and bip103 (pieter's) are
overly-optimistic (in their exponential technological growth
assumptions).
|
