Inscripties

Inscripties inscriberen sats met willekeurige inhoud, waardoor bitcoin-native digitale artefacten worden gecreëerd, die beter bekend staan als NFT's. Inscripties vereisen geen sidechain of apart token.

Deze geïnscribeerde sats kunnen vervolgens worden overgedragen via bitcoin-transacties, verzonden naar bitcoin-adressen en vastgehouden in bitcoin-UTXO's. Deze transacties, adressen en UTXO's zijn in alle opzichten normale bitcoin-transacties, adressen en UTXO's, met als uitzondering dat om individuele sats te verzenden, transacties de volgorde en waarde van inputs en outputs moeten beheren volgens de ordinale theorie.

Het inscriptie-inhoudsmodel is dat van het web. Een inscriptie bestaat uit een inhoudstype, ook wel bekend als een MIME-type, en de inhoud zelf, wat een bytestring is. Dit maakt het mogelijk om inscriptie-inhoud van een webserver op te halen en HTML-inscripties te maken die de inhoud van andere inscripties gebruiken en remixen.

Inscriptie-inhoud bevindt zich volledig on-chain, opgeslagen in taproot script-path spendscripts. Taproot-scripts hebben zeer weinig beperkingen op hun inhoud en krijgen bovendien de getuigenkorting, waardoor het opslaan van inscriptie-inhoud relatief voordelig is.

Aangezien taproot-scriptspends alleen kunnen worden gedaan vanuit bestaande taproot-uitgangen, worden inscripties gemaakt met behulp van een twee-fasen commit/reveal-procedure. Eerst wordt in de commit-transactie een taproot-uitgang gecreëerd die zich verbindt aan een script dat de inscriptie-inhoud bevat. Ten tweede wordt in de reveal-transactie de output die door de commit-transactie is gecreëerd, besteed, waardoor de inscriptie-inhoud on-chain wordt onthuld.

Inscriptie-inhoud wordt geserialiseerd met behulp van datapushes binnen niet-uitgevoerde conditionals, zogenaamde "enveloppen". Enveloppen bestaan uit een OP_FALSE OP_IF … OP_ENDIF die een willekeurig aantal datapushes omhult. Omdat enveloppen in feite no-ops zijn, veranderen ze de semantiek van het script waarin ze zijn opgenomen niet, en kunnen ze worden gecombineerd met elk ander vergrendelingsscript.

Een tekstinscriptie met de string "Hello, world!" wordt als volgt geserialiseerd:

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

Eerst wordt een push uitgevoerd met de string ord om aan te geven dat de inscriptie zal worden gebruikt.

OP_PUSH 1 Geeft aan dat de volgende push het type inhoud is, en OP_PUSH 0 geeft aan dat de volgende gegevens in de push de inhoud bevatten die wordt toegevoegd. Voor grote inscripties moeten meerdere gegevenspushes worden gebruikt, aangezien een van de weinige beperkingen van Taproot is dat een gegevenspush niet groter mag zijn dan 520 bytes.

De inhoud van de inscriptie bevindt zich binnen de invoer van een onthullingstransactie, en de inscriptie wordt gecreëerd in de eerste satoshi van zijn invoer, indien deze geen pointer-veld heeft. Deze satoshi kan worden gevolgd volgens de regels van de ordinale theorie, waardoor hij kan worden overgedragen, gekocht, verkocht, verloren in kosten en hersteld.

Content

Het gegevensmodel van de inscripties is dat van een HTTP-respons, waardoor de inhoud van de inscriptie kan worden verkregen via een webserver en bekeken kan worden in een webbrowser.

Velden

Inscripties kunnen velden bevatten vóór een optionele body. Elk veld bestaat uit twee gegevenspushes: een label en een waarde.

Momenteel zijn er zes gedefinieerde velden:

• content_type, met een label van 1, waarvan de waarde het MIME-type van de body is.
• pointer, met een label van 2, zie documentatie van pointers.
• parent, met een label van 3, zie herkomst.
• metadata, met een label van 5, zie metadata.
• metaprotocol, met een label van 7, waarvan de waarde de identificator van het metaprotocol is.
• content_encoding, met een label van 9, waarvan de waarde de codering van de body is.
• delegate, met een label van 11, zie gedelegeerde.

Om het begin van de body en het einde van de velden aan te geven, wordt een lege gegevenspush uitgevoerd.

Niet-herkende labels worden op verschillende manieren geïnterpreteerd, afhankelijk van of ze even of oneven zijn, volgens de regel "oneven is toegestaan" die wordt gebruikt door het Lightning Network.

Even labels worden gebruikt voor velden die de creatie, initiële toewijzing of overdracht van een inscriptie kunnen beïnvloeden. Daarom moeten inscripties met niet-herkende even labels worden weergegeven als "niet-gelinkt", dat wil zeggen zonder locatie.

Oneven labels worden gebruikt voor velden die geen invloed hebben op de creatie, initiële toewijzing of overdracht, zoals extra metadata, en kunnen daarom worden genegeerd.

IDs van inscripties

Inscripties worden opgeslagen in de invoeren van een onthullingstransactie. Ze krijgen een ID toegewezen zoals dit:

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

Het deel vóór de i is de transacte-ID (txid) van de onthullingstransactie. Het nummer na de i is de index (beginnend bij 0) van de nieuwe inscripties die in de onthullingstransactie worden ingeschreven.

Inscripties kunnen zich in verschillende invoeren bevinden, binnen dezelfde invoer of in een combinatie van beide. In beide gevallen is de volgorde duidelijk, aangezien een parser de invoeren achtereenvolgens zou doorlopen op zoek naar de omslagen van de inscripties.

Inscriptie-nummers

Inscripties krijgen inscriptienummers, beginnend bij nul, op basis van de volgorde waarin ze in de transacties verschijnen.

Vanwege een historische fout in ord die niet kan worden gecorrigeerd zonder een groot aantal inscriptienummers te veranderen, worden inscripties die worden onthuld en vervolgens onmiddellijk worden besteed aan kosten, genummerd alsof ze aan het einde van het blok verschijnen waarin ze worden onthuld.

Inscripties die als cursed zijn gemarkeerd, ontvangen inscriptienummers beginnend vanaf min één en dalend. Die inscripties die sinds het jubileum in blok 824544 als cursed zijn gemarkeerd, worden geredempt en krijgen positieve inscriptienummers toegewezen.

Sandboxing

Inscripties in HTML en SVG zijn beperkt tot een geïsoleerde omgeving die sandboxing wordt genoemd om verwijzingen naar inhoud buiten de keten te voorkomen, waardoor de inscripties onveranderlijk en ingesloten blijven binnen de omgeving.

Dit wordt bereikt door de inscripties in HTML en SVG te laden binnen iframes met het sandbox-attribuut en door Content-Security-Policy aan de headers toe te voegen.

Autorreferentie

De inhoud die hoort bij de inscriptie geïdentificeerd door het ID INSCRIPTION_ID moet beschikbaar zijn via de URL-route /content/<INSCRIPTION_ID>.

Dit maakt het mogelijk dat de inscripties hun eigen inscriptienummer verkrijgen met behulp van:

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

Als een inscriptie met ID X delegeert aan een inscriptie met ID Y, dat wil zeggen, als inscriptie X een delegate-veld bevat met waarde Y, moet de inhoud van inscriptie X worden weergegeven via de URL-pad /content/X, niet /content/Y.

Dit maakt het mogelijk voor delegeerende inscripties om hun eigen inscriptienummer te gebruiken als basis voor generatieve delegate-inhoud.

Reinscriptions

Satoshis die eerder zijn geïnscribeerd kunnen worden gereinscribed met het commando --reinscribe als de inscriptie aanwezig is in de portemonnee. Dit voegt alleen een extra inscriptie toe aan een satoshi, zonder de oorspronkelijke inscriptie te wijzigen.

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

Reinscribe op een sat (vereist sat-index): ord --index-sats wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --sat <SAT>