[Bitcoin-development] Network propagation speeds

[Bitcoin-development] Network propagation speeds

[Christian Decker]

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 :-)

Regards,
Chris
--
Christian Decker

Re: [Bitcoin-development] Network propagation speeds

[Gregory Maxwell]

On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
<decker.christian@gmail.com> 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.

Could you publish the block ids and timestamp sets for each block?

It would be useful in correlating propagation information against
block characteristics.

Re: [Bitcoin-development] Network propagation speeds

[Christian Decker]

Sure thing, I'm looking for a good way to publish these measurements,
but I haven't found a good option yet. They are rather large in size,
so I'd rather not serve them along with the website as it hasn't got
the capacity. Any suggestions? If the demand is not huge I could
provide them on a per user basis.
--
Christian Decker


On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
> <decker.christian@gmail.com> 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.
>
> Could you publish the block ids and timestamp sets for each block?
>
> It would be useful in correlating propagation information against
> block characteristics.

Re: [Bitcoin-development] Network propagation speeds

[Michael Gronager]

Hi Christian,

Cool - thanks for posting - agree, that it would be nice to normalize
the results with block size - so divide by size and:
1. see if there is a correlation (we all presume there still is)
2. plot the delay graph as e.g. normalized to the averaged blocksize or
lets define a "standard block size" of 200kb or what ever so we can
compare the plot btw days.

Also, does the correlation of propagation times hold for transaction
sizes as well (would be ice to find the logical t0 and the constant - I
guess the interesting measure is not kb but signatures, so number of
inputs - some correlation with size though).

Best,

Michael

On 24/11/13, 17:37 , Christian Decker wrote:
> Sure thing, I'm looking for a good way to publish these measurements,
> but I haven't found a good option yet. They are rather large in size,
> so I'd rather not serve them along with the website as it hasn't got
> the capacity. Any suggestions? If the demand is not huge I could
> provide them on a per user basis.
> --
> Christian Decker
> 
> 
> On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
>> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
>> <decker.christian@gmail.com> 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.
>>
>> Could you publish the block ids and timestamp sets for each block?
>>
>> It would be useful in correlating propagation information against
>> block characteristics.
> 
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing 
> conversations that shape the rapidly evolving mobile landscape. Sign up now. 
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

Re: [Bitcoin-development] Network propagation speeds

[Christian Decker]

Thanks Mike for the Tip :-)

I will definitely extend the calculations to include a size-normalized
version. As for transaction propagations, being much smaller the
measurements tend to be much noisier, but given enough samples we
might be able to reconstruct some of the system parameters.

Good idea to attempt to correlate propagation speed and number of
inputs/outputs, might be interesting to see whether processing at the
nodes has an influence.

Regards,
Chris
--
Christian Decker


On Mon, Nov 25, 2013 at 9:51 AM, Michael Gronager <gronager@ceptacle.com> wrote:
> Hi Christian,
>
> Cool - thanks for posting - agree, that it would be nice to normalize
> the results with block size - so divide by size and:
> 1. see if there is a correlation (we all presume there still is)
> 2. plot the delay graph as e.g. normalized to the averaged blocksize or
> lets define a "standard block size" of 200kb or what ever so we can
> compare the plot btw days.
>
> Also, does the correlation of propagation times hold for transaction
> sizes as well (would be ice to find the logical t0 and the constant - I
> guess the interesting measure is not kb but signatures, so number of
> inputs - some correlation with size though).
>
> Best,
>
> Michael
>
> On 24/11/13, 17:37 , Christian Decker wrote:
>> Sure thing, I'm looking for a good way to publish these measurements,
>> but I haven't found a good option yet. They are rather large in size,
>> so I'd rather not serve them along with the website as it hasn't got
>> the capacity. Any suggestions? If the demand is not huge I could
>> provide them on a per user basis.
>> --
>> Christian Decker
>>
>>
>> On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
>>> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
>>> <decker.christian@gmail.com> 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.
>>>
>>> Could you publish the block ids and timestamp sets for each block?
>>>
>>> It would be useful in correlating propagation information against
>>> block characteristics.
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Network propagation speeds

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]

Hey Christian,

Could you sort the snapshots by date? At the moment they're kind of in a
random order.

Sometimes I wish we had real-time stats too but this is a great start.


On Mon, Nov 25, 2013 at 8:27 PM, Christian Decker <
decker.christian@gmail.com> wrote:

