Feedback on the tbDEX white paper

[csuwildcat]

We want to engage with you to gather feedback and ideas that will help shape tbDEX and advance our mission of making cryptocurrency and decentralized value exchange accessible to all.

[PC65049955]

Interesting Idea.

[italianblaze]

i just don't see how this is considered "decentralized" when you aren't really giving people TRUE anonymity... Especially from GOVERNMENT. This is undoing the whole point of which bitcoin was founded. All this would do if universally adopted would undo all that hard work. Not that it'll ever happen thank god.

[tx5westmt]

Unfortunately I think the issue is that there will be no such thing (legally) as an anonymous ramp to/from fiat. In my understanding Bitcoin is special because it is fully self contained and its version of the truth will always be 'right' (ie the value object and the transaction record exist together in the same system with no regard for what any other system says or thinks). Once you attempt to link separate value systems together (digital/digital or digital/physical) you must solve for trust somehow right? Even with NFTs for example, my 'certificate' claiming ownership of the 'thing' can be recorded and verifiable on blockchainA but it is still lacking in terms of guarantees about the actual 'thing' (always reminds me of tommy boy 'if you want me to take a dump in a box and mark it guaranteed, I will'). I'm still struggling to conceptualize how a system of trust verifiers wouldn't gravitate towards a few large authorities but maybe I am treating it more like PKI than amazon/ebay reputation based.

[johnpc]

there will be no such thing (legally) as an anonymous ramp to/from fiat

What about Bisq? My understanding was that it is legal and anonymous.

[tx5westmt]

Yeah I honestly don't know I am just imagining that the easiest method of control will be mgmt of the fiat on/offs. bisq has some pretty tough limitations (order size, automations, etc.) and I guess I was taking a more scaled up/mainstream position. They also include on their site "But there have been reports of banks closing accounts upon suspecting bitcoin activity."...so traditional banks may continue to distance themselves until more regulatory clarity is available.

[garzonyi]

Do you have a plan to publish other language version? Or allowing translation to community?

[garzonyi]

If transaction fee effects privacy level, it causes usability-divide between rich and poor. For instance, economic poor people become to be more less-privacy(more-transparent) to transact speedy or efficiently or frequently. They are let to pick just the one way to live active. Imagine you have to pay a lot of transaction fee to play on even game smoothly. Therefore, graduated taxation based on wallet wealthy class will be required. Quick comment.

[BenjaminPiette]

Hi guys,

I'm Benjamin Piette, team leader of the Elastos Essentials wallet. Just read your tbDEX whitepaper and I think this somehow matches with what we are doing.

Elastos Essentials in short:

• Crypto Wallet with good UX, trying to reduce technical complexities. EVM / Web3 libraries support. Works perfectly with DeFi dApps.
• Identity wallet, based on the full W3C DID stack made by the Elastos Foundation (DID SDKs, Identity blockchain ...)

We currently have a nice to use identity wallet, that can import third party Verifiable Credentials, disclose credentials to requesters, all of this through a connectivity SDK over wallet connect.

We are using a third party KYC service as a KYC provider to generate credentials and are currently building a community voting system based one one person one vote, using KYC-ed credentials. This will be released next month (just to says that our DID solution is quite advanced, including almost all parts of the usability "flow").

If any of this sounds interesting to you, we can talk about it. I'm not sure what your plans are but on our side we are already quite advanced on the wallet/cryptos/DID side, and maybe you need such technical environment to start implementing/demonstrating your protocol. Could be interesting for us to support the tbDEX protocol soon or later.

https://play.google.com/store/apps/details?id=org.elastos.essentials.app
https://apps.apple.com/us/app/elastos-essentials/id1568931743
https://www.elastos.org/
https://github.com/elastos/
https://github.com/elastos/Elastos.Essentials

Let me know, thanks

[sicktastic]

Q1. Are we still giving too much power to PFI (banks)?

Transaction costs are ultimately driven by risk. 
At maximum anonymity, transaction costs will necessarily be higher; 
at maximum disclosure, they should be lower. 
This approach to price discovery allows the marketplace to find the right balance.

☝️ that part is super interesting.

[gjcarneiro]

The example on-ramp/off-ramp scenarios use smart contracts. Does that mean it will be impossible to buy or sell bitcoin without using Ethereum or the like? That would be disappointing. That means buying wrapped BTC, not BTC.

[LiranCohen]

@gjcarneiro the protocol itself seems to be Blockchain agnostic.

However, bitcoin also supports smart contracts. Multisig wallets and lightning channels are an example of smart contracts on Bitcoin.

With the addition of Taproot, smart contracts on Bitcoin have some additional abilities, but also require less fees than before.

So the examples given can be accomplished without any wrapped Bitcoin.

[johnpc]

I think when people in the Ethereum world hear the words “smart contract” they think about something much more sophisticated than what taproot enables on Bitcoin.

[nlukin]

I love the idea of plug and play architecture by allowing licensed small business to join the network as PFIs. Also, love the use of DIDs - distributed identity is the future.
I wonder how different NFRs would fit into this design? Specifically, performance and availability are usually pretty hard requirements for CEX, so what kind of trade matching performance and system availability during peak price fluctuation events can be expected?

[sunphy]

With LN & TBD & RGB & Synonym, I have a feeling that bitcoin will play a much bigger part in DeFi & Web3 & Metaverse.

[nottrunner]

"Ideally, there would be a way to guarantee that the PFI will send the fiat before they receive the crypto. In future implementations, PFIs and wallets can rely on bank monitoring services and act as oracles within the smart contract to monitor the individual's bank account and trigger crypto funds to be released to the PFI only after they see the fiat push is initiated." - page 11

