From: Jeff Garzik <jgarzik@exmulti•com>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
Date: Wed, 1 May 2013 10:26:57 -0400 [thread overview]
Message-ID: <CA+8xBpeKN4oFJb9UP_-cEX4w+VeBg1qZBFweuVybNpPt2Yms6w@mail.gmail.com> (raw)
In-Reply-To: <201305011505.03860.andyparkins@gmail.com>
On Wed, May 1, 2013 at 10:05 AM, Andy Parkins <andyparkins@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@exmulti•com
next prev parent reply other threads:[~2013-05-01 14:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-28 15:51 [Bitcoin-development] " Pieter Wuille
2013-04-28 16:29 ` Mike Hearn
2013-04-28 16:44 ` Pieter Wuille
2013-04-28 16:57 ` Mike Hearn
2013-05-03 12:30 ` Pieter Wuille
2013-05-03 14:06 ` Mike Hearn
2013-05-03 14:18 ` Peter Todd
2013-05-03 15:02 ` Mike Hearn
2013-05-03 15:11 ` Peter Todd
2013-05-04 18:07 ` John Dillon
2013-05-04 18:55 ` Jeff Garzik
2013-05-05 13:12 ` John Dillon
2013-05-06 8:19 ` Mike Hearn
2013-05-06 13:13 ` Pieter Wuille
2013-04-28 19:50 ` Gregory Maxwell
2013-04-29 2:57 ` John Dillon
2013-04-29 3:36 ` Gregory Maxwell
2013-04-29 3:42 ` Robert Backhaus
2013-04-29 3:48 ` John Dillon
2013-04-29 3:55 ` Peter Todd
2013-04-29 6:10 ` Jay F
[not found] ` <CAFBxzACw=G7UgG853zQrM-Z1-B4VqSQR5YUJQ5n1=wnv7EyWsw@mail.gmail.com>
2013-04-30 16:14 ` [Bitcoin-development] Fwd: " Rebroad (sourceforge)
2013-04-30 18:04 ` Jeff Garzik
2013-04-30 19:27 ` Andy Parkins
2013-04-30 19:31 ` Simon Barber
2013-04-30 20:11 ` Jeff Garzik
2013-05-01 14:05 ` Andy Parkins
2013-05-01 14:26 ` Jeff Garzik [this message]
2013-05-01 14:34 ` Andy Parkins
2013-04-30 20:06 ` [Bitcoin-development] " Brenton Camac
2013-05-01 13:46 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+8xBpeKN4oFJb9UP_-cEX4w+VeBg1qZBFweuVybNpPt2Yms6w@mail.gmail.com \
--to=jgarzik@exmulti$(echo .)com \
--cc=andyparkins@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox