Discussion autour de la RFC5 (devenue fygg)

protocole

#141

NEO fait consumer du gaz pour faire tourner les programmes Turing-Complet, on peut dire que ce sont des frais du coup :wink:

Mouai, pour l’instant j’ai pas été très convaincu par Steem xD


#142

Oui, ya 2 tokens, le NEO et le Gas. Le NEO s’échange s’en frais (car limité en volume), le Gas non. :slight_smile:


#143

Pour Duniter il faudra encore plus encourager les membres à faire tourner des nœuds calculant, et simplifier encore plus leur configuration. N’importe qui sans grande connaissance en info devrait pouvoir participer à l’écriture de la blockchain et du coup appliquer les “règles de modération” pour faire passer en priorité les transactions “positives” pour la blockchain.


#144

Tout à fait. D’ou l’intéret de pouvoir implémenter les noeuds sous deux-modes :

  • Light nodes qui vérifient l’historique de la chaine via le merkleTree pruné dans le temps
  • Full nodes qui archivent la chaine et permettent une vérification de bout en bout

Les lights nodes ayant pour cible des petits ordinateurs type rasp, alors que les full, plutôt de vrais serveurs / PC, avec du stockage.


#145

mais tous les deux pourront calculer des blocs ou seulement les “serveurs” ?


#146

Yeap, sachant que les light nodes stockent quand même l’historique des transactions de la fenêtre de fork.

Les 2 :wink: Les full nodes pourraient cependant permettre de voir l’historique complet des transactions, alors que les lights node ne font que ne garder que les informations nécessaires à régler les forks.


#147

Merci, de toute façon je me connais, j’installerai les deux :stuck_out_tongue:


#148

Un full node proposera toutes les fonctionnalités d’un light node, donc un seul suffit :wink:


#149

Sinon je pense que l’on devrait tout simplement interdire toute transaction qui créé des UTXOs inférieures au montant minimum, et trouver des solutions pour permettre des paiements de moins de 1 G1. Pour qu’un commerçant puisse accepter des paiements inférieurs au minium (disons 1 G1) :

  • L’acheteur construit le document de transaction avec la sortie du vendeur inférieur au minimum, mais ne la signe pas et l’envoi au commerçant. (il écrit tout de même l’unlock script de son UTXO en disant quel index de signature il utilisera)
  • Le commerçant rajoute une nouvelle source à lui introduisant assez de fonds pour avoir la sortie supérieure à 1 G1, et il rajoute ce montant à la sortie et signe la transaction : il a en plus vérifié que le montant était bon
  • L’acheteur vérifie que tout est bon, signe le document et le publie.

Il n’y a alors plus de destruction de monnaie dans le cas où le prix est inférieur à 1 G1.

Le 2ème cas à résoudre c’est quand un utilisateur fait une transaction et que le reste est inférieur à 1 G1, et qu’il n’a aucune autre source à disposition pour combler ce manque. S’il a d’autres sources à disposition il peut gonfler la sortie avec, mais sans je ne vois pas encore comment faire, a part payer un surplus ou faire un mini canal de paiement offchain en prévision que l’utilisateur ai une nouvelle source suffisante plus tard.

A noter que plus tard on pourra passer par le Lightning Network, mais pour la fermuture du canal il faudra aussi en prendre compte.


#150

Les paiement inférieurs à 1 Ğ1 ne sont pas détruits aujourd’hui. Seuls les clés contenant moins de 1 Ğ1 détruisent de la monnaie et voit leur compte mis à 0. Les outputs en centimes sont déja possibles.

Du coup j’ai plutôt l’impression que ta règle apporte une grosse régression par rapport aux fonctionnement actuel ?


#151

Les clés ne contiennent rien. Les clés permettent de dévérouiller des sorties non dépensées.

Les outputs en centimes sont déjà possible car implicitement un nouvel output est créé à partir du reste de la source, et je décris un processus explicite equivalent, sauf que la même clé pour la source et la destination n’est pas obligatoire. Je ne vois donc aucun régression par rapport au fonctionnement actuel.


#152

Ben si, pour envoyer un petit montant, là il faut que ça passe par 2 acteurs là ou il suffisait d’un seul auparavant.

Oui, mais les sorties sont associées à un montant sur une clé. C’est cette somme qui provoque la destruction des sorties associées ou non.


