No. Starbucks make an app that requires name, number and location; they know who sweatysocks442 is and they make two-way data sharing agreements with other companies; the devil is in the detail.
Front-end Team Evolution Demo Video #1
- Thread starter Chuck Williams
- Start date
No. Starbucks make an app that requires name, number and location; they know who sweatysocks442 is and they make two-way data sharing agreements with other companies; the devil is in the detail.
Then that’s up to the customer if they want to release that information to Starbucks. How does that fall on the responsibility of Dash core? Every business asks for different levels of information, if we don’t want to give that info, don’t transact with that business.
Nope, Starbucks are getting access to your entire contact list. Are you sure your friends will appreciate that?
jimbursch
Well-known member
The privacy issue has a new thread here:
https://www.dash.org/forum/threads/poll-evo-will-expose-your-contact-list-are-you-concerned.31660/
Let's continue this discussion there, I think.
https://www.dash.org/forum/threads/poll-evo-will-expose-your-contact-list-are-you-concerned.31660/
Let's continue this discussion there, I think.
JGCMiner
Active member
Your Friends List:
FriendsForever1
Dashlover77
.
.
.
A bunch of pseudonyms for which Starbucks has no additional information (unless said user gave them that information willingly in a previous transaction).
I fail to see the problem in terms of releasing the MVP. Privacy is a “nice to have”, but not a “must have” by where Core should delay Evo for months if not a full year.
I went to Starbucks, FriendsForever1 used Lyft and got loyalty points, and Dashlover77 is a New York Red Bulls fan. Google it and you'll see they are all partners, sharing data. Additionally, companies like Coinfirm step in and they make two-way data sharing agreements and datamine the contact lists of all three people, recursively. You involuntary gave out more info than you thought or intended.
Behind the scenes, Evo is using a HD wallet, but ask yourself, what is the point of doing so when someone's entire contact list is exposed? I propose then that we also reveal the entire public key hierarchy. I fail to understand how we can justify privacy in one argument (HD wallets), yet glibly hand out info about our friends and our friends friends.
Here's a real world example. These days, ShapeShift require a "refund address" for the minority case that a transaction goes wrong. Of course, most of the time the refund address is redundant but they require it anyway. They store that refund address and hand it over to companies like Coinfirm. In turn, Coinfirm track that refund address knowing full well it belongs to you. Perhaps that address is next seen at Starbucks. And so, it's these kind of dirty underhanded tactics that others use, it's a hostile world. Why should we handover that kind of power on a plate?
JGCMiner
Active member
So much of your info is out there anyway with the legacy financial system. This will not be any worse. And even with all the datamining they are still dealing with pseudonyms.
Plus privacy is on the roadmap. In the meantime, if you don’t like it — don’t use it.
Sorry, but you can’t convince me that the MVP should be delayed any number of months for this “issue”.
Good luck swaying others...
Good to know you don't give a shit about your friends privacy.
yocko
Active member
- Why would we extend this to other coins?
Because a) no one holds just one coin / token, and b) it would be a highly effective way to switch people to dash / upsell our benefits.
The future is not one coin, there will always be multiple coins, in the exact same way we have multiple programming languages; different use cases and preferences. Blockchain interoperability is the future, in the same way TCP/IP was the joining of different philosophies.
yocko
Active member
I only hold one coin, why hold more if you believe in the project more than the rest?
amanda_b_johnson
Well-known member
Thanks so much for the great demo.
Two questions from me (one of which was repeated elsewhere):
1. If someone wanted to pay me and I gave them my username, would I first have to accept a contact request from them before they're able to pay me?
2. (repeated question) Is there any reason for concern that malicious parties will set about registering tens of thousands of usernames, just to try to use up as many desirable namespaces as possible?
Thanks!
Two questions from me (one of which was repeated elsewhere):
1. If someone wanted to pay me and I gave them my username, would I first have to accept a contact request from them before they're able to pay me?
2. (repeated question) Is there any reason for concern that malicious parties will set about registering tens of thousands of usernames, just to try to use up as many desirable namespaces as possible?
Thanks!
Chuck Williams
Member
First a clarification: A "person" will NOT have "their" contact list readily available. The Dash protocol & Evolution platform is not designed not collect or store any identifying information of "persons".
HOWEVER - in it's CURRENT nascent state of prototype and system design, the following statements *I believe* to be true AND ARE SUBJECT TO (& WILL PROBABLY) CHANGE:
1) The REGISTRATION TRANSACTIONS of BLOCKCHAIN USERNAMES WILL BE PUBLICLY AVAILABLE *on the blockchain*.
1.1) All registrations transactions will require in invitation from an existing blockchain user. It will be known which blockchain username invited them and paid the miner fee. Businesses will be able to register usernames and "sponsor" (read as "pay miner fees for") public registrations for the privilege of being that user's first contact.
1.2) Contacts may be removed at any time.
2) ALL blockchain user CONTACT REQUEST TRANSACTIONS (& associated state transitions) will be PUBLIC and VISIBLE on the blockchain
2.1) When a blockchain user response to a contact request, one part is only decipherable by the receiver. Someone else cannot distinguish between an approval and a rejection. Furthermore, they can't tell if you have declined, then re-asked yourself, or first accepted, then removed... This "series" of "states" on a "blockchain user object" are "opaque" (not decipherable).
2.2) Right now, in the prototype - everything is transparent and not cryptographically protected. Dash protocol developers have encryption securities planned, not yet implemented, in the system design.
3) WALLETS, FUNDS, and ALL associated WALLET transactions, balances, etc. are *expected NOT TO BE PUBLIC*, or LINKABLE to blockchain user accounts from the blockchain.
4) RESPONSES (acceptances, denials, & or lack of responses) WILL BE PARTIALLY PRIVATE. Existence of a RESPONSE is public, but details like HD public keys will be encrypted.
5) ALL PAYMENTS ARE NOT PUBLICLY ASSOCIATED TO/WITH BLOCKCHAIN USERNAMES.
5.1) Blockchain Usernames are registered, recoverable, and managed with HD private keys (like wallets, but separate from wallets).
5.2) Wallet transactions executed from a blockchain username are not publicly associated with that username.
5.3) Wallet access connected to Blockchain user accounts will require the HD Keys of the Blockchain User Account &/or HD key of the wallet itself to access & control wallet funds.
5.4) Blockchain User accounts *should not be* accessible or linkable through wallets, wallet transactions, or any wallet specific behavior. We are working through cryptographic methods to seal this portion of functionality.
After talking with @j0shua, he & I agree that the current system level or privacy is roughly equivalent to "email" standards with PGP encryption options - and no transport security. We believe this so because while it is not possible (yet?) to encrypt the sender and recipient of emails, it is possible to securely encrypt the messages and data enclosed.
We expect to improve the quality of privacy, and the level of functionality as we progress in direct response to the public's reception of the platform.
We haven’t addressed this, specifically, yet. However, we believe the results of our research data and system designs will be able to maintain security across the 2nd tier network of masternodes, and the assets they protect in DashDrive.
We are thinking/arguing/debating/dreaming/designing/POC’ing/re-implementing really hard about this issue. This issue is the core of the Evolution Platform that is expected to be the flagship product for Dash Core Group, Inc. for some time to come. We really don’t get a 2nd opportunity to get this right if we get it wrong. Blockchain Usernames are possibly the single most discussed nouns among Core developers since September 2017.
On that note, here’s one of our collective homework items for your review (thanks again, @j0shua) : https://www.b-list.org/weblog/2018/feb/11/usernames/
@GrandMasterDash - the rest of your questions are not yet addressed. Thanks for your questions and contribution to the discussion!
Thanks all, we’ll try to keep up on the discussion here.
If you send them a contact request, or if you accept their request, they will have what they need to send you a payment. A contact request/confirmation (in DashDrive they are the same thing) is an entry in your userspace that says, "Hey XYZ, here's a public HD key you can use for paying me, and it's encrypted just for you." (The "Hey XYZ" part is publicly visible, the HD key part is encrypted.)
Yes, this is a topic of concern. Registering usernames will cost a few cents of Dash, which helps a little bit. But usernames as property is a huge, thorny topic, and we haven't found any easy answers. For now we're not doing anything special to try to prevent a username market from developing.
Unstoppable
Active member
Chuck, thank you for the thorough reply, as well as the interesting link. I had no idea managing usernames could be so complicated, and I'm elated that you, DCG as a whole, have the depth of knowledge to consider such things. Please, by all means, continue taking your time to identify all the landmines before beginning to march this thing out!
Each time we have a chance to hear something from the DCG, there is a nugget that makes many other things fall into place, such as when Ryan mentioned the defensive patent during the Q4. A light bulb went off, many pieces fell into place for me, and I was very, very happy we had such a great team with such a wide expanse of knowledge and experience considering things I wouldn't have thought of in a hundred years. That also goes for the VMN development environment, and the SDK as well.
So much going on behind the scenes, very necessary things, fundamental building blocks, that the public will never need to worry about, or will really be able to appreciate.
My confidence in you is restored each and every time.
Each time we have a chance to hear something from the DCG, there is a nugget that makes many other things fall into place, such as when Ryan mentioned the defensive patent during the Q4. A light bulb went off, many pieces fell into place for me, and I was very, very happy we had such a great team with such a wide expanse of knowledge and experience considering things I wouldn't have thought of in a hundred years. That also goes for the VMN development environment, and the SDK as well.
So much going on behind the scenes, very necessary things, fundamental building blocks, that the public will never need to worry about, or will really be able to appreciate.
My confidence in you is restored each and every time.
jimbursch
Well-known member
Thanks @Chuck Williams and @j0shua
The more you guys are able to educate us, the better we will be able to educate others and perhaps take some of the load.
Given this:
Using the analogy of Alice, the California medical marijuana dispensary operator who is supported by local government, but vilified by the federal government:
If she makes contact requests of all her local organic suppliers, the DEA will be able to observe the contact requests, but NOT know the status of the requests or any transaction data that takes place between them.The best practice for Alice and her suppliers is, for business purposes, to use a username that is anonymous and in no way connected to their identity. If the DEA does not know their username, they will not be able to observe their contact requests. In the future it is planned that contact requests will be encrypted, so even if the username is known, the contact request cannot be seen.
Is this correct?
The more you guys are able to educate us, the better we will be able to educate others and perhaps take some of the load.
Given this:
Using the analogy of Alice, the California medical marijuana dispensary operator who is supported by local government, but vilified by the federal government:
If she makes contact requests of all her local organic suppliers, the DEA will be able to observe the contact requests, but NOT know the status of the requests or any transaction data that takes place between them.The best practice for Alice and her suppliers is, for business purposes, to use a username that is anonymous and in no way connected to their identity. If the DEA does not know their username, they will not be able to observe their contact requests. In the future it is planned that contact requests will be encrypted, so even if the username is known, the contact request cannot be seen.
Is this correct?
Interesting. So the way I understand your reply, it will not be possible for Amanda to accept tips from her viewers on her Dash username, except if she accepts (or sends) contact requests from each of them ?