Silent Payments en Bitcoin: guía práctica (2026)

Una nota sobre la financiación: CypherpunkGuide no lleva publicidad de vigilancia. Nada de redes publicitarias, píxeles de seguimiento ni contenido patrocinado. Nos sostienen vías transparentes: hoy, las donaciones; más adelante, una suscripción y afiliación alineada con nuestra línea editorial. Respondemos ante nuestras lectoras y lectores, no ante los anunciantes.

Recibir bitcoin encierra una contradicción pequeña y silenciosa. Todas las guías repiten lo mismo: nunca reutilices una dirección, porque la reutilización es una de las señales más limpias que tiene quien analiza la cadena. Pero en cuanto quieres que te paguen —un bote de propinas en una bio, una línea de donaciones en un README, una factura que envías una vez y olvidas— necesitas una dirección que se quede quieta. Rotar direcciones y mantener una identidad fija tiran en direcciones opuestas.

Los Silent Payments (BIP-352) son el protocolo que lo resuelve: publicas una dirección y cada persona que te paga deriva de ella una dirección on-chain distinta, de modo que quien vigila la cadena solo ve salidas inconexas, sin un destino compartido. Es uno de los mayores avances en privacidad de recepción de los últimos años. También es de los más malentendidos: llega a medias a cada wallet y arrastra un coste real que los artículos entusiastas suelen pasar por alto.

Escribo bajo seudónimo y doy por vigilada cada moneda que tengo, así que no quise creerme el protocolo por fe. Antes de escribir una sola línea de esta guía, programé una implementación de BIP-352 desde cero en Python —con libsecp256k1 a través de la librería coincurve— y la ejecuté contra los vectores de prueba oficiales de la especificación: los 28 sub-casos de envío y los 29 de recepción coincidieron, bit a bit, en menos de 200 milisegundos (registro adjunto). Lo que sigue es la versión que funciona de verdad: qué protege, qué wallets lo ofrecen en 2026 y el coste de escaneo que conviene entender antes de confiar en él.

Qué es de verdad un Silent Payment (y qué no protege)

#

Un Silent Payment es una dirección de Bitcoin reutilizable, definida en BIP-352: publicas una sola cadena de texto una vez y, a partir de ahí, quien te paga deriva para ti una dirección on-chain única e imposible de vincular. Protege el vínculo de recepción —la conexión entre pagos distintos hacia una misma identidad— y nada más. No oculta los importes, no protege a quien te paga y no hace nada frente a los registros fuera de la cadena que atan tus monedas a tu nombre.

La dirección son dos claves públicas codificadas juntas: una scan key y una spend key. En mainnet empieza por sp1; en una red de pruebas, por tsp1 (el prefijo legible es sp / tsp, y ese 1 no es más que el separador de bech32m). Cuando alguien te paga, su wallet combina sus propias claves de entrada con tu scan key para calcular un secreto compartido y, a partir de ahí, deriva una salida Taproot nueva que solo tú puedes detectar y gastar. No hay dos pagadores que generen la misma salida, y no existe ninguna «transacción de notificación» que delate el vínculo: esa es la mejora clave frente al viejo enfoque de códigos de pago de BIP-47.

Conviene decir sin rodeos qué deja al descubierto, porque la palabra «privado» carga aquí con más peso del que merece. Los Silent Payments sirven para recibir. El importe que recibes sigue a la vista en la cadena. La privacidad de quien te paga es asunto suyo, no tuyo. Y el ataque más fuerte contra un seudónimo estable casi nunca es la cadena: es lo que escribes, los metadatos, el exchange con KYC donde una moneda se cruza con un pasaporte. Ese es el modelo aditivo que desgloso en cómo funciona de verdad el rastreo on-chain y, fuera de la cadena, en la desanonimización con IA. Los Silent Payments cierran una brecha concreta y valiosa. Son necesarios, no suficientes.

Qué wallets admiten Silent Payments en 2026

#

El soporte es real pero desigual, y lo más útil es comprobar por separado enviar y recibir: llegaron en momentos distintos, a wallets distintas, a veces con años de diferencia. Enviar a una dirección Silent Payment ya es lo habitual; poder recibir en una, algo que obliga a la wallet a escanear la cadena, es más reciente y más raro. La tabla de abajo recoge fuentes primarias a fecha de 2026-07-09; contrasta las notas de versión de cada proyecto antes de mover dinero de verdad, porque esta lista cambia.

