El código de operación nSequence, es un sistema que permite bloqueos de tiempo en Bitcoin. Nos sirve para programar ciertas condiciones en las transacciones que deben cumplirse en primer lugar, para que esas transacciones se puedan aceptar en la red de forma definitiva. Una enorme potencia de programación que Bitcoin nos ofrece para gran cantidad de casos de usos.

Uno de los bloqueos de tiempo o TimeLock más particulares de Bitcoin es nSequence. Este es un bloqueo de tiempo relativo que opera a nivel de transacciones y que permite la utilización de los números de secuencia de entradas para programar un bloqueo de tiempo en las transacciones de Bitcoin.

Los nSequence permiten que una entrada pueda especificar cuál es el tiempo más temprano en el que se puede agregar un bloque. Es decir, eviten la confirmación de una transacción hasta que no transcurra una cierta edad en las salidas de la transacción. Esta edad se puede medir en bloques confirmados o en tiempo transcurrido.

Así mismo, los nSequence permiten la creación y programación de múltiples condiciones de tiempo sobre la misma transacción Bitcoin usando Bitcoin Script. Las cuales, a pesar de ser diferentes, se encontrarán relacionadas entre sí, por lo que deben cumplirse en su totalidad para que las transacciones puedan ser validadas e incluidas en un bloque de la cadena de bloques. En caso de que todas las condiciones establecidas no se cumplan, simplemente las transacciones no podrán ser validadas. Por lo tanto, esta transacción será rechazada por la red.

¿Cómo funcionan las nSequence?

Los nSequence utilizan sólo 18 bits de los 32 bits disponibles en el campo de secuencia de cada transacción. Con ello se mantienen los 14 bits restantes en reserva para implementaciones futuras. Por lo que los nSequence son unos de los bloqueos de tiempo o TimeLock más ligeros que existen en la red Bitcoin.

Así mismo, de los 18 bits que utilizan, 16 bits se usan para configurar los tiempos de bloqueo. Lo que hace que estos bloqueos de tiempo sean limitados a un total de 65.535 unidades de bloques disponibles. O a un tiempo de 18 horas, lo que equivale a 64.800 segundos.

Entonces, aunque en un principio los nSequence fueron implementados para permitir la modificación de las transacciones dentro del mempool de Bitcoin. Y permitirían el reemplazo de una transacción antes de que ésta fuera finalizada o confirmada. Es decir, en la actualidad se utiliza como un tiempo de bloqueo relativo. Esto impide que una transacción pueda ser extraída hasta que no se alcancen las condiciones establecidas. Dichas condiciones pueden ser un intervalo de tiempo definido o una altura de bloque. Esto aplica incñuso cuando sus firmas digitales sean completamente válidas.

En tal caso, si el valor de nSequence es mayor que 0xEFFFFFFF, no hay consenso sobre el número de secuencia, por lo que la transacción podrá ser incluida en cualquier bloque con todas las circunstancias posibles. Mientras que si el valor de nSequence es menor o igual que 0xEFFFFFFF, entonces significa que existe un tiempo de bloqueo. Donde el bit número 22 de la secuencia es quien determina si el bloqueo está basado en un intervalo de tiempo o en la altura de bloque.

Si este bit tiene el valor de “1”, entonces el tiempo de bloqueo está basado en un intervalo de tiempo; mientras que si su valor no está establecido se le considera como “0” y hace referencia a un número o altura de bloque.

Puesta en marcha de los nSequence: activación del BIP 68

El BIP 68 que lleva por nombre “Tiempo de bloqueo relativo utilizando números de secuencia impuestos por consenso”. Este le dio un nuevo concepto y definición a los números de secuencia para las transacciones de Bitcoin con una versión mayor o igual a “2”. Permitiendo que estos números de secuencia se puedan reutilizar para nuevos casos de uso. Asi como tambien para futuras implementaciones sin romper con su funcionalidad.

Así mismo, en el BIP 68 se define que el intervalo de tiempo se mide iniciando con la mediana del tiempo pasado (MTP) del bloque anterior a la salida y finaliza con la mediana del tiempo pasado (MTP) del bloque anterior. La mediana del tiempo pasado (MTP) se define en el BIP 113, que especifica la MTP como punto final para los cálculos del tiempo de bloqueo.

Interpretación de un nSequence

La interpretación del tiempo de bloqueo se realiza contando los bits a partir del bit número 16 en la secuencia nSequence.

