diff options
| author | Rebroad (sourceforge) <rebroad+sourceforge.net@gmail.com> | 2012-04-30 17:40:18 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-04-30 16:40:47 +0000 |
| commit | 29f4b59cb5790ce9659269e5cda617dc28c3af10 (patch) | |
| tree | 6ea1896dc18e590b552eb0f3c123fe091b21cfa1 | |
| parent | 608dc87ede1a18476600ec4e0ed180208cbcb498 (diff) | |
| download | pi-bitcoindev-29f4b59cb5790ce9659269e5cda617dc28c3af10.tar.gz pi-bitcoindev-29f4b59cb5790ce9659269e5cda617dc28c3af10.zip | |
[Bitcoin-development] BIP to improve the availability of blocks
| -rw-r--r-- | 9f/33a1499857ae84a0ec400ddd805d4bb0d75e2a | 100 |
1 files changed, 100 insertions, 0 deletions
diff --git a/9f/33a1499857ae84a0ec400ddd805d4bb0d75e2a b/9f/33a1499857ae84a0ec400ddd805d4bb0d75e2a new file mode 100644 index 000000000..70d124932 --- /dev/null +++ b/9f/33a1499857ae84a0ec400ddd805d4bb0d75e2a @@ -0,0 +1,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 + + |