Prueba de propiedad de la dirección

Esta pregunta aparece muchas veces en SO, pero hay algo en las respuestas que no obtengo.

Estoy diseñando un sistema basado en las llamadas API realizadas a blockchain.info, pero tengo problemas para entender la relación entre Pubkey, la dirección y las firmas digitales para mi caso de uso.

Digamos que el usuario Jane ha realizado transacciones previamente con Bitcoin y asumimos que la transacción está confirmada en la cadena de bloques de Bitcoin. Jane ahora hace una solicitud desde su software de billetera basado en la aplicación para algunos metadatos relacionados con esa transacción específica a través del servicio web del sistema.

El servicio web requiere que Jane demuestre que su billetera realmente instigó esa transacción para permitir que su billetera acceda a los datos, pero aquí me pongo un poco confuso: de toda mi lectura durante los últimos 6 o 7 días, reúno la billetera el software necesitaría firmar algún mensaje predeterminado que contenga, por ejemplo, el TXID usando la clave privada de la billetera, firmarlo y enviarlo al sistema junto con la clave pública, pero una vez que el sistema recibe los datos, puede verificar el mensaje usando la clave pública clave, ¿y qué? ¿Cómo prueba eso que el txid (o la dirección o lo que sea) en ese mensaje firmado fue firmado por la misma clave privada de la que se deriva indirectamente la transacción en cuestión? Me falta una parte que "reconcilia" los datos remotos de blockchain con los datos enviados desde la aplicación de billetera.

Entiendo la PKI básica y que las direcciones son derivaciones cifradas de una clave pública, pero la parte de la firma digital me está dando vueltas en la cabeza.

Gracias por leer. Cualquier ayuda sería muy apreciada.

¿Hay alguna razón específica por la que lo estás haciendo de una manera tan complicada y torpe? ¿Hay alguna razón por la que no puedas hacerlo de una manera mucho más directa? Por ejemplo, ¿por qué no hacer que Jane pague a una dirección específica solo para ella que vincule todo lo que compró a su cuenta o a alguna otra credencial?
El sistema que deseo construir pertenece a los metadatos sobre una transacción btc, casi ninguno de los cuales está disponible a través de la cadena de bloques pública, eventualmente será generado por el sistema. Todo lo que pregunto es cómo el sistema, como un tercero, podría determinar mejor que una aplicación de billetera de software realmente participó en una transacción BTC determinada, a la que se relacionan los metadatos. De tal manera que solo esa billetera puede tener acceso a esos datos.

Respuestas (1)

Abrí una transacción aleatoria para este ejemplo: https://blockchain.info/tx/c929454d6c83c15ecd9931c005a5a7fbacb1faba69f0a49538ab334d2848c5a1

Guiones de entrada:

ScriptSig:
PUSHDATA(72)[3045022100eb1d36c6fe6c201e5594d90a7bdc73dd9a33d291e7e58ba74fec46ab2139c9c602207a7124819f9a004a36a0a2ac494603cfeecf38b8c12b3c6e3ff6dea74053706101]
PUSHDATA(33)[033f2223c8f6b74e75e4afd05811b8c9f55c8584abef768336e6ad61d931bef548]

El primer valor hexadecimal es la firma de la transacción. El segundo valor es la clave pública (punto de curva elíptica). Y a partir de este valor podemos derivar la dirección.

Si tiene otra firma que firma algo, y esta firma tiene la misma clave pública , eso prueba que este es el mismo tipo que realizó la transacción. Solo alguien que tenga una clave privada puede firmar algo.

La criptografía elíptica funciona de la siguiente manera: elegimos un número aleatorio, y esta será la clave privada. Luego multiplicamos este número y el punto EC llamado generador, y obtenemos la clave pública.

Gracias, eso ayuda. Entonces, ¿tengo razón? Para la "aplicación" descrita anteriormente ("reconciliar" o "asociar" direcciones de entrada 1 o N tx enviadas a la aplicación desde alguna aplicación de billetera), debería ser 1). Solicitar que la billetera de Jane firme algunos datos 2). Solicitar que se envíe la firma resultante y Pubkey 3). Verifique que el documento firmado contenga los datos esperados descifrándolo con la clave pública proporcionada y 4). Si se verifica, compare la clave pública con la utilizada en la transacción de cadena de bloques deseada para afirmar la "propiedad"?
Para el paso 3. No puede descifrar nada con firmas. La clave pública se utiliza para la verificación. El procedimiento de verificación puede devolver 2 valores: la firma es válida o no. Acepta 2 parámetros: clave pública y datos. Se supone que los datos se codifican y luego se verifica el hash.
Correcto, entonces el proceso se convierte en: 1). Firmar datos sin procesar 2). Enviar sig + hash-data + pubkey 3). ¿Verificar? Pero lo que todavía me falta (¡lo siento!) es cómo la "verificación" fuera de la cadena de datos arbitrarios demuestra que la clave privada del remitente se usó para codificar el mensaje y está implicada en un TX de cadena de bloques determinado. Supongo que una vez que se completó la verificación del hash del mensaje en sí, el sistema podría verificar la cadena de bloques en busca de un TX con esa (s) entrada (s) de clave pública, pero la clave pública es diferente para cada entrada de TX, por lo que ¿no sería también diferente para este procedimiento fuera de la cadena también?
La "verificación" de datos arbitrarios demuestra que la clave privada del remitente se usó para codificar el mensaje: la clave privada se usa para firmar el cifrado, no para codificar el mensaje. Tienes razón, no puedes verificar nada fuera de la cadena. Debe estar seguro de que cierta transacción está dentro de blockchain. La clave pública en la entrada de TX significa que los bitcoins provienen de alguna dirección, y su procedimiento de verificación confirma que el propietario de esta dirección firmó algún mensaje.
Entiendo que las direcciones derivan de pubkeys. Lo que no entiendo es cómo una firma como parte de este proceso fuera de la cadena se relaciona con una clave pública, una dirección o cualquier otra cosa dentro de la cadena.
La firma se crea utilizando una clave privada, la clave pública y la dirección también se crean utilizando una clave privada.
Prueba de propiedad de la dirección
RespuestasAquíPolítica de privacidad1y, 0v