I need to investigate the technical way of building a history of a balance for Polkadot account - initial balance (if comes from genesis), all spent coins, all received coins, etc. The first thing is to understand types of addresses existing on Polkadot. After reading documentation, I know that address can start with 1 (00 prefix byte in public key before Base58) and 5 (2A prefix). 1 means Polkadot, 5 means “Generic substrate”. I’m having hard time understanding what “Generic Substrate” means. In many examples I see addresses starting with 5 used in APIs or Multisig creation.
My question is - can an address starting with 5 have DOT balance, send and receive DOT, or is it always an address starting with 1? I’m not interested in parachains, strictly DOT.
OK, thank you. Then the question would be - can a user of Polkadot who is only interested in keeping DOT coins somehow get his/her 5… address instead of 1…?
OK, thank you, this is clear. Another question. After reading polkadot.js API documentation, I learned that Polkadot supports 3 curve/signature schemes: sr25519, ed25519 and secp256k1. However, when using polkadot.js extension or other extensions like SubWallet, it looks like they default to sr25519 and there is no way to choose another scheme. The only way I came across to do that by means of UI is to use polkadot.js.org UI and enable local storage. What happens with Ledger and other hardware wallets?
Thanks! I understand that wallet can use whatever curve and signature scheme. But in real world scenarios, can an end user choose non-sr25519 scheme with publicly available wallets? The only way I found is using Polkadot.JS UI in developer mode and keeping keys in local store, I understand that even with that scenario user can export wallet keys and be quite safe, but would anyone do that if an intention is to keep economically substantial stash?
BTW I came across a strange thing. Polkadot.JS UI cannot verify secp256k1 signature. SDK seems to have all the necessary methods, did not have time to play with it to make sure it can decode that kind of signature.
If you import an address that was created using a different scheme, then the wallet will honour that scheme and it will internally use it for everything. It has to, because using a different scheme would produce a different public key. So, if the wallet is able to successfully import the address, then it has to honour the scheme that it was used for the account which is being imported.
On the other hand, AFAIK wallets in this ecosystem, in their UI for creating a new account, don’t allow the user to pick the underlying signature scheme. They could, but I think (don’t quote me on this, I have not tried them all) that they don’t. Probably because the signature scheme is deemed as an implementation detail, and wallets try to make the UX simpler for users. In other words: why confuse the user if there is no need to?
For instance, this is -roughly speaking- what happens when you create a new “account” using the PJS extension:
The extension generates a 12 word nemonic seed phrase that the user should write down, remember, keep safe, whatever…
It then hashes that key-phrase so that it deterministically produces a private key.
This private key could be used with different signature schemes, but doing so would produce different public addresses.
In order to avoid overwhelming the user with unnecessary options/permutations, the wallet uses a default signature scheme. In the case of the PJS extension that is sr25519.
However, if you are an advanced user and you wanted to add a new account using a different scheme, then you could do that by using the option “Restore Account from backup JSON file” and in that json file you could specify your preferred scheme. I mean, I guess that I don’t see why anyone would want to do that unless they are actually importing an account from somewhere else, but I mean, you could do that.
You could also fork the PJS extension and add the option of picking a different signature scheme, I guess, but again: I have a hard time understanding your use case.
What happens with Ledger and other hardware wallets?
Ledger and other hardware wallets don’t ever “leak” the private key outside of their hardware device. That’s why they are a lot safer than hot wallets. When you use a hardware wallet through a hot-wallet (like using ledger via the PJS wallet), it’s the hardware wallet itself the one signing the transactions, and all what the browser extension does is to provide a UX so that the dApp can communicate with the hardware wallet.
But in real world scenarios, can an end user choose non-sr25519 scheme with publicly available wallets?
Yes, Nova Wallet / Polkadot JS app, and I believe other wallets/apps in the ecosystem allow users to select different crypto type for their keypair, there are 3 options usually available: Schnorrkel sr25519 (default), Edwards ed25519, ECDSA.
While in general it doesn’t matter what crypto type you are using, it was important for Nova Wallet to support all 3 in order to achieve compatibility with Polkadot JS app (since it was first Polkadot app/wallet for majority of the user base). It is recommended (and set to default in all Polkadot wallets) to use sr25519.
I just tried with Nova Wallet and the UX doesn’t give me the option of selecting the scheme.
Is it possible that what you meant to say is that it supports the 3 different schemes for imported accounts? Or perhaps I missed something and there is in fact an advanced option to select the scheme while creating a new account?
It’s “hidden” there for a reason — right now it’s in the top-right corner on the Wallet creation/import screen — before it was on the same screen under the “Advanced” spoiler and oh boy it raised millions of questions for ecosystem newcommers while in end of the day yielding zero results due to the nature of choosing alternative crypto type for your wallet.
After all, we want to push Polkadot eco to the mass adoption through Nova, but we also taking care of supporting legacy use cases in the ecosystem, and also want our power users to be happy, so that’s why we still allocated efforts to implement this.
Use case is the following - I’m investigating the Polkadot blockchain for 2 purposes:
To build a software solution which would ensure address is indeed controlled by the party which claims so.
To build a balance report for the address, meaning restore history of all operations which affect its balance, potentially starting from genesis.
For purpose #1 we use the approach of having the user sign an arbitrary text message generated by our software, with their wallet software/hardware. Because of 3 curves/signature schemes existing in Polkadot I need to know if a regular user can choose which one to use. And looks like yes, they can (especially considering users might be not the regular people holding some DOT, but crypto firms doing more sophisticated things), so we need to support all 3, meaning when entering an address into the system, asking the user which signature scheme should be used with it when validating the signature.
Look, I don’t want to tell you how you should be solving this. However, please know that your software doesn’t need to know the underlying scheme that was used for creating the address. As long as your software supports the 3 different schemes, then all it needs is the public key. You just ask the user to sign some data and then you try against the 3 different schemes, if one of them is a match that means that whoever signed that data is in control.
:
