Darkside TXIDs are incorrect

[AloeareV]

What is the bug?
Darkside txids are incorrect

Additional context
In a production server, the txid issue is bypassed according to this comment:

lightwalletd/common/common.go

Lines 262 to 267 in 8003d7f

	func getBlockFromRPC(height int) (*walletrpc.CompactBlock, error) {
	// `block.ParseFromSlice` correctly parses blocks containing v5
	// transactions, but incorrectly computes the IDs of the v5 transactions.
	// We temporarily paper over this bug by fetching the correct txids via a
	// verbose getblock RPC call, which returns the txids.
	//

This doesn't help on darkside, though

lightwalletd/common/darkside.go

Lines 99 to 103 in 8003d7f

	func darksideSetTxID(tx *parser.Transaction) {
	// SHA256d
	// This is correct for V4 transactions, but not for V5, but in this test
	// environment, it's harmless (the incorrect txid calculation can't be
	// detected). This will be fixed when lightwalletd calculates txids correctly .

Zingo, and I believe some other lightwallets (although I haven't investigated this), when it sends a transaction, it calculates the transaction ID of the transaction it's submitting, and is then confused when the on-chain txid doesn't match what it deterministically should be.

[zancas]

Hi @LarryRuane are you aware of this issue where there's a discrepancy between the TxID that's produced for Version 5 transactions, and the one that's specified in the protocol?

[LarryRuane]

Hi @zancas, yes, I'm aware of this problem, see #392. As I said in the comment quoted above, I didn't think it matters in darkside mode (and we have a workaround for regular (production) mode). But if it does matter (that is, if it's a problem for some wallet testing), we should bump up the priority of getting this fixed.

Can someone give me a sense for the urgency to fix this?

I did look into fixing it recently, but the official blake2b Golang package support "personalization" which is required. See #392 (comment)