Alors j’ai travaillé là-dessus hier soir et ce soir, et je me suis rendu compte qu’il est impossible de générer toutes les transactions intermédiaires cotés serveur en l’état actuel du protocole, voici pourquoi :
Les sources de monnaies provenant de transactions antérieures sont identifiées par le hash de la transaction d’origine, or ce hash se calcule à partir du document complet avec signature: il est donc impossible de générer en même temps plusieurs transactions chaînées sans posséder la clé privée de l’émetteur.
On peut évidemment réfléchir à la redéfinition du hash d’une transaction pour une future version du protocole mais ça attendra, car je ne souhaite pas intégrer de nouvelles modifications à DUPBv13 autre que celles prévues afin d’éviter un effet tunnel trop important.
parenthèse effet tunnel
Déjà qu’il n’y a pas eu de nouvelle version de Duniter depuis 5 mois alors que je voulais releaser plus souvent :
Fin septembre j’étais à deux doigts de commencer la campagne de test de duniter 1.9, c’est suite aux demandes de @kimamila que j’ai décidé de retarder la release pour y intégrer un prototype de GVA + réintégrér certains changements du DUBPv13 que j’avais prévu de reporter.
Bref tout ça pour dire que, en attendant, je souhaite tout de même permettre le paiement simplifié de gros montant sans changer le protocole. Voici comment :
Avec deux échanges supplémentaires entre le client et le serveur pour chaque niveau de profondeur.
J’ai conçu un algorithme qui minimise le niveau de profondeur, ce dernier ne sera que de 2 dans la très grande majorité des cas.
Voici un tableau qui résume le nombre d’aller-retour client<->serveur en fonction du nombre de sources de monnaie nécessaire :
| Nombre de sources |
Profondeur |
AR client-serveur |
Nombre de tx doc |
| 1-40 |
1 |
2 |
1 |
| 41-1600 |
2 |
4 |
2-41 |
| 1601-64000 |
3 |
6 |
42-1641 |
| 64001-2560000 |
4 |
8 |
1642-65641 |
On peut continuer le tableau à l’infini, mais dans 99.99% des cas on sera dans la 2ème ligne, même pour des très gros montant, c’est à dire 4 AR client-serveur au lieu de 2 
L’implémentation est presque terminée, je gère déjà la génération des transactions de change, ce qu’il me manque c’est la prise en compte des sources de monnaie en mempool parmi les sources de monnaies utilisables, détail absolument nécessaire pour que les cas de profondeur 2 ou plus puisse fonctionner sans avoir besoin d’attendre qu’un bloc (voir plusieurs) passe entre chaque étape.
Il est donc théoriquement déjà possible d’envoyer de gros montant via le paiement simplifié de GVA à condition d’avoir beaucoup de temps pour le faire, mais ce n’est pas très pratique, il vaut mieux attendre que j’implémente le «détail» ci-dessus.
