summaryrefslogtreecommitdiff
path: root/a2/9765fb879dbad12a10ce9e26c1497dac0ad7ad
blob: 173c5f73e9d7dca4332899d12096c39b5efcbfe5 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <decker.christian@gmail.com>) id 1Vl1p5-00065i-KV
	for bitcoin-development@lists.sourceforge.net;
	Mon, 25 Nov 2013 19:27:55 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.175 as permitted sender)
	client-ip=209.85.214.175;
	envelope-from=decker.christian@gmail.com;
	helo=mail-ob0-f175.google.com; 
Received: from mail-ob0-f175.google.com ([209.85.214.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Vl1p4-0006jR-Nw
	for bitcoin-development@lists.sourceforge.net;
	Mon, 25 Nov 2013 19:27:55 +0000
Received: by mail-ob0-f175.google.com with SMTP id uz6so4674683obc.20
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 25 Nov 2013 11:27:49 -0800 (PST)
X-Received: by 10.60.136.196 with SMTP id qc4mr7154623oeb.41.1385407669325;
	Mon, 25 Nov 2013 11:27:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.130.198 with HTTP; Mon, 25 Nov 2013 11:27:09 -0800 (PST)
In-Reply-To: <52930FA3.3070802@ceptacle.com>
References: <CALxbBHWwQXjjET+-GFTKNFPd_yWPjEWGvS-YwUPL+z86J8sw0Q@mail.gmail.com>
	<CAAS2fgQxBVOT1ceWWttH5e2wG7-qJ3LxKKnFBEqLwbz-OwDo3g@mail.gmail.com>
	<CALxbBHX9PACKFJM_-=0Hm7hO7Km7jnLNRk=pRcKYTAcPD4G5qg@mail.gmail.com>
	<52930FA3.3070802@ceptacle.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Mon, 25 Nov 2013 20:27:09 +0100
Message-ID: <CALxbBHUQaFd7zA+CW8GUNHE1FMhbmCy7NGgsfsdwnfNrck5xrA@mail.gmail.com>
To: Michael Gronager <gronager@ceptacle.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.6 (-)
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]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(decker.christian[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Vl1p4-0006jR-Nw
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: Mon, 25 Nov 2013 19:27:55 -0000

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