Ich denke beide Seiten haben gewissermaßen recht, wobei aber von unterschiedlichen Punkten gesprochen wird.
Evtl. können ja beide Seiten, wie @piet vorschlägt, mal auf den Punkt der anderen Seite eingehen.
Punkt 1) Sinnhaftigkeit von Smart Contracts
@HODLer und @DasPie sprechen Smart Contracts auf einer Blockchain, die auf Realwelt-Eingaben (Oracles) angewiesen sind, generell die Sinnhaftigkeit ab. @DasPie hat das hervorragend zusammengefasst:
Anwendungen komplett innerhalb des Systems, die keine Oracles benötigen, sind sicher interessant. Aber ich kenne mich selbst nicht damit aus, was es so gibt.
Punkt 2) Möglichkeit von Smart Contracts auf Bitcoin
Natürlich können nicht beliebige Smart Contracts auf Bitcoin implementiert werden.
Die Bitcoin Script Sprache hat bewusst einen begrenzten Umfang (s.a. Blocktrainer Artikel). Insbesondere ist sie nicht Turing-vollständig. Für alle, die nicht so tief im Thema drin sind: Alle verbreiteten Programmiersprachen heutzutage sind Turing-vollständig, was nichts anderes heißt, als dass man praktisch jede denkbare Funktionalität damit umsetzen kann.
Das sicher bewusst von @Buzz gewählte Beispiel kann man z.B. nicht direkt in Bitcoin Script umsetzen, da Bitcoin Script keine Schleifen unterstützt.
Die Beschränktheit von Bitcoin Script ist ein bewusster Trade-Off zugunsten der Sicherheit. Smart Contracts können z.B. auf Bitcoin Side Chains (z.B. RSK) oder in Zukunft evtl. durch BitVM implementiert werden. Letzteres ist interessant, allerdings auch ein bisschen von Hinten durch die Brust ins Auge.
Hier zum Thema noch ein Zitat des Altmeisters:
Mastering Bitcoin 2nd Edition, Andreas M. Antonopoulos
Transaction Scripts and Script Language
[…] Script is a very simple language that was designed to be limited in scope and executable on a range of hardware, perhaps as simple as an embedded device. It requires minimal processing and cannot do many of the fancy things modern programming languages can do. For its use in validating programmable money, this is a deliberate security feature.
Today, most transactions processed through the Bitcoin network have the form „Payment to Bob’s Bitcoin address“ and are based on a script called a Pay-to-Public-Key-Hash script. However, bitcoin transactions are not limited to the „Payment to Bob’s Bitcoin address“ script. In fact, locking scripts can be written to express a vast variety of complex conditions. […]
Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language. This language allows for a nearly infinite variety of conditions to be expressed. This is how bitcoin gets the power of „programmable money“.
Turing Incompleteness
The bitcoin transaction script language contains many operators, but is deliberately limited in one important way—there are no loops or complex flow control capabilities other than conditional flow control.
This ensures that the language is not Turing Complete, meaning that scripts have limited complexity and predictable execution times. Script is not a general-purpose language.
These limitations ensure that the language cannot be used to create an infinite loop or other form of „logic bomb“ that could be embedded in a transaction in a way that causes a denial-of-service attack against the Bitcoin network. Remember, every transaction is validated by every full node on the Bitcoin network. A limited language prevents the transaction validation mechanism from being used as a vulnerability.