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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 15DEC117F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 19:03:59 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 569E61D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 29 Aug 2015 19:03:58 +0000 (UTC)
Received: from localhost ([::1]:55652 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZVlPx-002Lwk-DO; Sat, 29 Aug 2015 15:03:57 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Sat, 29 Aug 2015 15:03:57 -0400
From: jl2012@xbt.hk
To: Btc Drak <btcdrak@gmail.com>
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>
Message-ID: <252a127e52be46262b09482c39ad286c@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
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 19:03:59 -0000
I am quite skeptical about any pay-to-increase proposal because it is
difficult to predict the game dynamics and determine the right amount of
penalty. But anyway, here is my response to your revised proposal:
1. I agree with you that there should be a cap in the rate of change,
and also the maximum possible size. This is already part of BIP100
2. Requiring a higher difficulty is bad for everyone:
a) it increases the variance of the miner;
b) average confirmation time for all tx are increased. It may even
cause a feedback: many tx in mempool -> increase block size -> wait
longer for confirmation -> more tx in mempool;
c) difficulty of the next round will be decreased, leading to a greater
fluctuation in confirmation time.
Instead, you should require miners to burn their coinbase reward. This
is effectively same as higher difficulty but is good for everyone: a)
mining variance and confirmation time unchanged; b) all bitcoin holders
become relatively richer
If you don't want to burn any bitcoin, you may require the miner the
send to penalty to <840000 + current height> OP_CHECKLOCKTIMEVERIFY,
which will subsidize the mining when the block reward drops below 1 BTC
3. It is a better idea to allow mining of a bigger block immediately,
which reduces (but not eliminates) the problem of tragedy of the
commons. However, you can't use the blocksize as the vote. Mining an
empty block doesn't mean the miner wants to decrease the block size to
200 bytes. That will just encourage some miners to fill up a block with
garbage which does no good for anyone. Therefore, you need to look at
both the actual block size and the coinbase vote, and always take the
bigger value to determine the penalty and the max block size of next
round. If a miner includes nothing in the coinbase, it should be
consider as a vote for the current max block size.
Btc Drak via bitcoin-dev 於 2015-08-29 06:15 寫到:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 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?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
