Wie Bitcoin versehentlich NFTs bekommen hat
Dieses Bild ist auf der Bitcoin-Blockchain in Block 774.370.
Weil es im Taproot-Protokoll keine Begrenzung für die Witness-Daten gibt, wird es möglich, einigermaßen große Dateien auf der Bitcoin-Blockchain zu speichern. Das Ordinals-Protokoll macht davon Gebrauch, um einzelne Satoshis zu Sammlerstücken aufzuwerten. Die nun eingeführten Bitcoin-NFTs führen zu hitzigen Diskussionen in der Community.
Bitcoin hat mal wieder einen kleinen Skandal: Jemand hat einen Trick gefunden, um Dateien auf die Blockchain zu laden und damit NFTs zu schaffen. Der Trick nutzt eine Lücke im Taproot-Protokoll aus – und spaltet die Szene: Die einen laden Bilder auf die Blockchain und freuen sich über ihre NFTs, während die anderen fluchen und überlegen, wie sie Bitcoin vor diesem Unfug beschützen können.
Aber beginnen wir ein Stückchen weiter vorne.
Es gibt schon seit langem eine Debatte darüber, ob es möglich sein darf, Bitcoin als Datenspeicher zu nutzen. Grundsätzlich tendieren die Entwickler dazu, dass Bitcoin ein reines Zahlungssystem ist und kein dezentraler Cloudspeicher. Doch weil es immer einen Weg gibt, Daten auf die Blockchain zu bringen, wenn man unbedingt will, haben sie 2014 mit OP_Return erlaubt, auf “sanfte” Weise bis zu 80 Bytes an eine Transaktion anzuhängen. Dies wurde von verschiedenen Protokollen rege genutzt, etwa Omni, Counterparty und Veriblock, flaute dann aber ab etwa 2019 deutlich ab, vermutlich, weil Ethereum und andere Blockchains besser passten.
Soweit, so gut. Wir haben Blockchains für Token, die zur Basis von tausenden und abertausenden Token und NFTs wurden, und wir haben Bitcoin, eine simple, stabile und eiserne Blockchain, die genau das kann, was Satoshi geplant hat: Geld überweisen.
Satoshis für Numismatiker
Das änderte sich vor einigen Tagen, als das Ordinals-Protokoll live ging und sogenannte Inscriptions erlaubte. Seitdem laden Bitcoiner Bilder auf die Blockchain – am liebsten diverse Varianten von Bitcoin-Illustrationen – und NFTs landen auf Bitcoin.
Die Theorie von Ordinals ist durchaus interessant und originell. Sie macht Satoshis (Sats), nicht Bitcoin, “zur atomaren, nativen Währung des Bitcoin-Netzwerks.” Ein Satoshi ist die kleinste Einheit von Bitcoin, 0,00000001 BTC, derzeit 0,02 Cent. Ordinals betrachtet jeden Satoshi als Einzelstück von numismatischem Wert. Denn Satoshis sind zwar an sich fungibel, aber sie sind nicht gleich. Es gibt verschiedene Seltenheitsgrade, die einen Satoshi auszeichnen:
Gewöhnlich: Jeder Sat, der nicht der erste seines Blocks ist
Ungewöhnlich: Der erste Sat jedes Blocks
Selten: Der erste Sat jeder Difficulty Adjustment Periode
Episch: Der erste Sat jeder Halving-Epoche
Legendär: Der erste Sat jedes Zyklus
Mythisch: Der erste Sat des Genesis-Blocks
Bitcoin hat seine verschiedenen Zyklen: Blöcke (alle zehn Minuten), Difficulty Perioden (alle 2016 Blöcke), Halving-Äras (alle 210.000 Blöcke). Ordinals definiert zudem Zyklen, wenn Halving und Difficulty-Anpassung zusammenfallen, was jedes sechste Halving passieren sollte (alle 24 Jahre). Der mythische Genesis-Sat ist der erste Satoshi, der jemals erzeugt wurde. Er liegt für alle Zeiten im Genesis-Block fest und ist unerreichbar.
Wenn ein Satoshi nun am Anfang eines solches Zyklus steht, wird er besonders. Alle anderen Satoshis sind gewöhnlich.
Satoshis beschriften – Artefakte schaffen
Doch Ordinals erlaubt auch, ordinäre Satoshis aufzuwerten oder seltene zu veredeln. Durch “Inscroptions” kann man sie an Daten wie eine Bilddatei knüpfen. Man kann sie quasi beschriften:
“Satoshis können mit beliebigen Daten beschriftet werden, wodurch Bitcoin-native digitale Artefakte entstehen. Die Beschriftung funktioniert, indem man den Satoshi mit einer Transaktion versendet, die den Content onchain onchain zeigt. Dieser Content ist untrennbar mit dem Satoshi verbunden und macht ihn so zu einem unveränderbaren digitalen Artefakt, das man nachverfolgen, transferieren, horten, kaufen, verkaufen, verlieren und wiederentdecken kann.” Inscriptions schaffen, anders ausgedrückt, einen NFT.
Anders als viele NFTs verlinken die Inscriptions nicht zu einer Bilddatei, die beispielsweise auf dem Interplanetary File System (IPFS) liegt, sondern laden die gesamte Datei auf die Blockchain. Das ist gut, weil die Daten so ebenso verewigt werden wie die Transaktion. Es sollte aber eigentlich gar nicht möglich sein, da bei Bitoin der OP_Return-Anhang auf 80 Byte begrenzt ist, was bestenfalls winzige Pixelbilder erlaubt. Doch eine Art Lücke im Taproot-Protokoll, das vor etwa einem Jahr eingeführt wurde, erlaubt es, sehr viel größere Daten hochzuladen.
Ein “Hack” von Taproot
Technisch ist das Verfahren ziemlich interessant. Die Bilder werden in “taproot script-path spend scripts” gespeichert. Taproot-Scripte haben, erlärt die Ordinals-Dokumentation, “sehr wenige Begrenzungen ihres Inhalts, und erhalten zusätzlich einen Witness-Discount, was das Speichern von Inscriptions relativ ökonomisch macht.” Das hört sich kompliziert an, ist aber, auf einer groben Ebene, gar nicht so schwierig zu verstehen.
So wie P2SH-Transaktionen definieren Taproot-Transaktionen (P2TR) bestimmte Bedingungen, unter denen ein Output ausgegeben werden kann. Diese Bedingungen werden als Hash – bzw. als Root Hash eines Hashbaums – deklariert: als eine sehr kurze Zeichenfolge, die es erlaubt, zu prüfen, ob eine später enthüllte Information die Bedingungen erfüllt. Wenn man nun eine Transaktion bildet, die den Output ausgibt, muss man in dieser Transaktion jene Information preisgeben, quasi das Geheimnis oder Script, welche den Hash ergibt.
Kurz: Die erste Transaktion bildet einen Output, den man nur ausgeben kann, wenn man mit der Nachfolgetransaktion ein Geheimnis enthüllt. Dieses Geheimnis wird die “Witness-Data” genannt, da es das Recht bezeugt, den Output auszugeben. Bei P2SH ist dieses Geheimnis ein Script, bei P2TR steckt dahinter ein Hashbaum, der vielfältigere Geheimnisse erlaubt. Da es bei Taproot keine Begrenzung der Witness-Data gibt, kann man nun fast beliebig große Dateien einpflegen. Die Grenze ist lediglich das (harte) Limit der Blocksize von 4 Megabyte bzw. das von Bitcoin Core gesetzte (weiche) Limit von 400 Kilobyte für eine Transaktion.
Dazu kommt noch, dass SegWit einen Discount auf die Witness-Data eingeführt hat. Bei der Berechnung der Gebühren zählen die Witness-Daten nur mit einem Viertel der Größe. So wurde es also möglich,relativ günstig interessante Illustrationen zu Bitcoin hochzuladen, CryptoPunks und Bored Apes auf Bitcoin zu bringen, oder auch die Etherrocks zu Bitcoin-Rocks umzubranden.
Kann man das nicht verbieten?
Neben diesem spaßigen, numismatich interessanen Aspekt haben die Inscriptions aber auch einige ernstere Aspekte, die in der Szene rege Diskussionen angestoßen haben.
Manche empfinden Ordinals als Angriff auf Bitcoin. Bitcoin ist für monetäre Transaktionen da. Inscriptions rauben diesen den Platz auf der Blockchain und müllen dieselbe mit sinnlosen Daten zu, welche die Full Nodes speichern müssen. Sie tragen zudem das Risiko, illegale Daten auf die Blockchain zu bringen, was die juristische Stellung eines Full Nodes verschlechtern kann. Die NFTs machen Bitcoin nicht besser, sondern schlechter, weshalb manche Bitcoin-OGs sie am liebsten unterbinden wollen.
“Ordinals” is a DOS attack on #Bitcoin nodes and it would be good to have a mitigating softfork, perhaps limiting OP_PUSH ops per input or tx? Open to ideas
— Bitcoin is Saving (@BitcoinIsSaving) January 30, 2023
Bitcoin Knots Entwickler Luke Dashjr fragt daher kurzerhand, ob schon jemand an einem “Spam Filter” für “diesen Müll” arbeite.
Is anyone working on a spam filter for this garbage yet?#Bitcoin https://t.co/Wws8hi54R4
— @LukeDashjr@BitcoinHackers.org on Mastodon (@LukeDashjr) January 28, 2023
Denn Ordinals sei nicht Bitcoin, sondern ein Angriff auf Bitcoin:
It's not Bitcoin, it's an attack on Bitcoin
— @LukeDashjr@BitcoinHackers.org on Mastodon (@LukeDashjr) January 29, 2023
Blockstream-CEO Adam Back empfiehlt, die Daten auf andere Weise zu speichern, etwa im IPFS oder mit OpenTimestamps. Er meint auch, dass es nur fair wäre, wenn die Miner diesen “Mist” zensieren.
ordinal devs – sers, have you heard of @ipfs and @opentimestamps? asking for the sake of our respective node hard-drives wear-leveling.
— Adam Back (@adam3us) January 29, 2023
Daraufhin entbrannte die übliche Debatte, ob es Zensur auf Bitcoin geben darf, da ja alles, was einen gültige Transaktion sei, legitim sei. Selbst wenn sie Luke Dahjr und Adam Back nicht gefällt. Andererseits könnten die Bitcoin-Entwickler die Regeln per Softfork ändern, um bestimmte Arten von Transaktionen zu verhindern, was eine Art von Zensur wäre, aber vielleicht auch nicht.
Dem Vernehmen nach freuen sich manche Miner darüber, dass sich mit den NFTs neue Einnahmequellen erschließen. Denn die Bitcoin-Blöcke sind in letzter Zeit selten wirklich voll, so dass der Gebührendruck äußerst gering ist und die Einnahmen durch Transaktionsgebühren fallen. Dies funktioniert gerade noch, doch für die Zukunft, wenn sich der Blockreward noch ein oder zweimal halbiert, werden die Miner zunehmen darauf angewiesen sein, dass die Blockchain benutzt wird. Daher sorgen die Bitcoin-NFTs, so seltsam es sich anhört, indirekt für die nachhaltige Sicherheit der Blockchain.
Die Debatte ist, zugegeben, nicht einfach zu entscheiden. Es gibt Gründe, die Bitcoin-Blockchain nicht als Lager für Bilddateien zu verwenden – und es gibt Gründe, dies interessant zu finden und dagegen zu sein, zensierend einzuschreiten. Aber eine solche Debatte ist ohnehin müßig, denn bis auf weiteres wird Bitcoin mit den NFTs von Ordinals leben müssen.
Wenn jemand ein kinderpornographisches Bild in eine Transaktion packt, wird es in vielen Jurisdiktionen für alle Zeiten illegal, die Blockchain zu speichern, sprich, einen Full Node zu betreiben?
Es dürfte wohl nicht lange dauern, bis ein Bitcoingegner auf diese Idee kommt. Mich würde interessieren (habe die Diskussion nicht verfolgt), ob jemand diese Befürchtung schon geäußert hat, bevor Taproot eingeführt war, oder ob es sich um einen „Unfall“ handelt.
Sehr interessantes Gedankenspiel! Das ist (für mich) das Argument schlechthin, diese Designlücke zurück zu bauen und das Hochladen von Bildern in die BTC-Blockchain zu verhindern.
Für den Fall, dass zuvor schon so ein Bild hochgeladen wurde, hilft wohl nur ein Software-Update, welches den betroffenen Block “hartkodiert” mit einer um das Bild bereinigten Version enthält und zusätzlichem Code, der die Clients den nächsten Block trotz nicht passender Hashsumme dennoch akzeptieren lässt. Zusätzlich muss die Software den betroffenen, zuvor gültigen Block, explizit vom Rechner löschen (obwohl er ansonsten allen Regeln entspricht!). Alles eben hartkodiert. Je länger sich die BTC-Entwickler Zeit lassen, desto aufwendiger wird es, falls ein Spammer über einen längeren Zeitraum hinweg regelmässig solche Bilder hochlädt.´
Wenn das nicht geschehen sollte ist BTC in meinen Augen tot, zumindest in den Ländern mit den entsprechenden Gesetzen. Dann wird es nämlich auch nie passieren, dass die Zentralbanken BTC in ihre Bilanzen aufnehmen werden, was für mich ein wichtiger Schritt in den nächsten 10 Jahren darstellt.
Die Möglichkeit, so eine bereinigte Version eines Blocks mit nicht passender Hashsumme im Nachhinein akzeptieren zu lassen … das würde dann ja bei jeder irgendwie unerwünschten Transaktion funktionieren, ob da nun ein bestimmtes Bild drin ist oder eine Zahlung an einen unliebsamen Journalisten. Wer entscheidet, wann dieser Mechanismus greift – „die BTC-Entwickler“, von denen du schreibst?
Ich würde sagen, wenn so ein Software-Update durchkommt, ist BTC ebenfalls tot.
Man kann die Witness-Data prunen, also löschen, d.h. ein Node funktioniert auch ohne die illegalen Dateien. Allerdings braucht man sie, um zu verifizieren, ob eine Transaktion- und damit die Blockchain- korrekt ist.
Wie würde das im Folgenden funktionieren, wenn so eine Transaktion dann später reinkommt? Gibt es dann nicht einen Split im Netzwerk weil die Transaktion von meinem “geprunten” Node nicht verifiziert werden kann und damit als ungültig angesehen wird? Oder würde sich mein Client dann temporär zum Verifizieren die Witness-Data anderweitig wieder dazu laden (und hoffentlich gleich im Anschluss wieder verwerfen)? Was wäre, wenn “sämtliche” (oder sagen wir “fast alle”) Nodes die Witness-Data geprunet haben … dann wird es schwierig, sie für die Verifikation nochmals nachzuladen …? Fragen über Fragen 🙂
Ein schneller Gedanke, der mir gerade gekommen ist. Achtung, mein Hintergrund ist der, dass ich mich nur oberflächlich mit Bitcoin ausdenke (schon tiefer als 99% der Weltbevölkerung, aber eben nicht wirklich tief), vermutlich klappt meine Idee daher nicht ganz, aber …
…
Was wäre wenn es zusätzlich zum normalen Mining-Mechanismus noch einen parallelen “Mining-Slot” gäbe. Quasi eine Art “Super-Lotterie”. Es geht darum, die Blockchain wieder zu verkürzen. Das kann natürlich nur funktionieren, wenn die Schwierigkeit dafür abartig gross ist (sagen wir Faktor 4320 grösser als die jeweils aktuelle Difficulty – gerne rollierend, sodass die Schwierigkeit leichter wird, je mehr Zeit verstrichen ist zwischen dem letzten “Pruning”. Von der Idee her sollte im Schnitt 1x pro Monat ein Pruning stattfinden, daher Faktor 4320, was der Block-Anzahl in 30 Tagen entspricht). Denn immerhin wäre die Blockchain im Anschluss nur “einen Block gross” und alle Nodes sollten diesen bitteschön akzeptieren, daher muss es eben so schwierig sein, damit nicht irgendjemand daherkommt und es nicht zu häufig passiert. Es wäre so etwas Ähnliches wie ein grosser Snapshot-Block: er enthält den zu diesem Zeitpunkt gültigen Zustand (wie sagt man es richtig, Outputs?), sodass alle BTC Adressen weiterhin gültig bleiben und aus Anwendersicht (=BTC überweisen, empfangen etc.) alles weiterhin funktioniert. Nur eben so, dass die History davor nicht mehr notwendigerweise benötigt wird um einen Full-Node zu betreiben, d.h. für einen Full-Node würde es ausreichen, beim letzten dieser “Snapshot”-Blöcke mit der Verifikation zu beginnen (Strafverfolgungsbehörden können ja trotzdem noch die ganze Kette bis zum Ursprung vorrätig halten – natürlich wird es nach ein paar Jahren irgendwann für neue Full Nodes schwierig werden, an die komplette History bis zum Gensis-Block zu gelangen, aber wer über Jahre hinweg dauerhaft online ist sollte sie ja dennoch irgendwann beisammen haben – für Strafverfolgungsbehörden also kein Problem).
Das löst aber noch nicht das Problem, dass die Witness-Data (als zukünftiges Beweismittel, dass mir ein Output gehört) dann immer noch vorhanden sein muss, entsprechend auch ein illegales Bild in der Witness-Data. Diese muss daher technisch (jedoch nicht juristisch) zensierbar sein. Der rechtmässige Besitzer muss immer noch die Möglichkeit haben, an seine BTC zu gelangen, jedoch nicht mehr technisch: die Miner könnten den Output (=Betrag) bspw. zwangsumleiten auf eine Treuhand-Wallet. Der Besitzer darf dann bei seiner Regierung vorsprechen, ggf. seine Anklage erhalten, dafür aber auch an seine BTC herankommen (wenn sie ihm rein rechtlich dann noch zustehen) … wie entscheiden Miner, welche Outputs zwangsumgeleitet werden? Vielleicht mit einem Voting-System? Jeder Client könnte Outputs flaggen, die entfernt werden sollen. Ab einer gewissen Menge an Flags könnte es dann erlaubt sein, Outputs auf die besagte(n) Treuhand-Wallets umzuleiten.
So, jetzt bin ich mal gespannt, was ihr dazu denkt. Gerne dürft ihr meine Idee zerreissen etc. … es war wie gesagt nur ein schnelles Gedankenexperiment um das Problem der illegalen Daten auf der Blockchain zu lösen.
Update:
Ich hatte bis eben noch einen Denkfehler: ich dachte, die Witness-Data muss vorab auf der Blockchain sein, damit man seine Berechtigung am Output nachweisen kann. Tatsächlich ist es, wie Christoph im Artikel beschreibt, nur notwendig, die Witness-Data im Zusammenhang mit der Transaktion preis zu geben, mit der man den Output ausgeben will. Das heisst, dass meine Idee oben mit den “Snapshot-Blocks” tatsächlich auch komplett ohne Zensur funktionieren könnte.
Wichtig bzw. klar ist natürlich: in einen neuen “Snapshot-Block” müssen sowohl ALLE zuvor gültigen Snapshot-Blöcke einfliessen (=Kette), als auch der zuletzt gültige “normale” Block. Gesnapshottet wird damit letzten Endes immer der Teil zwischen dem letzten und vorletzten Snapshot-Block.
Skizze (S = Snapshot-Block, ca. 1x pro Monat / Jahr wie auch immer, n = normaler Block, alle 10min):
Aktuelle Blockchain:
n – n – n – … – n
Mit dem ersten Snapshot-Block:
(n – n – n – … – n – ) S
–> Full Nodes müssen nur S wissen
–> Wer mag, darf auch die vorherige Kette nachfragen
Ein Block nach dem ersten Snapshot-Block:
S – n
Ca. ein Monat nach dem ersten Snapshot-Block kommt der 2. Snapshot-Block:
S – n – n – … (ca. 4320 Blöcke) – S
Alle Clients, Full Nodes können bei Bedarf (sagen wir im Default-Modus) die Kette ersetzen durch:
S – S
Irgendwann haben wir dann folgenden Zustand (für neue, minimale Full Nodes):
S – S – S – S – S – n – n – … (bis zu 4320 Blöcke)
Möglicherweise braucht es, um in der Realität zu funktionieren, noch kleinere Anpassungen, aber ich hoffe das grobe Prinzip ist klar geworden. Was denkt ihr?
Hm, aber um die Witness-Daten einer Transaktion zu löschen, möglichst bevor man sie gespeichert hat, müsste man einer dritten Partei vertrauen, die eine Liste der entsprechenden problematischen Transaktionen vorhält.
Das jemand – der so etwas Dämliches tut – das Geld dann nicht mehr ausgeben kann, fände ich überhaupt nicht schlimm, sofern dort tatsächlich entsprechende Bilder drin sind.
Wenn damit ein unterschwelliger Mechanismus für Zensur von Blöcken geschaffen wird, ist das hingegen schon ein ziemliches Problem. Natürlich kann man sich immer – in entsprechenden Jurisdiktionen – in die Gefahr begeben und den Inhalt der Witnessdata prüfen, somit wäre Zensur eh nicht perfekt machbar.