-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrapping public keys in TS structures before Bech encoding #1261
Comments
@joe-u410 thank you for being involved in the project and welcome! I have good news, there is no mistake. In comparison to EVM-like networks, in Spacemesh VM we're not using the public key as an actual address. Instead of this, you can use your keys for creating and managing different accounts. Also, I've double-checked that Smapp generates key pairs the same as So I'm closing the issue. |
Thanks for the response! I'm familiar with BIP 44 style wallet heirarchies. I think we're talking about different issues here. I've also verified that smapp and smcli generate the same public/private keypairs, this issue is referring specifically to how smapp is handling the conversion between the pubkey and the bech-encoded address. Right now, smapp wraps the pubkey in a typescript template before converting to the sm1... style bech address. This means that it will be difficult to maintain similar logic in other repos - how will you guarantee that the pubkey is wrapped with the same padding in Go or Rust address generation? |
Ideally this would live in one place, probably the SDK, and be used everywhere: spacemeshos/spacemesh-sdk#10 |
@brusherru could you please summarize what we are doing encoding-wise in smapp in binary addresses are represented as 24 bytes, 4 first bytes reserved zeroes, next 20 bytes are last 20 bytes from principal address hash given standard bech32 library the process of encoding is looks like this
are we doing the same in smapp or something else? |
|
Is there any documentation for the purpose of calculating the principal, versus just bech encoding the pubkey like most other networks using Bech32? What is the point behind the zero padding? |
This has to do with our model of account unification (account abstraction). See spacemeshos/SMIPS#49. We need to do a better job of documenting this. In short, we don't use simple keypair-based accounts (externally owned accounts) in Spacemesh. All accounts are smart contract (template)-based accounts. So we need to convert the pubkey for the user's keypair into the corresponding "smart wallet" account address.
We're reserving 4 bytes in the address for future use. See spacemeshos/pm#106. |
@joe-u410 if you meant why I pad it with zeroes up to 24 bytes: Because otherwise, the |
There is no problem. So I'm closing the issue. |
smapp/desktop/main/reactions/views/walletView.ts
Line 35 in dd05bac
Right now, smapp is wrapping public keys in a Typescript template before doing the psuedo-Bech32 encoding used in other parts of the Spacemesh codebase. Because of this, any address generated via the spacemeshos/address or spacemeshos/address-wasm repos directly will not match the address generated by smapp, leading to confusion at best or loss of funds at worst. Happy to discuss further here, but I believe that the correct logic here would just be to feed the pubkey to a bech encoding library directly without wrapping it in this struct.
The text was updated successfully, but these errors were encountered: