PIP: 6 Title: Ethereum (ECDSA) Keys (RCD-e) Layer: Consensus (hard fork) Author: Steven Masley <[email protected]> Comments-Summary: No comments yet. Comments-URI: https://github.com/pegnet/pips/wiki/Comments:PIP-0006 Status: Draft Type: Standards Track Created: 2019-11-21 License: BSD-2-Clause
To support the Ethereum gateway for PegNet tokens, PegNet will have to support Ethereum keys. By supporting the signature scheme (ECDSA) used by Ethereum, all PegNet tokens going through the gateway will never change ownership. The same key used to redeem the PegNet tokens is the same that uses the ERC20 tokens.
Factom addresses use an RCD structure detailed here. RCD-1 is the only currently supported type, and uses the ed25519 signature scheme. This PIP details a new RCD type, RCD-e. RCD-e will use the ECDSA signature scheme when validating transaction signatures. The e is for Ethereum and 0x0e is the first byte of the RCD.
| data | Field Name | Description |
|---|---|---|
| varInt_F | Type |
The RCD type. This specifies how the data structure should be interpreted. Type 14 (0x0e) indicates the Ethereum-linked RCD.
|
| 64 bytes | Pubkey 0 |
The 64-byte ECDSA uncompressed public key. If generating an uncompressed key and the length is 65, remove the 0x04 prefix indicating an uncompressed key.
|
The private key is the 32-byte ECDSA private key. When presented as text, the Ethereum hex-style 0x00.. should be used. Factom private keys are encoded in base58 with an Fs prefix. We do not want users to confuse the two types.
Signatures are 65 bytes in length. The first 64 bytes is the signature itself, with the 65th byte being the recovery byte. The recovery byte allows the operation pubkey = recover(digest, signature). All signatures are Sign(Sha256(Sha256(msg))). This means only sign hash digests, and for RCD-e, all hash digests are a sha256d of the original msg.
Example Vector:
Private Key: 0xbde0723b3236d7b7613d11c6c93c57ad89fd7f7c586aaa18f7a1b392aa2c39fd
Public Key: 0x25892ecbaf10c71d52f260c0b43a8e6b2384324b02c0d4b576d74452b81c359068e584b8831287a1a21b21fd2ac0c0e326cfcdaff27df14261a78bee0e0177d4
FAAddress: FA2M5uK3aPrJ8RfHdbTUL1ySxp22s3TwQ3Js6n7jss7QErw3S6ae
FeAddress: Fe1UgCvpEx72E1fXYZUjfSk5bUGFUrTaZ5zzzVC7QuGz4vCjkoLM
EthAddress: 0xD8A27BdCA2067F233551F29231CD2cDa0828bF62
Digest: 0000000000000000000000000000000000000000000000000000000000000000
Signature: 4bc4cee5b07114dcc0dd4a7654d42a1abc51f8d5c417fde8413686126a8cfb0633fac598664c46ec88be878f8fe9c3245e8385e00be107f021a937ab73d09d7a00
It should be noticed that the resulting Factom address is encoded in the same method as the RCD-1; 0x5fb1 + sha256d(rcd) + checksum. This imposes a potential risk to users, as the RCD-e is not yet implemented into the Factom Protocol and, therefore, unable to transfer FCT.
To protect users from making the mistake of transferring FCT to this new address type, a client-side protection standard should be used.
In order to ensure funds are not accidentally sent to unredeemable locations, we can impose a different address encoding scheme for the RCD-e addresses. It should be known that although we are changing the encoding from the wallet, all explorers and external tools will still show the FA... address. All wallets should support these extra encoding standards. Any legacy wallets will intentionally fail to work with this new standard. If funds need to be sent from a legacy wallet, they will need to send to the alternative FA... encoding.
All user RCD-e addresses should be encoded as follows: Example Code
RCDHash = Sha256(Sha256(rcd))wherercdbytes are defined in the table above (0x0e + pubkey)- Concatenate the 0x62f4 prefix (
Fe) and the rcdhash,0x62f40000000000000000000000000000000000000000000000000000000000000000 - Take the SHA256d of the above data, and append the first 4 bytes to the end.
- Base58 encode the result.
0x6028 (FE). This will be explained below.
When a user inputs the Fe or FE encoding, the underlying wallet should understand the encoding and apply the client-side protections associated with each. The first is that legacy wallets only support FCT transactions, and as such will reject any new encoding as invalid. This will protect legacy users from sending FCT to this new address type. The rules of which addresses can send to which is provided below. The main thing to note about Fe vs FE is that an FA address cannot send funds to an FE address. This is because an FE address indicates a gateway, and an FA address does not have a linked Ethereum address to receive the funds on the other side of the gateway. A user who sends pegged tokens to the FE address must be able to redeem their tokens on the other side of the gateway.
| Input | Currency | Allowed Output |
|---|---|---|
| FA | FCT | FA |
| FA | pXXX | FA, Fe |
| Fe | FCT | x |
| Fe | pXXX | FA, Fe, FE |
| FE | FCT | x |
| FE | pXXX | Fe, FE |
Since the RCD-e uses the ECDSA signature scheme, all RCD-e addresses should also display their linked Ethereum address. The Ethereum address derivation can be found in the 'Ethereum Addresses' section in this chapter. If a wallet supports this RCD-e type, the wallet should also show the user their linked Etheruem address. It should also indicate to the user their FA address if the user is going to confirm their address on a legacy explorer or look at a transaction that has only FA addresses.
All Ethereum Linked addresses (Fe) should be derived using the Ethereum coin type path found in this list. The address generated by the wallet should have the linked Ethereum address that an Ether wallet would generate. This means a user moving their seed from a PegNet to Ether wallet after a gateway transaction would see their coins.
The motivation for this is to support an Ethereum gateway. In order to send tokens through the gateway and maintain ownership, the same private/public key should be able to redeem the tokens. This means Factom must support ECDSA keys.
By implementing this address scheme, no gateway will ever be in the position where the ownership of the tokens might have changed. By ensuring the same owner is on both sides of the transaction, it is legally a much safer transaction.
This address type will likely be adopted by the Factom protocol in the future, so all wallets should plan to accept it. Until that is done, there will be an incompatibility between RCD-e and factomd. RCD-e addresses will be constrained to PegNet at this time.