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
|
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 <pete@petertodd.org>) id 1VkdFQ-0001sq-CO
for bitcoin-development@lists.sourceforge.net;
Sun, 24 Nov 2013 17:13:28 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.161 as permitted sender)
client-ip=62.13.148.161; envelope-from=pete@petertodd.org;
helo=outmail148161.authsmtp.com;
Received: from outmail148161.authsmtp.com ([62.13.148.161])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VkdFM-0002MY-JO for bitcoin-development@lists.sourceforge.net;
Sun, 24 Nov 2013 17:13:28 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id rAOHDGlZ051098;
Sun, 24 Nov 2013 17:13:16 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 rAOHDBVM066208
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 24 Nov 2013 17:13:13 GMT
Date: Sun, 24 Nov 2013 12:13:10 -0500
From: Peter Todd <pete@petertodd.org>
To: Christian Decker <decker.christian@gmail.com>
Message-ID: <20131124171310.GB16143@savin>
References: <CALxbBHWwQXjjET+-GFTKNFPd_yWPjEWGvS-YwUPL+z86J8sw0Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR"
Content-Disposition: inline
In-Reply-To: <CALxbBHWwQXjjET+-GFTKNFPd_yWPjEWGvS-YwUPL+z86J8sw0Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: b402d08b-552b-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAYUFloCAgsB AmUbWlNeUV57WGc7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcGN5 cmx4Lxl0cQdGcDBx Z09iVz4JWER4IUZ1
EFNREG9UeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4tEyIj QAoBVS01GlUMSCwv
LhsgYkUEEUsdKS0A
X-Authentic-SMTP: 61633532353630.1024: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: blockchain.info]
X-Headers-End: 1VkdFM-0002MY-JO
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Network propagation speeds
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: Sun, 24 Nov 2013 17:13:28 -0000
--6sX45UoQRIJXqkqR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Nov 24, 2013 at 05:20:22PM +0100, Christian Decker wrote:
> Since this came up again during the discussion of the Cornell paper I
> thought I'd dig up my measurement code from the Information
> Propagation paper and automate it as much as possible.
>=20
> The result is the Network Propagation page on bitcoinstats.com
> (http://bitcoinstats.com/network/propagation/). It takes a daily
> snapshot of the situation, then calculates the time until blocks and
> transactions reach a certain percentile of the nodes in the network.
> There is also a detailed page showing the density function describing
> at what times nodes learn about the existence of a block/transaction
> (for example yesterdays distribution:
> http://bitcoinstats.com/network/propagation/2013/11/23).
>=20
> I intend to add more information and plots over time, but I wanted to
> push this out quickly as there were some people asking for it. Hope
> this helps getting the blockchain fork rate down :-)
Do you have the resources to save the raw log data? You'll also need to
save transaction timestamp data - whether or not a given node has a
transaction already matters re: propagation.
Of course given pool centralization the moment pools start peering
directly with each other all these stats might not mean all that much.
Note that the number that's important isn't seconds, rather rather
seconds/actual block interval as long as hashing power is growing.
Unfortunately actually determining that is tricky - block interval is
inherently noisy so you'll want to use a fairly agressively smoothed
average.
So here's a rough calculation: right now blocks are happening roughly
%15 faster than they would at equilibrium, and blockchain.info reports
about 2 orphans a day. 2/166=3D1.2% orphan rate.
Now with a simplistic model where it takes exactly t seconds for a block
to propagate to 100% of the hashing power, and until then 0% has it,
you'd get:
orphan rate =3D t / actual block interval -> t =3D rate * interval
Or 6.2 seconds with our orphan rate data. Now whether or not
blockchain.info succesfully captures all orphans I don't know, but given
you're reporting 4.5 to 9.4 seconds for 50th and 75th percentile
respectively that number 6.2s seems "ballpark" reasonable - remember
that hashing power is definitely not distributed evenly among the nodes
you are sampling from.
Which is another point... it may be the case that your propagation data
doesn't actually give any insight into real-world orphan rates because
the distribution of hashing power is concentrated into pools.
--=20
'peter'[:-1]@petertodd.org
00000000000000064bb57c6681a117371f06c4efe26917d9179a56cc20cff9f2
--6sX45UoQRIJXqkqR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJSkjOmXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDY0YmI1N2M2NjgxYTExNzM3MWYwNmM0ZWZlMjY5MTdkOTE3
OWE1NmNjMjBjZmY5ZjIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftC1AgAnvcCatx0AyVn37ayPSjPyVDi
tYf1X0FJuAwRNV4JkA4oiH5FZBLQ3dcQ1rOrPHWwdFhxdFOY2J9pDZl9Imf8QXYk
EwmWKZ/yYth+4IyWTT5JeWw+tbngKPLgtCwKyxQngNba+KKVH7nUWyz9mten4eg9
DKMDo7dat8kk9XThoHhb/W9txlT781noryiXlDpvk6fQgAgG7Os+cQceb1r0JyqE
weTUQokGhCpHHIuFvotZgof28NLTdRfr7hkIj+GPAM4two6VzVa2wHyATSSsGcmE
xF1ZUrJE2t25SD1xf6Ly+tlDzlqErI8GMWH6vAMDLIFFcIMlo1PfF/+AUKMOow==
=mxME
-----END PGP SIGNATURE-----
--6sX45UoQRIJXqkqR--
|
