Acceso arbitrario a transacciones ya confirmadas

Este enlace menciona que

"[ getdata ] se puede usar para recuperar transacciones, pero solo si están en el grupo de memoria o en el conjunto de relés; no se permite el acceso arbitrario a las transacciones en la cadena..."

Pero, ¿no puede un nodo SPV hacer lo siguiente para tener acceso arbitrario a una transacción T (supongo que el nodo SPV conoce el bloque hash H del bloque B que contiene T):

  1. establezca un filtro de floración usando filterload para T en algún nodo completo
  2. envíe una solicitud de obtención de datos con el tipo MSG_FILTERED_BLOCK y bloquee el hash H
  3. luego, en respuesta, el nodo completo generará dos mensajes para el nodo SPV: primero, un merkleblock de B; y segundo, la transacción T (como se menciona aquí y aquí )

¿Este mecanismo en realidad no da acceso arbitrario a las transacciones?

Eso solo funciona para un nodo que tiene el índice de transacción activado. Si no es así, no ofrecería este servicio durante el protocolo de enlace p2p (el mensaje de versión indica los servicios disponibles) y no sería posible con este par.

Respuestas (1)

Eso se basa en la indexación mínima requerida para ejecutar un nodo completo.

Un mensaje getdata a los pares solo puede solicitar recursos TX en mempool (válido, sin confirmar). No todas las transacciones confirmadas de índice de nodos completos. UTXO y mempool tx están necesariamente indexados para la validación y la creación de plantillas de bloque/propagación de tx, respectivamente.

La transacción confirmada se proporciona como parte de la solicitud getdata con hashes de bloque. Los bloques están indexados por todos los nodos completos. (Dado que los nuevos encabezados de bloque deben hacer referencia a los encabezados anteriores, incluso si se extienden por ramas, en lugar de extenderse por cadenas fuertes)

Corrección (ver comentario a continuación):

Esto no es correcto. El enfoque sugerido por OP (usando BIP37) funcionaría, pero es altamente ineficiente (requiere el escaneo completo del nodo a lo largo de toda la cadena, pero no necesita un índice). Esa es la razón por la que se desaconseja BIP37.
Wow, ¿un escaneo de cadena completo? Gracias por la corrección. Nunca hubiera pensado que esto se hace sin índice.
No es diferente de una descarga completa de blockchain, pero al mismo tiempo proporciona un filtro primero. El enfoque del filtro de floración BIP37 no se puede acelerar fácilmente usando un índice de todos modos (ya que un índice inherentemente no tendría falsos positivos y, por lo tanto, perdería mucha privacidad). Ver BIP157 para un enfoque más moderno (que usa algunos datos precalculados, pero aún no es un índice).
Acceso arbitrario a transacciones ya confirmadas
RespuestasAquíPolítica de privacidad1y, 0v