Does the bitcoin validate the taproot script path commitment?

[Hashblock]

Hello guys, I’m new here. But not new to bitcoin actually, while trying to understand one specific part of taproot transactions validation. I had so many thoughts and questions.
Assuming a taproot output was created with internal key p and a script tree with merkle root m. Output is:
Q= p+ H_TapTweak( p || m) G
When sending the script path, the witness provides the script, stack elements and a control block.
Now my question is how exactly does the bitcoin node proves that this revealed script actually belongs to the taproot output being spent?

[athanred]

how exactly does the bitcoin node proves that this revealed script actually belongs to the taproot output being spent?

By hashing a given TapScript, and checking, if secp256k1 point addition matches.

Let's say, that you have some public key:

Code:

P=02BB0CC84DB7B318CB9F3521B809530440DE0870F8E53D075298D06B10018162B8

And now, let's say, that you have some message, which you want to commit into it:

Code:

SHA-256("message")=ab530a13e45914982b79f9b7e3fba994cfd1f3fb22f71cea1afbf02b460c6d1d

Now, both things can be combined under some new public key, exactly as you described:

Code:

Q=P+H_TapTweak(p||m)G
P=02BB0CC84DB7B318CB9F3521B809530440DE0870F8E53D075298D06B10018162B8
p=bb0cc84db7b318cb9f3521b809530440de0870f8e53d075298d06b10018162b8
m=ab530a13e45914982b79f9b7e3fba994cfd1f3fb22f71cea1afbf02b460c6d1d
SHA-256("TapTweak")=e80fe1639c9ca050e3af1b39c143c63e429cbceb15d940fbb5c5a1f4af57c5e9
H_TapTweak(p||m)=SHA-256(e80fe1639c9ca050e3af1b39c143c63e429cbceb15d940fbb5c5a1f4af57c5e9e80fe1639c9ca050e3af1b39c143c63e429cbceb15d940fbb5c5a1f4af57c5e9bb0cc84db7b318cb9f3521b809530440de0870f8e53d075298d06b10018162b8ab530a13e45914982b79f9b7e3fba994cfd1f3fb22f71cea1afbf02b460c6d1d)=9409ba4775979349c29ab664fa65dff67458b02ef726cbf8257c66257a837a7d
H_TapTweak(p||m)*G=028AF5531F8100ACD57F3D49C47E3DCD6002439BED59ADAAB83ECEDB82B62D3367
Q=02BB0CC84DB7B318CB9F3521B809530440DE0870F8E53D075298D06B10018162B8+028AF5531F8100ACD57F3D49C47E3DCD6002439BED59ADAAB83ECEDB82B62D3367
Q=037D9E93308E6105308D46B3A7912844FBD0925F920381501C19FC21716B6B4ADB

And now, you can see only x-value of Q, which is 7d9e93308e6105308d46b3a7912844fbd0925f920381501c19fc21716b6b4adb. This alone is enough, to commit to the message, under some public key. Then, someone reveals these things:

Code:

+------------------+------------------------------------------------------------------+
| Q (external key) | 7d9e93308e6105308d46b3a7912844fbd0925f920381501c19fc21716b6b4adb |
+------------------+------------------------------------------------------------------+
| P (internal key) | bb0cc84db7b318cb9f3521b809530440de0870f8e53d075298d06b10018162b8 |
| m (message)      | 6d657373616765 //"message"                                       |
+------------------+------------------------------------------------------------------+

Which means, that external key can be seen in your output, and everything else goes to the witness. Then, when things are validated, the same algorithm is used. The message is hashed, added to the internal key through secp256k1 point addition, and it should match the external key exactly, when it comes to the reached x-value of the public key.

And then, people have two options: they can sign things with external key, by just making a signature, which would match it, or they can reveal the internal key, and some data, which will then decide, how things should be processed, and if any keys are needed at all. Because the message could be like "<pubkey> OP_CHECKSIG", but it could be anything else at all, for example "OP_TRUE".