¿Es posible (de una forma u otra) caducar un txout?

Leo Contratos: ¿Será esto posible? donde parte de la pregunta se relacionaba con el vencimiento de una transacción y una de las respuestas decía que nunca sería posible ya que causa problemas. Desafortunadamente, la respuesta no indicó qué problemas causaría.

No puedo entender por la pregunta/respuesta si se trataba de una transacción (¿no confirmada?) que expira (que bien podría ser problemática) o de que expira un txout de una transacción previamente confirmada.

¿Es esto último completamente imposible por cualquier método actual, por ejemplo, secuencias de comandos y/o una combinación de transacciones?

Una forma en que percibo que podría ser posible (y solo soy un novato de bitcoin, así que tenga piedad de mí y ayúdeme a entender si esta sugerencia es evidentemente ridícula para los expertos de bitcoin) sería tener una nueva operación de secuencia de comandos de bitcoin que podría ser usado en el scriptPubKey del txout para empujar el tiempo ' actual ' a la pila para que pueda ser comparado (usando OP_LESSTHAN, OP_GREATERTHAN, OP_LESSTHANOREQUAL o OP_GREATERTHANOREQUAL) a un tiempo de caducidad fijo (que está en scriptPubKey y empujado a la pila por scriptPubKey) y solo si la hora actual es menor que la hora de vencimiento, el resto de scriptPubKey permitirá que se confirme la transacción (es decir, el pago de bitcoin).

Una nota sobre lo que quiero decir con hora ' actual '... podría haber un largo debate sobre la fuente de la hora actual y la confiabilidad de esa fuente, pero propongo que la hora 'actual' realmente no necesita ser la tiempo actual real, siempre que sea una aproximación razonablemente cercana en el ámbito de bitcoin (alrededor de 10 minutos en promedio, pero tal vez más, tal vez más corto). Por lo tanto, podría ser la marca de tiempo del bloque anterior en la cadena de bloques; de esa manera, cada nodo (suponiendo que no haya bifurcación) juzgará la expiración de txout contra el mismo tiempo 'actual'.

Un efecto secundario indeseable pero posiblemente aceptable es que si una transacción que gasta el txout se envía y se confirma en una bifurcación corta de blockchain, se volverá a poner en cola en la bifurcación más larga y existe la posibilidad de que txout haya expirado antes de que se vuelva a procesar la transacción y, por lo tanto, el la transacción fallará la segunda vez.

Otra sutileza para ayudar a la usabilidad podría ser ofrecer dos variantes de la nueva operación de tiempo 'actual' para reflejar las dos 'variantes' de lock_time, una variante para insertar la marca de tiempo del bloque anterior en la pila y la otra variante para insertar la marca de tiempo del bloque anterior. altura sobre la pila. De esta forma, un usuario puede escribir transacciones que son autoconsistentes en referencia de tiempo o autoconsistentes en referencia de altura.

Las bifurcaciones funcionan de manera un poco diferente de lo que supone: tan pronto como divergen de una fuente común, son completamente independientes entre sí. Son ramas hijas divergentes de una raíz común, que nunca volverán a encontrarse. Cada bifurcación considera que sus competidores no son válidos, ya que son incompatibles entre sí. Por lo tanto, nunca habrá una nueva cola debido a la interacción con otras bifurcaciones, sino que cada bifurcación considerará cada transacción por sí misma tan pronto como esté disponible.

Respuestas (1)

Expirar un txout realmente no tiene sentido, ya que destruiría las monedas, y no hay forma de destruir las monedas. (Las monedas no mencionadas por ningún txout se contribuyen como tarifas).

Podría crear una transacción con lock_time en el futuro que envíe las monedas a otra dirección de bitcoin. Si le da esta transacción a una contraparte, entonces tendrá la opción de transmitir la transacción a la red después de que venza y entrará en vigencia.

Antes de ese tiempo, podría crear otra transacción sin la restricción lock_time, mover las monedas y hacer que la transacción de la contraparte sea inútil.

