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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <rebroad@gmail.com>) id 1SOteZ-0005Ex-Jn
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Apr 2012 16:40:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=rebroad@gmail.com;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SOteX-0000ho-CJ
for bitcoin-development@lists.sourceforge.net;
Mon, 30 Apr 2012 16:40:47 +0000
Received: by wgbds1 with SMTP id ds1so2620249wgb.4
for <bitcoin-development@lists.sourceforge.net>;
Mon, 30 Apr 2012 09:40:39 -0700 (PDT)
Received: by 10.180.104.230 with SMTP id gh6mr16918898wib.22.1335804039195;
Mon, 30 Apr 2012 09:40:39 -0700 (PDT)
MIME-Version: 1.0
Sender: rebroad@gmail.com
Received: by 10.223.96.135 with HTTP; Mon, 30 Apr 2012 09:40:18 -0700 (PDT)
From: "Rebroad (sourceforge)" <rebroad+sourceforge.net@gmail.com>
Date: Mon, 30 Apr 2012 17:40:18 +0100
X-Google-Sender-Auth: Fj97G0thFLdsg4-Gq1VOzJihSH0
Message-ID: <CAFBxzABqQBNdy9SbrKeePLsMdwwXDE7ghifh1GoOWscmpAZ+Tw@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(rebroad[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: 1SOteX-0000ho-CJ
Subject: [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 16:40:47 -0000
Dear Bitcoin developers,
In brief, the proposal I have is to extend the protocol to allow
partial block download and upload. This is for people with
intermittent connectivity or restricted connectivity. e.g. my own
internet connection is quite slow, and my ISP routinely sends RSTs to
both sides of connections to severe them. This often happens during
block download and upload. I also often encounter the reception of
blocks I have already received, further wasting bandwidth. This
happens as quite often it can be far more than 2 minutes before block
reception occurs following the getdata request, by which time my node
has already sent a new getdata to another node requesting the same
block.
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.
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.
Currently, without this=A0functionality, 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.
Hopefully, not too clueless a post for my first post to this mailing list.
Regards,
Ed
|