Dos advertencias que la tabla comprime. La primera: «recibir» es la columna que importa y la que va por detrás; una wallet puede dejarte pagar a la dirección sp1 de un amigo mucho antes de poder ofrecerte una propia para recibir. La segunda: cómo escanea una wallet es una decisión de privacidad, no solo de rendimiento, y es el tema de las dos secciones siguientes. Para conseguir de entrada las monedas que vas a recibir por esta vía, sin sembrar el vínculo de identidad en el exchange, mira cómo comprar Bitcoin sin KYC.

Enviar: la mitad fácil

#

Enviar a una dirección Silent Payment es la mitad sencilla del protocolo, porque quien paga hace todo el trabajo en su propio equipo y no tiene que escanear nada. En una wallet compatible —Sparrow es la referencia en escritorio— pegas la dirección sp1… del destinatario en el campo de envío igual que cualquier otra, y la wallet hace la derivación sin que la veas.

Por dentro, tu wallet toma las claves privadas de las entradas que va a gastar, las combina con la scan key del destinatario para calcular un secreto compartido y usa ese secreto para derivar una dirección de salida Taproot de un solo uso para este pago concreto. Como la derivación incorpora tus entradas, la misma dirección del destinatario produce una salida on-chain distinta cada vez que la paga otra persona —o un conjunto distinto de tus monedas—. Quien envía no necesita nada del destinatario más allá de la dirección publicada: ni ida y vuelta, ni aviso, ni interacción. Por eso el soporte para enviar llegó primero y hoy es lo normal. Esa asimetría es toda la historia de la sección siguiente: el coste que enviar se ahorra es justo el coste que recibir no puede esquivar.

Recibir: el coste de escaneo del que nadie te avisa

#

Para recibir Silent Payments, tu wallet tiene que examinar las salidas candidatas de toda la cadena de bloques y probar cada una contra tus claves para dar con los pagos que son para ti: no hay ninguna dirección en la cadena que puedas simplemente «buscar». Ese coste de escaneo es el compromiso central y poco contado de BIP-352, y la forma en que tu wallet lo resuelve decide a la vez tu comodidad y tu privacidad. Publicar la dirección es gratis. Encontrar lo que te enviaron a ella, no.

Si corres tu propio nodo completo, el escaneo es un cálculo local sobre los datos de los bloques: exigente, pero privado, porque nada sale de tu máquina. La fricción aparece cuando quieres recibir en un móvil o un portátil sin nodo. Ahí entra un servidor indexador. En Sparrow, ese servidor es Frigate (un servidor Electrum para Silent Payments, en su última versión v1.5.3), y existe una instancia pública en frigate.2140.dev. No lo «visitas» en un navegador: habla el protocolo Electrum, no HTTP. En Sparrow lo eliges en Preferences → Server → Public Server y luego pruebas la conexión.

Aquí está la parte que los tutoriales optimistas se saltan, y es una cuestión de privacidad, no una nota al pie. Para dejar que un servidor escanee por ti, tu wallet le entrega tu scan private key y tu spend public key. Aunque el servidor —tal como está diseñado Frigate— solo guarde esas claves en memoria, un indexador malicioso o comprometido puede usarlas para reconstruir justo la imagen que los Silent Payments deberían negarle a un observador: la lista completa de los pagos que has recibido. La guía práctica de bennet.org lo dice sin rodeos: un servidor malicioso «podría construir exactamente la imagen de tu historial de recepción que los Silent Payments deberían impedir». Así que, para ser honestos, esto es un espectro: tu propio nodo es totalmente privado y da más trabajo; un indexador público es cómodo y te pide confiar tu historial de recepción a quien lo opera. Elige a conciencia, y no dejes que «uso Silent Payments» se convierta en una falsa sensación de seguridad cuando quien hace tu escaneo es el servidor de un desconocido.

Reproduje BIP-352 a mano

#

