De acuerdo con la referencia del desarrollador central de Bitcoin, la llamada RPC getPeerInfo tiene en su salida un campo llamado "addrlocal" que contiene nuestra IP desde la visión del mundo del par.
¿Por qué esta salida allí? ¿Se usa en cualquier lugar? ¿Tiene un caso de uso?
Además, comentaron que "la mayoría de los nodos SPV establecen esto en 127.0.0.1:8333", ¿por qué haría eso un nodo SPV?
¿Por qué esta salida allí?
Porque es parte del versionmensaje P2P. getpeerinfoemite en gran medida la información proporcionada por el versionmensaje.
¿Se usa en cualquier lugar? ¿Tiene un caso de uso?
Actualmente no. Sin embargo, es posible que se haya incluido en el versionmensaje porque Bitcoin se diseñó originalmente para que las cosas fueran directamente a las direcciones IP. Solía haber una cosa de Pay-to-IP donde esto podría haber sido útil.
Además, comentaron que "la mayoría de los nodos SPV establecen esto en 127.0.0.1:8333", ¿por qué haría eso un nodo SPV?
Porque es más fácil de implementar y en realidad nadie lo usa.
¿Por qué esta salida allí?
Sus pares lo envían al nodo Bitcoin en sus versionmensajes P2P.
¿Se usa en cualquier lugar? ¿Tiene un caso de uso?
Sí. Principalmente, se utiliza en la red P2P de Bitcoin. Cuando un nodo desea aceptar conexiones de red entrantes de Bitcoin a través de Internet pero no conoce su propia dirección IP en Internet, puede usar el addrLocalinforme de un par de salida para descubrir de qué dirección IP ve el par de salida que proviene la conexión de este nodo. Si esta dirección IP está dentro de rangos de Internet válidos, este nodo puede anunciar esta IP para futuras conexiones entrantes. En Bitcoin Core, este comportamiento de descubrimiento se activa o desactiva proporcionando la -discoveropción de bitcoind o bitcoin-qt.
addrLocaltambién puede ser utilizado por aplicaciones que reciben la información a través del procedimiento RPC getPeerInfo que mencionas. Si una aplicación desea tomar sus propias decisiones sobre qué dirección IP anunciar para un nodo, como para un sitio web, puede incluir estos datos proporcionados por pares en su decisión. Una aplicación también podría desear determinar cómo un par se conectó a un nodo cuando este nodo ofrece múltiples rutas para que los pares se conecten (por ejemplo, a través de NAT, proxies inversos, proxies de reenvío, túneles, anonimizadores, etc.)
Además, comentaron que "la mayoría de los nodos SPV establecen esto en 127.0.0.1:8333", ¿por qué haría eso un nodo SPV?
Ya sea porque el nodo SPV se está ejecutando y conectado localmente o porque el nodo SPV ha mentido. Un caso de uso para cualquier tipo de mentira de nodo podría ser que el desarrollador deje un valor de marcador de posición mientras no haya terminado de implementar completamente los requisitos del protocolo de red, o si el nodo de conexión desea ocultar qué ruta tomó para conectarse a este nodo cuando hay múltiples opciones disponibles.
La redacción "la mayoría de los nodos SPV" se ha eliminado en gran medida de la documentación.