<p>ah, indeed that was not clear to me. The input sigscript is composed of two parts, the signature itself, and the following "condition", that need to be met for spending the tx. Usually this is a public key, but can also be multisig elements or smart contracts. </p>

<p>In the case where a public key follows, there are two representations of public keys: compressed keys and uncompressed keys. How they are generated is explained in a thread here: <a href="https://bitcoin.stackexchange.com/questions/69315/how-are-compressed-pubkeys-generated/69366?noredirect=1#comment80625_69366">How are compressed PubKeys generated?</a>. 
So you can have this representation:</p>

<p><strong>pubkey hex uncompressed (04 + x + y):</strong></p>

<p>04 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 2CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6</p>

<p>or this:
<strong>pubkey hex compressed (02 + x, y=even):</strong></p>

<p>02 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352</p>

<p>In the case where y=odd, then a 03 is at the beginning. 
Looking at the length, you have 65 for uncompressed, and 33 bytes for compressed keys. </p>

CC BY-SA 3.0
2018-01-27T09:45:37.943Z
2018-01-27T09:45:37.943Z
pebwindkraft
<p>Why in some transactions the public key after R and S is longer 33 bytes and in others is 65 bytes? There's a difference during the signature check?</p>

<p>Thanks</p>

CC BY-SA 3.0
2018-01-27T08:54:35.663Z
Possible duplicate of [Input script difference](https://bitcoin.stackexchange.com/questions/69507/input-script-difference)
pebwindkraft
CC BY-SA 3.0
2018-01-27T08:57:11.853Z
have a look at the questions, and especially their replies, they contain a complete explanation of the way, the signatures are structured. If not the answer, then consider rephrasing your question, it doesn't make sense, as sigs are always having an R and and S component, each being hex 0x47 or 0x48 bytes long.
pebwindkraft
CC BY-SA 3.0
2018-01-27T09:26:37.673Z
Hi, I think my question is clear. I asked bot the question for a reason. The first one was about the header script, this one is about the Len of the public key. I want to now why can I have public keys of different length
lemanb84
<transactions><bitcoin-core><blockchain>
Input script public key len
lemanb84
# Input script public key len

(Asked by: username_0 on 2018-01-26)

Why in some transactions the public key after R and S is longer 33 bytes and in others is 65 bytes? There's a difference during the signature check?

Thanks

**Tags:** transactions, bitcoin-core, blockchain

> **Comments:**
> **username_1**: Possible duplicate of [Input script difference](https://bitcoin.stackexchange.com/questions/69507/input-script-difference)  
> **username_1**: have a look at the questions, and especially their replies, they contain a complete explanation of the way, the signatures are structured. If not the answer, then consider rephrasing your question, it doesn't make sense, as sigs are always having an R and and S component, each being hex 0x47 or 0x48 bytes long.  
> **username_0**: Hi, I think my question is clear. I asked bot the question for a reason. The first one was about the header script, this one is about the Len of the public key. I want to now why can I have public keys of different length  

---

## 1 answers

### Answer by username_1 on 2018-01-27. Score: 0 | Accepted answer

ah, indeed that was not clear to me. The input sigscript is composed of two parts, the signature itself, and the following "condition", that need to be met for spending the tx. Usually this is a public key, but can also be multisig elements or smart contracts.

In the case where a public key follows, there are two representations of public keys: compressed keys and uncompressed keys. How they are generated is explained in a thread here: [How are compressed PubKeys generated?](https://bitcoin.stackexchange.com/questions/69315/how-are-compressed-pubkeys-generated/69366?noredirect=1#comment80625_69366).
So you can have this representation:

**pubkey hex uncompressed (04 + x + y):**

04 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 2CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

or this:
**pubkey hex compressed (02 + x, y=even):**

02 50863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352

In the case where y=odd, then a 03 is at the beginning.
Looking at the length, you have 65 for uncompressed, and 33 bytes for compressed keys.


---

