An ersten beiden Irrtümern sind meiner Meinung nach die Medien mit ihrer schlechten Recherche, Copy&Paste sowie Clickbait Mentalität schuld.
Die Geldwäsche Behauptung rührt von dem Irrtum, dass Bitcoin anonym sei aber in Wirklichkeit pseudonym ist. Gutes Beispiel: Ross Ulbricht sowie Shaun Bridges.
https://www.theguardian.com/technology/2015/jul/02/silk-road-undercover-dea-agent-turned-bitcoin-thief-pleads-guilty

Der "Angriff" ist möglich.
Er hat nur nichts mit Bitcoin zu tun
Strafbar ist er übrigens auch, zumindest in der EU und den USA, vermutlich aber in den meisten zivilisierten Ländern der Welt. Unabhängig davon, ob der Angreifer den Double Spend gegen sich selbst ausführt oder nicht, handelt es sich um eine Marktmanipulation.

Eine vorsätzliche Markmanipulation, die noch dazu gewerblich und/oder bandenmäßig durchgeführt wird, ist ein Verbrechen, welches mit Freiheitsstrafe bis zu zehn Jahren geahndet werden kann. Die Geldbuße kann dabei bis zum Dreifachen des Gewinns betragen.

Alles in Allem würde ich sagen, der Angreifer hat das selbe Problem wie bei der normalen 51%-Attacke: er ist leicht identifizierbar und riskiert eine schwere Straftat, seine Miner können beschlagnahmt werden, er kassiert eine gewaltige Geldstrafe etc.
Anders gesagt: lohnt sich nicht. Punkt.

Hm, ist eigentlich durch Punkt 11 schon erklärt. Es gibt keine ganzen Bitcoins, sondern nur ganze Satoshis

Mal ein erster Entwurf, weil ich das schon länger vor mir herschiebe:

Warum auch eine 100%-Attacke keine Gefahr für Bitcoin darstellt

Um das zu erklären, ist sicherlich ein einfaches Gedankenexperiment am besten.

Bob hat einen Super-Virus entwickelt, der alle Computer, die an Bitcoin minen, auf einen Schlag zerstört (bis auf seine eigenen, natürlich).
Damit kommt er plötzlich zu 100% der Rechenleistung im Bitcoin-Netzwerk.

Was kann er jetzt mit seiner Superkraft anfangen?
Er kontrolliert in jedem Fall, welche Transaktionen überhaupt noch in neue Blöcke gelangen.
Das macht ihn sozusagen zur "Zensurbehörde" des Bitcoin-Netzwerks.

Somit kann er z.B. verhindern, dass noch Bitcoins zu Börsen überwiesen werden.
Er kann damit den Preis von Bitcoin mit Sicherheit massiv nach unten drücken.

Er kann auch verhindern, dass Alice Bitcoins überweist. Die Bitcoins von Alice sind damit insofern "wertlos", als Alice sich damit nichts mehr kaufen kann.

Kann Bob die Bitcoins von Alice aber klauen? Nein.
Sofern Alice ihre Bitcoins schon eine zeitlang hat, sind ihre Bitcoins sicher.
Wenn Alice ihre Bitcoins erst vor ein paar Transaktionen bekommen hat, könnte Bob die Transaktion, in der Alice ihre Bitcoins erhalten hat, "rückgängig" machen, genauer gesagt, er kann eine Blockchain durchsetzen, in der Alice diese Bitcoins nie erhalten hat.
Alice hat zwar ihre Bitcoins nicht mehr, aber Bob hat sie auch nicht, sondern wieder derjenige, der die Bitcoins eigentlich an Alice gesendet hatte.

Soweit, so schlimm.

Das Problem an der Sache ist für Bob, dass all das nicht unbemerkt bleibt.
Zum einen wundern sich die Miner auf aller Welt, warum ihre ASICs plötzlich explodiert sind und zum anderen wundern sich Bitcoiner auf aller Welt, warum sie ihre Bitcoins nicht mehr versenden können.
Da niemand so recht weiß, was da eigentlich los ist, wird vorerst niemand mehr Bitcoins überweisen.

Wenn dieser Zustand länger anhält (dafür reichen in der Praxis wahrscheinlich schon ein, zwei Stunden), werden die Entwickler von Bitcoin Telefonkonferenzen mit den großen Minern abhalten, um zu klären, was hier gerade passiert.
So etwas ähnliches ist schon einmal geschehen, als sich in einem Versionswechsel ( von 0.7 auf 0.8 ) die Bitcoin-Blockchain versehentlich "aufgespalten" oder "geforkt" hat.
In diesem Zuge werden die Miner und Entwickler sehr schnell zu dem Ergebnis kommen, dass es sich hier um einen großangelegten "Angriff" auf Bitcoin handelt.

Den Entwicklern bleibt in solch einem Fall eigentlich nur eine Lösung:
Der Mining-Algorithmus von Bitcoin muss sofort geändert werden.
Die Miner werden davon sicherlich nicht begeistert sein, alle ihre ASICs sind damit auf einen Schlag wertlos.
Andererseits bleibt ihnen nichts anderes übrig, weil ohne eine Änderung ihr Equipment auch wertlos ist, wenn Bitcoin nicht mehr "funktioniert" (abgesehen davon ist ihr Equipment sowieso kaputt).
Die großen Miner werden vermutlich darauf drängen, einen bestehenden Algorithmus zu verwenden, für den sie selbst schon Equipment am Laufen haben.
Die meisten größeren Miner dürften also z.B. auf den Scrypt-Algorithmus setzen, was auch insofern sinnvoll ist, als damit das neue Bitcoin-Netzwerk von Beginn an eine gewisse, hohe Leistungsfähigkeit hat.

Wie lange es dann dauert, bis die Entwickler eine neue Version von Bitcoin "programmiert" haben, die den neuen Algorithmus verwendet, ist schwer abzuschätzen. Man wird sicherlich auf Nummer sicher gehen wollen, und die Software wenigstens ein paar Tage testen.

Insofern kann man davon ausgehen, dass im Falle einer 100%-Attacke das Bitcoin-Netzwerk für einige Tage stillsteht.
Danach geht es mit neuem Algorithmus weiter.
Die alten Miner haben herbe Verluste erlitten, weil ihr Equipment in Flammen aufging und die entwickelten ASCIs wertlos sind. Andererseits besteht ihre Infrastruktur weiterhin und sie sind in der Lage, ihre Rechenzentren relativ schnell mit neuen ASICs für den neuen Algorithmus auszustatten. Damit bleiben sie wohl weiterhin die dominanten Player im Bitcoin-Netzwerk.

Das neue Bitcoin-Netzwerk ist kurzfristig deutlich geschwächt, die Miner werden aber in relativ kurzer Zeit (vermutlich ein paar Wochen bis wenige Monate) ihre Rechenzentren mit voller Kapazität wieder laufen haben.

Einige wenige Transaktionen in einem Zeitraum von einigen Stunden sind "unklar", es muss also eine Entscheidung getroffen werden, ob diese gültig sind oder nicht. Man wird sich vermutlich auf die konservative Lösung einigen, im Zweifel lieber ein paar Blöcke weiter zurückzugehen, um den letzten "sicheren" Block zu bestimmen.
Damit müssen wahrscheinlich einige Nutzer mit gewissen Verlusten leben, andere werden mit ihren Geschäftspartnern eine Neu-Abwicklung bereits getätigter Transaktionen aushandeln müssen.

Das Bitcoin-Netzwerk als solches ist nicht unsicher geworden, es hatte nur einen mehrtägigen Herzstillstand.
Die schnelle Lösung des Problems ohne, dass es hierbei zu einer Zentralisierung gekommen wäre, ist ein überzeugender Beweis für die Robustheit des Systems Bitcoin.
Mittel- und langfristig geht Bitcoin deutlich gestärkt aus diesem Vorfall hervor.
Kurzfristig kommt es natürlich zu Kurseinbrüchen und schlechter Presse.
Wenige Nutzer werden tatsächlich einen Schaden haben.


Und Bob? Er hat eine Menge Geld in sein eigenes Equipment investiert.
Dieses Equipment kann nur SHA256, den ursprünglichen Algorithmus von Bitcoin.
Bitcoin verwendet nun aber kein SHA256 mehr.
Seine Investition ist wertlos.
Er konnte keine Bitcoins erbeuten.
Er konnte das Bitcoin-Netzwerk nicht ernsthaft beschädigen.
Hat er versucht, mit massivem Shorting oder dergleichen Geld zu verdienen, wird er voraussichtlich beim "Auscashen" erwischt und wandert auf Jahre in den Knast.
War er ein Geheimagent, der seinen Chef überzeugt hat, dass dieses Milliardenprojekt Bitcoin in die Knie zwingen wird, hat sein Scheitern sicherlich seine Kündigung zur Folge.
Armer Bob.

