📅 Original date posted:2013-05-01
📝 Original message:On Wed, May 1, 2013 at 10:05 AM, Andy Parkins <andyparkins at gmail.com> 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 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.
[...]
>> 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?
That posits -expanding- blocks from their native form into a larger
form, and then squashing them back down again upon request. A lot of
extra work from the point of view of clients downloading blocks
themselves.
But sure, if you want to do it, yes, it is possible to design an
interface like that.
>> 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.
Correct, Apache today could easily serve an HTTP-based layout of
blkNNNN.dat, plus a tiny JSON metadata file.
That's not "no schema", just a different layout.
>> 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 ;-)
In the context of this thread: distributing and downloading blocks.
All current users require the native binary block format.
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 nice addition to bitcoind.
That is a separate topic for a separate email thread, though.
As an example, see the pull request I wrote for an HTTP REST interface
that downloads an encrypted wallet backup:
https://github.com/bitcoin/bitcoin/pull/1982
--
Jeff Garzik
exMULTI, Inc.
jgarzik at exmulti.com
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 15:01:13
in reply to nevent1q…2mmh
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 15:01:13Event JSON
{
"id": "9740a0f71b09a1ce9f2de73e0cee6f2ca3505c34a8c6ca166491e7cce4eb9ab3",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686150073,
"kind": 1,
"tags": [
[
"e",
"fe608d065ddcdb6901f8485589a6ac2fc445c89eb0eaf770225c0787d32f7402",
"",
"root"
],
[
"e",
"3cee4290490054191b25dc3a07fced0899bd5fd7b905925d8b58713106e50567",
"",
"reply"
],
[
"p",
"99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59"
]
],
"content": "📅 Original date posted:2013-05-01\n📝 Original message:On Wed, May 1, 2013 at 10:05 AM, Andy Parkins \u003candyparkins at gmail.com\u003e wrote:\n\u003e On Tuesday 30 April 2013 21:11:47 Jeff Garzik wrote:\n\u003e\n\u003e\u003e Hardly. The storage format is bitcoin protocol wire format, plus a\n\u003e\u003e tiny header. It is supported in multiple applications already, and is\n\u003e\u003e the most efficient storage format for bitcoin protocol blocks.\n\u003e\n\u003e \"Most efficient\" for what purpose? There is more that one might do than just\n\u003e duplicate bitcoind exactly. I can well imagine storing bitcoin blocks parsed\n\u003e and separated out into database fields.\n[...]\n\u003e\u003e You don't have to create anything on the fly, if you store blocks in\n\u003e\u003e their native P2P wire protocol format.\n\u003e\n\u003e If. What if I'm writing a client and don't want to store them the way\n\u003e bitcoind has?\n\nThat posits -expanding- blocks from their native form into a larger\nform, and then squashing them back down again upon request. A lot of\nextra work from the point of view of clients downloading blocks\nthemselves.\n\nBut sure, if you want to do it, yes, it is possible to design an\ninterface like that.\n\n\n\u003e\u003e This is a whole new client interface. It's fun to dream this up, but\n\u003e\u003e it is far outside the scope of an efficient HTTP protocol that\n\u003e\u003e downloads blocks.\n\u003e\n\u003e Except the alternative is no schema at all -- essentially it's just give\n\u003e access to a file on disk. Well, that hardly needs discussion at all, and it\n\u003e hardly needs the involvement of bitcoind, apache could do it right now.\n\nCorrect, Apache today could easily serve an HTTP-based layout of\nblkNNNN.dat, plus a tiny JSON metadata file.\n\nThat's not \"no schema\", just a different layout.\n\n\u003e\u003e Your proposal is closer to a full P2P rewrite over HTTP (or a proxy\n\u003e\u003e thereof).\n\u003e\n\u003e I don't think it's a \"rewrite\". The wire protocol is only a small part of\n\u003e what bitcoind does. Adding another thread listening for HTTP requests at the\n\u003e same time as on 8333 for stadnard format.\n\u003e\n\u003e Anyway -- I've obviously misunderstood what the idea behind a HTTP protocol\n\u003e was, and it's not like I was volunteering to do any of the work ;-)\n\nIn the context of this thread: distributing and downloading blocks.\nAll current users require the native binary block format.\n\nA generalized HTTP REST query protocol would be a nice addition... it\nis just off-topic for this thread. On IRC yesterday, we discussed an\nHTTP query interface like you suggested. It was agreed that it was a\nnice interface, and might be a nice addition to bitcoind.\n\nThat is a separate topic for a separate email thread, though.\n\nAs an example, see the pull request I wrote for an HTTP REST interface\nthat downloads an encrypted wallet backup:\n https://github.com/bitcoin/bitcoin/pull/1982\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com",
"sig": "5d7df1fafe9410d3e83f73c2192a71f0e48f64e9975e17721aa35b7c6052e8a16f2f0de1515683e83110df8a880c0dde88d9c2c22945460bb84b732bd6047249"
}