From: Peter Todd <pete@petertodd.org>
To: Christian Decker <decker.christian@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Network propagation speeds
Date: Sun, 24 Nov 2013 12:13:10 -0500 [thread overview]
Message-ID: <20131124171310.GB16143@savin> (raw)
In-Reply-To: <CALxbBHWwQXjjET+-GFTKNFPd_yWPjEWGvS-YwUPL+z86J8sw0Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2717 bytes --]
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.
>
> 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).
>
> 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=1.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 = t / actual block interval -> t = 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.
--
'peter'[:-1]@petertodd.org
00000000000000064bb57c6681a117371f06c4efe26917d9179a56cc20cff9f2
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
prev parent reply other threads:[~2013-11-24 17:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-24 16:20 [Bitcoin-development] Network propagation speeds Christian Decker
2013-11-24 16:26 ` Gregory Maxwell
2013-11-24 16:37 ` Christian Decker
2013-11-25 8:51 ` Michael Gronager
2013-11-25 19:27 ` Christian Decker
2013-11-27 19:35 ` Mike Hearn
2013-11-27 20:46 ` Christian Decker
2013-11-24 16:38 ` Mike Hearn
2013-11-24 17:13 ` Peter Todd [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131124171310.GB16143@savin \
--to=pete@petertodd.org \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=decker.christian@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox