02:11 <stellar-slack1> <joyce> Yes, its because most people find it easier to use a username. whereas, seeing a long public key string can intimidate people

03:38 <stellar-slack1> <sacarlson> @andrey.z: I don't want to pick on you but I'm not sure I follow your white paper model and this one statement in it: Service operator receives complaints from users abut fake balance or inability to send transactions. After investigation service is switched to the backup supernode. Money Lost: 0 ? how do you come to the conclusion that no money is lost here? I think I can give you many instances that 0

03:40 <stellar-slack1> <andrey.z> supernode provider does not have access to any private keys

03:40 <stellar-slack1> <andrey.z> so the only thing they can do is disrupt wallet operations

03:41 <stellar-slack1> <andrey.z> like return wrong balance for the address

03:41 <stellar-slack1> <andrey.z> or say that transaction went through when it didn't

03:41 <stellar-slack1> <andrey.z> they cannot alter destination address or anything like that

03:42 <stellar-slack1> <sacarlson> yes but what if I sent the vendor a false balance after purchase of my icecream, I eat the icecream then the vendor find I didn't really pay for it?

03:42 <stellar-slack1> <sacarlson> that's not zero loss

03:43 <stellar-slack1> <sacarlson> who pays for my lost icecream?

03:43 <stellar-slack1> <andrey.z> ok, this case is valid, in theory. But normally vendors will be using merchant service providers. I have hard times imagining merchant service provider cheating on their business clients

03:44 <stellar-slack1> <andrey.z> they'll have contract, SLA, etc

03:45 <stellar-slack1> <andrey.z> the ice cream will be lost, i agree

03:45 <stellar-slack1> <andrey.z> but all funds will remain in original accounts

03:45 <stellar-slack1> <sacarlson> yes but icecream today shiping container tomaro

03:47 <stellar-slack1> <andrey.z> ok, you won. We'll insist on using several supernodes (data sources) for merchant services for our clients for whom this will be a risk

03:47 <stellar-slack1> <andrey.z> added to a todo list

03:48 <stellar-slack1> <andrey.z> this is also the case for wallets, i agree. But since we have more than 1 data source for balances by design, it's really easy to use 2 or more when this scenario becomes a serious risk

03:48 <stellar-slack1> <andrey.z> thank you :)