BBQr es un formato de transporte documentado públicamente por Coinkite. Cada QR empieza con el prefijo B$ y una cabecera breve que contiene codificación, tipo de archivo, número total de partes e índice; después sigue un segmento de datos en HEX, Base32 o Zlib fijo más Base32.
BBQr resuelve los casos en que un PSBT, una transacción firmada u otro archivo no cabe en un solo QR razonablemente legible. El emisor divide los datos en una serie de tramas y el receptor los recompone, para que el archivo cruce un air gap sin cable, tarjeta ni conexión de red. El formato no firma nada, no transmite a la red Bitcoin y no forma parte del consenso. [1]
Cada trama empieza con una cabecera de ocho caracteres. El prefijo B$ identifica BBQr, el carácter siguiente elige la codificación, el siguiente el tipo de contenido, dos posiciones base36 indican el total de tramas y las dos últimas el índice actual. B$HP0301 significa HEX, PSBT, 3 tramas en total y la parte con índice 1. Todas las tramas de una serie deben declarar la misma codificación, tipo y cantidad. [1]
El QR usa modo alfanumérico con un conjunto restringido de mayúsculas. H escribe HEX, 2 usa Base32 sin el carácter = y Z comprime primero todo el archivo con Zlib, wbits=10 y sin cabecera, y luego usa Base32. La compresión puede reducir un PSBT, pero ayuda poco con hashes, UTXO y otros datos de alta entropía; el codificador debe elegir entonces la opción sin comprimir más pequeña. [1]
Las tramas pueden leerse en cualquier orden porque la cabecera lleva su índice. Pero no es un fountain code: el receptor debe obtener las N partes y no puede reconstruir una trama ausente. La capa QR ya aporta detección y corrección de errores, por lo que la especificación no añade otro checksum de serie; el debate de diseño trató el equilibrio entre sencillez, sobrecarga y recuperación de tramas omitidas. [4]
La documentación califica BBQr como ampliamente desplegado y, a 27 de julio de 2026, verificó código público publicado en varios firmantes, monederos móviles y coordinadores, entre ellos COLDCARD Q, Sparrow Wallet, Nunchuk Desktop, BTCPay Server, Krux y BlueWallet. La compatibilidad no es necesariamente bidireccional: SeedSigner figuraba en la versión 0.8.7 solo para decodificar. [2]
Dos posiciones base36 permiten como máximo 1295 partes, es decir, ZZ. Para QR versión 40, la especificación indica 4296 caracteres alfanuméricos y un máximo teórico sin comprimir de 2 776 480 bytes en HEX o 3 470 600 bytes en Base32. Una implementación real puede imponer menos: COLDCARD Q acepta archivos de hasta 2 MiB y muestra el progreso según el número de partes. [6]
El carácter P identifica un PSBT y T una transacción Bitcoin terminada; J, C, U, B y X cubren JSON, CBOR, texto UTF-8, binario genérico y ejecutables. El tipo ayuda a elegir parser, pero no prueba que el contenido sea correcto o seguro. El monedero debe rechazar un tipo inesperado y el firmante debe mostrar por separado salidas, importes y comisión antes de firmar. [5]
La implementación debe verificarse con una prueba round-trip frente al repositorio y datos publicados: codificar el mismo archivo, mezclar las tramas, leerlas y comparar el resultado byte a byte. Hay que probar aparte una trama ausente o dañada, H, 2 y Z, el caso de una sola trama y los límites de memoria. Un PSBT real u otros datos sensibles nunca deben introducirse en un generador web público. [3]
Para obtener la imagen más completa, lee esta entrada junto con PSBT, Transacción, Hardware Wallet, Air-gapped Wallet, Multisig, Output Descriptor.
01¿Es BBQr lo mismo que SeedQR?+
No. SeedQR representa un secreto de recuperación BIP39 y debe tratarse como una clave privada. BBQr es una envoltura general para datos divididos, a menudo un PSBT o una transacción firmada. Puede llevar contenido sensible, pero su nombre no implica que contenga un seed y no cifra los datos.
02¿El traslado air-gapped mediante BBQr vuelve segura una transacción?+
No. El canal óptico elimina una vía de red o cable, pero un coordinador malicioso aún puede preparar un PSBT con una salida ajena, comisión inadecuada o entradas inesperadas. El usuario debe verificar direcciones, importes, comisión y política en un firmante fiable; después debe emitirse exactamente la transacción revisada.