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 i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/23/13 3:29 AM, Andreas Schildbach 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 (provi
On Tue, Jul 23, 2013 at 4:36 AM, Pieter Wuille wrote:
> 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 only thing that sho
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 a
On Tue, Jul 23, 2013 at 12:29 PM, Andreas Schildbach
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
> resources themselv
On 07/23/2013 11:47 AM, Peter Todd wrote:
>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
>
> The REST API has nothing to do with SPV clients; it's similar to the RPC
>
On Tue, Jul 23, 2013 at 12:17 PM, Andreas Schildbach
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 way to avoid that i
On Tue, Jul 23, 2013 at 12:00 PM, Andy Parkins 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
> lightweight clients) fo
On 07/23/2013 11:37 AM, Pieter Wuille wrote:
>> Is it planned to expose the UXTO set of a given address? That would be
>> useful for SPV wallets to be able to swipe a previously unknown private
>> key (e.g. paper wallet).
>
> Depends what you mean by expose.
>
> Maintaining an address/script-index
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 store a partial blockchain would result in lower dema
On Tue, Jul 23, 2013 at 12:02 PM, Andy Parkins wrote:
> 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 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 b
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 c
On Tue, Jul 23, 2013 at 11:52 AM, Andy Parkins 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 surprised at that. Ho
>
> 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 whe
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
> > ful
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
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
On Tue, Jul 23, 2013 at 10:27:19AM +0200, Andreas Schildbach wrote:
> 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
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
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. Integrating
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
u
+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 helpf
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 external access
to transaction/address/block indices that we
24 matches
Mail list logo
