đ
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
Andy Parkins [ARCHIVE] /
npub1nxâŚ7wjrv
2023-06-07 15:01:12
in reply to nevent1qâŚfjgk
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 15:01:12Event JSON
{
"id": "3cee4290490054191b25dc3a07fced0899bd5fd7b905925d8b58713106e50567",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686150072,
"kind": 1,
"tags": [
[
"e",
"fe608d065ddcdb6901f8485589a6ac2fc445c89eb0eaf770225c0787d32f7402",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "đ
Original date posted:2013-05-01\nđ Original message:On Tuesday 30 April 2013 21:11:47 Jeff Garzik wrote:\n\n\u003e Hardly. The storage format is bitcoin protocol wire format, plus a\n\u003e tiny header. It is supported in multiple applications already, and is\n\u003e the most efficient storage format for bitcoin protocol blocks.\n\n\"Most efficient\" for what purpose? There is more that one might do than just \nduplicate bitcoind exactly. I can well imagine storing bitcoin blocks parsed \nand separated out into database fields.\n\n\u003e \u003e Wouldn't it be better to add support for more bitcoin-protocol-oriented\n\u003e \u003e HTTP requests? Then any client can supply the same interface, rather\n\u003e \u003e than being forced to create blkNNNN.dat on the fly?\n\u003e \n\u003e You don't have to create anything on the fly, if you store blocks in\n\u003e their native P2P wire protocol format.\n\nIf. What if I'm writing a client and don't want to store them the way \nbitcoind has?\n\n\u003e This is a whole new client interface. It's fun to dream this up, but\n\u003e it is far outside the scope of an efficient HTTP protocol that\n\u003e downloads blocks.\n\nExcept the alternative is no schema at all -- essentially it's just give \naccess to a file on disk. Well, that hardly needs discussion at all, and it \nhardly needs the involvement of bitcoind, apache could do it right now.\n\n\u003e Your proposal is closer to a full P2P rewrite over HTTP (or a proxy\n\u003e thereof).\n\nI don't think it's a \"rewrite\". The wire protocol is only a small part of \nwhat bitcoind does. Adding another thread listening for HTTP requests at the \nsame time as on 8333 for stadnard format.\n\nAnyway -- I've obviously misunderstood what the idea behind a HTTP protocol \nwas, and it's not like I was volunteering to do any of the work ;-)\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "c0f62db14eedb026f62d65ded603a38cebd118c3867986bf203d6f2a714195f4370d305462f9c9fa38786fa2aafaa4abf9ec3b18b46e08bc5e9cefac1d1aeb0b"
}