Tanto en las transacciones de "envío" como en las de "recepción", el comando gettransactionme da el nombre de la cuenta y la dirección de recepción, ignorando la dirección de envío. ¿Por qué debería preocuparme por la dirección de recepción en una transacción de "recepción"? Quiero saber la dirección de envío , por supuesto...
¿Por qué no funciona de esta manera, qué me estoy perdiendo y cómo puedo obtener la dirección de envío en una transacción de recepción?
editar : me gustaría enfatizar la pregunta de por qué se comporta de esta manera. como en este comentario "No lo entiendo: si introduzco el txid en blockchain.info, me dice la dirección del remitente, ya que obviamente está presente en la cadena de bloques ... ¿entonces es solo una opción de bitcoindno decírmelo? "
editar : enviar algo a la dirección de origen está totalmente fuera del alcance de la pregunta, por lo que es irrelevante si no desean recibir nada allí.
Tenía la intención de responder otra pregunta , que mientras tanto se cerró como un duplicado, pero usaré el caso que se describió allí como ejemplo para responder esta pregunta.
Suponiendo que la transacción es de hecho una transacción estándar, el script revela el remitente de la transacción. De acuerdo con la descripción estándar de la transacción en la especificación del protocolo, la transacción primero debe demostrar la propiedad de una salida para reclamarla y gastarla en la nueva transacción. La transacción que entregó los fondos al remitente especifica el hash de una clave pública a la que enviar los fondos. En este caso, es el script de salida 1 de la transacción f8c71a9f7...:
OP_DUP OP_HASH160 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7 OP_EQUALVERIFY OP_CHECKSIG
Observe el 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7de allí. Ese es el hash de la clave pública. Para reclamar esta salida y luego enviársela, el remitente debe proporcionar tanto la clave pública como una firma válida. Así que echemos un vistazo a la secuencia de comandos que reclamó esta salida:
304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb
Al ser una transacción estándar, se ajustará al formato <sig> <pubKey>, por lo que la clave pública es 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb. Para verificar esto, verificamos si los hashes coinciden (código de Python por delante):
script = "304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb".split()
h = hashlib.sha256(script[1].decode("hex")).digest()
ripe160 = hashlib.new('ripemd160')
ripe160.update(h)
d = ripe160.digest()
print d.encode("hex")
Esto debería dar como resultado 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7, que es el hash que hemos visto en el script de salida del reclamo que finalmente se le envió. Tenga en cuenta que para calcular esto no tuvimos que buscar la transacción, f8c71a9f7...sino que simplemente confiamos en la información que podría obtener de la transacción que recibió. Ahora, dado que una dirección no es mucho más que el hash de una clave pública, simplemente podemos construir una dirección a partir de la información que hemos recopilado hasta ahora (teniendo ya el hash, comenzamos desde el paso 4 en la construcción de la dirección ):
#Prepend the Mainnet prefix
address = ('\x00' + d)
#Calculate checksum
checksum = hashlib.sha256(hashlib.sha256(address).digest()).digest()[:4]
# Build the raw address
address += checksum
# Encode the address in base58
encoded_address = b58encode(address)
print encoded_address
La codificación se puede hacer con cualquier codificador base58, usé este . Esto debería imprimir la dirección 17h6u26N2TVmoPRcvxwUdfAUjDzBJX513Vque es la dirección que envió los bitcoins en la transacción que estábamos viendo todo el tiempo. Como puede ver, la información que estaba buscando estuvo en la transacción todo el tiempo, pero bastante oculta. Entonces, dada una transacción entrante (o saliente, de hecho), puede reconstruir quién fue el remitente (o el destinatario). Tenga en cuenta que esto le permite reconstruir el remitente de cada entrada individual, que puede ser varias direcciones. El simple hecho de suponer que cualquiera de las direcciones que firman las entradas es el remitente de la transacción puede conducir o no al resultado semántico deseado.
Creo que se debe al modelo de seguridad previsto: genera una dirección para un cliente, que le envía bitcoins.
Permitir que las personas descubran la dirección de envío puede hacer que las personas creen una dirección de bitcoin y luego soliciten a los clientes que ingresen su dirección de envío.
En cuanto a cómo...
Encontré estos tres hilos:
o0'.
bitcoindno decírmelo?pieter wuille
o0'.
pieter wuille