Iscrizioni

Le iscrizioni iscrivono i sats con contenuti arbitrari, creando artefatti digitali nativi di bitcoin, più comunemente noti come NFT. Le iscrizioni non richiedono una sidechain o un token separato.

Questi sat iscritti possono essere trasferiti con transazioni bitcoin, inviati a indirizzi bitcoin e conservati in UTXO di Bitcoin. Queste transazioni, indirizzi e UTXO sono normali transazioni, indirizzi e UTXO bitcoin a tutti gli effetti, con l'eccezione che per inviare i singoli sat, le transazioni devono controllare l'ordine e il valore degli input e degli output secondo la teoria ordinale.

Il modello di contenuto dell'iscrizione è quello del web. Un'iscrizione consiste in un tipo di contenuto, noto anche come tipo MIME, e nel contenuto stesso, che è una stringa di byte. Ciò consente di restituire il contenuto dell'iscrizione da un server web e di creare iscrizioni HTML che utilizzano e rimescolano il contenuto di altre iscrizioni.

Il contenuto dell'iscrizione è interamente on-chain,archiviato negli script di spesa del percorso dello script taproot. Gli script taproot hanno pochissime restrizioni sui loro contenuti e ricevono inoltre lo sconto testimone, rendendo relativamente economica la memorizzazione dei contenuti delle iscrizioni.

Poiché gli script taproot possono essere spesi solo a partire da output taproot esistenti, le iscrizioni vengono effettuate utilizzando una procedura di commit/reveal in due fasi. In primo luogo, nella transazione di commit, viene creata un'uscita taproot che esegue il commit di uno script contenente il contenuto dell'iscrizione. In secondo luogo, nella transazione reveal, l'output creato dalla transazione commit viene speso, rivelando il contenuto dell'iscrizione sulla catena.

Il contenuto dell'iscrizione viene serializzato utilizzando push di dati all'interno di condizioni non eseguite, chiamate "buste" (envelopes). Queste buste consistono in un OP_FALSE OP_IF … OP_ENDIF che avvolge un numero qualsiasi di push di dati. Poiché questi involucri sono effettivamente no-ops, non cambiano la semantica dello script in cui sono inclusi e possono essere combinati con qualsiasi altro script di chiusura.

Un'iscrizione di testo contenente la stringa "Hello, world!" viene serializzata come segue:

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

Per prima cosa viene inserita la stringa ord, per distinguere le iscrizioni da altri usi delle buste.

OP_PUSH 1 indica che il prossimo push contiene il tipo di contenuto, mentre OP_PUSH 0 indica che i successivi push di dati contengono il contenuto stesso. Per iscrizioni di grandi dimensioni è necessario utilizzare più push di dati, poiché una delle poche restrizioni di taproot è che i singoli push di dati non possono essere più grandi di 520 byte.

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.

Il Contenuto

Il modello di dati delle iscrizioni è quello di una risposta HTTP, che rende disponibile il contenuto dell'iscrizione da un server web e lo rende visualizzabile in un browser web.

I Campi

Le iscrizioni possono includere campi prima di un corpo opzionale. Ogni campo è composto da due dati, un tag e un valore.

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.

L'inizio del corpo e la fine dei campi sono indicati con un push di dati vuoto.

I tag non riconosciuti vengono interpretati in modo diverso a seconda che siano pari o dispari, seguendo la regola "va bene essere dispari" utilizzata dalla Lightning Network.

I tag pari sono utilizzati per i campi che possono influenzare la creazione, l'assegnazione iniziale o il trasferimento di un'iscrizione. Pertanto, le iscrizioni con campi pari non riconosciuti devono essere visualizzate come "non vincolate", cioè senza una posizione.

I tag dispari sono utilizzati per i campi che non influiscono sulla creazione, sull'assegnazione iniziale o sul trasferimento, come i metadati aggiuntivi, e quindi possono essere tranquillamente ignorati.

ID dell'iscrizione

Le iscrizioni sono contenute negli input di una transazione di rivelazione. Per identificarle in modo univoco, viene loro assegnato un ID del tipo:

521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0

La parte davanti alla i è l'ID della transazione (txid) della transazione rivelata. Il numero dopo la i definisce l'indice (a partire da 0) delle nuove iscrizioni che vengono inserite nella transazione di rivelazione.

Le iscrizioni possono trovarsi in ingressi diversi, all'interno dello stesso ingresso o in una combinazione di entrambi. In ogni caso, l'ordine è chiaro, poiché un parser dovrebbe passare in rassegna gli ingressi consecutivamente e cercare tutte le buste di iscrizioni.

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

Le iscrizioni HTML e SVG sono sottoposte a sandboxing per evitare riferimenti a contenuti esterni alla catena, mantenendo così le iscrizioni immutabili e autonome.

Ciò si ottiene caricando le iscrizioni HTML e SVG all'interno di iframes con l'attributo sandbox e servendo il contenuto dell'iscrizione con intestazioni Content-Security-Policy.

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>