Para confiar de verdad en un protocolo de privacidad, lo más rápido es hacerlo funcionar y contrastarlo con las cifras de la propia especificación: eso es justo lo que hice, en vez de creerme las afirmaciones por fe. Mi implementación desde cero reproduce con exactitud los 57 sub-casos de los vectores de prueba oficiales —28/28 al enviar, 29/29 al recibir— y el registro completo junto con los scripts se publican con este artículo (bip352-verification.txt), así que puedes reproducirlos por tu cuenta. Pero más útil que la cuenta de aciertos es ver cómo se deriva un solo pago, paso a paso.

Toma una dirección publicada y sigue lo que calcula quien paga. Los valores de abajo son reales, salidos de los propios vectores de prueba de la especificación:

Y ahora viene la propiedad que hace que todo esto merezca la pena. Construí yo misma un segundo pagador independiente —otro material de claves, una moneda distinta a efectos del ejemplo— que paga a la misma dirección publicada (aquí no se emite ninguna transacción; como en la traza de arriba, esto es pura derivación). Su salida fue 3f1dd702…879b98ad. Dos pagos, una sola dirección y, en la cadena, las dos salidas no comparten nada: ni dirección común ni vínculo visible. Solo quien tiene la scan key puede hacer el cálculo inverso y reconocer ambas como suyas. Esa es la garantía de privacidad al recibir, y puedes comprobarla en la traza en vez de aceptarla como una afirmación. Es la contraparte on-chain del problema de reutilización que disecciono en privacidad on-chain de Bitcoin: el mismo agrupamiento que la reutilización le regala a un analista es justo lo que esta derivación le niega.

Los escollos: multisig, etiquetas y el límite K_max

#

Más allá del coste de escaneo, tres detalles de implementación deciden si los Silent Payments encajan en tu configuración, y cada uno conviene aprenderlo antes de depender de ellos, no después. Son los rincones que los tutoriales de «cómo funciona» rara vez pisan.

• Multisig y transacciones colaborativas se llevan mal con esto. Como quien paga deriva el pago a partir de las claves privadas de las entradas que gasta, enviar desde una wallet multifirma o desde un CoinJoin —donde las claves de firma están repartidas entre partes que no deben juntarlas sin más— no encaja limpiamente con BIP-352. Los Silent Payments resuelven el vínculo de reutilización, no el problema de la mezcla; si quieres privacidad de importes y de grafo, eso sigue siendo terreno de las transacciones colaborativas, que trato en privacidad on-chain. Trátalos como complementarios, no como intercambiables.
• Las etiquetas son comodidad con una asimetría. BIP-352 permite a quien recibe derivar variantes etiquetadas de una misma dirección, útiles para distinguir qué salidas vinieron de qué fuente. Esa información de etiqueta solo tiene sentido para ti, que la posees; no queda expuesta en la cadena. Pero es un registro que llevas tú, y por tanto un registro que una wallet o una copia de seguridad comprometidas pueden filtrar. Comodidad, contada con honestidad.
• Hay un límite de destinatarios, K_max = 2323. La especificación (v1.1.0, marzo de 2026; versión actual v1.1.1, abril de 2026) topa cuántas salidas puede derivar un mismo grupo, como defensa frente a transacciones diseñadas para disparar el trabajo de escaneo de quien recibe. Como particular no lo alcanzarás nunca, pero es la razón por la que un ingenuo «paga 3.000 salidas a una dirección» falla por diseño, y te dice que los autores del protocolo se tomaron en serio el ataque por coste de escaneo.

Un apunte de realidad relacionado, sobre los clientes ligeros, porque es donde la gente espera que el problema del escaneo ya esté resuelto: a mediados de 2026 no existe ni una sola herramienta de cliente ligero lista para producción y con confianza minimizada que puedas instalar sin más. El demonio de wallet blindbitd fue archivado en agosto de 2025; solo se mantiene activo su indexador acompañante, blindbit-oracle, y la especificación del cliente ligero sigue en desarrollo. Existen librerías experimentales como bdk-sp, pero sus propios autores desaconsejan usarlas en mainnet. Si una guía da a entender que recibir Silent Payments desde el móvil es una experiencia resuelta y sin contrapartidas, va por delante del software.

