On 05/09/2014 01:58 PM, Noel Maersk wrote:
>> 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.
It's a problem if you want to receive a stealth payment on a mobile app.
You have to hack around that problem and create privacy concerns in the
process.
>
>> Fifth problem: you have no idea who sent you money or why.
> That's kind of the whole point?..
By that he's referring to authentication. You want to make sure the
stealth address belongs to the purported owner.
> 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.
I think one the problems it solves is it allows for lightweight p2p
clients to take advantage of stealth functionality without needing to
fork bitcoin core. Right now only server based lightweight wallets
(darkwallet/electrum/etc) can receive stealth addresses because they can
implement their own filtering solutions. P2P wallets can't do that since
they rely on full nodes to serve up transaction data.

It also allows for authenticated transactions since it uses BIP70.
Stealth addresses are not authenticated at the moment although Peter
tells me the plan is to include them in PGP keys (which themselves have
to be authenticated).

The downside, of course, is the quasi-centralized comm channel. In
practice it might not be any more centralized than Tor, but it's still
not ideal. I guess the choice comes down to when do you want to use a
semi-trusted centralized server... for downloading blockchain data
(darkwallet/electrum)? Or for receiving stealth transactions (mike's
proposal)?

I don't know if one model is better than the other. It probably comes
down to personal preference.
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem