Un buzón metálico cerrado con una única ranura y una moneda de Bitcoin dorada en el frontal, con varias cartas de distintos tamaños entrando en silencio, sobre un fondo oscuro con ondas desenfocadas en naranja y azul
Ilustración propia generada con IA (FLUX.1-schnell, local) — no representa datos reales.

Silent Payments: la dirección de Bitcoin que puedes publicar sin reutilizarla nunca, y lo que cuesta recibir con ella

Equipo NodeWitness 9 min de lectura

BIP-352 define una dirección estática, con prefijo sp1, que puedes publicar en una web o un perfil para siempre: cada pago que recibas aterriza en una dirección Taproot distinta que solo tú sabes que es tuya. A cambio, tienes que escanear la cadena para encontrar tus propios pagos, y ese coste decide quién puede usarlo con comodidad hoy.

Silent Payments es un protocolo, definido en BIP-352 [1], que elimina la reutilización de direcciones del lado del receptor sin que emisor y receptor tengan que hablar entre sí. La dirección que publicas empieza por sp1 y nunca aparece escrita en la cadena; lo que aparece es una dirección Taproot corriente, distinta en cada pago, que el emisor calcula por su cuenta. El BIP figura con estado "Complete": la versión 1.0.0 es del 8 de mayo de 2024 y la vigente, 1.1.1, del 16 de abril de 2026.

El problema que hereda: publicar una dirección es publicar el vínculo

Ya explicamos por qué reutilizar una dirección es el fallo de privacidad más repetido, y cómo encaja dentro de la pregunta general de si tu wallet es rastreable. Lo que Silent Payments no toca, la consolidación tóxica de entradas, también tiene su propio artículo.

El caso que ninguna wallet resuelve por sí sola es la dirección que tienes que publicar: una web de donaciones, un perfil de Nostr o una factura recurrente necesitan algo fijo que el pagador copie sin pedírtelo. Y en cuanto ese algo fijo es una dirección normal, cada donante queda unido a todos los demás y al total recaudado.

Las dos soluciones anteriores tenían un coste que las dejó fuera de ese caso. Compartir un xpub le entrega al pagador, como recuerda el propio texto de BIP-352, todas tus direcciones futuras, no solo la suya. Y los códigos de pago de BIP-47 [2] exigen una transacción de notificación en cadena antes del primer pago — un output a tu dirección de notificación más 80 bytes en un OP_RETURN — que cuesta comisión y deja una huella que el propio BIP-47 reconoce como fuga potencial de la relación entre las dos partes. Para una donación puntual no tiene sentido.

Cómo funciona, sin fórmulas

La dirección sp1 codifica dos claves públicas tuyas: una de escaneo y una de gasto. Cuando alguien te paga, su wallet toma las claves privadas de las entradas que va a gastar y, junto con tu clave de escaneo, calcula un secreto compartido mediante un intercambio de claves de curva elíptica (ECDH). Con ese secreto ajusta tu clave de gasto y obtiene una dirección Taproot nueva, que escribe en la salida. Como las entradas de cada transacción son distintas, el resultado cambia en cada pago aunque te pague cien veces la misma wallet; un hash del punto de gasto más pequeño de la transacción garantiza que dos pagos con la misma clave de entrada tampoco coincidan.

Las salidas Taproot son SegWit versión 1. Qué parte de las transacciones usa ya SegWit, sin separar Taproot, lo seguimos ajuste a ajuste en la gráfica de adopción de SegWit [19].

Tú puedes rehacer el mismo cálculo desde el otro lado, porque conoces tu clave privada de escaneo y ves en la cadena las claves públicas de las entradas. Eso es todo lo que hace el escaneo: recorrer cada transacción con al menos una salida Taproot y una entrada elegible (P2TR, P2WPKH, P2SH-P2WPKH o P2PKH; las multifirma quedan fuera por diseño), calcular el secreto y comprobar si alguna salida coincide.

Diagrama del flujo de un Silent Payment: la dirección estática sp1 arriba, que nunca aparece en la cadena; el emisor deriva con sus claves de entrada una dirección Taproot única por pago; el receptor escanea cada bloque para encontrar las suyas
Diagrama propio: tres pagos a la misma dirección sp1 producen tres direcciones Taproot distintas en la cadena. La dirección sp1 no se escribe nunca; el receptor las encuentra escaneando.

