1

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.

Improve this question
2
  • 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
    Commented Aug 28, 2017 at 11:11
  • 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
    Commented Aug 29, 2017 at 8:34

1 Answer 1

Reset to default
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.

Improve this answer
6
  • 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
    Commented Aug 28, 2017 at 10:58
  • 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
    Commented Aug 28, 2017 at 12:27
  • 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
    Commented Aug 28, 2017 at 21:39
  • "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
    Commented Aug 28, 2017 at 21:53
  • 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
    Commented Aug 29, 2017 at 7:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.