En la propuesta de eltoo para la gestión de canales de pago con menos gastos generales propuesta por Christian Decker et al. la update transactionsnecesidad de ser ordenado. En el capítulo 4.1.2 de la propuesta, se describe, con el fin de ser compatible con versiones anteriores, que el nLocktimecampo se puede reutilizar dentro de las transacciones de actualización.
¿Existen otros inconvenientes de esta solución además del hecho de que parece un poco raro?
Esperaba que alguien más respondiera esto, ya que soy el autor de eltoo, hubiera preferido una respuesta independiente.
Para recapitular: el tiempo de bloqueo se usa en eltoo para permitir una comparación numérica entre un elemento en la pila (número de estado) y un valor al que se compromete la firma. La razón por la que no podemos simplemente insertar un número en la pila nosotros mismos es que esta inserción ocurriría en el redeemScript, que no se puede confirmar en la firma, ya que contiene la firma. OP_CLTVcombina el empuje, la comparación y la verificación en un código de operación:
Marca la transacción como no válida si el elemento de la pila superior es mayor que el campo nLockTime de la transacción; de lo contrario, la evaluación del script continúa como si se hubiera ejecutado un OP_NOP.
A su pregunta sobre si es seguro: OP_CLTVes el único código de operación que alguna vez toca el nLocktime(destinado a usarse en scriptPubkey), y el único otro uso es marcar una transacción como no válida hasta una cierta altura. Ambos casos de uso solo especifican lo que sucede con las alturas de bloque y las marcas de tiempo futuras, y no tienen ningún efecto si está nLocktimeen el pasado.
Por lo tanto, el uso que hace eltoo del nLocktimecampo y OP_CLTVtécnicamente no es una reutilización, sino que hace uso de la semántica existente.
Por supuesto, no puedo prever si hay alguna propuesta futura que pueda querer reutilizar las alturas de bloque y las marcas de tiempo pasadas, pero no tengo conocimiento de ninguna, y la búsqueda de BIP no arroja resultados contradictorios. También sería muy inseguro redefinir su semántica para las marcas de tiempo que eran plausibles en la cadena de bloques, dejándonos unos pocos millones de marcas de tiempo únicas, incluso si solo consideramos 2009-01-03, hoy.