Silent Payments

Si Bob publica una dirección Bitcoin normal, cualquiera puede seguir sus ingresos en un explorador. Un explorador de bloques es una aplicación para consultar transacciones y bloques de una red concreta. Dar una nueva dirección a cada persona es mejor, pero alguien debe distribuirlas. Silent Payments resuelve ese problema: Bob publica datos fijos y Alice crea con ellos una salida para cada pago, un registro del importe y de la condición para gastarlo después. El contacto público no se repite como una misma dirección receptora en la cadena. [1] [3] [9] [7]

Una dirección Silent Payments contiene una scan key pública y una spend key pública. Una clave privada es un valor numérico secreto; la clave pública correspondiente puede compartirse con otras personas. Los nombres indican sus funciones: la scan key está relacionada con localizar pagos y la spend key con gastarlos. Las claves privadas correspondientes permanecen con Bob. En mainnet, la red principal de Bitcoin, comienza por sp1 y usa Bech32m. No es una dirección Taproot normal que empiece por bc1p ni una copia de seguridad. El par público permite a un remitente compatible calcular el destino, pero no le concede permiso para gastar ni una lista de los cobros de Bob. [1] [5] [9]

Para pagar a Bob, la cartera de Alice selecciona importes recibidos anteriormente. Las referencias a esos importes forman las entradas de la nueva transacción. Para calcular el destino se utilizan las claves de las entradas que cumplen las reglas de BIP352; no todos los tipos sirven. Alice combina sus claves privadas con la scan key pública de Bob mediante ECDH. Este método criptográfico permite que ambas partes obtengan por separado el mismo secreto sin intercambiar claves privadas. A partir de ese secreto y de su vinculación a las entradas concretas, la cartera ajusta la spend key pública de Bob y obtiene la clave de la nueva salida. Vincular el cálculo a las entradas evita repetir el destino al reutilizar una clave de entrada. Si Alice utiliza RBF, es decir, sustituye una transacción sin confirmar, por ejemplo para aumentar la comisión, y cambia las entradas, la cartera debe calcular el destino de nuevo. No puede limitarse a reutilizar el resultado anterior. [1] [4]

La cartera de Bob examina transacciones aptas y calcula posibles salidas usando su scan key privada y los datos públicos de las entradas. Cuando encuentra una coincidencia, registra esa salida entre sus fondos. En la cadena es una salida Taproot sin mensaje especial de aviso. Bob no necesita estar conectado cuando Alice envía ni responderle antes, pero su cartera sí debe procesar después los datos necesarios. [1] [6]

La scan key localiza pagos; la spend key permite gastarlos junto con los datos derivados. La spend key privada puede mantenerse separada del escáner conectado. La filtración de la scan key privada por sí sola no permite gastar los fondos, pero puede revelar cobros al combinarla con información pública. Entregarla a un servidor de escaneo ajeno afecta, por tanto, a la privacidad. No se envían a ese servidor la seed ni la spend key privada. [1]

Silent Payments no necesita una transacción especial de aviso, pero los cálculos y la transferencia de datos no son gratis. El destinatario examina transacciones aptas y realiza los cálculos criptográficos descritos. En un teléfono importan la indexación, la fuente de datos y el tiempo desde el último escaneo. Una lista normal de direcciones no basta. Un nodo es un programa que verifica transacciones y bloques y se comunica con otros participantes de la red. Un nodo propio y un proveedor externo tienen exigencias y consecuencias diferentes para privacidad y disponibilidad. [1] [2] [8]

Bob puede utilizar labels, variantes de pago derivadas, por ejemplo para distintos proyectos. No necesita hacer un escaneo completamente independiente por cada variante. Sin embargo, las variantes públicas comparten scan key, por lo que un observador puede reconocer al mismo propietario. Una etiqueta ayuda a Bob a clasificar un cobro; no crea otra identidad anónima. La etiqueta especial de cambio identifica el sobrante de un pago propio. Si Bob gasta un importe recibido anteriormente que supera el pago más su comisión, el resto vuelve a su cartera. No es un reembolso de un comercio. BIP352 reserva para ello la etiqueta m = 0. La cartera siempre la busca durante la recuperación y no debe publicarla como contacto para recibir pagos de otras personas. [1] [4]

Imagina que Bob pierde el teléfono, pero conserva su copia de seguridad. La seed es el valor secreto inicial del que la cartera deriva sus claves; normalmente se respalda mediante una Seed Phrase, palabras de recuperación en un orden determinado. Esas palabras por sí solas no garantizan que cualquier aplicación encuentre los Silent Payments. Debe admitir la misma derivación de claves y saber localizar esos pagos. Guardar las labels utilizadas y la fecha de inicio de uso de la cartera facilita la recuperación. Para recuperar los fondos actuales se pueden examinar los datos necesarios de las transacciones con UTXO restantes: importes recibidos individualmente que todavía no se han gastado. Recuperar todo el historial requiere recorrer la cadena de forma más amplia. Una pantalla vacía antes de terminar el escaneo no significa necesariamente que el dinero se haya perdido. [1]

Silent Payments reduce los vínculos por reutilización de direcciones, pero no oculta importes, momento de confirmación ni historial de las entradas gastadas. Alice conoce su propio pago a Bob y un pedido puede incluir datos personales. Si Bob reúne después varias UTXO en una transacción, puede revelar su relación. Silent Payments no es CoinJoin y combinarlos no es automáticamente seguro: BIP352 advierte que falta una prueba formal para remitentes independientes que colaboran. [1] [3]

BIP352 indica como autores a josibake, Ruben Somsen y Sebastian Falbesoner; recibió su número en 2023. Al comprobarlo el 17 de octubre de 2026 tiene estado Complete. Eso no implica compatibilidad universal: hay que verificar por separado envío, recepción, escaneo y recuperación. El protocolo usa Taproot existente y no requiere un nuevo Soft Fork, es decir, un endurecimiento de las reglas de validez adoptado por la red. Las aplicaciones antiguas sin compatibilidad no pueden procesar correctamente una dirección sp1. [1] [2]