Skip to main content
Bitcoin

Return to Answer

wanted to correct typo of `r` in `s`, added a note in the end to overcome the obscure "at least 6 character" edit rule
Source Link
edit approved May 22, 2020 at 14:45
Riccardo Casatta
edit approved May 22, 2020 at 14:45
Riccardo Casatta
  • 538
  • 3
  • 8

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has the following components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following rs value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures. Note that in bitcoin transactions a byte is added at the end of a DER signature denoting the SigHash type used.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has the following components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following r value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has the following components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following s value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures. Note that in bitcoin transactions a byte is added at the end of a DER signature denoting the SigHash type used.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

added 10 characters in body
Source Link
Murch ♦
Murch ♦
  • 79.6k
  • 36
  • 193
  • 667

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has sixthe following components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following r value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has six components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following r value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has the following components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following r value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

added missing components (point 4 and 6: one byte to encode the length of the following r/s value)
Source Link
edit approved Mar 25, 2020 at 19:03
Ferdinando M. Ametrano
edit approved Mar 25, 2020 at 19:03
Ferdinando M. Ametrano
  • 58
  • 4

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has six components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following r value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has six components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. the r value as a big-endian integer
  5. 0x02: header byte indicating an integer
  6. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

DER

The Distinguished Encoding Rules (DER) format is used to encode ECDSA signatures in Bitcoin. An ECDSA signature is generated using a private key and a hash of the signed message. It consists of two 32-byte numbers (r,s). As described by Pieter here the DER signature format has six components:

  1. 0x30 byte: header byte to indicate compound structure
  2. one byte to encode the length of the following data
  3. 0x02: header byte indicating an integer
  4. one byte to encode the length of the following r value
  5. the r value as a big-endian integer
  6. 0x02: header byte indicating an integer
  7. one byte to encode the length of the following r value
  8. the s value as a big-endian integer

Note that the r and s value must be prepended with 0x00 if their first byte is greater than 0x7F. This causes variable signature lengths in the case that the r value is in the upper half of the range (referred to as "high r"). Signatures with high s values are non-standard and usually don't appear in the wild. Also note that in rare cases r or s can be shorter than 32 bytes which is legal and leads to shorter signatures.

SEC

The Standards of Efficient Cryptography (SEC) encoding is used to serialize ECDSA public keys. Public keys in Bitcoin are ECDSA points consisting of two coordinates (x,y). x and y may be smaller than 32 bytes in which case they must be padded with zeros to 32 bytes (H/T Coding Enthusiast). Bitcoin uses two formats, uncompressed and compressed:

Uncompressed:

  1. 0x04 byte: header byte to indicate ECDSA point
  2. the x coordinate as a 32-byte big-endian integer
  3. the y coordinate as a 32-byte big-endian integer

Compressed:

As the coordinates (x,y) must satisfy the secp256k1 curve equation y² = x³ + 7, the two possible values for y can be calculated from the x value. Thus, we can express a public key just as the x coordinate in combination with an indicator which of the two y values to use.

  1. 0x02/0x03 byte: header byte to indicate compressed ECDSA point, 0x02 for even y, 0x03 for odd y
  2. the x coordinate as a 32-byte big-endian integer

The above is more comprehensively explained e.g. in Jimmy Song's Programming Bitcoin: Ch4. Serialization.

added 50 characters in body
Source Link
Murch ♦
Murch ♦
  • 79.6k
  • 36
  • 193
  • 667
added 129 characters in body
Source Link
Murch ♦
Murch ♦
  • 79.6k
  • 36
  • 193
  • 667
Source Link
Murch ♦
Murch ♦
  • 79.6k
  • 36
  • 193
  • 667