En conclusión: ¿deberías usar ya los Silent Payments?

#

Los Silent Payments están listos para una tarea concreta y valiosa —una dirección pública y reutilizable para recibir que no filtra el vínculo de reutilización— y todavía no para ser tu única herramienta de privacidad ni una opción móvil sin fricción. Ajusta la herramienta a la tarea, y corre tu propio nodo si tu historial de recepción es sensible. El objetivo honesto aquí es más privacidad al recibir, no el anonimato.

Sea cual sea tu caso, la secuencia es la de siempre: ponle nombre al adversario, arregla primero los eslabones baratos e irreversibles —comprar sin KYC donde sea legal, cuidar tus monedas, no reutilizar jamás una dirección normal— y suma Silent Payments allí donde cierran la brecha concreta de una dirección publicada que quieres mantener imposible de vincular. Es un avance de verdad. También es una herramienta para recibir con una factura de escaneo, y saber quién paga esa factura —tú, o un servidor en el que confías— es lo que separa la privacidad de su mera sensación.

Preguntas frecuentes

#

¿Qué es una dirección de Silent Payment?

#

Una dirección de Silent Payment es una dirección de Bitcoin reutilizable, definida en BIP-352, que puedes publicar una sola vez; en mainnet empieza por sp1. A diferencia de una dirección normal, cada pagador deriva de ella una dirección on-chain distinta y de un solo uso, así que los pagos que recibes no comparten un destino que se pueda vincular. Codifica dos claves públicas (una scan key y una spend key) en lugar de un único script.

¿Los Silent Payments ocultan el importe que recibo?

#

No. Los Silent Payments protegen el vínculo de recepción —la conexión entre pagos distintos hacia una misma identidad— y nada más. El importe de cada pago sigue quedando registrado en la cadena de bloques pública, la privacidad de quien te paga no cambia y los registros fuera de la cadena (como los de un exchange con KYC) quedan intactos. Para la privacidad de importes, las herramientas que valen son Lightning o las transacciones colaborativas.

¿Qué wallets admiten Silent Payments en 2026?

#

A fecha de 2026-07-09, Sparrow admite tanto enviar (desde la v2.3.0, octubre de 2025) como recibir (desde la v2.5.0, mayo de 2026); Cake Wallet admite ambas con escaneo en el propio dispositivo (desde la v4.18.0, finales de mayo de 2024). El soporte a nivel de wallet de Bitcoin Core aún no está fusionado, aunque el módulo criptográfico de base sí lo está. Comprueba siempre por separado el soporte para enviar y para recibir, y contrástalo con las notas de versión actuales.

¿Por qué recibir un Silent Payment es lento?

#

Porque no hay ninguna dirección en la cadena que buscar. Para dar con los pagos que te enviaron, tu wallet tiene que escanear las salidas candidatas a lo largo de los bloques y probar cada una contra tus claves. En tu propio nodo es un cálculo local y privado; sin nodo, dependes de un servidor indexador, que es más rápido pero añade un compromiso de confianza. Las herramientas de cliente ligero que eliminan a la vez el coste y la confianza siguen en desarrollo.

¿Siguen siendo privados los Silent Payments si uso un servidor público?

#

Solo en parte. Para escanear en tu nombre, un indexador público recibe tu scan private key y tu spend public key. Aunque solo las guarde en memoria, esas claves permiten a un servidor malicioso o comprometido reconstruir el historial completo de los pagos que has recibido, justo lo que los Silent Payments deberían impedirle a un observador de la cadena. Correr tu propio nodo lo evita; un servidor público cambia esa privacidad por comodidad.

Aquí se cruzan tres hilos de este sitio. Los Silent Payments responden a la mitad de recepción del problema de reutilización que disecciono en Privacidad on-chain de Bitcoin: cómo funciona el rastreo; léelo para ver qué capta el agrupamiento y qué se le escapa. Como la dirección es tan privada como las monedas que recibes en ella, acompaña esta lectura con Comprar Bitcoin sin KYC, que arregla el ancla de identidad aguas arriba. Y como la cadena nunca es toda la amenaza, La desanonimización con IA cubre la inferencia fuera de la cadena que corre en paralelo a todo esto.