Inscriptions

Inscriptions beschriften Sats mit beliebigen Inhalten und erzeugen Bitcoin-native digitale Artefakte, besser bekannt als NFTs. Für Inscriptions erfordern keine Sidechain oder separaten Token.

Diese eingeschriebenen Sats können dann mithilfe von Bitcoin-Transaktionen übertragen, an Bitcoin-Adressen gesendet und in Bitcoin-UTXOs gespeichert werden. Diese Transaktionen, Adressen und UTXOs sind in jeder Hinsicht normale Bitcoin-Transaktionen, Adressen und UTXOS, mit der Ausnahme, dass Transaktionen zum Senden einzelner Sats die Reihenfolge und den Wert der Ein- und Ausgänge gemäß der Ordinal theorie steuern müssen.

Das Inhaltsmodell der inscription ist das des Webs. Eine inscription besteht aus einem Inhaltstyp, auch MIME-Typ genannt, und dem Inhalt selbst, bei dem es sich um eine Bytefolge handelt. Dies ermöglicht die Rückgabe von inscriptions von einem Webserver und die Erstellung von HTML-inscriptions , die den Inhalt anderer inscription verwenden und neu mischen.

Der Inhalt der Inscription ist vollständig in der Kette und wird in Taproot-Skriptpfad-Ausgabeskripten gespeichert. Für Taproot-Skripte gelten nur sehr wenige Einschränkungen hinsichtlich ihres Inhalts und sie erhalten zusätzlich den Witness-Rabatt, was die Speicherung von Inscription-Inhalten relativ kostengünstig macht.

Da Ausgaben für Taproot-Skripts nur aus vorhandenen Taproot-Ausgaben getätigt werden können, werden inscriptions mithilfe eines zweiphasigen Commit/Reveal-Verfahrens vorgenommen. Zunächst wird in der Commit-Transaktion eine Taproot-Ausgabe erstellt, die ein Commit für ein Skript mit dem Inhalt der Inschrift durchführt. Zweitens wird bei der Offenlegungstransaktion die durch die Festschreibungstransaktion erzeugte Ausgabe ausgegeben, um den Inhalt der Inschrift in der chain preiszugeben.

Der Inhalt der Inscription wird mithilfe von Daten-Pushs innerhalb nicht ausgeführter Bedingungen, sogenannter „Umschläge“, serialisiert. Umschläge bestehen aus einem OP_FALSE OP_IF … OP_ENDIF , das eine beliebige Anzahl von Daten-Pushs umschließt. Da Umschläge praktisch No-Ops sind, ändern sie nicht die Semantik des Skripts, in dem sie enthalten sind, und können mit jedem anderen Sperrskript kombiniert werden.

Eine inscription mit der Zeichenfolge "Hello, world!" wird wie folgt serialisiert:

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "text/plain;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "Hello, world!"
OP_ENDIF

Zuerst wird die Zeichenfolge ord gedrückt, um inscriptions von anderen Verwendungszwecken von Umschlägen zu unterscheiden.

OP_PUSH 1 indicates that the next push contains the content type, and OP_PUSH 0indicates that subsequent data pushes contain the content itself. Multiple data pushes must be used for large inscriptions, as one of taproot's few restrictions is that individual data pushes may not be larger than 520 bytes.

The inscription content is contained within the input of a reveal transaction, and the inscription is made on the first sat of its input if it has no pointer field. This sat can then be tracked using the familiar rules of ordinal theory, allowing it to be transferred, bought, sold, lost to fees, and recovered.

Inhalt

Das Datenmodell von inscriptions ist das einer HTTP-Antwort, sodass inscription inhalte von einem Webserver bereitgestellt und in einem Webbrowser angezeigt werden können.

Felder

Inscriptions können Felder vor einem optionalen Text enthalten. Jedes Feld besteht aus zwei Daten-Pushs, einem Tag und einem Wert.

Currently, there are six defined fields:

• content_type, with a tag of 1, whose value is the MIME type of the body.
• pointer, with a tag of 2, see pointer docs.
• parent, with a tag of 3, see provenance.
• metadata, with a tag of 5, see metadata.
• metaprotocol, with a tag of 7, whose value is the metaprotocol identifier.
• content_encoding, with a tag of 9, whose value is the encoding of the body.
• delegate, with a tag of 11, see delegate.

Der Anfang des Hauptteils und das Ende der Felder werden durch einen leeren Daten-Push angezeigt.

Nicht erkannte Tags werden unterschiedlich interpretiert, je nachdem, ob sie gerade oder ungerade sind. Dabei gilt die vom Lightning Network verwendete Regel "Es ist in Ordnung, ungerade zu sein".

Sogar Tags werden für Felder verwendet, die sich auf die Erstellung, Erstzuweisung oder Übertragung einer inscription auswirken können. So müssen inscription mit nicht erkannten geraden Feldern als "ungebunden“, also ohne Ortsangabe, angezeigt werden.

Ungerade Tags werden für Felder verwendet, die sich nicht auf die Erstellung, anfängliche Zuweisung oder Übertragung auswirken, wie z. B. zusätzliche Metadaten, und daher sicher ignoriert werden können.

Inscription IDs

Die inscriptions sind in den Eingaben einer Enthüllungstransaktion enthalten. Um sie eindeutig zu identifizieren, wird ihnen eine ID der Form zugewiesen:

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

Der Teil vor dem „i“ ist die Transaktions-ID (txid) der Offenlegungstransaktion. Die Zahl nach dem i definiert den Index (beginnend bei 0) der neuen inscriptions, die in die Offenlegungstransaktion eingeschrieben werden.

Inscriptions können sich entweder in verschiedenen Eingaben (inputs), innerhalb derselben Eingabe oder in einer Kombination aus beiden befinden. In jedem Fall ist die Reihenfolge klar, da ein Parser die Eingaben nacheinander durchgehen und nach allen inscription envelopes suchen würde.

Inscription Numbers

Inscriptions are assigned inscription numbers starting at zero, first by the order reveal transactions appear in blocks, and the order that reveal envelopes appear in those transactions.

Due to a historical bug in ord which cannot be fixed without changing a great many inscription numbers, inscriptions which are revealed and then immediately spent to fees are numbered as if they appear last in the block in which they are revealed.

Inscriptions which are cursed are numbered starting at negative one, counting down. Cursed inscriptions on and after the jubilee at block 824544 are vindicated, and are assigned positive inscription numbers.

Sandboxen

HTML- und SVG-inscriptions werden in einer Sandbox gespeichert, um Verweise auf Inhalte außerhalb der chain zu verhindern, sodass die inscriptions unveränderlich und in sich geschlossen bleiben.

Dies wird erreicht, indem HTML und SVG-Inschriften in iframes mit dem Sandbox Attribut geladen werden und inscriptions inhalte mit Content-Security-Policy Headern bereitgestellt werden.

Self-Reference

The content of the inscription with ID INSCRIPTION_ID must served from the URL path /content/<INSCRIPTION_ID>.

This allows inscriptions to retrieve their own inscription ID with:

let inscription_id = window.location.pathname.split("/").pop();

If an inscription with ID X delegates to an inscription with ID Y, that is to say, if inscription X contains a delegate field with value Y, the content of inscription X must be served from the URL path /content/X, not /content/Y.

This allows delegating inscriptions to use their own inscription ID as a seed for generative delegate content.

Reinscriptions

Previously inscribed sats can be reinscribed with the --reinscribe command if the inscription is present in the wallet. This will only append an inscription to a sat, not change the initial inscription.

Reinscribe with satpoint: ord wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --satpoint <SATPOINT>

Reinscribe on a sat (requires sat index): ord --index-sats wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --sat <SAT>