Los pagos silenciosos de Bitcoin, conocidos como Silent Payments, podrían permitir a los usuarios recibir fondos sin exponer en la cadena un historial evidente de pagos asociado a una dirección reutilizable. El principal obstáculo para llevar esta función a los teléfonos no parece ser ya el consumo de datos, sino la capacidad de verificar que el monedero ha recibido toda la información necesaria para detectar una transferencia.
Un proyecto de medición publicado en septiembre calcula que la descarga completa de datos de escaneo de BlindBit Oracle v2 requeriría unos 8 MB diarios en la parte alta de su conjunto de datos. La cifra sugiere que el tráfico sería asumible para una conexión móvil. Pero también pone el foco en un riesgo menos visible: los monederos ligeros dependen de un indexador o servidor que les entregue los datos pertinentes. Si falta una sola entrada, el pago puede quedar sin descubrir.
Cómo funcionan los pagos silenciosos
BIP-352 define un sistema en el que el receptor publica información que el emisor utiliza para derivar un destino Taproot nuevo para cada pago. La dirección reutilizable no aparece como una secuencia evidente de cobros en la cadena. Después, el monedero del receptor debe revisar las transacciones válidas para determinar si alguno de sus resultados le pertenece.
Un nodo completo puede obtener directamente de la cadena los datos necesarios para realizar ese proceso. En cambio, un monedero móvil ligero necesita recurrir a otra fuente. Según el modelo utilizado, el servidor puede enviar ajustes públicos para que el teléfono haga la comprobación o trasladar parte del emparejamiento a su propia infraestructura. En ambos casos, la respuesta debe ser completa.
El problema es concreto: si el servidor omite el ajuste que corresponde a un pago entrante, el monedero no generará el destino coincidente y no mostrará la recepción. Los fondos no desaparecen de Bitcoin y las claves del usuario siguen controlándolos, pero la aplicación puede no informar de que han llegado.
Qué dicen las mediciones de BlindBit
El proyecto procesó todos los bloques comprendidos entre las alturas 709.656 y 965.089, un intervalo de 255.434 bloques que va desde poco después de la activación de Taproot hasta septiembre de 2026. El conjunto completo de datos de escaneo de BlindBit v2 suma 15.079.946.729 bytes, equivalentes a 15,08 GB, con una media de 59,0 KB por bloque.
Ese total describe la recuperación de todo el periodo analizado, no el consumo diario de un monedero que sigue la cadena. Para estimar este último, el estudio toma la media registrada entre los bloques 900.000 y 965.089 y supone 144 bloques diarios. El resultado es de aproximadamente 8,0 MB al día.
El mismo trabajo modela una alternativa basada en filtros exclusivos para Taproot y unos 6,2 GB de ajustes sin procesar. El subtotal estimado sería de unos 7,14 GB frente a los 15,08 GB del flujo completo. Sin embargo, esa vía exige descargar el bloque entero cada vez que el filtro encuentra una coincidencia, incluidos los falsos positivos, por lo que el tráfico final dependería de la actividad del monedero y de la tasa de coincidencias. El modelo de filtros se contrastó con 21 codificaciones reales y, según el proyecto, quedó dentro de un margen aproximado del 0,5%. Todavía no existe un filtro Taproot específico para Silent Payments desplegado.
El reto es comprobar que no falta información
El repositorio procede de un único operador independiente. Sus datos y scripts son públicos, y los totales pueden verificarse a partir del archivo CSV, aunque todavía no hay una segunda ejecución completa publicada por otro operador. Además, las mediciones se refieren al volumen de datos: no evalúan el consumo de batería, la carga del procesador, el almacenamiento ni la latencia.
Una incidencia analizada en Cake Wallet en julio de 2025 planteó que un cliente podría guardar como completada una altura de escaneo posterior aunque hubiera recibido información incompleta. En ese caso, cambiar de servidor no obligaría necesariamente a revisar el tramo anterior. La página de la incidencia no acredita una confirmación del equipo mantenedor ni documenta un ocultamiento intencionado por parte de ningún servidor. La recuperación sería posible al volver a escanear desde una altura anterior con una fuente completa y fiable, o mediante un nodo completo.
La especificación principal de BIP-352 figura como completa, pero su apartado para clientes ligeros mantiene abierta la investigación sobre el soporte móvil. El documento convergente para clientes ligeros continúa en fase preliminar. Mientras tanto, distintos proyectos están adoptando modelos diferentes: Sparrow Wallet 2.5.0 incorporó la recepción de Silent Payments y la selección automática de un servidor público de Frigate; otros desarrollos giran en torno a Cake Esplora, BlindBit Oracle o nodos propios. La cuestión decisiva para estos monederos no será solo cuánto pesan los datos, sino cómo demostrar que no falta ninguno.
