Doc protocol example tx format

Max · 21 October 2017 13:53

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)

elois · 21 October 2017 15:51

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

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.

Max · 21 October 2017 16:13

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 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…

elois · 21 October 2017 18:36

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

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

Max · 21 October 2017 18:41

Certe elle est bien “dépensable”
cependant, personne ne peut la dépenser

ce n’est pas un portefeuillle,
la fonction necessaire pour débloquer cette ressource n’est pas relative a une clé publique ou privée
et par consequent personne ne peut acceder a ce montant dans sa liste de ressource dans une future transaction

ou alors il y a un tricks “vaudoo” dont je n’ai pas connaissance

SHA256: [03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4]
pour etre “unlock” necessite d’ecrire XHX(1234) dans une future transaction
03a… = sha256(1234)

elois · 21 October 2017 18:44

C’est faux, quiconque possède le code qui génère ce hash peut très bien la dépensée (la source XHX), ce n’est pas parce que BMA ne fournie pas une info qu’elle n’est pas utilisable, c’est ce qui se trouve dans l’index global du nœud qui fais foi, pas ce que renvoie l’API.

A propos voilà la bdd, regarde donc dans s_index : https://ifee.fr/pub/duniter-g1-test-73176.db

Max · 21 October 2017 18:45

Merci pour la bd

bon a savoir

bon a savoir que tu peux changer mon post → ta citation a la volée aussi

elois · 21 October 2017 18:49

Je rajoute des repères pour que les observateurs comprennent ce qu’on se raconte

Max · 21 October 2017 19:02

juste pour remarque, l’API BMA ne fais pas lien ici,
le sujet c’est bien comment dans une future transaction je fais reference au hash du block avec le unlock XHX(1234)

je n’ai peut etre pas a m’en soucier, juste mettre le XHX(1234) ?

elois · 21 October 2017 19:04

Tu ne fais pas référence au hash d’un bloc, c’est une source de type transaction, tu fait donc référence au hash de la transaction, dans ton cas le input est :

1200:0:T:71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C:0

@Max en revanche toute transaction doit avoir au moins un issuer, donc la personne qui souhaite dépenser cette source doit s’envoyer au moins 0.01 G1 a elle-même dans la même transaction

Max · 21 October 2017 19:30

du coup je viens de tester ca :

Issuers:
7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY
Inputs:
1200:0:T:71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C:0
Unlocks:
0:XHX(1234)
Outputs:
1200:0:SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ)

Duniter return => 2013 Wrong unlocker in transaction

et ca

Issuers:
7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY
Inputs:
1200:0:T:71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C:0
Unlocks:
0:XHX(1234)
Outputs:
1199:0:SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ)
1:0:SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY)

Duniter return => 2013 Wrong unlocker in transaction

surement que je dois changer
0:XHX(1234) en 1:XHX(1234)
ca ne change rien,
je ne vois pas comment unlock la source…

elois · 21 October 2017 19:48

tu a oublié d’input au moins une source de la clé issuer…

Max · 21 October 2017 20:09

Duniter return => 2013 Wrong unlocker in transaction
Issuers:
7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY
Inputs:
207494:0:T:90E6F6C973E0147838EA15F0090F5BBA7236FE1AF494BF12B16E9B9C64C892BE:0
1200:0:T:71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C:0
Unlocks:
0:SIG(0)
1:XHX(1234)
Outputs:
207494:0:SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY)
1200:0:SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY)

…

Duniter return => 2013 Wrong unlocker in transaction
Issuers:
7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY
Inputs:
207494:0:T:90E6F6C973E0147838EA15F0090F5BBA7236FE1AF494BF12B16E9B9C64C892BE:0
1200:0:T:71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C:0
Unlocks:
0:SIG(0)
1:XHX(1234)
Outputs:
208694:0:SIG(7t38cKwaBN9e6KymPnPS7SDc4bSJEMML1mTyKg4sDtiY)

…

elois · 21 October 2017 20:10

Ok là c’est curieux tu peut ouvrir une issue

elois · 21 October 2017 20:43

Pourtant il y a bien un test unitaire grammar-test.js qui teste unlock sur du XHX seul, je viens de faire le test unitaire en local il fonctionne, je pense que le souci est ailleurs il faudrait envoyer ton document sur un nœud en mode debug pour vérifier ce qu’il se passe. Tu utilise quoi comme outils pour cURL le document en POST ?

Max · 21 October 2017 20:54

le tout dernier document
https://pastebin.com/5N7HcD5H

elois · 21 October 2017 22:55

@Max J’ai trouver l’erreur dans ton dernier document, tu a copié mon input sans réfléchir, le T_INDEX n’est pas bon, je t’ai donné zéro mais j’ai vérifié dans la transaction d’origine le output XHX est en 2ème position donc le T_INDEX est 1 :

1200:0:T:71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C:1

Je m’en suis rendu compte en envoyant ton document a mon nœud de dev en mode debug, il attendait comme condition d’unlock de cet input un SIG(m8zQ5XSE8NjF7wcrys2UjsssnmYzbHsTSnn2nfD2vqQ), ce qui correspond en fait à l’autre source de la transaction d’origine tu saisie ?

Bref, a mon humble avis sur ce coup là il n’y a aucun bug du coté de duniter ouf

EDIT: je pourrais consommer la source XHX du coup mais je te laisse la satisfaction de la consommée toi-même

Max · 21 October 2017 23:46

Soit…

ok, ca j’entends et je comprends…

par contre,
ca —> impossible de le deviner
au regard de la documentation ici: duniter/doc/Protocol.md at master · duniter/duniter · GitHub

et par consequent ca ne fait pas sens pour moi sans un exemple concret bien que je “pense” comprendre ce que tu me dis,
ce serait appreciable si tu peux toi meme valider la transaction et me la montrer.

elois · 22 October 2017 01:54

@max en fait même pas besoin de s’envoyer de la monnaie a soi-même, c’est juste que le protocole Duniter impose au moins 1 issuer qui signe le document, voici donc le document transaction que j’ai soumis au réseau pour consommer la source XHX seule :

Version: 10
Type: Transaction
Currency: g1-test
Blockstamp: 73116-00002F7E8C5593F23D1C4D1850CF90DDD3C0500DFA75105613C10ADDC66D6251
Locktime: 0
Issuers:
8UVU9hFi1E46YBPSRxkEHgYZGkhuDh8AATaZNuaJUQaC
Inputs:
1200:0:T:71745D93C2023299F18914050E5DE6AC1277409B52ECDDA8ECA8E6980571DA6C:1
Unlocks:
0:XHX(1234)
Outputs:
1200:0:SIG(8UVU9hFi1E46YBPSRxkEHgYZGkhuDh8AATaZNuaJUQaC)
Comment: 
iumnSW/eHEqXlU8fTcwpwW7CZOZ/SAikbfjrj0c0aNQlOWTPqj/omBIAToV68JqO4In+vSNnfg8tji8kP/HiBg==

Document accepté par mon nœud duniter et écrit au bloc #73228 : https://g1-test.duniter.org/blockchain/block/73228

D’ailleurs c’est marrant Cesium ne sait pas gérer une transaction avec seulement des sources XHX il prend ça pour une “transaction de change” et ne l’affiche pas dans “Mes opérations”, en revanche la clé 8UVU… a bien un solde de 12 GT maintenant

EDIT : J’ai donc fermé ton issue puisque tout fonctionne nickel du coté de Duniter

EDIT2 : a noter que j’ai arbitrairement choisi de verser les sous a la clé Issuer mais ça aurait pu être verser a n’importe qu’elle autre clé et plus généralement a n’importe-quel “ensemble de conditions de déblocage” que ça aurait fonctionné tout autant.

elois · 22 October 2017 02:03

Tu n’a pas saisi, a ce moment là je ne parlais plus de la fonction XHX, je parlais de l’autre source issue de la même transaction d’origine, comme le T_INDEX était mauvais c’est cette autre source que Duniter allait chercher, il attendais donc une condition de déblocage correspondante a cette autre source, ce qui n’était pas le cas, d’où l’erreur “Wrong unlocker in transaction”