Inscripciones
En una inscripción inscribimos contenido arbitrario en un sat, con este proceso creamos artefactos digitales nativos de Bitcoin, comúnmente conocidos como NFTs. Las inscripciones no requieren una cadena lateral ni un token aparte.
Los sats que se han inscrito pueden ser transferidos en una transacción de bitcoin, ser enviados a direcciones Bitcoin y ser contenidos en UTXOs (transacción de salida no gastada) de Bitcoin. Todos estos procesos se llevan a cabo como se han hecho normalmente en Bitcoin, con la excepción de que, para enviar cada sat, las transacciones deben controlar el orden y el valor de las entradas y salidas según la teoría Ordinal.
El modelo de contenido de las inscripciones funciona similar al de la web.Una inscripción está conformada por el tipo de contenido, conocido como el tipo MIME, y el contenido que es una cadena de bytes. Esto permite que el contenido de la inscripción se pueda obtener de un servidor web y tener la posibilidad de crear inscripciones HTML que usen el contenido de otras inscripciones.
El contenido de la inscripción está completamente en la cadena de bloques o blockchain, almacenado en scripts de taproot. Los scripts de taproot tienen muy pocas restricciones en cuanto a lo que pueden contener, y además reciben el descuento de testigo, lo que hace que el almacenamiento de contenido de las inscripciones sea relativamente económico.
Dado que los gastos de script de taproot (taproot script spends) sólo pueden hacerse desde salidas de taproot existentes, las inscripciones se hacen en dos fases de compromiso/revelación. Primero, en la transacción de compromiso, se crea una salida de taproot que se compromete a un script que contiene el contenido de inscripción. Segundo, en la transacción de revelación, la salida creada por la transacción de compromiso se gasta, revelando el contenido de la inscripción en la cadena.
El contenido de la inscripción se serializa utilizando push de datos dentro de condicionales que no han sido ejecutados, a estos se les llama "sobres". Los sobres consisten en un OP_FALSE OP_IF ... OP_ENDIF envolviendo los push de datos. Dado que los sobres son operaciones nulas, no cambian la semántica del script en el que están incluidos y pueden combinarse con cualquier otro script de bloqueo.
Una inscripción de texto que contiene la cadena "¡Hola, Mundo!" se serializa de la siguiente manera:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 0
OP_PUSH "¡Hola, Mundo!"
OP_ENDIF
Primero, se hace un push con el string ord para diferenciar que sobre va a utilizar la inscripción.
OP_PUSH 1 indica que el próximo push es el tipo de contenido y OP_PUSH 0 indica que los siguientes datos en el push contienen el contenido que se va a anexar. Múltiples push de datos deben ser utilizados para inscripciones de gran tamaño ya que una de las pocas restricciones de Taproot es que un push de datos no puede ser mayor a 520 bytes.
El contenido de la inscripción se encuentra dentro de la entrada de una transacción de revelación, y la inscripción se crea en el primer satoshi de su entrada si este no tiene un campo de puntero. Este satoshi puede ser rastreado utilizando las reglas de la teoría ordinal, lo que permite que sea transferido, comprado, vendido, perdido en las tarifas y recuperado.
Contenido
El modelo de datos de las inscripciones es el de una respuesta HTTP, permitiendo que el contenido de la inscripción sea obtenido a través de un servidor web y visualizado en un navegador web.
Campos
Las inscripciones pueden incluir campos antes de un cuerpo opcional. Cada campo consta de dos push de datos, una etiqueta y un valor.
Actualmente, hay seis campos definidos:
content_type, con una etiqueta de1, cuyo valor es el tipo MIME del cuerpo.pointer, con una etiqueta de2, ver documentación de punteros.parent, con una etiqueta de 3, ver proveniencia.metadata, con una etiqueta de5, ver metadatos.metaprotocol, con una etiqueta de7, cuyo valor es el identificador del metaprotocolo.content_encoding, con una etiqueta de9, cuyo valor es la codificación del cuerpo.delegate, con una etiqueta de 11, ver delegado.
Para indicar el principio del cuerpo y el final de los campos se hace un push de datos vacío.
Las etiquetas no reconocidas se interpretan de forma diferente según sean pares o impares, siguiendo la regla "está bien que sean impares" utilizada por la Lightning Network.
Las etiquetas pares se utilizan para campos que pueden afectar a la creación, asignación inicial o transferencia de una inscripción. Por esto, las inscripciones con campos pares no reconocidos deben mostrarse como "no vinculadas", es decir, sin ubicación.
Las etiquetas impares se utilizan para campos que no afectan a la creación,asignación inicial o transferencia, tales como los metadatos adicionales, y por lo tanto se pueden ignorar.
ID de las Inscripciones
Las inscripciones están alojadas en las entradas de una transacción de revelación. Para identificarlas se les asigna un ID como este:
521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0
La parte delante de la i es el ID de transacción (txid) de la transacción de revelación. El número después la i es el índice (comenzando por 0) de las nuevas inscripciones que se están inscribiendo en la transacción de revelación.
Las inscripciones pueden estar en diferentes entradas, dentro de la misma entrada o en una combinación de ambas. En ambos de estos casos, el orden es claro, ya que un analizador sintáctico (parser) recorrería las entradas consecutivamente buscando los sobres de las inscripciones.
| Entrada | Conteo de Inscripciones | Índice |
|---|---|---|
| 0 | 2 | i0, il |
| 1 | 1 | i2 |
| 2 | 3 | i3, i4, i5 |
| 3 | 0 | |
| 4 | 1 | i6 |
Números de Inscripción
Las inscripciones se les asignan números de inscripción comenzando desde cero, basados en el orden en que aparecen las transacciones de revelación dentro de los bloques y el orden de los sobres de revelación dentro de esas transacciones.
Debido a un error histórico en ord que no se puede corregir sin cambiar una gran cantidad de números de inscripción, las inscripciones que se revelan y luego se gastan inmediatamente en tarifas se numeran como si aparecieran al final en el bloque en el que se revelan.
Las inscripciones que están marcadas como embrujdas reciben números de inscripción comenzando desde menos uno y contando hacia abajo. Aquellas inscripciones marcadas como embrujadas desde el jubileo en el bloque 824544 son redimidas y se les asignan números de inscripción positivos.
Sandboxing o Aislamiento
Las inscripciones en HTML y SVG están restringidas en un entorno aislado llamado sandboxing para evitar referencias a contenido fuera de la cadena, manteniendo así las inscripciones inmutables y contenidas dentro del entorno.
Esto se logra cargando las inscripciones en HTML y SVG dentro de iframes con el atributo sandbox y agregando Content-Security-Policy a los encabezados.
Autorreferencia
El contenido asociado a la inscripción identificada por el ID INSCRIPTION_ID debe estar disponible desde la ruta URL /content/<ID_DE_INSCRIPCIÓN>.
Esto permite que las inscripciones obtengan su propio ID de inscripción usando:
let inscription_id = window.location.pathname.split("/").pop();
Si una inscripción con ID X delega a una inscripción con ID Y, es decir, si la inscripción X contiene un campo de delegado con el valor Y, entonces el contenido de la inscripción X debe estar disponible desde la ruta URL /content/X, no desde /content/Y.
Esto permite que las inscripciones delegadas utilicen su propio ID de inscripción como semilla para generar contenido delegado.
Reinscripciones
Los satoshis previamente inscritos pueden reinscribirse con el comando --reinscribe si la inscripción está presente en el monedero. Esto solo añadirá una inscripción adicional a un satoshi, sin modificar la inscripción inicial.
Reinscribe con el satpoint: `ord wallet inscribe --fee-rate <TASA_DE_TARIFA> --reinscribe --file
Reinscribir en un sat (requiere el índice de sats): ord --index-sats wallet inscribe --fee-rate <TASA_DE_TARIFA> --reinscribe --file <ARCHIVO> --sat <SAT>