Inscriptions

Ang inscriptions ay sats na naglalaman ng arbitraryong content, na lumilikha ng bitcoin-native digital artifact, na mas karaniwang kilala bilang NFTs. Ang mga inskripsiyon ay hindi nangangailangan ng sidechain o hiwalay na token.

Ang mga naka-inscribe na sat na ito ay maaaring ilipat gamit ang mga transaksyon sa bitcoin, ipadala sa mga bitcoin address, at gamitin sa mga bitcoin UTXO. Ang mga transaksyon, address, at UTXO na ito ay normal na mga transaksyon sa bitcoin, address, at UTXOS sa lahat ng aspeto, maliban nalang para makapagpadala ng mga indibidwal na sats, dapat kontrolin ng transaksyon ang pagkakasunud-sunod at halaga ng mga input at output ayon sa ordinal theory.

Ang modelo ng inscription content ay sa web. Ang isang inskripsiyon ay binubuo ng isang uri ng nilalaman, na kilala rin bilang MIME type, at ang nilalaman mismo ay isang byte string. Ito ay nagbibigay-daan sa nilalaman ng inskripsiyon na maibalik mula sa isang web server, at para sa paglikha ng mga HTML inscriptions na gumagamit at nagbubuo ng nilalaman ng iba pang mga inskripsiyon.

Ang nilalaman ng inskripsiyon ay on-chain, na naka-imbak sa taproot script-path spend scripts. Ang mga script ng Taproot ay may limitasyon sa kanilang nilalaman, at bukod pa rito ay tumatanggap ng witness discount, na ginagawang matipid ang pag-iimbak ang nilalaman ng isang inskripsiyon.

Dahil ang spend ng taproot script ay maaari lamang gawin mula sa mga kasalukuyang taproot output, ang mga inskripsiyon ay ginawa gamit ang isang two-phase commit/reveal procedure. Una, sa commit transaction, isang taproot output na nag-committ sa isang script na naglalaman ng inskripsyon ay nabuo. Pangalawa, sa reveal ng transaksyon, ang output na nilikha ng commit na transaksyon ay ginamit sa pagbayad, na mag-rereveal ng inscription content sa on-chain.

Ang nilalaman ng inskripsiyon ay naka-serialize gamit ang data pushes sa loob ng mga hindi naisagawang kondisyon, na tinatawag na "envelopes". Ang envelopes ay binubuo ng isang OP_FALSE OP_IF ...OP_ENDIF na nag-wawrap sa kahit anong numero ng data pushes. Dahil ang envelopes ay epektibong no-ops, hindi nito binabago ang semantika ng script kung saan kasama ang mga ito, at maaaring isama sa anumang iba pang locking script.

Isang text inscription na naglalaman ng string na "Hello, world!" ay serialized tulad ng sumusunod:

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

Una ang string na ord ay pushed, upang i-dismbiguate ang mga inskripsiyon mula sa iba pang gamit ng envelopes.

Ang OP_PUSH 1 ay nagpapahiwatig na ang susunod na push ay naglalaman ng content type, at OP_PUSH 0 naman ay nagpapahiwatig na ang mga kasunod na data ay naglalaman ng content mismo. Dapat gumamit ng maraming push data para sa isang malalaking inskripsiyon, dahil ito sa limitasyon ng taproot, na kung saan hindi maaring lumagpas sa 520 bytes ang bawat isang data push.

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.

Content

Ang data model ng mga inskripsiyon ay isang HTTP response, na nagbibigay-daan sa nilalaman ng inskripsiyon na maipakita gamit ang web server at nang web browser.

Fields

Ang inskripsiyon ay maaring magkaroon ng fields bago ang optional body. Ang bawat field ay binubuo ng dalawang data pushes, isang tag at isang value.

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.

Ang simula ng body at dulo ng mga fields ay mayroong isang walang laman na data push.

Ang mga hindi unkown tag ay sinusuri depende sa kung even o odd ang mga ito, na sumusunod sa panuntunang "it's okay to be odd" na ginagamit ng Lightning Network.

Ang mga tag na ginagamit para sa fields ay maaaring makaapekto sa pag-create, paunang pagtatalaga, o paglipat ng isang inskripsiyon. Kaya, ang mga inskripsiyon na unknown at kahit na ang fields ay dapat na ipakita bilang "unbound", iyon ay, walang lokasyon.

Odd tags ay hindi nakakaapekto sa paggawa, paunang pagtatalaga, o paglilipat, gaya ng karagdagang metadata, at sa gayon ay ligtas na huwag pansinin.

Inscription IDs

Ang nilalaman ng inskripsyon ay nakapaloob sa input ng isang naka-reveal na transaksyon. Upang natatanging makilala ang mga ito, binibigyan sila ng ID, tulad ng:

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

Ang bahagi sa harap na i ay ang transaction ID (txid) ng reveal na transaksyon. Ang numero pagkatapos ng i ay tumutukoy sa index (nagsisimula sa 0) ng mga bagong inskripsiyon ng transaksyon.

Maaaring matatagpuan ang mga inskripsiyon sa iba't ibang input, sa loob ng parehong input o kumbinasyon ng pareho. Sa anumang kaso ang order ay madaling makita, dahil ang parser nage-scan sa mga input nang sunud-sunod at hahanapin ang lahat ng inskripsiyon na may envelopes.

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.

Sandboxing

Ang mga inskripsiyon na gaya ng HTML at SVG ay nasa-sandbox upang maiwasan ang ma-reference sa off-chain content, sa gayo'y pinapanatili ang mga inskripsiyon na hindi nababago at self-contained.

Nagagawa ito sa pamamagitan ng pag-load sa mga HTML at SVG na inskripsiyon sa loob iframes na may sandbox na katangian, pati na rin ang pag-serve ng nilalaman ng inskripsiyon na may Content-Security-Policy sa header.

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>