Hors sujet, en tout cas pour ce topic ^^ La j’implemente le protocole actuel en Rust, donc pas de changement de structure de données la dedans. Par contre dans le cadre des RFC pour la prochaine version du protocole ça peut être intéressant. Je vais voir ce que ça donne mais je ne suis pas sûr que ça soit adapté à notre structure, ni qu’il y ai déjà une implémentation en TypeScript et en Rust.
Je viens de remarquer que les champs multi-lignes sont directement à la ligne, et il n’y a rien après le : de la clé. Je peux donc utiliser ça pour reconnaître et parser les champs multi-lignes.
EDIT : J’ai un problème au niveau du document Transaction. En exemple j’ai le doc signé :
Version: 10
Type: Transaction
Currency: duniter_unit_test_currency
Blockstamp: 3-73434C90B0609B5B6A624D63EE1BD763B0E49CBF5D817321D8CA6875772F2260
Locktime: 0
Issuers:
DKpQPUL4ckzXYdnDRvCRKAm1gNvSdmAXnTrJZ7LvM5Qo
Inputs:
1200:0:D:DKpQPUL4ckzXYdnDRvCRKAm1gNvSdmAXnTrJZ7LvM5Qo:2
510:0:T:B6DCADFB841AC05A902741A8772A70B4086D5AEAB147AD48987DDC3887DD55C8:0
Unlocks:
0:SIG(0)
1:SIG(0)
Outputs:
1710:0:SIG(DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQdLV)
Comment:
coU3A3t0P7UkLQ6+O+utznx7ztLX2BuDtVRQ0ux9fwcRW1VgrOLzLXFTMzSGpUXW2Ad3kJzmfqA4hz2B8tBPCA==
Mon document généré (avec des @ à la place des espaces pour les voir) :
Version:@10
Type:@Transaction
Currency:@duniter_unit_test_currency
Blockstamp:@3-73434C90B0609B5B6A624D63EE1BD763B0E49CBF5D817321D8CA6875772F2260
Locktime:@0
Issuers:
DKpQPUL4ckzXYdnDRvCRKAm1gNvSdmAXnTrJZ7LvM5Qo
Inputs:
1200:0:D:DKpQPUL4ckzXYdnDRvCRKAm1gNvSdmAXnTrJZ7LvM5Qo:2
510:0:T:B6DCADFB841AC05A902741A8772A70B4086D5AEAB147AD48987DDC3887DD55C8:0
Unlocks:
0:SIG(0)
1:SIG(0)
Outputs:
1710:0:SIG(DNann1Lh55eZMEDXeYt59bzHbA3NJR46DeQYCS2qQdLV)
Comment:@
Avec un diff je ne vois aucune différence, hors je n’ai pas la même signature :
- Original :
coU3A3t0P7UkLQ6+O+utznx7ztLX2BuDtVRQ0ux9fwcRW1VgrOLzLXFTMzSGpUXW2Ad3kJzmfqA4hz2B8tBPCA== - Rust :
/pIiZaY9K7TIwMGJ+PUT0XPBd+NRXwQWaFUoEaAtAOApSHVpn/NtyTYWMIw/uATiSpacZwnodFIoIgQ9PukXCg==
Ce problème est reproductible dans les tests unitaires de la branche protocol-10-documents de duniter-rs.
Si quelqu’un à une idée du pourquoi ? 
(@cgeek ?)
Passe les documents dans une fonction de hashage pour vérifier qu’ils sont bien identiques, car la signature peut varier d’une implémentation de Ed25519 à l’autre.
Euh avec un diff j’ai pas de différence, donc ça ne devrait pas changer le hash. Je veux bien essayer, mais il faut que tu me passe le hash de ton document, si je le fait moi même je vais forcement trouver le même.
Par contre le fait que la signature peut varier suivant l’implémentation de ed25519 est très inquiétante, tu en es sur ?
Mais de toute façon ça ne peux pas être ça car mes autres documents sont correctement signés. Je dois faire une erreur débile dans le test mais là je ne vois pas xD
EDIT : ou alors c’est peut-être dû au champ multi-lignes, je vais regarder de ce côté là.
Oui logiquement le diff a dû déjà te donner le résultat.
Absolument certain. C’est notamment pour ça que Algorand s’appuie sur les VRF, afin justement de n’avoir qu’une signature possible pour un document donné.
Tu veux dire qu’ils produisent la même signature ? Mais la même signature que quoi exactement ? Je ne sais pas trop sur quoi tu compares.
C’est très bizarre ça. Comment un même algorithme ne peux pas être déterministe ? Ce n’est pas plutot la distinction entre les clés ed25519 et curve25519 ?
Tous les autres documents (sauf le bloc qui n’est pas encore fait) passent les tests. Mon code génère donc les même signature que dans tes exemples. (voir tests en bas de duniter-rs/protocol-10/members.rs). Donc je sais qu’au niveau des signatures ça marche. Mais pour ce document là ça marche pas. Il faudrait que je l’exporte en tableau d’octets et vérifier qu’il n’y a pas de caractères Unicode à la con qui trainent.
Voici un commentaire sur crypto.stackexchange.com :
However, that’s not enough, because signature schemes do not usually guarantee uniqueness of the signature. […] and the signer can choose any per-signature secret nonce they want without the verifier noticing.
Oui vérifie, l’espace insécable est très vite inséré dans le code. Normalement les diffs le repèrent, mais sait-on jamais. D’où l’idée du test avec une fonction de hashage pour être tranquille 
De toute façon dans le prochain protocole on pourra permettre d’utiliser d’autre schemas de signature comme les VRF.
Pour le hash ça sera le même problème que la signature : je saurais que ce n’est pas égal, mais je ne saurais pas d’où ça vient. Et puis s’il y a un espace insécable il est dans ton document, or ils ne sont cencé être que du texte simple (j’ai juste copié les hashs, clés, signatures, le reste est procédural).
Bon eh bien si tu sais te débrouiller, je te laisse chercher.
Interessant tout ça…
Ma conclusion : les TU doivent vérifier que la signature est vérifiable mais pas qu’elle est égale à une valeur.
Par contre les hash sont forcément déterministes 
On arrête pas d’en apprendre hehe…
1 Like
J’ai fait la modif pour vérifier la signature avec la clé publique plutôt que de signer le document avec la clé privée et comparer, et ça fonctionne, les tests passent sans problème.
C’est assez surprenant, mais ce n’est pas un problème en soit (vu que l’on peut bien vérifier les signatures, et que dans la pratique on ne va évidement pas générer la signature avec la clé privée pour vérifier qu’elle est valide).
Cependant je n’avais pas pensé qu’un document pouvait être signé par plusieurs personne quand j’ai fait mon trait, du coup ça pose problème pour des documents “Transaction” avec plusieurs signatures. Comme dis précédemment, je vais sûrement reprendre des parties du code mais refaire proprement tout ça avec des vrais types dédiés, et pas simplement des surcouches d’une HashMap.
Modération : Séparation de la discution sur l’implémentation de Duniter en Rust et de celle s’attardant sur le format des documents.
Je viens de regarder plus en détail le format. Il est intéressant, mais je pense d’abord travailler sur un format personnalisé. Peut-être que j’utiliserais XDR si je n’arrive pas à avoir un format “plus puissant”.
Sinon on peut stocker tout et n’importe quoi en Base64. Le Base64 c’est juste une façon de représenter/afficher des données sous la forme d’une chaîne de caractères.
Je vais bientôt plancher sur une RFC décrivant ce format personnalisé, et ensuite je porterais les RFC 1 et 2 vers ce nouveau format. L’une des idées est d’avoir une structure fortement typée qui pourrait être retranscrite de manière safe dans le système de types de Rust, de sorte qu’il y a une stricte équivalence entre les 2. Il serait bien évidement possible de le faire en TypeScript, même si je pense que ça sera moins pratique. Au final, on pourrait faire tous les échanges sous ce format “standard” qui pourrait être étendu selon les besoins.
2 Likes
Où en es-tu concernant les deux RFC DIP01 et DIP02 ?
J’aimerais participer à les relire et certainement les implémenter dans duniter-ts, mais ayant désormais très peu de temps je n’irai y jeter à nouveau un œil que quand tu estimeras la réflexion assez mûre.
1 Like
Je pense que je vais les reprendre avec un format de données plus standardisé et plus extensible, qui permettra par exemple de rajouter des champs optionnels ou simplement de nouveaux éléments sans faire quelque chose d’ultra-spécifique. Je pense que ça sera la RFC3 qui définira ce nouveau format avec à la fin le nouveau système de transactions. Quand ce document sera terminé et audité, tu pourras commencer à l’implémenter et je ferais de même de mon côté quand j’aurais implémenté le protocole actuel (même si je le fait de telle sorte qu’il soit “simple” d’implémenter le nouveau dans la même architecture).
Il me semble qu’actuellement il reste quelques discussions non résolus dans les 2 RFC, il faudrait donc y jêter encore un coup d’oeil. Pour la taille des transactions, je pense vraiment que le RFC1 ne doit pas préciser de limite car il ne précise que la structure, et pas dans quel contexte il va être utilisé.
Je pense que d’ici 2 mois on pourra commencer à l’implémenter
J’ai lu pas mal de documents sur le Lightning Network, et notamment son whitepaper. C’est plus complexe que ce que je pensais, mais si on arrive a comprendre entièrement son fonctionnement on pourra surement développer d’autres solutions de second niveau pour des usages avancés, sans les stocker dans la blockchain. J’aimerais vraiment que la blockchain reste très légère et ne stocke que le nécessaire, et qu’a terme la grande majorité des transactions se fassent via le LN.
Si nous sommes d’accord que la version 11 du protocole contient un changement du format vers du binaire, ainsi qu’un nouveau système de script pour les transactions; alors je vais travailler sur une RFC unique contenant les spécifications entières de la version 11, que l’on pourra ensuite implémenter dans duniter-ts (duniter-rs ne sera pas encore assez avancé je pense pour implémenter la version 10 et 11 rapidement).
Cette RFC contiendra :
- Un format binaire compact mais extensible, permettant d’avoir des documents de petite taille mais acceptant de nouveaux champs au fil des mise à jours.
- Le nouveau système de script/transactions qui utilisera ce nouveau format binaire.
- Le nouveau format des documents qui utilise ce format binaire.
Il pourrait être intéressant de rajouter les documents relatif à la communication réseau au format binaire.
Enfin il faudrait tester ce nouveau protocole sur une nouvelle monnaie de test (pour vérifier qu’une nouvelle monnaie puisse bien être créée avec ce nouveau protocole), puis amorcer la transition sur G1test. Quand tout ça sera fait on pourra envisager le déploiement sur G1.
EDIT : @cgeek tu as lu le whitepaper de LN ? Ça faisait longtemps que je n’avais pas eu une lecture technique aussi passionnante, et leur utilisation des signatures (incomplètes) est juste incroyable.
3 Likes
Me concernant oui, c’est acquis. Sauf à ce qu’après relecture je me rende d’un gros soucis, mais a priori ça devrait le faire
Je ne sais plus si j’ai lu leur whitepaper ou autre chose. J’ai principalement été intéressé par les channels, c’est très malin, mais je ne suis pas sûr que l’idée vienne du projet LN, et après la partie networking me paraissait encore floue. Il faudrait sûrement donc que je (re)lise ce whitepaper
Très bien, je vais donc plancher sur cette RFC3 pour dans quelques semaines.
Ce que je trouve hyper intéressant c’est la construction des contrats off-chain qui permettent d’invalider la publication des anciens états (ou plus exactement, la publication d’un ancien état par A permet a B de récupérer tous les fonds du channel car à n’a pas respecté le contrat). Tout ça est géré avec des contrats partiellement signés, et je suis sur qu’en creusant un peu on peut faire tout sorte de contrats plus complexes, ce qui m’incite pas mal à réduire ce que j’avais ajouté dans ma RFC1 et de ne proposer que le strict minimum, le reste pouvant être fait offchain.
Lien du white-paper : https://lightning.network/lightning-network-paper.pdf
Bonne lecture, et accroche toi bien
pour ajouter de la lecture
Je ne suis pas très convaincu par cet article.
Une solution très simple serait d’ouvrir un channel avec chaqu’uns de ses certificateurs et certifiés, puis que quelques personnes ouvrent des channels avec des entreprises proposant des services (uniquement les premiers donc, les autres pouvant ensuite passer par eux).
De plus sans création ou fermeture de channels, la montant verrouillé dans le LN est contant. Rien n’empêche de rééquilibrer les échanges en interne, de faire circuler les fonds (en trustless avec les HTLC) pour re-remplir son channel.
L’idée à terme est de faire toutes dépenses off-chain, et d’avoir la blockchain comme sécurité de cette seconde couche, de servir compte à froid (non utilisés pour dépenser directement) et bien évidement gérer les DU et la Web Of Trust.
Un gros problème dans Bitcoin c’est que cette solution est assez tardive et qu’elle arrive alors que Bitcoin connait des problèmes de congestion. Si nous arrivont à déployer un LN et à rendre son usage simple et “normal” alors que nous avons peu de membres (en tout cas tant que notre blockchain n’a pas de congestion), alors l’ouverture des channels peuvent se faire toute en douceur et ne posera pas de problèmes.
J’ai aussi lu (mais pas en détail) qu’il y avait un proposition d’intermédiaire entre la blockchain et LN qui permettrait de créer un groupe de personne en 1 fois, et qu’a partir de cet étape ils puissent créer autant de channels off-chain. Le LN serait alors une couche de niveau 3.
1 Like