Bitcoin Smart Contract have been a long overseen feature of the Bitcoin Protocol.
Apparently there is a new trend in research trying to reproduce the "smart contract friendly" ecosystem built on the Ethereum blockchain also on the Bitcoin Blockchain.
[...]
Do you know more?
, where I was wondering why these contracts are not too popular, although Satoshi told Wei Dai 11.5 years ago that they are possible.
To my surprise (and others' as well), gmaxwell himself posted in my topic, this being the first time when I had the honor to see him writing in any of my topics. And he brought more light in this subject:
Bitcoin has smart contracts-- that is what script is.
This is why lightning can exist.
This is why escrow transactions
exists (which weren't just proposed by satoshi, but are used by users!)
This is why multisig exists and is extremely widely used.
Bitcoin script is only less expressive than ethereum in there respect that access to transactions and the blockchain data is limited, that a few opcodes were disabled due to dos attacks and that there is a reasonable bound on execution resources.
The reason you may have an impression otherwise is a direct result of intentional fraud perpetuated by the creators of Ethereum, breathlessly hyping some "World Computer" nonsense early on to sucker people into buying coins from their 72 million coin (17 billion dollars at current prices) pre-mine. Many of the things they marked (replacement for Facebook!) were obvious nonsense, and much of what wasn't nonsense was already possible in Bitcoin but their hype made it sound like it wasn't.
That said: every time you create a new smart contract what you are actually doing is creating a novel bespoke cryptosystem. That should be ringing alarm bells for you because almost always when someone-- even an expert-- cooks up a new cryptosystem the result is broken from top to freeking bottom. Creating secure cryptosystems is among the most challenging domains of engineering.
Ethereum throws up a javascript like interface to enable maximum YOLO by the people least familiar with infrastructure engineering, they don't give a damn about the resource impact and have utterly obliterated the scalability of their system through poor design decisions (as a result the minimum hardware to keep up with Ethereum while it's doing *fewer* transactions than bitcoin, is literally orders of magnitude more-- and as a result most businesses blindly trust consensys or another third party to give them access to a node).
But ignoring all those constraints doesn't make easier to write _SAFE_ smart contracts: experience has show that over and over again virtually all smart contracts on ethereum are absurdly vulnerable. A smart contract to enable multisig there (functionality that bitcoin had widely deployed half a decade earlier) written by the authors of one of the most popular ethereum nodes was destroyed by someone simply sending it a command to delete itself-- instantly destroying two hundred and eighty million dollars of other people's coins.
Worse, very few "smart contracts" in ethereum have any reason to exist at all. The vast majority of them are completely controlled by the decisions of a key holder (or sometimes a multisig of key holders). The only purpose those smart contracts exists is
decentralization theatre-- where people engage in something which is an unambiguous violation of securities law (and usually an outright fraud too) but then pretend it's okay because they falsely claim it's totally trustless and decentralized. Outside of those the next most common are trivial automated ponzi schemes and the like.
On the rare event where people want to actually do something interesting and worthwhile that doesn't just reduce to hiding a trusted third party the astronomical resource costs of doing in inside the EVM directly make it infeasible-- even in an exploration beta-test sense-- and instead they need to convince the operators of ethereum to hardfork the network to embed their critical inner-loop functionality in ethereum as a "precompiled contract".
Of course, Bitcoin can also be extended with new logic and much more simply and compatibility because it doesn't need to be hardforked: OP_CSV, CLTV, P2SH, and Taproot are all examples of this. (in fact, Bitcoin could provide an entirely new virtual machine in a softfork).
The issue isn't environment specific either. It turns out that creating a centralized service is a LOT easier than creating a decentralized autonomous one, and while there is an easy way to monetize a centralized service a truly decentralized autonomous service is almost impossible to monitize-- so it's difficult to justify paying for all that extra effort. ... this makes the actual demand for real smart contracts fairly low which is why you haven't seen more done there.
I'd love to see an interesting neutral database (e.g. not created by some breathless eth pumper) that attempts to catalogue actually useful and interesting ethereum smart contracts to the limited extent that they exist. Some of them are likely possible in Bitcoin currently, others would be possible with the addition of an opcode here or there. A number of years ago I assigned someone working for me at blockstream to conduct such a study-- hoping to mine it for useful operations, and they mostly came up empty. I'm
fairly sure that this wouldn't be the same today.
One of the things bitcoin developers have struggled with when it comes to adding opcodes is that while there is a multitude of interesting things that could be added, it is
exceptionally difficult to justify sticking something in the consensus rules under a conjectural "maybe this will be useful". There is a *lot* of functionality there which is essentially never used already. But this creates a bit of a chicken and egg situation because there probably is functionality that could be easily added, which people would use if it existed, but people don't develop the uses because it isn't there already.
So that's why you see that taproot creates a massive efficiency and privacy improvement for various multisig schemes and for some things like lightning-- which already have widespread use but it doesn't do much for other kinds of usage: it just isn't clear what that other kind of usage would need but it's clear what would benefit existing and related uses.
Another factor is that when something is sufficiently developed, you call it what it is, not the underlying technology. People call lightning, lightning, they don't call it smart contracts just like someone calls a chess engine a chess engine (or its name like, stockfish) rather than "artificial intelligence". The generic names are reserved for vaporware and stuff that doesn't really work but you hope it will someday.
