summaryrefslogtreecommitdiff
path: root/a9/8fe44e5b94cd9a1fdb03783b27ecf4ba4191b7
blob: f2f3532f6df4e6cf6a80094c4944ee2d69b1cd46 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gronager@ceptacle.com>) id 1VgZeC-0002Kd-Cl
	for bitcoin-development@lists.sourceforge.net;
	Wed, 13 Nov 2013 12:34:16 +0000
X-ACL-Warn: 
Received: from 2508ds5-oebr.1.fullrate.dk ([90.184.5.129]
	helo=mail.ceptacle.com)
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1VgZeA-0005Ug-Eu for bitcoin-development@lists.sourceforge.net;
	Wed, 13 Nov 2013 12:34:16 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.ceptacle.com (Postfix) with ESMTP id 2B1AA36E4F77
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 Nov 2013 13:34:09 +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 hxRSXph-vnpU
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 Nov 2013 13:34:08 +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 31B5536E4F64
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 Nov 2013 13:34:08 +0100 (CET)
Message-ID: <528371BF.9030100@ceptacle.com>
Date: Wed, 13 Nov 2013 13:34:07 +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>
References: <528367F5.9080303@ceptacle.com>
In-Reply-To: <528367F5.9080303@ceptacle.com>
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: doubleclick.net]
X-Headers-End: 1VgZeA-0005Ug-Eu
Subject: Re: [Bitcoin-development] Even simpler minimum fee calculation
 formula: f > bounty*fork_rate/average_blocksize
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: Wed, 13 Nov 2013 12:34:16 -0000

Just a quick comment on the actual fees (checked at blockchain.info) the
average fee over the last 90 days is actually ~0.0003BTC/txn - so not
too far behind the theoretical minimum of 0.00037BTC/txn.

I suppose, though, that it has more to do with old clients and fee
settings (0.0005) than network wisdom ;)

On 13/11/13, 12:52 , Michael Gronager wrote:
> Last week I posted a writeup: "On the optimal block size and why
> transaction fees are 8 times too low (or transactions 8 times too big)".
> 
> Peter Todd made some nice additions to it including different pool sizes
> into the numbers.
> 
> However, it occurred to me that things can in fact be calculated even
> simpler: The measured fork rate will mean out all the different pool
> sizes and network latencies and will as such provide a simple number we
> can use to estimate the minimum fee. Key assumption is that the latency
> will depend on block size (# txns) and the fork rate will depend on latency.
> 
> Using the formulas from last week:
> 
> P_fork = t_propagate/t_blocks
> 
> and:
> 
> t_propagate = t_0 + alpha*S ~= alpha*S
> 
> We get a measure for alpha as a function of the average fork rate and
> average block size:
> 
> alpha = P_fork*t_block/S
> 
> Further, take the formula for the minimum fee:
> 
> f > alpha*E_bounty/t_block
> 
> And insert the formula for alpha:
> 
> f > P_fork*E_bounty/S_average
> 
> Luckily the fork frequency and the average block size are easily
> measurable. blockchain.info keeps historical graphs of number of
> orphaned blocks pr day - average over the last year is 1.5. Average
> number of blocks per day over the last year is 169, which yields a
> P_fork of ~1/113. Average block size in the same time is 134kBytes,
> which yields a minimum fee:
> 
> f > 0.00165XBT/kb or 0.00037XBT/txn
> 
> So the 0.0001 is only 4 times too small. Further, let us look at the
> trend over the last 12 months. Pieter Wuille claimed that there has been
> several improvements over the last half year that would bring down the
> latency, there has also been speculations regarding direct connections
> between the major pools etc - lets see if this is indeed true.
> 
> If you look instead of 360 days, only at the last 90 days the average
> block size has been 131kBytes, and the fork rate has been ~1/118, which
> results in a minimum fee of:
> 
> f > 0.00162XBT/kb or 0.00037XBT/txn
> 
> So a small improvement but not statistically important...
> 
> Last question, recalling that optimal revenue block size is a function
> of the txn-fee (from the last writeup) - lets see what fee it takes to
> support a block size of 131kBytes:
> 
> S = 1/2 * (t_block/alpha - E_bounty/f)
> 
> S = 1/2 * (S/P_fork - E_bounty/f)
> 
> f = E_bounty/[(1/P_fork-2)*S] = 0.00165XBT/kB
> 
> So a 4 times increase is still sufficient for the current load.
> 
> Anyway - the all important number is alpha, the network latency which we
> expect to be dependent of various things such as interconnectivity,
> bandwidths, software quality etc, where mainly the latter is within our
> hands to bring down the fee. And you can actually setup the standard
> client to choose a better fee, as all the parameters in the formula are
> easily measured!
> 
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>