Trying to understand P2PKH mechanism almost there but not quite there.

[ggbtctalk000]

I am going over locking and unlock scripts:
locking script: DUP HASH160 H(PUBKEY) EQ CHECKSIG
unlocking script: SIG PUBKEY
now EQ operation is easy: checking the hashed publeys and pubkeys are of same origin provided by locking and unlocking scripts by hashing the latter.
But CHECKSIG operation I understand technicals but struggling to understand what it is verifying:
Locking script provides H(PUBKEY) = BTC ADDRESS, Okay,
Unlocking script does supply PUBKEY and DIGITAL SIGNATURE.
But DIGITAL SIGNATURE = E(H(Plaintext) where E() is enc by priv key and H is hash function.
Verify by: D(E(H(plaintext) = H(plaintext) since D() by pubkey and E()  cancels each other out.
What remains is H(plaintext) which needs to be compared against. What is this value?
Hash public key??? which means plaintext = pubkey???

[1715498387]

1715498387

[1715498387]

1715498387

[aleksej996]

What remains is H(plaintext) which needs to be compared against. What is this value?
Hash public key??? which means plaintext = pubkey???

That value is a hash of the transaction itself. The client calculates the hash of the transaction and compares it with that hash. If it is correct then checksig returns a 0, and the transaction is valid.

[cdb1690]

Execution looks like this:
1. value <Signature> is pushed to the top of the stack => stack {signature}
2. value <Public Key> is pushed to the top of the stack => stack {signature; public key}
3. OP_DUP operator duplicates the top value on the stack and pushes result to the top of the stack => stack {signature; public key; public key}
4. OP_HASH160 hashes the top item on the stack with RIPEMD160(SHA256(x)) and pushes the resulting value to the top of the stack => stack {signature; publick key; public key hash}
5. value <Public Key Hash> from the locking script is pushed to the top of the stack => stack {signature; publick key; public key hash; public key hash}
6. OP_EQUALVERIFY operator compares the top two items on the stack and if they are the same, removes them form the stack => stack {signature; publick key}
7. OP_CHECKSIG operator checks if the signature matches the publick key and if so, it pushes TRUE value to the stack => stack {TRUE}

note: OP_EQUALVERIFY is a combination of two operators OP_EQUAL & OP_VERIFY
• OP_EQUAL consumes the top two items on the stack, compares them, and pushes true onto the stack if they are the same, false if not
• OP_VERIFY consumes the topmost item on the stack; if that item is zero (false) it terminates the script in failure
• OP_EQUALVERIFY runs OP_EQUAL and then OP_VERIFY in sequence

[ggbtctalk000]

What remains is H(plaintext) which needs to be compared against. What is this value?
Hash public key??? which means plaintext = pubkey???

That value is a hash of the transaction itself. The client calculates the hash of the transaction and compares it with that hash. If it is correct then checksig returns a 0, and the transaction is valid.

thanks that is what i suspect. it looks like in that case pub key still never leaves the sender. Wonder how the receiver gets the pubkey in that case used to verify the transaction?

[ggbtctalk000]

ok i think i figured out. this makes sense:

receiver to sender: receiver generates payment request which contains:
btc address H(pubkey)
amount=??
label=
message=
according to book. p17 mastering bitcoin
or receiver simply gives has H(pubkey) or bitcoin address to sender through e-mail or copy-n-paste whatever.

once sender receives this he generates locking script using the btc address + transaction (TX) itself:
DUP HASH H(pubkey) EQ CHECKSIG + TX

receiver makes the fund available to himself by providing unlocking script:
PUBKEY DIGITAL-SIGNATURE DUP HASH H(PUBKEY) EQ CHECKSIG.

During script execution on receiver's client, HASH(PUBKEY) = H(PUBKEY) and D(E(H(TX`)) = TX.

Now the only perplexing part still remains is TX`, where would get receiver this from?
Sure, he will definitely get the TX from sender but it does not make sense to E(H(TX)) and verify it back (D(E(H(TX))).

[aleksej996]

ok i think i figured out. this makes sense:

receiver to sender: receiver generates payment request which contains:
btc address H(pubkey)
amount=??
label=
message=
according to book. p17 mastering bitcoin

once sender receives this he generates locking script using the btc address
DUP HASH H(pubkey) EQ CHECKSIG

receiver makes the fund available to himself by providing unlocking script:
PUBKEY DIGITAL-SIGNATURE DUP HASH H(PUBKEY) EQ CHECKSIG.

During script execution on receiver's client, HASH(PUBKEY) = H(PUBKEY) and D(E(H(TX)) = TX

Well yes, but note that a payment request is absolutely unnecessary and usually isn't used. You just give someone the address and they send you coins.

Technically receiver has the funds available as soon as the sender sends a transaction with that locking script and it gets confirmed in a block.
When the receiver wants to spend the funds, he references the transaction in the blockchain and only provides PUBKEY DIGITAL-SIGNATURE,
which during validation of the transaction by the network is added to the top of unlocking script in the referenced transaction.

[ggbtctalk000]

ok i think i figured out. this makes sense:

receiver to sender: receiver generates payment request which contains:
btc address H(pubkey)
amount=??
label=
message=
according to book. p17 mastering bitcoin
or receiver simply gives has H(pubkey) or bitcoin address to sender through e-mail or copy-n-paste whatever.

once sender receives this he generates locking script using the btc address + transaction (TX) itself:
DUP HASH H(pubkey) EQ CHECKSIG + TX

receiver makes the fund available to himself by providing unlocking script:
PUBKEY DIGITAL-SIGNATURE DUP HASH H(PUBKEY) EQ CHECKSIG.

During script execution on receiver's client, HASH(PUBKEY) = H(PUBKEY) and D(E(H(TX`)) = TX.

Now the only perplexing part still remains is TX`, where would get receiver this from?
Sure, he will definitely get the TX from sender but it does not make sense to E(H(TX)) and verify it back (D(E(H(TX))).

Ok, after going through transaction format here the full picture I constructed:
LETS THIS IS TRANSACTION NO. X from PERSON A TO PERSON B:


Transaction
====================
4 bytes - version
VI bytes - #No  of inputs (for simplicity we assume one inputs (and one output too)
---
TX INPUT 0:
32 bytes - Prev. TX hash
4 bytes - Prev TX out index
VI bytes - TX script length
SigScript - Digital Signature + Pubkey (I assume digital signature here is constructed  by E(H(Prev.TX)) from which H(Prev.TX) itself is 32 bytes of input above, Pubkey is PERSON B'S (receiver's) PUBKEY.

4 bytes - sequence No.

(Now at this point, for the B to receive he construct OUTPUT below to complete the transaction.

TX OUTPUT 0:
32 bytes - TxOutHash
4 bytes - TxOutIndex
VI bytes - ScriptLen
ScriptPubkey - DUP HASH H(PUB) EQ SIGCHECK
4 Seq No.

Does it make sense?

[achow101]

receiver makes the fund available to himself by providing unlocking script:
PUBKEY DIGITAL-SIGNATURE DUP HASH H(PUBKEY) EQ CHECKSIG.

No. The receiver spends it only with <pubkey> <signature>. The rest is not needed in the input script.

E(H(TX`)

