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