1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
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 <jgarzik@exmulti.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 01 May 2013 14:27:05 -0000
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
|
