[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?

[hn_throwaway_99]

This conversation has probably been the biggest waste of time I've ever had on HN. "Moving the goalposts"??? This whole thread is on an article titles "Smart Contract Security Field Guide". To be clear, what you are talking about has absolutely nothing to do with the concept of smart contracts as discussed in that article, and honestly I have never heard someone in the past 10 years or so discuss smart contracts in a way that doesn't include distributed consensus. It has very little to do with ethereum specifics, but if you want "smart contract" to mean any automated behavior, then sure.

Feel free to call a giraffe a dog and then get upset when people point out that nobody else calls that thing a dog.