-
Notifications
You must be signed in to change notification settings - Fork 41
Fundamental issues #5
Comments
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.
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.
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.
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...
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.
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.
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. |
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.
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?
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.
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.
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.
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. |
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.
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.
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).
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. I see an advantage of having a format for your PKI, so i wouldn't argue with using DIDs at all, just which kind. |
The text was updated successfully, but these errors were encountered: