On Sat, May 10, 2014 at 02:04:52AM +1000, Washington Sanchez wrote:
> https://medium.com/p/cb2f81962c1b
>
> Any thoughts?

Highlights these issues for stealth addresses:

> First problem: stealth address usage bloats the block chain.

Everything bloats the blockchain. P2Pool payouts, text messages,
protocols built on top of Bitcoin, sending two transactions instead of
one when you decided to stay for one more round at the pub...

Maybe he meant this (Later on):

> Using the block chain as a scratchpad to store temporary data only one
> or two people care about is incredibly expensive and inefficient

..., but I don't see how it's more temporary than entries in a
four-year-old ledger.

Besides, it's not temporary. It's part of the transaction. If it bloats
the blockchain, charge fees.

> Second problem: stealth payments look different to regular payments.

Might be a problem if you're trying to conceal the nature of a payment,
true.

> Third problem: stealth addresses and phones don’t mix

Hey, phones are horrible at running a full node! That's why no one uses
them to run a full node. There are, however, full nodes on the network.

What I meant to say is not everything has to work on a phone.

> Fourth problem: stealth addresses are not backwards compatible.

As described by Peter in his message to the darkwallet list (today),
this might be an issue if nodes refuse to relay such transactions (or
blocks), now or in the future.

Otherwise, I expect one would use a supporting client when receiving a
stealth transaction.

> Fifth problem: you have no idea who sent you money or why.

That's kind of the whole point?..


He then goes on describing how something similar can be implemented in
the payment protocol (BIP70).

First off, since the implementations are different, their use case sets
are different (although overlapping). Various scalability/anonymity
tradeoffs. I don't see why only one has to be implemented. And it all
sounds a little bit like "mine is better than yours".

What I don't like about his solution is this:

> One of the next pieces of infrastructure we need is a simple network of
> store-and-forward servers.
> ...
> It could be a little like email, where people explicitly pick a server
> and their wallet creates an account and either polls for new payments or
> just uses a hanging GET for immediate responsiveness.
> ...
> Tor nodes have their uptime and capabilities measured by “bandwidth
> authorities” which are trusted not to lie about what nodes can do. A
> coalition of wallet authors could likewise run uptime measurement
> servers that report back to wallets which ones are working well.

Here, I'd need to trust the store-and-forward server. Sure, I have to
trust the Electrum/Mycellium/Obelisk servers, which is already asking
for a lot. These are, however, interchangeable, and they're running
critical infrastructure. store-and-forward isn't critical, so, although
it's easier on the resources, I wouldn't expect them to be as abundant.
Meaning a smaller pool to choose from.