Bitcoin-NFTs begeistern die Szene – und verärgern manche
Nachdem Ordinal mit den Inscriptions NFTs auf die Bitcoin-Blockchain gebracht hat, entsteht über Nacht ein neues Ökosystem. Es gibt bald 100.000 Bitcoin-NFTs, und die Preise erinnern bereits an die Hypes um CryptoPunks und Bored Apes. Aber nicht jeder ist begeistert, und die Entwickler diskutieren bereits, ob und wie sie dem Treiben einen Riegel vorsetzen können.
Die Ordinal Inscriptions, auch als Bitcoin NFTs bekannt, sind ein rasender Erfolg. Offensichtlich hat die Szene glühend darauf gewartet, endlich Bilder auf die Blockchain zu laden und Nicht-Fungible-Token zu schaffen, zu handeln und zu sammeln, ohne sich die Wallets mit Ethereum und anderen mutmaßlichen Shitcoins schmutzig zu machen: Etwa drei Wochen, nachdem Ordinal live ging, gibt es bereits mehr als 85.000 Inscriptions, und es ist ein lebhafter Markt entstanden, auf dem Bitcoin-NFTs zu sagenhaften Preisen gehandelt werden.
NFT Now schreibt fasziniert darüber, wie viele gute NFT-Sammlungen bereits auf der Bitcoin-Blockchain gelandet sind. Interessant sind etwa die Timechain Collectibles, die Uhren und Kalender mit dem Bitcoin-Logo verbinden. Die nur 21 Objekte werden über den Discord-Server des Projekts gehandelt; der Preis lag beispielsweise bei 3,08 Bitcoin für Inscription 364 (Timechain Collectible #6). Auch die Insignia Art it spannend. Sie umfasst lediglich 16 NFTs, die eine Art Wappen darstellen – Schilder, Affenköpfe, Kronen, Bäume, Drachen, Sonnen – und, so das Projekt, “die rapide Reproduktion, Verbreitung und Nutzung von Insignien auf der Bitcoin Blockchain” erlauben. Hier könnten NFTs mit besonderen Transaktionen zusammenkommen und eine ganz eigene Art von Urheber-Beweis etablieren – eine ziemlich inspirierende Aussicht.
Faszinierender als diese Projekte sind aber andere, obwohl – oder gerade weil – sie sehr viel weniger innovativ sind. Die Ordinal Punks etwa kopieren die CryptoPunks, und die Bitcoin Rocks die Ether Rocks. Beides waren zwei der erfolgreichsten NFT-Sammlungen auf Ethereum, und was dort funktioniert hat, so der Gedanke, funktioniert umso besser auf Bitcoin. Tatsächlich erzielen beide auf je 100 Exemplare begrenzte Sammlungen hohe Preise. Der Floorpreis bei den Punks beträgt 5 Bitcoin, der bei den Bitcoin Rocks sogar 42,21 BTC.

Das Ordinal Deal Book zeigt für einige Bitcoin-NFT-Kollektionen auch den Floor-Price
Bitcoin hat zwar NFTs wie Ethereum, doch keine Smart Contracts, weshalb die Auktionen nicht onchain stattfinden, sondern privat. Daher ist nur ausschnittsweise bekannt, welche Inscriptions zu welchen Preisen verkauft wurden. So hat etwa ein Ordinal Punk für stolze 15,2 Bitcoin den Besitzer gewechselt – mehr als 300.000 Euro.
Wie kann das sein? Warum wird eine schnöde, unkreative Kopie von erfolgreichen NFTs so teuer verkauft? Die geistige Eigenleistung liegt mehr oder weniger bei Null. Als Antwort kann ich darauf nur zwei Spekulationen geben. Erstens lieben Bitcoiner Knappheit, und die bereits bekannten Projekte verankern die Knappheit in einem sinnhaften Kontext. Es geht nicht um Kreativität, sondern darum, ein knappes Gut (Bitcoins) durch ein zweites knappes Gut (Punks, Rocks) noch knapper zu machen. Zweitens sind Bitcoin NFTs ein Update zu Ethereum-NFTs und, rein technisch, zu recht mehr wert: Die Motive sind vollständig auf der Blockchain – was bei Ethereum in der Regel nicht so ist – und sie werden durch den Proof of Work des mit himmelweitem Abstand stärksten Computernetzwerk der Welt geschützt. Die NFTs sind mit der brutalen Gewalt großer Zahlen in die Blockchain eingraviert! Sie stecken da drin, um für immer da zu sein!
Nicht jeder teilt jedoch diese Begeisterung. Denn die Bitcoin-NFTs verbrauchen Platz auf der Blockchain, der eigentlich für monetäre Transaktionen bestimmt ist. Wie viel erkennt man schon, wenn man einen Chart mit der durchschnittlichen Blocksize öffnet. Diese bewegte sich die letzten drei Jahre stabil zwischen 0,8 und 1,5 Megabyte, und ist mit der Einführung von Ordinals explodiert. Heute sind Blöcke im Durchschnitt schon mehr als 2,5 Megabyte groß – sie haben sich verdoppelt!

Der Ordinals-Ausschlag ist deutlich zu sehen im Chart mit der durchschnittlichen Blockgröße von Blockchain.com
Rund 50 Prozent des Platzes sind, erklärt Bitcoin-Influencer Pierre Rochard, Ordinal Inscriptions. Bitcoin, das Netzwerk für P2P-Geld, bei dem die Entwickler sorgsam darauf achten, dass es möglichst stark auf seine Kernfunktionen reduziert bleibt, prozessiert mit der Hälfte seiner Kapazität Bilddateien. Das ist nicht ganz das, was geplant war.
BREAKING: ordinal inscriptions are consuming 50% of #bitcoin block space pic.twitter.com/8n7sXpLcNB
— Pierre Rochard (@BitcoinPierre) February 6, 2023
Wenn die Blöcke auf 4 Megabyte anschwellen, rechnet Rochard vor, werden sie 210 Gigabyte je Jahr verbrauchen. Full Nodes müssen etwa 10 Dollar im Jahr in Festplattenspeicher investieren und brauchen 30 Minuten länger, um die Blockchain zu synchronisieren. “Ich denke, es wird für uns in Ordnung sein”, meint er – und führt damit zwei Jahre der erbitterten Blocksize-Diskussionen ad absurdum. Hätte man nicht 2016 sagen können, dass das “in Ordnung sein” wird, ansatt die Szene darüber in einen Bürgerkrieg zu verwickeln?
Ohnehin hinkt die Vorstellung, die Inscriptions verdrängten finanzielle Transaktionen oder stünden mit ihnen in Konkurrenz. Um dies zu verstehen, muss man einige Details des SegWit-Upgrads von 2017 kennen. Einfach ausgedrückt reserviert dieses den Platz in der Blockchain nicht für alle Daten einer Transaktion gleich, weshalb es mit normalen Transaktionen unmöglich ist, Blöcke auf mehr als 1,5 Megabyte zu bringen. Nur sehr spezielle Multisig-Transaktionen mit vielen Teilnehmern können vier Megabyte große Blöcke füllen – oder eben, wie man jetzt weiß, Bilddateien. Die Inscriptions füllen quasi einen Platz, den normale Transaktionen gar nicht füllen können. Daher bleiben die Gebühren stabil.
Dennoch würden manche Entwickler dem Treiben gerne einen Riegel vorschieben. In der Bitcoin-Mailing-List fragt etwa Robert Dickinson, ob es “nicht besser wäre, eine Möglichkeit zu finden, Inscriptions ein ähnliches Limit aufzuerlegen wie OP_Return-Outputs.” Zwar stimmen manche der Entwickler seiner Abneigung gegen die NFTs bei, doch der breite Konsens scheint zu sein, dass ein Limit technisch nicht wirklich möglich ist; die Entscheidung darüber, welche Daten im Rahmen des geltenden Blocksize-Limits wertvoll und nicht wertvoll seien, sei eine Art Zensur und ein erster Schritt auf einem gefährlichen Weg.
Sinnvoller wirkt der Vorschlag eines Entwicklers, die “Witness-Data” – zu der auch die Inscriptions gehören — auf Option nicht herunterzuladen, wenn ein Block als valide gilt (assumed-valid). Ohne zu tief ins Detail zu gehen, versuche ich das zu übersetzen: Man kann einen Full Node im “pruned Mode” starten, was bedeutet, dass er Daten, die er nicht aktiv braucht – darunter die Witness-Daten – löscht. Da er sie aber benötigt, um die Blockchain zu verifizieren, während er sie synchronisiert, lädt er sie dennoch herunter. Darauf könne man bei Blöcken verzichten, an denen das “assumedvalid”-Tag klebt. Mit diesem zeichnen die Core-Entwickler mit jedem neuen Release einen Block aus, damit die Nodes die Blöcke vor ihm beim Download weniger streng verifizieren müssen.
Wenn man mit assumed-valid also schon ein gewisses Vertrauen darin setzt, dass die Blockchain bis zu einem bestimmten Punkt valide ist, könnte man doch auch auf den Download von Bilddateien verzichten, so die Intention. Die meisten Bitcoin-Entwickler finden die Idee gut, weil sie den Start eines neuen Full Nodes erheblich beschleunigen kann. Gerade weil manche sie nicht wollen, stoßen die Ordinals Inscriptions damit eine interessante Diskussion an. Sie könnten am Ende einen Full Node nicht schwerer, sondern sogar leichter machen.
Bingo! Das gefällt mir sehr gut und es kommt Leben in die verstaubte Bude! Vielleicht kommt Satoshi Nakamoto mit einer kleinen Erweiterung um die Ecke, die damals wohl etwas im Enthusiasmus der selbsternannten Experten-Szene untergegangen ist.
Kannst ´e behalten.
Onchain NFT’s gibt es auf BitcoinSV schon seit ca. zwei Jahren.
Egal ob man NFT’s gut oder schlecht findet, es zeigt meiner Meinung vor allem, dass ein Protokoll mit zunehmender Komplexität gleichzeitig auch “Fehleranfälliger” wird.
Nach SegWit, Lightning, Watchtowers, Taproot usw. scheinen da selbst die Hauptentwickler nicht mehr alle Folgen und Auswirkungen im Blick zu haben.
Halte ich für keine besonders Vertrauen erweckende Entwicklung.
Das originale Design war simpel und effizient und auch als Laie konnte man das ganz gut nachvollziehen, wenn man sich ein wenig damit beschäftigt hat.
Meinst du mit der Fehleranfälligkeit, dass die NFTs technisch nicht verhindert werden konnten?
Dann stellt sich aber die Frage, ob NTFs auch ohne die Entwicklungen möglich gewesen wären. Vielleicht sogar ohne SegWit – was, wenn man eine Möglichkeit gefunden hätte, die NFTs direkt in die Blöcke zu schreiben?
Ja, so in etwa meinte ich das.
Das “Grundmantra” von BTC ist, dass man mit Speicherplatz auf Layer1 so sparsam wie möglich umgehen sollte, damit möglichst viele Menschen einen Node auf Layer1 betreiben können.
Anstatt also das ursprüngliche simple Design beizubehalten, das relativ einfach zu verstehen war und einfach die Blocksize zu erhöhen, hat man die ursprünglich nur temporär gedachte Blocksize von 1MB beibehalten, dann Segwit implementiert, dann Lightning + Watchtower und zuletzt Taproot (inklusive einiger anderer Änderungen).
Und das hat jetzt ungewollte Auswirkungen.
Ich gehe davon aus, dass die Auswirkungen ungewollt sind, denn wenn man Jahrelang einen riesengroßen Aufriss wegen einer simplen Verdopplung (Erhöhung) der Blocksize macht und dann aber plötzlich Jpegs auf der Blockchain ermöglicht, was zu 4MB Blöcken (blockweight) führt, dann sind das zwei wiedersprüchliche Narrative. Also gehe ich von einem Versehen aus.
Das wiederum bedeutet, dass das Design mittlerweile so komplex geworden ist, dass die Entwickler selber keine Ahnung mehr haben, was ihre Änderungen für Folgen haben.
Das wiederum halte ich für bedenklich und nicht besonders Vertrauen erweckend.
Die NFT’s wären wie schon gesagt auch ohne die Entwicklungen möglich gewesen. Auf BitcoinSV, welches dem ursprünglichen Design am nächsten kommt ist das schon seit längerem möglich und zwar mit Dateien weit über 4MB.
Ob das ganze sinnvoll ist, wäre eine andere Frage die meiner Meinung nach nur der freie Markt/Wettbewerb langfristig entscheiden kann.
Ich halte es allerdings für ein Fass ohne Boden, wenn die Miner zusätzliche Daten speichern. Vor allem, wenn sie die Daten langfristig auf Nachfrage zur Verfügung stellen müssen.
So etwas kann man mit einer einmaligen Fee nicht wirklich einpreisen und würde entweder in einem Gebührenmarkt für das zur Verfügung stellen der Daten enden, in einem löschen/prunen der Daten, oder irgendjemand finanziert das auf irgendeine andere Art und Weise.
Das Hosting von Daten (zumindest aber einer bestimmten Größe) würde ich weiterhin den Profis überlassen.
Ich bin zwar kein Fan von Stillstand bei der Softwareentwicklung, denn der Fortschritt binnen 10+ Jahren ist immens, aber es gibt auch immer noch Menschen, die auf Windows 2000 schwören. Bei Bitcoin ist es ähnlich und alleine P2SH erreicht eine knapp 30% bessere Effizienz als alte Legacy Adressen, bei SegWit noch mehr (abgesehen vom durchaus streitbaren Discount beim Gewicht).
Lightning hat nichts mit dem Protokoll an sich zu tun, es ist eine App mit Bitcoin als Grundgerüst, die mehr oder weniger funktioniert (Ansichtssache), davon gibt es einige wie z.B. OpenTimestamps.
Allerdings sollte man konsequent auch alte Zöpfe abschneiden, statt alles in die Ewigkeit mitzuschleppen. UTXO dürfen natürlich nie verfallen, aber ist die Möglichkeit zum Senden an alte Adressen noch notwendig? Je mehr man mitschleppt, desto fehleranfälliger sind Implementierungen von Wallets bei Usern, Börsen und allen Marktteilnehmern. Hard Forks werden nur noch aus ideologischer Sicht vermieden, weil man sich während der Block Size Kriege in diese Ecke verrannt hat, dabei sind die Soft Forks eigentlich auch Hard Forks, weil eine alte Wallet z.B. mit SegWit nichts anfangen kann, obwohl sie die Transaktionen als valide sieht. Hier hätte man viel Effizienz gewinnen können, als über Umwege eine Soft Fork Möglichkeit reinzuhacken.
Absolut richtig, nur ist Bitcoin hier klar im Vorteil gegenüber BSV, denn die Blöcke können maximal 4MB groß sein und bei maximaler Auslastung also 4*144*365 => 210GB pro Jahr, während es bei BSV auch 210TB (ausgehend vom bisher größten Block mit 4GB und ganzen 10 BSV Gebühren) sein könnten. Ein dringend benötigter Gebührenmarkt (wegen der Halvings) ist gerade mit den Ordinals und der beschränkten Block Size das erste Mal in Aussicht, bei BSV sehe ich Unmengen von Daten praktisch für Lau und keine Aussicht, dass sie irgendwie sinnvoll bepreist werden, wenn die Block Größe ohnehin nicht limitiert ist. Falls sich die Ordinals auf Dauer durchsetzen sollten, wird das natürlich auch für “normale” Transaktionen Konsequenzen haben, indem sie deutlich teurer werden…
Naja, es gibt auch gute verteilte Protokolle, je nach Anwendung z.B. IPFS oder sogar Torrents.
Zum “Senden an alte Adressen”:
Angenommen jemand hat eine signierte und valide UTXO bei der “nLocktime” auf das Jahr 2030 eingestellt wurde. Er hat sie an sich selbst geschickt, damit er die Coins bis 2030 nicht anrühren kann, weil er sie unter keinen Umständen ausgeben möchte.
Die Schlüssel zur alten Wallet hat er zerstört und er hat nur die signierte UTXO, die noch nicht propagiert wurde und irgendwo sicher verwahrt ist.
Allerdings ist die Empfängeradresse natürlich eine “alte Adresse”. Im Jahr 2024 wird das “Senden an alte Adressen” abgeschafft. Ich bin mir nicht hunderpro sicher, aber ich denke das wäre ein Problem.
Wie du schon geschrieben hast: UTXO’s dürfen nie verfallen, das ist das wichtigste!
In dem oben genannten Fall würde diese UTXO allerdings verfallen (kann mich irren?)
So oder so: Änderungen am Fundament können unvorhersehbare und gravierende Auswirkungen auf das Gesamtkonstrukt haben.
Und die Auswirkungen merkt man meistens erst dann, wenn es zu spät ist.
Ansonsten habe ich zwar nichts gegen Verbesserung und Optimierung, aber man sollte es meiner Meinung nach auf ein Minimum beschränken und vor allem das Grunddesign möglichst unangetastet lassen. Man kann fast überall endlos optimieren, aber irgendwann sollte etwas “gut genug” sein.
War generell darauf bezogen, dass man das als Laie immer schwerer nachvollziehen kann und dass das Gesamtgebäude (BTC + Lightning) immer komplexer wird.
BTC kommt mir ein bisschen so vor wie unsere Politik. Die greifen in ein bestehendes Protokoll ein, dann gibts Probleme, dann werden zentralistisch geplante Lösungen per Gesetz erzwungen, welche nur noch mehr Probleme verursachen. So gehts dann immer weiter, bis irgendwann das ganze System so an die Wand gefahren wurde, dass mans in die Tonne treten kann.
Naja, zu viel Schrott kommt bei BSV jetzt auch nicht drauf, kostet ja schon noch was, wenn auch sehr wenig. Wobei mal irgendwas mit Hundebildern war, die for free hochgeladen wurden oder so.
Wäre ein Thema für sich, aber ich denke, dass das die Zeit und der Markt regeln wird, wenn man die beiden lässt. Gebührenmarkt für die Abfrage von Dateien wäre mit Mikrotransaktionen durchaus machbar. Auch bei BSV.
Ob das Hosting dann auf IPFS oder durch einen zentralen Anbieter erfolgt muss jeder selbst entscheiden. Wenn ich eine Datei für 10 Jahre online haben möchte, würde ich eher einen zentralen Abieter bevorzugen und den für den Upload und die Verfügbarkeit bezahlen.
Bin gespannt, wie sich das entwickelt.
Die Transaktion wäre wahrscheinlich ohnehin unbrauchbar, da sie die voraussehbaren Gebühren 2030 nicht erfüllen würde… Man könnte sie aber gegebenenfalls durch CPFP pushen, indem man eine Transaktion mit hohen Gebühren darauf aufbaut und Miner dazu animiert, sie trotzdem aufzunehmen. Allgemein halte ich die Vorsignierung auf einen weiten Zeitraum in der Zukunft für problematisch, das einzige, was tatsächlich beständig sein muss, sind die entsprechenden Schlüssel. Das Protokoll selbst sollte agil bleiben und ist die einzige Option, dass Bitcoin doch noch irgendwie skaliert, sei es durch effizientere Signaturen, sei es durch irgendeine Art von Batching etlicher Teilnehmer, bei dem die Einzeltransaktion kaum ins Gewicht fällt. Auch die Closing Transaktionen bei Lightning fallen darunter und werden bei kurzfristig stark steigenenden Gebühren zu einem echten Problem werden, wenn Channels einseitig geclosed werden und Miner über andere Kanäle dazu gebracht werden, diese in ihre Blöcke aufzunehmen. Wir hatten beim letzten Fee-Event bereits Zahlungsgateways um Transaktionen zu pushen über Kreditkarte bei großen Mining Pools und das kanns ja wohl nicht sein…
Problematisch ist hier tatsächlich, dass das Feature existiert und wahrscheinlich von ein paar Menschen genutzt wurde. Hierfür müsste man tatsächlich eine Ausnahme machen, die allerdings auch nach sich zieht, dass die alten Zöpfe alle mitgeschleppt werden müssen und Wallets klammheimlich die Möglichkeit bekommen, überhaupt nicht auf modernere Signaturen umzustellen, sondern einfach die Locktime auf den aktuellen Block setzen können. Locktime ist extrem fehleranfällig, eine Ziffer mehr ist schnell angehängt und bedeutet dann unter Umständen etliche zusätzliche Jahre blockierter Funds. Adressen haben eine Prüfsumme, die einen Vertipper meistens erkennt, entweder das eigene Wallet oder der Miner, der die Transaktion an eine nicht valide Adresse nicht in seinen Block aufnehmen kann.
Das droht bei Bitcoin eben durch Verkennen der offensichtlichen Probleme, denn ein ausreichender Gebührenmarkt, der die Block Rewards nach den nächsten 2-3 Halvings übernehmen würde, ist weder bei Bitcoin noch bei einem der Forks erkennbar. Die meisten Bitcoiner wollen jegliche Art der heiligen 21 Millionen-Kuh nicht schlachten, ohne die es imho auf Dauer nicht gehen wird. Es gab etliche Vorschläge dazu, entweder die frühen Patoshi Coins (die CSW für sich beansprucht) für eine langfristige Emittierung zu nutzen, oder die Halvings auszusetzen, falls die Hashrate/Difficulty sinkt, wird aber alles abgelehnt, obwohl das irgendwann jedem einleuchten müsste… Weder OnChain noch Lightning ist bei Gebühren um 100$ realistisch.
Wie gesagt, der Gebührenmarkt ist überlebenskritisch für Bitcoin aufgrund der Halvings. Ordinals werden von Maxis verpönt, obwohl gerade sie für ein besseres Verhältnis von Base Reward zu Gebühren geführt haben, denn kein rational denkender Akteur wird zig Dollar Gebühren für eine Transaktion bezahlen, aber die “Spinner”, die irgendwelche Bildchen auf der Blockchain speichern, durchaus. Ob das jetzt nachhaltig ist, kann man kaum abschätzen, aber es gibt keine mir bekannten sinnvollen Ideen, die Gebühren langfristig für die Sicherheit bezahlen zu lassen. Gerade bei Lightning hört die Akzeptanz bei wenigen Dollar fürs Onboarding auf und klar könnte man das effizienter machen, indem man sich Offchain verabredet und wie bei CoinJoins Batching etlicher User nutzt, aber das macht es nur noch komplizierter. Klar, Custodial löst das alles, verschiedene Wallet-Anbieter können das Settlement analog zu Banken alle paar Stunden machen… Nur dann kann man Bitcoin als gescheitertes Experiment abstempeln.
Die lautesten Schreihälse sind jedenfalls wieder sehr aktiv für eine Zensur, darunter gerade diejenigen, die bei der Blocksize “Debatte” behauptet haben, Bitcoin sei unveränderbar…
Darunter Luke DashJr, der früher Bibelverse in seinen Transaktionen verewigt hat und SatoshiDice “Spam” beim Gentoo Bitcoin Client unterbinden wollte.
https://twitter.com/janowitz/status/1625775156705492992
Bitcoin war noch nie fungibel, jeder Bitcoin und Sat hat seine eigene History, für jeden nachvollziehbar und dadurch bereits nicht beliebig auswechselbar wie Bargeld. Die Ordinals treiben diesen Zustand natürlich auf die Spitze, denn sie verewigen externe Daten auf der Blockchain, was für Node Betreiber problematisch werden kann. Ich habe schon sogenannte “Dickpics” gesehen, aber wie schon vor einigen Jahren auch hier geschrieben können diese Daten für Node Betreiber (vielleicht vor allem Miner) problematisch werden, wenn sie “illegale” Daten enthalten, sei es CP oder auch das Urheberrecht. Beim Broadcasten verbreitet man aktiv diese Daten und ich kenne keinen Bitcoin Node Client, der ermöglicht, einzelne Transaktionen nicht zu broadcasten, abgesehen vom Aufwand.
Übrigens: Auch Monero ist mit tx_extra potenziell betroffen (worauf ich auch schon öfter hingewiesen habe), aber man hat dank Bitcoin’s “Testnet” endlich erkannt, dass das zum Problem werden kann und eine Limitierung ist endlich auf dem Weg:
https://github.com/monero-project/monero/pull/8733
Obwohl das “schon” spätestens vor knapp 3 Jahren bereits ein Thema war, aber damals leider auch als wenig relevant klassifiziert wurde:
https://github.com/monero-project/monero/issues/6668
Die Diskussionen im Github sind übrigens auch sehr interessant, jeder ist eingeladen konstruktiv daran teilzunehmen, mache ich auch selbst sehr oft.
Hm, zitieren will gelernt sein. Ich meinte natürlich
Noch ein Versuch:
Der SegWit Datenbereich enthält lediglich die Inputscripts, mit denen Transaktionen verifiziert werden. Die muss man nicht ewig aufbewahren. Ein Bitcoin Knotenrechner kann sie problemlos nach einiger Zeit weglassen (so wie eine Bank eingereichte Schecks irgendwann vernichtet). Diese Pruning-Möglichkeit war übrigens 2017 eine der wichtigsten Beweggründe, SegWit einzuführen.
Ich sehe hier keine Gefahr, dass die Blockchain überlastet wird. Bitcoin wird nur noch attraktiver werden. Das einzige was mich etwas besorgt, ist, dass die Entwickler und Experten diese neue NFT-Variante bei der Taproot Einführung nicht erkannt oder vorausgesehen haben. Wer weiß, was für Überraschungen noch auf uns warten.
Pruning dieser Daten ist in der Tat kein Thema, dafür bräuchte es aber kein SegWit, ein Full Node kann jederzeit (fast) alles prunen, nachdem er es verifiziert hat und nur UTXO werden für den Betrieb benötigt, bei Monero sogar alle TXO, denn man kann nicht erkennen, welche unspent sind und ist eines der Haupt-Features aber könnte auch noch zum Problem werden. Pruning führt dann aber zwangsläufig zur philosophischen Frage, was ein Full Node eigentlich ist, noch stärker ausgeprägt bei Ethereum… Ich sehe hier nichtmal den Speicherplatz an sich sehr problematisch (man bekommt mittlerweile SSD für unter 50€ pro TB), eher die Bandbreite, die für den Sync notwendig ist und die ist selbst in Deutschland abseits von Rechenzentren und Ballungsgebieten (selbst da haperts) nicht flächendeckend verfügbar. Aber Bitcoins 4MB Blöcke sind auch da kein Problem, ich sehe eher Probleme ab mehreren Mbit/s, also mehr als tausendfach der derzeit minimal benötigten Bandbreite Bitcoins.
Ich sehe die Ordinals für eine spannende Entwicklung, Bitcoin war noch nie fungibel und daher nur konsequent, NFTs darauf abzubilden. Zudem könnten sie dazu beitragen, den Gebührenmarkt zu entwickeln, nur sollte man sich auch vor Augen halten, dass dann eben auch deutliche Gebührensteigerungen für alle Nutzer bringt, was jedem Bitcoiner eigentlich einleuchten müsste. Ich war ja immer schon für eine regelmäßige Block Size Vergrößerung zusammen mit jedem Halving, aber wollte ja keiner hören. Wir streamen heute Videos in 4k, was ca. 20GB pro Stunde an Bandbreite verursacht, aber ein paar MB Blöcke pro Stunde sollen zu viel sein? Wer nicht mit der Zeit geht, geht mit der Zeit und ich sehe keinerlei Szenario, warum Bitcoin in 10-20 Jahren noch relevant sein könnte, wenn es weiterhin jeglichen Fortschritt verblendet.
Bei Monero halte ich tx_extra für gefährlich, da es potenziell zur ungewollten Deanonymisierung führen könnte. Monero hat konsequent alles darauf gesetzt, Transaktionen immer weniger unterscheidbar zu machen, sei es durch eine feste Ring Größe mit aktuell 15 Decoys, davor 11, davor 4 und davor beliebig viele. Letzteres war deswegen ein Problem, weil jeder Wallet-Anbieter seine Ring Größe selbst definieren konnte und daher identifizierbar war. Auch lange Payment IDs hat man getilgt und erlaubt nur noch die verschlüsselten kurzen, obwohl auch diese nicht ganz unumstritten sind. Letzte Woche gab es ein Monero Research Lab Meeting zum Thema tx_extra und man ist sich generell einig, dass man etwas damit machen muss, wir haben aber noch keinen Konsens ob man ex komplett entfernt, nur stärker begrenzt oder sogar nur verschlüsselt zulässt und z.B. ASCII Zeichen per Protokoll verbietet. Ich tendiere zur verschlüsselten Version, begrenzt auf eine sinnvolle Anzahl von Zeichen. Warum? Bei Monero landen ja keine Adressen auf der Blockchain, aber gewisse Businessmodelle erfordern z.B. Refund-Adressen falls etwas nicht lieferbar ist oder ähnliches, eventuell sollte das Feld sogar verpflichtend werden wie bereits mindestens zwei Outputs bei Transaktionen, damit man sie möglichst ununterscheidbar macht. Kostet zwar alles Bandbreite und Speicherplatz, aber wie oben geschrieben, habe ich keinerlei Bedenken für eine Skalierung x100 von hier ohne jegliche weiteren Optimierungen, wahrscheinlich auch x1.000 und mit Seraphis und Jamtis stehen bereits zwei Optimierungen in den Startlöchern, die alles bisherige in den Schatten stellen… Will aber nicht zu viel ankündigen, um nicht dazustehen wie die IOTA Jungs, die seit 6 Jahren immer noch ankündigen, bloß nix liefern können 😛
Im großen und ganzen, weil man davon ausgehen kann, dass alles was bereits ausgegeben worden ist, zu dem Zeitpunkt des Ausgebens ausreichend von einer großen Anzahl an Full Nodes validiert worden ist, und nun auch ohne Signatur unveränderbar ist, weil genügend Blöcke oben drauf liegen.
Unspent Transactions kann man aber nicht einfach prunen, oder. Und somit muss man den Betrag einfach nur nicht ausgeben.um die Daten auf der Blockchain zu erhalten.
Ich gehe hier nicht davon aus, dass etwas nur von dritten Nodes geprüft wurde, sondern vom eigenen und fast alle Daten einer Transaktion sind danach unnötig (auch die Taproot Signatur, die die Oridinal Daten enthält), bis auf die UTXO, um neue Transaktionen selbst zu verifizieren.
Gerade bei Taproot ist eine Aufbauende Transaktion notwendig, um die Bedingung überhaupt zu veröffentlichen, hier also den Ordinal Code. Nachdem diese Transaktion verifiziert wurde, kann jede Node alles bis auf die UTXO prunen, denn die Bedingung für ihre Korrektheit wurde bereits erfüllt und jede darauf aufbauende Transaktion kann mittels UTXO, der genauso groß ist wie bei jeder anderen Transaktion, verifiziert werden.
Wenn es also dumm läuft und irgendwann keiner mehr eine Full Node betreibt (extremst unwahrscheinlich), wären die Ordinals weg, Bitcoin würde aber weiterhin normal funktionieren.
Dann ist ja alles, tutti. Wusste nicht dass Ordinals erst beim ersten Ausgeben (aka Aufbauende Transaktion) auf die Chain geschrieben werden. Danke für den Hinweis. Für einen kurzen Moment dachte ich schon …
Naja, vielleicht will ich manche der gespeicherten Bilder nicht nachträglich prunen sondern erst gar nicht runterladen.