Re: [Bitcoin-development] Fwd: Service bits for pruned nodes

[Andy Parkins <andyparkins@gmail.com>]

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?  There is more that one might do than just 
duplicate bitcoind exactly.  I can well imagine storing bitcoin blocks parsed 
and separated out into database fields.

> > Wouldn't it be better to add support for more bitcoin-protocol-oriented
> > HTTP requests?  Then any client can supply the same interface, rather
> > than being forced to create blkNNNN.dat on the fly?
> 
> You don't have to create anything on the fly, if you store blocks in
> their native P2P wire protocol format.

If.  What if I'm writing a client and don't want to store them the way 
bitcoind has?

> This is a whole new client interface.  It's fun to dream this up, but
> it is far outside the scope of an efficient HTTP protocol that
> downloads blocks.

Except the alternative is no schema at all -- essentially it's just give 
access to a file on disk.  Well, that hardly needs discussion at all, and it 
hardly needs the involvement of bitcoind, apache could do it right now.

> Your proposal is closer to a full P2P rewrite over HTTP (or a proxy
> thereof).

I don't think it's a "rewrite".  The wire protocol is only a small part of 
what bitcoind does.  Adding another thread listening for HTTP requests at the 
same time as on 8333 for stadnard format.

Anyway -- I've obviously misunderstood what the idea behind a HTTP protocol 
was, and it's not like I was volunteering to do any of the work ;-)



Andy

-- 
Dr Andy Parkins
andyparkins@gmail.com