Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2013-05-01 📝 Original message:On Tuesday 30 April 2013 ...
📅 Original date posted:2013-05-01
📝 Original message: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 at gmail.com
📝 Original message: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 at gmail.com