Andreas Schildbach [ARCHIVE] on Nostr: 📅 Original date posted:2013-07-23 📝 Original message:On 07/23/2013 11:47 AM, ...
📅 Original date posted:2013-07-23
📝 Original message: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
> 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.
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 themselves).
Or, a trusted party can set up a server. For example, I would be willing
to set it up for users of Bitcoin Wallet. I don't expect shitloads of
paper wallets sweeps for the forseeable future.
📝 Original message: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
> 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.
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 themselves).
Or, a trusted party can set up a server. For example, I would be willing
to set it up for users of Bitcoin Wallet. I don't expect shitloads of
paper wallets sweeps for the forseeable future.