To update to the latest dependencies, I removed everything within the
`require` sections of `go.mod`, updated to the latest protobuf compiler,
and then ran `go mod tidy` and `make`. This repopulated go.mod and go.sum.
I had previously done this in PR 395 (June 2022).
This should be done periodically to obtain the latest bug fixes and
other improvements in the dependencies. There should be no functional
changes.
No functional changes.
As pointed out in lightwalletd/pull/469, the errors package we're using
has been deprecated, so this commit updates the code to use "errors"
instead of "github.com/pkg/errors". Same with "io/ioutil", which has
been superceded by "os".
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.
And also to GetBlockRange. This requires an updated version of zcashd
`getblock` RPC that returns these values. These values are written to
the compact block cache (/var/lib/lightwalletd/db/main/blocks), but of
course older cached compact blocks won't have these values. To get these
values into all cached blocks, shut down lightwalletd, remove that file,
and restart (with, of course, an updated version of zcashd running).
In PR 412 (darksidewallet fixes for tx v5), I added a failure condition
to the GetBlock gRPC based on a block being requested always being in
the cache. I believe my thinking was that since there is no asynchronous
independent zcashd, if it wasn't in the cache, it never would be. I
failed to take into account that the block ingestor takes time to run,
and a test can run quickly enough that the block ingestor hasn't had
time to process the block. I reproduced the problem by commenting out
the starting of the block ingestor.
I think that error condition can be removed, which is what this commit
does. I tested by leaving the block ingestor commented out, so that
GetBlock has to use the RPC interface to get the block, and it works.
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.
If the darkside "getblock" RPC handler is given a block hash as argument
(rather than a height), it was deserializing all active blocks
sequentially to find the one with the given hash. This is slow if there
is a large of blocks.
I considered the most general solution of adding a block hash map to
darkside so that any block could be looked up by its hash, but that
turns out to be a lot of effort. So instead, maintain a one-block cache
because a block is always looked up by hash immediately after being
looked up by height (this was changed in PR 412).
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
Darkside test framework broke due to the V5 txid changes (issue 392).
This change enhances darksideRawRequest("getblock") to allow the
argument to be either a height or a block hash, rather than only a
height.
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.
dependabot[bot]
str4d
Emerson Hall
Yasser Isa
Larry Ruane
Kris Nuttycombe
chairulakmal
oscar-pepper
ebfull
Dimitris Apostolou
JG
Francisco Gindre