From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UXXzt-00030E-6p for bitcoin-development@lists.sourceforge.net; Wed, 01 May 2013 14:27:05 +0000 X-ACL-Warn: Received: from mail-da0-f43.google.com ([209.85.210.43]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UXXzs-0004Lj-0Z for bitcoin-development@lists.sourceforge.net; Wed, 01 May 2013 14:27:05 +0000 Received: by mail-da0-f43.google.com with SMTP id h21so692474dal.16 for ; Wed, 01 May 2013 07:26:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=PyKh+Jwb+olUpCQ+mM8D4LVTsUefV4oYO/jBpFjSPIk=; b=Ogont1LjxzlY9Uz2TSDCZ2I2XOYB35NprV9GM0c6TL0t5221Ia9aknsHhx87seTDvS E+0Q0Gn+Q+eUAZbbsxUVd3veAdRY1qp6rgGe+51GLYgl0CBNsQ86pTmFJnB8lVg7W+oi AzKzWHyDCvZH3/nUkbworxc4DdU1wl8jgeKqrsXjiPD5fBGNwLxfgRzBgceMPgVEsmQC 6kQK35CnwNeBOdEXwJhuz+woSNpXB2QngUyc1g9DxDX+TfFWzfw0tkoXPtjGQBPWdhB1 YMyjNJkthAP3wk7X1fQC3cNyff00ApXyRgNJmkWbDpPSoUOmkIUUYETh0BVTkDLrc+pb vUzA== MIME-Version: 1.0 X-Received: by 10.68.231.65 with SMTP id te1mr4369140pbc.98.1367418418030; Wed, 01 May 2013 07:26:58 -0700 (PDT) Received: by 10.68.240.106 with HTTP; Wed, 1 May 2013 07:26:57 -0700 (PDT) X-Originating-IP: [99.43.178.25] In-Reply-To: <201305011505.03860.andyparkins@gmail.com> References: <201304302027.10247.andyparkins@gmail.com> <201305011505.03860.andyparkins@gmail.com> Date: Wed, 1 May 2013 10:26:57 -0400 Message-ID: From: Jeff Garzik To: Andy Parkins Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm0ZVhh+DYrurwSJUuKeUbkjkDNcus2TEect3zOf+o+l32TUPfUKnSCeqMtvoud0eodAhGt X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1UXXzs-0004Lj-0Z Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Fwd: Service bits for pruned nodes X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 14:27:05 -0000 On Wed, May 1, 2013 at 10:05 AM, Andy Parkins 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