Cryptographic digital signatures

Question

I have a doubt since the public keys are known to everyone, so someone could falsify a transaction by writing down a deposit from a public address to another public address in a new block and solving the proof of work, but for a transaction to be valid, it has to be signed the signature is nothing more than the combination of the public key and the private key so according to me in the text of the block I should enter a transaction signature field I asked and this is how the block does contain a signature field the strange thing is I searched several block browsers and none of them included the signature field information.

I asked the forums, why didn't they do it? and what they answered me is that for block browsers that information is irrelevant because it is assumed that the transaction has already been signed but it omits this field in the information they show in the block browser so my question is where can I download all the complete information of a block that does not omit any detail?

Answer 1

the signature is nothing more than the combination of the public key and the private key

Here's an example of a digital signature process

Source

The signature process in Bitcoin is different but it still involves a mathematical process which takes as input the data to be signed and a private-key. The process emits a number we call a digital signature. Checking the digital signature involves a different process that takes as input the data that has been signed, the signature itself and a public-key (not the private key).

---

The structure of a transaction is described in the protocol documentation - which includes signature values in the unlocking script for an input.

That web-page gives a fully worked out example including

Input 1:
 6D BD DB 08 5B 1D 8A F7  51 84 F0 BC 01 FA D5 8D  - previous output (outpoint)
 12 66 E9 B6 3B 50 88 19  90 E4 B4 0D 6A EE 36 29
 00 00 00 00

 8B                                                - script is 139 bytes long

 48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
 7A 7A 25 3B C1 13 52 23  AD B9 A4 68 BB 3A 59 23
 3F 45 BC 57 83 80 02 20  59 AF 01 CA 17 D0 0E 41
 83 7A 1D 58 E9 7A A3 1B  AE 58 4E DE C2 8D 35 BD
 96 92 36 90 91 3B AE 9A  01 41 04 9C 02 BF C9 7E
 F2 36 CE 6D 8F E5 D9 40  13 C7 21 E9 15 98 2A CD
 2B 12 B6 5D 9B 7D 59 E2  0A 84 20 05 F8 FC 4E 02
 53 2E 87 3D 37 B9 6F 09  D6 D4 51 1A DA 8F 14 04
 2F 46 61 4A 4C 70 C0 F1  4B EF F5

 FF FF FF FF                                       - sequence

The 48 is a OP-PUSHDATA opcode that pushes the next 48₁₆ (72₁₀) bytes onto the stack. Then there is a 41 that pushes the remaining 41₁₆ (65₁₀) bytes as a separate item on the stack. The data items on the stack include a DSA digital signature.

The structure of a ECDSA signature is a little esoteric but it is usually about that length.

The remainder of the scriptsig is likely other values and/or opcodes that creates the data items on the stack that can be fed to the locking script from the referenced transaction to verify the signature using the public-key of the recipient in the referenced transaction who is the spender in this.

There are several types of standard script and so the above is only a rough description of the simplest sort. To fully decode every transaction you have to identify the type of script for each output contained (or referenced).