PSBT

Anna quiere enviar a Pavel 60 000 sat, sesenta mil de las unidades más pequeñas de bitcoin. Su cartera utiliza una salida recibida anteriormente y aún sin gastar de 100 000 sat. Una salida registra una cantidad y las condiciones para gastarla. En este ejemplo, la cartera propone 60 000 sat para Pavel, 39 000 sat de vuelta a Anna como cambio y deja 1 000 sat como comisión. Por ahora son solo instrucciones. La aplicación las guarda en un PSBT y lo pasa a la cartera física, por cable, código QR o tarjeta de memoria según el dispositivo. Anna comprueba el pago en su pantalla y autoriza la firma. Lo que vuelve es la firma, no la clave secreta. Preparar el pago no tiene por qué ocurrir en el dispositivo autorizado para firmarlo. [1] [4]

Un archivo con extensión .psbt no es automáticamente un pago seguro. El ordenador que lo creó puede estar comprometido o mal configurado. Anna compara el destinatario con la dirección obtenida de Pavel y comprueba el importe, la comisión total y que el cambio vuelva a su propia cartera. Con una cartera física, se guía por su pantalla fiable y el procedimiento del fabricante. El software de firma verifica también los datos de apoyo y qué datos cubre la firma. El término técnico sighash describe qué partes de la transacción protege la firma frente a cambios. Un principiante no debería aprobar un modo inusual sin entenderlo. Si la dirección no coincide o no se puede verificar la comisión, hay que revisar la propuesta, no saltarse la comprobación. [1]

En una cartera Multisig de dos firmas entre tres claves, Anna puede aportar la primera y Pavel la segunda, cada uno desde su dispositivo. No necesitan intercambiar palabras de recuperación ni conectarse a la vez. Un coordinador, la aplicación que organiza el proceso, reúne los datos del mismo pago y combina las firmas. Cada firmante sigue teniendo que verificar su propia intención: el coordinador no decide por él. BIP 174 distingue al creator, que inicia la propuesta; al updater, que añade información; al signer, que firma; y al combiner, que une versiones correspondientes. El finalizer construye los datos finales que satisfacen las condiciones de las entradas, y el extractor obtiene la transacción normal de red. Un programa suele asumir varios papeles. Estos nombres describen tareas, no seis participantes obligatorios. [1] [4]

Un PSBT puede revelar qué monedas piensas utilizar, a quién pagas, cuánto cambio recibes y cómo se relacionan las direcciones. Puede incluir un xpub, datos públicos para derivar otras claves públicas y, junto con las reglas de la cartera, direcciones, o rutas de derivación, que indican dónde están las claves en la estructura de la cartera. No lo envíes a cualquier servicio web solo para leer su contenido. Además, un PSBT firmado puede permitir que otra persona complete y difunda precisamente la transacción que autorizaste, si dispone de todos los datos necesarios. Borrar tu copia no revoca la firma. Tampoco sustituye a la Seed Phrase (las palabras de respaldo para recuperar las claves) ni a una copia completa de la configuración Multisig: sirve para un pago concreto, no para recuperar toda la cartera. [1] [4]

Añadir una firma no significa que la red conozca el pago. Tras construir la transacción final, alguien debe difundirla. Un nodo es un ordenador con software que verifica las transacciones y los bloques de Bitcoin. Un nodo la evalúa según las reglas de la red y su política de admisión; un minero puede incluirla en un bloque. Una firma ausente, una entrada ya gastada y una comisión insuficiente son problemas distintos que un botón de ‘completar’ no resuelve por sí solo. Prueba la combinación concreta de aplicación, dispositivo y tipo de cartera antes de depender de ella. En Bitcoin Core 29, analyzepsbt puede mostrar datos o firmas que faltan. finalizepsbt puede producir la transacción terminada; enviarla es un paso adicional. Completarla correctamente tampoco equivale a una confirmación en bloque. [4] [5] [6]

BIP 174 define PSBT como un formato binario que organiza información en pares clave–valor. Aquí ‘clave’ significa identificador de un campo, no necesariamente una clave privada de Bitcoin. Un mapa global describe toda la transacción, los mapas de entradas describen las salidas que se gastan y los de salidas describen las nuevas que se crean. Junto a la propuesta pueden llevar scripts, es decir, condiciones de gasto, además de orígenes de claves y firmas parciales. Los datos pueden guardarse en un archivo .psbt o representarse mediante Base64, una codificación de datos binarios como texto. Base64 no es cifrado. PSBT no añade un nuevo tipo de transacción a las reglas de Bitcoin: la red recibe la transacción resultante, no todo el archivo de trabajo. [1]

Un dispositivo desconectado de la red necesita saber qué va a firmar. Un UTXO es una salida anterior todavía sin gastar; una nueva entrada hace referencia a ella. Non-Witness UTXO puede llevar toda la transacción anterior, mientras que Witness UTXO lleva la salida concreta con su importe y condiciones. Los datos requeridos dependen del tipo de entrada y de las reglas del software de firma. Se comprueban, entre otras cosas, el identificador de la transacción anterior y su salida correspondiente, la relación entre scripts y un sighash aceptable. Un importe ausente no debe interpretarse como una comisión cero, ni la falta de datos como una verificación superada. Hay que aportarlos mediante un procedimiento fiable, no adivinarlos. [1]

La versión de PSBT describe la estructura del formato, no la cantidad de firmas ni la versión de la propia transacción Bitcoin. PSBT v0 guarda la transacción sin firmar en un campo global; si se omite la versión de PSBT, se entiende v0. PSBT v2, definido por BIP 370, excluye ese campo y distribuye la información de construcción entre campos individuales. Así permite añadir entradas y salidas respetando los cambios autorizados y las firmas existentes. No permite reescribir libremente un pago firmado. Ambas partes deben entender esa versión; ‘compatible con PSBT’ no es una descripción suficientemente precisa. [2]

BIP 371 incorpora información para Taproot, como sus firmas, scripts y orígenes de claves. Estos campos pueden usarse tanto con PSBT v0 como con PSBT v2. Por eso una cartera puede admitir Taproot en el primer formato sin admitir el segundo. Del mismo modo, admitir v2 no demuestra que un dispositivo maneje todos los casos de Taproot. Firmar por la vía de clave y gastar por una rama de script son formas distintas de cumplir las condiciones de una salida Taproot. Para el usuario, la pregunta es sencilla: ¿mi combinación concreta puede manejar el pago que quiero firmar? La respuesta está en la documentación y en un procedimiento probado, no en una sigla dentro de una lista de funciones. [3]