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
|
Return-Path: <daniele.pinna@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 58C61279
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 21:35:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com
[209.85.213.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB9F8E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 21:35:19 +0000 (UTC)
Received: by igfj19 with SMTP id j19so23146646igf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 14:35:19 -0700 (PDT)
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
:content-type; bh=6YQBW8cZzsxJefhqn9bPRwsrygi9cyFgskhxKw98Vv8=;
b=bO1bcneApf4nIwaEyVmiVnNlurGNEgM6+IWq7734tF3PNqmPCHJqapHBOmMTmupa/r
qMY8tYxJg2Tq0C0UjrvgZdiaMpoxZt/iXpb/jSDpDVatuKEUbn4E2q4cr1U1xR64aHgi
7yL3x1szgFRuud6SEImukFwpZguVC9QuG9b7nyiqRg4sFVT4Tud8/p5fkj59S5Etkjkt
ba9ob8KcB9DvIPYNiWv9MK4R0lS56qpXln8hPtyOsckAh+vi4iGvftDm+V7sPHPsZ2kJ
wUiwpr/Qam4Ga889gHDJo9laFxhMbhizw1FB4hpksrrwedIK5wOAfSjRDa9n0hZK0Y4c
L+aA==
MIME-Version: 1.0
X-Received: by 10.50.128.169 with SMTP id np9mr4967876igb.37.1440192918871;
Fri, 21 Aug 2015 14:35:18 -0700 (PDT)
Received: by 10.50.30.198 with HTTP; Fri, 21 Aug 2015 14:35:18 -0700 (PDT)
Received: by 10.50.30.198 with HTTP; Fri, 21 Aug 2015 14:35:18 -0700 (PDT)
In-Reply-To: <CAEgR2PFhubcZmiCnZOAYfNOeXwhsu6m1Xd9=KMmP7wueFQaK9A@mail.gmail.com>
References: <CAEgR2PFhubcZmiCnZOAYfNOeXwhsu6m1Xd9=KMmP7wueFQaK9A@mail.gmail.com>
Date: Fri, 21 Aug 2015 23:35:18 +0200
Message-ID: <CAEgR2PEwhrAtsxBkVEeHn_jqK4+TgNkUY36qT1wktEwp2jmS_g@mail.gmail.com>
From: Daniele Pinna <daniele.pinna@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=047d7b10ca835665a4051dd90b48
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_20,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max C
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, 21 Aug 2015 21:35:20 -0000
--047d7b10ca835665a4051dd90b48
Content-Type: text/plain; charset=UTF-8
"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3% of
the blocks."
Peter_R's analysis of fee markets in the absence of blocksize limits [1]
shows that the hashrate advantage of a large miner is a side-effect of
coinbase subsidization. As the block rewards get smaller, so will large
miner advantages. An easy way to think about this is as follows:
Currently, the main critique of larger blocksizes is that we'll connected
miners can cut out smaller miners by gratuitously filling up blocks with
self-paying transactions. This only works because block subsidies exist.
The moment block rewards become comparable to block TX fees, this exploit
ceases to be functional.
Basically, large miners will still be forced to move full blocks, but it
will go against their interest to fill them with spam since their main
source of income is the fees themselves. As a result, large miners (unlike
smaller ones) will lose the incentive to mine an un full block this evening
the playing field.
In this context, large blocksizes as proposed by BIP100-101 hope to
stimulate the increase of TX fees by augmenting the network's capacity. The
sooner block rewards become comparable to block fees, the sooner we will
get rid of mine centralization.
Dpinna
[1]
http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit
--047d7b10ca835665a4051dd90b48
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">"I ran some simulations, and if blocks take 20 seconds =
to propagate, a<br>
network with a miner that has 30% of the hashing power will get 30.3% of th=
e blocks."</p>
<p dir=3D"ltr">Peter_R's analysis of fee markets in the absence of bloc=
ksize limits [1] shows that the hashrate advantage of a large miner is a si=
de-effect of coinbase subsidization. As the block rewards get smaller, so w=
ill large miner advantages. An easy way to think about this is as follows:<=
/p>
<p dir=3D"ltr">Currently, the main critique of larger blocksizes is that we=
'll connected miners can cut out smaller miners by gratuitously filling=
up blocks with self-paying transactions. This only works because block sub=
sidies exist. The moment block rewards become comparable to block TX fees, =
this exploit ceases to be functional. </p>
<p dir=3D"ltr">Basically, large miners will still be forced to move full bl=
ocks, but it will go against their interest to fill them with spam since th=
eir main source of income is the fees themselves. As a result, large miners=
(unlike smaller ones) will lose the incentive to mine an un full block thi=
s evening the playing field. </p>
<p dir=3D"ltr">In this context, large blocksizes as proposed by BIP100-101 =
hope to stimulate the increase of TX fees by augmenting the network's c=
apacity. The sooner block rewards become comparable to block fees, the soon=
er we will get rid of mine centralization. </p>
<p dir=3D"ltr">Dpinna</p>
<p dir=3D"ltr">[1] <a href=3D"http://www.scribd.com/mobile/doc/273443462/A-=
Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit">http://www.scribd=
.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-S=
ize-Limit</a></p>
--047d7b10ca835665a4051dd90b48--
|
