Machine à état et réponses prouvées des noeuds aux clients ?

Du coup on est obligé de chainer les transactions, et les clients doivent se mettre à jour continuelement pour récupérer le nouveau hash, et ça demande en plus de changer le calcul du hash. KISS non ?

Oui, sauf si tu as meilleure idée pour éviter le rejeu.

Ils doivent simplement connaître le nombre de transactions qui sont passées sur le compte.

C’est un argument ? :slight_smile:

Je t’ai donné mon idée : la transaction contient un champ “index” et chaque addresse à un “last_index” associé. Une transaction n’est valide que si “index > last_index”, ou alors pour éviter cette histoire d’ordre : “index = last_index + 1” (beaucoup mieux même). On ne fait que rajouter 2 champs, et ça évite un chainage (récursif du coup).

Après au final ça revient à peu près à la même chose je pense.

Plutôt que te souvenir de la transaction il faut te souvenir du nombre, donc oui c’est pareil.

Index : 2 octets dans la transac, 2 octect par addresse
Hash : 32 octets :stuck_out_tongue:

Après je trouve l’index plus pratique si tu veux envoyer un batch de 50 transacs par exemple, tu peux faire ++ pour chaque transac sans rien hash en plus, et sans attendre d’avoir hash la transac d’avant. Avec un traitement parellèle c’est pas bloquant :slight_smile:

Non mais on est d’accord, je ne comprends juste pas pourquoi tu veux ajouter le nombre dans la transaction ?

S’il y a seulement un compteur à côté de l’addresse (qui ne change pas son hash), comment tu fais pour discriminer les rejeux ?

Non le compteur modifie bien le hash à cibler par la transaction, tel que :

prochain_hash_à_donner_par_la_tx = hash(compteur + hash_compte)

Ah, je pensais que c’était prochain_hash = hash(compteur + ancien_hash). Mais du coup, le noeud doit garder en mémoire le dernier hash de chaque compte pour savoir à quelle compte correspond le hash donné en source ?

Par contre je me dis que ça peut être très sympa pour brouiller les traces, quelqu’un qui voit que les documents de transaction ne sait pas de quelle compte ça vient … Du coup ta solution est mieux, je m’incline :wink:

Oui j’ai effectivement dit cela un peu plus haut mais ce n’était pas bon tu le dis bien, cela oblige à stocker le hash courant du compte en plus. Du coup je suis passé sur une autre idée en te parlant :slight_smile:

J’avais plutôt pour idée qu’il était déterministe, un peu comme les clés clés hiérarchiques en fait. La suite de hash est connue d’avance, dès lors qu’on a le hash_compte.

Alors là c’est à toi d’expliquer car ce n’est pas à ça que je pensais ! :grin: D’ailleurs je ne vois pas comment ça marche.

1 Like

Oui du coup il suffit juste de stocker l’ID associé au compte à côté, ça prend 2 bytes donc c’est bon.

En fait, si justement on chainait les hashs comme tu disais plus haut, le hash du compte va changer et toutes les anciennes transactions seraient alors annonymisées pour quelqu’un qui ne stocke pas tout l’historique. Mais du coup ça poserait problème avec les scripts-chains … Mince.

Bon, je pense qu’on va rester sur ton idée de hash(index + compte) et la liste des compte -> (quantité, index) dans un document référencée dans l’arbre de Merkle. C’est simple à gérer, c’est déterministe et prévisible à l’avance.

Edit : en conclusion les inputs sont hash(index + compte) et pas compte ?

2 Likes

Oui c’est ça.

Si je comprend bien ça veut dire que ne peut être écris en blockchain qu’une tx qui fourni comme hash, hash(previousIndex + compte) avec previousIndex = zéro par défaut, c’est bien ça ?

hash((previousIndex + 1) + compte)

Sinon il y a bien la forme d’anonymisation que je voyais : vu que la source ne donne que hash(index + compte) et que en bloc cet index est incrémenté, il est difficile de retrouver après coup dans quel compte il a pioché. Il faudrait tester en brute force plein d’indexes pour chaque compte.

“Dont le hash de la source à débiter est égal à”, mais sinon oui c’est ça.

Qu’appelle tu la source a débiter ? Puisqu’il n’y aurait plus de sources

Oui, certes, disons plutôt “Dont le hash courant du compte à débiter est”.

Enfin après il y a peut-être un meilleur qualificatif, mais vous voyez l’idée :slight_smile:

Une transaction avait des sources (des comptes) et des sorties (des comptes aussi).
Sauf que maintenant les sources sont hash(index + compte), du coup le compte est masqué (on ne connais ni l’index, ni le compte). Il est facile de le trouver au moment de l’insertion en bloc / vérification, vu que le noeud connait l’association (index, compte) -> hash(index + compte). Mais quand il incrémente l’index, il override cette association et l’ancienne est oubliée. Du coup en regardant uniquement cette ancienne source il est impossible de savoir le compte prélevé ni l’index. Se souvenir de tous les hashs demanderais trop de place, ça serait comme stocker l’historique de toutes les transactions, ce qu’on a réussi à supprimer :slight_smile:

Et comment fait un client pour connaître les sources disponibles pour une clé donnée ?

Il peux récupérer le compte -> (index, amount) du dernier bloc, calculer hash(index, compte) et l’utiliser comme source. C’est la seule source disponible pour cette “clé” (compte). Il peut toutefois calculer les suivantes à l’avance en incrémentant index.