Work in progress Transaction / Module

Ola,

Un tout petit aperçu pour montrer que la signature fonctionne sur ce genre de composant :slight_smile:

En l’état sur la vidéo, le module effectue une signature des la reception du document,
et la transmet aussitôt
transaction visible sur Gtest

bien sur l’integration d’un code pin sera de mise
:slight_smile:

Un premier proto « propre » bientot avec le code pin, j’attends des boutons poussoirs

C’est donc dans un premier temps un systeme tel qu’une carte bleue de paiement,
peut etre bientot un « portefeuille electronique de plusieurs monnaies libre » :hugs:

maintenant ca peut servir a stocker ces identifiants au chaud également :slight_smile:
.https://streamable.com/ki5kg

12 « J'aime »

Tu utilises quelle type de composants? C’est un module LoRa au premier plan?

https://forum.duniter.org/t/systeme-transaction-discussion/3053/62?u=max

donc en 1er plan c’est un ESP qui execute la signature et qui affiche quelques data concernant les etapes dans le code

la communication se fait par liaison UART, la c’est cablé sur mon poste,
je vais le plugé sur les pins UART d’un PI zero W que je viens d’acquerir a cet effet :slight_smile:

pour l’instant j’utilise l’UART,
je suis face a une problematique concernant l’I2C,
pour faire communiquer un PI zero ou un PC celui ci doit etre esclave et mon module ESP doit être le maitre

pour les brancher directement, ca demande le developpement d’un driver, ce a quoi je vais m’atteler de comprendre comment en realiser un specifiquement pour le composant BCM2835 du rpi
sinon quoi je passe par un atmega entre les 2 et ca fonctionne aussi, le atmega sert d’intermediaire entre les 2

1 « J'aime »

Je suis tombé sur ça : https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=44482. Je ne sais pas si c’est toujours d’actualité…

et moi sur ca:

a priori sur le PI zero W , j’ai essayer de compiler le module pour le kernel
maintenant a l execution lorsque je l’insert dans le kernel,
il ne me crée pas de chemin /dev/i2c-slave…

en meme temps c’est expliqué que ca fonctionne que sur certains modele, A et B+ je crois, a revoir…
faudrait que quelqu’un qui a ces modeles puissent confirmer que le pi peut fonctionner en slave et la c’est bonheur :slight_smile:


edit:

d’un autre cote l’uart c’est pas mal non plus pour faire communiquer l’ESP et [ PC / RPI / INTEL EDISON / ONION OMEGA / CHIP] << terminal de paiement

comme ca je garde la ligne i2c de l’ESP pour l’ecran et du coup "l’affichage " du code pin se faisant sur cette ligne i2c,
n’est pas en communication direct avec le module “terminal de paiement” et plus de sniffing potentiel avec un module de paiement traffiqué

Merci pour le lien.

Je n’ai malheureusement que du RPI B, 2B, 3B, PIZERO et PIZERO W

Edit: Une idée: si on utilise un module LoRa embarquant un atmega, on pourrait créer son propre réseau de paiement…
Dans tous les cas, bravo pour ce que tu fais.

Edit2: N’y a t-il pas un moyen d’informer l’I2c maitre par un fil/signal type IRQ pour demander à l’I²C maitre “interroge moi”?

@Max excellent :slight_smile:

Souhaiterai tu nous présenter ce projets lors du créneau de libre le Jeudi de 16h à 17h ?

6 « J'aime »

Super @Max :slight_smile:
As-tu avancé depuis sur ta RPI ?

Je parle justement de ça sur ce topic: https://forum.duniter.fr/t/terminaux-de-paiement-pour-g1/895/4

Salut @poka

A vrai dire , sur le RPI non.
J’ai passé des commandes de composants chez des fournisseurs chinois,
je dois compter 3 semaines ou + pour la livraison,
–> avant tout pour finaliser la partie “Carte bleue”.

pour le coté TPE,
Le programme qui tourne sur cette demo doit tourner sans probleme a priori sur un RPI. J’ai déjà tester la communication entre les 2 ca tourne :slight_smile: la je reste en standby sur le PI…

Donc, ici, le TPE c’est mon poste, ca peut être un RPI, une tablette sous android etc…

Concernant :
"" ce qui empêche de simplement utiliser une tablette avec Cesium dessus en guise de TPE… “”

Je ne suis pas au fait de l’appli Cesium pour smartphones / tablettes,

En soit , c’est une contrainte technique vis a vis du systeme operateur (android / ios) pour communiquer avec “la carte bleue” tel que moi de mon côté je l’envisage…


Sinon pour revenir au QRCode,
sur Cesium, c’est un parsing a faire d’une URL,

