Some doubts about transactions validation

[fabbit]

Good evening, I have some doubts about transactions validation. Always referring to this link https://bitcoin.org/en/transactions-guide#introduction

After putting his signature and public key in the signature script, Bob broadcasts the transaction to Bitcoin miners through the peer-to-peer network. Each peer and miner independently validates the transaction before broadcasting it further or attempting to include it in a new block of transactions.

If the transaction is between Alice and Bob with Alice as sender and Bob as receiver, after Alice checks the sign with OP_CHECKSIG operation, why, as stated above, the transaction has to be validated by every node of the network?

Another thing, after a block has a certain number of transaction the block is validated and inserted in the blockchain with the PoW algorithm?

Thanks,

[1713561254]

1713561254

[1713561254]

1713561254

[1713561254]

1713561254

[1713561254]

1713561254

[nc50lc]

If the transaction is between Alice and Bob with Alice as sender and Bob as receiver, after Alice checks the sign with OP_CHECKSIG operation, why, as stated above, the transaction has to be validated by every node of the network?

That's how "trustless" works, nodes don't trust other peers and must validate each transaction and blocks before accepting/relaying it to others.

Another thing, after a block has a certain number of transaction the block is validated and inserted in the blockchain with the PoW algorithm?

No, it can only have the coinbase transaction (mining reward) and still be valid.

[HCP]

Another thing, after a block has a certain number of transaction the block is validated and inserted in the blockchain with the PoW algorithm?

No. Miners are free to pick and choose any number of transactions they would like to include in a block... up to the max block size weight limit.

So, as nc50lc has said, they can include none if they want and just have the coinbase reward. However, they are incentivised to include as many as possible by being rewarded the transaction fee from each transaction they include. This is (generally) why miners prioritise transactions that pay the best fee rate... highest fee per weight. Sometimes, there just aren't many unconfirmed transactions available, so miners will generally just include everything they can to maximise their reward... other times, they have a surplus (ie. more than 1 full blocks worth), so they can pick and choose the most profitable.

[fabbit]

I don't understand, if the transaction is p2pkh from Alice to Bob and they have scripts to verify the transaction, how can other nodes verify the transaction? I mean the other nodes don't have the scriptPubKey and the scriptSig referring to Alice and Bob.

And referring to this

Another thing, after a block has a certain number of transaction the block is validated and inserted in the blockchain with the PoW algorithm?

The PoW algorithm validates a block made up of transactions, while the scripts validate transactions, I mean are they two different and separate things?

[squatter]

I don't understand, if the transaction is p2pkh from Alice to Bob and they have scripts to verify the transaction, how can other nodes verify the transaction? I mean the other nodes don't have the scriptPubKey and the scriptSig referring to Alice and Bob.

Other nodes do validate these scripts. Full nodes enforce OP_CHECKSIG on all transactions, which verifies the public key and signature of each script. If the scripts don't pass validation, the transaction is considered invalid and will not be propagated to the network.

OP_CHECKSIG is script opcode used to verify that the signature for a tx input is valid. OP_CHECKSIG expects two values to be on the stack. These are, in order of stack depth, the public key and the signature of the script. These two values are normally obtained by running the scriptSig script of the transaction input we are attempting to validate. The scriptSig script is deleted after it is run, but the stack is left as is. Then, the scriptPubKey script from the previous transaction output that is now being spent is run, generally concluding in an OP_CHECKSIG.

The standard scriptPubKey checks that the public key (actually a hash of) is a particular value, and that OP_CHECKSIG passes.

For normal transaction inputs, if the creator of the current transaction can successfully create a ScriptSig signature that uses the right public key for the ScriptPubKey of the transaction output they are attempting to spend, that transaction input is considered valid.

[mikeywith]

A short answer:

Every full nodes functions as if it's the only node out there, it trusts no other node, Alice and Bob's verification aka "their words for it" mean nothing to all other nodes, every full node needs to verify the transaction. The moment Alice broadcast a transaction she needs to provide the scripts for everyone else to validate. Unless Alice has a mining node and she includes that transaction in the block first, mine it and then broadcast the whole block and even then if the transaction is not valid-the other full nodes will reject the whole block.

I don't understand, if the transaction is p2pkh from Alice to Bob and they have scripts to verify the transaction, how can other nodes verify the transaction? I mean the other nodes don't have the scriptPubKey and the scriptSig referring to Alice and Bob.

In fact, nobody has the scriptPubKey and scriptSig except Alice, not even Bob! , Alice MUST include them in the transaction and broadcast it for the transaction to go through.


If you want slightly more detailed answer keep reading