Por otra parte, cuando el tiempo de bloqueo está basado en un intervalo de tiempo, entonces el bloqueo se desarrolla como una limitación mínima al tiempo del bloque sobre la antigüedad de la entrada. Mientras que si el tiempo de bloqueo está basado en bloques, éste se interpreta como una limitación mínima a la altura del bloque sobre la antigüedad de la entrada.

En el primer caso, un nSequence basado en un tiempo “n” puede ser incluido en cualquiera de los bloques que sean producidos 512*n segundos después de la fecha de extracción de la salida gastada o de la MTP del bloque anterior que lo extrajo. Para los bloqueos de tiempo basados ​​en tiempo, se escogió una escala de 512 segundos ya que los bloques de Bitcoin son producidos cada 10 minutos, lo que equivale a 600 segundos. Esto permite que se pueda codificar la misma cantidad de tiempo con el número de bits disponibles en ambos casos. Tanto cuando se utilicen bloqueos de tiempo basados ​​en bloques o cuando se utilicen bloqueos de tiempo basados ​​en intervalos de tiempo.

Para el segundo caso, donde el tiempo de bloqueo está basado en bloques, el nSequence indica una entrada que se puede incluir tras “n” cantidad de bloques después de la fecha de extracción de la salida gastada o de cualquier bloque posterior a éste.

Implementaciones de nSequence

Bloqueo de tiempo CHECKSEQUENCEVERIFY

El bloqueo de tiempo relativo a nSequence se puede implementar en el código OP_CHECKSEQUENCEVERIFY. Este código permite hacer un bloqueo del gasto sobre una salida en una transacción específica. Esto hasta tanto no se cumple ciertas condiciones. Como alcanzar ciertos bloques o un intervalo de tiempo definido desde la extraccion de las transacciones que contienen dicha salida.

En este caso, cuando un usuario utiliza y gasta las UTXO en una entrada de transacciones, se debe establecer que el valor de nSequence en esa entrada sea mayor o igual que el parámetro establecido en CHECKSEQUENCEVERIFY. Así como también el formato del valor de nSequence debe coincidir con el valor de CHECKSEQUENCEVERIFY. Es decir, si CHECKSEQUENCEVERIFY está especificado en términos de bloques, el valor de nSequence también debe estar basado en bloques.

monedas de colores

Las monedas de colores son un método de identificación que permite representar y reconocer ciertos activos del mundo real en la cadena de bloques de Bitcoin. Con la finalidad de evitar las manipulaciones y falsificaciones que estos activos pueden sufrir aprovechan las propiedades y características que ofrece la tecnología blockchain para su protección y resguardo.

Aunque actualmente ha perdido mucha popularidad con el nacimiento de Ethereum y los tokens ERC-20, este tipo de transacciones que se crea en la cadena de bloques de Bitcoin son marcadas de tal forma que se pueden distinguir entre el resto de transacciones que ocurren dentro de la cadena de bloques de Bitcoin. Para lo cual se utiliza un valor de etiqueta en el campo nSequence de la primera entrada de la transacción. Y aunque nSequence siempre está presente en las transacciones, en este caso no se utiliza como bloqueo sino como identificador, utilizando 6 de sus bits para formar y codificar el valor de etiqueta.

Canales de pago Decker-Wattenhofer

Los canales de pago dúplex se describen por primera vez en los documentos de Christian Decker y Roger Wattenhofer. Este tipo de canal de pago requiere el uso de nSequence. Como su nombre lo indica, un canal de pago dúplex se compone de dos canales de pago unidireccionales, uno en ambas direcciones.

Estos canales usan una estructura llamada “árbol de invalidación” de transacciones fuera de la cadena. Una propiedad entre la transacción de financiación y las transacciones de finalización del canal de pago. Las transacciones del árbol de invalidación también usan el tiempo de bloqueo relativo; la primera versión de las transacciones tiene un tiempo de bloqueo relativo grande. Y la siguiente versión de las transacciones (que invalida la primera) usa un tiempo de bloqueo relativo ligeramente menor, y así sucesivamente. También hay una transacción de “inicio” que inicia el tiempo de espera para el tiempo de bloqueo relativo.

La secuencia de transacciones es asi:

Financiación -> Inicio -> Árbol de invalidación -> Canal de pago.

Gracias a esto, es posible crear canales de pago seguros con un funcionamiento similar al ofrecido por Lightning Network, aunque técnicamente más complejos en su funcionamiento.