Tikka V1 V2 - Quelle est la stratégie de migration?

Support Tikka
,
1

Ce soir, je me suis dit, “allez essaye tikka”
En me laissant aller à l’UX… Je crée un portefeuille v2, je note mes mnemonics (coool ils sont en français), je ne peux pas changer “AAAAAA”, enfin je crée ma nouvelle clef.

FredV2
FredV2827×187 17.1 KB

Je veux tenter le “transfert de compte v1/v2”
Pas froid aux yeux (et surtout confiance dans le code de @vit), je choisi mon compte membre… clic…

et voilà ce qu’on me propose :

tikkaV1V2
tikkaV1V21094×719 59.5 KB

Je ne clique pas sur Finish !!!
Si je comprends bien, cela effacerait mes sources de DU de la chaîne G1, ou bien celles qui sont sur mon portefeuille??!!

The V1 source account will be deleted from the blockchain on success

Que ce serait-il passé si j’avais cliqué sur Finish ???

1 Like
2

Quand on parle de migration à ce niveau, on parle de transférer les données d’un compte vers un autre. Il ne s’agit ici que de comptes Gdev, il est impossible de faire des transferts entre un compte sur une chaine V1 et un compte sur une chaine V2.

La Gdev est une image de la Ğ1, (photo prise fin janvier début février je n’ai pas la date exacte). C’est pourquoi tu retrouves tes comptes Ğ1 sur la Ğdev, (sans les actions depuis cette date).
Toutes actions faites sur la Gdev n’aura jamais aucun impact sur la Ğ1.
Tu peux y aller sans crainte !

3 Likes
3

Comptes V1 et V2 se rapportent à la manière de générer la clé, pas à la chaîne. Tout est en ĞDev et ça ne touche pas à la Ğ1 (j’imagine ?). Les comptes “V1” existent bien en ĞDev et ont le même statut que les comptes “V2”, mais leur clé a été générée par Scrypt.

Comme on ne peut pas forger un mnemonic à partir des mots de passe Scrypt, on déplace le compte de l’ancienne clé publique (nommée V1) vers la nouvelle (nommée V2), avec toute sa monnaie et ses certifs. Les autres clients font la même chose.

La formulation dans la capture d’écran fait peur “account will be deleted”. Parler de déplacement et insister sur le fait qu’on ne perd rien dans l’opération, pourrait rassurer et éviter que des gens n’osent pas cliquer. Le “Finish” laisse penser que le bouton va causer une action (on ne sait pas laquelle), or si j’ai bien compris il sert à fermer la fenêtre ?

2 Likes
4

OK, la procédure est inoffensive alors… Cool

Avec ce message je pensais que les sources présentes sur mon portefeuilles allaient être “brulées” (dans des portefeuilles de moins de 1G1) ou transféré ailleurs dans un wallet perdu, ou celui d’une asso…

Ca signifie que la clef v2 s’initialise comme la v1

Le jour J, cette procédure permet de “flasher” sa clef v2 à l’identique de son compteur v1, et de changer de chaîne.
A priori cet “import” ne peut (pourra) se faire qu’une fois.

cela pourrait aussi déclencher une alerte envoyée aux amis (N1)

Tant que j’y suis, j’avais une question plus “bas niveau”
La v2 n’utilise plus de “sources” et fonctionne en “atomic swap”?
Si c’est le cas. Cela va effacer la traçabilité de la source des “DU”…

5

Ça permet d’utiliser une ancienne clé avec une authentification plus sécurisée, ça permet donc d’utiliser facilement la nouvelle chaîne, mais le compte avec l’ancienne clé existe déjà sur la nouvelle chaîne, puisque tous les comptes ont été copiés depuis un bloc donné de la Ğ1. (et la vraie Ğ1V2 sera issue d’un instantané futur)

Oui, mais rien ne t’empêche de recréer un compte ĞDev avec tes identifiants Scrypt et de tout transférer dessus. La notion d’import est une fiction des clients pour simplifier l’usage, Duniter s’en fiche (pour lui c’est un transfert de monnaie et éventuellement un déplacement d’identité).

Il n’y a plus de sources UTXO, chaque compte a un montant. Une conséquence est qu’une transaction doit être publiée rapidement après avoir été signée (il y a un nonce croissant).

La traçabilité des DU n’avait de toute façon aucun intérêt réel puisque les clients choisissaient les UTXOs d’une manière arbitraire pour forger des transactions.

Le terme atomic swap réfère plutôt à un échange inter-chaînes, et les transactions étaient déjà atomiques en V1.

Si tu as besoin des propriétés des UTXOs, il est possible de s’en rapprocher en utilisant des oneshot accounts (utilisable dans PolkadotJS).

1 Like
6

J’entends parfois le mot migration pour cette action, import semble aussi source de confusion, transfert sera-t-il plus approprié ?
Je crois qu’il faut surtout éviter de dire V1/V2, mais plutôt parler de “id-mdp/mnémonic” car ce transfert ne concerne que la V2.

7

Tout dépend de ce dont on parle : c’est un transfert d’un compte à un autre, une migration d’un système crypto à un autre, un import de la clé privée dans le client… Je ne sais pas quel terme est le plus clair.

Le terme “identifiant Cesium” est aussi utilisé mais puisque Cesium sera mis à jour il faudra trouver autre chose.

Le mnemonic sert à générer la clé privée, mais après on stocke la clé privée chiffrée par un mot de passe ou un code PIN, donc c’est aussi un id-mdp.

V1/V2 en parlant des méthodes d’authentification, dans la mesure où tous les clients adoptent le mnemonic, me semble le moins ambigu. Certes ce n’est pas adéquat pour décrire formellement les protocoles, mais ça correspond à l’usage et aux normes de sécurité promues lors de ces deux versions.

8

Hello et merci de tester Tikka !

Alors le boutton dangereux c’est le bouton Import au milieu ! Le message vert indique que l’import est terminé et le compte V1 supprimé (désolé pour toi… non je plaisante c’est juste le compte migré sur la gdev !).

Merci à tous pour vos réponses ! Je vais revoir le message, mais il supprime bien le compte V1 migré sur la blockchain substrate. Donc l’opération n’est pas anodine…

2 Likes
9

A ouais! Je trouve cette proposition un peu radicale…

Mais dans ce cas, comment cette procédure se déroulerait?
Envoi de document de résiliation, purge ou transfert des sources??

Quel intérêt à faire cela ?

Si j’ai d’autres portefeuilles (non membre) à migrer qui ne sont pas fabriquées par mnemonic, comment on procède ?

10

Est-ce que tout ce qu’on a dit (sans avoir lu le code de Tikka) est bien correct ?

Parler de suppression plutôt que de déplacement fait peur, on n’a pas l’impression d’avoir la garantie de tout conserver. J’éviterais de dire suppression, plutôt que l’ancienne clé publique doit être abandonnée au profit de la nouvelle. D’ailleurs il sera toujours possible de recevoir des G1 sur l’ancienne clé et de les rapatrier sur la nouvelle.

Entre le passage des clés publiques V1 aux adresses V2, et le passage du compte V2 Scrypt au compte V2 mnemonic, on peut perdre les gens facilement et créer des superstitions facilement…

2 Likes
11

Tu as raison, j’ai cru bêtement que le compte serait “détruit” en utilisant la commande “transfer_all” avec keep_alive=False :


        params = {"dest": recipient_address, "keep_alive": keep_alive}
        try:
            call = self.connections.rpc.client.compose_call(
                call_module="Balances",
                call_function="transfer_all",
                call_params=params,
            )

Disons que les données du compte “disparaissent” seulement du storage pour faire du ménage, mais que la moindre transaction vers ce compte va le “recréer” en storage. Ce qui est totalement invisible du côté de l’utilisateur.

L’opération n’étant pas dangereuse et, de plus, réversible (si on a bien noté le mnémonique du nouveau compte V2 ! :sweat_smile:), je vais modifier cette phrase stupide pour quelque chose comme :

The V1 account money and Identity will be transferred onto the V2 account on success.

2 Likes
12

Donc dans le principe, les “G1” présentent sur le compte “v1” sont "déplacées sur le compte portefeuille “mnemonic” (v2) et disparaissent de l’espace v1 (grace à cette option transfer_all qui s’adresse à l’API v1)

  • Une clef publique existe sur le réseau v1 et sur le réseau v2

  • on pourrait toujours recevoir des G1 sur le compte v1 au travers du réseau v1 et les retransférer ensuite sur le v2 ? A priori non ? Mais si on transfert ses G1 sur le compte d’un membre G1 par encore v2ifié, on pourrait…

Est-ce que je commence à saisir ?

13

Tikka ne se connecte que sur la blockchain V2 ! Il n’agit absolument pas sur la blockchain V1.

Du coup Non. On transfert juste la monnaie et l’identité du compte V1 migré présent sur la blockchain V2, sur un nouveau compte Mnémonique créé sur la blockchain V2. Rien ne disparaît nulle part.

Oui. Après la migration on a les mêmes trousseaux de clef V1 sur la V1 et la V2.

Non. Car la migration a lieue une seule fois et elle seule copie les comptes V1 avec leurs soldes et les identités sur la V2. Après tu ne pourras plus rien “transférer” entre la blockchain V1 et la V2.

Si tu as des questions sur la migration, pose les plutôt sur les sujets dédiés stp.

Gardons ce fil pour Tikka et ses bugs. :wink:

1 Like
14

OK!! Si on clique sur importer, tikka va juste récupérer le solde présent sur le clone du wallet G1 (en v2) pour le déplacer dans le compte mnemonic v2

Reste plus qu’à attendre l’instant T

Concernant tikka, sera-t-il possible de programmer des virement automatiques depuis le compte créateur du DU vers 1 ou plusieurs compte standard ?

NB : La sécurité s’en trouverait amélioré si c’était une fonction codé dans le moteur de la blockchain. Sinon on sera encore obligé d’utiliser sa clef privée membre dans un client pour réaliser l’opération…