Front-end Team Evolution Demo Video #1
- Thread starter Chuck Williams
- Start date
-
- Tags
- development evolution video
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.
I only hold one coin, why hold more if you believe in the project more than the rest?
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!
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.
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.
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:
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 ?
Thanks for the update, very good.
I think the name space should have two levels; a network name followed by "@username". A network name would be similar to TLDs e.g. "flights", "food", "news", "sexy" etc. If no network name is specified, then the "dash" network would be assumed. All other network names must be approved by MNOs via a proposal vote. If approved, the new owner would be entirely responsible for managing their username space. This is very important because:
The lease time for network names is up for discussion but for now I would suggest 5 years / 60 cycles, with the option to down vote and disable.
I think the name space should have two levels; a network name followed by "@username". A network name would be similar to TLDs e.g. "flights", "food", "news", "sexy" etc. If no network name is specified, then the "dash" network would be assumed. All other network names must be approved by MNOs via a proposal vote. If approved, the new owner would be entirely responsible for managing their username space. This is very important because:
- "@Joe", "[email protected]" and "[email protected]" would be three different users, and
- it means DCG can significantly mitigate responsibility (and control) over name squatting / copyright.
The lease time for network names is up for discussion but for now I would suggest 5 years / 60 cycles, with the option to down vote and disable.
I can't yet confirm the future plan that contact requests will be encrypted. It seems reasonable to expect, but we'll likely have to prioritize it appropriately. I think we'll clear up plans for that soon. The rest seems about right.
By comparison - consider the case with email. They would have to take pains to disassociate their identities from their email addresses in the same way, right? Even if many emails were intercepted - with PGP encryption presumably they'd only have from & to addresses, right?
The system design (as I recall from ~ 2 months ago) may have zone in which part of the registration transaction includes a newly generated public address for use in default "pay-by-name" schemes. This way Amanda can receive funds to this address just by using the name on-protocol - but those funds would be known, public, and not private (unless later mixed, of course). This was designed specifically as a "tipping" address. I would have to go back and confirm that it's still in the design. I understand there's been some modifications.
Great answer @chuck. Glad to see you guys making progress!
1. Basic Question:
Why are you dealing with any sort of user/contact architecture?
2. Difficult question: Why is that not handled outside of dash core, like 3rd party, other devs, etc? There could be several companies that could exist just to handle users, data contracts, and authentication to the dash network.
3. Product Question: This all seems to be adjacent to infrastructure & the dAPPI you are building. Why take the risk? What problem are you solving?
Without seeing the code.. I'm just shooting in the dark, but if you had pubically accessible generic name level information around user/contact info at a network level it would get abused big time.
Thank you, @Chuck Williams and @j0shua for the answers here. And thanks also, @chinmi, for clarifying my question for increased understanding.
Perhaps something like Keybase or Civic is a better platform for username management to prevent squatting in the namespace? Why try to do this internally when all of the difficult work for e.g. phone/email verification and bundling disparate internet identifiers together and releasing that information selectively could be handled by a platform specifically designed to manage what identity data is shared?
Actually, DNS isn't that good, is regularly abused by governments.
From what I understand, Civic would be a bad choice as they are essentially making it easy for data collection.
The important thing is, if dash could make a better DNS, possibly replicating the zone parts and ignoring all that third level country code stuff, then it would have a shot (a long shot) at giving people true freedom of speech.
"Why" questions are always hard for me. It always invokes my philosophical side. So, apologies up front.
My personal opinion based on my growing understanding of the vision being presented here is this: In the distant future, identity & privacy is going to be extremely important. If Dash is going to be properly prepared to deal with the very critical issues of privacy & identity in the future, we must begin to take slow, methodical steps into the space. Not so far out as a rabbit in this case - ahead of the pack and first off the cliff, and not so slow as the turtle - left behind and consumed by the forest fire - or maybe the trick there is to dunk in the lake?
In any case - my very, very much biased opinion is that Dash is at the leading edge of this pack of freedom-finders. These groups who wish to protect humanity from those who would control and abuse our identities, and hence our communities of connected beings. We must tread carefully here but there is an important vector here manifesting that coils around government & central banking farm-base identities, and self-directed, reputation enabled, sovereign based identities.
Agree. I personally hope that a wildly successful competitive market of identity provision services arise atop the Dash Evolution Platform to help bring freedom to all sovereign beings. (See I'm all philosophical now).
We are giving individuals the ability to claim what is essentially an inalienable right to a namespace of their choosing represented on the Dash blockchain. We will help them cryptographically protect it with a private key. With these namespaces, many data objects will be traded very easily - because they can be named. One thing I've always concluded in software development is that names are important.
Of course, due to the limited nature of language, characters, and meanings - these will be naturally scarce items that correlate to natural reality. There is only one word that is "tree" in the english language. We understand that words, labels, and symbols have perceived value because they are the foundation of communication, and I personally believe that these labels are intended to be publicly utterable by & visible to all conscious beings. Isn't this the foundation of free speech?
It is because names are important that we must move slowly, and incrementally. The right way to start with anything big is with incremental, calculated risks. We are risking our platform on a "big idea". We believe it will add value to our platform by moving cryptocurrency from the very technical to the very verbal and repeatable. This movement will remove friction in making payments. No more swiping of cards, exchanges of characters, tapping of devices, scanning of chips, or biometrics.
Now you can pay someone with a single word.
Words that are public, open-source, MIT licensed by Dash Core Group, Inc. to function on top of the Dash blockchain.
And then - we make it easy for developers of the world to implement it in the words (code, language) of their choosing, on the devices of their choosing. IMHO, That's why we're doing both at the same time.
Last edited:
Sold usernames on Dash Evo platform will be completely useless won't they? Because you can never know whether the seller has kept a copy of the Private key, so it's highly unsafe to use a bought one. Or can you change the Privkey associated with a username?
So I'd gather usernames don't really have resell value, but they could probably be used for phishing
So I'd gather usernames don't really have resell value, but they could probably be used for phishing
That hasn't quite been worked out, AFAIK. I'm making some limited arguments for a moderated trading management system - but I'm pretty sure I don't have team agreement that Dash Core Group, Inc. should be managing the scope of this idea - in which case I agree. I think there's a lot of uncertainty about how the names should be managed, post-acquisition/registration, and we have limited examples that are decentralized and open source in nature. I'm personally open to suggestions & musings here.
Technically - I'm pretty sure that there is agreement among Dash Core that names will be exchangeable, & transferrable using a combination of the new transaction capabilities that have been designed and researched. This is most definitely subject to change, though. So I wouldn't expect everyone to be 100% happy with resolution v0.0.1 here.
We are working on an on-chain and deterministic masternode system which will allow all DAPI clients (and other SPV type clients) to query and verify a masternode list. This will require an initial (hardcoded or from DNS) list of nodes to be known, which can then be used to query the current masternode list with additional SPV like proof data. If individual entries from your known-nodes list are failing or malicious, other nodes from your list will compensate this. After this process succeeds, the resulting masternode list can be reused later to re-initiate the process, which will then be faster, as less nodes are likely to have failed or being malicious, and also because only diffs to the previously verfified masternode list need to be transferred.
The verification basically verifies that the masternode list is actually confirmed on the longest-work chain, using SPV (merkle proofs) like methods. So it should be pretty secure and reliable. We will publish more details in the upcoming weeks when DIPs have been finalized.
“When the DIPs have been finalized” - this has to be the quote most used in the Evo project lol. If I had a dollar evertime core said this I would be retired
<snark> It's our new "Proof of Proposal" mining algorithm. We're just conducting the pre-mine now. </snark>“When the DIPs have been finalized” - this has to be the quote most used in the Evo project lol. If I had a dollar evertime core said this I would be retired
About usernames:
Maybe it would be a good idea to use the keyboard key "-" called Dash (also called hyphen) as part of the usernames.
Just as domain names use the "." ("Dot") and email names use the "@" ("At")
It's not so flashy as the "@" or "#" but it reinforces our brand.
My dash username could be "-Elmo" pronounced "dash elmo"
(Also, like domains and emails lowercap and Uppercap should be the same. Elmo = elmo)
Maybe it would be a good idea to use the keyboard key "-" called Dash (also called hyphen) as part of the usernames.
Just as domain names use the "." ("Dot") and email names use the "@" ("At")
It's not so flashy as the "@" or "#" but it reinforces our brand.
My dash username could be "-Elmo" pronounced "dash elmo"
(Also, like domains and emails lowercap and Uppercap should be the same. Elmo = elmo)
The problem is, usernames need to be speakable, that is to say, imagine you are giving your email / web / username to someone on the phone. When you say "dash", you would have to clarify and say, "the dash symbol". It's a common mistake when people choose names. "TenX", for example, is a bad name because you have to actually say, T E N X.
For better or worse, the "@" symbol is used on forums and social media to identify users. It's the most widely recognized cue to mean "user".
I agree, english usernames should be case insensitive or lowercase only (just like graphene). But equally we must be fully internationalized.
It won't be any better, either... So why not stick with the familiar? Why go to all this trouble when what Joe Facebook is already doing is better in his eyes?
That will be your problem if you go through with this foolishness...
I have no doubt you'll get continuing support from the SuckerNodes. Most just quit voting, so only the yes men still show up to the polls.
But, overall, this is a path to failure. You care only for getting the votes from MNOs, paying no attention that this is a non-starter for any potential new users, while driving away anyone already here by abandoning the reasons why they're here...
You point out that "people" (Joe Facebook) prefer convenience over privacy, but neglect the reality that Joe Facebook already gets more of both from the existing Bank/Fiat system...
If at any point a psuedonym is attached to a transaction, ever... It's worse than exposing a single address. It exposes everything, forever.
"then don't do business with Starbucks"
How about paying utilities? Just don't do business with them? There are tons of entities with which one is forced to do business, the need, not want, of which grants sufficient leverage to coerce this information.
What color is the sky on your planet?
I think you're so deep in the forest that you can't see the sky.
You've created a disincentive for Joe Facebook to use it, and eliminated the reasons existing cryptotards would use it... Alienating your current base while turning away new users. Brilliant.
You've gone Microsoft, but in a marketplace of abundant competitors with no embedded, proprietary market... You simply don't have the entrenchment/monopoly to make these demands.
The ever-shrinking echo chamber has swollen your heads more than I thought...
"Come use DASH! It's the total pain in the butt crypto that makes your entire transaction history public knowledge in the name of privacy!"
Lolwut? Seriously, this is absurd. If you can't see that then this project is in serious trouble...
Banks are better than this.
Last edited: