Inscrições
Inscrições inscrevem conteúdo arbitrário em sats, criando artefatos digitais nativos de bitcoin, mais comumente conhecidos como NFTs. As inscrições não exigem uma sidechain ou token separado.
Esses sats inscritos podem então ser transferidos usando transações de bitcoin, enviados para endereços de bitcoin e mantidos em UTXOs de bitcoin. Essas transações, endereços e UTXOs são transações, endereços e UTXOS normais de bitcoin em todos os aspectos, com a exceção de que, para enviar sats individuais, as transações devem controlar tanto a ordem quanto o valor das entradas e das saídas de acordo com a teoria ordinal.
O modelo de conteúdo da inscrição é o da web. Uma inscrição consiste em um tipo de conteúdo, também conhecido como tipo MIME, e o próprio conteúdo, que é uma string de bytes. Isso permite que o conteúdo de inscrições seja retornado de um servidor web, e usado para criar inscrições HTML que usam e remixam o conteúdo de outras inscrições.
O conteúdo da inscrição é inteiramente on-chain, armazenado em scripts de gasto do caminho do script taproot. Os scripts taproot têm pouquíssimas restrições em seu conteúdo e adicionalmente recebem o desconto da Witness, fazendo com que o armazenamento do conteúdo da inscrição seja relativamente econômico.
Como os gastos com script taproot só podem ser feitos a partir de saídas taproot existentes, as inscrições são feitas usando um procedimento de confirmação/revelação de duas fases. Primeiro, na transação de confirmação, uma saída taproot confirmando um script contendo o conteúdo da inscrição é criado. Depois, na transação de revelação, a saída criada pela transação de confirmação é gasta, revelando o conteúdo da inscrição na rede.
O conteúdo da inscrição é serializado usando envios (pushes) de dados em condicionais não executados, chamadas "envelopes". Os envelopes consistem em um OP_FALSE OP_IF … OP_ENDIF envolvendo qualquer quantidade de envios de dados. Porque os envelopes são efetivamente autônomos, eles não alteram a semântica do script em que eles estão incluídos, e podem ser combinados com qualquer outro script de bloqueio.
Uma inscrição de texto contendo a string "Hello, world!" é serializada como 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
Primeiro, se faz um push da string ord, para desambiguar inscrições de outros usos de envelopes.
OP_PUSH 1 indica que o próximo push contém o tipo de conteúdo, e OP_PUSH 0indica que os pushes subsequentes contêm o próprio conteúdo. Múltiplos pushes de dados devem ser usados para inscrições grandes, porque uma das poucasrestrições do taproot é que os pushes de dados individuais não podem ser maioresque 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.
Conteúdo
O modelo de dados das inscrições é o de uma resposta HTTP, permitindo que os conteúdos de inscrições sejam servidos por um servidor web e visualizados em um navegador web.
Campos
As inscrições podem incluir campos antes de um corpo opcional. Cada campo consiste em dois envios de dados, uma tag e um valor.
Currently, there are six defined fields:
content_type, with a tag of1, whose value is the MIME type of the body.pointer, with a tag of2, see pointer docs.parent, with a tag of3, see provenance.metadata, with a tag of5, see metadata.metaprotocol, with a tag of7, whose value is the metaprotocol identifier.content_encoding, with a tag of9, whose value is the encoding of the body.delegate, with a tag of11, see delegate.
O início do corpo e o final dos campos são indicados com um push de dados vazio.
Tags não reconhecidas são interpretadas de maneira diferente dependendo se são pares ou ímpares, seguindo a regra "não há problema ser ímpar" usada pela Rede Lightning.
Etiquetas pares são usadas para campos que podem afetar a criação, atribuição inicial ou transferência de uma inscrição. Assim, inscrições com campos pares não reconhecidos devem ser exibidas como "não vinculadas", ou seja, sem localização.
Tags ímpares são usadas para campos que não afetam a criação, atribuição inicial ou transferência, como metadados adicionais, e, portanto, podem ser ignorados com segurança.
IDs das Inscrições
As inscrições estão contidas nas entradas de uma transação de revelação. Para identificá-las de forma única, elas recebem uma ID no formato:
521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0
A parte na frente do i é o ID da transação (txid) da transação de revelação. O número após o i define o índice (começando em 0) de novas inscrições sendo inscritas na transação de revelação.
As inscrições podem estar localizadas em entradas diferentes, dentro da mesma entrada, ou em uma combinação de ambas. Em qualquer caso, a ordem é clara, já que um analisador percorreria as entradas consecutivamente e procuraria por todos os envelopes de inscrição.
| Entrada | Contagem de inscrições | Índice |
|---|---|---|
| 0 | 2 | i0, il |
| 1 | 1 | i2 |
| 2 | 3 | i3. i4, i5 |
| 3 | 0 | |
| 4 | 1 | i6 |
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
As inscrições HTML e SVG são isoladas (sandboxed) para evitar referências a conteúdo fora da cadeia, mantendo assim as inscrições imutáveis e autocontidas.
Isso é feito carregando inscrições HTML e SVG dentro de iframes com o atributo sandbox, bem como servindo conteúdo de inscrição com cabeçalhos 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>