#153
  • Si l’ancienne source associée à la clé n’est pas détruite, alors on peut faire autant d’UTXOs que l’on veut avec la même clé et remplir la mempool, tant que la somme de ces outputs n’est pas en dessous du minimum ? C’est un beau vecteur d’attaque, et même s’il est freiné par des règles de priorité de transaction il n’en reste pas moins problématique à long terme.

  • Si elle est détruite et consommée implicitement, alors on consomme une UTXO sans la signature qui permet de la dévérouiller ? Qu’est ce qui se passe si c’est une UTXO multisig ? Et si un cannal de paiement est attaché à cet UTXO ? Toutes les transactions signées dans ce cannal et qui se basent sur l’id de transaction/id de l’UTXO sont maintenant invalides ? Plus de cannal de paiement possible, ni de Lightning Network.
    Edit : ça marche pour n’importe quel transaction qui serait pré-signée, même une simple signature, mais du multi-sig/channel est un bon exemple d’application importante.

En ayant une limite par UTXO, et un processus de “gonflage” explicit, on évite ces 2 problèmes.


#154

Faut voir, toute quantité peut être relativisée.

Pas faux, je réfléchissais encore à “je pompe dans le compte, je ne crée qu’une sortie”. Oublions ma remarque.

Je suis pas sûr d’avoir tout compris, peux-tu reformuler ?


#155

Honnêtement, je trouve que la gestion des centimes c’est se casser la tête pour pas grand-chose. Votre idée avec @elois disant que toute UTXO doit être >= 1,00 Ğ1 me paraissait simple, élégante et très efficace. Beaucoup moins coûteuse que l’actuel mécanisme de vidage de compte.

Alors certes, aujourd’hui on pouvait envoyer 0,01 Ğ1 à un compte qui possédait au moins 1,00 Ğ1, les 0,01 Ğ1 n’était pas perdues et le transfert fonctionnait.

Mais franchement, y a-t-il urgence économique à avoir ce mécanisme, alors même que M augmente perpétuellement ? Je ne crois pas.


#156

2 choses :

  • dans le document Membership il y a maintenant un script avec lequel sera verouillé les fonds si l’identité arrive à expiration. Ca permet déplacer l’argent dans une UTXO et de plus tard supprimer l’entrée du membre sans détruire de monnaie, et ça peut servir pour récupérer les DUs non consommés si la personne n’a plus ses clés ni son document de révocation, ou qu’elle est morte/disparue et pourrait être léguée à ses heritiers.
  • dans le document Revocation il y aussi un script qui verouillera les DUs non utilisés au moment de l’utilisation du document. Il peut comme ça transférer ses tous ses DUs vers une nouvelle clé, même s’il a perdu sa clé privée (document de révocation présigné).

Dans tous les cas, l’argent ne disparait pas et va dans une UTXO.

Il n’y a pas d’urgence puisque le protocole v11 ne va vraiment pas arriver de suite. Mais vu que l’on essaye de repartir sur des bases propres, autant le faire bien. Si on peut limiter les spams et éviter de détruire la monnaie, pourquoi pas le faire ?

Ca peut être n’importe quel lock script. Il vérouille les UDs non dépensés, et on le dévérouille en validant le script. Il est strictement equivalent à une transaction dans la seule source est le montant de DU non dépensé du membre et la seule sortie est une UTXO vérouillant ces fonds.

La personne/groupe qui pourra fournir le bon unlock script. Dans la cas d’un document de révocation, le propriétaire de compte. Dans le cas de l’expiration de l’identité, ça peut être le propriétaire qui a perdu son acces, ou des héritiers, voir les 2 (via un Or avec les 2 conditions). Ca peut permettre d’avoir une porte de secours en cas de problème, ou un “testament numérique”.


#157

Mais que contient ce script ? Quelles sources verrouille-t-il ? Et comment le déverrouiller ?

Même question, et in fine qui donc peut déverrouiller les sources ?


#158

Je sais pas ce que vous avez fait, mais la réponse de nanocryk est au dessus de la réponse de cgeek :face_with_raised_eyebrow:


#159

Il a posté son dernier message quand j’editais ma réponse au 2ème message, et je n’ai pas pensé qu’il allait s’afficher avant, my bad.


#160

On peut déjà mettre ses DU en UTXO avec une transaction, pourquoi utiliser l’adhésion ?

Et puis par quel mécanisme une révocation pourrait-elle déverrouiller des DU futurs ?

Mais avec la limitation à 1Ğ1 par UTXO il n’y a jamais de monnaie de détruite, au pire comme tu le dis cela empêche les micro transferts, ou oblige à refiler les derniers centimes de la source. Mais vraiment je ne trouve pas cela choquant, étant donné l’intérêt supérieur de conserver une monnaie fonctionnelle en empêchant l’explosion en taille de la BDD.