From: Zell Faze <zellfaze@yahoo•com>
To: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
Date: Mon, 30 Apr 2012 13:02:47 -0700 (PDT) [thread overview]
Message-ID: <1335816167.89493.YahooMailClassic@web120904.mail.ne1.yahoo.com> (raw)
In-Reply-To: <1335813078.98321.YahooMailNeo@web121004.mail.ne1.yahoo.com>
Although quite true, I actually agree though that there should be some sort of checksum for the blocks. Bandwidth may not be a bottleneck now (or ever), but it may be at some point. This change will help Bitcoin scale.
------------------------
"It stopped being just a website a long time ago. For many of us, most of us, Wikipedia has become an indispensable part of our daily lives."
— Jimmy Wales, Founder of Wikipedia
Help protect it now. Please make a donation today: http://www.wikimediafoundation.org/wiki/Donate
--- On Mon, 4/30/12, Amir Taaki <zgenjix@yahoo•com> wrote:
> From: Amir Taaki <zgenjix@yahoo•com>
> Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks
> To: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
> Date: Monday, April 30, 2012, 3:11 PM
> This is optimisation where it isn't
> needed. Bandwidth is not the bottleneck of the Bitcoin
> system. It is the immense time needed to validate the
> blockchain.
>
> And clients should never send blocks first. They always send
> an inv packet, then you request the block. It is a
> disruptive change and brings little.
>
> We don't need to optimise every aspect of Bitcoin :) Just
> focus on the big bits that matter, while keeping everything
> working with minimal changes.
>
> For instance say we did this and to maintain backwards
> compatible, we introduced a new message called "hash+block".
> Now there are 2 code branches that must be maintained -
> urgh.
>
>
> ________________________________
> From: Wladimir <laanwj@gmail•com>
> To: Rebroad (sourceforge) <rebroad+sourceforge.net@gmail•com>
>
> Cc: bitcoin-development@lists•sourceforge.net
>
> Sent: Monday, April 30, 2012 7:26 PM
> Subject: Re: [Bitcoin-development] BIP to improve the
> availability of blocks
>
>
> 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
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and
> threat landscape has changed and how IT managers can
> respond. Discussions
> will include endpoint security, mobile security and the
> latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and
> threat landscape has changed and how IT managers can
> respond. Discussions
> will include endpoint security, mobile security and the
> latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2012-04-30 20:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-30 16:40 Rebroad (sourceforge)
2012-04-30 18:26 ` Wladimir
2012-04-30 19:11 ` Amir Taaki
2012-04-30 20:02 ` Zell Faze [this message]
2012-04-30 20:54 ` Peter Vessenes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1335816167.89493.YahooMailClassic@web120904.mail.ne1.yahoo.com \
--to=zellfaze@yahoo$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox