Topic: Question on the scriptSig and scriptPubKey - page 2. (Read 6322 times)

I see what you did there. 

Or more generally the concept of Asymmetric Cryptography (also known as public key cryptography).

Really to start understanding Bitcoin one needs to have a very good understanding of the following concepts:
Cryptographic Hash Function
Asymmetric Cryptography
Digital Signatures
Cryptographic Nonce  <- used in mining not transactions

(Some wikipedia links to get the OP started).

Note I didn't reference a specific hash function or the asymmetric cryptography algorithm used.  It is important to understand in general terms what these are, how they work, and why they are used.   For example why do we use a cryptographic hash instead of the original value?  What does a digital signature prove?  How can we verify the authenticity of a digital signature with the public key if it was signed by the private key?

Then one should be familiar with the algorithms used:
SHA-256 (cryptographic hash function)
RIPEMD-160 (cryptographic hash function)
ECC (Elliptical Curve Cryptography)
ECDSA (ECC Digital Signature Algorithm)
SECP256K1 (specific ECC curve used by Bitcoin

One doesn't need to know for example the internal dataflow of SHA-256 but one does need to know what it is and at a high level how it works. Purpose?  Block size? Hash size?


None of these are Bitcoin specific and if someone doesn't have a fairly good understanding of them, then any explanation on Bitcoin really becomes a confusing mess of Bitcoin concepts AND the underlying cryptographic concepts.

It would be like trying to learn double entry bookeeping without understanding arithmetic.  It simply can't be done.  

It sounds to me like you are struggling to understand what ECDSA (Elliptic Curve Digital Signature Algorithm) is and how it works.  This is a well established and widely used cryptographic algorithm for "signing" information using a private key in such a way that anyone with the associated public key can prove that the signature could only have been provided by the holder of the private key.  The private key is never revealed (which is why it is called "private"), but the public key must be revealed (which is why it is called "public").  I don't fully understand the process, but it has been vetted by enough people that I trust it.

You can find some of the process involved here:
http://en.wikipedia.org/wiki/ECDSA

When sending bitcoin, the bitcoin address is provided in the output but the public key is not.  It is not possible to determine what the public key is if you only have the bitcoin address.

Since the public key is required to verify the signature, and since the owner of the private key can easily/quickly calculate both the public key and the bitcoin address, the owner of the private keys scans the blockchain for outputs that are associated with addresses that can be generated from those private keys.  Then they choose one and calculate the public key from the private key.  The public key is then presented along with the signature in the scriptSig.

Now there is enough information available to prove that the spender has the right to do so.  Being given the public key in the scriptSig means that anyone can:
To verify that the resulting bitcoin address is the same as the address provided in the previous output.

Being given the public key and the signature in the scriptSig means that using ECDSA, anyone can confirm that the signature provided could only have been provided by a person who holds the private key associated with the given public key.

Since the public key and signature provide proof of control of the private key, and the public key can be confirmed as the correct public key for the given address, authorization to spend the previous output is verified.

Understanding the fact that a signature created by a private key can be verified with the public key, and that the same signature cannot be created with the public key is essential to understanding how the bitcoin transaction verification process works.  Understanding how and why the signature can be verified and how and why the same signature can't be created if you only have the public key is not essential to understanding how the transaction verification process works.

You'll probably want to seek out a cryptography forum if you really want to understand the internals of SHA-256, RIPEMD-160, and ECDSA.

The magic of public key crypto is that you can give somebody your public key, some data, and a signature, and they can be certain that:

a) that particular signature could only have been created by somebody that has the private key that corresponds to the public key
b) the data hasn't been changed in any way

They don't need to know the private key-- you keep it secret.

The "hash over..." bit is the way digital signatures work-- you sign a hash of the data, and not the data itself, because the hash is much smaller.

The "...simplified version of the transaction" bit is complicated. The data signed is the transaction minus all it's scriptSig signatures, plus (almost always) the previous transaction's scriptPubKey. See the OP_CHECKSIG page on the wiki for all the gory details.

Look at the picture on that page.  It shows that the transaction signature includes both the signature and the pubkey that verifies the signature.  We then hash the pubkey and compare it to the hash embedded in the prevout.

The wikipedia page explains, in a way, how the signature is actually calculated.  The OP_CHECKSIG page on the bitcoin wiki goes into some detail on the simplification stage.

Not very long and I'm back with more questions. I've learned quite a bit about Bitcoin through my pursuits on here and now I have more technical questions. Right now I'm studying the scriptSig of the input portion of a transaction and the scriptPubKey of the output portion of a transaction. I've found some answers and understand aspects but others I don't.

Pertaining to the scriptSig I see the two aspects, public-key and the signature. I a m comfortable with the public-key aspect. When you try to spend BTC you refer back to the output of the previous tx and the program hashes your public-key thus finding the your address and since the preceding output sent the BTC to your address it is verified you have the key. That seems simple to me, now at least.

When it comes to signature portion of it I'm lost. I know that somehow your private-key you provide verifies your public-key through hashes. This makes sense, I understand how that happens. My question is how do you provide your private-key to the input of your tx to process it and find a line-up with your public-key without putting your private-key in the record? Does the process just use the private-key but do nothing else with it? Also I know you sign a hash of the tx and I get how the hash is made from the tx. But what exactly is that signature? Is it a hash of a combination of a your private and public-key? I found this information:

"The script contains two components, a signature and a public key. The public key belongs to the redeemer of the output transaction and proves the creator is allowed to redeem the outputs value. The other component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment."

here: https://en.bitcoin.it/wiki/Transactions

and I'm trying to understand the italicized part.