je ne sais pas si cela vous interpelle, mais il pourrait être intéressant de pouvoir utiliser un client physique, à base de microcontroleur, pour faire des transactions chez les commerçant en wifi par exemple…
Premier jet d’idées:
utiliser le wifi du commerçant avec SSID = clef publique destinataire de la transaction. Il faut bien sûr valider visuellement que le wifi utilisé est bien celui du commerçant).
si duniterPy est compatible avec micropython = synergie de dev.
ttgo t-display me semble cocher toute les cases du coté hardware
utiliser l’électricité du commerçant et/ou batterie.
Fonctionnalités vitales:
scanner les wifi, se connecter
input de la somme à payer
faire la transaction vers la clef pub du commerçant
afficher le solde du compte du propriétaire
sécurité minimaliste: code PIN au boot, si 3 erreur autodestruction logiciel.
Bien sûr en cas de perte, il faut vite vider le compte et ne plus l’utiliser. Les identifiants sont considérés compromis.
I can think of even less that an air-gapped micro-controller might be useful for, let’s assume it has no wifi but does have storage for your ewif, a camera, a display, and some buttons.
Any merchant can create the transaction with their connection to any node… the user would ONLY need to sign on their airgapped device.
If this assumption is true, the protocol might be.
turn on your hardware wallet microcontroller, and show the merchant your QR code to transmit your public key.
Let the merchant create the unsigned transaction and transmit it to the air-gapped hardware wallet via QR code.
air-gapped wallet displays a human-readable understanding of the transaction (just parsing, no need for wifi or connection to node) which could be as simple as « Paying Xg1 to Ymerchant: OK/Cancel »… then sign it, and transmit the signed transaction back to the merchant via QR code… leaving the merchant responsible for publishing to a duniter node (or not at their own risk/peril).
I was not aware of that possibility!
How can I test this?
What is the size of the unsigned and signed transaction?
RFID could be interesting too to exchange small peace of data.
I’ve been storing my learning experience in a duniter. org git repo, with some python tools that can do very simple things (for learning/explaining how things work). A normal unsigned tx with one input and 2 outputs (one for change) comes in under 430 bytes and the bottom signature adds another 90bytes.
So anyone connected to a node can create an unsigned tx for anybody else, simply with their pubkey (using bma /tx/sources/pubkey) and I suspect that Elois is going to make this even simpler with the GVA that he’s working on… but to be seen and currently it might be a moving target api-wise).
A “normal” transaction will most of the time have much more than one input, unless the amount sent is ridiculously small. It is rather necessary to start on 1Kb the transaction, counting in addition the «change» transactions, a hardware dot being able to store at least a few tens of Kb otherwise it is unusable in practice.
Est-ce que se rapprocher de sociétés telles que Trezor ou encore Ledger ne serait pas une bonne idée ? Ces deux sociétés proposent déjà des solutions de porte-feuilles numérique physique. Car se lancer dans un projet « physique » implique d’énormes moyens :
Si le logiciel est libre (et ça a l’air d’être le cas pour Trezor et Ledger) et que le matériel est bidouillable, alors on peut nous-mêmes intégrer un client Duniter dedans. Il suffirait d’acheter un appareil et de changer le logiciel.
Un client sans ordi smartphone ?
Mais si je comprend bien le fil de cette discussion ce serait quand même un matériel proche d’un ordi ou d’un smartphone, sans toutes les capacité de ces matériels.
Où j’ai rien compris?
Ça dépend, en fonction de ce qu’on veut lui faire faire, il faut un appareil différent.
Dans tous les cas, un Raspberry Pi Zero (petit ordinateur) à 10$ est suffisant (sans compter les interfaces et le reste). Si l’appareil ne fait que récupérer des données sur le terminal du vendeur, générer une transaction et l’envoyer, et synchroniser les sources et le numéro de bloc sur un ordinateur, un microcontrôleur type Arduino (9$) ou ESP (3$) est suffisant.
Si la connexion au vendeur se fait en WiFi, il faut que le terminal vendeur soit un point d’accès. Le vendeur ne doit pas avoir à emporter un routeur WiFi aux marchés. Sinon, le NFC me semble plus pratique (pas besoin de chercher le bon SSID, il suffit d’approcher l’appareil) mais plus cher (au moins 20$ si j’ai bien cherché).
Attention vous devez vous assurer que le hardware supporte Ed25519 en particulier.
À ne pas confondre avec Curve25519 qui est un autre algo !
De plus, le support de «ECC» n’implique pas nécessairement le support de Ed25519.
ECC est un acronyme générique qui signifie «Elliptic Curve Cryptography».
Mais des algos de crypto sur courbe elliptique il y en a plein : ECDSA, ECDH, Ed25519, Curve25519, etc
Oui la crypto c’est compliqué
Tu as des exemples de documents transaction signés dans la RFC du DUBP :
Tu peux également vérifier en ligne la validité d’une signature via cet utilitaire que j’avais dev il y a 2 ans :
Il existe une bibliothèque Arduino qui gère ed25519 et plein d’autres algos, qui devrait être compatible avec le TTGO qui utilise un ESP.
@Frederic Pour la signature et la génération de la transaction, tu peux aussi regarder dans le code de Duniterpy et de ĞMixer-rs.
Pour le fun, j’avais réfléchi à un nœud Duniter minimaliste sur Arduino, mais il a à peine assez de mémoire pour les bibliothèques… mais sur cette carte il doit y en avoir largement assez.
Ce matériel coûte un certain prix.
Je crains que ce prix soit aujourd’hui un obstacle à l’utilisation d’une telle technologie, par un utilisateur lambda.
Je pense qu’il faudra encore quelques années d’existence de la G1, pour qu’un utilisateur lambda se dote d’un tel équipement.
Mais j’aime bien l’idée de chercher des solution d’usage, qui simplifierons l’utilisation de la G1 dans le futur.
Merci aux pionniers qui ouvrent le chemin.
Si vous voulez éviter de réinventer la roue, je viens de tomber sur le projet Blockstream Jade :
Adapté pour BTC et une sidechain, mais sans doute y a-t-il des idées à prendre. Tout le projet est sous licence MIT, y compris le matériel. Disponible sur M$ Git**b : https://github.com/Blockstream/Jade/
