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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1VeQJI-0001FC-V7
for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 14:11:49 +0000
X-ACL-Warn:
Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129]
helo=mail.ceptacle.com)
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VeQJH-0005uA-33 for bitcoin-development@lists.sourceforge.net;
Thu, 07 Nov 2013 14:11:48 +0000
Received: from localhost (localhost [127.0.0.1])
by mail.ceptacle.com (Postfix) with ESMTP id 86EE1369C59D
for <bitcoin-development@lists.sourceforge.net>;
Thu, 7 Nov 2013 15:11:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at ceptacle.com
Received: from mail.ceptacle.com ([127.0.0.1])
by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new,
port 10024) with ESMTP id dncFokgj64Dt
for <bitcoin-development@lists.sourceforge.net>;
Thu, 7 Nov 2013 15:11:40 +0100 (CET)
Received: from MacGronager.local (cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net
[188.180.67.254])
by mail.ceptacle.com (Postfix) with ESMTPSA id 8AE37369C586
for <bitcoin-development@lists.sourceforge.net>;
Thu, 7 Nov 2013 15:11:40 +0100 (CET)
Message-ID: <527B9F9B.4060808@ceptacle.com>
Date: Thu, 07 Nov 2013 15:11:39 +0100
From: Michael Gronager <gronager@ceptacle.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: ethz.ch]
X-Headers-End: 1VeQJH-0005uA-33
Subject: [Bitcoin-development] On the optimal block size and why transaction
fees are 8 times too low (or transactions 8 times too big)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2013 14:11:49 -0000
Following the discussion on the recent mining sybil trick, I reread the
article on block propagation by Decker et al.* and decided to use it for
doing a proper estimate of transaction fee size and optimal block size.
The propagation of a block depends on and is roughly proportional to its
size. Further, the slower a block propagates the higher the risk of a
fork, so as a miner you are basically juggling the risk of a fork
(meaning you loose your bounty) vs the opportunity for including more
transactions and hence also get those fees.
This alone will dictate the minimal transaction fee as well as the
optimal block size!
Lets try to put it into equations. For the purpose of this initial study
lets simplify the work by Decker et al. Roughly, we can say that the
average propagation time for a block is t_propagate, and the average
time between blocks is t_blocks. Those are roughly 10sec and 600sec
respectively. The risk of someone else mining a block before your block
propagates is roughly**:
P_fork = t_propagate/t_blocks (~1/60)
Also note that propagation time is a function of block size, S:
t_propagate = t_0 + alpha*S
where Decker et al have determined alpha to 80ms/kb. We also define the
fee size pr kilobyte, f, so
E_fee = f*S
Given these equations the expected average earning is:
E = P_hashrate*(1 - P_fork)*(E_bounty + E_fees)
And inserting:
E = P_hashrate*[1 - (t_0 + alpha*S)/t_block]*(E_bounty + f*S)
We would like to choose the fee so the more transactions we include the
more we earn. I.e. dE/dS > 0:
dE/dS = P_hashrate*{[(t_block - t_0)*f - alpha*E_bounty]/t_block -
2*alpha*f/t_block*S}
Which gives:
f > alpha*E_bounty/(t_block-t_0) ~ alpha*E_bounty/t_block
or f > 80*25/600000 = 0.0033 or assuming a standard transaction size of
0.227kb:
f_tx > 0.00076.
Note that this number is 8 times higher than the current transaction
fee! So the current optimal block size is an empty block i.e. without
other transactions than the coinbase! (miners don't listen now...)
Lets see what you loose by e.g. including 1000 transactions:
E(1000) = P_hashrate*24.34XBT
Which is a loss of 2.6% compared to not including transactions at all!
So there are two ways forward from here. 1) raise the minimum fee, and
2) make transactions smaller. We cannot make transactions much smaller,
but we can utilize that most of them have already been broadcasted
verified and validated and then just include their hash in the block***.
This changes the relevant size for a transaction from 0.227kb to
0.032kb. Which makes f_tx = 0.00011. We are almost there!
Now assume that we implement this change and raise the minimum fee to
0.00015, what is then the optimal block size (dE/dS = 0) ?
S = 1/2 * (t_block/alpha - E_bounty/f)
Which gives 1083kb for a bounty of 25 and 2417kb for a bounty of 12.5.
Optimal size in case of no bounty or an infinite fee is 3750MB.
Final conclusions is that the fee currently is too small and that there
is no need to keep a maximum block size, the fork probability will
automatically provide an incentive to not let block grows into infinity.
*)
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf
**) The calculations should be done using the proper integrals and
simulations, but I will leave that for academia ;)
***) A nice side effect from switching to broadcasting transactions in
blocks as only their hash is that it decouples fee size from transaction
size!
|
