Topic: Question about Bitcoin Digital signatures (Read 328 times)

Thanks for your time guys, everything is clear now !
It's great how people help each other on this forum

Assuming your question 2 is
Alice does not compare the 2 hashs. It's as simple as that, I think you misunderstood how are "sent" the coins. When Bob sends some coins to Alice, he sends a transaction unlocking some coins that have been locked for him, in order to lock them for Alice, to the whole network. Why send it to the whole network ? Because neither Alice or Bob have something such as coins on their computer, if some coins are transferred from Bob to Alice the whole network (or most of it) must verify the transaction then verify a block including this transaction which change the state of the global ledger and especially the coins that can be unlocked by Bob or Alice private key.

Actually, the hash is used and it is what is called the txid, but it is not what it secures the transaction in that case.

Elliptic Curve Cryptography is just math, and in the mathematical operations you are basically working with numbers. So when you want to sign something you convert that into a number and then perform your calculations using that number.
Signing needs to happen on anything. It can be 1 byte or it can be 1000 bytes. You can't calculate if everything else is 32 byte while you message size varies. So what you do is that you find a way to "shrink" the size of that message you want to sign to an always-the-same size. That is where Hash function comes in.
The hash function which is chosen needs to be secure so that there is no collision risk and since security level of secp256k1 curve is 128 bit we need to choose a hash function that has at least 128 bit security level. SHA256 has 258/2 bit or 128 bit security level. So it is used for bitcoin.

Now this "message" can be anything. In bitcoin when someone creates a transaction and signs it, there is a standard about what that "message" should be so everyone can easily calculate it too. In short it is serialization of the transaction with its script signature replaced by previous output's scriptpub and then hashed twice using SHA256.
So in other words to answer your second question above, the hash doesn't need to be included anywhere, it is easily calculated.

Great

And would you have a clue for my question 2 ? (I edited after I published it)

Yes. Every node receiving a transaction on the network verifies it before broadcasting it (verifying includes verifying its encoding, its signature(s) validity, etc..).

Thank you for this high-level explanation @darosior, @achow101 !
I understand it good now.

I just have a last interrogation about the validity check of signature and the hash:

1) Does Alice  (or the nodes of the network ?) verifies the signature, by checking if it can unlock Bob's public key provided in the transaction ?

2) The ECDSA algorithm hash the transaction and creates a signature using Bob's private key. Alice checks the signature using bob's public key so she is sure Bob sent the transaction, and verifies if the transaction was modified by trying to hash the transaction to see if the hash is the same that Bob sent to her ? But if you say that "the hash itself is not included anywhere", how can Alice compare the 2 hashs ?

I hope my questions are clear, I did my best ^^

Close. The transaction is signed with Bob's private key using ECDSA. ECDSA is an algorithm. You can read about how it works on Wikipedia

Alice verifies the signature with Bob's public key (provided in the transaction). She does not just decode it, but decoding (interpreting the values in a piece of data) is necessary to get the values inside of the signature.

Part of ECDSA is hashing the message to be signed. In this case, that is the transaction. The message hash itself is not included anywhere. However, because the message is provided (it's the transaction), we can easily compute the hash of it in order to verify the signature. if the transaction were modified, the hash would not match the hash that was used to create the signature, so the signature would not validate to true. Thus the transaction would be invalid.

Hi,

ECDSA stands for Elliptic Curve Digital Signature Algorithm and is therefore an algorithm used to create a signature from a message (here the transaction).
Now if Bob makes a transaction, the transaction is signed with a Digital Signature Algorithm using an Elliptic Curve and more precisely the secp256k1 curve (https://en.bitcoin.it/wiki/Secp256k1).
Actually she does not need to do that. Here is roughly what happens :
- Bob constructs a transaction. A transaction unlocks some coins in order to lock them (or part of them) so that only the receiver private key can unlock them. Actually being spent some coins to your address, it is just that someone made a transaction that locks coin that only your private key can unlock.
- Bob signs the transaction. To sign a message you must provide a private key, and unlocking some coins is, roughly, providing a valid signature (meaning "Hey, I have the private key !").
- The signature is then appended to the transaction (in a special field).
- The transaction is broadcasted to the whole Bitcoin network. (Alice knows about the transaction but her wallet says it is unconfirmed)
- The transaction is put in a block by a miner. (Alice know sees the transaction as confirmed)

Alice does not have to decode the signature, when the transaction is broadcasted every node of the network checks that the signature that Bob provided to unlock the coins is valid. A valid signature is a one which is from a private key corresponding to the address for which the coin have been locked.

Actually hashing the message is part of ECDSA, the transaction (=the message) is hashed (with a double sha256) and this is the hash which is signed.

English is not my first language so I don't know if I've been clear enough.

Thank you for answering guys

So if I get it right,

- The transaction is signed with Bob's private key + ECDSA (if you know the process or have an article about it, I would be interested)

- Alice can decode the signature with Bob's public key.


- So,  if the transaction is not hashed, how can Alice know if the transaction has been modified ?

Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the curve secp256k1. Part of ECDSA is that the message to be signed is hashed.

Hello guys,

I have a question regarding Bitcoin digital signatures :

On the Bitcoin network, when

- Bob sends a transaction to Alice's public Key and signs using his private key, what is the method used to sign ? In my understanding, the transaction would be hashed in SHA 256 and then encoded with the private key.

- Alice receives the transaction and needs to verify its validity : she decrypt the signature using Bob's public key, and this is where I don't really understand anymore. Like when she decrypts the signature, she then has the hash of the transaction right ? Because the transaction was hashed by Bob, so she can't immedialty get the original transaction at this moment, or she can ? So how can she get the original transaction with the hash of this transaction, because we can't reverse it, right ? Like if a document is hashed and encoded with a private key, then if I decrypt it with a public key, will I get the original document, or will I just get the hash of this document ?

- When she finally gets access to the transaction, then she would have to hash the transaction she received to compare the result with the hash she got ? This way she is able to know if it's bob who sent the document and if the document wasn't modified, right ?

Thank you to the guys who will respond, if any
I'm not really into cryptography or programming so it can be pretty hard to understand sometimes.