¿Qué índices mantiene un nodo Bitcoin Core para atender solicitudes filtradas por Bloom y pares SPV?

El Wiki hace esta declaración:

Se puede usar [ getdatamensaje] para recuperar transacciones, pero solo si están en el grupo de memoria o en el conjunto de retransmisión: no se permite el acceso arbitrario a las transacciones en la cadena para evitar que los clientes comiencen a depender de los nodos que tienen índices de transacciones completos (lo cual es moderno) . los nodos no) . [mi énfasis]

https://en.bitcoin.it/wiki/Protocol_documentation#getdata

Sin embargo, el "filtrado de floración de conexión" (BIP-37) parece requerir un sistema de índice de este tipo:

El filtro se puede probar con datos arbitrarios, para ver si el cliente insertó esos datos. Por lo tanto, surge la pregunta de qué datos deben insertarse/probarse.

Para determinar si una transacción coincide con el filtro, se utiliza el siguiente algoritmo. Una vez que se encuentra una coincidencia, el algoritmo aborta.

Luego se da una lista ordenada de criterios.

Parece que un nodo que admita dicho filtro también necesitaría mantener un índice (o varios) o correr el riesgo de ataques de denegación de servicio.

Vi esta pregunta:

¿El 70% de los nodos acepta filtros Bloom, a pesar del vector de ataque DoS?

que no parece responder a la pregunta sobre los índices.

Vi esta pregunta:

¿Hay alguna manera de indexar las transacciones para que los comandos de carga de filtro se puedan responder sin iterar a través de todas las transacciones en un bloque?

cuya única respuesta implica, sin declarar explícitamente, que no se crean índices en absoluto.

¿Qué índices crea un nodo con el único propósito de admitir el filtrado Bloom para nodos SPV?

Si no se crea ninguno y las transacciones se filtran sobre la marcha, ¿cómo puede ser cierta esta afirmación en la pregunta vinculada anterior?

Por lo tanto, puede desencadenar fácilmente exactamente el mismo ataque DoS simplemente usando solicitudes regulares de obtención de datos en bloques grandes una y otra vez. No necesita filtrado Bloom. Si no desea descargar los bloques, simplemente no haga ACK de TCP de los paquetes y luego FIN después de unos segundos ... todos los datos se habrán cargado y estarán en los búferes de envío.

Respuestas (1)

Bitcoin Core mantiene un índice de bloques y sus ubicaciones en el disco. Cuando alguien solicita un bloque, extrae el bloque del disco y, si utilizó BIP 37, ejecutará el bloque a través del filtro. El índice de bloque es necesario para el funcionamiento normal del nodo; no hay otros índices creados. La única cosa similar a un "índice" es el mempool, y eso se mantiene únicamente en la memoria. De allí provienen las transacciones si son solicitadas; las transacciones confirmadas no estarán en el mempool y no se pueden retransmitir.

Para BIP 37, las cosas solo se prueban contra el filtro antes de ser retransmitidas a un nodo que haya establecido un filtro. Lo único que se transmitirá alguna vez son las transacciones no confirmadas y los bloques completos.

Si no se crea ninguno y las transacciones se filtran sobre la marcha, ¿cómo puede ser cierta esta afirmación en la pregunta vinculada anterior?

La declaración es verdadera porque un nodo puede establecer un filtro y solicitar bloques y transacciones no confirmadas del nodo. Luego, el nodo pasará esos bloques y transacciones a través del filtro antes de retransmitirlos.

Fragmentar transacciones y ejecutar las piezas a través de un filtro Bloom como recomienda BIP-37 consume recursos del nodo, ¿no es así? Si un nodo simplemente envía sin filtrar, entonces esos recursos no necesitan consumirse. ¿El filtrado de transacciones sobre la marcha no abre un vector de ataque DoS que no existe cuando se envían bloques y mempool sin filtrar?
Sí, consume recursos y puede conducir potencialmente a ataques DoS. También hay formas de mitigar los ataques DoS, como la limitación de velocidad. Es por eso que la mayoría de los desarrolladores consideran que BIP 37 es malo, pero hasta ahora es lo único que admite billeteras livianas de manera descentralizada.
El diseño de BIP 37 es más o menos incompatible con cualquier tipo de indexación en cualquier caso, ya que se requiere que el nodo de servicio modifique continuamente el filtro en orden transacción por transacción.