There is no encryption, nothing is encrypted.

Now the only perplexing part still remains is TX`, where would get receiver this from?

The TX' is a slightly different version of the transaction that is spending the output. This stackexchange question explains it: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

[aleksej996]

-snip-
TX INPUT 0:
32 bytes - Prev. TX hash
4 bytes - Prev TX out index
VI bytes - TX script length
SigScript - Digital Signature + Pubkey (I assume digital signature here is constructed  by E(H(Prev.TX)) from which H(Prev.TX) itself is 32 bytes of input above,

4 bytes - sequence No.

(Now at this point, for the B to receive he construct OUTPUT below to complete the transaction.

TX OUTPUT 0:
32 bytes - TxOutHash
4 bytes - TxOutIndex
VI bytes - ScriptLen
ScriptPubkey - DUP HASH H(PUB) EQ SIGCHECK
4 Seq No.

Does it make sense?

I can't check this format 100%, since I am not fully familiar with the exact format of the transaction, however I do understand the basics.
This is not correct in few places.

First, in a transaction where A sends to B, like the above example that you made, in the input is a script where A unlocks his funds (proves he has them).
In the output he locks them with the B's address (hash of his public key).

So in the input, B is not referenced. This input is just for A to unlock his funds, it has nothing to do with B. Input is placed at the start of the previous transaction's output. So the pubkey in the input belongs to A, this is why no one knows your public key until you spend the funds, only the hash of it.
So only in the output a hash of the B's pubkey (his address) is written.

Second, the digital signature is a signature for the current transaction (without a part of the script where signature is to be written of course, since this would create a loop where you need a signature to create a signature), not the signature of the previous one. This is to ensure that A is really the one who sent this transaction, as he is spending his coins he is the only one who needs to be able to create this transaction. Only A can sign this transaction with his private key, since we already said in the first problem that it is his public key that the signature is checked against.

There is no encryption, nothing is encrypted.

I believe that he mathematically deconstructed the signature here. As I understand, a signature of some message is just an encryption of the hash of the message with a private key.

[ggbtctalk000]

receiver makes the fund available to himself by providing unlocking script:
PUBKEY DIGITAL-SIGNATURE DUP HASH H(PUBKEY) EQ CHECKSIG.

No. The receiver spends it only with <pubkey> <signature>. The rest is not needed in the input script.

E(H(TX`)

There is no encryption, nothing is encrypted.

Now the only perplexing part still remains is TX`, where would get receiver this from?

The TX' is a slightly different version of the transaction that is spending the output. This stackexchange question explains it: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

Dude get some crash course in cryptography before teaching me a bitcoin. I am trying to sort out one of the most complicated part so no need to get it more complicated.

[pebwindkraft]

I'd like to throw my 2 cents in:
generally tx are a serialization of bytes, which are constructed as explained for P2PKH here: https://bitcoin.org/en/developer-guide#p2pkh-script-validation
what helped me alot to go through was this: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
good pictures and nice tables to understand the layout of a tx (obviously no segwit )
and this blockchain analyzer displays very nicely (with segwit): http://srv1.yogh.io/
I then created some shel lscripts for for decoding (and more) at the OpenBSD/Unix/OSX shells, there: https://github.com/pebwindkraft/trx_cl_suite
It displays and explains OpCodes in a tx...

[ggbtctalk000]

I actually see more problem with your response than the one I have with your statement.

"Your assumptions are mistaken." - I was asking for correction in case of mistakes are made, so no reminder

Pubkey is Person A's (senders) PUBKEY.

Are you saying Person A (sender) has pubkey? So your rationale i person A's pubkey is used to verify Digital Signature??
Well, dont tell me, sender's private key is used in this case??

Digital signature is constructed by:
E(H(Current.TX))

Current.TX is the serialized bytes of this transaction (inputs and outputs, without the signature of this input) being constructed by the sender.
I will give a more thought on that since I was not sry.


Below, you are challenging what i got from bitcoin.org, may be you can call out to 'em to correct their mistakes?

Quote from: ggbtctalk000 on September 09, 2017, 04:56:07 PM
4 bytes - sequence No.

(Now at this point, for the B to receive he construct OUTPUT below to complete the transaction.

No.

The sender (Person A) constructs the OUTPUT.

The receiver will construct an INPUT later, when he wants to spend the output in some future transaction that he sends.

Quote from: ggbtctalk000 on September 09, 2017, 04:56:07 PM
TX OUTPUT 0:
32 bytes - TxOutHash

Output does not contain a 32 byte hash

Quote from: ggbtctalk000 on September 09, 2017, 04:56:07 PM
4 bytes - TxOutIndex

Output does not contain a 4 byte TxOutIndex

Quote from: ggbtctalk000 on September 09, 2017, 04:56:07 PM
VI bytes - ScriptLen
ScriptPubkey - DUP HASH H(PUB) EQ SIGCHECK

Prior to the ScriptLen and the ScriptPubkey, the output contains:
4 bytes - value

Where value is a 4 byte integer representing the quantity of satoshis (0.00000001 BTC) being assigned to the output.

Quote from: ggbtctalk000 on September 09, 2017, 04:56:07 PM
4 Seq No.

Outputs do not have a Seq No.

Quote from: ggbtctalk000 on September 09, 2017, 04:56:07 PM
Does it make sense?


"
I think you are still misunderstanding some of the basics of how bitcoin transactions work. You are hyper focused on the cryptography and have overlooked how inputs and outputs are used."

- I am hyper focused on how bitcoin works using my crypto's base understanding, I believe it is natural to have a sound base of cryptography since whole bitcoin operation involves various forms of crypto. I am not sure what are you saying that I am focusing on cryptography and not on bitcoin.

[ggbtctalk000]

Pubkey is Person A's (senders) PUBKEY.

Are you saying Person A (sender) has pubkey?

Yes.

They have both the PUBKEY and the private key for their address that they used when they previously received the bitcoins prior to the creation of this transaction.

So your rationale is person A's pubkey is used to verify Digital Signature??

Correct.

Person A creates signature using private key.  Then, person A's pubkey is used to verify that signature.

Well, dont tell me, sender's private key is used in this case??

sender's private key is used to create signature.

sender's pubkey is used to verify signature.

Digital signature is constructed by:
E(H(Current.TX))

Current.TX is the serialized bytes of this transaction (inputs and outputs, without the signature of this input) being constructed by the sender.

I will give a more thought on that since I was not sry.

Ok.

4 bytes - sequence No.

(Now at this point, for the B to receive he construct OUTPUT below to complete the transaction.

No.

The sender (Person A) constructs the OUTPUT.

The receiver will construct an INPUT later, when he wants to spend the output in some future transaction that he sends.

TX OUTPUT 0:
32 bytes - TxOutHash

Output does not contain a 32 byte hash

4 bytes - TxOutIndex

Output does not contain a 4 byte TxOutIndex

VI bytes - ScriptLen
ScriptPubkey - DUP HASH H(PUB) EQ SIGCHECK

Prior to the ScriptLen and the ScriptPubkey, the output contains:
4 bytes - value

Where value is a 4 byte integer representing the quantity of satoshis (0.00000001 BTC) being assigned to the output.

4 Seq No.

Outputs do not have a Seq No.

Does it make sense?

"I think you are still misunderstanding some of the basics of how bitcoin transactions work. You are hyper focused on the cryptography and have overlooked how inputs and outputs are used."

- I am hyper focused on how bitcoin works using my crypto's base understanding, I believe it is natural to have a sound base of cryptography since whole bitcoin operation involves various forms of crypto. I am not sure what are you saying that I am focusing on cryptography and not on bitcoin.

What I am saying, is that achow101 gave you some very good information about how bitcoin transactions work.  Instead of paying attention to the important parts about what the receiver does, what's in the input, and what TX' is, you focus on whether or not a digital signature is a form of encryption or not.  And how that signature is verified. Then you scold achow101 for generalizing a difference between "encrypting" and "signing", and ignore the rest of what he said.

Start by understanding what a transaction is, and how a transaction works.  Then once you've got a good understanding of where the signature is, and what is signed, it will become obvious to you (because of your crypto's base understanding) how the sender creates the signature for the input script and how nodes use the input script of the current transaction and output script of the previous transaction to verify the signature.

Below, you are challenging what i got from bitcoin.org, may be you can call out to 'em to correct their mistakes?

Perhaps you misunderstood what you read at bitcoin.org.

Perhaps bitcoin.org has some errors.

Which part of what I said do you think is different than bitcoin.org?

dude, seriously i am not finding a single useful information from your post. if you were so smart, you could have mentioning good reason about why your arguments are right but instead you just said some crap that makes no sense and then started critisizing my post instead of filling my knowledge gap. If you were so good then by your advise, i would have improved my bitcoin transaction knowledge greatly and would have been thankful to you (as i did in other user forums in the past) but so far i am fighting with your useless post, wasting my time. I aint taking any of your advise about what to learn and what not, i am just doing what i know that i needed to do to understand it better. Anyways, this is the last reply to your useless posts.
I ain't interested in your advise buddy, just stay away if possible.

[ggbtctalk000]

YOU SURE ABOUT IT???
sender's private key is used to create signature.

Let me give you an example!!! This is taken from "Mastering Bitcoin" by Andreas 978 1 449 37404 4
On its p129:
Alice pay Bob's cafe TO BUY COFFFE ))
Two scripts together form this:

<CAFE SIGNATURE> <CAFE PUBLIC KEY> OP_DUP OP_HASH160 <CAFE PUB KEY HASH> OP_EQUAL OP_CHECKSIG

NOW ACCORDING TO YOUR STATEMENT, BOB'S CAFE SIGNATURE IS CREATED BY SENDER WHO IS ALICE (PAYING FOR COFFEE)

YOU ALREADY CHALLENGED WHAT I TOOK FROM BITCOIN.ORG AND NOW IF YOU CAN CHALLENGE THIS AUTHOR'S BOOK NOW IF YOU CAN EXPLAIN ME THAT OR PROVE AUTHOR WRONG, I AM GOING TO WORSHIP YOU!!!
FEEL FREE TO LOOK AT THE BOOK ONLINE OR PURCHASE IT IT IS UP TO YOU.
IF YOU CAN NOT AND START PUTTING ANOTHER LONG NON-SENSE, GO SOMEWHERE AND B.S OTHER'S POST!!!

DO NOT BOTHER ME WITH SOME GENERIC STATEMENT B.S. PLEASE, I HAVE BEEN DOING WHAT YOU HAVE BEEN ADVISING HERE BEFORE MY ORIGINAL POST BUDDY! IF YOU LOOK AT MY O.P, I AIN TLOOKING FOR GENERIC ADVISE BUDDY, LOOKING FOR VERY SPECIFIC ANSWER!

[aleksej996]

Alright, calm down people.
DannyHamilton and achow101 here are one of the most knowledgeable active users on this forum when it comes to technical stuff on Bitcoin. You will notice that achow101 is a moderator in the Technical Support board of this forum and by his username alone you can figure out his purpose here.
They are correct in what they say how transactions work and it fits with my knowledge of the protocol as well.

However, no one should stray of topic and criticize you either, you just came here to learn, no need to start any trouble. You both got way too emotional here. Just be cool and talk about the protocol.

Back on the topic a bit more:

Sender has to sign a transaction with his private key, otherwise anyone could make a transaction and spend his coins.
He makes the whole transaction and signs it, he doesn't need any information from the receiver other then his address, so no need for the receiver to make the output of the transaction.

<CAFE SIGNATURE> <CAFE PUBLIC KEY> OP_DUP OP_HASH160 <CAFE PUB KEY HASH> OP_EQUAL OP_CHECKSIG

This is a whole script obviously and no transaction has a complete script, it has two parts of two scripts. Input (unlocking funds) is used as a start of the script of the previous transaction's output (called input since it really is just data and no real op codes, just pushing on the stack, and it goes at the start, just like when you call functions in assembly).

This script is valid. Beginning of this script is input of the transaction that comes after the transaction with the output that is the second part of this script, like in every other transaction. Specifically, beginning of this script belongs to the transaction that cafe made to spend the funds they got from Alice and the second part is output of the transaction Alice made to send funds to the cafe.

[ggbtctalk000]

so I should believe this guy just because has been here and knowledgeable?
he virtually basically negated to major source of bitcoin technical materials and thinks he is right, lol and I should somehow discard what is written there and follow this guy at the same time being critisized??? Haha, WHAT A BIT-COIN-CIDENCE     

https://en.bitcoin.it/wiki/Transaction
...
A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key...

[ggbtctalk000]

so you did 6 years of exp!? What I should do, bravo? The fact you did dev work means really nothing to me. Did you contribute to open source bitcoin software? I hope not. if you do, no wonder why there are so much compilation and dependency problems with open-source. Not mean to troll you or your work, but I was rarely ever impressed by open source software's quality and proper programming.

1. I am a developer too with years of experience worked with many types, and i can assure you your tones and attitudes are in tunes with the ones that does not really do a good job and mess up a big time. (can start murmurng a whole lecture here but my time is precious)

2. If you want me to read  and digest your stuff, why dont u publish a book, and I will happily buy and read it, that would be beneficial for you. I ain't bother reading your post here, seriously, prefer reading printed pulblication however I appreciate your willing to help.

3. Yes, you got it completely right, I will struggle to get complete understanding of how it works that is how i approach only that but without your complication.

It seems like you really need to realize I can do very well on my journey to understating the topics concerning here w/o you.

[DannyHamilton]

2. If you want me to read  and digest your stuff, why dont u publish a book, and I will happily buy and read it, that would be beneficial for you. I ain't bother reading your post here
- snip -
I can do very well on my journey to understating the topics concerning here w/o you.

I apologize.  I didn't mean to waste your time with useful information.  I've removed my posts so as not to clutter up your thread.

[achow101]

so I should believe this guy just because has been here and knowledgeable?
he virtually basically negated to major source of bitcoin technical materials and thinks he is right, lol and I should somehow discard what is written there and follow this guy at the same time being critisized??? Haha, WHAT A BIT-COIN-CIDENCE  

https://en.bitcoin.it/wiki/Transaction
...
A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key...

You are horribly misunderstanding the page. The scriptPubKey is the output script of the output being spent. The scriptSig is the script of the input that spends the previous output. From the wiki:

scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

The only time a script like

Code:

<CAFE SIGNATURE> <CAFE PUBLIC KEY> OP_DUP OP_HASH160 <CAFE PUB KEY HASH> OP_EQUAL OP_CHECKSIG

is ever seen is during script validation where the output script is concatenated to the input script (note that this is not how script validation is done anymore by the same idea remains). This only occurs during validation and is never present in any transactions. This is also explained on https://bitcoin.org/en/developer-guide#p2pkh-script-validation, particularly in the diagrams provided there.


Side note: please stop with the aggressive behavior, insulting those who are trying to help you, and shouting (typing in all caps). Otherwise you will be temporarily banned for flaming and I will lock and delete this thread.