MIME-Version: 1.0
In-Reply-To: <201305011505.03860.andyparkins@gmail.com>
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
	<201304302027.10247.andyparkins@gmail.com>
	<CA+8xBpfUVsX5CrJMrJRks4pa5g2Sko41cMXewYfvw_ZrPcxeQg@mail.gmail.com>
	<201305011505.03860.andyparkins@gmail.com>
Date: Wed, 1 May 2013 10:26:57 -0400
Message-ID: <CA+8xBpeKN4oFJb9UP_-cEX4w+VeBg1qZBFweuVybNpPt2Yms6w@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
Precedence: list

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