EIP-191: The Signed Data Standard

Once upon a time when signaturescame about. They were loved by independent bodies and DOAs. One could set a transaction, sign it and then send it for someone to perform the transaction thereby paying the gas for the transaction.
Yet and yet again a new solution came along with it cons and those cons prompted the EIP191.
Several multisignature wallet implementations have been created which accepts presigned
transactions. A presigned
transaction is a chunk of binary signed_data
, along with signature (r
, s
and v
). The interpretation of the signed_data
has not been specified, leading to several problems
Problem 1: Standard Ethereum transactions can be submitted as signed_data
. An Ethereum transaction can be unpacked, into the following components: RLP<nonce, gasPrice, startGas, to, value, data>
(hereby called RLPdata
), r
, s
and v
. If there are no syntactical constraints on signed_data
, this means that RLPdata
can be used as a syntactically valid presigned
transaction.
Problem 2: Multisignature wallets have also had the problem that a presigned
transaction has not been tied to a particular validator
, i.e a specific wallet. Example:
Users
A
,B
andC
have the2/3
-walletX
Users
A
,B
andD
have the2/3
-walletY
User
A
andB
submitpresigned
transactions toX
.Attacker can now reuse their presigned transactions to
X
, and submit toY
.
Martin Holst Swende (@holiman) and Nick Johnson <arachnid@notdot.net\> probably said to themselves and said why create two solutions to two problems when we can create one solution for both.
THE SOLUTION
A new format for signed data was proposed
0x19 <1 byte version> <version specific data> <data to sign>.
The initial 0x19
byte is intended to ensure that the signed_data
is not valid RLP. 0x19 is a prefix saying "hey! I'm a signature!". 0x19 was chosen because it's a weird number not used in any other context. It's decimal value is 25, we don't really use 25 for anything.
That means that any signed_data
cannot be one RLP-structure, but a 1-byte RLP
payload followed by something else. Thus, any EIP-191 signed_data
can never be an Ethereum transaction.
Then, the <1 byte version> is what version of "signed data" the user is using. Perhaps in the future we want to format our signed data different. This <1 byte version> allows us to do that. There are 3 commonly used versions as of today:
0x00: Data with intended validator
0x01: Structured data ( is used most often in production dapps, and associated with EIP-712. )
0x45: personal_sign messages
The version 0x00
has <intended validator address>
for the version specific data. In the case of a Multisig wallet that perform an execution based on a passed signature, the validator address is the address of the Multisig itself. The data to sign could be any arbitrary data.
Version 0x01
The version 0x01
is for structured data as defined in EIP-712
Version 0x45
(E)
0x19 <0x45 (E)> <thereum Signed Message:\n" + len(message)> <data to sign>
The version 0x45
(E) has <thereum Signed Message:\n" + len(message)>
for the version-specific data. The data to sign can be any arbitrary data.
NB: The E
in Ethereum Signed Message
refers to the version byte 0x45. The character E
is 0x45
in hexadecimal which makes the remainder, thereum Signed Message:\n + len(message)
, the version-specific data.
Then finally the data to sign is what the intended sender wants to perform on the blockchain.
This EIP is in use and not stagnant. Cheers to more growth on the EVM blockchain.
Subscribe to my newsletter
Read articles from Udeh Udochukwu directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
