Fondo
Estaba leyendo un poco sobre las transacciones bloqueadas por tiempo de Bitcoin en el contexto de Lightning Network. Una cosa que nunca se explicó es lo que sucede cuando uno intenta gastar prematuramente la salida de un UTXO con bloqueo de tiempo.
Ejemplo
Alice envía 1 BTC a Bob en la dirección B a través de la transacción T, Salida 0. Pero la transacción está bloqueada en el tiempo hasta que la altura del bloque, actualmente en H, alcanza H+100. Entonces, para gastar T:0, Bob necesita dos cosas:
Bob está impaciente e intenta gastar T:0 cuando la altura del bloque es H+30. Transmite la transacción.
Pregunta
¿Qué sucede con la transacción de Bob? ¿Los mineros lo ignoran y los validadores lo rechazan ya que H+100 aún no ha ocurrido? Siempre había asumido que eso es lo que sucede; La transacción simplemente se descarta.
Pero al investigar Lightning Network, en la que las transacciones con bloqueo de tiempo juegan un papel clave, no es raro que un compañero de canal intente engañar a su socio transmitiendo un TX con bloqueo de tiempo desde un estado anterior. En realidad, depende de la parte inocente ver esta transacción en la cadena de bloques y, de alguna manera, usar algunos de los datos que se revelan en esa transacción como entrada para su propia transacción de penalización. Y, además, esa transacción de penalización debe ejecutarse antes de que se lleve a cabo la transacción de trampas con límite de tiempo. Y eso es lo que no entiendo. ¿Cómo ve la parte inocente este intento de transacción deshonesto si ya ha sido rechazado por los mineros y validadores?
¿O es incorrecta mi suposición de que los mineros rechazan las transacciones que dependen de una entrada bloqueada en el tiempo que aún no se ha alcanzado?
Solo abordaré la primera parte de su pregunta, ya que creo que la raíz de su confusión se puede abordar allí.
El bloqueo de tiempo en Bitcoin se refiere a dos conceptos relacionados e interactivos, pero fundamentalmente distintos:
nLockTime) que determina aproximadamente el momento o la altura más temprana en que esa transacción se puede incluir en la cadena. Una transacción con un tiempo de bloqueo en el futuro no es inválida; es simplemente inaceptable para su inclusión en la cadena hasta que pase dicho tiempo. La mayoría de los nodos de Bitcoin hoy en día no transmiten transacciones a menos que sean elegibles para la minería en los próximos bloques.nLockTimecampo que no esté por debajo de un valor proporcionado. No interactúa directamente con el tiempo o la altura . Todo lo que hace es requerir que la transacción de gasto se restrinja al futuro, y una transacción sin tal transacción nLockTimees incondicionalmente inválida y nunca puede ser minada. La consecuencia es, por supuesto, que esta salida no se puede gastar hasta que pase dicho tiempo, pero la relación se divide en dos.Esta separación de los dos tiene una serie de ventajas. Significa que los scripts solo deben ejecutarse una vez; no necesitamos volver a ejecutar cada vez que cambie el tiempo/la altura para volver a evaluar si siguen siendo válidos. También significa que las transacciones no pueden invalidarse a sí mismas a medida que pasa el tiempo: una vez que son válidas (y aceptables para ser extraídas), una transacción no puede volverse inaceptable a menos que se gaste dos veces.
Entonces, la respuesta a su pregunta depende de cómo la transacción viole el bloqueo de tiempo:
nLockTimecampo demasiado bajo, la transacción es incondicionalmente inválida.nLockTimecampo correcto, pero aún no ha llegado el momento, la transacción no es elegible para minería o retransmisión, pero cuando llegue el momento, cualquiera puede transmitirla y extraerla.
juan_more_bitcoin