Open harmoniqpunk opened 3 years ago
I'm not a part of the TBDev team, but I will try to answer those questions based on my views an understanding of the whitepaper.
DID uses public key cryptography, it is an entire PKI system. Using a DID instead of just a single keypair comes with several advantages.
From my understanding, this would just be a module/service loaded into the user's identity hub. If the user has a module that provides the service that someone is looking for, they can interact with that service. Although I'm not 100% sure of the details here.
& 4. I don't thinks this is fully defined yet, and it may not be defined as a single protocol. I think you will have choices of service providers and various contracts that they offer. Depending on the asset, some might work in an atomic fashion. But as the paper outlines, that doesn't always work when you are mixing something that is not native to a chain (like FIAT). This is where the DIDs come into place, and the idea of reputation. You, as the user, have the ability to choose from any PFI that will accept your credentials. If there is a PFI that is your enemy, you are free to choose a different PFI.
Again, I'm not on the TBD(ex) team, so this is just my personal take on the whitepaper and how DIDs/Identity Hubs work.
Also, I wouldn't call any of these things "fundamental issues", seems more like questions about the details of the system being proposed.
I maintain my title "fundamental issues" because these are rhetoric questions which I personally know the answer. That's why no one will want to be hones and answer them.
Once again, I'm not part of the TBDex team, but I am an interested party.
I'm not sure why you are asking these questions if you feel you know the answers? The questions don't seem to quite describe the protocol correctly. I'll do my best to try and understand your concerns/questions and see if I can provide some of my own ideas around them.
Additionally to #1 you mention that there is no need for a DID. The DID allows you to find the most recent service endpoints and keys for a specific identity. It also offers key rotation and recover for a specific identity in a standardized way.
How "easy" would depend on the assets they are trading most likely. It would probably be a bit difficult to become a PFI for FIAT trading as you would need a way to transfer this FIAT to/from the user that is requesting the trade. If you were to become a PFI for another digital asset, that would likely be as simple as installing a module on your IdentityHub that supports those smart contracts. Whether this service is run on a mobile phone or a long-running service depends on the implementation. That is open to implementers to figure out what the best UX they can come up with that satisfies the protocol and contracts.
I really don't understand your statements/questions here. This is a general purpose exchange protocol... you could use this same protocol to purchase a cone at your local ice cream shop. There is no way to "define" any kind of atomic swap there. But there will be some PFIs that will be able to create trustless swaps between 2 different digital assets. It's just not defined in the protocol because the protocol is not limiting to ONLY digital assets.
I hope I was able to clear up some ideas, and I also hope that I didn't mis-understand the protocol and paper myself.
I think I can help here. Take a step back out of the tech world.
- Why do you need DID and why public key cryptography is not enough?
If a new key is issued for every transaction, there is no chain of trust. If you don't want a reputation, you don't need it...
- How does the normies (individual with usually just a smartphone) can become liquidity providers (PFIs)?
They already are. People do stuff for each other all the time, it's just not measured. This is a standard that can pave the way for the tech world to get in on that... it gives a standard foundation on which techies can try to fit existing things.
- How does P2P Fiat payment transaction work in very detail?
Here is an example: Localbitcoins adopts some concepts from this paper, and now their API automatically speaks to a whole world of other apps... spreads narrow, traffic and liquidity picks up.
- Bitcoin is the enemies currency. What if a PFIs is my enemy? Where is the atomic swap or at least the escrow mechanism.
This is not the level at which to address this problem... you will need to build your own market and economy, where you are efficient enough to not need them. A standard can pave the way, but it is just a brick and you want to build a road...
Again, this is about a standard and getting different parties to be able to do more together by virtue of having common definitions, and thus a better understanding of the similar moving parts and how they can interact. Why do we have internet? Because someone released TCP/IP as a standard. How much productivity did the USB standard unlock?
Back to the 1st question: Reputation. DID would be part of a solution to differentiate scammers from parties who have not yet scammed. (Theoretically doing transactions much smaller than total volume, would be safe? "Safety in numbers". Favorite scam is anonymous intermediaries waiting for a whale transaction as a pay day... and then do not complete the transaction but take the money. Their pay day, for rendering a cheap and popular service... so just DID is not enough, but it is a foundation on which to build, which is better than just endless string of random keys with no chain of trust... some combination of verified volume, escrow, and proof of funds, that goes several levels deep on the escrow, would be necessary... (Pause and read this again. Does this sound familiar?... the chain part?... We have been building to each individual trust record being a blockchain of its own.... but do we want to centralize these chains, or can they live decentralized as artifacts on other chains? I think this standard paves the way to the latter.) Back to why this is the only way I see - otherwise you can just escrow yourself via indirection - can you prevent this? No. It is similar to back link and reputation problem for search engines and how they get gamed, a whole industry has had decades of practice in this by now, to an extent everything is an arms race - so how do you curb an arms race, or even better, use it to curb itself? In terms of your last message saying it's not possible... it's not "absolutely" possible. But it is approachable, and you have to give the centralized world credit for the extent to which they have held the line. Personally I don't see a way to track untainted trust, other than the way the banking industry does it: rate limiting: SLOW transactions (aka paperwork, and bureaucracy), transfer limits, and anything above a threshold is tainted, forever. Who will police the exceptions? Power cuts both ways.
If a new key is issued for every transaction, there is no chain of trust. If you don't want a reputation, you don't need it...
You don't need to issue a new identity for every transaction, but you should definitely be able to do this if you want by deriving new key pairs like in BIP 0032. I don't want a probabilistic chain of trust (reputation is just a probabilistic chain of trust that can be hacked anyway). I want trust-less, pure deterministic. Again, Bitcoin is the enemy currency. This is the difference between federation and decentralisation. You want a federated exchange? Great, it's much better than centralised. But again, be honest and call it what it is: a federated exchange with centralised flavour.
They already are. People do stuff for each other all the time, it's just not measured. This is a standard that can pave the way for the tech world to get in on that... it gives a standard foundation on which techies can try to fit existing things.
No, they are not. You do not understand the value of giving power to the plebs for having the opportunity to get passive income on their liquidity like in proof of stake. That's why PoS have such a great succes on plebs, because people love the idea of staking their liquidity. But there is no system yet where plebs can operate like investment banking on NYSE. This is the true power. The technical barrier for people to become PFIs are huge in this paper. They just through some abstract ideas without giving the implementation details. I don't even know the authors of this paper. I only read it because came from Square and Jack. I can follow the commits but why no authors? Are they ashamed of theirs ideas?
Here is an example: Localbitcoins adopts some concepts from this paper, and now their API automatically speaks to a whole world of other apps... spreads narrow, traffic and liquidity picks up.
Again, you come with abstraction. I love engineering, I work on this ideea. These details makes the difference between a concept that works and one that not. The devil is in the implementation details.
This is not the level at which to address this problem... you will need to build your own market and economy, where you are efficient enough to not need them. A standard can pave the way, but it is just a brick and you want to build a road...
I've heard same rhetoric before Bitcoin and before Lightning Network. Not even Satoshi believed in the ideea of Lightning Network. Still, it is here and it works pretty well.
Again, this is about a standard and getting different parties to be able to do more together by virtue of having common definitions, and thus a better understanding of the similar moving parts and how they can interact. Why do we have internet? Because someone released TCP/IP as a standard. How much productivity did the USB standard unlock?
Did you ever read the TCP/IP RFC paper from DARPA? There you can find in very fine details how to implement. Same for USB and many RFC. When Satoshi wrote the paper, he already had the implementation done. He only wrote the paper after the implementation? Why? I hope you can answer for yourself.
Back to the 1st question: Reputation. DID would be part of a solution to differentiate scammers from parties who have not yet scammed...
I do not agree. Just because you don't see how, doesn't mean can not be achieved. FIAT is also a digital form of money. Can be done atomic swap. We will have true DEX. There are many ideas that can work. For hard cash excahnge you can have physical tellers with LN PoS in small shops. Then you can have RGB on top of LN where you can mint RGB assets back by BTC. The hardest problem is to create 2WP (2 way peg) but there are many guys, including me that work on this problem and are optimistic that will work. First implementation and then paper.
PKI can be handled nicely by the existing, production-ready https://github.com/decentralized-identity/ion . Maybe skip that part and rely on something that's already working.
- Why do you need DID and why public key cryptography is not enough?
If your identifier is a public key, and you have/want to roll that key for any reason (which a few scenarios require), you would lose your whole identity attached to that identifier. DIDs allow you to have an identifier that remains stable across PKI changes, so you can durably retain it over a long period of time.
- How does the normies (individual with usually just a smartphone) can become liquidity providers (PFIs)?
You would snag a DID and load up a wallet that implements the standard P2P messaging/data protocol (being defined in DIF) and use that to offer up whatever you want to exchange.
- How does P2P Fiat payment transaction work in very detail?
You would request Bitcoin, for example, in exchange for USD, and a PFI would send you requirements and data you need to complete the transmission of funds, after which they would send you Bitcoin to a specified address you send via the messaging layer. The trust eval between both parties will help you know you are talking to a reputable PFI (ex: a bank presents a valid credential that it's chartered and you can check its reputation).
- Bitcoin is the enemies currency. What if a PFIs is my enemy? Where is the atomic swap or at least the escrow mechanism.
You can include a third-party signer if both Asker/Bidder agree to it, and that party can be the determining one to execute the final send.
Can you link to a discussion on the scenarios that require key rollover? i haven't found it in the DID threads i follow. because my question would actually be why use ion/element instead of peer did?
I see an advantage of having a format for your PKI, so i wouldn't argue with using DIDs at all, just which kind.