Topic: What's the Extra Byte for P2PK? (Read 777 times)
Thanks so much for your response, achow101. Your answer has cleared things up. I appreciate it.
It is a size indicator opcode. It means that the next n bytes are to be pushed to the stack as one element. Otherwise a script interpreter wouldn't know that the next 65 or 33 bytes represented a public key and had to be pushed to the stack as such.
I've been looking at raw transactions on the blockchain and have noticed that transaction outputs which use a pay-to-public-key locking script, tend to have an extra byte in front of the public key. Does anyone know what this preceding byte is?
For instance, take a look at the following raw transaction from block #10 on the blockchain:
01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff0704ffff001d0136ffffffff0100f2052a01000000434104fcc2888ca91cf0103d8c5797c256 bf976e81f280205d002d85b9b622ed1a6f820866c7b5fe12285cfa78c035355d752fc94a398b675 97dc4fbb5b386816425ddac00000000
Now let me point out the extra byte in between -> and <-:
01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff0704ffff001d0136ffffffff0100f2052a0100000043 -> 41 <- 04fcc2888ca91cf0103d8c5797c256bf976e81f280205d002d85b9b622ed1a6f820866c7b5fe122 85cfa78c035355d752fc94a398b67597dc4fbb5b386816425ddac00000000
As you can see, there's this 41 hexadecimal byte.
The first transaction, on block 277316, also has an extra byte in front of the public key. Take a look:
01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff0f03443b0403858402062f503253482fffffffff0110c08d950000000023 -> 21 <- 02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000
This time it's hexadecimal 21.
Does anyone know why these P2PK locking scripts have an extra byte? My understanding is that it's just supposed to be the public key and then the OP_CHECKSIG operator (hex ac) on the end. Am I missing something?
Thanks for your time, and I appreciate any help that anyone is willing to provide.
For instance, take a look at the following raw transaction from block #10 on the blockchain:
01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff0704ffff001d0136ffffffff0100f2052a01000000434104fcc2888ca91cf0103d8c5797c256 bf976e81f280205d002d85b9b622ed1a6f820866c7b5fe12285cfa78c035355d752fc94a398b675 97dc4fbb5b386816425ddac00000000
Now let me point out the extra byte in between -> and <-:
01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff0704ffff001d0136ffffffff0100f2052a0100000043 -> 41 <- 04fcc2888ca91cf0103d8c5797c256bf976e81f280205d002d85b9b622ed1a6f820866c7b5fe122 85cfa78c035355d752fc94a398b67597dc4fbb5b386816425ddac00000000
As you can see, there's this 41 hexadecimal byte.
The first transaction, on block 277316, also has an extra byte in front of the public key. Take a look:
01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff0f03443b0403858402062f503253482fffffffff0110c08d950000000023 -> 21 <- 02aa970c592640d19de03ff6f329d6fd2eecb023263b9ba5d1b81c29b523da8b21ac00000000
This time it's hexadecimal 21.
Does anyone know why these P2PK locking scripts have an extra byte? My understanding is that it's just supposed to be the public key and then the OP_CHECKSIG operator (hex ac) on the end. Am I missing something?
Thanks for your time, and I appreciate any help that anyone is willing to provide.
Jump to: