Silent Payments: el siguiente salto evolutivo para las billeteras de Bitcoin
Craig Raw (
https://t.me/craigraw) — 1 de abril de 2026 — Hilo traducido al castellano
---
▎ Silent payments no es solo un nuevo enfoque para códigos de pago estáticos. Es el primer candidato serio para mejorar el sistema de derivación de direcciones desde las billeteras HD en 2013. Las billeteras HD fueron un gran avance sobre las claves únicas, y silent payments podría ser un salto similar.
---
1. ¿Por qué silent payments?
La primera razón son, por supuesto, los códigos de pago estáticos, que con BIP353 se ven como http://₿
[email protected]/. Un sistema de pago que requiere una interacción de ida y vuelta para cada nuevo pago con tal de mantener la privacidad del receptor es arcaico, así que esto lleva mucho tiempo pendiente.
Quizás más importante es el corolario: se elimina la reutilización de direcciones. Dado que cada dirección se calcula usando los inputs de la transacción —que solo pueden gastarse una vez— cada dirección está garantizada como única, resolviendo el problema de privacidad original del whitepaper.
Y como bonus, se elimina también el gap limit. El gap limit es cuántas direcciones hacia adelante revisan las billeteras HD buscando transacciones, y es la razón por la que restaurar una billetera puede perder transacciones si se generaron demasiadas direcciones sin recibir pagos.
---
2. El problema: escanear es demasiado costoso
Con estas ventajas, cabe preguntarse por qué silent payments no es ya el tipo de billetera por defecto. La razón está en un defecto aparentemente fatal: escanear transacciones recibidas requiere un cómputo significativo sobre cada transacción que pueda contener un output de silent payments.
De forma ingenua, esto significa descargar cada bloque y realizar miles de cálculos solo para ver si tiene algún output para tu billetera. Esto es increíblemente costoso e inmediatamente inviable.
El BIP de silent payments sugirió una mejora: reducir la información necesaria de cada bloque a una sola clave pública por transacción. Fue un gran paso adelante, reduciendo cada bloque a unos 50–100 kilobytes de datos.
Pero no es suficiente. Ponerse al día con unos meses lleva una hora, cuando en móvil debe ocurrir en pocos segundos. Los usuarios se rinden rápido, e iOS limita severamente el cómputo en segundo plano. En la práctica, la experiencia en billeteras móviles es inutilizable.
Además, descargar megabytes de datos para escanear una billetera es demasiado caro para muchos usuarios móviles. Y la mayoría de los teléfonos no tienen ni de lejos suficiente capacidad de cómputo para intentar el escaneo en un tiempo razonable.
---
3. La solución: Frigate
Craig Raw decidió probar un enfoque diferente: Frigate, un servidor Electrum experimental para el escaneo de silent payments. Al mover la carga del escaneo al servidor, se sacrifica algo de privacidad. Pero mientras los datos del cliente se mantengan efímeros (no guardados en disco), la privacidad es similar a la de los servidores Electrum para billeteras HD.
---
4. Optimización progresiva del rendimiento
Paso 1 — Base de datos personalizada. La forma más rápida de realizar el cómputo es meter los datos en una base de datos y crear una función personalizada para ejecutar el cómputo dentro de ella, evitando copiar los datos hacia fuera en cada escaneo. Resultado: el escaneo de unos meses pasó de una hora a un minuto. Prometedor, pero la CPU quedaba saturada.
Paso 2 — Cómputo en GPU. Como cada transacción puede escanearse de forma independiente, es posible un pipeline altamente paralelo. El cómputo en GPU,
implementado como función de base de datos, redujo el escaneo a unos pocos segundos. La CPU quedó libre para otras tareas. Sin embargo, requería hardware potente y seguía siendo apenas viable para un servidor público.
