Remember Mike sees different adversaries than we do.
When he talks about privacy, he means privacy from hackers not police.

On 09/05/14 23:16, Chris Pacia wrote:
>
> 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
>
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>