Discrepancies in the Address Codec

[ckeshava]

Summary

Understanding design decisions in cryptographic key-generation RPCs

Motivation

1. xrpl.js and xrpl-py SDKs use a different prefix for ed25519 keys, compared to rippled. This difference in the prefixes is not documented and the reasons are unknown for this difference in behavior.

Except for a code comment alluding to this historical discrepancy, I couldn't learn much about these prefixes.

The above check in rippled suffices to preserve backwards compatibility. Is there any need to retain the differing prefix in the client SDKs? For the sake of uniformity, can we unify the behavior of rippled and the client SDKs ?

2. wallet_propose RPC could use certain updates in its behavior.

• Add CLI support ed25519 keys
• Set ed25519 as the default signing algorithm instead of secp256k1 (which is the current default). This behavior is at odds with that of xrpl-py and xrpl.js SDKs, where ed25519 algorithm was set as the default, owing to its merits over secp256k1

3. Differing API design for wallet_propose and validation_create RPCs: While wallet_propose supports both secp256k1 and ed25519 cryptographic algorithms, validation_create RPC only supports the former. Is there a reason for this design choice? I believe ed25519 keys can be used for creating/signing validations.