Bloqueo temporal relativo

BIP-68 dio un significado de consenso al campo del número de secuencia de cuatro bytes de cada entrada, pero solo en las transacciones que declaran la versión 2 o superior. La regla se incorporó a la red mediante un despliegue de bits de versión de BIP-9 en el bit 0; el despliegue se abrió el 1 de mayo de 2016 y llegó junto con BIP-112 y BIP-113. Si usted conserva monedas bloqueadas en un script de recuperación o de canal, la cuenta regresiva se reinicia cada vez que esas monedas se mueven.

Cómo funciona

Los bloqueos temporales relativos se codifican en el campo del número de secuencia, y el bit más alto decide si ocurre algo en absoluto.

Con el bit 31 activado, el campo no tiene ningún significado de consenso y la entrada puede incluirse en cualquier bloque. Con el bit 31 sin activar, los nodos aplican al campo la máscara 0x0000ffff y leen los 16 bits que quedan como un período de espera. El bit 22 elige la unidad. Si no está activado, el número cuenta bloques, y BIP-68 da un rango de 0 a 65.535 bloques, que describe como 1,25 años. Si está activado, el número cuenta períodos de 512 segundos, un rango que el BIP sitúa por debajo de 33.554.431 segundos, alrededor de 1,06 años. El peculiar 512 se eligió porque los bloques llegan aproximadamente cada 600 segundos, así que las dos unidades abarcan un intervalo parecido con los mismos 16 bits.

Una entrada que lleve un valor n basado en bloques puede incluirse n bloques después del bloque en el que se minó la salida que gasta, así que un valor de 1 se cumple ya en el bloque inmediatamente siguiente, y no en el de después. Los valores basados en tiempo nunca se comparan con un reloj. BIP-68 mide desde el tiempo pasado mediano del bloque anterior a aquel en el que se minó la salida hasta el tiempo pasado mediano del bloque anterior al que se está construyendo, y BIP-113 define esa cifra como la mediana de las marcas de tiempo de los últimos 11 bloques. Se usan medianas y no marcas de tiempo en bruto porque las reglas de consenso garantizan que la mediana avanza de forma monótona, lo que impide que un minero cobre comisiones adicionales mintiendo sobre la hora de un bloque.

Hay dos excepciones que importan. Las reglas nunca se aplican al campo del número de secuencia de la entrada de una transacción coinbase. Y seis posiciones, de la 16 a la 21, quedaron sin definir para que una bifurcación blanda (soft fork) posterior pueda aumentar la granularidad o el tope sin un campo nuevo.

Dónde aparece

BIP-112 explica un bloqueo temporal relativo con el ejemplo de un contrato de escrow (depósito en garantía) que expira 30 días después de su financiación.

Alice, Bob y un agente de escrow comparten un script 2 de 3. Dos cualesquiera pueden gastar en cualquier momento; pasado el retraso, Alice firma sola. El BIP es tajante sobre el desencadenante: el reloj no empieza a correr hasta que se confirma el pago a la dirección de escrow. Esa es toda la diferencia con una fecha límite de calendario, y es la razón por la que un mismo script sirve para cada nuevo escrow sin reescribirlo.

La regla también condiciona el comportamiento de las mempools. Bitcoin Core comprueba los bloqueos de secuencia con la altura del siguiente bloque, y no con la de la punta actual de la cadena, y trata una transacción padre sin confirmar como si fuera a confirmarse en ese bloque, así que un gasto cuya espera expira con el próximo bloque se retransmite un poco antes de ser gastable. Fuera de esa tolerancia no hay cola: un gasto inmaduro es inválido, no pendiente.

Bloqueo temporal relativo frente a OP_CHECKSEQUENCEVERIFY

Un bloqueo temporal relativo vive en la entrada de transacción, mientras que OP_CHECKSEQUENCEVERIFY vive en el script de la moneda y comprueba que la entrada que la gasta respete uno.

BIP-68 por sí solo no obliga a nadie. Quien construye el gasto elige el número de secuencia, así que un retraso escrito ahí es una preferencia, no una regla en la que una contraparte pueda confiar. BIP-112 cierra la brecha haciendo que el campo pueda leerse desde el script: el opcode (código de operación) falla si la versión de la transacción es inferior a 2, si el número de secuencia de la entrada tiene activado el indicador de desactivación, si los dos valores no coinciden en su unidad o si el número que hay en la pila supera el número de secuencia enmascarado. Si el propio valor de la pila lleva el indicador de desactivación, el opcode se comporta como una operación nula, un espacio que se dejó a propósito para una futura bifurcación blanda. Solo con esas comprobaciones en vigor la espera se convierte en algo con lo que puede contar un agente de escrow o un par Lightning.