Robust transaction history implementation

[mmrrnn]

What's wrong with the current implementation?

1. minotari_console_wallet's grpc service only exposes the get_completed_transactions request, which streams all transactions in an unordered manner. This poses a challenge, especially for users with a large number of transactions (for instance, Mike currently has around 1500). We need to fetch them all and sort on our side. When we want to refresh the tx history, we have to to refetch all transactions and sort them again.
   2. As the name implies, get_completed_transactions returns only confirmed transactions. When a user mines a block, they almost immediately see a winning animation and a balance update; however, the transaction history is only updated after three confirmations. To face this issue, we can only use stream_transaction_events to handle unconfirmed transactions on our own. This adds a lot of complexity. We would need to store unconfirmed transactions separately, wait for confirmations and refetch them as confirmed ones. It's possible, but seems unreasonable to do, since it's exact copy of what minotari_console_wallet does.(Edit: turned out we receive status 12, not sure why we had an issue with this then)

What we want to achieve?

• We want, as early as possible, to fetch unconfirmed transactions and combine them with confirmed transactions
• From the frontend perspective, we want to fetch only specific amount of the latest transactions at a time(infinite scrolling)

What we can do?

We can use stream_transaction_events to refetch tx history

[mmrrnn]

#1346
#883

[SWvheerden]

Confirmations are there to protect the wallet from funds getting reorged out primarily. Thats why they are handled differently than confirmed completed ones.
But to make a long complicated story short, this was very naivly added as this is something you do in pow crypto to ensure statistic finality. But in Tari we are much more resilient to reorgs than other chains due to the way our chain works, and we can very easily add reorged transactions back.

So the block confirmation is a user-set config option, that can be set to 0 for the universe wallet. That means you get all the confirmed as confirmed right from get go.

BUT this will lead to some lost funds as coinbase transactions are the only transactions that cannot be reoerged. They are locked to a block. This is a problem for us as we have many 1 block reorgs.

Sp TLDR, think carefully about just displaying rewards as gotten as soon as a block is mined. That block might be reorged out and the user will "loose" funds. That might lead to some false reports of wallets losing funds.

[SWvheerden]

FYI:
get_completed_transactions should return all compelted transactions,
that means all transactions that are:

• mined and unconfirmed
• mined and confirmed
• not yet mined an sitting in a mempool
• reoerged out

[mmrrnn]

I completely agree. At present, we utilize pending_incoming_balance as an indicator for block wins. I know this may not be the most effective method, but it allows us to quickly display the winning animation and update the block height in the UI. However, some users have expressed concerns about the lack of a corresponding transaction for the latest win. I wante to find a way to enhance this process without having to imitate the event handlers from minotari_console_wallet.

[SWvheerden]

But note in the code, I checked, get_completed_transactions should return everything I listed above.
So if in universe, we don't see every thing, somewhere is a bug we need to fix for that.

[mmrrnn]

I'll try to win some blocks and let you know about mined and unconfirmed

[mmrrnn]

Looks like you're right 👍

[TransactionInfo { tx_id: 2211753715037590900, source_address: "2601a2a7eff771754f755484cbffd00fbfd1fe204a9c7db2508cfc38fda4844614647ed9e7b6b0c5f5a815589288c061e9661eeec3adf85d24afa5eba618f4d19127c6", dest_address: "2601a2a7eff771754f755484cbffd00fbfd1fe204a9c7db2508cfc38fda48446146482ff96fdfd0d4e8665dc4f418cdda290c89e6e168f52180585f1084ebb72843753", status: 12, direction: 1, amount: MicroMinotari(13670504610), fee: 0, is_cancelled: false, excess_sig: "0000000000000000000000000000000000000000000000000000000000000000", timestamp: 1736502211, payment_id: "", mined_in_block_height: 23261 }]

[SWvheerden]

Just a note on the view only wallet used in universe, this wallet most interacts with the block chain and never with another wallet. So you only time you will see not yet mined transactions are when they are reorge out. But if the mined in block and mined timestamp are null, or 0, the tx is completed but not yet mined, aka not in the block chain