In production mode, the `GetTreeState` gRPC supports block specification
by either height or block hash. But until now, darkside emulation only
supports height. This commit adds support for block hash.
It also allows entries to be deleted (darkside `RemoveTreeState`) by
block hash (not just height).
We also remove the `i < maxEntries` bound on returned results, as the
`limit` parameter already causes `zcashd` to bound its returned entries.
Closeszcash/lightwalletd#444.
See issue 397. If the block cache is still populating (lightwalletd is
syncing with zcashd), behave the same as if the cache was fully
populated, other than performance.
This turned out to affect only the GetLatestBlock() gRPC. Previously, it
would return the height and hash of the latest block in the cache. After
this commit, it queries zcashd using the getblockchaininfo, which
contains both of those values.
GetBlock() (and GetBlockRange()) already worked correctly; if the
requested block isn't in the cache, it requests it from zcashd.
This commit adds support for adding/removing/clearing TreeState
structs for lightwalletd to return as if they were TreeState
messages requested to Zcashd for a given height.
Closes#390
Fixes issue 408.
This bug was introduced by PR 393, which changed how txids are
determined. That PR changed each call to the zcash getblock call into a
pair of calls, the first to get the raw block data, the second to
retrieve the txids in the block. (Unfortunately, you can't get both in a
single getblock RPC.) But this ordering introduced a timing window in
which the block at the given height can change, if a reorg occurred
between the two calls.
This PR reorders the getblock calls, so that the first call gets the
transaction IDs, which also happens to return the block hash, so then
the second getblock call can specify the block hash, rather than the
height. This ensures that the two RPC calls return consistent data,
definitely the same block.
Now "go test ./..." passes, it had broken due to the V5 transaction
(NU5) changes in #392. I didn't have time to fix the tests at the time.
Also, this fixes a few lint problems.
This causes lightwalletd to discard cached blocks at the given height
and beyond. This in turn causes it to re-fetch those blocks from zcashd.
It's similar to --redownload, except that option discards all blocks
(equivalent to --sync-from-height 0, but the existing --redownload is
retained for compatibility).
This is mostly intended for testing. It's sometimes useful to force the
node to (re)sync some recent blocks, but redownloading all of them takes
around an hour.
This commit is based on adityapk00 streaming mempool interface but
avoids using goroutines, which are difficult to reason about.
Co-authored-by: Aditya Kulkarni <adityapk@gmail.com>
Add a new darksidewallet gRPC to add a utxo that can be returned by the
production GetAddressUtxos, for example:
grpcurl -plaintext -d '{"address":"t1g1HQJuwDoStGrYYLj8VhLu1J5igd8TNXV","txid":"1zjB42Z7FtwRZOBNMlTubCgx9l3dsZSqXxmWpuZXJto=","script": "dqkU8saQsCVS4mNwcByoGCtfOaHFaCiIrA==","valueZat": "3010000","height": "686773"}' localhost:9067 cash.z.wallet.sdk.rpc.DarksideStreamer/AddAddressUtxo
Then the following returns this entry:
grpcurl -plaintext -d '{"startHeight":0,"maxEntries":2,"addresses":["t1g1HQJuwDoStGrYYLj8VhLu1J5igd8TNXV"]}' localhost:9067 cash.z.wallet.sdk.rpc.CompactTxStreamer/GetAddressUtxos
You can also clear the list of entries:
grpcurl -plaintext localhost:9067 cash.z.wallet.sdk.rpc.DarksideStreamer/ClearAddressUtxo
I installed the latest toolchain according to:
https://grpc.io/docs/languages/go/quickstart/
I updated the protoc command line arguments in Makefile based on
that quickstart guide, then I ran: make update-grpc
This has set the tool version (which you can see at the top of
any .pb.go file) to:
protoc-gen-go v1.25.0
protoc v3.14.0
- renamed GetAddressBalance to GetAddressBalanceStream
- changed GetAddressBalance argument to repeated (string) rather than
streaming
- rename balance field to valueZat (consistent with zcashd)