Doc protocol example tx format

j’entends bien ce que vous me dite,

je fais comment pour unlock ??? XHX((1234) ???

Voilà, très bien, et @inso t’a déjà répondu : XHX attend comme déverrouillage un ensemble de caractères alphanumériques.

Le fait que tu aies demandé l’impossible avec un déverrouillage comprenant des caractères tels une parenthèse te regardent. Tes Ğ1-Test sont tout simplement perdues.

1 Like

la c’est clair :slight_smile:
maintenant peux tu me préciser où dans le protocol est il stipulé que je ne dois en aucun cas utiliser de tel caracteres dans mon pass pour utiliser la fonction XHX ?

Ce n’est pas indiqué. Et donc, qu’en conclues-tu ?

J’en conclus qu’une petite phrase en + c’est pas de refus :slight_smile:

Et quelles actions crois-tu mènent à cette petite phrase en plus ?

Par exemple, est-ce que faire un feu de bois et danser autour en invoquant l’esprit divin permettra de façon efficace à cette phrase d’être ajoutée ?

je ne crois rien, je constate

qu’une âme charitable veuille bien se donner la peine de changer la page,
maintenant il est dit que :

etant donné que le protocol qui fait foi , est infiné le code développé, je ne peux pas me fier au document :

duniter/doc/Protocol.md at master · duniter/duniter · GitHub

donc est ce a moi de faire la demarche, ou encore de demander l’autorisation (ou pas) et de faire acte de changer ce document ?

pour le coup j’ai envie d’invoquer le dieu “giiiiit”

La meilleure des choses à faire : une Pull Request !

1 Like

@Max plutôt que discuter des heures sur ce qui devrait être il te suffit de compléter toi-même la doc et de soumettre une PR, c’est ce que je fait quand je trouve un oubli dans la doc, pas besoin de demander l’autorisation pour ça, si ton ajout est correct, on mergera :slight_smile:

Non là tu es en train d’invoquer le dieu « les autres ». Ce qui n’est certainement pas la voie la plus rapide pour réaliser ce qu’on souhaite voir advenir.

Pourquoi ne serais-tu pas l’âme charitable, plutôt que de demander aux autres de faire les choses à ta place ?

Oui exactement c’est le code qui fait loi. Or, le fichier “Protocol.md” n’est pas le code.

Oui enfin dans l’idéal la documentation devrait faire foi, il conviens de reconnaitre que nous avons du boulot de ce coté là :stuck_out_tongue:

Mais ce n’est pas de critique dont nous avons besoins, c’est de contributeurs, alors lorsque vous repérez un manquement, sortez votre git et soumettez nous une PR :slight_smile:

Je suis d’accord avec toi cgeek pour “voir advenir”
Ne prends pas mal ma remarque au regarde de tes propos:

Je ne suis pas OK sur ce point,
j’ai cru comprendre que tu souhaitais toi même qu’il y est dans un premier temps discussion sur le forum avant d’interagir avec git dans certains cas…

ce que je fais, tout comme je dis plein d’anneries et que je test, infiné assujetti a l’erreur,
il etait a forciori souhaitable en amont que je discute de la fonction XHX dont je n’avais pas reussis a faire la transac et qu’apres discussion elois m’a invité a faire une issue qui apres re analyse n’avait pas lieu d’être…
(voir les precedents posts)


maintenant a la lecture partielle que je viens de faire du document :
.duniter/app/lib/common-libs/constants.ts at dev · duniter/duniter · GitHub

si je ne dis pas de bêtises, tout est basé sur des expressions regulieres,
si tel est le cas, je trouve cela étonnant…
un parseur fait une lecture caractere apres caractere …puis l’analyse qui en decoule…


Elois , je ne suis pas d’accord, bien au contraire
maintenant a vous de considerer si ce sont des critiques constructives ou non…

Et après le constat, on fait quoi ?

Pour les nouveaux développements. Et de toute manière, tu peux toujours proposer une modification du code sous la forme d’une PR. Elle peut être acceptée, refusée ou en attente d’analyse, ça ne fait aucun mal. Au contraire, si jamais la modification est pertinente cela fera gagner un temps précieux car la modification s’intègre en 1 clic.

Au contraire, discuter de façon interminable ne mène pas à la modification voulue.

Tout document passe par 3 étapes :

  1. vérification de la forme (expressions régulières)
  2. vérification de la cohérence locale (le contenu du document en lui-même)
  3. vérification de la cohérence globale (le contenu du document vis-à-vis des autres documents, au sein de la blockchain)

Les étapes 2 à 3 voient l’analyse du contenu opérer, notamment le parser syntaxique. Mais l’étape 1 se contente de dire « ça ressemble à ce qui est attendu » sans autre forme de procès.

2 Likes

Pour revenir sur le parsing

J’ai validé sur GTest une transaction telle que condition d’output:

52000:0:(SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ) || SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY)) && (CLTV(1509750000) || CSV(10))

dit autrement :

( [ sig m8 ] OU [ sig 7t ] ) ET ( [ samedi 4 nov 2017 00:00 ] OU [ block temps median + 10 sec ] )

donc je fais une nouvelle transaction apres quelques minutes passées pour test la deuxieme partie de la condition
a savoir atteindre une date précise OU 10 sec se sont écoulées du temps median du block sur lequel je me suis basé pour faire le document (EDIT: ou alors c 'est plutot le temps median du dernier block calcule, je sais plus trop…)

soit mon nouveau document de transaction, avec comme unlock:

52000:0:SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY)

et la j’ai un wrong unlocker en réponse…
je vais attendre de voir minuit passé si je peux unlock.
je me pose la question pourquoi je ne peux pas unlock quand bien même la condition CSV(10) est OK
j’ai zappé quelque chose ?


Sachant que de telles conditions d’ouput pour l’exemple:
SIG(7t38…) && CSV(10)

je peux unlock sans probleme en attendant un peu avec comme unlock
…:0:SIG(7t38…)


EDIT:
je viens de valider avec la clé m8z qui se trouve être la premiere clé de la condition :

52000:0:(SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ) || SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY)) && (CLTV(1509750000) || CSV(10))

en produisant:

52000:0:SIG(m8z…)

et je confirme le cas :
sur une condition de lock telle que

(SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY) || SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ))

seule la premiere signature 7t38 est en mesure de consommer la ressource


EDIT 2:

(SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY) || SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ)) && XHX(03AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4)

unlock et validé avec

Issuers:
m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ
7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY
Inputs:
52000:0:T:40EB012763DD2F91252E28E2C1696555AC9F03134E36F3EACDFD9B3E94C83231:3
Unlocks:
0:SIG(1) SIG(0) XHX(1234)

au lieu de

0:SIG(0) XHX(1234)

en résumé
(SIG A || SIG B ) && XHX —> nécessite SIG A && SIG B

Merci, j’ai pu écrire un test et je reproduis l’erreur.

En fait, ce sont les fonctions checkSourcesAvailability et unlock qui sont incorrectes dans le cas de multiples conditions. Ces fonctions deviennent sur-contraignantes, et ne permettent pas le déverrouillage comme espéré : c’est-à-dire que les conditions OU se comportent parfois comme des ET, tandis que les ET restent des ET. Bref il faut avoir quasiment toutes les conditions remplies à la fois.

Donc je vais réécrire ces fonctions, clarifier leur comportement et aussi réécrire un peu le protocole sur cette partie.

3 Likes