<p>I opened random transaction for this example: <a href="https://blockchain.info/tx/c929454d6c83c15ecd9931c005a5a7fbacb1faba69f0a49538ab334d2848c5a1" rel="nofollow noreferrer">https://blockchain.info/tx/c929454d6c83c15ecd9931c005a5a7fbacb1faba69f0a49538ab334d2848c5a1</a></p>

<p>Input scripts:</p>

<pre><code>ScriptSig:
PUSHDATA(72)[3045022100eb1d36c6fe6c201e5594d90a7bdc73dd9a33d291e7e58ba74fec46ab2139c9c602207a7124819f9a004a36a0a2ac494603cfeecf38b8c12b3c6e3ff6dea74053706101]
PUSHDATA(33)[033f2223c8f6b74e75e4afd05811b8c9f55c8584abef768336e6ad61d931bef548] 
</code></pre>

<p>First hex-value is signature of transaction. Second value is public key (elliptic curve point). And from this value we can derive address.</p>

<p>If you have another signature that signs something, and this signature has <strong>the same public key</strong>, that proves, that this is the same guy, who did transaction. Only one who have private key can sign something.</p>

<p>Elliptic cryptography works in the next way: we choose random number, and this will be private key. Then we multiply this number and EC point called generator, and we get public key.</p>

CC BY-SA 3.0
2017-08-28T10:58:08.240Z
Thank you, that does help. So am I correct then, that for the "application" outlined above ("reconciling" or "associating" 1 or N tx input addresses sent to the application from some wallet app), that it should 1). Request that Jane's wallet signs some data 2). Request that the resulting signature and Pubkey are sent 3). Verify the signed document contains the expected data by decrypting it with the provided Pubkey and 4). If verified,  compare the pubkey with the one used in the desired blockchain transaction in order to assert "ownership"?
theruss
CC BY-SA 3.0
2017-08-28T12:27:17.310Z
For step 3. You cannot decrypt anything with signatures. Public key is used for verification. Verification procedure can return 2 values: signature is valid, or not. It accepts 2 parameters: public key, and data. Data is supposed to be hashed, and hash then be verified.
Zergatul
CC BY-SA 3.0
2017-08-28T21:39:40.267Z
Right, so does the process therefore become: 1). Sign raw data 2). Send sig + hashed-data + pubkey 3). Verify?

But what I'm still missing (sorry!) is how off-chain "verification" of arbitrary data proves that the sender's prikey was used to hash the message, _and_ is implicated in a given blockchain TX. I suppose once verification of the message-hash itself was complete, the system could check the blockchain for a TX with that/those pubkey input(s), but the pubkey differs for each TX input, so wouldn't it also be different for this off-chain procedure too?
theruss
CC BY-SA 3.0
2017-08-28T21:53:30.617Z
"verification" of arbitrary data proves that the sender's prikey was used to hash the message - privkey is used to sign the hash, not to hash the msg. You are right, you cannot check anything off-chain. You have to be sure, that certain transaction is inside blockchain. Public key in TX input means bitcoins came from some address, and your verification procedure confirms, that the man who owns this address signed some message.
Zergatul
CC BY-SA 3.0
2017-08-29T07:32:36.897Z
I understand that addresses derive from pubkeys. What I do not understand is how a signature as part of this off-chain process, relates to a Pubkey, address or anything else on-chain.
theruss
CC BY-SA 3.0
2017-08-29T08:41:15.953Z
Signature is created by using private key, public key and address is created by using private key as well.
Zergatul
CC BY-SA 3.0
2017-08-28T09:19:38.477Z
2017-08-28T09:19:38.477Z
Zergatul
<p>This question appears many times on SO, but there's something in the answers I'm not getting.</p>

<p>I'm designing a system predicated upon API calls made to blockchain.info, but I'm having real trouble getting my head around the relationship between Pubkey, Address and digital signatures for my use-case.</p>

<p>Say user Jane has previously transacted using Bitcoin and we assume the transaction is confirmed on the Bitcoin blockchain. Jane now makes a request from her app-based wallet software for some metadata concerning that specific transaction via the system's web-service. </p>

<p>The web-service requires Jane to prove that her wallet really instigated that transaction in order to permit her wallet access to the data, but here I get a bit hazy: From all my reading over the last 6 or 7 days, I gather the wallet software would need to sign some pre-determined message containing e.g. the TXID using the wallet's private key, sign it and send it to the system along with the public key, but once the system receives the data, and can verify the message using the public key, so what? How does that prove the txid (or address or whatever) in that signed message, was signed by the same private key from which the transaction in question is indirectly derived? There's some part missing for me that "reconciles" remote blockchain data with the data sent from the wallet app.</p>

<p>I understand basic PKI and that addresses are hashed derivations of a public key, but the digital signature part is messing with my head.</p>

<p>Thanks for reading. Any help would be greatly appreciated.</p>