pour exemple

je me fais ma petite appli en JS executé dans le navigateur pour essayer tout un tas de combinaisons exotiques dont on dispose avec les fonctions de lock/unlock.

Bref,
je peux pré remplir des champs avec l’url tel que :
k=clé cible
a=montant
d=choix d’un domaine sur lequel envoyer les requetes
c=choix de la monnaie (G1 ou G1-test)

grosso modo , tu crées un QRCode sur un site adapte
avec une url en parametre tel que:
http://monsite.com/mapage.html?k=MACLE&a=1234 (fake url)

ce qui créer un QRCode que tu imprime et que n’importe qui peut scanner
et ca le renvois sur “monsite.com”, prêt a signer puis expedier 1234 unité (12,34 G1) a la clé MACLE :slight_smile:

1 « J'aime »

Tu nous présentera ca aux RML10 ?! :wink:
Où au moins en off, si c’est pas près.

@Max a dit qu’il ne sera pas présent.

Désolé pour la latence…
Oui c’est super intéressent tout ça… Je suis curieux de voir ton système en fonctionnement.
Tu ne sera donc pas présent aux RML10 ?

Yop,

Je confirme que pour ces RML10 je ne peux pas être présent.


Après quoi ca avance,
mon appli en JS pour :

1-creer des « smarts contract »
2-generer des qrcodes (comme expliqué plus haut)
les qrcodes :
==> d’un coté, un commercant creer un qrcode pour un produit, le client le scan et est renvoyé vers l’appli y a plus qu’ a signer et envoyer la transaction.

==> d’un autre, le client creer un qrcode que le commercant scan et est renvoyé vers l’appli pour savoir si le client a suffisament de credit sur son compte et accepter de lui vendre un produit


pour les smarts contracts j’ai des pulls requests qui vont tomber :wink:
j’ai besoin que duniter accepte certains contrats tout autant que je dois peaufiner certaines fonctionnalités sur mon appli, dependantes (ou pas) d’implementation coté duniter (je fais reference au topic doc protocole tx format).

On peut tres bien envisager de faire tourner cette appli dans le navigateur d’un RPI avec mon autre appli pour communiquer avec le « module CB » et la on a un dispositif si je puis dire « tout en un » (pratique pour un commercant) pratique pour qui a une prestation / des produits a vendre tout court…

petit apercu de l’appli JS dans le navigateur


creation de qrcode une fois avoir remplis la clé publique

j’ai brouillé le qrcode à l’image
il y a aussi un champ pour mettre un montant (non visible sur cette image)

smartqrcode_


smart contract:

pour unlock des ressources et constituer un nouveau document de transaction

photo : je peux disposer de 9.99 (G1/GT) si je remplis la condition

SIG && XHX

ma clé m8zQ (infiné le lien est vert c’est moi qui produit le document) ET que je valide un mot de pass dont le resultat de SHA256(mon pass) == EA0…

dans la meme liste de ressources
je peux disposer d’une unité si conditions:

SIG && CSV && CLTV

pseudo valid ici, les liens verts sont ok,
pour le lien bleu, il est certe valide CSV(1) cependant
j’ai besoin de recup le champ median time du bloc ou se trouve la transaction d’où provient cette source et pour le moment ca implique que l’utilisateur qui veut consommer cette ressource doit connaitre cette valeur pour faire en sorte que l’appli n’est pas a effectuer moultes requetes avec l’api BMA pour trouver cette info

(ca implique qu’une requete tx/sources/pubkey renvois dans les sources ce champ mediantime du block dans lequel la transaction a etait validé dans l’objet json de retour – tout comme il serait utile notamment pour des transactions ou il existe un seul et unique unlock XHX ou CSV ou CLTV , bref ==> voir topic doc tx example … pull request :blush:)

donc conditions =
ma clé ET que 1s est écoulé a partir du temps median du block ou se trouve la transaction ET que la date du 9/11/2017 minuit est écoulé


cette photo ci dessous juste pour le fun histoire de voir l’arbre des conditions de lock (les liens sont rouges = verrouiller ici c’est pour tester jusqu’ou le text reste lisible)


enfin une fois avoir déverroullier ces ressources
creation d’un tel arbre où l’on définit les parametres des fonctions pour finir le document de transaction


voili voilou :slight_smile:

3 « J'aime »

Si je résume :

  • tu as une appli destinée aux échanges avec les commerçants. Par contre, je n’ai pas bien compris le principe des deux qrcode (ils ont un lien avec les smart contract que tu développes ?)

  • tu as une appli pour développer des smart contract : ça c’est hyper cool ! J’ai hâte de jouer avec :slight_smile: par contre, c’est destiné aux développeurs d’application ou aux utilisateurs/commerçants ?