I don't understand, if the transaction is p2pkh from Alice to Bob and they have scripts to verify the transaction, how can other nodes verify the transaction?

To get a clearer understanding of how transactions work, you should first think of it this way: bitcoin does not travel from Alice's wallet to Bob's wallet because Bitcoin was never in Alice's wallets to begin with. All that Alice has is the private key needed to spend an x amount of unspent transaction output (UTXO).

The blockchain that each full node keeps a copy of has the information of every single unspent outputs out there.  Alice creates scriptSig to prove her ownership of that amount of bitcoin she wants to send and creates scriptPubKey which is in simple English is Bob's public key hash so that amount of UTXO can only be spent by Bob.

Bob will then undergo another scriptSig using his signature and public key to prove that the current inputs (previously outputs from Alice) actually do belong to him when/if he needs to spend them.

So Alice initiate the transaction and then broadcast it to the blockchain. Let us assume she uses Exodus wallet, the transaction will be first sent to Exodus's full node, it will verify it and if everything is in place, it will broadcast it to every node around it. Those nodes will broadcast the transaction to the nodes around them and so on; every node will verify the validity of the transaction before it actually is broadcasted. Eventually Alice's transaction will end up in a mempool of a mining node after that mining's full node has verified the transaction too (theoretically, it will end up in all mempools of all mining nodes aka mining pools running full nodes).

Up to this point, Bob can't spend the anything that Alice "theoretically sent" despite the fact that everyone knows by now that Alice gave up ownership on x amount of BTC to Bob, because if he tries to do so, his transaction will be invalided because the transaction does not exist in mined block (not in the blockchain).
In other words, it is only Alice's words to Bob that he will be able to spend those outputs; as long as it was not added to a mined block- it simply means nothing. Therefore, when one of the miner's picks Alice's transaction and add it to the block, Bob can then spend that bitcoin if he has the private key and can actually create a scripSig, because now (officially) the transaction is on the blockchain.

The PoW algorithm validates a block made up of transactions, while the scripts validate transactions, I mean are they two different and separate things?

Full nodes validate transactions, Mining nodes write them on the Blockchain (after verifying them and picking the once that pay the most or the once they want to pick for whatever reason). For a transaction to be considered completed, it must be verified by full nodes and put in a block by a miner, BOTH must happen for Bob to be able to spend the BTC he received.

[pooya87]

The PoW algorithm validates a block made up of transactions, while the scripts validate transactions, I mean are they two different and separate things?

yes they are entirely different.
PoW is proof of work, as the name suggests it is a proof that the miner has done a certain amount of work to find the hash. in simple terms think of it like this, i ask you to give me a message that has 5 letters in it and hash of it starts with 0. now you have to set the letters (aaaaa, aaaab, aaaac,... zzzzz) and hash until you find what i was looking for. when you publish that message i can know that you have done work.
read this for technical explanation: https://en.bitcoin.it/wiki/Proof_of_work