El coste honesto: alguien tiene que escanear

El propio BIP-352 lo dice sin rodeos: los beneficios "vienen al coste de exigir a las wallets escanear la cadena para detectar pagos", algo "generalmente viable para nodos completos" que "plantea un desafío para clientes ligeros". Un nodo completo ya tiene todas las transacciones en disco; escanearlas es trabajo de CPU. Un móvil no tiene nada de eso.

Para el móvil existen dos caminos, y ninguno es gratis. El primero es descargar de un servidor los datos mínimos para escanear tú mismo: por cada transacción elegible basta una clave pública sumada de 33 bytes, más filtros de bloque compactos (BIP-158) para saltarse bloques vacíos. El apéndice de BIP-352 estima ese tráfico en 30-50 MB al mes con el uso actual de Taproot, y en unos 450 MB al mes si toda la red usara Taproot; la misma sección observa que alrededor del 75 % de las transacciones con salidas Taproot las gastan del todo en 150 bloques o menos, así que quien escanea cada pocos días se ahorra buena parte del trabajo.

El segundo camino es entregar la clave de escaneo al servidor para que escanee él. Es lo que hace Frigate [3], el servidor Electrum que Sparrow selecciona automáticamente para recibir: el cliente envía su clave privada de escaneo, el servidor la mantiene solo en memoria durante la sesión y devuelve las transacciones del cliente. La clave de escaneo no permite gastar nada, eso sí, pero quien opera ese servidor sabe qué transacciones son tuyas mientras estás conectado. Su README lo justifica con el fallo del primer camino: escanear un periodo razonable exige "gigabytes de tweaks, filtros y bloques" en el cliente.

Para nosotros esto no es una limitación abstracta: operamos Bitcoin Core completo y sin pruning — la misma condición que nos permite calcular HODL waves desde el UTXO set — y Frigate publica instrucciones para alojarlo uno mismo. Quien tiene un nodo completo puede hacer que el "escaneo remoto" ocurra en su propia máquina, y la clave de escaneo no sale de casa. Es una ventaja para quien ya paga el coste de un nodo, no algo que el protocolo regale a todo el mundo.

Estado del soporte a 8 de octubre de 2026, con fuente

