Peter Todd es desarrollador de Bitcoin, autor de la propuesta de bloqueo temporal BIP 65, coautor de las reglas de sustitución de transacciones no confirmadas BIP 125 y desarrollador de OpenTimestamps. Son aportaciones sobre garantías distintas: condiciones de gasto, estado de un pago y existencia demostrable de datos. Ninguna garantiza por sí sola todas las demás.
Imagina que necesitas demostrar que una versión concreta de un contrato existía antes de una disputa. OpenTimestamps, proyecto vinculado a Peter Todd, responde a esa necesidad. Su anuncio histórico de 2016 presentó una versión pública de prueba y agradeció a Riccardo Casatta su trabajo de desarrollo y pruebas. Es un registro de aquella colaboración, no una afirmación de que el proyecto siga siendo experimental. Todd también trabajó en condiciones para gastar fondos en el futuro y en pagos pendientes de confirmación. Empecemos por esos dos ámbitos. [1]
BIP 65, escrito por Todd, introdujo OP_CHECKLOCKTIMEVERIFY, abreviado CLTV. Esta instrucción permite condicionar una vía concreta de gasto a alcanzar cierta altura de bloque o límite temporal. Piensa en una vía de respaldo para unos ahorros compartidos que el destinatario solo podrá usar más adelante. Hasta entonces, la condición temporal impide utilizarla. Cuando se cumple, las monedas no se envían solas: todavía hay que crear una transacción válida y satisfacer los demás requisitos, como una firma. Si existe otra vía de gasto, tendrá sus propias condiciones; el bloqueo no afecta necesariamente a todas. [2]
El bloqueo no se guía simplemente por el reloj de la cartera. BIP 65 comprueba la relación entre el script, las instrucciones que regulan el gasto, y el campo nLockTime de la transacción. Ambos deben expresar el mismo tipo de límite: altura de bloque o tiempo. Además, el campo nSequence de la entrada no puede tener el valor de finalidad que impediría aplicar la comprobación. Se trata de un límite absoluto, no de la edad relativa de la salida desde su confirmación. Cumplirlo tampoco garantiza entrar en un bloque en un segundo exacto; un minero aún debe incluir la transacción en un bloque válido. [2]
Una transacción enviada puede quedarse en el mempool, el conjunto de transacciones no confirmadas que conserva un nodo. Si suben las comisiones, el remitente puede querer ofrecer más mediante una transacción de sustitución. David A. Harding y Peter Todd describieron las reglas originales de sustitución opt-in en BIP 125. La posibilidad de sustitución se señalaba con nSequence o se heredaba de una transacción antecesora no confirmada cuya salida gastaba el pago. Por tanto, también importaban las dependencias entre transacciones. Una comisión mayor puede ayudar, pero no garantiza una confirmación inmediata. [3]
Sustituir una transacción en el mempool cambia el candidato que el nodo conserva para su confirmación. No reescribe el historial confirmado. BIP 125 describe además una política histórica opt-in, no una regla eterna para todos los programas y versiones. Versiones posteriores de Bitcoin Core convirtieron la sustitución sin esa señal en el comportamiento habitual, aunque siguen aplicando condiciones de aceptación. Para quien recibe un pago, la lección es sencilla: la ausencia de señal no demuestra que el pago sea definitivo. Tampoco un aviso de «enviado» significa que ya esté en un bloque confirmado. [3] [6]
Volvamos al contrato. OpenTimestamps crea una prueba verificable de que unos datos concretos existían antes de un límite temporal acreditado. Utiliza un hash, una huella digital breve del contenido, y una prueba anclada en Bitcoin. Al cambiar el documento, su huella cambia al verificarlo. Sin embargo, el sello no acredita quién lo escribió, la veracidad de sus afirmaciones ni el instante exacto de creación. También se puede sellar a tiempo un relato falso. La prueba limita lo tarde que pudieron surgir los datos; no indica cuánto tiempo llevaban existiendo. [1] [4]
El cliente de OpenTimestamps no envía el documento a los servidores de calendario. Procesa su huella junto con un valor aleatorio para que el servidor no pueda deducir el contenido a partir de lo recibido. Aquí un calendario es un servicio que reúne solicitudes y ayuda a anclarlas en Bitcoin. Proteger el contenido no ofrece anonimato completo: la proximidad temporal y las pruebas creadas conjuntamente pueden revelar vínculos entre solicitudes. El archivo .ots no es una copia de seguridad. Consérvalo junto al original exacto; una huella no permite recuperar un texto perdido y una copia modificada ya contiene otros datos. [5]
Un sello recién creado puede no estar todavía anclado en un bloque confirmado. La mera existencia del archivo .ots no demuestra que el proceso haya terminado. El cliente de OpenTimestamps distingue una prueba pendiente de una completa, que contiene el recorrido hasta el bloque. El comando ots upgrade puede obtener y guardar la información restante cuando esté disponible; no obliga a minar un bloque. Después hay que verificar la prueba contra los datos originales y la cadena de Bitcoin. Igual que con un pago pendiente, importa el estado real, no solo que aparezca un archivo o una notificación. [5]
Para obtener la imagen más completa, lee esta entrada junto con Luke Dashjr, Mara van der Laan, Satoshi Nakamoto. También enlazan con esta entrada Luke Dashjr, Mara van der Laan.