Sachant qu’il y a toujours un potentiel “spam” des documents de transactions en ces adresses, mais ce n’est pas trop grave car elle n’existeraient que pendant 1 bloc, vu que l’on “stocke” l’état complet dans les arbres.
C’est à dire “la logique de chaînage des transactions” ?
Ce qui est super avec cette agrégation en comptes, c’est qu’il n’y a plus le problème de “j’ai trop de sources vers ma clé publique pour une transaction”.
1 Like
Vous parliez plus haut de transactions en parallèle. Il serait bon d’obliger à chaîner les transactions de sorte qu’on ne puisse pas juste dépenser 20, 30, 26, 14, 20 en même temps depuis un même “compte” et que seule la dernière somme soit invalidée par manque de fonds.
Je veux dire : ce n’est pas le “manque de fonds” qui doit empêcher la dépense, mais plutôt l’indisponibilité de la source.
1 Like
Je vois ce que tu veux dire, mais je ne vois pas comment permettre ces dépenses parallèles sans retrouver les mêmes limites qu’avant. Pour moi ça me semble être un comportement normal que l’on puisse “dépenser 20, 30, 26, 14, 20 en même temps depuis un même “compte” et que seule la dernière somme soit invalidée par manque de fonds”. Normalement l’utilisateur ne devrait pas essayer de dépenser plus qu’il n’a (un client dévirait l’empêcher), et s’il essaye (à la main) certaines transactions sont refusées. Je ne vois pas de problème à ça en tout cas.
On a une possibilité d’oublier la notion même de chaînage, ça me semble dommage de la remettre 
Je répondrai ce soir. Il me semble au contraire qu’elle est indispensables à certains mécanismes de smart contracts.
1 Like
Je viens de me rendre compte que ça pourrait permettre de rajouter ou d’enlever de l’argent dans un channel Lightning sans le fermer ! C’est juste génial !
Et pour des SC qui veulent empecher le “mixage”, il leur suffit d’imposer une condition sur les valeurs des outputs de tel sorte qu’ils correspondent à l’entrée. Si j’ai 2 SC qui verouillent 2x10 G1, on ne pourrait pas l’utiliser pour avoir 5 et 15 G1, mais seulement 10 et 10, comme s’ils étaient indépendants.
2 FetchOutputScriptHash IsEmpty Verify
0 FetchOutputAmount 1 FetchOutputAmount Add 1000 NumEqual
ou
2 FetchOutputScriptHash IsEmpty
0 FetchOutputAmount 1 FetchOutputAmount Add 1000 NumEqual
And
La notion de comptes permet aussi de largement simplifier le fonctionnement des clients.
Edit/Note : Les UDs pourraient directement être ajoutées au compte ayant pour script
CheckSigHash <compact public key>
ce qui permet de retirer le cas particulier “la source est un DU”.
Edit 2 : Je suis en train d’ajouter tous ces éléments à la RFC qui commence a être pas mal éloignée de l’idée actuelle de ce nouveau protocole 
Edit 3 : Vu que les identités sont supprimées un certain temps (à définir) après leur révocation, est-ce qu’il devient possible de réutiliser un username ? Sinon si on veut empêcher ça, il serait nécessaire de stocker la liste de tous les usernames qui ont étés utilisés depuis le début de la monnaie, ce qui me semble être assez problématique avec un nombre de membre plus important et la rotation des individus.
Edit 4 : RFC mise à jour. La partie bloc/Merkle tree n’est pas encore faite mais les autres idées ont été prise en compte.
2 Likes
Donc pour reprendre ma réponse : certains smart contracts, notamment ceux nécessaires aux échanges automatisés cross-blockchains, nécessitent le chaînage des transactions. C’est-à-dire qu’il est nécessaire qu’une transaction T2 ne puisse n’être dépensée que si T1, sur laquelle elle est basée, passe préalablement.
Autrement dit, ce que je ne voudrais pas :
,--> TX1
C1 -|--> TX2
`--> TX3
Mais plutôt :
C1 --> TX1 --> TX2 --> TX3
À noter que cela n’empêche en rien le compte C1 de réaliser ses 3 transactions d’un seul coup. Mais on est absolument certain alors que TX3 passera après TX2, qui passera elle-même après TX1.
De sorte que si TX1 ne passe pas, ni TX2 ni TX3 ne passeront non plus. C’est cette assurance dont on a besoin.
Et donc peu importe si quelqu’un est en possession de TX2 ou TX3, tant que TX1 ne passe pas, rien d’autre ne passe.
Note : en écrivant ce message, j’ai quelques doutes sur le “on a besoin”.
je réfléchis…
1 Like
Alors T1 aura un script qui s’assurera de ça, notament avec l’opcode FetchOutputAddress (permet d’imposer le script de la transaction suivante), et aura donc un autre script hash, donc pas d’aggrégation. (C’est les “script chain” dont je te parlais aux RML 
)
T2 quand a lui peut être half-signed (comme dans LN) et imposer de dépenser de cette adresse précisement. On a donc bien un chainage des transactions obligatoire.
De plus, cet échange cross-blockchain pourra être réalisé avec des LN, et ce même avec ces transactions parallèles.
Si c’est vrai, alors je ne vois plus vraiment d’objection.
Oui, et ça permet d’alléger considérablement la taille d’une transaction aussi. Et ça simplifie à l’extrême la génération de celles-ci d’ailleurs … les clients ont juste à “puiser dans le compte” sans autre soucis que vérifier qu’il reste assez de Ğ1.
Donc pour résumer l’idée (j’en ai besoin) :
- le script associé à un output de transaction = condition de déverrouillage
- hash(script) = compte
Peut-être oui, mais déjà ce serait bien que ce soit faisable sans LN
1 FetchOutputAddress IsEmpty Verify
0 FetchOutputAddress <script_hash> BitEqual
ne peut être dépensé que par une transaction n’ayant qu’un seul output avec le script <script_hash>
Compte/addresse. J’ai détaillé ça dans la partie 2.7. Keys. En gros un utilisateur pourra rentrer soit une clé publique (qui sera “convertie” en script correspondant correspondant à son dévérouillage) soit directement le hash de script. Les 2 sont au même format qui inclu aussi un checksum et un code de la monnaie, il est donc impossible de l’utiliser sur une autre blockchain Duniter et la faute de frappe est très improbable. Il faudrait que je test cet encodage et regarder si on peut le voir rapidement sans le décoder.
En vrai ce n’est même pas du LN, c’est juste une négociation off-chain avec un multi-sig C’est LN sans la partie Network (ni la partie Lightning du coup C’est le “”)
2 Likes
Tu es taquin ! J’aime bien
2 Likes
Hehe 
Du coup tu vois d’autres problèmes (ou peut-être certains qui n’ont pas encore été réglés) ?
… Du coup … Maintenant que les sommes des “addresses” sont fusionnées et qu’on les met à jour, sommes nous encore obligé de stocker leur base ?
Le seul endroit où on ne peux pas enlever les bases c’est dans les scripts, vu qu’ils sont hashés et qu’on ne peux pas forcement savoir quelles valeurs sont en (base, amount). Mais même avec ça, ça élimine une très grosse partie de la complexité des valeurs monétaire en tout cas.
Aie, ya un problème. Si mon addresse à plus de 20 G1 en réserve, et que j’envoi 10 G1 a quelqu’un, elle peut être replay pour me prendre 2x10 G1.
Une possibilité est que dans chaque transaction on doit fournir un nombre, et il faudra que les transactions suivantes aient un nombre plus grand. On peut autoriser dans un bloc plusieurs transactions venant de la même source tant qu’elles ont un nombre différent et qu’il est supérieur au compteur du bloc précédent. On prévois ce nombre assez large pour couvrir tous problèmes (4 octets ?) et au cas où on prévoit un système d’interval autorisé et de rotation.
Edit : 2 octets et un nouveau nombre au plus de 1024 du bloc précédent me semble amplement suffisant, non ?
Si les transactions sont obligatoirement chaînées comme je l’ai montré plus haut, il n’y a pas ce problème de rejeu justement.
Concrètement c’est assez simple, cela signifie juste qu’il faut pointer vers le bon “hash” de la source. Dans Duniter aujourd’hui, on peut dire que la source est une TX dont on pointe le hash. Dans le nouveau système, on peut tout simplement dire que le hash de la source = hash(ancien hash de la source + hash de la transaction). De ce fait à chaque transaction, le compte change de hash mais pas de hash(script).
Tu me suis ?
Et du coup on doit continuer a stocker l’historique des transactions, et on pert l’avantage du groupement par script hash. Si on ajoute un compteur pour chaque “script hash” par contre on peut faire autant de transactions non-dupliqué que l’on veut et sans attendre d’avoir fait les autres, et sans stocker d’historique en plus.
Note : pour que ça soit optimal le noeud doit préférer prendre en priorité les compteurs les plus petit, comme ça si tout le batch de transac ne passe pas elles resteront toutes valides.
Oui tout simplement ! Un compteur ! Je disais le hash de la transaction pour que ce ne soit pas prédictible, mais après tout … pourquoi pas
Je n’ai pas compris ?
C’est ce que je disais dans mon message précédent x)
En gros si quelqu’un veut envoyer des pleins de transactions et qu’elles ne rentrent pas tous dans un bloc, un noeud devrait prendre les plus petits “index” pour qu’au bloc suivant toutes les autres transactions soient valide. S’il prend les indexes les plus grand, alors au bloc d’après toutes les autres transactions ne seront plus valides car inférieures au compteur.
Ah OK, je pensais à plutôt à un incrément automatique, genre “le compte a été mis à jour X fois”, alors le nombre = X.
Il faut que ça soit contenu dans le document de transaction, sinon ça n’empeche pas l’attaque de rejeu.
Non : je veux dire le hash du compte bouge à chaque transaction, au niveau blockchain. Il n’y a pas d’action particulière à faire ni de nombre à donner.
Dès que la transaction passe, le hash change automatiquement.