Reorg race condition that can cause rare crashes

[defuse]

There's a race condition that can cause a lightwalletd crash when a reorg occurs at just the right time.

getBlockFromRPC first calls getblock to get the block into the block variable:

lightwalletd/common/common.go

Lines 267 to 268 in 2d3943b

	block := parser.NewBlock()
	rest, err := block.ParseFromSlice(blockData)

Then, it makes another call to getblock and puts the block data into the block1 variable:

lightwalletd/common/common.go

Lines 285 to 291 in 2d3943b

	params[1] = json.RawMessage("1") // JSON with list of txids
	result, rpcErr := RawRequest("getblock", params)
	if rpcErr != nil {
	return nil, errors.Wrap(rpcErr, "error requesting verbose block")
	}
	var block1 ZcashRpcReplyGetblock1
	err = json.Unmarshal(result, &block1)

It then loops over block's transactions, but indexes into block1. If block and block1 are identical blocks, this should be fine. But if block has more transactions than block1, which could occur if there's a reorg at just the right time, it will index out of bounds into block1 and crash.

lightwalletd/common/common.go

Lines 295 to 296 in 2d3943b

	for i, t := range block.Transactions() {
	txid, err := hex.DecodeString(block1.Tx[i])

The data here is coming from zcashd, so this crash can not be triggered intentionally to DoS the server.

[defuse]

Suggested fix: Make the verbose call to getblock first (to get block1), then fetch the block using getblock <hash> (to get block). Using the hash prevents fetching a different block. The reorg-handling logic elsewhere in lightwalletd will deal with the reorg.

[LarryRuane]

Closed by #409