Peter Todd [ARCHIVE] on Nostr: š Original date posted:2013-07-23 š Original message:On Tue, Jul 23, 2013 at ...
š
Original date posted:2013-07-23
š Original message: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 others for
> them to supply; but suddenly makes it possible for an SPV client to trace the
> providence of any transaction without needing to maintain the entire chain.
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 API.
>
> 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
interface and won't be exposed to the network as a whole.
Increasing the resource usage by SPV clients on full nodes is undesirable; we
have a lot of work to do regarding DoS attacks. John Dillon's comments here on
using micro-transactions to compensate full-nodes for maintaining expensive
blockchain indexes are worth reading:
https://github.com/bitcoin/bitcoin/pull/2802#issuecomment-20232958
In any case UTXO data currently requires you to have full trust in
whomever is providing you with it, and that situation will continue
until UTXO commitments are implemented - if they are implemented.
--
'peter'[:-1]@petertodd.org
000000000000007bea8b46717ec4acb05830bcb6222497366dd72b02ddc80569
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/95cd1e72/attachment.sig>;
š Original message: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 others for
> them to supply; but suddenly makes it possible for an SPV client to trace the
> providence of any transaction without needing to maintain the entire chain.
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 API.
>
> 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
interface and won't be exposed to the network as a whole.
Increasing the resource usage by SPV clients on full nodes is undesirable; we
have a lot of work to do regarding DoS attacks. John Dillon's comments here on
using micro-transactions to compensate full-nodes for maintaining expensive
blockchain indexes are worth reading:
https://github.com/bitcoin/bitcoin/pull/2802#issuecomment-20232958
In any case UTXO data currently requires you to have full trust in
whomever is providing you with it, and that situation will continue
until UTXO commitments are implemented - if they are implemented.
--
'peter'[:-1]@petertodd.org
000000000000007bea8b46717ec4acb05830bcb6222497366dd72b02ddc80569
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/95cd1e72/attachment.sig>;