hanh
May 24, 2022, 2:18pm
1
Are you guys (@aiyadt , @NighthawkApps ) planning to upgrade to zcashd 5.0 & lightwalletd 0.4.10?
It seems to be running a pretty old version
{
"version": "v0.4.9",
"vendor": "ECC LightWalletD",
"taddrSupport": true,
"chainName": "main",
"saplingActivationHeight": "419200",
"consensusBranchId": "e9ff75a6",
"blockHeight": "1678912",
"gitCommit": "83bb19918fb36a5f6d5013fba7938daf3d73db1d",
"buildDate": "2022-05-15",
"buildUser": "lightwalletd",
"estimatedHeight": "1678912",
"zcashdBuild": "v4.6.0-2-gac0c24cfa07",
"zcashdSubversion": "/MagicBean:4.6.0-2/"
}
2 Likes
Han, we are looking forward to deploying a working version of lightwalletd prior to the NU5 activation.
You can find the latest updates on Twitter:
zcash:master ← LarryRuane:2022-05-v5-txid
opened 10:50PM - 23 May 22 UTC
Partially fixes #392
This is a shortcut fix. Instead of replicating the zip244… transaction
logic that's implemented in librustzcash:
zcash_primitives/src/transaction/components/orchard.rs
cheat by calling getblock with verbose level 1, which prints the txid
of each transaction. This currently requires calling getblock twice,
once for the raw hex (as we have always done), and again to get the
transaction IDs. An easy improvement would be to add the raw hex to
verbosity 1 result. (Or have a new verbosity that shows both.)
The unit tests don't pass with this change, but I wanted to make it
available for testing as soon as possible, we can fix the tests later.
opened 05:00PM - 13 May 22 UTC
closed 01:51PM - 26 May 22 UTC
I-performance
I-regression
### Describe the issue
One of the RPC methods in zcashd has a severe performanc… e regression over v4.6.0-2. This issue is most likely also present in v4.7.0, but I haven't tested it yet.
### Can you reliably reproduce the issue?
LightwalletD is currently unable to run against v5.0.0 when running in production, because one of the RPC methods is taking too long to return. It is almost certainly one of these RPC methods:
- `getaddresstxids`
- `getrawtransaction`
- `getaddressbalance`
- `getaddressutxos`
What is happening is that one of these RPCs is grabbing some sort of lock inside zcashd and taking a long time to return. This causes CPU usage on one core to become 100%, and subsequent RPC calls to queue up, eventually failing with a timeout. Note that my machine has multiple cores, but zcashd consumes 100% of one core and locks up the RPCs, eventually causing timeouts.
This is also happening only in production, which makes me think that the large number of calls coming in from Zecwallet users is causing this problem.
### The version of Zcash you were using:
v5.0.0, (but almost certainly also happens with v4.7.0)
### Machine specs:
4 core AWS t2.xlarge instance with 8GB of ram.
### Any extra information that might be useful in the debugging process.
4 Likes
We’ve just wrapped up testing and deployment of zcashd v5.0.0 on lightwalletd.com load-balanced infra
11 Likes
