PSBT v2

Anna y Jan quieren pagar una factura entre los dos. Cada uno aporta fondos y añade su firma desde su propio dispositivo. Necesitan intercambiar una propuesta coincidente, no sus claves privadas. Una clave privada es un número secreto que el monedero utiliza para crear una firma digital que autoriza el gasto. PSBT actúa como un sobre de trabajo que contiene la transacción y la información que la acompaña. Las entradas identifican importes anteriores que se gastan; las salidas fijan nuevos importes y las condiciones para gastarlos después. El formato original PSBT v0 guarda esta estructura en una transacción global sin firmar que permanece fija. En v2 pueden añadirse entradas y salidas de forma progresiva según las reglas correspondientes. La ventaja es construir juntos, no reescribir libremente lo que otra persona ya ha firmado. [1] [2]

Anna no necesita leer cada campo técnico. Sí debe comprobar en un dispositivo de firma fiable el destinatario real, el importe, la comisión y el posible cambio que vuelve a su monedero. Este último detalle puede pasar desapercibido: no debe confundir una salida ajena con su propio cambio. El dispositivo tiene que verificar los datos de los UTXO, las salidas que aún no se han gastado, y que sus condiciones concuerden con lo que se firma. La ruta de derivación indica los pasos que sigue el monedero para obtener una clave concreta a partir de su clave maestra. Que esa ruta figure en el archivo no demuestra por sí solo la propiedad. El dispositivo de firma también debe interpretar SIGHASH, la opción que determina qué partes de la transacción protege la firma. Para firmar no hace falta añadir al archivo intercambiado una clave privada ni la Seed Phrase, las palabras de respaldo del monedero. [2] [4]

Que una aplicación o dispositivo anuncie compatibilidad con PSBT no prueba que admita v2. Hay que comprobar todo el recorrido: creación, importación, firma y devolución del resultado entre los programas y dispositivos concretos. PSBT v0 y v2 no son intercambiables directamente. Convertir a v0 exige construir la transacción sin firmar y adaptar los campos a las reglas de esa versión; no basta con cambiar un número. Tampoco Taproot, una forma más reciente de definir las condiciones de gasto de las salidas de Bitcoin, es lo mismo que v2. BIP 371 describe sus datos de firma para ambas versiones de PSBT. Una prueba pequeña de principio a fin comprueba la compatibilidad de esa combinación, no la corrección de todos los pagos futuros. [1] [3]

La versión del formato del archivo y la versión de la transacción de Bitcoin significan cosas distintas. En v2, PSBT_GLOBAL_VERSION debe contener 2 y el antiguo campo PSBT_GLOBAL_UNSIGNED_TX debe estar ausente. Otro campo obligatorio, PSBT_GLOBAL_TX_VERSION, indica la versión de la propia transacción. También son obligatorios los recuentos de entradas y salidas. Así, la información queda junto a cada elemento, sin que el programa tenga que buscarla además en una estructura común. Si quien crea el archivo delega su construcción en otros participantes, BIP 370 exige los indicadores de modificación adecuados y una versión de transacción de al menos 2. Sigue siendo un formato de trabajo, no unas nuevas reglas de consenso para la red. [1]

Cada entrada necesita un TXID, el identificador de la transacción anterior, y el índice de la salida concreta que se gasta de ella. El TXID no basta: una transacción puede tener varias salidas. Cada salida nueva lleva un importe en satoshi, las unidades mínimas de Bitcoin, y un scriptPubKey, el script que define las condiciones para gastarla. Al añadir un elemento debe actualizarse también su recuento global. El campo opcional sequence contiene otro valor de control de la entrada; si falta, se usa 0xffffffff. Estos datos indican cómo construir la transacción. No sustituyen la información sobre el valor y las condiciones de gasto de los UTXO, necesaria para que el dispositivo evalúe con seguridad la firma y la comisión. [1]

Supongamos que Jan necesita añadir otra entrada. El programa no puede dar por hecho que está permitido solo porque tiene el archivo. En PSBT_GLOBAL_TX_MODIFIABLE, el bit 0 indica si pueden cambiar las entradas y el bit 1 si pueden cambiar las salidas. El bit 2 avisa de una firma SIGHASH_SINGLE, que vincula una entrada con la salida situada en la posición correspondiente. Esa pareja debe conservarse al insertar más elementos. Por ello, quien construye la transacción revisa las firmas concretas y sus restricciones. Los indicadores informan a los programas que colaboran; no eluden una firma criptográfica ni convierten en válido un cambio inválido. [1]

Algunas entradas requieren esperar a una altura de bloque o a un límite temporal antes de que la transacción pueda utilizarse. Un bloque es un conjunto de transacciones registrado en el historial compartido de la red; su altura indica su posición en la cadena. El campo común nLockTime debe emplear un tipo de requisito compatible con todas las entradas. Se escoge el mayor valor requerido de ese tipo; si ambos tipos son posibles, tiene preferencia la altura de bloque. No se comparan altura y tiempo como si fueran dos números corrientes. Si ninguna entrada impone requisitos, se usa el valor global de respaldo o, si falta, 0. No puede añadirse una entrada con requisitos incompatibles. Cuando ya hay firmas, una entrada nueva tampoco puede alterar el nLockTime calculado. Estos campos por sí solos no garantizan cumplir todas las reglas de los bloqueos temporales. [1]

Cada firma restringe las modificaciones posteriores. BIP 370 exige desactivar los cambios de entradas cuando la firma no usa SIGHASH_ANYONECANPAY y los de salidas cuando no usa SIGHASH_NONE; con SIGHASH_SINGLE se registra la pareja que debe conservarse. Son nombres de distintos alcances de protección de una firma, no opciones que un principiante deba cambiar al azar. Cuando todas las entradas están listas, la finalización reúne los datos de firma necesarios y un extractor construye la transacción en el formato de la red. Solo al enviarla pueden los nodos evaluarla y un minero incluirla en un bloque. Anna y Jan distinguen, por tanto, una propuesta, un resultado firmado y un pago confirmado: intercambiar un PSBT no equivale por sí solo a firmar ni a confirmar. [1] [2] [4]