CSV

Anna y Pedro pueden gastar de común acuerdo las monedas que custodian juntos. También quieren una vía de recuperación que Anna pueda usar sola, pero solo tras un plazo contado desde la confirmación de la salida correspondiente. CSV ayuda a imponerlo. A diferencia de CLTV, que apunta a una altura o un momento fijo, su límite no es un punto predeterminado de toda la historia. Depende de unas monedas concretas. Crear una cartera, preparar una firma o dejar esperando una transacción sin confirmar no sustituye ese inicio. Una cartera es una aplicación o un dispositivo para recibir y enviar bitcoin. [1] [2] [8]

Un bloque agrupa transacciones en un lote que se añade al historial compartido. La altura de bloque es su posición en la cadena. Imagina una salida confirmada a la altura 900000 y un plazo obligatorio de 10 bloques. Para este bloqueo, el primer bloque donde puede gastarse es 900010. Un intervalo de solo 9 bloques resulta insuficiente. Esto no promete un número exacto de minutos: los bloques no llegan a intervalos regulares. Tampoco la antigüedad suficiente equivale a un pago confirmado. La transacción debe ser válida en todo lo demás y un minero debe incluirla realmente en un bloque. [2] [4] [9]

El plazo también puede codificarse en pasos de 512 segundos. El código 2 representa entonces 1024 segundos. Pero no se comparan dos relojes de ordenador. El inicio es el Median Time Past del bloque anterior al que confirmó la salida; el otro extremo es el Median Time Past del bloque anterior al candidato. Es la marca de tiempo central de los últimos hasta 11 bloques, tras ordenarlas. La diferencia entre ambas medianas debe alcanzar el plazo exigido. No es una alarma exacta según la hora local. [2] [4] [7]

Para pagar, una cartera puede combinar varias cantidades recibidas antes. Cada entrada de transacción hace referencia a una salida recibida anteriormente, cuya antigüedad se mide desde su confirmación en la cadena. El campo nSequence pertenece a la entrada. Este campo contiene la información usada para la espera relativa. No basta con que solo una parte del dinero tenga suficiente antigüedad: deben cumplirse todos los bloqueos aplicables a la transacción. Además, una reorganización puede cambiar dónde se produjo la confirmación. Por eso, haber podido gastar antes no es una propiedad irreversible de la moneda. En una reorganización, la red adopta otra rama válida de la cadena y sustituye parte del historial de bloques anterior. [2] [4] [9]

Un Full Node verifica las reglas por sí mismo mediante comprobaciones relacionadas. CSV, según BIP 112, compara el argumento del script con nSequence de la entrada que gasta la salida. No calcula por sí mismo la antigüedad; BIP 68 lo hace al validar la transacción. Para un argumento normal sin la bandera de desactivación, la versión de la transacción debe ser al menos 2 y el bit 31 de nSequence debe estar desactivado. Un bit es un pequeño interruptor dentro de un campo numérico. Un argumento negativo, una versión anterior o un nSequence incompatible hacen fallar la comprobación. [1] [2] [3]

El bit 22 determina cómo interpretar el plazo. Si está desactivado, la unidad son bloques; si está activado, se usan pasos de 512 segundos. El argumento del script y nSequence deben usar el mismo tipo. Piensa en comparar medidas: un número mayor no basta si un lado cuenta kilómetros y el otro horas. Aquí la incompatibilidad sería entre una cantidad de bloques y un intervalo temporal. [1] [2] [3]

Los 16 bits inferiores contienen la duración. La máscara 0x0000ffff selecciona esa parte del campo numérico. CSV compara esa parte junto con el tipo de plazo; no interpreta cualquier nSequence grande como una espera más larga. Tras seleccionar los bits pertinentes, la exigencia del script no puede superar el valor de la entrada. Es un límite técnico importante para quien diseña carteras, pero el usuario no debería configurarlo a mano sin entender el procedimiento completo. [1] [2] [3]

Un plazo cero no añade espera, pero las demás comprobaciones del CSV normal siguen vigentes. Distinto es que el propio argumento no negativo del script tenga activado el bit 31. En ese caso CSV actúa como NOP, una instrucción sin efecto sobre el bloqueo relativo. Ese argumento no impone espera. Hay que distinguirlo de la misma bandera en nSequence de la entrada: con un argumento normal, esa bandera debe estar desactivada. [1] [3]

Si la vía de recuperación de Anna necesita su firma, deberá aportarla también después del plazo. La clave privada es un valor numérico secreto con el que se crea esa firma. Una clave privada perdida no reaparece y otra rama puede seguir permitiendo gastar antes. Durante la ejecución, CSV deja su argumento en la pila, un espacio de trabajo con datos apilados; a menudo le sigue OP_DROP para retirarlo. Retirar ese dato no autoriza a nadie a tomar el dinero. Eso lo determinan las firmas y las demás condiciones del camino elegido. [1] [3] [5]

BIP 112 introdujo CSV sustituyendo OP_NOP3 junto con BIP 68 y BIP 113. Es una función activa, no un mero plan. Se usa, por ejemplo, en canales de pago de Lightning Network, donde un plazo puede dar a la otra parte tiempo para reaccionar; no provoca esa reacción. Al terminar la espera, la transacción aún debe difundirse y confirmarse. Importan las comisiones, los datos disponibles y el estado de la cadena. Bitcoin Core v29.0 y las especificaciones indicadas documentan los detalles. [1] [2] [6]