Actuando como un nodo pasivo en lugar de uno activo usando bitcoind

Lo que está pidiendo no es posible con una versión no modificada de bitcoind. Entonces interpretaré su pregunta como por qué no y cómo lograr algo similar.

Tener nodos de bitcoin que no transmiten transacciones es un peligro para bitcoin: si los nodos comienzan a comportarse de esa manera, no solo avanzamos un paso más hacia el riesgo de que las transacciones se bloqueen porque alguien que envía una transacción no las reenvía en absoluto, pero lo que es más importante, las hazañas mineras como la descrita en el preprint Majority no es suficiente: Bitcoin Mining is Vulnerable pasa de lo teórico a lo práctico. De hecho, alguien que intente implementar este exploit podría hacer prácticamente la misma pregunta que usted.

Entonces, ¿qué te impide hacerlo de todos modos, con una versión modificada de bitcoind? Nada, en realidad, excepto que parece un poco contraproducente. Considere que tan pronto como otros comiencen a percibirlo como una molestia suficiente (¡y deberían, por razones de equidad y seguridad!), propondremos alguna modificación que requerirá que reenvíe al menos algunas transacciones o que no reenvíe las transacciones. tú mismo. O quédese atrapado con nodos igualmente egoístas a los que conectarse. Eso será exactamente lo contrario de lo que desea lograr para verificar transacciones. ¡Solo considere que, eventualmente, es posible que solo vea esas transacciones con más probabilidades de no propagarse hasta los grupos de minería!

Entonces, ¿qué opciones tiene para limitar el ancho de banda (dudo que pueda ahorrar mucho tiempo de CPU, de todos modos)? Aquí están sus opciones:

1. Ya conoce la respuesta más radical: no ejecutar su propia copia de bitcoind y, en su lugar, utilizar las API públicas de blockchain.info y blockexplorer.com (o alguna solución comercial). Supongo que no está contento con confiar en servicios externos gratuitos, pero considerando que hay redundancia (para lidiar con el tiempo de inactividad individual o para obtener más de una confirmación). Por lo tanto, este enfoque de ancho de banda súper bajo (al menos para algunas transacciones para monitorear activamente) puede no ser tan malo como parece al principio.

2. Limite la cantidad de nodos a los que se conecta su bitcoind. Esto, desafortunadamente, es una espada de doble filo. Al mismo tiempo, limita los datos que enviará (¡menos pares!) y los datos que recibirá. Por lo tanto, tiene una mayor posibilidad de llegar tarde a ver una transacción, si por alguna razón no llegó a los pocos (¿uno?) otro nodo al que se conectó, o porque pocos pares significan que tiene un riesgo elevado de perder la conexión simultáneamente. a todos ellos, siendo cortados de la red bitcoin brevemente.

3. Modifica a tu cliente de forma sensata. Tal vez pueda vivir con la transmisión de nuevas transacciones, pero ¿acelerando las descargas masivas de toda la cadena de bloques? Esto podría tener un gran impacto en su ancho de banda saliente (y total), al tiempo que ofrece la posibilidad de un comportamiento general muy sensible. Considere que incluso podría tener sentido para la línea principal de bitcoind si se pudieran implementar medios alternativos de descarga masiva de la cadena de bloques, y siempre que encontremos espejos para ellos, esto debería ser factible. De hecho, al colocar una parte de "blockchain mirror" de su sitio detrás de una cuenta gratuita de cloudflare para servir contenido estático a costo cero, ¡podría hacerlo!

¿Puedo sugerir que la opción 3 podría ser el camino a seguir? Si las modificaciones necesarias a bitcoind son un problema para usted, podría ayudarlo (o incluso hacerlo todo), aunque lamento decir que probablemente no podría hacerlo de forma gratuita.