Comment faut-il afficher les transactions complexes?

Clients
,
1

Oui c’est ce que je fais, je demandais pour savoir comment sont gérées les ambiguïtés.

On peut déterminer si on l’affiche en reçue ou émise, mais dans certains cas le résultat ne sera pas satisfaisant :

Dans une tx avec 2 entrées :

  • 1000 Ğ1 venant du compte A
  • 10 Ğ1 venant du compte B

et 2 sorties :

  • 505 Ğ1 pour le compte B
  • 505 Ğ1 pour le compte C

le compte B a gagné des Ğ1 mais a envoyé des Ğ1 à C en même temps… les deux catégories envoi et réception ne suffisent pas, il faut prévoir un affichage pour ces cas plus complexes.

2 Likes
2

Tu peux commencer simple et te limiter aux transactions mono-issuer pour le moment, comme le font quasiment tous les clients existants :slight_smile:

Pour afficher convenablement une transaction dans le cas général, je ne sais pas quelle est la bonne manière de faire, c’est une réflexion collective à avoir !

Peut-être que @vit a des idées là-dessus vu qu’il y a réfléchi pour sakia (et maintenant tikka) ?

3 Likes
3

A few weeks ago I was playing with multi-issuer transactions and have these thoughts:

For the following G1 accounts: cesium+pseudo / public key

learn-g1 / 3A9A6RNzZ7fNBsTmRwhJWCnKmWW13DkQ41M2MULZPpjC
Alice / EVfy1VoZwbuN7L69kYiHxeosJLh5azkHV8G6TaSLy94r
Bob / 8txjWNFZhMJbKPijvnFybeksN1QpKaKJrM4jW8HhnFsX
Mallory / w1pLhQVXp7kQuf4TFppE4wG6j8oV1bs7k4MooxxyGCZ

where 3 transactions were interactively merged having:

learn-g1 sending to Alice, Bob, and Mallory with change,
Bob sending to Mallory with change,
and Alice sending to Mallory with change,

…the resulting merged tx was learn-g1, Alice and Bob as issuers, sending funds to Mallory with each of the issuers getting change.

cesium handles history reporting strange in some regards, ok in others… depending on the perspective of each account.

For each of the issuers (learn-g1, Alice and Bob), the history amount looks like my_output - sum(all inputs) and only shows Mallory as the counterparty… so for 3 issuers, the amount is wrong… it reflects the inputs of the other issuers instead of the net-amount for their pubkey.

For the one receiver that wasn’t an issuer (Mallory), it shows correctly that there were 3 separate issuers as counterparty with an amount of her_output.

My thoughts that a better way might be, in regards to each account history, to use sum(my outputs) - sum(my inputs) as the amount, and as for the counterparty (issuers except me) when amount is positive and (output receivers except me) when amount is negative.

I haven’t played enough to be sure… but those are my thoughts for now.

Spencer971

added: Me documenting what I was trying to achieve in this play session is here: https://git.duniter.org/spencer/learn-g1/-/blob/master/docs/merge_unsigned_txs.rst

1 Like
4

More thoughts on being able to do an itemized list:

Its not of great value (or even possible) to itemize the list of counterparty amount, and costs screen space.

If only 1 issuer and many outs, sender’s history might detail amounts per output that is not theirs; but also mostly useful to know the net total and perhaps an inline list of links to view each receiver.

if multiple issuers and multiple outputs, then the info/intent can be lost as far as who sent how-much to who… so perhaps no sense in bothering to itemize.

In my play example, originally learn-g1, Alice and Bob went 40/30/30% to fund Mallory, and learn-g1 was kicking-back 2/3rds each to Alice and Bob for their contributions.

In the final merged tx, we don’t know. It’s also plausible that learn-g1 and Alice went 50/50% to fund Mallory while learn-g1 also paid 15g1 to Bob, and Bob was just making a 20g1 payment to Alice. Many other explanations of who paid how-much to who would also be plausible.

Spencer971

5

Yes, Cesium does not correctly handle complex TX.

2 Likes
6

Oui, c’est une question que je me pose toujours. C’est pourquoi je n’avais pas gérer ces cas pour le moment.

Par ailleurs, il y a le cas des TX lockés par une condition qui n’est pas encore remplie (un password à délivrer, etc). Dans ce cas, le montant ne peut pas vraiment être crédité à un compte, ni débité d’une autre. Si rajoute plusieurs condition de unlock, alors cela devient encore plus difficile de savoir où afficher la TX.

Peut-être faut il un autre concept, genre « Transactions particulières » dans lequel nous pourrions afficher tous les cas qui ne sont pas A -> B ou A -> B, C, D, E
Un tel historique pourrait avoir une colonne « état » (locked, 2/3 signatures, waiting pwd, etc.) et une autre « action » (unlock, set pwd, etc.)

2 Likes
7

J’ai commencé à faire cela dans Sakia pour les tx avec delai de retour.
J’affichais la condition brute quand un blocage avait lieu pour que l’utilisateur comprenne pourquoi il y avait un blocage.

Aussi ma proposition est, pour ces cas là, effectivement comme tu le proposes de les afficher à part, mais la plus value serait d’afficher la condition en langage humain. Une sorte de PEG qui analyserait la condition et la traduirait dans une grammaire compréhensible par le plus grand nombre.

Du style :

sig(pubkey1) | (sig(pubkey2) & ctv(DELAY))

deviendrait :

dépensable par pubkey1 ou (pubkey2  à partir de DATE)
5 Likes