tip-120.md

April 3, 2025 · View on GitHub

tip: 120
title: ECDSA Signature Encoding Specification
author: federico<federico.zhen@tron.network>
discussions-to: https://github.com/tronprotocol/tips/issues/120
status: Final
type: Standards Track
category: TRC
created: 2020-01-07

Simple Summary

This TIP aims to present clear signature encoding specification to avoid ambiguity in practical applications.

The ECDSA signature scheme in RFC6919 with elliptic curve secp256k1 returns the signature (r, s, v), where r and s are the values used in standard ECDSA signatures. v is needed to recover the public key. In programming, The signature (r, s, v) needs to be encoded in standard manner for storage and transmission.

Motivation

In practice, if two applications interact with signature, e.g. one application generate the signature and another verify. If they use different signature encoding and decoding method, an valid signature may fail the verification. In order to avoid the ambiguity, the it needs to unify the the signature encoding specification.

Specification

The TIP concentrates on how to encode the ECDSA signature (r, s, v), regardless of the procedure on how to generate ECDSA signature.

Let S = (r, s, v), we specify its encoding method is

encode(S) = r ‖ s ‖ v

where r and s are 32-byte value, v is one byte, v = 27 + (y % 2). adding 27 is just the conventional manner to denote the v, so v is 27 or 28.

Rationale

In practical cases, we find someone may encode signature by encode(S) = v ‖ r ‖ s or someone may regard v as v = y % 2. So we specify the encoding order of (r, s, v). As for v = 27 + (y % 2), it is consistent with convention used in Bitcoin and Ethereum.

Test Cases

The following is a practical signature encoding example:

private key: 0xc85ef7d79691fe79573b1a7064c19c1a9819ebdbd1faaab1a8ec92344438aaf4

public key: 0x040947751e3022ecf3016be03ec77ab0ce3c2662b4843898cb068d74f698ccc8ad75aa17564ae80a20bb044ee7a6d903e8e8df624b089c95d66a0570f051e5a05b

plain message: message digest

message hash: 0xf7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650

signature: 0xdfe0122b92e0eff35e67d479e7ed774400231c723aef4bb6616f392f2505f63c726c57b96469e0c71eb58e46cd4efd16295e9bba99fb6da3758c026ceb4ace061c

r: 0xdfe0122b92e0eff35e67d479e7ed774400231c723aef4bb6616f392f2505f63c

s: 0x726c57b96469e0c71eb58e46cd4efd16295e9bba99fb6da3758c026ceb4ace06

v: 0x1c

Implementation

None