En bitcoin, cada transacción tiene un nLockTimenúmero entero para especificar el número/tiempo de bloque permitido más temprano en que la transacción se puede agregar a la cadena de bloques. Además, cada entrada de transacción tiene un nSequencenúmero entero que teóricamente podría usarse para actualizar las transacciones y saber cuál es la más reciente (aunque esta funcionalidad actualmente está deshabilitada).
Pero, ¿hay alguna forma de transmitir una transacción que sea definitiva y se pueda agregar a la cadena de bloques de inmediato, pero también hacer que sus salidas no se puedan gastar hasta un determinado número/tiempo de bloque? Parece que esta sería una característica útil. Por ejemplo, si quiero dar mi herencia para que esté disponible en el momento en que mi nieto/nieta cumpla 18 años, no creo que haya ninguna forma de hacerlo en bitcoin, excepto que alguien retenga los fondos y se los entregue en el tiempo. O si quisiera darle una asignación a alguien, podría enviar fondos de una sola vez durante 3 meses más o menos, y aparecerían en la billetera del hijo/hija semanalmente.
Entonces, solo para verificar, no hay forma de hacer algo como esto en bitcoin, ¿verdad? ¿Existe algún riesgo de seguridad al permitir transacciones como esta? Si realmente no hay ninguna forma de hacer esto, entonces tal vez sea algo para agregar a la lista de deseos de la bifurcación dura .
Si no hay forma de hacer esto con Bitcoin en este momento, ¿es porque hay una falla grave en un sistema de este tipo en el que se podría agregar un UTXO a la cadena de bloques que AÚN no se puede gastar ?
Puedo pensar en dos formas en que tal cosa podría implementarse.
OP_BLOCKINDEXy OP_BLOCKTIMEcódigos de operación, que simplemente insertan el valor correspondiente en la pila. Sin embargo, estos valores tendrían que provenir del bloque que gasta la UTXO, no del bloque que incluyó la transacción que creó la UTXO. Esto significaría que cualquier salida de transacción con estos códigos OP no podría gastarse con 0 confirmaciones, porque estos OP no tendrían significado en este contexto. (Este método posiblemente agrega demasiada complejidad a la situación)nSequencecampo, podríamos agregar algunos bytes adicionales a cada salida para indicar cuándo se puede gastar una salida (número de bloque/tiempo). Si no se proporciona, se puede suponer que es 0.No, actualmente no hay ninguna forma de hacer lo que describe sin utilizar un oráculo de terceros.
Sí, es posible que pueda hacer esto relativamente pronto. Se ha propuesto una bifurcación suave para introducir un código de operación ( OP_CHECKLOCKTIMEVERIFYCLTV ), y lo que puedo decir es que tiene un fuerte apoyo del equipo de desarrollo central (pero tenga en cuenta que las bifurcaciones blandas requieren soporte minero para la implementación).
Como dice Nick, los intentos anteriores fueron rechazados porque proponían empujar la altura o el tiempo del bloque actual a la pila de esta manera:
<pubkey> checksigverify block <data> equalverify
<your pubkey> compare to sig current height 1000000 Only spend in block 1,000,000
Nuevamente, profundizando en lo que dijo Nick, la transacción de ejemplo anterior sería válida en el bloque 1,000,000, pero si hubiera una reorganización de la cadena, es posible que no se incluya en el nuevo bloque 1,000,000 y, por lo tanto, cualquier transacción que dependa de ella sería inválida.
El código de operación CLTV evita esto de dos maneras. Primero, usa el valor nLockTime de la transacción de gasto en lugar del valor de altura del bloque o tiempo del encabezado del bloque. Dado que una transacción solo se puede incluir en un bloque si su nLockTime es igual o mayor que la altura/tiempo del bloque actual, esto logra el objetivo principal de permitir UTXO que no se pueden gastar hasta un momento determinado.
La otra cosa que hace CLTV es verificar los valores directamente en lugar de enviar datos a la pila. Esto le permite implementar solo una verificación de mayor o igual que, por lo que la transacción siempre se puede gastar después de la altura/tiempo especificado.
Mi conjetura es que el proceso de bifurcación suave para introducir CLTV comenzará con Bitcoin Core 0.11, posiblemente en algún momento alrededor de julio de 2015. (Pero, en realidad, es poco probable que los desarrolladores principales pasen mucho tiempo en CLTV hasta que se lance 0.10 alrededor de enero, así que no No cuentes con eso.)
No puedo encontrar el problema de bitcointalk thread/github discutiendo esto, pero se consideró y rechazó un código de operación de índice de bloque.
La razón (IIRC) es que es importante que si una transacción no entra en un bloque, aún puede incluirse en otro bloque. Sería muy sorprendente que una transacción se revirtiera porque el bloque en el que se encontraba se extinguiera y el bloque que lo reemplazó tuviera una marca de tiempo de diez segundos después.
Por supuesto, podría mitigar esto al detectar cuándo un pago entrante tiene uno de los códigos de operación dependientes de tiempo/bloque. El siguiente problema que debe resolver es que alguien podría realizar una transacción dependiente del tiempo y luego gastar una de esas salidas con una transacción normal. Parecería una transacción normal para la persona a la que se la envió, pero en realidad dependería de una transacción que podría volverse inválida si se incluyera en un bloque diferente.
Ninguno de estos problemas es irresoluble, pero sin un caso de uso convincente, no vale la pena la complejidad. En el ejemplo que da, se podría lograr lo mismo poniendo su clave privada en una caja de seguridad y entregando su contenido a su nieto.
Además, su problema puede resolverse con nLockTime. Puede crear una transacción enviando sus Bitcoins a una dirección controlada por su nieto; configurar nLockTime para que caduque en una fecha determinada; y destruir la clave privada que firma esa transacción. El problema con esto es que la transacción no se guarda en la cadena de bloques. Además, será mejor que su nieto no pierda esa clave privada. :)
Comentaristas, por favor participen si pueden encontrar dónde se discutió esto.
if you could send to a Multisig, you could eliminate thatVerdadero. What do you meanLo siento, eso no fue muy claro. ¿Esta mejor ahora?x > 0no se procesará hasta x blocksdespués de la altura del bloque de Txn, aunque en la práctica aparentemente 2 horas (12 bloques) es el tiempo de corte ideal. Esto se debe a que si desea rescindir la transacción, se debe formar un nuevo Tx para desviar los Bitcoins de la dirección de salida bloqueada en el tiempo a una nueva salida (es decir, cuando expire ntimelock, el Tx fallará porque se gastaron las entradas. Esto Sin embargo, todo es de memoria, así que aún no estoy lo suficientemente seguro como para que sea una respuesta.Las otras respuestas aquí están actualmente desactualizadas porque la red adoptó OP_CSV y OP_CHECKLOCKTIMEVERIFY, las cuales brindan formas de construir salidas bloqueadas.
Nick ODell
codificador morse
nLockTimepuede usar tanto para determinar el punto más temprano en que se puede agregar una transacción a la cadena de bloques como para determinar el tiempo más rápido que se puede gastar? ¿nLockTimePerderá su antigua funcionalidad y será reemplazada por la nueva? No puede tomar dos valores a la vez...David A. Harding
codificador morse
nLockTimemás de un número que se especifica en el scriptPubKey, y la funcionalidad actual de bitcoin ya lo hace para que las transacciones no se pueden incluir en la cadena de bloques antes delnLockTimebloque/tiempo. ¡Gracias!