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 b
On Wed, May 1, 2013 at 10:05 AM, Andy Parkins wrote:
> 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 bi
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?
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 after
On Tue, Apr 30, 2013 at 3:27 PM, Andy Parkins 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 download, and serve th
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 ti
On Tue, Apr 30, 2013 at 12:14 PM, Rebroad (sourceforge)
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 and thus make it more
> accessibl
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.
--
8 matches
Mail list logo
