Ok, I got it. Thank you @HeptaSean for clarifying and taking your time to educate.
What I have learned:
distributed records: all nickname records will be scattered across the blockchain. Any third party can build an index off-chain though.
resolving doublets: A smart contract must (and can) add a timestamp. When building an index, it is easy to resolve eventual doublets.
only one: A smart contract cannot verify if a name is available. The off-chain system registering this nickname would likely verify whether a name is available before registering that name, by using a index reasonably up to date. That still leaves the possibility for a name beeing registered twice, which leads to a failed registering attempt and costs for using the smart contract. Seems good enough to me.
Bottomline:
A smart contract is sufficient to establish an OCAWAN register.
Using a full node, any third party can build an index.
I expect another major issue: Phishing attacks: In an open system, any party can be registrar. How can we trust that parties?
Example: if the registrar connects donations@greenpeace.com to a wallet and claims to have verified that the owner of this mail address is really controlling this mail address: Is there a way to proof this claim?
â It is possible for mail addresses with a S/MIME certificate: The registrar could provide a copy of a Mail signed with the private key, but S/MIME certificates are not popular, probably since the creation is cumbersome and expensive (~15 USD/y). But I canât imagine any alternative.
â It is easy for Twitter accounts: The registrar could attach a link to a twitter post containing the wallet address.
For both scenarios, the smart contract wouldnât be able to verify this (off-chain) claim, though. The verification would have to be delegated to the system building an index, which would take quite a time.
Every system implementing
While this would be an open system where every (A) registrar can add records and every (B) system implementing those nicknames is able to verify those claims, every (B) system must verify each and every claim at least once. The validation procedures must be implemented by every system (B). Or they use prefabricated indexes from a (C) trusted index provider.
S/MIME certificates are ⊠cumbersome and expensive (~15 USD/y). But I canât imagine any alternative.
Well, there is an alternative available to most users: Many people have an account in a trusted system like googleÂč, and those companies share profile details. The user account holds verified mail adresses and mobile numbers, and in the case of a Google account you may even add additional contact details like a «chat user names», which is labelled with «AIM». Only the the account owner can modify those entries, where she/he can publish his wallet address (or a hash of it).
Âč I use Google as a popular service, but many other systems might be as suitable to verify any âčclaimâș: Google, Microsoft, APple, Dropbox, LinkedIn, âŠ
That is a massive RED FLAG. I will run a mile from any system that places google at the centre for verifying wallet addresses.
Please, everywhere you see google think of every possible way that you can make it hard for them to get your data. Think of the AI algorithms of the future. People are selling their private thoughts to google for convenience.
The fact that thereâs no way to connect a cardano wallet address to a person is a huge feature, not a flaw.
OCAWAN is a solution for those people willingly to share at least one of their wallet addresses. Because you can have an indefinite number of addresses per wallet, they only share kind of a sub ledger, not their whole wallet.
That is a massive RED FLAG. [âŠ] Think of the AI algorithms of the future.
I share your stance. BTW Iâm looking for methods that everyone can verify that my nicknames are linked to a Cardano wallet address. Itâs not essential whether google is the system providing this proof.
Suppose we have two versions of the Cardano blockchain, one with nicknames and the other one without. The first is proud to show the banner «we protect your privacy!» and the other one «reviews confirm: we have the best usability!». Which one will be the popular one?
If OCAWAN becomes a reality, it should be made abundantly clear that this solution compromises privacy. OCAWAN is and will always be opt-in. You and me are not in the target group.
The need for privacy is gradual, and it is always a compromise between costs and benefits. If you were a privacy maximist, you might even avoid Cardano.
The wallet staking key is in every address normally generated for that wallet. Therefore as soon as you link one of your normal wallet addresses to your nickname, you also link the staking key, which enables everyone to see how much funds that nickname controls. Check this out yourself: Plug one of your wallet addresses into cardanoscan.io and it will tell you the balance of your entire wallet.
It is of course possible to create multiple wallets. Each wallet has a different staking key.
You can also create addresses for the same wallet spending key but without a staking key or even addresses with another personâs staking key (franken addresses). A franken address could be used to make blockchain explorers think that someone else owns the nickname.
It would be better if you could design your system to somehow not require any entity to control the database of nicknames. Maybe there is a way to use zero knowledge proofs and store a copy of a zero knowledge proof âtreeâ of nicknames in IPFS. Then when someone wants to create a new nickname they can somehow prove to the smart contract that the name is not already in the IPFS ZK proof tree. The smart contract then allows them to proceed with creating the new nickname and update the IPFS ZK proof tree at the same time. The IPFS ZK proof tree could then also be the lookup database to enable users to lookup addresses associated with nicknames.
Maybe someone with more understanding of the capabilities of ZK proof systems could say if that might be possible. @HeptaSean ???
It would be better if you could design your system to somehow not require any entity to control the database of nicknames.
Iâve learned above that the blockchain is the database. All nicknames are stored as separate records in transaction metadata.
⊠when someone wants to create a new nickname they can somehow prove to the smart contract that the name is not already in the IPFS ZK proof tree.
Iâve learned above that this is not possible, because a smart contract can not access off-chain data.
Thereâs no way to prevent that the same nickname is registered twice in parallel, within the same block.
You MUST verify this afterwards, at the time you create (your own) index.
In an open system, every party must be able to add new nickname records. It must be possible for everyone to verify whether any âčclaim to own a nicknameâș is valid. If this is true, it is up to the party building in index, and verify each and every claim before using this nickname. Everyone can build such an index. Thatâs why there is in fact no entity controlling the database.
And finally, this is the one big advantage versus adahandle.com, where everybody can pay to own Terminada forever. (to be clear: forever!)
What I am saying is that there might be a way to use zero knowledge proofs to achieve your goals in a decentralised way. For example, you might be able to have some sort of tree data structure stored as an IPFS file and use zero knowledge cryptology techniques to prove to the smart contract that the tree data structure doesnât contain a particular nickname.
A hash of the current tree data structure could be stored in the metadata of the UTxO holding the smart contract. The user generates a ZK proof that the existing tree data structure doesnât already contain the nickname and submits this proof to the smart contract along with a proof for an updated tree data structure which is otherwise identical but with the addition of the nickname. The smart contract checks the validity of the ZK proofs and allows the UTxO to be spent. The new UTxO generated then stores the hash for the updated tree data structure now containing the new nickname.
You need to speak with someone that knows enough about ZK cryptology, but I suspect that it might be possible to use this new technology to achieve something along the lines of what I just described.
Also, you can leverage the UTxO architecture to ensure that your nickname database can only be updated one nickname at a time since a UTxO can only be spent once. (Of course you could still chain transactions to get many nickname additions within one block or use a hydra head to process even more.)
Interesting. Thanks for pointing out my misunderstanding.
Why do you think ZK is required? Is there a trust issue between on-chain and off-chain code? If not, the off-chain code could just reply whether a given string is contained or not, right?
There is always a trust issue between on-chain and off-chain code. The problem is with how you prove that something is not there. The off-chain code needs to prove this to the on-chain smart contract (validator). It will also need to prove that it updated the file database correctly.
This ZK cryptology allows you to do some really tricky things not previously possible. For example you can have someone do a computation and produce a proof that the computation was done correctly. Even multi-party computation where each separate party computes just a portion of the problem and then this is aggregated with a combined proof that ensures that each party did its partial computation correctly.
Like I said, I just donât understand the cryptology enough to explain it or even to be sure that what I am saying is totally possible. But, I think it can work for your use case and I think your idea is really good and something that I want to support. I was hoping that someone like @HeptaSean would chime in with some cryptology âknowledge bombsâ.
I donât think that something like proving that a Twitter handle, an e-mail address, a Telegram account belongs to someone is possible with zero-knowledge proofs. And also proving that off-chain code has checked a registry of already registered names to on-chain code does not seem to be the realm of these things.
In fact, their privacy gains for SSI applications seem grossly overstated to me. They allow some form of plausible deniability. There is a possibility that a verifier made the whole proof up. But that doesnât obligate anyone to not trust the verifier, anyway. If I proof my address or the fact that I am older than 18 years to a verifier, they can, of course, just store that fact in a conventional database forever.
For the purposes of this thread, I thought the âfirst come, first serveâ approach with an asset name that also contains a time stamp seems most doable to me.
If there should be some assurance that the name is somehow âownedâ outside the blockchain â a Twitter, e-mail, Instagram account being controlled â there will have to be some trusted, centralised entity checking and certifying that. Donât know if that is really needed. Would surely put me off a bit, especially since they will take fees for that service.
Maybe my terminology was incorrect but the concept was worth exploring. After some more reading, what I think could work is an âAuthenticated Dictionaryâ.
Here is some quotes from the second article introduction:
An authenticated dictionary (AD) scheme securely outsources storage of a set of keys-value pairs to an untrusted prover. In this setting, the prover can convince any verifier, who has a succinct digest of the dictionary, that a key has a particular value in the outsourced dictionary by sending him a lookup proof for that key.
âŠ
Specifically, our new construction satisfies strong key binding, which means security holds even when digests are maliciously constructed by the adversary. This is the case in many applications, such as transparency logs, authenticated file systems and privacy-preserving web applications.
âŠ
Furthermore, we add support for non-membership proofs of keys that are not in the dictionary.
That last quote appears to address @HeptaSeanâs contention that: âit is not really possible for such a contract to check that something is not there.â
Probably Cardano needs more crypto primitives added to Plutus in order to make use of such âAuthenticated Dictionariesâ. But such a setup could achieve @wintifroschâs goals of an open solution for linking human readable names to wallet addresses.
