Updated EIP-2098 compact representation with suggestions and moved to review. (#3624)

EIPS/eip-2098.md

@@ -1,11 +1,12 @@
 ---
 eip: 2098
 title: Compact Signature Representation
-status: Draft
+status: Review
 type: Informational
 author: Richard Moore (@ricmoo), Nick Johnson <nick@ethereum.org>
 discussions-to: https://github.com/ethereum/EIPs/issues/2440
 created: 2019-03-14
+requires: 2
 ---
 
 ## Simple Summary
@@ -22,10 +23,11 @@ as well as on-chain in EVM contracts for example, in meta-transactions and
 multi-sig contracts.
 
 Currently signatures require 65 bytes to represent, which when aligned
-to 256-bit words, requires 96 bytes (with 31 zero bytes injected). With
-compact signatures, this can be reduced to 64 bytes, which remains 64
-bytes when word-aligned.
-
+to 256-bit words, requires 96 bytes (with 31 zero bytes injected). The
+yParity in RLP-encoded transactions also require (on average) 1.5 bytes.
+With compact signatures, this can be reduced to 64 bytes, which remains 64
+bytes when word-aligned, and in the case of RLP-encoded transactions
+saves the 1.5 bytes required for the yParity.
 
 ## Motivation
 
@@ -35,44 +37,46 @@ transactions in client code, reduce gas costs and reduce transaction sizes.
 
 ## Specification
 
-A secp256k1 signature is made up of 3 parameters, `r`, `s` and `v`. The `r`
-represents the `x` component on the curve (from which the `y` can be
+A secp256k1 signature is made up of 3 parameters, `r`, `s` and `yParity`.
+The `r` represents the `x` component on the curve (from which the `y` can be
 computed), and the `s` represents the challenge solution for signing by a
-private key. Due to the symmetric nature of an elliptic curve, a `v` is
-required, which indicates which of the 2 possible solutions was intended,
+private key. Due to the symmetric nature of an elliptic curve, a `yParity`
+is required, which indicates which of the 2 possible solutions was intended,
 by indicating its parity (odd-ness).
 
 Two key observations are required to create a compact representation.
 
-First, the `v` parameter is always either 0 or 1 (canonically the values used
-have been 27 and 28, as these values didn't collide with other binary prefixes
-used in Bitcoin.)
+First, the `yParity` parameter is always either 0 or 1 (canonically the values
+used have been 27 and 28, as these values didn't collide with other binary
+prefixes used in Bitcoin).
 
 Second, the top bit of the `s` parameters is **always** 0, due to the use of
 canonical signatures which flip the solution parity to prevent negative values,
 which was introduced as [a constraint in Homestead](./eip-2.md).
 
-So, we can hijack the top bit in the `s` parameter to store the value of `v`, resulting in:
+So, we can hijack the top bit in the `s` parameter to store the value of
+`yParity`, resulting in:
 
 ```
-[256-bit r value][1-bit v value][255-bit s value]
+[256-bit r value][1-bit yParity value][255-bit s value]
 ```
 
 
 ### Example Implementation In Python
 
 ```python
-def to_compact(r, s, v):
+# Assume yParity is 0 or 1, normalized from the canonical 27 or 28
+def to_compact(r, s, yParity):
     return {
         "r": r,
-        "vs": ((v - 27) << 255) | s
+        "yParityAndS": (yParity << 255) | s
     }
 
-def to_canonical(r, vs):
+def to_canonical(r, yParityAndS):
     return {
         "r": r,
-        "s": vs & ((1 << 255) - 1),
-        "v": (27 + (vs >> 255))
+        "s": yParityAndS & ((1 << 255) - 1),
+        "yParity": (yParityAndS >> 255)
     }
 ```
 
@@ -87,8 +91,8 @@ while reducing transaction sizes and gas costs.
 ## Backwards Compatibility
 
 The Compact Representation does not collide with canonical signature as
-it uses 2 parameters (r, vs) while canonical signatures involve 3
-separate parameters (r, s, v).
+it uses 2 parameters (r, yParityAndS) and is 64 bytes long while canonical
+signatures involve 3 separate parameters (r, s, yParity) and are 65 bytes long.
 
 
 ## Test Vectors
@@ -101,8 +105,8 @@ Signature:
   s:  0x7e865ad05c4035ab5792787d4a0297a43617ae897930a6fe4d822b8faea52064
   v:  27
 Compact Signature:
-  r:  0x68a020a209d3d56c46f38cc50a33f704f4a9a10a59377f8dd762ac66910e9b90
-  vs: 0x7e865ad05c4035ab5792787d4a0297a43617ae897930a6fe4d822b8faea52064
+  r:           0x68a020a209d3d56c46f38cc50a33f704f4a9a10a59377f8dd762ac66910e9b90
+  yParityAndS: 0x7e865ad05c4035ab5792787d4a0297a43617ae897930a6fe4d822b8faea52064
 ```
 
 ```
@@ -113,8 +117,8 @@ Signature:
   s:  0x139c6d6b623b42da56557e5e734a43dc83345ddfadec52cbe24d0cc64f550793
   v:  28
 Compact Signature:
-  r:  0x9328da16089fcba9bececa81663203989f2df5fe1faa6291a45381c81bd17f76
-  vs: 0x939c6d6b623b42da56557e5e734a43dc83345ddfadec52cbe24d0cc64f550793  
+  r:           0x9328da16089fcba9bececa81663203989f2df5fe1faa6291a45381c81bd17f76
+  yParityAndS: 0x939c6d6b623b42da56557e5e734a43dc83345ddfadec52cbe24d0cc64f550793  
 ```