[hn_throwaway_99]

OK, great example, so I'll explain why a smart contract couldn't work here at all.

So, to start, going to be clear I'm using your specific example of "escrowing funds on purchase of a piece of real estate (and I mean actual, real, real estate)". Simple enough. But, at the end of the day, who is to say "the keys you gave me are really the keys to the house you said you sold me"? That is, there needs to be some way to import to the smart contract ecosystem "yes, these are the keys to the house he sold me, and yes, the seller is the unencumbered title holder of this house". There is no real way to do that without some sort of oracle, and then you've just moved the problem back a step (i.e. you need to trust the oracle).

I happen to think title insurance is vastly overpriced in many states, but that's not the same thing as thinking that title companies (who normally do escrow in the US) don't serve a very important purpose. Most importantly, they ensure the seller is the actual title holder. And I can hear the crypto fans saying "Well, if you just held that title on a blockchain, there would be no ambiguity about who owns it." But that just pretends that all the real world examples don't exist, like a contractor who puts a lien on a house because he claims he wasn't paid. Also, in the real world, if someone steals the key to your house, it's not usually that hard to evict them and change your locks. In the crypto world it's "sorry, finders keepers".

So again, this simple example just falls apart on further inspection. Very happy to hear why any of the rationale I've given above is not correct.

[samuellevy]

More than just needing an oracle - the keys and the house are both physical items. There's not really any practical way for a contract on the blockchain to validate that a particular physical item is in fact the item that it purports to be.

Are these ACTUALLY the keys to this house? Are they the only set? The original set? Were the locks changed, and this set in the contract is no longer valid?

Then putting aside all of that... How do you ENFORCE a "smart contract"? Probably through... Existing contract law. Because that's what it's there for. Smart contracts are just more convoluted paper, and we can do that already with DocuSign or any number of other digital contract options - all of which provide, so far as I can tell, precisely the same level of verification that a smart contract does. The only "advantage" of a smart contract over those platforms is that the history of the "document" is more or less baked into the chain, instead of trusting that the third party platform hasn't modified it... Which they will never have any motivation to do...

People have been initialing pages to mark them as read/accepted for more years than I've been alive. In the event of a contract dispute, smart contract or not, it's going to be up to a third party (mediator, judge, etc.) to decide on resolution anyway... At which point even the exact wording of the contract may well be discarded as being unenforceable because _contracts are not above the law_.

[jeffbee]

Thinking of a real estate transaction as an exchange of physical things is already a mistake. Most people expect to take possession of a structure in most deals, but it is sort of beside the point. What you're trading is a legal filing where you go to the county recorder (most states) and just claim to own something. What are you really buying? The promise from the other guy that they won't claim to own it in the future. But, under our deeply stupid title system, there really isn't a guarantee that the seller "owns" it in the first place. All kinds of people could have claims on it.

In a legal system this vague, smart contracts simply do not have a niche.

[photonthug]

> In a legal system this vague, smart contracts simply do not have a niche.

This is an interesting point. The way I think about this is, if we can ignore for a second the bitcoin-related baggage of smart-contracts as a concept, then there's still a lot of overlap with related concepts like open government and automated legal reasoning. So I'm curious if you think of those things as also intractable. Also, blockchain isn't some magic wand that replaces the need for other datastructures. Why should partial or even doubtful ownership be impossible to model and do secure/verifiable/conditional compute on?

[notacoward]

> All kinds of people could have claims on it.

That is not necessarily true. Often, one or more of the closing documents addresses this very issue, attesting that there are no such known claims and/or assigning any unknown ones to you as the new owner. Liability is part of ownership, after all, and all ownership is "just a legal filing" unless it's backed by force. While it's true that a real estate transaction is not the same as a transfer of a physical thing, dismissing such transactions as fictional is a bit sophist.

[photonthug]

> More than just needing an oracle - the keys and the house are both physical items. There's not really any practical way for a contract on the blockchain to validate that a particular physical item is in fact the item

Responding to you but this applies to lots of stuff in this thread. Quoting wikipedia, "a smart contract is a computer program or a transaction protocol that is intended to automatically execute, control or document events and actions according to the terms of a contract or an agreement. The objectives of smart contracts are the reduction of need for trusted intermediators, arbitration costs, and fraud losses, as well as the reduction of malicious and accidental exceptions."

How can anyone possibly object to this technology as if it were a) impossible or b) useless? In the next sentence we get into "commonly associated with cryptocurrencies", but I think the main idea is already there in the opening. There is no strict requirement for whatever implementation details that you love to hate (blockchain, digital goods, digital titles, web3, etc).

[hn_throwaway_99]

> How can anyone possibly object to this technology as if it were a) impossible or b) useless?

Because it doesn't work, nor do I believe it ever really can work, at least as it's largely advertised. I mean, you just read the description from Wikipedia and are basically saying "How can people object to this idea?" That's like reading about all the great things flying cars can do and then saying "How can anyone object to flying cars?"

The point is that I (and many others, but I'll only speak for myself) do not believe that the utility the crypto boosters like to tout about smart contracts is technically feasible, at all, for most of the things we use contracts for in the real world.

[photonthug]

Final will and testament: When I'm dead, move all the money from account A into account B. What is "not feasible" about a government API that answers whether a citizen is alive and a banking API that runs a funds transfer? Let's stick the code for this in some large cloud provider where it checks the credentials and conditions involved every minute.

We could debate whether this is a cheaper/easier/safer approach than trusting a law firm/banks/clergy/clerks to execute things on your behalf. But it's absurd to say that this is not possible (because every part of this is already done), or that it is not useful (it has exactly the same use-case as a classic will, but moves trust from a law firm to a cloud provider).

[hn_throwaway_99]

Because what you are describing is not a smart contract, at least how it is nearly always commonly understood.

What you are describing is simple API automation. Nobody describes what IFTTT or Zapier can do as a smart contract, yet that is literally exactly what you have described.

[photonthug]

>Because what you are describing is not a smart contract, at least how it is nearly always commonly understood.

Shrug. So now we've moved through your criticisms of "it's not possible" and "it's not useful", and we're splitting hairs about whether it's in the right category. It seems like you want to have a conversation where "smart contracts" means exactly/only Ethereum as it exists today. If you're asking about the use-cases of abstract technology, and then pivot to insist that discussion revolves around existing brands/implementations, it feels like you're moving the goal-posts. You're of course free to insist that smart-contracts ARE ethereum and vice versa, but ironically when you do that you're a clear victim of marketing, and you're essentially endorsing the branding that you claim to dislike!

If "mere API automation" is disqualified as "smart contracts" according to your definitions because it isn't blockchainy enough, and if everything that IS blockchainy is disqualified as stupid or a scam, then I guess you win debates before they start. But that's just not a very interesting conversation for any one else.

FWIW, ethereum does have a concept of oracles ( https://ethereum.org/en/developers/docs/oracles/ ). I wonder if ethereum and zapier did have a lovechild, would you call it a smart-contract then? Do we need the contract AND the decision-data AND the assets to be blockchained, or can we blockchain a subset and still call it a smart-contract?

A mix between zapier, plus something like ethereum, together with legislation that requires open-APIs for critical services is probably exactly what we need to satisfy tons of practical real world use-cases. That's what you claimed to be interested in, right?

[photonthug]

> There is no real way to do that without some sort of oracle, and then you've just moved the problem back a step (i.e. you need to trust the oracle).

Sure, and of course this is desirable. The "oracle" is a trusted external API (the bank, the DMV, the municipality, whatever). Some people may not like that these institutions are the arbiter of ownership or whatever, but of course we expect to be able to trust these institutions more so than strangers from craigslist.

I haven't mentioned anything about "digital keys" to the house, or "titles on blockchain", or the US specifically, you brought up all that and then argued against it. Honestly, I'm not really a crypto-bro, just a guy who's had trouble with exactly this kind of transaction. And I'm not personally invested in ideals like radical decentralization, or implementation details like super pure smart-contract ecosystems that disallow external oracles. I just want less friction AND less risk when I'm trying to buy a motorcycle on craigslist, or a house in an arbitrary (i.e. potentially non-US) jurisdiction.

[hn_throwaway_99]

OK, I think I can fully understand and agree with your point, but what you are describing is really not a "smart contract" as it is usually described, at least by people who think of it as revolutionary technology. It sounds like you just want a title company with better technology, and that I can wholeheartedly agree with.

But the fundamental raison d'être of smart contracts (i.e. that they are "trustless", that "code is law", there is no intermediary) do not really support the use case that you are describing.

[bgitarts]

I guess you could say you don't need Amazon, the problem of getting goods is solved by physical stores. Yet, millions of people find value in ordering through Amazon instead.

There will be use cases where people simply prefer blockchain over the legacy alternatives because it's cheaper, faster or better and there will be "whole new world" use cases.

[hn_throwaway_99]

This is just more "handwaving with a bad analogy", which again only goes to show how hard it is for people to show any real utility for smart contracts.

It is very easy for me to explain and understand the benefit of ordering over Amazon vs. going to a physical store. When Amazon first showed up, I didn't think "Gosh, what is this really for?" or "Can somebody explain to me, simply, what Amazon is for?" No, I went to amazon.com, browsed a giant selection of books, ordered one and it showed up at my house a couple days later. "Wow, that's awesome" I thought.

If you say "There will be use cases where people simply prefer blockchain over the legacy alternatives because it's cheaper, faster or better and there will be "whole new world" use cases." then why is it so difficult for anyone to say what those use cases actually are?? You say it will be "cheaper, better, faster", but are able to offer no concrete examples or rationale as to why.