Invalid balance and tx list on Chrome

[bordalix]

• Using Marina commit 108eeed
• Added Marina extension to Chrome and Firefox (via load unpacked)
• Created two different wallets on each browser (different mnemonics)
• Got 2 L-BTC on Chrome through faucet and sent 1 L-BTC from Chrome to Firefox.
• On the Chrome side, balance is showing 0 (should be 1) and the transaction list shows a value of -2 L-BTC (should be -1).
• On the Firefox side everything is showing properly (balance = 1 and transaction list shows an inbound of 1 L-BTC)
• Esplora shows one of the outputs as non confidential

Left is Chrome, right is Firefox

Steps taken to replicate bug:

1. Create new wallet on Chrome
2. Create new wallet on Firefox
3. nigiri stop --delete
4. nigiri start --liquid
5. generate receiving address on Chrome
6. nigiri faucet --liquid <address from 5>
7. generate receiving address on Chrome
8. nigiri faucet --liquid <address from 7>
9. generate receiving address from Firefox
10. send 1 L-BTC from Chrome to Firefox (to address from 9)
11. ERROR: on Chrome, balance is now 0 (should be 1)
12. ERROR: on Chrome, Tx list shows -2 L-BTC outbound (should be -1)
13. On firefox things appear ok (balance and tx list)
14. Esplora shows one output as non confidential

[tiero]

cc/ @louisinger

[tiero]

It's very weird that the second output in the transactions is "unblinded" ie. not confidential.

By default Marina blinds all outputs of the receivers and his own for the change (which heuristically is vout#1 most of the time)

[louisinger]

@tiero @bordalix I'm not able to reproduce the "blinding error" (all my outputs are blinded), however I get some weird balances result. Note that, using the settings/deepRestorer on both wallets I'm able to "recover" the right balance value. I really think there are some regression on the updater which causes some weird behavior during the first send.

@bordalix are u able to "recover" the balances using deepRestorer ? And what happens if u try to send another tx after the buggish one?

PS: The same scenario works well on restricted asset PR where I refactored the updater using redux-saga.

[bordalix]

@louisinger after deepRestorer I was able to recover the balance on Chrome.
But the Tx list stills shows the -2 L-BTC Tx (when it was -1 L-BTC).
After a new Tx from Chrome to Firefox of 0.5 L-BTC:

Chrome on the left, Firefox on the right

[louisinger]

But the Tx list stills shows the -2 L-BTC Tx (when it was -1 L-BTC).

This is totally normal. The tx data is computed only one time (when fetched) - so unfortunately deepRestorer does not re-compute the "inbound/outbound" values of txs (we may change this but not the problem here I think)

After a new Tx from Chrome to Firefox of 0.5 L-BTC:

So it confirms that the bug only happens during the first send. I think the latest changes on master should fix at least your blinding error. see there: https://github.com/vulpemventures/marina/blob/master/src/application/redux/reducers/wallet-reducer.ts#L54. (-1 becomes 0). I think we should investigate there 🤔

[tiero]

Can we cherrypick the updater with redux-saga from restricted PR? @louisinger

Currently I tagged new version 0.3.4 with Testnet, let's figure out a way to fix this for a new patch release

[tiero]

If doable to cherrypick (cc @louisinger) I would assign to you @bordalix to try to propose a fix

[tiero]

As agreed offline with @louisinger, we think he would be more effective in fixing this trying to cherry-picking the updater refactor

[bordalix]

@louisinger just to let you know, if I change the network to Liquid and then back to Regtest, I get the correct balance. Without the need to do deep restore.

[louisinger]

@louisinger just to let you know, if I change the network to Liquid and then back to Regtest, I get the correct balance. Without the need to do deep restore.

Yeah, each time you switch the network type: a deep restorer is launched in order to discover new addresses.