Generateur de Paper Wallet

Hello,

Pour éviter le piratage la seule méthode qui me permet d’être confiant sur la sécurité de mes unités de monnaie est le “Cold Paper Wallet”

Pour ceux qui ne connaissent pas, l’idée est de générer une paire de clef Privée/Publique sur un ordi sans internet puis de l’imprimer sur papier (de préférence depuis un live CD)
Puis on envoie la plus grande partie de notre monnaie que l’on désire placer en sécurité sur la clef publique du paper wallet. (et on garde une partie sur son compte pour les petites transactions courantes)
lorsque l’on désire dépenser la monnaie présente sur le paper wallet, il suffit alors de rentrer la clef privée sur notre application cliente préférée (ou scan du QRcode) afin de l’importer.
il n’y a donc aucun risque de piratage. (il faut juste bien mettre le paper wallet dans quelque chose d’étanche, et a l’abri des flammes)

Ce petit générateur, est en démo ICI
en démo car il me reste encore du travail, afin d’intégrer tt le code dans un seul et même fichier HTML et de rajouter des fonctionnalités.

Bon aujourd’hui le problème c’est que les logiciels clients ne sont pas encore compatible pour se connecter avec une clef privée mais ça viendra. :slight_smile:

8 J'aimes

Excellent c’est une fonction qu’on voulait réaliser !

Faudra que tu documentes le format, mais c’est une fonction tout à fait intéressante pour les wallets. :slight_smile:

1 J'aime

Brao à toi !

As tu des exemples d’applications qui font ca (dans le monde BitCoin par exemple), qui pourraient nous servir de spec ?

Cesium pour Android est prévu pour pouvoir scanner des QR Code (même si en ce moment ce code est en rade - priorité au mode web). Il peut détecter un format et déclencher une action très facilement, à partir d’une REGEX.

Je n’avais pas pensé à une connexion par QRCode. Il faudrait un truc pour distinguer le format utilisé d’autres type de QRCode. A priori comme le clef privées est plus longue qu’une pubkey, ca devrait suffir.

Plus qu’à tester.

C’est une excellente idée, mais se concentrer sur le code de Duniter devrait rester la priorité avant une mise en prod future d’une monnaie libre. Les possibilités de réalisations diverses sur la base d’une monnaie existante sont toujours très grandes, variées, permettent toutes les innovations, mais la monnaie reste première. Sans monnaie, c’est à dire sans support long terme d’un code monétaire bien établi, penser les applications sur la monnaie c’est faire de la science fiction, ou mettre la charrue avant les boeufs.

C’est comme si on pensait pouvoir lancer une monnaie de prod sans les informaticiens qui développent le code qui la gèrent. Autant lancer une centrale nucléaire sans les ingénieurs pour la surveiller et la maintenir…

1 J'aime

Oui, actuellement c’est la clef privée brute, mais effectivement il faudrait mettre en place un WIF (Wallet import format) comme dans bitcoin. Pour détecter quel type de clef (public/privé/avec chiffrement/…) ajout checksum et j’en passe.
Je travail actuellement sur un petit document a vous proposer.

Aujourd’hui tous les navigateurs offrent la possibilité de prendre la main sur la webcam via WEBRTC
Il serais bien que même la version WEB (accessible par tous type d’équipements) offre cette possibilité de scan de QRCode.
Mais il n’y a pas d’urgence.

Je suis tout à fait d’accord avec toi, mais personnellement je ne suis pas Développeur de métier (mais admin Sys Unix/linux) j’ai voulu me plonger dans le code de Duniter, mais j’ai trop de retard pour être efficace en node.js et trop peur de réaliser du code pas propre :innocent:
Afin d’être plus productif pour le projet dans son ensemble, je préfère pour le moment me pencher sur des parties encore non étudiées. Comme ici les Protocoles d’import / Format d’adresses.
Mais oui, je ne désire pas disperser les autres Développeurs, juste peut-être quelques minutes afin de valider mes réflexions sur les protocoles choisis, et si de mon coté tout est fini, j’irais mettre la main a la patte directement dans les logiciel clients.

