From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: Service bits for pruned nodes
Date: Tue, 30 Apr 2013 20:27:10 +0100 [thread overview]
Message-ID: <201304302027.10247.andyparkins@gmail.com> (raw)
In-Reply-To: <CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
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
next prev parent reply other threads:[~2013-04-30 19:27 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-28 15:51 [Bitcoin-development] Service bits for pruned nodes 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 [this message]
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
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=201304302027.10247.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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