Los pagos silenciosos de Bitcoin, conocidos como Silent Payments, podrían ofrecer a los usuarios una dirección reutilizable sin revelar en la cadena un rastro evidente de los cobros recibidos. Sin embargo, su llegada a los teléfonos plantea un problema distinto al de la privacidad: un monedero ligero podría no detectar un pago si el servidor que le proporciona los datos omite una parte del historial.
Un análisis publicado en septiembre estima que un monedero que utilice la versión 2 de BlindBit Oracle necesitaría descargar alrededor de 8 MB al día para seguir la cadena en la parte más reciente de la muestra estudiada. La cifra sugiere que el consumo de datos móviles es asumible. El punto delicado está en la integridad de esa información: el dispositivo necesita una forma fiable de comprobar que ha recibido todos los elementos relevantes.
El coste de escanear la cadena cabe en una conexión móvil
Silent Payments permite que el emisor utilice la información pública del receptor para derivar un destino Taproot nuevo en cada operación. Después, el monedero del receptor escanea las transacciones aptas para localizar las salidas que le corresponden. Así se evita publicar una dirección reutilizada y fácilmente identificable.
El estudio procesó todos los bloques de Bitcoin comprendidos entre las alturas 709.656 y 965.089, un intervalo de 255.434 bloques que abarca 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 representa una restauración histórica sobre todo el periodo analizado, no el consumo diario de un monedero ya sincronizado. Para estimar este último, el proyecto tomó la media de los bloques situados entre las alturas 900.000 y 965.089 y asumió una producción de 144 bloques diarios. El resultado fue de aproximadamente 8,0 MB al día.
El mismo trabajo calcula una alternativa más ligera basada en filtros exclusivos para Taproot y datos de ajustes criptográficos. Los filtros representarían unos 0,94 GB y los ajustes sin procesar, alrededor de 6,2 GB, para un subtotal de 7,14 GB en todo el historial medido. El flujo completo de BlindBit v2 es, por tanto, unas 2,1 veces mayor. La vía de filtros tendría además que descargar cada bloque que coincidiera, incluidos los falsos positivos, por lo que el tráfico final dependería de la actividad del monedero.
El riesgo está en los datos que no llegan
Un nodo completo puede obtener directamente de la cadena la información necesaria para realizar el escaneo. Un monedero ligero, en cambio, necesita recurrir a un indexador o a un servidor auxiliar. En uno de los modelos en desarrollo, el teléfono conserva el trabajo de identificación y solicita al servidor los ajustes públicos de cada transacción.
Ese diseño evita compartir con el servidor la clave privada de escaneo, pero no elimina la dependencia de que la respuesta sea completa. Si falta precisamente el ajuste asociado a un pago entrante, el monedero no genera la dirección de destino correspondiente y no muestra el cobro. El pago sigue siendo válido en Bitcoin y las claves del receptor mantienen el control sobre los fondos; el problema es que el monedero puede no descubrirlos.
Una incidencia abierta en Cake Wallet en julio de 2025 examinó un escenario adicional: el cliente podría guardar una altura de escaneo posterior después de recibir datos incompletos y considerar ya revisado el tramo anterior. En ese caso, cambiar de servidor no obligaría necesariamente a repetir la consulta desde el bloque donde se produjo la omisión. La página de la incidencia no incluye una confirmación del mantenedor sobre esa interpretación ni documenta una retención deliberada de información por parte de ningún servidor.
La verificación aún está en desarrollo
El proyecto propone compromisos encadenados para los conjuntos de ajustes canónicos de cada bloque. La comparación entre servidores y un punto de control externo podrían ayudar a detectar modificaciones, respuestas contradictorias o historiales incompletos. Aun así, un cliente que confíe inicialmente en una única respuesta podría recibir datos incompletos antes de que una segunda comprobación revele la discrepancia.
BIP-352, que define el protocolo central de Silent Payments, figura como completo. Su apartado dedicado a clientes ligeros y soporte móvil con preservación de la privacidad sigue planteado como investigación abierta. El documento unificado sobre clientes ligeros continúa en estado preliminar, con los trabajos de adopción e interoperabilidad pendientes.
Mientras tanto, los monederos están optando por relaciones distintas con los servidores. Sparrow Wallet incorporó en su versión 2.5.0, publicada en mayo de 2026, la recepción mediante Silent Payments y la selección automática de un servidor público de Frigate. Otros proyectos, como Dana Wallet y Silentium, describen sus aplicaciones móviles como experimentales. Las mediciones reducen las dudas sobre el volumen de datos, pero dejan intacta la cuestión principal: cómo garantizar que la privacidad no convierta un pago legítimo en un ingreso invisible para su propio destinatario.
