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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1SOvIv-0008Ad-0q
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Apr 2012 18:26:33 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.46 as permitted sender)
client-ip=209.85.210.46; envelope-from=laanwj@gmail.com;
helo=mail-pz0-f46.google.com;
Received: from mail-pz0-f46.google.com ([209.85.210.46])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SOvIu-000240-4B
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Apr 2012 18:26:32 +0000
Received: by dadz9 with SMTP id z9so4993280dad.33
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Apr 2012 11:26:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.241.70 with SMTP id wg6mr5050776pbc.126.1335810386315; Mon,
30 Apr 2012 11:26:26 -0700 (PDT)
Received: by 10.142.217.1 with HTTP; Mon, 30 Apr 2012 11:26:26 -0700 (PDT)
In-Reply-To: <CAFBxzABqQBNdy9SbrKeePLsMdwwXDE7ghifh1GoOWscmpAZ+Tw@mail.gmail.com>
References: <CAFBxzABqQBNdy9SbrKeePLsMdwwXDE7ghifh1GoOWscmpAZ+Tw@mail.gmail.com>
Date: Mon, 30 Apr 2012 20:26:26 +0200
Message-ID: <CA+s+GJCy4Utm14S_2KWofSORfsVuTJBYpwB0a7M26XHn1QQVYw@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: "Rebroad (sourceforge)" <rebroad+sourceforge.net@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3395a5904b2504bee997fb
X-Spam-Score: -0.6 (/)
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
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1SOvIu-000240-4B
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
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, 30 Apr 2012 18:26:33 -0000
--047d7b3395a5904b2504bee997fb
Content-Type: text/plain; charset=UTF-8
On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) <
rebroad+sourceforge.net@gmail.com> wrote:
>
> My proposal is that in addition to the size (which is advertised in
> the header), the hash is also advertised in the header (of a block).
> This would help nodes to determine whether they wanted to reject the
> download. (e.g. if it already had a block matching that hash). This of
> course wouldn't prevent a rogue node from sending an incorrect hash,
> but this would aid in saving bandwidth amongst behaving nodes.
>
I suppose it would make sense for clients to be able to reject blocks that
they already have, if that's not currently possible.
The other part of the proposal is to allow nodes to request upload and
> download blocks that have already been partially downloaded.
>
> This could be done by modifying the existing methods of upload,
> download, or by adding a new method, perhaps even using HTTP/HTTPS or
> something similar. This would also help nodes to obtain the blockchain
> who have restrictive ISPs, especially if they are being served on port
> 80 or 443. This could perhaps also allow web caches to keep caches of
> the blockchain, thereby making it also more available also.
>
You don't need a BIP if you want to somehow fetch the (initial) block chain
outside the bitcoin protocol. You could download it from some http server
or even pass it along on an USB stick. Then with a simple client change you
can import it: https://github.com/bitcoin/bitcoin/pull/883 .
Currently, without this functionality, nodes with restrictive (or
> slow) internet have some options, such as going via a tor proxy, but
> due to the latency, the problem with multiple receptions of the same
> block still occur.
>
If you're behind such a slow internet connection, and concerned about every
bit of bandwidth, it is better to run a lightweight node. For example,
Electrum.
Even if you could reduce the wasted bandwidth a bit by puzzling around with
partial blocks, the download will still be substantial (and that's going to
get worse before it gets better).
Wladimir
--047d7b3395a5904b2504bee997fb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) <span dir=3D"ltr">&l=
t;<a href=3D"mailto:rebroad+sourceforge.net@gmail.com" target=3D"_blank">re=
broad+sourceforge.net@gmail.com</a>></span> wrote: <br><div class=3D"gma=
il_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My proposal is that in addition to the size (which is advertised in<br>
the header), the hash is also advertised in the header (of a block).<br>
This would help nodes to determine whether they wanted to reject the<br>
download. (e.g. if it already had a block matching that hash). This of<br>
course wouldn't prevent a rogue node from sending an incorrect hash,<br=
>
but this would aid in saving bandwidth amongst behaving nodes.<br></blockqu=
ote><div><br>I suppose it would make sense for clients to be able to reject=
blocks that they already have, if that's not currently possible.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The other part of the proposal is to allow nodes to request upload and<br>
download blocks that have already been partially downloaded.<br>
<br>
This could be done by modifying the existing methods of upload,<br>
download, or by adding a new method, perhaps even using HTTP/HTTPS or<br>
something similar. This would also help nodes to obtain the blockchain<br>
who have restrictive ISPs, especially if they are being served on port<br>
80 or 443. This could perhaps also allow web caches to keep caches of<br>
the blockchain, thereby making it also more available also.<br></blockquote=
><div><br>You don't need a BIP if you want to somehow fetch the (initia=
l) block chain=20
outside the bitcoin protocol. You could download it from some http=20
server or even pass it along on an USB stick. Then with a simple client cha=
nge you can import it: <a href=3D"https://github.com/bitcoin/bitcoin/pull/8=
83">https://github.com/bitcoin/bitcoin/pull/883</a> .<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex">
Currently, without this=C2=A0functionality, nodes with restrictive (or<br>
slow) internet have some options, such as going via a tor proxy, but<br>
due to the latency, the problem with multiple receptions of the same<br>
block still occur.<br></blockquote><div><br>If you're behind such a slo=
w internet connection, and concerned about=20
every bit of bandwidth, it is better to run a lightweight node. For example=
, Electrum.<br>
<br>Even if you could reduce the wasted bandwidth a bit by puzzling=20
around with partial blocks, the download will still be substantial (and tha=
t's going to get worse before it gets better). <br><br>Wladimir<br><br>=
</div></div>
--047d7b3395a5904b2504bee997fb--
|