CC BY-SA 3.0
2017-08-28T11:11:52.827Z
Is there some specific reason you're doing it such a complicated, kludgey way? Is there some reason you can't do it a much more straighforward way? For example, why not have Jane pay to a specific address just for her that binds whatever she bought to her account or to some other credential?
David Schwartz
CC BY-SA 3.0
2017-08-29T08:34:28.363Z
The system I wish to build pertains to metadata about a btc transaction, almost none of which is available via the public blockchain, it will eventually be generated by the system. All I'm asking is how the system as some 3rd party, might best determine that a software wallet app  really took part in a given BTC transaction, to which the metadata relates. Such that only that wallet can have access to thw data.
theruss
<wallet><signature>
Proof of address ownership
theruss
# Proof of address ownership

(Asked by: username_0 on 2017-08-28)

This question appears many times on SO, but there's something in the answers I'm not getting.

I'm designing a system predicated upon API calls made to blockchain.info, but I'm having real trouble getting my head around the relationship between Pubkey, Address and digital signatures for my use-case.

Say user Jane has previously transacted using Bitcoin and we assume the transaction is confirmed on the Bitcoin blockchain. Jane now makes a request from her app-based wallet software for some metadata concerning that specific transaction via the system's web-service.

The web-service requires Jane to prove that her wallet really instigated that transaction in order to permit her wallet access to the data, but here I get a bit hazy: From all my reading over the last 6 or 7 days, I gather the wallet software would need to sign some pre-determined message containing e.g. the TXID using the wallet's private key, sign it and send it to the system along with the public key, but once the system receives the data, and can verify the message using the public key, so what? How does that prove the txid (or address or whatever) in that signed message, was signed by the same private key from which the transaction in question is indirectly derived? There's some part missing for me that "reconciles" remote blockchain data with the data sent from the wallet app.

I understand basic PKI and that addresses are hashed derivations of a public key, but the digital signature part is messing with my head.

Thanks for reading. Any help would be greatly appreciated.

**Tags:** wallet, signature

> **Comments:**
> **username_1**: Is there some specific reason you're doing it such a complicated, kludgey way? Is there some reason you can't do it a much more straighforward way? For example, why not have Jane pay to a specific address just for her that binds whatever she bought to her account or to some other credential?  
> **username_0**: The system I wish to build pertains to metadata about a btc transaction, almost none of which is available via the public blockchain, it will eventually be generated by the system. All I'm asking is how the system as some 3rd party, might best determine that a software wallet app  really took part in a given BTC transaction, to which the metadata relates. Such that only that wallet can have access to thw data.  

---

## 1 answers

### Answer by username_2 on 2017-08-28. Score: 1

I opened random transaction for this example: <https://blockchain.info/tx/c929454d6c83c15ecd9931c005a5a7fbacb1faba69f0a49538ab334d2848c5a1>

Input scripts:

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

```

First hex-value is signature of transaction. Second value is public key (elliptic curve point). And from this value we can derive address.

If you have another signature that signs something, and this signature has **the same public key**, that proves, that this is the same guy, who did transaction. Only one who have private key can sign something.

Elliptic cryptography works in the next way: we choose random number, and this will be private key. Then we multiply this number and EC point called generator, and we get public key.

> **Comments:**
> **username_0**: Thank you, that does help. So am I correct then, that for the "application" outlined above ("reconciling" or "associating" 1 or N tx input addresses sent to the application from some wallet app), that it should 1). Request that Jane's wallet signs some data 2). Request that the resulting signature and Pubkey are sent 3). Verify the signed document contains the expected data by decrypting it with the provided Pubkey and 4). If verified,  compare the pubkey with the one used in the desired blockchain transaction in order to assert "ownership"?  
> **username_2**: For step 3. You cannot decrypt anything with signatures. Public key is used for verification. Verification procedure can return 2 values: signature is valid, or not. It accepts 2 parameters: public key, and data. Data is supposed to be hashed, and hash then be verified.  
> **username_0**: Right, so does the process therefore become: 1). Sign raw data 2). Send sig + hashed-data + pubkey 3). Verify?  But what I'm still missing (sorry!) is how off-chain "verification" of arbitrary data proves that the sender's prikey was used to hash the message, _and_ is implicated in a given blockchain TX. I suppose once verification of the message-hash itself was complete, the system could check the blockchain for a TX with that/those pubkey input(s), but the pubkey differs for each TX input, so wouldn't it also be different for this off-chain procedure too?  
> **username_2**: "verification" of arbitrary data proves that the sender's prikey was used to hash the message - privkey is used to sign the hash, not to hash the msg. You are right, you cannot check anything off-chain. You have to be sure, that certain transaction is inside blockchain. Public key in TX input means bitcoins came from some address, and your verification procedure confirms, that the man who owns this address signed some message.  
> **username_0**: I understand that addresses derive from pubkeys. What I do not understand is how a signature as part of this off-chain process, relates to a Pubkey, address or anything else on-chain.  
> **username_2**: Signature is created by using private key, public key and address is created by using private key as well.  

---