"Schnellere Blöcke sind besser", "mehr Confirmations sind sicherer"

Die Anzahl der Bestätigungen sagt nichts über die Sicherheit einer Transaktion aus.
Das hört sich erstmal falsch an. In der Tat ist natürlich innerhalb des Bitcoin-Netzwerks eine Transaktion mit mehr Bestätigungen stets sicherer als eine Transaktion mit weniger Bestätigungen.
Aber, es kommt genau genommen nicht auf die Anzahl der Bestätigungen an, sondern auf die Zeit, die seit einer Transaktion vergangen ist.
Die Sicherheit einer Transaktion in einer Blockchain ist stets so "hoch" wie die Rechenleistung, die benötigt würde, um diese Transaktion "rückgängig" zu machen (siehe hierzu auch die 51%-Attacke).
Man kann es auch anders formulieren: um eine Transaktion rückgängig zu machen, ist immer ein gewisser Stromverbrauch notwendig. Je höher dieser Stromverbrauch, umso teurer wird es für einen Angreifer. Irgendwann ist der Angriff einfach zu teuer.

Wenn nun ein Altcoiner sagt, "wir haben einen Block pro Minute, also hat eine Transaktion viel schneller 6 Bestätigungen, und ist deswegen schneller sicher", liegt er damit schon aus zwei Gründen falsch.
Zum einen haben seine 6 Bestätigungen nur 6 Minuten gedauert, er hat also nur die Sicherheit von 6 Minuten Rechenzeit in seinem Netzwerk, im Gegensatz zu einer Stunde im Bitcoin-Netzwerk.
Zum anderen verfügt sein Netzwerk vermutlich auch über deutlich weniger Rechenleistung als das Bitcoin-Netzwerk, damit ist der Aufwand oder "Stromverbrauch" für einen Angriff ohnehin erheblich geringer.
In Summe sind also z.B. 6 Bestätigungen in z.B. Litecoin erheblich unsicherer als 6 Bestätigungen im Bitcoin-Netzwerk.
Geschätzt um den Faktor 100 unsicherer, um genau zu sein (Faktor 10 wegen "eine Bestätigung pro Minute", x Faktor 10 wegen der um mindestens ein 10-faches geringeren Rechenleistung des gesamten Litecoin-Netzwerks).

Eine kleine Anmerkung hierzu:
Die Entwickler von Altcoins sind i.d.R. Informatiker. Sie haben gelernt, solche Berechnungen durchzuführen.
Man darf daher mit Fug und Recht davon ausgehen, dass sie sich keineswegs einfach nur "irren", wenn sie behaupten, ihr Altcoin mit einer Bestätigung pro Minute wäre "sicherer" als Bitcoin.
Man muss davon ausgehen, dass die Entwickler solcher Altcoins ihre Nutzer vorsätzlich täuschen, um ihre Produkte zu verkaufen. Nach Deutschem Recht ist ein solches Vorgehen Betrug, und somit eine Straftat.
Anders gesagt: die Entwickler solcher Altcoins sind Kriminelle.

Nun ja, beim 100%-Attack würde aber Bob:
- kaum Geld für ASICs ausgeben müssen (die anderen sind ja eh explodiert)
- selber double spenden, nicht irgendwelche anderen Transaktionen rückgängig machen
- vielleicht sogar Segwit-Anyonecanspend durchsetzen (dazu müsste er den Angriff aber heimlich durchführen, ohne den "Supervirus", sondern einen, der einfach die Effizienz der Asics runtersetzt oder so )
... oder alternativ:
- Bitcoin massiv shorten - wie bei meinem letzten Post erklärt.

Der PoS-Abschnitt:  . Punkt.

Punkt 1 - haste vollkommen recht, hab das mit der Difficulty nicht bedacht. Zumindest einen Teil der Hashrate könnte er sich aber sicher auch mieten.

Ich denke, er würde eine Kombination aus Punkt 2 und 3 (massives Double Spending und Shorten) versuchen. Hab deinen Satz zum Shorten jetzt gesehen - aber ich bin nach wie vor nicht 100% überzeugt, dass der Shorter hier eine Straftat begeht (vielleicht Sachbeschädigung?).

Jedenfalls glaube ich, dass ein Angreifer mit 100% ziemlich viel Unheil anstellen kann, und dass damit das Vertrauen in die betroffene Blockchain erst mal dahin ist (=Quasi-Totalverlust für alle "Investoren").

