On the -non- migration of wallets in v2

Protocols Ğ1v2 protocol
1

Dear all!

I want to insist once again that the migration of Duniter to version 2 should not affect the way our users currently interact with the network. It should be as transparent as possible for them.

We have already discussed this at least here and here.

Migrating wallets, public addresses (from b58 to ss58), or requiring new passwords seems quite painful, to say the least. And I can think of several reasons why we should not force users to go through this process:

  • People (many of them elderly) have made a tremendous effort to remember their wallets, passwords, and passphrases.
  • Many decorate their workspaces, warehouses, etc., with their v1 keys (b58).
  • Some of these accounts are collective (such as crowdfunding accounts for organizations), and the passwords are shared among different members managing these accounts.
  • V1 public keys (b58) are everywhere—printed, embedded in web tools (gchange, girala, etc.), shared on Telegram. We must ensure they remain usable, and technically, this is entirely feasible.

Example in gchange:

image
image556×158 11.3 KB

Example in girala:

image
image727×144 11.9 KB

For these reasons, I insist that our users should continue using their v1 public keys and passwords while only noticing improvements in their daily use of the migrated v2 network.

Users should not have to endure wallet migrations, nor should they experience discrepancies in balances, avatars, memberships, etc. Everything should remain familiar after the transition to v2.

I am particularly concerned that some clients, like Gecko, might create new BIP39 accounts and transfer identities, funds, etc., to new wallets (ss58 accounts/identities), which could be a major usability issue.

It would be like migrating an entire internet or telephone network and forcing everyone to switch to new IPv6 addresses or new phone numbers due to the advantages they offer—forcing people to change their address books or contact lists. A nightmare.

Coming back to Duniter, such a migration could be extremely painful for our users and downright exhausting for those of us working directly in the field, providing daily support and assistance.

So, what do I propose?

I’ve already mentioned this before, and I am implementing it in G1nkgo:

  • Users should be able to use the new v2 network with the same old wallets, passwords, and v1 public keys.
  • Cesium2, Gecko, gcli-v2s, G1nkgo, etc., should remain compatible with the current V1 usage.
  • Mnemonic-based wallets (BIP39) should only be offered for new accounts.

Let’s make this migration easier, please.

Thank you.

cc @poka @kimamila

4 Likes
2

Hello vjrj, I don’t get it :thinking: wallet migration is not mandatory already, and by default Duniter does not do any migration at all (and I don’t know how it could even be possible to do it).

Also, SS58 is just another format encapsulating the exact same public key as in Duniter v1, an Ed25519 public key. It just adds a checksum and a prefix, and is not mandatory to use at all.

For now, only wallets such as Ğecko indeed propose an identity migration, and also uses the SS58 notation by default. But you are free not to do the same thing, and to support both formats (SS58 just adds security, but the vanilla Ed25519 keys are still there under the hood and also work by definition).

1 Like
3

yes, as a G1 user I agree with what you say.

If DuniterV2 doesn’t migrate by default, from what I understand, once you’ve upgraded to V2, everyone will be forced to migrate.

From what I understand, the problem raised here is to keep as much as possible what users are used to, i.e. id + password.

I’m sorry I’m not tech-savvy enough to offer a solution, but apparently this is a concern for the Spanish community. :pray:

@elois @poka @Moul @Maaltir qu’en pensez-vous ?

1 Like
4

No problemo for Cesium v2 :slight_smile:

5 Likes
5

Exactly.

The advantage of the ss58 format is that it is natively managed by all the polakdot-sdk libraries, which makes it easier to integrate with third-party tools, and facilitates potential future bridges with other substrate blockchains.

Also, the old b58 format has no checksum by default, which doesn’t protect against potential input errors.

My suggestion for wallet developers would be to support both formats as input, as it’s easy to discriminate between them since the ss58 format is always longer than 44 characters. Here’s a suggested algorithm:

if (address.includes(':')) {
    // parse_b58_with_checksum
} else if (address.length > 44) {
    // parse_ss58
} else {
    // parse_b58
}

Ideally, the default address format to show should be based on the authentication type:

If salt + password: display address in old b58 format
If bip39: display address in ss58 format

Ideally with a small arrow on the side to display the address in the other format.

Another issue is the security of private key generation. Our historical use of scrypt, which lets the user choose the salt, is not sufficiently secure, as the scrypt function designed to prevent bruteforcing of an account assumes that the salt has at least 16 bytes of entropy, which is not currently enforced.

I know it’s not a real problem in practice as long as Ğ1 has a low economic value. But if one day the Ğ1 becomes much more valuable, some accounts will be stolen by hackers.

So BIP-39 should be the default option when creating a new account, which is compatible with @vjrj’s proposal:

2 Likes
6

To be more precise, I believe that clients should support v1 public addresses and classic v1 wallets in functionalities such as searches, QR v1 code scanning, and the import of old wallets, etc. I am not proposing any changes at the network level.

Instead, the transition to mnemonics (BIP39) and whatever comes in the future should happen gradually. But for now, with the network/protocol migration alone, we already have enough on our plate. This approach would allow our current users to transition to v2 with minimal effort—just as web tools like gchange or girala.net will not need to change the v1 address that they have everywhere.

If we maintain a common glossary for these keys, as we discussed in the meeting, even better. BTW I’m using in g1nkgo :old_key: and :key: utf-8 characters for v1 public keys and v2 addresses respectively.

PS: Merci @kimamila for your response.

3 Likes