Cada línea sale de las notas de versión o del repositorio de cada proyecto. Si algo cambia después de esa fecha, manda la fuente enlazada.

  • Cake Wallet envía y recibe desde la v4.18.0, del 29 de mayo de 2024 [4]. Según su documentación [5], el escaneo se activa a mano, corre en el dispositivo contra un servidor Electrum con índice de tweaks (el suyo, si el del usuario no lo ofrece) y consume tiempo, batería y datos.
  • Sparrow envía desde la 2.3.0, del 3 de octubre de 2025 [6], y recibe desde la 2.5.0, del 21 de mayo de 2026 [7], incluidos firmantes por aire; la recepción exige un servidor Electrum compatible, y la nota de versión añade uno público que se selecciona solo cuando hace falta.
  • BlueWallet envía desde la v6.6.7, del 25 de junio de 2024 [8] ("ADD: send to SilentPayment address"). No recibe: la petición en su repositorio (#7432 [9]) sigue abierta desde diciembre de 2024 sin respuesta de los mantenedores, y su propia librería marca la recepción como pendiente.
  • Silentium envía y recibe como aplicación web móvil; su repositorio [10] la describe como "un proyecto experimental que actúa como prueba de concepto". No es para fondos que importen.
  • Bitcoin Core: sin soporte de wallet en ninguna versión publicada. La pieza criptográfica sí existe: el módulo silentpayments se fusionó en libsecp256k1 el 22 de julio de 2026 [11], salió en su versión 0.8.0 el 3 de agosto y Core actualizó su copia de la librería el 9 de septiembre. De las tres PR de wallet, la del protocolo base (#35301 [12]) se fusionó en la rama principal el 23 de septiembre de 2026, después de que la 32.0 se separara para sus candidatas, así que no llega en esa versión; las de envío (#35302 [13]) y recepción (#32966 [14]) siguen abiertas. La del índice para clientes ligeros (#28241 [15]) se cerró sin fusionar, y ni las notas de versión de Core 30.0, 31.0 y 31.1 ni el borrador de notas de la 32.0 [16] mencionan Silent Payments. Seguimiento: issue #28536 [17].

La lista comunitaria de silentpayments.xyz [18] añade BitBox, Nunchuk y Wasabi como solo envío, y BlindBit y Dana como envío y recepción. No las hemos verificado contra sus notas de versión: referencia secundaria, no dato propio.

Qué resuelve y qué no

Problema Silent Payments Por qué
Reutilización de la dirección publicada Sí lo resuelve Cada pago va a una Taproot distinta; la sp1 nunca aparece en cadena
Donantes vinculados por compartir destino Sí lo resuelve Nada en la cadena une dos pagos a la misma sp1
Notificación en cadena antes de pagar (BIP-47) Sí lo elimina El emisor calcula la dirección con lo que ya tiene
Importes visibles No Las cantidades siguen siendo públicas
Heurística de entrada común del emisor No Las entradas del pagador siguen siendo suyas a ojos de todos
Consolidar tus recepciones después No Juntar salidas en una transacción las une igual que siempre
Anonimato de quién paga No No es un mixer ni un coinjoin

Silent Payments arregla un problema concreto, el del receptor que publica algo fijo, y lo arregla del todo. Todo lo demás sigue donde estaba. Si recibes diez donaciones en diez direcciones y las gastas juntas, la heurística de entrada común las vuelve a unir en un mismo dueño; el protocolo no te protege de tus propias transacciones posteriores. Y el pagador no gana anonimato: quien tenga sus entradas etiquetadas sabrá quién pagó, aunque no a quién.

Un matiz más: las etiquetas del protocolo comparten la misma clave de escaneo, así que quien conozca tu sp1 las reconoce como tuyas; el BIP avisa de que no sirven para gestionar identidades separadas.

Fuentes

Entre paréntesis, el tipo de fuente.

  1. Bitcoin BIPs, BIP-352. (Primaria, especificación)
  2. Bitcoin BIPs, BIP-47. (Primaria, especificación)
  3. Sparrow Wallet, Frigate. (Primaria, repositorio del proyecto)
  4. Cake Wallet, v4.18.0, del 29 de mayo de 2024. (Primaria, repositorio del proyecto)
  5. Cake Wallet, documentación. (Primaria, documentación del fabricante)
  6. Sparrow Wallet, 2.3.0, del 3 de octubre de 2025. (Primaria, repositorio del proyecto)
  7. Sparrow Wallet, 2.5.0, del 21 de mayo de 2026. (Primaria, repositorio del proyecto)
  8. BlueWallet, v6.6.7, del 25 de junio de 2024. (Primaria, repositorio del proyecto)
  9. BlueWallet, #7432. (Primaria, repositorio del proyecto)
  10. Silentium (louisinger), repositorio. (Primaria, repositorio del proyecto)
  11. Bitcoin Core, 22 de julio de 2026. (Primaria, repositorio oficial)
  12. Bitcoin Core, #35301. (Primaria, repositorio oficial)
  13. Bitcoin Core, #35302. (Primaria, repositorio oficial)
  14. Bitcoin Core, #32966. (Primaria, repositorio oficial)
  15. Bitcoin Core, #28241. (Primaria, repositorio oficial)
  16. Bitcoin Core, borrador de notas de la 32.0. (Primaria, repositorio oficial)
  17. Bitcoin Core, issue #28536. (Primaria, repositorio oficial)
  18. silentpayments.xyz, silentpayments.xyz. (Secundaria, web divulgativa)
  19. NodeWitness, datos propios, consultables en gráfica de adopción de SegWit. (Primaria, dato propio)

Antes de pensar en una dirección sp1, comprueba si el problema ya lo tienes: pega una dirección tuya en la auditoría de privacidad y verás si ha recibido pagos repetidos del mismo origen, con la fórmula de cada penalización a la vista y sin que te pidamos ninguna clave.

Más en Privacidad y autocustodia

Ver los 16 artículos de Privacidad y autocustodia →

Última actualización: 15 de octubre de 2026