On Tuesday 30 April 2013 21:11:47 Jeff Garzik wrote:
Hardly. The storage format is bitcoin protocol wire format, plus a
tiny header. It is supported in multiple applications already, and is
the most efficient storage format for bitcoin protocol blocks.
Most efficient for what purpose?
On Wednesday 01 May 2013 15:26:57 Jeff Garzik wrote:
A generalized HTTP REST query protocol would be a nice addition... it
is just off-topic for this thread. On IRC yesterday, we discussed an
HTTP query interface like you suggested. It was agreed that it was a
nice interface, and might be a
As part of a roadmap for block downloading, I think this may be a good time
to look into providing an HTTP/HTTPS protocol for block downloading - this
would also allow web proxies to cache blocks and thus make it more
accessible, as well as cater for resumeable downloads.
On Tue, Apr 30, 2013 at 12:14 PM, Rebroad (sourceforge)
rebroad+sourceforge@gmail.com wrote:
As part of a roadmap for block downloading, I think this may be a good time
to look into providing an HTTP/HTTPS protocol for block downloading - this
would also allow web proxies to cache blocks
On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote:
The format currently used by bitcoind would be just fine --
blocks/blk.dat for raw data, size-limited well below 1GB. Just
need to add a small metadata download, and serve the raw block files.
That doesn't seem very generic. It's tied
On Tue, Apr 30, 2013 at 3:27 PM, Andy Parkins andypark...@gmail.com wrote:
On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote:
The format currently used by bitcoind would be just fine --
blocks/blk.dat for raw data, size-limited well below 1GB. Just
need to add a small metadata
And then the problem of what domain name to use - ideally a single name
would be used so caches had the maximum chance to reuse content. To
keep the network distributed perhaps the existing DNS seed mechanism
could be used - a few names, each serving a random bitcoind's address.
Put :8333
7 matches
Mail list logo