Mir ist schon klar, dass du das nur als Extrembeispiel bringst, aber dennoch ist mir das etwas zu "rosig" beschrieben.

Zu PoS nur ganz kurz, deine Meinung ist ja da "gefestigt": Ich bin mir eigentlich fast sicher, es geht auch ohne PoW gut genug für eine funktionierende und sichere Kryptowährung. Sieben Jahre Forschung, dazu noch in einem Nischengebiet der Informatik, sind halt nicht sooo viel, jedenfalls nicht genug, um ein Problem ad acta zu legen, das eines der großen Probleme von Bitcoin lösen könnte ...

Was ist eigentlich ein "Hash"?
Ein Hash ist eine Art eindeutiges "Alias" für einen Wert.
Klingt komisch, ist aber so.

Das ist der Bernd. Der Bernd, der hat 'ne Disco.
Weil da immer viele Leute reinwollen, hat der einen Türsteher, den Klaus.
Der Klaus bekommt vom Bernd jeden Abend eine Gästeliste.
Da stehen Leute drauf, die in die Disco rein dürfen.

Weil der Bernd aber nicht will, dass der Klaus zur Presse geht, und den Paparazzi erzählt, dass heute abend die Lady Gaga auf der Gästeliste steht, schreibt der Bernd nicht die Namen der Gäste auf die Liste, sondern nur einen Alias.
Mit dem Alias kann der Klaus an der Tür nachschauen, ob der Gast auch eingeladen ist. Und trotzdem weiß der Klaus nicht, wer da eigentlich auf der Liste steht.

Deswegen hat sich der Bernd eine Hashfunktion für die Namen auf der Gästeliste einfallen lassen.
Er nimmt den Nachnamen und den Vornamen von 'nem Gast, dann entfernt er einfach alle Vokale und Leerzeichen.

Aus "Lady Gaga" wird dann erstmal "Gaga Lady" und schließlich "ggld".
Weil der "Elton John" auch zur Party kommt, steht auf der Liste auch "jhnltn".

Wenn jetzt am Abend die Lady Gaga an der Tür steht, kann die dem Klaus ihren Ausweis zeigen, da steht "Lady Gaga" drauf, der Klaus wendet wieder die Hashfunktion an und schaut nach, ob "ggld" auf der Gästeliste steht. Weil er "ggld" auf der Liste hat, lässt er die Lady Gaga jetzt rein.


Was ist eine "Kollision" bei einem "Hash"?
Weil der Hash manchmal für unterschiedliche Werte den gleichen Alias erzeugt, kann es schonmal zu Verwechslungen kommen.
Wenn die "Anna Meier" und die "Anne Mayr" vor Türsteher Klaus stehen, haben die beide den Hash "mrnn", also lässt der Klaus natürlich auch beide rein. Eigentlich wollte der Bern aber nur die Anna reinlassen, nicht die Anne.
Sowas nennt man dann eine Kollision. Das kommt bei einem Hash gelegentlich vor.
Eine gute Hashfunktion sorgt natürlich dafür, dass es selten zu solchen Kollisionen kommt.

Mal ein weiterer Entwurf (und ja, ich weiß, dass ich mal die eigentliche FAQ überarbeiten und ergänzen muss)

Smart Contracts
Smart Contracts sind eine tolle Sache und man darf davon ausgehen, dass sie über kurz oder lang in vielen Bereichen zum Einsatz kommen werden.
Die allein glückselig machende Lösung aller juristischen, finanziellen und technischen Probleme sind sie aber sicher nicht.
In vielen Fällen sind Smart Contracts vor allem: juristisch problematisch, "dumm" und teuer.


Was sind Smart Contracts eigentlich?
Vereinfacht gesagt ist ein Smart Contract ein Stück Software, in dem bestimmte Regeln beschrieben sind, nach denen irgend ein Vorgang abläuft. Das ist so allgemein formuliert, dass man eigentlich auch sagen könnte: jedes Computer-Programm ist ein Smart Contract.
Insofern muss man die Definition sicherlich eingrenzen und voraussetzen, dass ein Smart Contract in der Lage sein muss, nach Außen wirksame Entscheidungen auf der Basis vorher bestimmter Regeln zu treffen. Aber selbst das trifft eigentlich noch auf alle Programme zu (nach Außen wirksam wäre z.B. die Ausgabe von Zeichen auf einem Computerbildschirm).
In Bezug auf unseren heutigen Umgang mit dem Begriff Smart Contract wäre also noch zu ergänzen, dass dieser in der Lage sein muss, direkt finanziell wirksame Entscheidungen zu treffen. Dies kann der Smart Contract nur dann, wenn er unmittelbar Zugriff auf die finanziellen Mittel hat.

