🏠 INICIO
🤝 MEETUPS
Iniciamos temporada con un proyecto (aún en fase de producción) made in Málaga → Fundy: Una wallet Bitcoin que implementa timelocks y miniscripts como medidas adicionales de seguridad para proteger fondos. Estas opciones avanzadas permiten establecer condiciones específicas para que únicamente se liberen los fondos bajo determinadas circunstancias.
Agradecemos a Juan Carlos De La Torre y Diego García que nos presentaran su proyecto y deseamos que continúen trabajando con el mismo entusiasmo para que pronto podamos estar “diseñando recetas” con Fundy.
Estaremos muy atentos a su evolución. Mientras tanto puedes leer su **White Paper aquí.**
Durante su exposición aprendimos cuales son las posibilidades y casos de uso de timelocks y miniscript. Veamos un poco más en detalle en qué consiste cada uno de estos conceptos.
Se trata de un contrato inteligente que restringe el gasto de algunos UTXOs hasta un determinado momento futuro (medido en tiempo UNIX) o una altura de bloque. De ahí su nombre “bloqueo temporal”.
Realmente no son nada nuevo y fueron añadidos al software original de Bitcoin por Satoshi Nakamoto. Están presentes en todas las transacciones aunque la mayoría no utilice esta función, por lo que el tiempo de bloqueo por defecto es 0x00000000 (0) o 0xFFFFFFFF (4294967295).
| CLASIFICACIÓN ↓ → | Absoluto | Relativo |
|---|---|---|
| A nivel de transacción | nLockTime | nSequence |
| A nivel de Script | CheckLockTimeVerify (CLTV) | CheckSequenceVerify (CSV) |
Los Timelocks en Bitcoin tienen tres atributos comunes:
Extraido de la presentación de Fundy
Los timelocks pueden incluirse en las transacciones además de en los scripts.
Un timelock a nivel de transacción (nLockTime y nSequence) no se validará hasta un momento determinado. Esto se aplica incluso si la firma es válida.
Los timelocks a nivel de transacción sólo evitan que la transacción sea transmitida/minada, pero las salidas pueden ser doblemente gastadas antes de que llegue el momento establecido en el timelock. Un ejemplo extraído de Mastering Bitcoin:
*Alice firma una transacción gastando una de sus salidas a la dirección de Bob, y configura la transacción nLocktime dentro de 3 meses. Alice envía esa transacción a Bob para que la guarde. Con esta transacción Alice y Bob saben que:
*Sin embargo:
- Alice puede crear otra transacción, gastando dos veces las mismas entradas sin tiempo de bloqueo. Por lo tanto, Alice puede gastar el mismo UTXO antes de que transcurran los 3 meses.
- Bob no tiene ninguna garantía de que Alice no lo haga*
Este problema del doble gasto es una limitación de nLockTime. La única garantía es que Bob no dispondrá de estos fondos antes de que pasen 3 meses e incluso entonces, no hay garantía de que Bob obtenga los fondos. Tal garantía sólo se puede obtener a través de un timelock a nivel de script que restrinja el gasto del UTXO, en lugar de en la transacción.
Los timelocks a nivel de script, como CheckLockTimeVerify **(**CLTV) y CheckSquenceVerify **(**CSV), determinan si una transacción se puede realizar o no.
<aside> ⏱️ Una transacción con bloqueo de tiempo a nivel de script es válida antes de que se alcance el bloqueo de tiempo, simplemente no se puede gastar el UTXO. Los bloqueos de tiempo a nivel de transacción invalidan las transacciones hasta que se llegue al momento establecido.
</aside>
Existen timelocks de tiempo absoluto o de tiempo relativo. En ambos se especifica un momento concreto en el futuro en el que debe validarse una transacción.
Timelock absoluto: Determina una marca de tiempo específica o altura de bloque hasta el que la salida de una transacción es inválida. (Por ejemplo: a las 22:00)
Timelock relativo: Los bloqueos relativos hacen que las salidas de una transacción no se puedan gastar hasta que haya transcurrido una cantidad determinada de tiempo/bloques desde que la anterior salida de la transacción se minó en un bloque. (Por ejemplo: en 6 horas)