[mattdesl]

I gave an example here[1].

The typical answer is "just trust a third-party service" which side-steps the constraints in the question.

FWIW there is a variety of reasons you may not want to use a service like escrow.com — they take a cut of the exchange, operate as a for-profit business in a particular US-based jurisdictions, only operate on a limited set of currencies, request personal/private data sharing, and tend to settle the transaction in days, not seconds or minutes.

[1] https://news.ycombinator.com/item?id=31190423

[hiq]

Your example only works because you're considering an asset that lives in the blockchain itself. So it doesn't apply to anything physical, as in this case, you need a trusted channel to transfer the asset anyway, and a blockchain doesn't solve that.

Even considering only these digital assets, you have an implicit notion of trust. The xyz.eth representation on the Ethereum blockchain is considered valuable because most people think it does represent what people expect to find at xyz.eth. But the ICANN can change this at any moment by adding .eth to https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom... and this will all be gone.

Humans don't live in a blockchain, and blockchain rules don't apply outside of it, so you can't solve this boundary problem. Or rather, you solve it by trusting whoever's in charge of this boundary.

[mattdesl]

The whole point is peer to peer transfer of digital assets and digital state that is recorded on-chain. The goal is not “how to transfer a physical asset.”

These assets do have market value (despite your own personal feeling on what they “should” be worth) and so users do wish to find ways of interacting with and trading them without an intermediary.

The TLD/ICANN is irrelevant, as “.eth” is a construct for Ethereum clients, not HTTPS clients.

And yes, we build trust of, say, an immutable contract address originated by a human, and continue to trust in it years later because (a) the ledger is incredibly expensive to dismantle and (b) we can cryptographically verify this on our own local node.

[hiq]

> The whole point is peer to peer transfer of digital assets and digital state that is recorded on-chain. The goal is not “how to transfer a physical asset.”

Yes I understood where you were going. Just pointing out that the scope of the problem you're solving is way smaller than that of a generic transaction, to the point that it has very little relevance for pretty much anything real.

> The TLD/ICANN is irrelevant, as “.eth” is a construct for Ethereum clients, not HTTPS clients.

What do you think would happen to the value of the xyz.eth domain registered on Ethereum if ICANN decided to have .eth as a TLD and somebody made a website on a xyz.eth reachable natively via mainstream browsers?

This value would decrease, independently of what actually happens on the blockchain. Value doesn't exist independently from the real world.

Trusting a certain smart contract about what's at xyz.eth rather than another is also arbitrary and is a matter of social capital, again something that's not embedded within the blockchain.

[mattdesl]

The assets are “real” in the same way domain names are “real.” These are social constructs, maintained by social consensus.

It is very easy to come to a shared consensus about what address “mattdesl.eth” points to, because the history is recorded on-chain, and can be verified locally. I’m sure the exact valuation of this domain will go up and down, but as long as the the chain and network continues to exist, the asset holds value within the network, regardless of what occurs with ICANN/TLDs.

[hiq]

> These are social constructs, maintained by social consensus.

AKA trust, so we're not transacting only with "a bunch of people that you do not trust".

[dmitriid]

> of digital assets and digital state that is recorded on-chain. The goal is not “how to transfer a physical asset.”

Even with "purely digital assets" you have the trouble with oracles that provide you with data and whom you must explicitly trust, and with trust in general (when someone sells you NFTs that may or not be stolen from someone else).

The sum total of "p2p transfer of digital assets and digital state that is recorded on-chain between parties [without intermediaries - d.] that don't trust each other" is a very minuscule part of a very minuscule subset of a very minuscule number of activities that people engage in.

[mattdesl]

I'm not sure what point you are making. Using a blockchain doesn't mean you no longer need trust. But it can be used as a tool to help build social consensus about certain digital state/records without placing the data in control of a single centralized entity. Same discussion was had here[1].

[1] https://news.ycombinator.com/item?id=31190947

[dmitriid]

> I'm not sure what point you are making.

As a simbling comment desctibed it, "the scope of the problem you're solving is way smaller than that of a generic transaction, to the point that it has very little relevance for pretty much anything real."

[mattdesl]

The scope of the problem is basically what is happening on Uniswap (peer-to-peer swapping of ERC20 tokens) and Opensea (peer-to-peer swapping of ERC721/1155 tokens), which together account for the vast majority of Ethereum's daily contract activity.

These discussions often circle back to the notion that USDC, ENS, or any other ERC20 or ERC721 (NFT) is "not real" and therefore this problem is not worthy of study.

And yet nobody has an issue with Namecheap marketplace—a centralized ledger that manages token balances and virtual property exchange (domain names), without these token credits/debits ever being realized in your bank account (i.e. you can transact within their virtual dollar system without withdrawing funds to PayPal).