Restez concentré :wink:

5 J'aimes

Hello à tous,

Voilà j’ai fait un petit bout de doc comme proposition de format d’adresse.
Toutes questions ou remarques sont constructives, n’hésitez pas :slight_smile:

Proposition Format d’adresse

je ne sais pas pourquoi je l’ai fait en anglais alors que je suis une buse, mais trop tard ^^

3 J'aimes

Le tout me paraît bon, juste une chose à propos des paramètres N,r,p : il sont désormais saisissables dans Sakia.

Sinon quelques termes/typos :

  • UCP était pour UCoin Protocol, désormais j’utilise plutôt DUP pour DUniter Protocol
  • “ovoid”
  • “publlic”

Ça promet :thumbsup:

1 J'aime

Je suis en train d’essayer d’implémenter la clé avec CRC à l’API python.

Je suis un peu embêté avec l’exemple que tu as fourni sur la page.

Pubkey : J4c8CARmP9vAFNGtHRuzx14zvxojyRWHW2darguVqjtX
sha256(pubkey):
0x47c7aee49dfb9bea99949d04623281d8ad6188be8f6a698b0eb5994fa44d0a67

Quand je l’implémente en python :

hashlib.sha256(pubkey.encode("ascii")).hexdigest()
# '53c97ed12bb13e0b9b1c423610c8e37b739616dda708a59555154163c2951781'

En bash :

$ echo "J4c8CARmP9vAFNGtHRuzx14zvxojyRWHW2darguVqjtX" | sha256sum -
909dcbb047de88f4502c639d19f902e96185daf1259e7923f2f26101da95bda4  -

Bref, sur trois hash d’une même valeur, je n’ai jamais le même résultat. Vous avez une idée d’où est-ce que ça peut venir ? Ca parait tout con mais bon :slight_smile:

Ah ça oui c’est tout con : mes valeurs sont bidon ! :slight_smile:

Pour le echo ... | sha256sum, attention au retour chariot de la commande echo.

J’ai fini par m’en sortir, l’exemple de Tortue était bon, il fallait juste réussir à l’implémenter dans la librairie standard :slight_smile:

https://github.com/duniter/duniter-python-api/blob/master/duniterpy/documents/crc_pubkey.py

Je reprends cette discussion à propos du paper wallet.

Je suis en train de modifier ce projet https://wikifab.org/wiki/Polar01d pour qu’il sache prendre une photo, isoler le visage, puis créer un portefeuille avant d’imprimer le tout sur un ticket autocollant…
QRcode CLEF PUBLIQUE / VISAGE / QRcode CLEF PRIVEE

Je prépare un autre terminal équipé d’un clavier qui servira à gérer les transactions: https://pad.p2p.legal/s/G1Tx
A l’usage, on présente le QRcode de la clef publique, on saisi le montant à y recevoir, puis on présente le QRcode de clef privée du wallet à débiter. Le visage pourra servir à contrôler que le bon propriétaire déclenche la TX (par human ou computer vision).

Je pense utiliser un diceware fourni à silkaj pour créer les QRcode à partir des clef produites. Mais il faut que je patche auth.py pour lui parler en CLI

def auth_by_scrypt(cli_args):
	# G1SMS:: Accept salt & password from "cli_args"
    if cli_args.contains_definitions('salt') and cli_args.contains_definitions('password'):
        salt = cli_args.get_definition('salt')
        password = cli_args.get_definition('password')
    else:

Comme je vois qu’on parle ici du sujet…
Je me demandais s’il existait d’autres façon d’obtenir un couple de clefs compatibles? Une ligne de commande pleine de pipe peut-elle y arriver?

Un avis, un coup de main?