<blockquote>
<p><strong>the signature is nothing more than the combination of the public key and the private key</strong></p>
</blockquote>
<p>Here's an example of a digital signature process</p>
<p><a href="https://i.sstatic.net/JzwLG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/JzwLG.png" alt="Digital Signature diagram" /></a>
<a href="https://commons.wikimedia.org/wiki/File:Digital_Signature_diagram.svg" rel="nofollow noreferrer">Source</a></p>
<p>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).</p>
<hr />
<p>The structure of a transaction is described <a href="https://en.bitcoin.it/wiki/Protocol_documentation#tx" rel="nofollow noreferrer">in the protocol documentation</a> - which includes signature values in the unlocking script for an input.</p>
<p>That web-page gives a fully worked out example including</p>
<pre><code>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
</code></pre>
<p>The <code>48</code> is a <code>OP-PUSHDATA</code> <a href="https://en.bitcoin.it/wiki/Script#Opcodes" rel="nofollow noreferrer">opcode</a> that pushes the next 48<sub>16</sub> (72<sub>10</sub>) bytes onto the stack. Then there is a <code>41</code> that pushes the remaining 41<sub>16</sub> (65<sub>10</sub>) bytes as a separate item on the stack. The data items on the stack include a DSA digital signature.</p>
<p>The <a href="https://b10c.me/blog/006-evolution-of-the-bitcoin-signature-length/" rel="nofollow noreferrer">structure of a ECDSA signature</a> is a little esoteric but it is usually about that length.</p>
<p>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.</p>
<p>There are several <a href="https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch05.html#id442699" rel="nofollow noreferrer">types of standard script</a> 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).</p>

CC BY-SA 4.0
2022-09-26T12:54:23.123Z
Note that in ECDSA, it isn't actually true that signing is "encrypting with the private key" - that's an explanation that's only correct for RSA as far as I know. In ECDSA, there is no encryption whatsoever. It's just an algorithm that takes private key and message.
Pieter Wuille
CC BY-SA 4.0
2022-04-28T09:25:14.660Z
2022-04-28T16:01:04.890Z
2022-04-28T16:01:04.890Z
RedGrittyBrick
<p>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.</p>
<p>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?</p>

CC BY-SA 4.0
2022-04-28T05:18:23.103Z
Hello, welcome to bitcoin.stackexchange! This is an english-language website, so I've edited your question and replaced the text with an english translation. If the translation does not accurately reflect your question, please feel free to edit it appropriately.
chytrik
<blockchain.info><signature>
Cryptographic digital signatures
Dig
# Cryptographic digital signatures

(Asked by: username_0 on 2022-04-28)

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?

**Tags:** blockchain.info, signature

> **Comments:**
> **username_1**: Hello, welcome to bitcoin.stackexchange! This is an english-language website, so I've edited your question and replaced the text with an english translation. If the translation does not accurately reflect your question, please feel free to edit it appropriately.  

---

## 1 answers

### Answer by username_2 on 2022-04-28. Score: 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

[![Digital Signature diagram](https://i.sstatic.net/JzwLG.png)](https://i.sstatic.net/JzwLG.png)
[Source](https://commons.wikimedia.org/wiki/File:Digital_Signature_diagram.svg)

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](https://en.bitcoin.it/wiki/Protocol_documentation#tx) - 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](https://en.bitcoin.it/wiki/Script#Opcodes) that pushes the next 4816 (7210) bytes onto the stack. Then there is a `41` that pushes the remaining 4116 (6510) 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](https://b10c.me/blog/006-evolution-of-the-bitcoin-signature-length/) 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](https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch05.html#id442699) 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).

> **Comments:**
> **username_3**: Note that in ECDSA, it isn't actually true that signing is "encrypting with the private key" - that's an explanation that's only correct for RSA as far as I know. In ECDSA, there is no encryption whatsoever. It's just an algorithm that takes private key and message.  

---

