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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andyparkins@gmail.com>) id 1UXGCu-0000bs-6X
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Apr 2013 19:27:20 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=andyparkins@gmail.com;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UXGCt-00026a-AE
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Apr 2013 19:27:20 +0000
Received: by mail-wg0-f41.google.com with SMTP id e11so3348825wgh.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 30 Apr 2013 12:27:13 -0700 (PDT)
X-Received: by 10.180.21.167 with SMTP id w7mr26828984wie.2.1367350033190;
Tue, 30 Apr 2013 12:27:13 -0700 (PDT)
Received: from momentum.localnet ([91.84.15.31])
by mx.google.com with ESMTPSA id q13sm31046979wie.8.2013.04.30.12.27.11
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Tue, 30 Apr 2013 12:27:12 -0700 (PDT)
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Date: Tue, 30 Apr 2013 20:27:10 +0100
User-Agent: KMail/1.13.7 (Linux/3.8-trunk-686-pae; KDE/4.8.4; i686; ; )
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
<CAFBxzACmpODv-zvDb39TBpydSinwQ__BaPJfoVBeg==m7RLwrA@mail.gmail.com>
<CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
In-Reply-To: <CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201304302027.10247.andyparkins@gmail.com>
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(andyparkins[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UXGCt-00026a-AE
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: Tue, 30 Apr 2013 19:27:20 -0000
On Tuesday 30 April 2013 19:04:59 Jeff Garzik wrote:
> The format currently used by bitcoind would be just fine --
> blocks/blkNNNN.dat for raw data, size-limited well below 1GB. Just
> need to add a small metadata download, and serve the raw block files.
That doesn't seem very generic. It's tied far too much to the current storage
format of bitcoind.
Wouldn't it be better to add support for more bitcoin-protocol-oriented HTTP
requests? Then any client can supply the same interface, rather than being
forced to create blkNNNN.dat on the fly?
http://bitcoind.example.com/block/BBBBBBBBBBBBBBBBBBBBBBB
http://bitcoind.example.com/tx/TTTTTTTTTTTTTTTTTTTTTTTT
http://bitcoind.example.com/block/oftx/TTTTTTTTTTTTTTTTTTT
http://bitcoind.example.com/peers
http://bitcoind.example.com/peer/nnn
Essentially: block explorer's raw mode but in every bitcoind. The hardest
operation for light clients is finding out the block that contains a
particular transaction -- something that bitcoind already knows.
I'd like to see support for HTTP POST/PUT of signed transactions and block
announcements too.
Andy
--
Dr Andy Parkins
andyparkins@gmail.com
|
