I think this is a useful feature, but I din't see why it should be a part
of bitcoind. I've created a simple HTTP REST wrapper around bitcoind's RPC
interface in Python:
https://github.com/runeksvendsen/btchttp/blob/master/btchttp.py
It simply runs a HTTP server that translates HTTP GET requests
On 07/22/2013 09:42 PM, Jeff Garzik wrote:
The general goal of the HTTP REST interface is to access
unauthenticated, public blockchain information. There is no plan to
add wallet interfacing/manipulation via this API.
Is it planned to expose the UXTO set of a given address? That would be
Hi Andreas / Jeff,
Access to the UTXO set can be done using libcoin (see the coinexplorer
example), which also has a rest interface. Access to the UTXO set pr
address/script requires indexing of all scripts, which was easy in libcoin as
the blockchain is stored in a sqlite database.
On Monday 22 July 2013 20:42:45 Jeff Garzik wrote:
URL: https://github.com/bitcoin/bitcoin/pull/2844
Adding an HTTP REST API for bitcoind has been occasionally tossed
about as a useful thing. Such an API would essentially provide a
decentralized block explorer capability, enabling easy
On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
One additional URL makes this pretty much perfect:
GET /rest/block-with-tx/TX-HASH
Construction of the transaction-hash-to-block database is something the full
client's have to do anyway, so this query is no harder than the
On Tuesday 23 July 2013 10:42:05 Pieter Wuille wrote:
On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
One additional URL makes this pretty much perfect:
GET /rest/block-with-tx/TX-HASH
Construction of the transaction-hash-to-block database is something the
full client's
The only way to do this safely at an SPV security assumption, is by
having an address-indexed committed merkle UTXO-set tree, like the
one proposed by Alan Reiner, and being implemented by Mark
Friedenback. I know Michael Gronager has something similar implemented,
but I don't know whether
On Tue, Jul 23, 2013 at 11:52 AM, Andy Parkins andypark...@gmail.com wrote:
There is actually no such index being maintained by default, and doing so
is an unnecessary burden IMHO (you need to enable -txindex since 0.8 to
get this). Of course, if enabled, it can be exposed.
Wow. I'm
On Tuesday 23 July 2013 10:47:03 Peter Todd wrote:
On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote:
One additional URL makes this pretty much perfect:
GET /rest/block-with-tx/TX-HASH
Construction of the transaction-hash-to-block database is something the
full client's
On Tuesday 23 July 2013 10:56:02 Pieter Wuille wrote:
The block chain is not involved at all to verify transactions, it's
just a historical
record to serve to other nodes, and to do wallet rescans with.
It must be involved to some extent. Certainly during a temporary fork, there
are two
On Tue, Jul 23, 2013 at 12:00 PM, Andy Parkins andypark...@gmail.com wrote:
The REST API has nothing to do with SPV clients; it's similar to the RPC
interface and won't be exposed to the network as a whole.
Yes; I know that. I'm saying that it would make it easier for SPV (and other
On Tue, Jul 23, 2013 at 12:17 PM, Andreas Schildbach
andr...@schildbach.de wrote:
Sweeping paper wallets is a common feature request. People switch to
centralized services just for getting that.
That means they value convenience more than the trust-freeness of a
decentralized solution. The only
On Tue, Jul 23, 2013 at 12:29 PM, Andreas Schildbach
andr...@schildbach.de wrote:
Yes, I understand that. For this reason, I would vote for adding the
usual HTTP authentication/SSL stuff to the REST API. That way, SPV users
can decide to run their own instance of the API (providing the needed
On Tuesday 23 July 2013 11:17:28 Peter Todd wrote:
On Tue, Jul 23, 2013 at 11:00:24AM +0100, Andy Parkins wrote:
Increasing the resource usage by SPV clients on full nodes is
undesirable;
I don't think that's thinking big enough. What I imagine is that making
it easier and easier to
On Tue, Jul 23, 2013 at 4:36 AM, Pieter Wuille pieter.wui...@gmail.comwrote:
Apart from that, exposing this HTTP-based interface publicly has its
own problems, like security risks and potential DoS risks. If
anything, we should be reducing the attack surface rather than
increase it. IMHO, the
+1 and thank you. I've prototyped a couple different Bitcoin projects that
would benefit from this.
I'm traveling with poor 'net so I haven't read the patches yet. I echo pull
request comments about using Accept and Accept-Encoding headers. Same for
an API version number in the URL.
It'd be
16 matches
Mail list logo
