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: <btcdrak@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8D821C20
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 10:15:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
[209.85.212.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D748A1D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 10:15:50 +0000 (UTC)
Received: by wicne3 with SMTP id ne3so5577339wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 03:15:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type;
bh=hhJsz/21VTL21LAMDAzQGXY5blGPrhhnF0fG79SU1tw=;
b=RguB4IZXSXukS/ABoxk8q+0ZdS8j38lZbmGIWkNiVJgoCa5Tfc+RjvEAoR0E37ZuVp
TIU4td5b42AX3ptSWmYggqRTRldKXY4ttfU7ibixEBxf+l+uk9ZweAw+kNsmVineoKSx
LcLsuF5MsjRKenNHlb1MBpSO8nIFOLq8qHJr7qd2BPjPAUCvIvNKOziTIDZq2iJqJ7xz
1Dj5RLjW15+SkvXq8xVVhb0nRF/jZQmiAFaDueTa/02a/Bvb3ljIrW9hI2fj68uUqkaT
ErFtU/j51yW1ayTGoNmSoihqlCiZaw7cXGHtqB4DSqF4kacLlFDk+vbTAxpDgZgitJHC
em9w==
X-Received: by 10.194.121.131 with SMTP id lk3mr15439857wjb.77.1440843349311;
Sat, 29 Aug 2015 03:15:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.211.16 with HTTP; Sat, 29 Aug 2015 03:15:29 -0700 (PDT)
In-Reply-To: <CAOG=w-uYFbyUF+PZABNvMqHei2-yuoCETtXnfkYV-Rr9-pPKuw@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>
From: Btc Drak <btcdrak@gmail.com>
Date: Sat, 29 Aug 2015 11:15:29 +0100
Message-ID: <CADJgMzvJDSk6oZMZPc4C8ENHhGvspdeF7WURfnY6OPKWs33a7w@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
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, HK_RANDOM_ENVFROM,
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 10:15:51 -0000
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.
I believe the idea of a hard upper limit has become rather politicised
but is essential to the security model of bitcoin.
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?". 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.
Whilst the exact number may be up for discussion, I would propose an
initial upper limit of 8MB, so under my proposal the blocksize would
be flexible between 1MB and 8MB.
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.
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?
|