Man kann das einfacher sagen:
Ein Smart Contract ist ein Programm, in dem Geld "drinsteckt", das er nach vorher definierten Regeln verteilen kann.


Benötigt man für Smart Contracts eine Blockchain?
Nein.
Smart Contracts können auch einfach auf einem einzelnen Computer ablaufen.
Die Blockchain dient lediglich dazu, dass die Benutzer des Smart Contracts dem Computer nicht mehr vertrauen müssen.
Auch für das Geld, das im Smart Contract stecken soll, sind Blockchains i.d.R. eine Voraussetzung.


Für den folgenden Abschnitt gilt als enge Definition für einen Smart Contract:
Ein Smart Contract ist ein Programm, welches auf einer Blockchain läuft, selbst unmittelbar Geld "enthält" und dieses Geld nach den vorher definierten Regeln des Programms verteilen kann.


Sind Smart Contracts (im juristischen Sinne) Verträge?
Das muss man mit einem ziemlich eindeutigen "Nein" beantworten.
Das folgende beschreibt zunächst die juristische Situation in Deutschland, analog gilt das aber wohl in den meisten Rechtssystemen weltweit.
Für das Zustandekommen eines Vertrags bedarf es zweier übereinstimmender Willenserklärungen von (natürlichen oder juristischen) Personen.
Er wird geschlossen durch die Abgabe eines Angebots und einer Annahme desselben.
Man kann also zunächst davon ausgehen, dass der "Initiator" eines Smart Contracts ein Angebot in Form des Quelltexts abgibt.
Da nun für gewöhnlich ein Nutzer nicht zugleich Programmierer ist, ist er auch nicht in der Lage, den eigentlichen Angebotsinhalt, also den Quelltext, zu verstehen.
Somit ist er aber auch nicht in der Lage, überhaupt eine Willenserklärung zur Annahme abzugeben.
Damit kommt der Vertrag rein formal nicht zustande.
Vielmehr wird der Nutzer i.d.R. seine Zustimmung zur geschilderten Funktionsweise des Smart Contract erteilen.
Er nimmt also nicht den Smart Contract selbst an, sondern lediglich dessen "umgangssprachliche" Beschreibung durch den Anbieter.
Dies hat erhebliche Auswirkungen.
Weicht nämlich die Ausführung des Smart Contract von der "umgangssprachlichen" Formulierung ab, haftet ggf. der Anbieter für Schäden, die aus dieser Abweichung entstehen.
Natürlich kann es hier Sonderfälle geben, wenn z.B. sowohl Anbieter als auch Annehmender Programmierer sind und den Quelltext verstehen, oder wenn unter echten Kaufleuten die Vereinbarung getroffen wird, den Smart Contract als maßgeblich anzusehen, selbst wenn dieser
von umgangssprachlichen Formulierungen abweicht.
Für die Frage aber, ob ein Smart Contract tatsächlich üblicherweise als Vertrag angesehen werden kann, lautet die Antwort eindeutig: Nein.

An dieser Stelle mein Dank an iudica, dem wir hierzu eine anschauliche juristische Betrachtung verdanken:
Smart Contract | Wirksamkeit & Unwirksamkeit von Vertragsprogrammen


Lassen sich Verträge überhaupt in einem Smart Contract abbilden?
Um den typischen Juristen-Spruch zu bemühen: "kommt drauf an".
Sehr einfache Verträge lassen sich sicherlich fehlerfrei in einem Smart Contract abbilden.
Eine der einfachsten Formen eines solchen Smart Contract ist z.B. eine Bitcoin-Transaktion.
Auch einfachste Wenn-Dann-Regeln können hierbei zum Einsatz kommen, man denke dabei an Multisig-Transaktionen.
Bei komplexeren Sachverhalten wird es aber schwierig.
Aus ca. 4000 Jahren Rechtsgeschichte (um hier den "Codex Hammurapi" als willkürlichen "Anfang" zu nehmen) kann man als empirisch belegt ansehen, dass es alles andere als trivial ist, eindeutige, fehlerfreie Regeln selbst für relativ einfach gestaltete Rechtsgeschäfte zu definieren, die keiner weiteren Interpretation bedürfen.