Could one create an escrow contract that is instructed to hold funds until both parties have transferred funds in. Allow participants to set the terms of how long the contract will hold funds before reverting if both parties have not made their deposits.

This would reduce the need and added costs of monitoring services, and a reliance on banks to fulfil the role of an oracle. Depending on banks in this regard would also introduce censorship risk.

[notLocalMaxima]

Coming from tradfi world (yes, sorry, but only in the day job!), what's super interesting is that this framework gives a starting point for tradfi to engage with defi without diluting their current AML and KYC requirements enforced by the regulators. A decentralized ownership of "identity" clubbed with selectively exposing required info. (and by choice - both the user and the PFI can choose to not deal with each other as counterparties if they are not aligned wrt. info that's acceptable to be shared) sounds very promising for tradfi adoption. At the end of the day, it will be helpful for crypto adoption if on and off ramps from tradfi get a lot easier...

[egbertwietses]

This part of the paper is interesting to me:
In the average case, the payee needs a physical shipping address, while the payer would seek some signal to trust that the payee is a legitimate business.

Why should I give my shipping address to the payee and not the trusted transport party sending the package? Should a protocol not account for that? Currently a lot of commerce sites hold physical addresses while they have no need for it if a payer could supply it to their trusted transport party in a safe manner.

[ddeputy1]

shipping address is needed to compute VAT/Sales taxes as well as any customs duties on physical goods

[egbertwietses]

You need country and postal code. Not street and number. In a lot of places you only need country because tax is country wide. In US it's state level. I still think the fact that so many webshops we use have our address in their database is unnecessary.

[csuwildcat]

@egbertwietses you make a good point, and it may be better to use the tech to allow the delivery services you trust to know your drop-off address, then sign Verifiable Credentials to the merchants who can present them to prove you want your trusted shippers to accept and deliver their packages to you. You could do a PR to adjust this example accordingly, if you're interested.

[Sheilf]

I think this work is socially consequential and what's driving it is true. I'm inspired by the work as a Mexican essayist and engineer. I wrote my complete thoughts on it here: Sheilf/MathUI#1

[suren31]

Hi, I have a query on mutually trusted third-parties :

1. Who are these entities?
2. On what basis is one wallet more trustworthy over the other to get a better bid-ask spread. Currently we have credit scores for individuals and credit rating for entities.

Also one more risk I see is , if the most trustworthy wallet becomes a bad actor suddenly , since past is not always indicative of the future. Would like your thoughts on these. Nice effort to bridge the worlds , its always needed before we are all on the other side of the world .

[CoderBoogs]

After reading this my thoughts are as follows

• Will it be possible to stop crime/fraud?
• It doesn't seem to be 100% anonymous
• sounds like exchanges of today (Binance, Coinbase) will be the default liquidity providers while the user Alice will have to build her reputation in the mean time
• I still don't get how this is truly decentralized when you depend on the PFI to process the txns it's not a true Peer to peer exchange with out the PFI Alice's txns both on ramp and off ramp are dead in the water

Looking forward to the next release.

[cwarny]

From reading the paper, it seems like hubs play an important but tightly circumscribed role in the whole protocol. AFAICT they are responsible for relaying messages out-of-band, but they don't seem to really be storing any data, besides the message payload until it is fetched by the wallet. The only data that seems to be involved in the protocol is credentials, identifiers, and keys (eg, blockchain addresses), which are all in the wallet. In other words, I wonder if hubs are overkill as a technology here, since they don't seem to be storing much data, and that's supposed to be one of their key characteristics. Why not use so-called mediating or routing agents instead? They seem more appropriate to a mediating/relaying role. If I missed something and some data is meant to be stored on the identity hub, can you help me understand what that data is? Thanks in advance

[csuwildcat]

DWeb Nodes (formerly Hubs) do store quite a bit of data, even just for the tbDEX protocol (many other apps will be built on top of them that are even more data centric). Here are some examples of things DWeb Nodes will do that lean on storage and replication of data:

• All wallet state data - if you don't standardize how wallets store/sync state across devices, you can't really have true portability. Thankfully DWeb Nodes make this effortless.
• Historical transaction data - users will definitely want to retain their transaction histories, and that data will need to be stored in something that can be used across devices and wallets, which is what DWeb Nodes provide.
• Credential storage - you'll need your credentials across devices and different wallets, something DWeb Nodes do well.
• Payment info/options - users will likely have at least one well-known persona DID, which they may want to associate a wide array of payment options with so others can look up their DID to discover.
• User or PFI profile info - PFIs are businesses who need to expose profile info for many different viewing/inspection reasons, so they will need a datastore that exposes these bits of data in a standard way. If a person wishes to use a well-known DID for something, they will probably want to offer up the basic profile info you commonly find on the profile pages of apps.

^ These are just a few things that DWeb Nodes store, serve, and replicate among participants and devices, but there are countless more examples for all the different types of apps you can build with them.

[cwarny]

Thanks, that clarifies things, and makes sense. I think the whitepaper could benefit from making that salient. The notion of transaction history only appears once under the section about wallet. Profile information is not mentioned. From your reply, it seems like the line between wallet and DWN is a bit blurred, where a wallet seems almost like just another DWN instance. If you would find it useful, I'd be happy to do a PR that adds a bit more color to the role and functionality of DWNs, based on your reply here, unless the whitepaper is frozen at this point.

[sunboy88]

I want to contribute whitepaper translation, how can I submit?