Watch-only Wallet

Alicia guarda sus claves en una cartera de hardware y quiere consultar un pago desde el móvil. Transfiere al teléfono la configuración pública de la cartera, no las palabras de respaldo. La aplicación reconoce así las direcciones correspondientes y busca sus pagos en la red. Alicia ve una entrada de 20 000 sat, las unidades más pequeñas de bitcoin, y sus confirmaciones, aunque el dispositivo de firma esté apagado en casa. El teléfono no ha adquirido permiso para gastar ese dinero. Del mismo modo, un comerciante puede facilitar a su contable una vista de los pagos sin entregarle las claves. Lo decisivo es qué se ha importado: introducir una Seed Phrase, las palabras que permiten recuperar las claves, eliminaría esa separación. [12]

Es posible añadir la dirección pública de otra persona a una aplicación de seguimiento. La cifra mostrada no demuestra que el usuario pueda gastar ese dinero, ni mucho menos pagar todas sus deudas. La aplicación suma los UTXO que encuentra: salidas de pagos anteriores que siguen sin gastarse. Solo encuentra lo que corresponde a los datos importados y al historial disponible. Las direcciones omitidas, una búsqueda incompleta o un servidor poco fiable pueden ofrecer una imagen parcial. Un cero no significa por sí solo que se hayan perdido los bitcoins; primero hay que comprobar qué se está siguiendo y de dónde proceden los datos. [8] [9]

Cuando Alicia quiere pagar, la aplicación selecciona UTXO disponibles y prepara destinatario, importe y comisión. Puede devolver a su propia cartera la parte sobrante de una entrada; es el cambio, o change. Estos datos pueden viajar en una PSBT, el formato de transacción Bitcoin parcialmente firmada definido en BIP174. El dispositivo separado recibe así lo necesario para firmar sin tener su propia base UTXO. Alicia debe verificar en su pantalla fiable el destinatario real, importe, comisión y cambio. Una aplicación comprometida podría proponer un pago distinto del que ella pretendía. También importa sighash, que determina qué partes de la transacción cubre la firma. Solo tras comprobar y firmar se difunde la transacción final, conforme a la propuesta aprobada y a las reglas de la cartera. [2] [10]

Una clave pública extendida, o xpub, permite derivar más claves públicas de una rama de la cartera; por sí sola no firma pagos. Sin embargo, quien la obtiene junto con las reglas de la cartera puede relacionar las direcciones alcanzables, pagos pasados y futuros y saldos. Eso revela mucho más que una dirección para un único ingreso. Un servidor ajeno puede obtener una imagen parecida a partir de consultas repetidas. Un Full Node propio, que verifica la cadena, limita esa exposición; una conexión cifrada o privada no oculta las consultas al servidor de destino. Exporte solo la cuenta necesaria, limite las copias y proteja las etiquetas que relacionan direcciones con nombres o motivos de pago. [1] [13] [14]

Las secciones siguientes sirven como referencia técnica para configurar y recuperar la cartera. Un script establece las condiciones de gasto; un Output Descriptor recoge esas reglas y los datos para derivar direcciones. Una HD Wallet crea un árbol de claves a partir de un seed: los datos secretos de partida para derivarlas. La derivación non-hardened permite generar más claves públicas desde un xpub; la hardened necesita una clave privada. Multisig añade un número establecido de firmas necesarias. Importar una dirección permite observar su script, no futuras direcciones de recepción ni de cambio. Una clave pública cubre distintos tipos de script solo si el programa los deriva explícitamente. Un xpub de cuenta deriva descendientes non-hardened, pero no define P2PKH, SegWit, Taproot, la rama interna ni el umbral de firmas Multisig. El descriptor aporta ese contexto. Expórtelo desde la cuenta correcta del dispositivo firmante, con la red y el tipo de script adecuados; no adivine la ruta de derivación, la secuencia de pasos desde la clave de partida. [1] [4] [7]

Las carteras HD suelen separar la rama de recepción /0/* de la interna /1/* para el change, el importe devuelto al gastar. Sin la rama interna, parte del dinero puede parecer desaparecida después del gasto. Un range pequeño, es decir, un intervalo reducido de direcciones derivadas, puede ocultar ingresos. next_index determina la siguiente dirección que se genera; si dos programas no lo coordinan, pueden reutilizar direcciones. Mantenga alineados los descriptores activos, rangos e índices. Compruebe la dirección de recepción en la pantalla del firmante: un programa malicioso puede sustituirla aunque muestre un saldo creíble. [6] [9]

En Bitcoin Core, importdescriptors utiliza timestamp para fijar el inicio de una nueva búsqueda. now omite el historial anterior; 0 solicita buscar desde el Genesis Block. También importan el intervalo range y la disponibilidad de bloques antiguos. active indica si el descriptor se utiliza para generar nuevas direcciones; internal identifica salidas internas de la cartera, como el cambio. Un nodo podado, que ha borrado bloques antiguos para ahorrar espacio, puede no conservar los necesarios. Un rescan solo descubre transacciones existentes. Guarde la fecha o altura del primer uso y contraste la restauración con direcciones y transacciones conocidas, no solo con un cero en pantalla. [9] [10]

BIP380 define un lenguaje para conjuntos de scripts de salida. El ejemplo wpkh([d34db33f/84h/0h/0h]xpub…/0/*)#checksum incluye tipo de script, huella de la clave maestra, ruta de origen, clave pública de cuenta, rama, índice variable y suma de comprobación. No es un dato válido para importar. Taproot utiliza tr() según BIP386; BIP389 admite varias rutas en una expresión. La suma detecta errores de copia, no autentica al autor. Un descriptor con xprv contiene una clave secreta y no debe introducirse en un coordinador de observación. [4] [5] [6] [7]

BIP32 describe una excepción importante: el xpub de un padre junto con la clave privada de un descendiente derivado exclusivamente por pasos non-hardened permite calcular la clave privada del padre. El xpub solo no basta; la combinación es peligrosa. Un paso hardened por encima de la cuenta exportada impide que el ataque cruce esa frontera. Nunca introduzca xprv, seed o claves privadas en la cartera de observación, su base de datos o los archivos PSBT que la acompañan. [1]

Observar una cartera Multisig exige el umbral de firmas, el tipo de script, el xpub de cada cofirmante, el origen y orden de las claves y ambas ramas de direcciones. Un solo xpub no basta. Perder el descriptor puede complicar la recuperación aunque los seeds estén intactos; otro orden o envoltorio de script puede generar direcciones distintas. Verifique las reglas y una dirección de ejemplo en todos los firmantes. Guarde un descriptor con suma de comprobación o una configuración estándar, teniendo en cuenta que revela relaciones entre cofirmantes. [4] [11]

Guarde por separado de las claves privadas los descriptores de ambas ramas, orígenes, red, fecha o altura de creación, rangos, índices, etiquetas y reglas Multisig. BIP329 transporta etiquetas; no sustituye el descriptor ni el historial. Pruebe la recuperación en un perfil separado o una red de pruebas: importe la configuración pública, busque en la cadena, compare direcciones antiguas de ambas ramas y UTXO esperados, prepare una PSBT y fírmela con el dispositivo previsto. Compruebe el resultado antes de difundirlo. Watch-only permite observar y preparar, pero no concede autoridad para gastar. [3] [9] [12]