From: Brenton Camac <bpcamac@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Date: Tue, 30 Apr 2013 15:06:12 -0500 [thread overview]
Message-ID: <4EA3A617-AA9D-4E4B-B4CC-AC7BC28B2BB5@gmail.com> (raw)
In-Reply-To: <CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
Sounds like this part of Bitcoin (block sharing) would definitely benefit from having a REST (HTTP) API.
REST-based web APIs are a common feature of most online services these days. Makes writing other client services so much easier. Plus you get the benefit of the HTTP ecosystem for free (HTTP caches, etc).
- Brenton Camac
On Apr 30, 2013, at 1:04 PM, Jeff Garzik <jgarzik@exmulti.com> wrote:
> On Tue, Apr 30, 2013 at 12:14 PM, Rebroad (sourceforge)
> <rebroad+sourceforge.net@gmail.com> wrote:
>> As part of a roadmap for block downloading, I think this may be a good time
>> to look into providing an HTTP/HTTPS protocol for block downloading - this
>> would also allow web proxies to cache blocks and thus make it more
>> accessible, as well as cater for resumeable downloads.
>
> Speaking generally, I've always been a supporter of finding new and
> creative ways to store and transmit blocks. The more diversity, the
> less likely bitcoin can be shut down worldwide.
>
> HTTP is fine, but you run into many issues with large files. You
> would need a very well defined HTTP-retrievable layout, with proper
> HTTP headers along the entire path, if you want web caches to function
> properly. You need HTTP byte range support, HTTP 1.1 keep-alives, and
> other features for resuming large, interrupted downloads.
>
> 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.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
next prev parent reply other threads:[~2013-04-30 20:06 UTC|newest]
Thread overview: 34+ 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
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 ` Brenton Camac [this message]
2013-05-01 13:46 ` [Bitcoin-development] " Jeff Garzik
2013-05-16 11:26 Ricardo Filipe
2013-05-16 15:47 ` Jeff Garzik
2013-05-16 16:23 ` Ricardo Filipe
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=4EA3A617-AA9D-4E4B-B4CC-AC7BC28B2BB5@gmail.com \
--to=bpcamac@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