> Thanks Mike for the Tip :-)
>
> I will definitely extend the calculations to include a size-normalized
> version. As for transaction propagations, being much smaller the
> measurements tend to be much noisier, but given enough samples we
> might be able to reconstruct some of the system parameters.
>
> Good idea to attempt to correlate propagation speed and number of
> inputs/outputs, might be interesting to see whether processing at the
> nodes has an influence.
>
> Regards,
> Chris
> --
> Christian Decker
>
>
> On Mon, Nov 25, 2013 at 9:51 AM, Michael Gronager <gronager@ceptacle.com>
> wrote:
> > Hi Christian,
> >
> > Cool - thanks for posting - agree, that it would be nice to normalize
> > the results with block size - so divide by size and:
> > 1. see if there is a correlation (we all presume there still is)
> > 2. plot the delay graph as e.g. normalized to the averaged blocksize or
> > lets define a "standard block size" of 200kb or what ever so we can
> > compare the plot btw days.
> >
> > Also, does the correlation of propagation times hold for transaction
> > sizes as well (would be ice to find the logical t0 and the constant - I
> > guess the interesting measure is not kb but signatures, so number of
> > inputs - some correlation with size though).
> >
> > Best,
> >
> > Michael
> >
> > On 24/11/13, 17:37 , Christian Decker wrote:
> >> Sure thing, I'm looking for a good way to publish these measurements,
> >> but I haven't found a good option yet. They are rather large in size,
> >> so I'd rather not serve them along with the website as it hasn't got
> >> the capacity. Any suggestions? If the demand is not huge I could
> >> provide them on a per user basis.
> >> --
> >> Christian Decker
> >>
> >>
> >> On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell <gmaxwell@gmail.com>
> wrote:
> >>> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
> >>> <decker.christian@gmail.com> 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.
> >>>
> >>> Could you publish the block ids and timestamp sets for each block?
> >>>
> >>> It would be useful in correlating propagation information against
> >>> block characteristics.
> >>
> >>
> ------------------------------------------------------------------------------
> >> Shape the Mobile Experience: Free Subscription
> >> Software experts and developers: Be at the forefront of tech innovation.
> >> Intel(R) Software Adrenaline delivers strategic insight and
> game-changing
> >> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Shape the Mobile Experience: Free Subscription
> > Software experts and developers: Be at the forefront of tech innovation.
> > Intel(R) Software Adrenaline delivers strategic insight and game-changing
> > conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 6485 bytes --]

Re: [Bitcoin-development] Network propagation speeds

[Christian Decker]

Damn, that happens if I do the overview as an afterthought. Fixed :-)

Real time (last 24 hours, last week, last month) are in the pipeline,
just need to find the time to implement access to the collector from
the webpage.
--
Christian Decker


On Wed, Nov 27, 2013 at 8:35 PM, Mike Hearn <mike@plan99.net> wrote:
> Hey Christian,
>
> Could you sort the snapshots by date? At the moment they're kind of in a
> random order.
>
> Sometimes I wish we had real-time stats too but this is a great start.
>
>
> On Mon, Nov 25, 2013 at 8:27 PM, Christian Decker
> <decker.christian@gmail.com> wrote:
>>
>> Thanks Mike for the Tip :-)
>>
>> I will definitely extend the calculations to include a size-normalized
>> version. As for transaction propagations, being much smaller the
>> measurements tend to be much noisier, but given enough samples we
>> might be able to reconstruct some of the system parameters.
>>
>> Good idea to attempt to correlate propagation speed and number of
>> inputs/outputs, might be interesting to see whether processing at the
>> nodes has an influence.
>>
>> Regards,
>> Chris
>> --
>> Christian Decker
>>
>>
>> On Mon, Nov 25, 2013 at 9:51 AM, Michael Gronager <gronager@ceptacle.com>
>> wrote:
>> > Hi Christian,
>> >
>> > Cool - thanks for posting - agree, that it would be nice to normalize
>> > the results with block size - so divide by size and:
>> > 1. see if there is a correlation (we all presume there still is)
>> > 2. plot the delay graph as e.g. normalized to the averaged blocksize or
>> > lets define a "standard block size" of 200kb or what ever so we can
>> > compare the plot btw days.
>> >
>> > Also, does the correlation of propagation times hold for transaction
>> > sizes as well (would be ice to find the logical t0 and the constant - I
>> > guess the interesting measure is not kb but signatures, so number of
>> > inputs - some correlation with size though).
>> >
>> > Best,
>> >
>> > Michael
>> >
>> > On 24/11/13, 17:37 , Christian Decker wrote:
>> >> Sure thing, I'm looking for a good way to publish these measurements,
>> >> but I haven't found a good option yet. They are rather large in size,
>> >> so I'd rather not serve them along with the website as it hasn't got
>> >> the capacity. Any suggestions? If the demand is not huge I could
>> >> provide them on a per user basis.
>> >> --
>> >> Christian Decker
>> >>
>> >>
>> >> On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell <gmaxwell@gmail.com>
>> >> wrote:
>> >>> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
>> >>> <decker.christian@gmail.com> 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.
>> >>>
>> >>> Could you publish the block ids and timestamp sets for each block?
>> >>>
>> >>> It would be useful in correlating propagation information against
>> >>> block characteristics.
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Shape the Mobile Experience: Free Subscription
>> >> Software experts and developers: Be at the forefront of tech
>> >> innovation.
>> >> Intel(R) Software Adrenaline delivers strategic insight and
>> >> game-changing
>> >> conversations that shape the rapidly evolving mobile landscape. Sign up
>> >> now.
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Bitcoin-development mailing list
>> >> Bitcoin-development@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Shape the Mobile Experience: Free Subscription
>> > Software experts and developers: Be at the forefront of tech innovation.
>> > Intel(R) Software Adrenaline delivers strategic insight and
>> > game-changing
>> > conversations that shape the rapidly evolving mobile landscape. Sign up
>> > now.
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up
>> now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

Re: [Bitcoin-development] Network propagation speeds

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]

This is great, thanks for doing it. Tip sent your way.

Graphs of how propagation data change over time would also be helpful (as
well as raw data so we can calculate overhead per kilobyte and so on). I
know there are only two days worth of data, but for future, it'd be good.

I think the next part of figuring out why there's such huge disparity is
instrumenting bitcoind to find out where the time goes when relaying a
block.


On Sun, Nov 24, 2013 at 5:26 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
> <decker.christian@gmail.com> 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.
>
> Could you publish the block ids and timestamp sets for each block?
>
> It would be useful in correlating propagation information against
> block characteristics.
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2431 bytes --]

Re: [Bitcoin-development] Network propagation speeds

[Peter Todd]

[-- 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 --]