Post-NU5 testnet issues

[conradoplg]

I'm making tests of the Zebra + lightwalletd integration using ZecWallet Lite. However the results below were reproduced with zcashd too.

I'm using the upstream lightwalletd due to this issue, so be aware that some (or all?) of these issues might be caused by that.

Describe the bug

Testnet + upstream lightwalletd results:

• Shielded Sapling transactions show up in the wallet, but never become spendable
  • Investigating zecwallet-light-cli code, this seems to be caused by the anchor_height always having the wallet birthday and never increasing. Not sure why.
• When you click a transaction, it shows the wrong TXID (the old SHA256d one, instead of the NU5 TXID)
  • I can also see getrawtransactions queries to Zebra using the wrong TXID (and of course, failing). But somehow the shielded transactions and balance show up correctly
• Transparent transactions / balance do not show up at all (even though my address has a balance)
  • getaddressbalance does not seem to be called, so it seems it computes the balance manually (I do see a getaddresstxids followed by a getrawtransaction which work successfully)
  • This seems more related to the usage of upstream lightwalletd

To Reproduce

Start lightwalletd from this version

Run ZecWallet Lite with a hardcoded lightwalletd server (I used this. I also had to change this line to use "test")

Open ZecWallet Lite

Send a shielded transaction and a transparent transaction to your wallet.

Expected behavior

• It should allow you to send from your shielded balance
• It should show your transparent balance

Desktop (please complete the following information):

Ubuntu 20.04, ZecWallet Lite 1.7.8

[str4d]

• When you click a transaction, it shows the wrong TXID (the old SHA256d one, instead of the NU5 TXID)

This is zcash/lightwalletd#392, which is being addressed in zcash/lightwalletd#393.

[conradoplg]

• When you click a transaction, it shows the wrong TXID (the old SHA256d one, instead of the NU5 TXID)

This is zcash/lightwalletd#392, which is being addressed in zcash/lightwalletd#393.

Thanks @str4d! I tested it with the fix and the problem still seems to happen. I think ZecWallet might be computing the TXID by itself somewhere, but I couldn't find it so far (I'm not too familiar with the codebase yet)

[str4d]

Did you clear both the lightwalletd cache, and the zecwallet-lite state, before testing? The former needs to happen or else the incorrect txids continue to be served (or see the latest merged PR where you can now truncate the cache to a specific height), and the latter needs to happen if zecwallet-lite caches the txids locally (which I would expect it does).

[conradoplg]

Did you clear both the lightwalletd cache, and the zecwallet-lite state, before testing? The former needs to happen or else the incorrect txids continue to be served (or see the latest merged PR where you can now truncate the cache to a specific height), and the latter needs to happen if zecwallet-lite caches the txids locally (which I would expect it does).

@str4d thanks, that was it! I forgot about the lightwalletd cache. After clearing them, ZecWallet Lite is showing the correct TXID.

(It is still not allowing me to spend the shielded balance, but I guess it's a separate issue.)

[zancas]

We're working on this issue in our fork, tracking here: https://github.com/zingolabs/zecwalletlitelib/issues/36

[daira]

This issue seems to cover several different problems. Can the remaining ones not fixed by the lightwalletd v0.4.12 release be split into separate issues?

[AloeareV]

We've got a fix in progress here: https://github.com/zingolabs/zecwalletlitelib/pull/48

It's WIP, as the tests aren't updated yet. We're successfully parsing transactions past NU5 height on testnet, though.

[zancas]

@AloeareV 's fix now has some (but not all) tests running here:

https://github.com/zingolabs/zecwalletlitelib/pull/53

We can make a provisional alpha release with a button click, if we land that PR in dev. I'm not sure that there'd be value to that but there may be tooling around releases that could use it. I don't think it has a significant downside, to cut a provisional release.. except... the above hypothetical tooling might pick up our (also hypothetical) new bugs...