Ok en fait on ne se comprend pas car nous ne donnons pas le même sens aux mots.
En fais ce que tu veux c’est la variation du solde du compte dont on regarde l’historique. Un tel champ pourrait se nommer accountBalanceVar et est bien définissable pour tout doc tx donc il ne vaudra jamais null
Parler de amount me semble incorrect, car ce terme sous-entend que l’on désigne une propriété intrinsèque de la transaction, alors que l’on désigne en réalité le bilan d’un compte impliqué dans cette transaction.
Ce champ accountBalanceVar serait positif pour les transactions reçus et négatif pour les transactions émises.
On pourrait d’ailleurs se baser sur ce champ pour définir la direction.
Non, car l’historique fourni par GVA est indexé par compte, pas par clé publique.
Si tu requête l’historique de compte SIG(A) || SIG(B) tu auras bien une valeur pour accountBalanceVar pour chaque tx dans l’historique.
Tu pourras connaître tous les comptes liés à une clé publique P via une query accountsWithPubkey qui te retournera un tableau des scripts des comptes ayant un solde strictement positif et ayant la clé publique P dans leur script.
Ca pourrait être aussi accountDelta. Mais on ne comprend pas qu’il s’agit d’une quantité de monnaie.
Ou alors txBalance. L’abbrévation Var peut avoir plusieurs sens. Et inutile de préciser account, puisqu’on le donne en argument obligatoire de la fonction.
Oui voila. Comme dans l’historique des TX de Cesium
Oui, ca parait logique. A voir ou l’on mettra les TX “opération de change”, du coup.
Par exemple, si filtrage par direction : alors on ne les retourne pas. Si aucune direction n’est précisée, alors on les retourne, avec une txBalance = 0.
ok, ca me va.
Dans ce cas pourquoi ne pas renommer “pubkeyOrScript” en “account” ?
ca paraitrait logique que :
accountsWithPubkey => renvoi t des “account”
TxHistory(account) => renvoi les TX concernant ce compte (un script ou nue pubkey).
Au contraire, préciser «account » dans le nom du champ permet de prendre conscience que c’est un champ dont la valeur est relative au compte qu’on observe, que ce n’est pas une propriété intrinsèque de la transaction. Voici pourquoi le nom txBalance ne me conviens pas non plus.
Le sens de Var sera précisé dans la doc. Il vaut mieux indiquer ce suffixe Var afin que l’utilisateur de l’API se pose la question et donc lise la doc du champ plutôt que de ne pas indiquer ce suffixe et laisser l’utilisateur de l’API mal interpréter ce champ.
Après si dans le code de cesiumV2 tu veux manipuler un nom différent tu peux utiliser la syntaxe de renommage des champs graphql, exemple :
On peut également considérer qu’une transaction de change est une transaction envoyée.
Où alors l’enum Direction peut avoir des variantes supplémentaires :
enum Direction {
SENT
RECEIVED
ALL
CHANGE
SENT_AND_CHANGE
}
Avec ALL comme variante par défaut.
C’est bien le nom account que j’avais choisi au début. Il fallait alors entrer "SIG(A)" pour avoir l’historique du compte SIG(A).
Dans un 2ème temps, pour simplifier l’usage, j’ai décidé de convertir automatiquement une pubkey A en SIG(A), c’est là que j’ai changé le nom pour bien signifier qu’une clé publique seule est acceptée. Mais ça peut-être signifié dans la doc, donc oui or peut revenir à account comme nom d’input.
Sinon, la comptabilité utilise les concepts de crédit/débit, dont la différence est le solde (balance).
Si l’argument “account” est obligatoire, franchement “balance” suffit largement. C’est un historique de TX, donc autant utiliser les concepts existants, et ne pas reinventer la roue.
Cool. L’énumération SENT_AND_CHANGE ne me semble pas nécessaire. Il suffira de faire deux requêtes (ce qui est facile en graphql)
Super. Du coup oui il suffit de détecter si l’argument est une clé publique ou un script.
Pour moi oui. Account (compte) est un terme assez vague, qui indique simplement qu’on compte des unités. Script (de déblocage) désigne précisément les conditions à remplir pour utiliser une ou des UTXO.
Je comprends bien que, coté Duniter, un account est un ensemble de conditions à remplir pour débloquer la monnaie, et que cette notion se confond avec celle de Script de déblocage. Mais coté client, un compte peut désigner autre chose. Deux exemples pour ce « coté client » :
le script SIG(<pubkey1>) && XHX(<hash>) désigne de la monnaie disponible pour le compte SIG(<pubkey1>), avec une condition. La monnaie bloquée par ce script est uniquement à destination du compte SIG(<pubkey1>).
Un client qui dériverait une clef maître pour envoyer le change des tx sur de nouvelles clefs publiques gèrerait un seul compte, mais de très nombreux scripts de déblocages différents. Qui plus est, la clef publique maître de ce compte pourrait ne jamais être publiée en blockchain, et donc ce « compte » coté client n’existerait pas pour Duniter. (c’est le fonctionnement du client Electrum pour Bitcoin, et certainement d’autres)
Rien à voir, avec GVA comment peut on savoir l’heure à laquelle a été émise une transaction en Mempool ?
Je pense par exemple au cas où une transaction reste en Mempool pendant plusieurs jours, ce qui peut arriver, avons nous le moyens de dater cette entrée ?
Pour moi la réponse est « c’est impossible » car aucune date n’est associé à cette entrée en blockchain, mais je peux me tromper. Pour le moment j’affiche now pour les transactions en mempool.
En théorie c’est l’heure du bloc référencé dans le champ blockstamp de la TX, mais il est possible de référencer un bloc dans le passé. Et dans DUBPv13 il deviendra possible de dater une TX dans le futur, donc en effet il deviendra impossible de savoir la date d’émission d’une tx.
En revanche, étant donné que Duniter sera obligé de stocker de la date de réception d’une tx avec DUBPv13 (nécessaire pour l’élagage des piscines), il sera possible pour un contributeur de GVA d’exposer ce champ.
L’inconvénient de cette date de réception c’est qu’elle ne représente pas nécessairement la date d’envoi sur le réseau, ça peut être plusieurs heures après lors d’une synchro des mempool.
J’ai fait une MR pour obtenir un bloc à partir de son numéro.
D’ailleurs les requêtes currentBlock et node.peer.blockstamp disent qu’il n’y a pas de blockchain, chez moi, même si la requête block marche. Ça le fait parfois aussi sur ton nœud.
Après ça le plus important est d’ajouter les certifications aux identités, je pense, mais là il faut toucher à la db…
Edit:
Est-ce que ça pourrait avoir un rapport avec le bug (ou un des bugs) de blocage des nœuds ? Mon nœud s’est bloqué (un bloc considéré invalide) et j’ai vu ça dans le log, ça parle d’empty blockchain :
2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Block resolution: 0 potential blocks after current#401670...
2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: 9 potential block(s) found...
2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: 1 potential suite(s) found...
2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: HEAD = block#401670
2021-02-24T13:46:26+01:00 - ^[[32minfo^[[39m: Fork resolution: suite 1/1 (-> #401684-000000) revert to fork point block#401669
2021-02-24T13:46:27+01:00 - ^[[32minfo^[[39m: Fork resolution: suite 1/1 REFUSED block#401670: Try to apply non genesis block on empty blockchain
2021-02-24T13:46:27+01:00 - ^[[31merror^[[39m: Unhandled rejection: Error: ruleNumber
2021-02-24T13:46:27+01:00 - ^[[31merror^[[39m: Error: ruleNumber
at Function.checkBlock (/home/tuxmain/Documents/projets/duniter/app/lib/blockchain/DuniterBlockchain.js:62:19)
at process._tickCallback (internal/process/next_tick.js:68:7)
Plusieurs changements importants sur la taille d’une page (paramètre pageSize) de toutes les requêtes paginées :
pageSize vaut désormais 10 par défaut.
La valeur maximale de pageSize est fixée à 1000.
Si pageSize vaut zéro, cela est interprété comme l’infini (une seule page qui contient tout).
Seuls les clients whitelistés ont le droit d’utiliser la valeur zéro pour pageSize, c’est une idée que@tuxmain m’a donné il y a quelques semaines et que j’ai implémenté ce soir
@tuxmain du coup tu vas devoir adapter ta MR en cours sur la requête blocks
ps: notez également que les clients whitelistés ne sont pas soumis à la limite 1000. La valeur maximale de pageSize est pour eux la valeur maximale d’un entier non-signé de 32 bit
C’est fait ! J’espère que c’est prêt à merger maintenant ? Ce pauvre commit aura été amendé plein de fois…
Au passage tu as laissé /// Transactions history devant la requête utxos_of_script…
Une requête importante pour la suite serait les certifications. Est-ce que c’est faisable actuellement ? (avec CIndexDbV1 ?) Est-ce qu’il faudrait l’intégrer dans idty ou la mettre à part ?
Je viens de reviewer, il marquait juste un map_or_else, j’ai amend puis mergé
Bien vu je corrige
Non tout ce qui touche à la wot n’est pas encore faisable. DbV1 n’est pas accessible par Duniter car verrouillé par nodejs, seul dex peut y accéder (si duniter est arrêté).