script validation or basically validating a transaction has a couple of parts. first is a lookup in the database (aka blockchain) to see if the output that is being spent is spendable (like hasn't been spent before) then next step is taking the output script from that previous transaction in the blockchain and use it in the new tx that you want to verify. in P2PKH you use a hash function and ECDSA signature verification to validate the pubkey hash and signature respectively.
this may be helpful: https://bitcoin.stackexchange.com/questions/64455/how-blockchain-transaction-verification-takes-place

[fabbit]

Thanks for answering,

To get a clearer understanding of how transactions work, you should first think of it this way: bitcoin does not travel from Alice's wallet to Bob's wallet because Bitcoin was never in Alice's wallets to begin with. All that Alice has is the private key needed to spend an x amount of unspent transaction output (UTXO).

The blockchain that each full node keeps a copy of has the information of every single unspent outputs out there.  Alice creates scriptSig to prove her ownership of that amount of bitcoin she wants to send and creates scriptPubKey which is in simple English is Bob's public key hash so that amount of UTXO can only be spent by Bob.

I don't understand why you're talking about Alice's private key and scriptSig if the transaction is between Alice and Bob, I mean in every guide I read there is a transaction between Alice and Bob and Alice has the scritpPubKey and Bob has the scriptSig.
I think you're saying about that before Alice can send bitcoin to Bob, she has to receive bitcoin from another transaction for example a transaction Cindy-Alice and so Alice has the private key to spend UTXO, are you referring to this?

The PoW algorithm validates a block made up of transactions, while the scripts validate transactions, I mean are they two different and separate things?

this may be helpful: https://bitcoin.stackexchange.com/questions/64455/how-blockchain-transaction-verification-takes-place

I read the article and I don't understand this "their software will use the private key of an unspent output (a 'bitcoin') to cryptographically sign the transaction. This signature proves ownership of the unspent output, and authorizes movement of the coins."
It says that the transaction is signed by utxo, but the sign is in the scriptSig so in the input..

And the other thing I don't understand is this:
A transaction between A (sender) and B (receiver), so A and B have the scripts and using op_checksig the transaction is validated. In which way the other nodes validate the transaction? I mean then B broadcasts the transaction and the transaction is received by C and now B and C have the scripts. I don't know if I explained me clearly.

Thanks,

[figmentofmyass]

And the other thing I don't understand is this:
A transaction between A (sender) and B (receiver), so A and B have the scripts and using op_checksig the transaction is validated. In which way the other nodes validate the transaction?

the transaction data received by other nodes includes the scriptSig and scriptPubKey. other nodes validate the transaction the same way, with op_checksig.

I mean then B broadcasts the transaction and the transaction is received by C and now B and C have the scripts.

the sender broadcasts the transaction to the network. the receiver plays no role in broadcasting/propagating the transaction.

every node that receives it gets the associated scriptSig and scriptPubKey to validate the transaction. assuming op_checksig passes, they will continue propagating it to other nodes.

[fabbit]

the sender broadcasts the transaction to the network. the receiver plays no role in broadcasting/propagating the transaction.

According to this: https://bitcoin.org/en/transactions-guide#introduction

Alice broadcasts the transaction and it is added to the block chain. The network categorizes it as an Unspent Transaction Output (UTXO), and Bob’s wallet software displays it as a spendable balance.

And

After putting his signature and public key in the signature script, Bob broadcasts the transaction to Bitcoin miners through the peer-to-peer network. Each peer and miner independently validates the transaction before broadcasting it further or attempting to include it in a new block of transactions.

[mikeywith]

I think I understand where the confusion comes from after reading your reply to my last post, I think it all goes down to the lack of understanding of basic cryptography, public and private keys encryption in general.

You think that Sigscript is private information that can be used to spend bitcoin if revealed to others, allow me to explain this in a much simpler way.

Think about it this way, Alice is writing a check for Bob, Alice's signature (scriptSig) is PUBLIC information which everyone in the bank knows, but they all can't make an exact similar one, Alice writes Bob's account number (scriptPubKey) on the check, that account number is PUBLIC information.

You might wonder how can these information be PUBLIC yet nobody can create them except for Alice? well this is what cryptography and hashing is all about

scriptSig(S) = Alice's Signature(A) + Alices's public key (P)

P = public
S=  public
A= Private

to create (S)  you must have A and P,  knowing S and P can't give you (A), it's like mixing colors, it's easy to know the color you get if you mix blue(A) and red(P), but looking at Fuchsia (S) you can't really tell what colors were mixed together to get that exact grade, unless you keep trying all different colors and ratios (brute force).

ScriptPubKey  = in a nutshell is (Bob's Bitcoin Address) which is the hash of a public key

I think you're saying about that before Alice can send bitcoin to Bob,

Yes in my previous post,  I tried to explain how things work prior to Alice sending to Bob, because Alice needs to receive before she can send.

It says that the transaction is signed by utxo, but the sign is in the scriptSig so in the input..

Input is the new form of a previous output, you take an output, Sigcript it and put it in an input , in other words

A sends BTC to B, then B sends BTC to C, then C sends to D

imagine that Input is a banana, output is the same banana but peeled.

A has a banana which he sends to B and call it input, B received the banana from A, peel it and call it output, If B wants to send the banana to C he needs to seal it again ( you can't send peeled bananas they become contaminated) once sealed- it's called input again, C receives the banana, peel it, and it becomes output.

so an input is nothing but signed output/s (UTXO)

And the other thing I don't understand is this:
A transaction between A (sender) and B (receiver), so A and B have the scripts and using op_checksig the transaction is validated. In which way the other nodes validate the transaction? I mean then B broadcasts the transaction and the transaction is received by C and now B and C have the scripts. I don't know if I explained me clearly.

A,B,C,D,E,F......Z can see the scripts but only B can spend them, if you refer to the check example I gave above, A writes a check to B , he can publicly send it via the mail to B, everyone sees a million dollar check signed by A and going to B, they all know the check is valid because A's balance which is public information is => 1 million $, B's account number is a valid account number which is also public information, ONLY B can now spend that 1 million dollars once he proves his ownership to that account number.

I hope that by now a bit of confusion is now gone, I also hope i haven't made it even worse for you.  

[nc50lc]

That signing and verification works the same way as "digital signature scheme": read wikipedia (or just check the image)
Alice needs to include her public key and signature to the "RAW transaction" (will be Signed RAW transaction) before it can be broadcast to the network.
As explained in the image, it's the only information every node needs in order to verify if it's really the correct private key that signed the transaction.

BTW, Bob (the receiver) doesn't have to do anything in that transaction but to wait for his wallet/node's mempool to receive the transaction from his peers after Alice broadcast it.
After it got accepted by his node, it will be displayed as "unconfirmed transaction" (he can already spend it depending on the client/settings)
After it got accepted by a mining node and got included to a new block, they will relay it to their peers and will eventually reach Alice and Bob' nodes.
After being accepted by their nodes and verified that it's valid, the unconfirmed transaction will be deleted from their mempool and the wallet will display it as "1 confirmation".

imagine that Input is a banana, output is the same banana but peeled.

It wasn't supposed to be funny but the 'banana analogy' made me laugh :D

[fabbit]

Thanks, the thing that was confusing me was that you were referring to the Alice's previous transaction.
Having A->B transaction only B can spend, but every nodes of the network have to validate the transaction.
A and B execute this script <Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG  to validate the transaction and so permitting B to spend. What do other nodes do to validate A->B transaction?

[mikeywith]

A and B execute this script <Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG  to validate the transaction and so permitting B to spend. What do other nodes do to validate A->B transaction?

No!

Only A executes that script, the nodes verify it and tell B that the script is valid and that now B is the new rightful owner to those outputs.

B does not need to verify anything for the transaction to go through, once his pubkey is known, he has no saying on whether A can send him some bitcoin or not.

if A has the outputs to send, and he can sign them to prove his ownership, and he uses a correct address to send to, the nodes will allow the transaction to go to a mempool and then miners will add it to the block and it gets confirmed.

If you still don't get it, you should learn more about what nodes actually do.

[fabbit]

Ah okay now I understand.
But I think I am missing this two point:
1)How do the other nodes validate the transaction between A and B?
2)Why do we have the OP_EQUALVERIFY? It permits to check the two pubkeys at the top of the stack, but why do we need to check them?

Thanks,

[DannyHamilton]

Transaction contains:

• A list of inputs indicating where to find the value that is being spent by the spender, and meeting any requirements that must be met to be allowed to spend that value.
• A list of outputs encumbering value with a requirement that must be met if that value is to be spent in the future.

The list of inputs contains:

• An identifier (transaction hash and index) that can be used to look up the previous transaction (which encumbered the value being spent with some requirement that must be met)
• Some data that meets the encumbered requirements set by the previous transaction set (typically called Txin-script or scriptSig)

The list of outputs contains:

• Some value
• Some data that sets the requirements that must be met in order to spend that value (typically called Txout-script or scriptPubKey

The entire transaction (the full list of inputs including all the scriptSig, AND the full list of outputs including all the scriptPubKey) is broadcast to all nodes.

Therefore, all nodes can use the identifiers from the list of inputs to go look at the previous transactions and see what requirements must be met (typically a particular signature is needed, along with some script commands and a public key).  This allows everyone (Alice, Bob, and all full nodes) to use the scriptPubKey from the previous transaction (which encumbered the value with the requirement) and the scriptSig from the current transaction (which meets the requirements of that encumbrance) to verify that the requirements have been met.

The recipient of the value (Bob?) can make sure that he is able to meet the new requirements from the value in the list of outputs.  Any value that is encumbered with requirements that Bob is capable of meeting is value that Bob can spend in the future (by creating an input that refers to that output AND providing in that input the scriptSig that meets the requirements).


Note that nothing actually gets sent "from" the spender (Alice) "to" the person receiving the value (Bob).
(Alice can send the transaction directly to Bob if she or he would like that, but it isn't a necessary action. Bob can always just get the transaction from the blockchain later once it has been confirmed into a block. As long as Bob is able to meet the requirements of the output scriptPubKey in the future, he has control over that value.)

The person receiving the value (Bob) needed to provide the spender (Alice) some information BEFORE the transaction was created (typically the hash of a public key for which they have the private key), so that the spender can use that information when building the scriptPubKey for the transaction outputs.

Then once the spender builds the transaction, they broadcast it to all nodes that they are connected to.  Those nodes use the information from the list of inputs to verify that the spender (Alice) is authorized to spend that value, and that the transaction is structured in the standard way.  If they've determined that the transaction is valid, they then re-broadcast the transaction to all the nodes that they are connected to (who then use the information from the list of inputs to verify that the spender (Alice) is authorized to spend that value, and that the transaction is structured in the standard way).  This process of verifying and re-broadcasting repeats until effectively everyone on the network (including Bob, any mining pools, and any solo miners) has a copy of the transaction.

None of the nodes know that Bob is the person that will have control over the value.  They just know that ANYONE can spend the value in the outputs AS LONG AS THEY CAN MEET THE REQUIREMENTS OF THE scriptPubKey.  Typically, the spender (Alice) and the person receiving the value (Bob) are the only people that know that Bob is the one that will be capable of meeting those requirements when he wants to spend that value in the future.

[fabbit]

Thanks, it is much more clear now. But why do we need to do OP_EQUALVERIFY? I mean what are the security issues if we don't execute that operation?

[mikeywith]

Thanks, it is much more clear now. But why do we need to do OP_EQUALVERIFY? I mean what are the security issues if we don't execute that operation?

That function ensures the previously received outputs were sent to the same hash ( address) that is trying to now spend the outputs.

When Alice creates the scriptPubKey she locks those outputs to Bob's public key, those outputs can only be re-sent/spent by unlocking this script. Once Bob wants to send to Sara he will take that output and create his own ScriptPubkey, technically using Alice's outputs.

 OP_EQUALVERIFY ensures that both hashes (public key address) from Alice's output which now Bob's input to Sara are equal (both hashes belong belong to Bob).

[DannyHamilton]

We start with:

An empty processing stack

A txin-script (scriptSig) provided by the person spending the value to prove that they have the necessary private key. While anyone could provide the public key, only a person with the private key can provide a signature that will match that public key.

• <signature> <publicKey>

A txout-script (scriptPubKey) obtained from the previous transaction (when the spender previously received the value that they are now spending).

• OP_DUP OP_HASH160 <publicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

The txin-script and the txout-script are concatenated together resulting in a verification script of:

• <signature> <publicKey> OP_DUP OP_HASH160 <publicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Then processing of the script begins (left to right)

The two constants are pushed onto the stack resulting in a processing stack of:

• <publicKey>
• <signature>

Leaving behind a verification script of:

• OP_DUP OP_HASH160 <publicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

OP_DUP is performed (popping the top element, <publicKey>, off the stack, duplicating it, and pushing both values back onto the stack), leaving behind a verification script of:

• OP_HASH160 <publicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

The processing stack is now:

• <publicKeyDuplicated>
• <publicKey>
• <signature>

OP_HASH160 is performed (popping the the top element,<publicKeyDuplicated>, off the stack, hashing that value with RIPEMD160, and pushing the result back onto the stack), leaving behind a verification script of:

• <publicKeyHash> OP_EQUALVERIFY OP_CHECKSIG

The processing stack is now:

• <publicKeyHashComputed>
• <publicKey>
• <signature>

The next constant is pushed onto the stack, leaving behind a verification script of:

• OP_EQUALVERIFY OP_CHECKSIG

The processing stack is now:

• <publicKeyHash>
• <publicKeyHashComputed>
• <publicKey>
• <signature>

OP_EQUALVERIFY is performed (popping the top two elements off the stack and verifying that they are equal). This verifies that the <publickKey> provided by the spender hashes to the same value as <publicKeyHash> that is stored in the transaction where that spender previously received what they are now spending.

If we didn’t have OP_EQUALVERIFY here, and instead performed OP_CHECKSIG now, then we would be popping off the two copies of the public key hash, <publicKeyHash> and <publicKeyHashComputed>, and treating one as a public key and the other as a signature. We’d then try and verify that <publicKeyHashComputed> was a signature that is verifiable by using the <publicKeyHash> as a public key.  Clearly this wouldn’t work at all.

Instead, what we want to do is verify that the <publicKey> provided by the spender in the txin-script is the correct public key (verify that it hashes to the same value as was stored in the txout-script of the transaction where the spender received what they are now spending).

After this step is done OP_CHECKSIG can be performed (popping off the remaining two elements on the stack, <publicKey> and <signature>, and verifying that the signature provided was computed with the private key that matches the provided public key.

Notice that the public key is not stored in the txout-script, only the RIPEMD160 hash of the public key. An attacker could try to sign a transaction with any private key at all.  Verifying the signature requires a public key to make sure that the signature was generated with the CORRECT private key. This verification can’t be performed with the RIPEMD160 hash of the public key.

In order to prevent an attacker from providing the wrong public key (one that works with their own private key instead of the intended private key), the provided <publicKey> is hashed, and then compared (by way of OP_EQUALVERIFY) to the <publicKeyHash> that is stored in the txout-script. This forces the spender to provide the CORRECT <publicKey>, and then OP_CHECKSIG is used to force the spender to provide a <signature> that can be verified with the <publicKey> that they provided.