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
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pmlyon@hotmail.ca>) id 1WcGzh-0002Mj-OB
for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 16:22:57 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of hotmail.ca
designates 65.55.111.108 as permitted sender)
client-ip=65.55.111.108; envelope-from=pmlyon@hotmail.ca;
helo=blu0-omc2-s33.blu0.hotmail.com;
Received: from blu0-omc2-s33.blu0.hotmail.com ([65.55.111.108])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WcGze-0005tw-GJ for bitcoin-development@lists.sourceforge.net;
Mon, 21 Apr 2014 16:22:57 +0000
Received: from BLU170-W75 ([65.55.111.72]) by blu0-omc2-s33.blu0.hotmail.com
with Microsoft SMTPSVC(6.0.3790.4675);
Mon, 21 Apr 2014 09:22:49 -0700
X-TMN: [mhRkwfiJVGvpp3N17HUrzouvFaQUBTNM]
X-Originating-Email: [pmlyon@hotmail.ca]
Message-ID: <BLU170-W757A725FD907FDC49BF9F2A55E0@phx.gbl>
Content-Type: multipart/alternative;
boundary="_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_"
From: Paul Lyon <pmlyon@hotmail.ca>
To: Mark Friedenbach <mark@monetize.io>, Peter Todd <pete@petertodd.org>,
Jonathan Levin <jonathan.levin@sant.ox.ac.uk>
Date: Mon, 21 Apr 2014 13:22:48 -0300
Importance: Normal
In-Reply-To: <53554089.1010503@monetize.io>
References: <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>,
<52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk>,
<CACh7GpFGEvR+_qArYCkgi7AW4coSeH741ob4hmBpj6G3MayNAQ@mail.gmail.com>,
<a9a262a9-c70f-470d-81e0-ca32c41d8dc5@email.android.com>,
<53554089.1010503@monetize.io>
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Apr 2014 16:22:49.0160 (UTC)
FILETIME=[EFBEFC80:01CF5D7D]
X-Spam-Score: -0.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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pmlyon[at]hotmail.ca)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [65.55.111.108 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WcGze-0005tw-GJ
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Economics of information propagation
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, 21 Apr 2014 16:22:57 -0000
--_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I haven't done the math on this=2C so it may be a terrible idea. :)
I've been wondering if block propagation times could also be improved by al=
lowing peers to request the list of transaction hashes that make up a block=
=2C and then making a follow-up request to only download any transactions n=
ot currently known. I'm not sure what percentage of transactions a node wil=
l usually already have when it receives a new block=2C but if it's high I f=
igure this could be beneficial.
> Date: Mon=2C 21 Apr 2014 09:00:09 -0700
> From: mark@monetize.io
> To: pete@petertodd.org=3B jonathan.levin@sant.ox.ac.uk
> CC: bitcoin-development@lists.sourceforge.net
> Subject: Re: [Bitcoin-development] Economics of information propagation
>=20
> That wasn't what I was saying. Right now the primacy of a block is
> determined by the time at which the `block` message is received=2C which
> is delays due to both the time it takes to transmit the block data and
> the time it takes to validate. Headers-first=2C on the other hand=2C has =
the
> option of basing primacy on the time the block header is received=2C whic=
h
> is O(1) time to transmit and to SPV-validate. Mining on that block
> doesn't actually commence until the full block is received and validated.
>=20
> To see how this works=2C take an example: two blocks with a common parent
> are found relatively close to each other=2C block A and block B. A is
> found first but is a large block with the maximum block size and many
> slow scripts. B is found a few seconds later and is an empty block. In
> the current regime it is entirely possible that block B=2C the later but
> smaller block=2C would get received and processed first by more mining
> peers than the larger block A=2C exactly as described in Jonathan Levin's
> email.
>=20
> With headers-first=2C however=2C the cost of propagation of the block hea=
der
> is the same and we should expect block A to win out over block B nearly
> every time. Miners will continue working on the old=2C known valid parent
> block until the contents of block A are received and processed. So the
> smaller block B is still found=2C and since it's data moves across the
> network faster=2C miners even briefly mine on block B. But as soon as the=
y
> receive and process the contents of block A=2C they switch to that.
>=20
> The earlier=2C larger block A will only become stale if *two* blocks are
> found in the extra time it takes for block A to propagate the network.
> That is a substantially different risk=2C and probably a negligible
> concern to most miners.
>=20
> On 04/20/2014 09:06 PM=2C Peter Todd wrote:
> > That is mistaken: you can't mine on top of just a block header=2C
> > leaving small miners disadvantaged as they are earning no profit
> > while they wait for the information to validate the block and update
> > their UTXO sets. This results in the same problem as before=2C as the
> > large pools who mine most blocks can validate either instantly - the
> > self-mine case - or more quickly than the smaller miners.
> >=20
> > Of course=2C in reality smaller miners can just mine on top of block
> > headers and include no transactions and do no validation=2C but that is
> > extremely harmful to the security of Bitcoin.
>=20
> -------------------------------------------------------------------------=
-----
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social=2C Extensible=2C Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
=
--_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>I haven't done the math on this=
=2C so it may be a terrible idea. :)<div><br></div><div>I've been wondering=
if block propagation times could also be improved by allowing peers to req=
uest the list of transaction hashes that make up a block=2C and then making=
a follow-up request to only download any transactions not currently known.=
I'm not sure what percentage of transactions a node will usually already h=
ave when it receives a new block=2C but if it's high I figure this could be=
beneficial.<br><br><div>>=3B Date: Mon=2C 21 Apr 2014 09:00:09 -0700<br>=
>=3B From: mark@monetize.io<br>>=3B To: pete@petertodd.org=3B jonathan.=
levin@sant.ox.ac.uk<br>>=3B CC: bitcoin-development@lists.sourceforge.net=
<br>>=3B Subject: Re: [Bitcoin-development] Economics of information prop=
agation<br>>=3B <br>>=3B That wasn't what I was saying. Right now the p=
rimacy of a block is<br>>=3B determined by the time at which the `block` =
message is received=2C which<br>>=3B is delays due to both the time it ta=
kes to transmit the block data and<br>>=3B the time it takes to validate.=
Headers-first=2C on the other hand=2C has the<br>>=3B option of basing p=
rimacy on the time the block header is received=2C which<br>>=3B is O(1) =
time to transmit and to SPV-validate. Mining on that block<br>>=3B doesn'=
t actually commence until the full block is received and validated.<br>>=
=3B <br>>=3B To see how this works=2C take an example: two blocks with a =
common parent<br>>=3B are found relatively close to each other=2C block A=
and block B. A is<br>>=3B found first but is a large block with the maxi=
mum block size and many<br>>=3B slow scripts. B is found a few seconds la=
ter and is an empty block. In<br>>=3B the current regime it is entirely p=
ossible that block B=2C the later but<br>>=3B smaller block=2C would get =
received and processed first by more mining<br>>=3B peers than the larger=
block A=2C exactly as described in Jonathan Levin's<br>>=3B email.<br>&g=
t=3B <br>>=3B With headers-first=2C however=2C the cost of propagation of=
the block header<br>>=3B is the same and we should expect block A to win=
out over block B nearly<br>>=3B every time. Miners will continue working=
on the old=2C known valid parent<br>>=3B block until the contents of blo=
ck A are received and processed. So the<br>>=3B smaller block B is still =
found=2C and since it's data moves across the<br>>=3B network faster=2C m=
iners even briefly mine on block B. But as soon as they<br>>=3B receive a=
nd process the contents of block A=2C they switch to that.<br>>=3B <br>&g=
t=3B The earlier=2C larger block A will only become stale if *two* blocks a=
re<br>>=3B found in the extra time it takes for block A to propagate the =
network.<br>>=3B That is a substantially different risk=2C and probably a=
negligible<br>>=3B concern to most miners.<br>>=3B <br>>=3B On 04/20=
/2014 09:06 PM=2C Peter Todd wrote:<br>>=3B >=3B That is mistaken: you =
can't mine on top of just a block header=2C<br>>=3B >=3B leaving small =
miners disadvantaged as they are earning no profit<br>>=3B >=3B while t=
hey wait for the information to validate the block and update<br>>=3B >=
=3B their UTXO sets. This results in the same problem as before=2C as the<b=
r>>=3B >=3B large pools who mine most blocks can validate either instan=
tly - the<br>>=3B >=3B self-mine case - or more quickly than the smalle=
r miners.<br>>=3B >=3B <br>>=3B >=3B Of course=2C in reality smalle=
r miners can just mine on top of block<br>>=3B >=3B headers and include=
no transactions and do no validation=2C but that is<br>>=3B >=3B extre=
mely harmful to the security of Bitcoin.<br>>=3B <br>>=3B -------------=
-----------------------------------------------------------------<br>>=3B=
Start Your Social Network Today - Download eXo Platform<br>>=3B Build yo=
ur Enterprise Intranet with eXo Platform Software<br>>=3B Java Based Open=
Source Intranet - Social=2C Extensible=2C Cloud Ready<br>>=3B Get Starte=
d Now And Turn Your Intranet Into A Collaboration Platform<br>>=3B http:/=
/p.sf.net/sfu/ExoPlatform<br>>=3B _______________________________________=
________<br>>=3B Bitcoin-development mailing list<br>>=3B Bitcoin-devel=
opment@lists.sourceforge.net<br>>=3B https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development<br></div></div> </div></body>
</html>=
--_3823cccf-ed2a-4e2b-adbf-e246c42a35aa_--
|