A mon avis, ce n’est pas au protocole DUP en lui même de gérer directement les smarts contract, ils doivent fonctionner “par dessus” le protocole.

Si tu souhaite une modification du protocole DUP, stp ouvre un thread dédié a cette proposition de modification du protocole afin qu’on en discute.

Qui plus est la prochaine modif du protocole ne sera que pour la version 2.0 je viens donc de créer une branche 2.0-dev c’est sur cette branche là que devrons êtres soumises les PR touchant au protocole :slight_smile:

Mais avant de soumettre tes PR ouvre un thread pour discuter des changements que tu souhaite dans le protocole.
Si tes PR ne touchent pas au protocole tu peut les soumettre directement sur la branche dev :wink:

Il me semble que ce que @max appelle “smart contract” ce sont les différents type de conditions des transactions. Ce qui concerne directement DUP !

Oui j’avais compris mais justement, les fonctions actuelles (+ P2SH pour la 2.0) devraient suffirent :slight_smile:
Si @Max a besoin d’autres fonctions il faut qu’il nous en parle !

Après s’il s’agit de correctifs sur les parser pour régler les bug actuels là c’est différent :wink:

Les changements de protocole doivent faire office d’une discussion (Appelons ça par exemple DCP - DUP Change Proposal) afin de vérifier le besoin, la justification technique, les implications, la réalisation, etc.

2 « J'aime »

Yop,

non, pas avec le smart contract

je vais commencer par définir ce que j’entends par “smart contract”

Pour moi, c’est l’utilisation d’une source soumise a des conditions.
de maniere simple, utiliser un operateur [et, ou] c’est definir un smart contract.

De la, c’est destiné a celui qui sait se débrouiller a minima pour composer un tel document


pour eviter toute confusion, oui je fais bien référence aux opcodes existants SIG,XHX et les operateurs… qui ne me permettent pas de deverrouiller des sources.
pas encore de la creation de nouveau opcodes / operateurs. (ca va peut etre venir…)


A ce titre, j’ai vaguement survoler comment ils definissent “smart contract” dans ethereum,
puis j’ai regardé P2SH dans bitcoin

l’un dans l’autre, cela nécessite d’implementer une machine virtuelle.


Dans ethereum, ce sont les devs qui ecrivent un bout de code et ce code est inscrit dans la blockchain,

j’ai pas encore trouver les infos expliquant , quand comment, tout ca c’est gérer
a quel moment ce code s’execute, par qui…
et a premiere vue ca me semble délicat.
Sachant qu’un “contrat” peut en appeler un autre, qu’il y a egalement une limite du nombre d’appel de fonction,
et que enfin de compte, il est possible d’arriver a ce qu’un contrat n’execute pas l’ensemble de ses instructions dans ce cas où il y a une succession d’appel d’autre fonction appartenant a d’autre contrat…


Coté P2SH

si je considere que en l’etat aujourd’hui dans duniter, je dispose des opcodes SIG , etc…les operateurs et/ou

les seuls operateurs manquant
ce serait eventuellement des operateurs de comparaison, >, >= , <, <= , == , !=

j’ai vu tourner un document qui date de 2014 sur le bitcoin
99,9% des transactions sont "simple signature"
je ne sais pas ce qu’il en est aujourd’hui

C’est pour en venir au fait que , oui, implementer une machine virtuelle dans duniter,
je trouve cela techniquement parlant interessant,
cela ne “me” semble pas pour autant etre une priorité
dans la mesure où
on peut déjà proposer des contrats intéressants avec ce dont on dispose,
commencer par s’assurer que tout cela soit bien en place


a l’ecriture de ce post,
je vous propose 1 opcode :
NOTSIG => en parametre une clé publique dont la signature est exclue du document de transaction, exemple : NOTSIG(7t38…)
:rofl:

Ça sera corrigé dans la 1.6 officielle.

Exactement.

Mais d’ailleurs il n’était pas dans mon intention que Duniter soit une machine à tout faire, mais juste une machine à gérer de la monnaie libre. J’ai quand même pris compte de certains développements de Bitcoin concernant les transactions crosschain (permettre réaliser un change de monnaie automatique et sans tiers de confiance) et les lightning networks (permettre des paiements instatanés hors blockchain), qui ouvrent un champ des possibles considérable et à très court terme.

Mais on reste dans l’utilisation de monnaie. Je ne souhaite pas que Duniter fasse autre chose, toutefois désormais mon avis pèse moins lourd qu’avant, je ne suis plus le seul développeur sur le projet, et donc libre aux futurs contributeurs de changer cet état de fait :slight_smile: