Topic: Trying to understand P2PKH mechanism almost there but not quite there. (Read 1439 times)

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.

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...

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.

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.


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.

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

Quote from: ggbtctalk000 on September 09, 2017, 11:15:23 AM

E(H(TX`)

There is no encryption, nothing is encrypted.

Quote from: ggbtctalk000 on September 09, 2017, 11:15:23 AM

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

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?

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.

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))).

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?

Execution looks like this:
1. value is pushed to the top of the stack => stack {signature}
2. value 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 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

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.

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???