El documento, Sobre las disposiciones de privacidad de los filtros Bloom en los clientes ligeros de Bitcoin , dice lo siguiente sobre los filtros Bloom en SPV:
...De hecho, en las implementaciones actuales de los clientes SPV [BitcoinJ], tanto las direcciones como sus claves públicas se insertan en el filtro Bloom subcontratado. Como tal, si el adversario conoce tanto la dirección como su clave pública, entonces puede probar trivialmente si una dirección es un verdadero positivo del filtro verificando si tanto la dirección como su clave pública están insertadas dentro del filtro. Si no es así, es muy probable que la dirección sea un falso positivo del filtro. Creemos que la inclusión tanto de la dirección como de su clave pública en el filtro Bloom es una falla grave en las implementaciones actuales del cliente SPV y puede contrarrestarse fácilmente.; por lo tanto, no explotamos este defecto en nuestro análisis. De hecho, más del 99% de todas las transacciones de Bitcoin consisten en pagos a direcciones de Bitcoin (o hash de clave pública); además, solo 4587 de los 33 millones de direcciones totales en el sistema recibieron transacciones destinadas tanto a sus claves públicas como a sus hashes de clave pública. Esto significa que para la gran mayoría de los clientes de Bitcoin, no es necesario incluir tanto las claves públicas como sus hashes (es decir, las direcciones de Bitcoin) en los filtros Bloom; bastaría con insertar uno u otro (en más del 99% de los casos). [mi énfasis]
La idea detrás de este ataque se reiteró en Privacidad en BitcoinJ :
La vulnerabilidad es que si una clave pública está realmente en el filtro, la consulta tanto de la clave pública como de la clave pública debe devolver verdadero. Debido a que pubkeyhash es solo otra cadena aleatoria casi uniforme, la probabilidad de un falso positivo para el atacante es fp' = fp^2 = 0.0000000021555. Obtuve alrededor de 56 millones de claves públicas de la cadena de bloques (mediados de enero), lo que teóricamente da como resultado 56 millones * fp' = 1,29 falsos positivos esperados al escanear la cadena de bloques.
En otras palabras, un simple ataque es suficiente para seleccionar todas las claves públicas de un filtro BitcoinJ Bloom.
¿La versión actual de BitcoinJ agrega una clave pública y su valor hash a sus filtros Bloom? Si no es así, ¿qué lanzamiento evitó que ocurriera?
Además, ¿por qué se agregaron claves públicas y hashes en primer lugar?
¿La versión actual de BitcoinJ agrega una clave pública y su valor hash a sus filtros Bloom? Si no es así, ¿qué lanzamiento evitó que ocurriera?
Sí. El siguiente código lo implementa:
/** Inserts the given key and equivalent hashed form (for the address). */
public synchronized void insert(ECKey key) {
insert(key.getPubKey());
insert(key.getPubKeyHash());
}
Además, ¿por qué se agregaron claves públicas y hashes en primer lugar?
No soy el tipo que escribió esto (Mike Hearn). Dicho esto, supongo que es difícil saber si los depósitos a una dirección serán en formato P2PKH o P2PK. Pagar a la clave pública es realmente poco común, pero es legal. Dada la elección entre perder parte del dinero de su cliente por razones misteriosas o reducir su privacidad, eligió lo último.
Ahora, si está preguntando por qué filterloadno toma simplemente el HASH160 de una clave antes de compararlo con el filtro de floración para que un cliente ligero pueda buscar tanto el hash como la clave al mismo tiempo, no lo sé. Parece que solucionaría el problema mencionado en ese documento por una cantidad bastante razonable de tiempo de CPU. Culparía al autor de BIP37 , pero eso fue escrito por el mismo tipo.
Si un cliente de SPV quiere monitorear el saldo de su billetera, debe rastrear tanto los fondos entrantes (las transacciones con salidas que contienen el hash de la clave pública de la billetera (la dirección de bitcoin), como los fondos salientes, las transacciones con entradas que tienen la clave pública de la billetera en su guión característico. (Por supuesto, el cliente SPV tiene que monitorear todas las claves/direcciones de publicación que ha generado la billetera).
Se podría decir que el seguimiento de los fondos salientes duplica la funcionalidad de actualización automática del filtro de floración, pero supongo que el caso de uso aquí es una sincronización SPV desde una altura de bloque arbitraria.