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
|
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 5230197
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 05:21:13 +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 D2ACD30
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Aug 2015 05:21:12 +0000 (UTC)
Received: from localhost ([::1]:45916 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZNa4w-002sQG-N3; Fri, 07 Aug 2015 01:20:26 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 07 Aug 2015 01:20:21 -0400
From: jl2012@xbt.hk
To: Wes Green <maveric100@gmail.com>
In-Reply-To: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com>
References: <CAOvA3_hhzWqX0k7xbua=qFptb90fkbCU-WDMih4=mX+kRrWG1g@mail.gmail.com>
Message-ID: <ee3ac5ef1febb7d9a66d89c41543a64f@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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Block size implementation using Game Theory
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, 07 Aug 2015 05:21:13 -0000
It won't work as you thought. If a miner has 95% of hashing power, he
would have 95% of chance to find the next block and collect the penalty.
In long term, he only needs to pay 5% penalty. It's clearly biased
against small miners.
Instead, you should require the miners to burn the penalty. Whether this
is a good idea is another issue.
Wes Green via bitcoin-dev 於 2015-08-06 19:52 寫到:
> Bitcoin is built on game theory. Somehow we seem to have forgotten
> that and are trying to fix our "block size issue" with magic numbers,
> projected percentage growth of bandwidth speeds, time limits, etc...
> There are instances where these types of solutions make sense, but
> this doesn't appear to be one of them. Lets return to game theory.
>
> Proposal: Allow any miner to, up to, double the block size at any
> given time - but penalize them. Using the normal block reward,
> whatever percentage increase the miner makes over the previous limit
> is taken from both the normal reward and fees. The left over is
> rewarded to the next miner that finds a block.
>
> If blocks stay smaller for an extended period of time, it goes back
> down to the previous limit/ x amount decrease/% decrease (up for
> debate)
>
> Why would this work?: Miners only have incentive to do raise the limit
> when they feel there is organic growth in the network. Spam attacks,
> block bloat etc would have to be dealt with as it is currently. There
> is no incentive to raise the size for spam because it will subside and
> the penalty will have been for nothing when the attack ends and block
> size goes back down.
>
> I believe it would have the nice side effect of forcing miners to hold
> the whole block chain. I believe SPV does not allow you to see all the
> transactions in a block and be able to calculate if you should be
> adding more to your reward transaction if the last miner made the
> blocks bigger. Because of this, the miners would also have an eye on
> blockchain size and wont want it getting huge too fast (outsize of
> Moore's law of Nielsen's Law). Adding to the gamification.
>
> This system would encourage block size growth due to organic growth
> and the penalty would encourage it to be slow as to still keep reward
> high and preserve ROE.
>
> What this would look like: The miners start seeing what looks like
> natural network growth, and make the decision (or program an
> algorithm, the beauty is it leaves the "how" up to the miners) to
> increase the blocksize. They think that, in the long run, having
> larger blocks will increase their revenue and its worth taking the hit
> now for more fees later. They increase the size to 1.25 MB. As a
> result, they reward would be 18.75 (75%). The miner fees were .5BTC.
> The miner fees are also reduced to .375BTC. Everyone who receives that
> block can easily calculate 1) if the previous miner gave themselves
> the proper reward 2) what the next reward should be if they win it.
> Miners now start building blocks with a 31.25 reward transaction and
> miner fee + .125.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