Mi comentario es demasiado largo, por lo que viene en varias partes... PARTE 1 Este es un ejemplo algo artificial pero ilustra el tipo de cosas que estaba contemplando. NB: El ejemplo requeriría el uso de (actualmente) transacciones no estándar con operaciones de secuencias de comandos condicionales.
PARTE 2 Condiciones: 1) Alice quiere darle algunos bitcoins a Bob ahora mismo (tiempo t0) pero quiere estipular que deben gastarse en un tiempo futuro determinado (t2). A Alice no le importa en qué gasta Bob los bitcoins. 2) Si Bob no gasta los bitcoins en el tiempo t2, entonces Alice quiere que las monedas se donen a una fundación benéfica administrada de forma anónima por Eve. 3) Alice espera morir aproximadamente en el tiempo t1 donde t1<t2.
PARTE 3 Corolarios: 1) Alice necesita enviar una transacción (Tx0) en t0 con un txout que transfiere los bitcoins a Bob para que Bob pueda gastarlos. 2) Alice y Bob no quieren que Alice sea signataria de la transacción de gasto de Bob (todavía no escrita) (Tx.Bobspend) principalmente porque si Alice muere en t1<t2 antes de que Bob haya generado Tx.Bobspend, Alice ya no estará. para firmar Tx.Bobspend a pesar de que aún no hemos llegado a t2.
PARTE 4 3) Aunque Alice podría generar una transacción (Tx.Alicecharity) ahora con un txout que transfiere los bitcoins a la fundación, no conoce la identidad de Eve y, por lo tanto, no tiene a dónde enviar Tx.Alicecharity.
PARTE 5 Entonces, el Tx0 de Alice tendría un txout que funciona de esta manera cuando alguien intenta gastarlo con una transacción (Tx.futuro) en algún momento en el futuro (t.futuro): Si t.futuro < t2 y firmas en Tx.future coincide con la dirección de bitcoin de Bob y luego deja que Bob gaste los bitcoins. De lo contrario, si t.future > t2 y las firmas en Tx.future coinciden con la dirección de bitcoin de la fundación, deja que la fundación gaste los bitcoins. De lo contrario, t.future no es válido.
No hay forma de poner una referencia a la hora actual (u otra función similar al tiempo que aumenta monótonamente) en el script, por lo que no veo una manera de hacer esto con una sola transacción. Sin embargo, podría escribir un 1 de 2 multi-sig que transfiera las monedas a A1 y B1 (donde A1 está controlado por Alice y B1 está controlado por Bob), y enviar a Eve una transacción que mueva las monedas multi-sig a E1 (un dirección controlada por Eve) con lock_time establecido en t2. Luego, Eve es libre de transmitir la transacción, tomando las monedas de la transacción multisig después del tiempo t2.
¿Quiso decir 'actualmente de ninguna manera' (de acuerdo) o 'nunca será una forma'? Estaba planteando la idea de una o dos nuevas funciones de secuencias de comandos para el uso de scriptPubKey que empujarían la altura o la marca de tiempo del bloque anterior a la pila precedida o seguida por una inserción de una constante (expresando el tiempo de 'caducidad') y luego un op_lessthan u op_greaterthan para determinar si el tiempo 'actual' es anterior o posterior a la constante. Dado que los nodos ya tienen algún concepto del tiempo 'actual' para verificar Tx NLock_time, no parecía un gran paso hacia adelante ... pero mi comprensión es probablemente demasiado simplista. :-/
por cierto, su respuesta (reflexiva) parecía sugerir que Alice enviaría un Tx firmado y bloqueado a Eve, pero mi ejemplo (muy artificial) ya había declarado explícitamente que Alice no sabía quién era Eve, por lo que no tenía forma de enviar a Eve. cualquier cosa (A pesar de la posibilidad de que Alice use un tercero de confianza para transmitir el Tx lock_timed en nombre de Eve una vez que haya pasado el tiempo de bloqueo).
¿Es posible (de una forma u otra) caducar un txout?
RespuestasAquíPolítica de privacidad1y, 0v