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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VhGiS-0006bI-M9
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 10:33:32 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.77 as permitted sender)
client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
helo=outmail149077.authsmtp.com;
Received: from outmail149077.authsmtp.com ([62.13.149.77])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VhGiR-0004wP-FZ for bitcoin-development@lists.sourceforge.net;
Fri, 15 Nov 2013 10:33:32 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rAFAWpsN085373;
Fri, 15 Nov 2013 10:32:51 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rAFAWlkC075360
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 15 Nov 2013 10:32:50 GMT
Date: Fri, 15 Nov 2013 05:32:46 -0500
From: Peter Todd <pete@petertodd.org>
To: Michael Gronager <gronager@ceptacle.com>
Message-ID: <20131115103246.GB17034@savin>
References: <528367F5.9080303@ceptacle.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR"
Content-Disposition: inline
In-Reply-To: <528367F5.9080303@ceptacle.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 4776d3a5-4de1-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwcUFloCAgsB AmUbWlReU197XGI7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcGpw YUJFIRl1cgZAeDBx Z0VhWD5fW0N8IUUs
R1NQQTgHeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4mADM6 DwsDGC0rEFdNQiQ1
Lhk7LxYSEUtZOUw2 OkYlUE4ZNBlwQgNZ BURQBCYLb1dJEWIh
Ch5cQV9cHjpHQhBG CwElZRZWDyZbVSdv Dk9CQBIUCjFIOLUD
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
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: petertodd.org]
0.0 LOTS_OF_MONEY Huge... sums of money
X-Headers-End: 1VhGiR-0004wP-FZ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: Fri, 15 Nov 2013 10:33:32 -0000
--6sX45UoQRIJXqkqR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Nov 13, 2013 at 12:52:21PM +0100, 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)".
>=20
> Peter Todd made some nice additions to it including different pool sizes
> into the numbers.
>=20
> 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 laten=
cy.
>=20
> Using the formulas from last week:
>=20
> P_fork =3D t_propagate/t_blocks
>=20
> and:
>=20
> t_propagate =3D t_0 + alpha*S ~=3D alpha*S
Assuming t_0 is negligible is wrong in this case. Or, it should be...
> We get a measure for alpha as a function of the average fork rate and
> average block size:
>=20
> alpha =3D P_fork*t_block/S
So alpha has units of seconds/byte, which lets us indirectly figure out
the bandwidth the blocks are propagating at assuming t_0=3D0 and all links
are equal. When you realize that P_fork is basically a multiplier on the
bandwidth required to get a block out fast enough, the derivation makes
sense. In any case we get:
alpha =3D (1/113)*600s/134kBytes =3D 39.62uS/byte =3D 24kB/second
Which is atrocious... but when you remember that Bitcoin nodes send
blocks to all peers simultaneously,(1) thus dividing up the bandwidth and
ruining latency you see why. t_0 shouldn't be at all negligible due to
speed of light, but with this low bandwidth it is anyway.
1) To be precise, nodes answer queries for blocks from all peers
simultaneously.
This also indicates that pools haven't taken the simple step of peering
with each other using high-bandwidth nodes with restricted numbers of
peers, which shows you how little attention they are paying to
optimizing profits. Right now mining pulls in $1.8 million/day, so
that's up to $16k wasted.
However, because miners don't orphan themselves, that $16k loss is born
disproportionately by smaller miners... which also means the 24kB/sec
bandwidth estimate is wrong, and the real number is even worse. In
theory anyway, could just as easily be the case that larger pools have
screwed up relaying still such that p2pool's forwarding wins.
--=20
'peter'[:-1]@petertodd.org
000000000000000658459cd64e63243e719106014257870d073207c2d5460137
--6sX45UoQRIJXqkqR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJShfhOXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDc1ZWQ5MTUzMWUwN2QyMDQ1YjU4MjNkYTA1MGZlMzczYmRl
N2JiMzYzOTY1ZTQ0YWUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfurJwgAptj95GdOX0/cedNBfi2D1tAx
jfEFWFJXs497eh8DIcH6Fvl6qF6U+b//kX9Fsi3FuTBywdYSYcJmyfyWyeX7zELD
xZZeoOg0TETtHuGK0DA7h0I89MfP5rnxoRrQYHk3SP8MSoZIHbI+B7PA8VXd1olH
foPav+98SNsfQzHgO4uSuyqsjkCc5oFeaYeSMQ+TJz2RNgApwGr+HqCxq/oIA9ZJ
82n0yHmBEEnMqKzZ3Z9T1n5C2BIDQy0WL3jQMwADRfFQ1JhyBWEGefBXY4ee3isU
5nf7eprYS7GbteNANaHhijlgZQoCLb5HO0+kk5l7ejMNhrh58LzZx5G5cRc6Cg==
=aDyD
-----END PGP SIGNATURE-----
--6sX45UoQRIJXqkqR--
|
