Doc protocol example tx format

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 Like

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)

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

Merci pour la bd :slight_smile:

bon a savoir :slight_smile:

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

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

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) ?

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 :wink:

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…

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

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)

1 Like

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

1 Like

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 ?

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

1 Like

@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 :slight_smile:

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

1 Like