Doc protocol example tx format

fait : https://github.com/duniter/duniter/commit/169b9024672ca5d80baf9a9d6424fb0eaf054a32

1 « J'aime »

J’ai 2 points a signifier :

le 1er , concernant le formatage du document de transaction, chaque ligne etant séparé par un ‘\n’ dans les logiciels clients,
et que au vue de la doc sur l’api http et le retour a tx process, le champ “raw”’ induit en erreur et laisse penser que c’est ‘\r\n’ pour le composer…ici: https://github.com/duniter/duniter/blob/master/doc/HTTP_API.md#txprocess

2e point , j’ai effectuer des requetes curl pour test la signature,
je suis tombé sur :

{
“ucode”: 1005,
“message”: “Document has unkown fields or wrong line ending format”
}

qui me donne a penser que j’ai un soucis d’encodage, soit…

par contre je suis tombé sur une erreur comme :

{
“ucode”: 1002,
“message”: “Cannot read property ‘push’ of undefined”
}

dont je ne trouve pas la définition ici : https://github.com/duniter/duniter/blob/master/app/lib/common-libs/constants.ts#L129
et me semble plus liée à une erreur de JS…“cannot read…”

Oui c’est une erreur.

La définition de l’erreur 1002 est donnée ici, sur la branche dev. C’est en effet une erreur non contrôlée.

Tu devrais la voir plus en détail dans les logs de ton nœud Duniter, si tu en utilises un contrôlé par toi.

Aussi si tu reproduis l’erreur, ce serait bien que tu nous partage le document envoyé, quitte à remplacer quelques caractères de la signature pour empêcher qui que ce soit de voler les unités de monnaie afin que l’on puisse reproduire le cas systématiquement dans un test automatisé pour verrouiller un correctif.

le script bash se presente de la maniere suivante:

tx="mondoc_bien_formaté"
ev=$(python -c “import urllib; print urllib.quote_plus(’’’$tx’’’)”)
curl -H “Content-Type: application/x-www-form-urlencoded; charset=utf-8” -d “transaction=$ev” http://g1.duniter.org:10901/tx/process

pour l’instant je fais mes tests sur g1.duniter.org

a noté que depuis j’ai une erreur de signature :

“ucode”: 1002,
“message”: “Signature from a transaction must match”

de memoire (et si toutefois j’arrive a la reproduire) l’erreur 1002 etait liée aux differents tests que j’ai fait sur l’utilisation de python, tout comme j’avais le champ blockstamp = hash (erroné) au lieu de blockstamp=number + hash
j’ai testé plusieurs manip pour encode ma variable (ev) …
avec :

ev=$(python -c “import urllib; print urllib.quote(’’’$tx’’’)”)
ca me renvoyé des erreurs lors de la requete tx/process (ucode: 1005)

et un moment je suis tombé sur la 1002 (je ne sais plus comment)…


la mon probleme c’est surtout la signature qui est invalide, les différentes implementations de nacl / de l’algo ed25519 sont assez “flou”, entre l’usage du sha256 voir sha512, de comment recuperer ma cle privé en dur , c’est compliqué…


Au passage, c’est pas encore clair pour moi la situation suivante:

supposons que j’arrive a signé un document de transaction avec un numero de bloc 5000
que je garde cette transaction valide au chaud ^^
j’ai : blockstamp = 5000-HASH_BLOCK

que dans 1 semaine, 10 mois, 50 ans
je decide de faire une requete tx/process avec ce document, et par consequent ‘loin’ du block actuel en blockchain
on est bien d’accord qu’il sera rejeté ?
si oui il y a rejet, a quelle “distance” de block ma tx reste valide ?
ou dit autrement combien de “temps” je dispose pour envoyer une requete ?

Oui.

1 semaine :

https://github.com/duniter/duniter/blob/da85e4c3ba8e18a66b0c216335454473e1c205ae/app/lib/common-libs/constants.ts#L159

yop, erreur 1002 reproduite,
quand j’envois du bouzin, 500 fois le caratere A dans tx: (et 1 fois A aussi sort l’erreur 1002)

#!/bin/bash
dom="g1.duniter.org:10901"
tx=$(perl -e “printf 'A’x500”)
echo "$tx"
ev=$(python -c “import urllib; print urllib.quote_plus(’’’$tx\n’’’)” ) [erreur 1002 avec et sans le \n]
echo ""
echo ""
echo "$ev"
echo ""
echo ""
curl -v -H “Content-Type: application/x-www-form-urlencoded; charset=utf-8” -X POST -d “transaction=$ev” http://$dom/tx/process

ucode": 1002,
“message”: “Cannot read property ‘push’ of undefined”

1 « J'aime »

Merci, ticket #1139 créé et corrigé.

Le correctif sera déployé avec la 1.6.9 de Duniter.

Yop,

j’ai du mal a saisir “l’application” de la fonction de lock XHX
.https://github.com/duniter/duniter/blob/master/doc/Protocol.md#xhx-function

le cadre d’usage, pourquoi l’utiliser, quel est l’intérêt de composer un document avec cette fonction ?


concernant les 2 functions CSV et CLTV,
a y regarder cela me semble redondant, je n’arrive pas a discerner quels peuvent être les usages où l’on va préférer l’une a l’autre

CLTV => unlock at date
CSV => unlock after time elasped

CLTV => un trigger
CSV => un compte a rebours


PS @elois, je ne peux pas être présent au RML10

Ces fonctions ont été introduites dans le cadre du crosschain trading, autrement dit de faire du change inter-blockchain sans tiers de confiance. XHX ainsi que le champ timeout des transactions permet de faire ce type d’opérations.

Je t’invite à lire la description de ces fonctions dans le wiki Bitcoin, car dans Duniter elles sont identiques.

Ces fonctions ont été introduites dans le cadre du Lightning Network pour réaliser des paiements instantanés.

1 « J'aime »

Houston,
i’ve got a problem.

La situation est la suivante,

clé => compte en banque
7t38… => beaucoup de monnaie GT
m8zQ… => 0 GT
6H8L… => 0 GT

Je test l’utilisation de XHX selon le deroulement suivant :

7t38 envois 10 a m8zQ , puis m8zQ envois les 10 a 6H8L

7t38 crée un document de transaction tel que dans la liste outputs :
SIG(m8zQ) && XHX(sha256(1234))

ok, document enregistré et validé, visible dans l’historique de 7t38 comme derniere transaction:

une vue sur les sources de m8zQ avant et apres que le document soit enregistré:

m8zQ_sources

dès lors le document de 7t38 enregistré en blockchain,

je crée donc un document dont le but est que m8zQ débloque cette ressource et envois 10 unités a 6H8L

et la je patauge, je ne comprends pas pourquoi la source est « déjà consommé »…
et je ne vois pas comment m8zQ peut utiliser ces 10 unites verrouillé par 7t38.

1 « J'aime »

Peux-tu partager ici même le document de transaction complet ? Celui qui ne passe pas. Afin que j’essaye de reproduire sur un nœud local en mode debug.

https://pastebin.com/Lrn5X1JR

C’est bon j’ai trouvé, voici une excellente leçon ! :slight_smile:

La règle est : tout compte doit posséder au moins 1,00 Ğ1. Si celui-ci possède moins d’unités que cela, les unités restantes sont immédiatement détruites (« consommées »).

Tu as envoyé 0,1 Ğ1 sur le compte (SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ) && XHX(03AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4)).

Celui-ci a donc immédiatement été nettoyé. :smiley:

Merci pour ce test !

je viens d’en faire un deuxieme,
avec comme lock uniquement XHX
cle 7t38 => milliers de GT
cle ANy => 1047 units
cle 4WF => 0

7t38 cree lock
20:0:XHX(6B86B273FF34FCE19D6B804EFF5A3F5747ADA4EAA22F1D49C01E52DDB7875B4B)

ANy test le document en direction de 4WF:

Issuers:
ANyDaYrQVFXd7XYrJs4bbuSWaYnP3mXGc5tWB9c4V5FY
Inputs:
20:0:T:B28939C91BBB386AD00B53566FFE73B250CE0982287CB1068FD119473D28B6F0:1
Unlocks:
0:XHX(1)
Outputs:
20:0:SIG(4WFGHpVuh9tw58Ft5N5kZA5UdshPxyCvN7NZu2Der5hR)

et duniter retourne 2015 Source already consumed

Oui, c’est ce que je viens de dire : tu as envoyé 0,20 Ğ1 cette fois sur un autre compte :

XHX(6B86B273FF34FCE19D6B804EFF5A3F5747ADA4EAA22F1D49C01E52DDB7875B4B))

Qui après l’opération, ne possédait que 0,20 Ğ1 => le compte est immédiatement nettoyé.

D’ailleurs ce compte se finit par 2 parenthèses, je ne sais pas si la monnaie aurait pu être débloquée même avec 1 Ğ1 dessus.

@Max rappelle toi que tout les montants sont exprimés en centimes dans les documents, donc il faut que tu envoi au moins 100 sur un compte si tu veut que ça fonctionne :wink:

Yop,

j’ai une proposition a faire en lien avec la fonction XHX,

pour la création d’un tel document , no problemo

c’est plutôt dans la partie consommation de la ressource que ca devient un peu complexe,

pour ce faire et en l’état,
si j’effectue une transaction avec XHX(sha256(value))
je garde au chaud le Blockstamp de cette transaction, surtout son “number”:
ex:

Blockstamp: 72945-000017E685D29D14480F60BEEF5B654E1ADB14AFCC66EDF103193AD001631F9E

et ce a fin de recuperer dans la blockchain non pas le hash du block, c’est bien le hash de la transaction qui doit me permettre de consommer la source dans le futur

la je fais:
block a recuperer = 72945 + 2

/blockchain/block/72947

dans lequel je doit verifier les transactions si il y a bien un lock qui correspond a celui que je cherche a deverouiller, tel que : XHX(sha256(value))

concernant le “+2”, soit c’est parce que “j’ai de la chance” soit ce sera toujours a +2 block de celui concernant l’envois de ma transaction
sinon quoi je doit utiliser

/blockchain/block/72945/72955
en me disant que je vais regarder dans une fenetre de 10 block…
soit j’utilise encore /blockchain/with/tx …
etc…etc…

pour consommer et deverouiller je dois iterer et trouver:
–> block concerné–> transaction concernée --> XHX present


Sur un point optimal, la possibilité d’avoir le HASH de cette transaction inscrit dans les sources.

tel que pour le developpement d’une application client,
facilite grandement la tâche, minimise le nombre de requetes et d’informations a transiter sur le reseau

ce qui permet à la clé m8zQ de debloquer la ressource envoyé par 7t38
ex:

ajouter la clé “txhash” : “A1B2C3…”

a la ressource suivante que m8zQ dispose et souhaite utiliser

“type”: “T”,
“noffset”: 1,
“identifier”: “90E6F6C973E0147838EA15F0090F5BBA7236FE1AF494BF12B16E9B9C64C892BE”,
“amount”: 1234,
“conditions”: “(SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ) && XHX(03AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4))”,
“base”: 0

et ce en composant un nouveau document de transaction que m8zQ s’adresse a lui même
tel que le champ unlock
SIG(0) XHX(le pass)

Oui BMA n’est pas optimisé c’est pour ça qu’elle est indiquée comme obsolète sur al web-ui, on a besoins de dev motivés pour recréer une nouvelle API client de zéro :slight_smile:

Concernant ta remarque les sources de type T sont bien indexés par hash de transaction dans la bdd de duniter donc ça peut se faire en une requête c’est juste que l’API BMA ne le permet pas c’est tout.

Ok, c’est noté,

pour essayer de faire le job de mon coté, j’ai besoin de recup la base de données de g-test, je n 'ai pas retenté la synchro depuis la derniere fois… si quelqu’un peut la partager ce serait cool…

Autre remarque, cette fois ci concernant Duniter et le parseur
chose marrante ou comment perdre sa monnaie ?
je l’avais pressentis et j’ai fais attention en amont, je devais en avoir le coeur net,
par le passé j’ai testé
SIG() && XHX()
pas folle la guêpe

et la je devais bien essayer XHX tout seul :wink: une fois de + , cette fois ci avec suffisament de monnaie
du coup, ma transaction apparait bien dans mon historique

/tx/history/m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ

{
“version”: 10,
“locktime”: 0,
“blockstamp”: “73011-00001DD6BEA90A2AA1599BE0E678B306135B2B341C4EC632CA6AD2CA553B4F5A”,
“blockstampTime”: 1508599026,
“issuers”: [
“m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ”
],
“inputs”: [
“1234:0:T:8378709DD78D4B2B332163711E6867F265708C38E057976A000E251BC438694F:0”
],
“outputs”: [
“34:0:SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ)”,
“1200:0:XHX(03AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4)”
],
“unlocks”: [
“0:SIG(0)”
],
“signatures”: [
“bn4qRqy6VsksNdI0xejPnoEq9cRmZK4ZamlDn0uz0qKBnnrqwlb4qCeLNaY+0r1/6wlG/1Up91qaRy5FvcAUCA==”
],
“comment”: “”,
“hash”: “71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C”,
“time”: 1508599327,
“block_number”: 73013,
“received”: 1508600738
}

OR bien evidemment elle ne peut apparaitre dans aucune source
tel que
tx/sources/m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ

je n’ai pas testé avc CLTV et CSV, j’ai bien peur qu’il en soit de meme…


Edit:
je souhaite bien avoir dit une betise au travers de ce dernier message,
si c’est avéré :
-> Duniter accepte une TX avec les possibilites de ces functions, XHX, (CTLV , CSV pas encore testé), seul,
a partir de quoi en aucun cas j’utiliserais une application client developpé par un tiers qui ne peut pas me demontrer qu’il ne “shunt” pas ma transaction en utilisant ces fonctions en douce…

Je viens de vérifier la source avec XHX seule et elle est bien indéxée dans s_index donc bien dépensable, pas de monnaie perdue ici :slight_smile:

En réalité la notion de portefeuille dans une monnaie Duniter ne correspond pas a un trousseau de clé mais a un ensemble de conditions de déblocage de source, ainsi le portefeuille HXH(03AC674216F3E15C761EE1A5E255F067953623C8B388B4459E13F978D7C846F4) existe tout autant que n’importequel autre portefeuille.

Par simplification on considère généralement uniquement les portefeuilles de type SIG(pubkey) ou pubkey est une clé publique mais il ne s’agit que d’un sous-ensemble très restreints parmi l’infinité des portefeuilles possibles !

La encore, le problème viens seulement de l’API BMA qui est incomplète, Duniter gère déjà parfaitement bien le cas général :slight_smile:

1 « J'aime »