Glosario / Protocolo y actualizaciones
OP_CHECKSEQUENCEVERIFY
También se conoce como CSV o BIP112.
- ¿Qué es OP_CHECKSEQUENCEVERIFY?
- OP_CHECKSEQUENCEVERIFY bloquea una moneda durante un período medido desde su propia confirmación y hace fallar cualquier gasto cuya entrada no haya esperado lo suficiente.
Se especifica en el BIP-112.
El opcode (código de operación) lee un número de la pila y lo compara con el campo del número de secuencia de la entrada que se gasta, así que el reloj arranca cuando la moneda llega a un bloque y no en una fecha de calendario. Lo definió BIP-112, y la red empezó a hacerlo cumplir en el bloque 419.328, el 4 de julio de 2016. Todo canal Lightning que usted abra depende de él.
Cómo funciona
El opcode 178 era antes OP_NOP3 y no hacía nada, y así fue como la regla llegó a la red como una bifurcación blanda (soft fork) y no como una división de la cadena.
La comprobación se hace con tres valores de entrada: el número de la pila, el campo del número de secuencia de la entrada que se gasta y la versión de la transacción. Se exige la versión 2 o superior, porque las reglas de BIP-68 sobre el bloqueo temporal relativo (relative timelock) solo se aplican a partir de esa versión. Si el bit superior de cualquiera de los dos valores está activado, el bloqueo temporal queda desactivado y el opcode desiste. En caso contrario, los dos tienen que coincidir en la unidad y el valor de la pila no debe superar el del campo del número de secuencia.
Las unidades son de dos tipos y no se pueden mezclar en una misma comparación. Con un indicador concreto desactivado, el número cuenta bloques; con ese indicador activado, cuenta intervalos de 512 segundos. En ambos casos hay dieciséis bits disponibles, así que el techo es de 65.535 bloques, aproximadamente 455 días, o la misma cantidad de intervalos de 512 segundos, que se queda algo por debajo de 389 días. Cualquier espera más larga necesita, en su lugar, un bloqueo temporal absoluto.
El fallo no es un retraso, es un rechazo. Antes de que termine el período de espera, el gasto no es una transacción pendiente que aguarda en una cola, sino una transacción inválida que ningún nodo retransmitirá y que ningún minero incluirá. No hay que reintentar nada hasta que la moneda tenga la antigüedad suficiente, y en ese momento exactamente la misma transacción pasa a ser válida.
Dónde aparece
Lightning es el mayor usuario por volumen, y el opcode está en el script que protege su propio lado de cada canal.
Cuando un canal se cierra de forma unilateral, el saldo de la parte que cierra va a una salida que no se puede barrer hasta que haya pasado un retraso, el parámetro to_self_delay de BOLT 3, habitualmente de unos pocos cientos de bloques. El retraso existe para que el otro par tenga una ventana en la que publicar una revocación y quedarse con los fondos si el cierre usó un estado antiguo. Su dinero está a salvo en cualquier caso, pero por eso un cierre forzado le deja esperando un día o más, mientras que un cierre cooperativo paga de inmediato.
La misma construcción aparece en los intercambios submarinos y en los intercambios atómicos, donde una ruta de reembolso solo debe abrirse después de que la contraparte haya tenido una oportunidad justa de reclamar, y en las billeteras de recuperación, donde una clave de respaldo pasa a poder usarse tras un largo silencio.
Una trampa merece una advertencia. Un bloqueo temporal relativo se mide desde la confirmación de la moneda concreta que se gasta, así que vuelve a empezar cada vez que esa moneda se mueve. Consolidar polvo, barrer el cambio o dejar que una billetera redistribuya sus salidas reiniciará la cuenta regresiva en cada rama de recuperación que usted haya configurado, y un heredero que esperaba que la clave de respaldo funcionara el mes que viene puede encontrarse el reloj de nuevo en cero.
OP_CHECKSEQUENCEVERIFY frente a OP_CHECKLOCKTIMEVERIFY
CSV (OP_CHECKSEQUENCEVERIFY) pregunta cuánto tiempo lleva existiendo la moneda; CLTV (OP_CHECKLOCKTIMEVERIFY) pregunta qué hora es. Los dos opcodes están uno junto al otro en la numeración, 178 y 177, y se eligen para tareas muy distintas.
Use la forma absoluta cuando el plazo sea una fecha real: un fideicomiso que se desbloquea en 2030, un reembolso que expira a una altura conocida. Use la forma relativa cuando la espera deba empezar en el momento en que arranque el contrato, sea cuando sea, que es lo que necesita cualquier script escrito una vez y reutilizado muchas veces. Lightning no podía usar bloqueos temporales absolutos para los retrasos de los canales, porque un canal abierto hoy y un canal abierto el año que viene necesitarían scripts distintos. Además, los dos llegaron con pocos meses de diferencia, CLTV en el bloque 388.381, el 14 de diciembre de 2015, y CSV en julio del año siguiente, y el segundo existió en gran parte porque el primero no bastaba para construir canales de pago.