Los pagos silenciosos de Bitcoin pueden permitir el uso de una dirección reutilizable sin dejar en la cadena un rastro evidente de todas las operaciones recibidas en ella. Las primeras mediciones sobre su funcionamiento en móviles apuntan a que el consumo de datos sería asumible, aunque introducen un problema distinto: un monedero ligero puede dejar de mostrar un ingreso si el servidor que le proporciona la información omite una parte del historial.
Unos 8 MB diarios para seguir la cadena
El protocolo, definido en la propuesta BIP-352, permite que el emisor utilice la información pública del receptor para derivar una nueva dirección de destino Taproot en cada operación. Después, el monedero del receptor debe revisar las transacciones elegibles y comprobar cuál de sus salidas le pertenece.
Ese proceso de búsqueda es especialmente exigente para los teléfonos. Un proyecto de medición publicado en septiembre calcula que una cartera que siga la cadena en la parte más reciente del conjunto analizado necesitaría descargar alrededor de 8,0 MB al día mediante la fuente de datos completa de BlindBit Oracle v2. La estimación parte de 144 bloques diarios y de la media registrada entre las alturas 900.000 y 965.089.
El dato no representa la descarga inicial de todo el historial. El proyecto procesó 255.434 bloques, desde el 709.656 hasta el 965.089, un periodo que va poco después de la activación de Taproot hasta septiembre de 2026. En ese intervalo, la carga completa de datos alcanzó 15,08 GB, con una media de 59,0 KB por bloque.
La investigación fue realizada por un operador independiente. Los datos y los scripts son públicos, y los totales pueden comprobarse en el archivo disponible, aunque todavía no existe una segunda reproducción completa por parte de otro operador. Además, las cifras solo miden el volumen de datos: no evalúan el consumo de batería, la carga del procesador, el almacenamiento ni el tiempo que tardan en llegar las respuestas.
El riesgo está en los datos que no llegan
Un nodo completo puede obtener directamente de la cadena la información necesaria para localizar los pagos. En cambio, un monedero ligero depende de un indexador o servidor externo. Uno de los modelos previstos mantiene en el teléfono la identificación de las operaciones y solicita al servidor los datos públicos derivados de las entradas de cada transacción.
Este diseño evita que el servidor tenga que recibir la clave privada de búsqueda, pero no elimina la dependencia de que la respuesta sea completa. Si falta precisamente el dato necesario para identificar una transferencia, el monedero no genera la dirección de destino correspondiente y no muestra el ingreso. La operación sigue siendo válida en Bitcoin y las claves del receptor continúan controlando los fondos; el problema es que el cliente puede no descubrirlos.
Una incidencia abierta en Cake Wallet en julio de 2025 planteó que el fallo podría prolongarse si el cliente guarda como completada una altura posterior tras recibir información incompleta. En ese caso, cambiar de servidor no obligaría necesariamente al monedero a volver a consultar el bloque omitido. La página de la incidencia no incluye una confirmación del equipo de mantenimiento sobre esa arquitectura ni documenta una ocultación deliberada por parte de ningún servidor.
La recuperación exigiría volver a escanear desde una altura anterior utilizando una fuente completa y honesta, o recurrir a un proceso respaldado por un nodo completo. El riesgo para el usuario es que la cartera parezca sincronizada sin avisar de que parte del historial debe revisarse de nuevo.
Más privacidad, pero también más confianza en la infraestructura
El proyecto también modela una alternativa basada en filtros específicos para Taproot y datos auxiliares. Ese recorrido sumaría unos 7,14 GB en el periodo estudiado, frente a los 15,08 GB del flujo completo. Sin embargo, obliga a descargar el bloque entero cada vez que un filtro coincide, incluidos los falsos positivos, por lo que el tráfico final dependería de la actividad del monedero y de la tasa de coincidencias.
La especificación de clientes ligeros para pagos silenciosos aún está en desarrollo. BIP-352 figura como completa para el protocolo principal, pero su apartado sobre teléfonos mantiene abierta la investigación. El documento convergente para clientes ligeros se identifica como un borrador preliminar, versión 0.1.
Mientras tanto, los monederos están adoptando modelos distintos. Sparrow Wallet 2.5.0, publicado en mayo de 2026, incorporó la recepción mediante pagos silenciosos y la selección automática de un servidor público de Frigate. Otros proyectos, como Dana y Silentium, describen sus aplicaciones móviles como experimentales. La conclusión de las mediciones es clara: el ancho de banda no parece el principal obstáculo. La cuestión decisiva será que el monedero pueda verificar que ha recibido todos los datos necesarios antes de dar por completo el historial.
