Cliente ligero y OP_RETURN

Me gustaría entender mejor cómo funciona un cliente ligero. Hasta donde yo sé, un cliente ligero almacena localmente solo los encabezados de bloque (80 bytes cada uno) y recibe un nuevo encabezado de bloque en promedio cada 10 minutos.

Básicamente tengo dos preguntas:

1) ¿Cómo puede un cliente ligero recuperar una transacción dado su hash? Me gustaría recuperar la transacción completa para leer los datos después del código OP_RETURN.

2) ¿Cómo puede el cliente ligero estar seguro de que la transacción recuperada es realmente la de la cadena de bloques más larga? ¿Simplemente verifica si hay 5 bloques ya confirmados después del bloque de la transacción?

Muchas gracias

Respuestas (1)

1) La forma más fácil dentro del protocolo es probablemente agregar ese hash de transacción a un filtro de floración, enviar el filtro de floración a un nodo remoto con filterloady solicitar cada bloque filtrado. Esto le enviará solo la transacción que le interesa. (También enviará algunas transacciones adicionales que coincidan con el filtro de floración porque son falsos positivos). Consulte BIP37 para obtener más detalles sobre cómo funciona esta función. Así es como los clientes ligeros basados ​​en BitcoinJ encuentran transacciones relevantes para ellos.

Saber la altura del bloque en el que está incluido lo simplificaría enormemente, ya que solo necesitará mirar un bloque, en lugar de toda la cadena.

2) No. Obtienen los encabezados de bloque para toda la mejor cadena. Esto va desde el bloque de génesis hasta la punta actual. (Esto es actualmente 450000*80=36MB) Luego verifican que el bloque relevante esté en algún lugar de esa cadena.

¡Gracias por la explicación! ¿Puedo preguntarle también cuáles son los requisitos mínimos para un cliente ligero en términos de RAM y CPU?
Prácticamente nada. Estrictamente hablando, ni siquiera necesita conservar todos los encabezados de bloque una vez que haya verificado que se conectan al bloque de génesis. Puede conservar solo la punta de la cadena y las que le interesen. El problema principal con los clientes ligeros no son los recursos que utilizan, sino su incapacidad para comprobar si una cadena de bloques es válida.
Bien, ahora lo tengo. Para asegurarnos de que la cadena de bloques sea válida, necesitamos los bloques completos con todas las transacciones, así que un nodo completo, ¿verdad?
Bien. Necesita todos los bloques para hacer cumplir reglas como no permitir que la misma salida se gaste dos veces.
Hola @nick, si soy un cliente ligero (bitcoinj) y conozco tanto el tx_hashcomo el block_number, ¿qué tipo de mensaje debo enviar a mis compañeros para recuperar la transacción completa?
@ gatb27 Una vez que sepa block_hash, y tx_hashenvíe el filtro de floración con filterload. Luego envías getdata, con un tipo inv de MSG_FILTERED_BLOCK, y el hash de bloque. Esto documenta los detalles de bajo nivel. en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors Déjame ver si puedo elaborar un código de ejemplo para ti.
Acabo de estudiar los diferentes tipos de mensajes en la guía para desarrolladores :) Me gustaría pedir el último favor: estoy interesado en un fragmento de código en python (jython para bitcoinj) que, dado un y tx_hash, block_numberdevuelve el hexadecimal después de OP_RETURN en la salida tx_hash. ¿Dónde puedo encontrar una guía para aprender a hacerlo? :)
Cliente ligero y OP_RETURN
RespuestasAquíPolítica de privacidad1y, 0v