Komplexität ist hierbei tatsächlich das "Zauberwort".
Inwieweit der massenhafte Einsatz von Smart Contracts in trivialen Fällen hier zu einer Weiterentwicklung hin zu steigender Komplexität ermöglicht, wird in den kommenden Jahren sicherlich spannend mitzuverfolgen sein.
Wenn wir aus der Rechtsgeschichte aber eines lernen dürfen, dann, dass mit zunehmender Komplexität der zu regelnden Geschäftsvorfälle die Komplexität der diese regelnden Verträge eher überproportional zunimmt.

Ein abschließendes Urteil, wozu Smart Contracts tatsächlich einmal fähig sein werden, will ich mir nicht erlauben, ich bleibe vorerst allerdings vorsichtig pessimistisch.


Sind Smart Contracts "smart"?
Nein.
Im Vergleich mit anderen Programmen sind Smart Contracts i.d.R. äußerst "dumm".
Und das ist auch gut so.
Je komplexer ein Programm wird, desto höher ist die Wahrscheinlichkeit für Fehler.
Wer in seinem Smart Contract größere Geldbeträge bindet, will diese sicherlich nicht wegen einem kleinen Programmierfehler verlieren.
Insofern ist es nur vernünftig, die Komplexität von Smart Contracts so gering wie möglich zu halten.

Im Vergleich mit "echten" Verträgen sind sie ebenfalls "dumm".
Ein klassischer juristischer Vertrag "beinhaltet" immerhin letztlich die Weisheit von einigen Tausend Jahren Justizgeschichte und Fortentwicklung von Rechtssystemen, sowie die "Ausführungskapazität" des Gehirns eines durchschnittlichen Richters. Ich will mich hier nicht über die Intelligenz von Richtern auslassen, aber zumindest für den Moment darf man davon ausgehen, dass selbst der dümmste Richter noch um einiges "smarter" ist als selbst der leistungsfähigste Computer.


Sind Smart Contracts kostengünstig?
Das ist relativ. In jedem Fall sind (sinnvolle) Smart Contracts alles andere als kostenlos.
Damit ein Smart Contract seine Aufgabe erfüllen kann, muss das von ihm zu verteilende Geld in ihm "gebunden" sein.
Das bedeutet, dass ein Smart Contract für die Dauer seiner Laufzeit das Kapital, über welches er zu entscheiden hat, vollständig bindet.
Kapital zu binden, kostet Geld.
In der Wirtschaftswissenschaft spricht man hierbei von sog. "Opportunitätskosten", das sind die Kosten, die entstehen, weil einem quasi an anderer Stelle Gewinne entgehen.
Vereinfacht gesagt hätte man das Geld auf ein Sparbuch legen können und dafür Zinsen bekommen.

Damit ist auch klar, wie sich diese Kosten in Relation zum Smart Contract verhalten:
je länger der Smart Contract das Geld hält und je höher der Geldbetrag ist, umso höher sind die Kosten für seine Ausführung.
Dazu kommen ggf. noch weitere Kosten, die z.B. aus Kursschwankungen entstehen und aus Transaktionsgebühren, aber diese vernachlässige ich für diese Betrachtung.
Nehmen wir als Beispiel einen Smart Contract, der 1 Million Dollar verwalten und diese in einem Jahr wieder an die Vertragspartner ausschütten soll.
Gehen wir von 3% Zinsen aus, entstehen hier Opportunitätskosten i.H.v. 30.000 Dollar für diesen Smart Contract.
Ein anderer Smart Contract verwaltet vielleicht nur einen Dollar für eine Sekunde. Das kann ich nicht mal mehr berechnen, der Betrag ist sicherlich winzig. Aber wenn man sich vorstellt, dass ein solcher Smart Contract vermutlich millionenfach Verwendung findet, weil er z.B. für Micropayments oder dergleichen zum Einsatz kommt, ist die Summe der Kosten schnell wieder in der selben Höhe wie im oben geschilderten Fall.

Ob der Smart Contract also kostengünstig ist oder nicht, ist immer in Relation zu den Kosten zu sehen, die ein vergleichbares System ohne Smart Contract verursachen würde.
Es kann durchaus sein, dass in einem Fall der Smart Contract "billiger" ist, in einem anderen aber ein "klassischer" Vertrag mit Notar, Gutachtern, Versicherungen, Banken, etc. pp.