Another important way to help people handle blockchain growth:
opened 08:08AM - 15 Jul 22 UTC
C-upstream-port
use case
Please backport/merge from upstream Bitcoin:
* bitcoin/bitcoin#12653
* bi… tcoin/bitcoin@386a6b62a8a1db9dd0f354cb95b7585f555c7e5d
* bitcoin/bitcoin@f38e4fdb06406f9a1a2562836fab523eb75b5090
* bitcoin/bitcoin@a1926362ecb3c354ae338ef7d7020daf78f980c9
* bitcoin/bitcoin#14364
* bitcoin/bitcoin@ccc27bdcd2d91fe2c023ad004019d5b970f21dbf
Also be aware of:
* bitcoin/bitcoin#14409 (For reference, see also bitcoin/bitcoin#15445.)
* bitcoin/bitcoin@c3f1821ac788e522e7558e3575150433450dcb8c
* bitcoin/bitcoin@e4a0c3547ed886871f8b3d51c6b4ffdb181a8b9c
(Related: #2074 needs updating in the “After 0.12 branch” section. Is there a comprehensive tracking issue for useful merges from upstream?)
This will help to resolve [an issue discussed on the Zcash forum,](https://forum.zcashcommunity.com/t/heavily-increased-transaction-load-since-june-14/42349/40) which currently prevents me (and no doubt others) from catching up with a rapidly growing blockchain. It may also facilitate development of a third-party block data storage management tool that I’ve been contemplating for awhile for Bitcoin, which would now be urgently useful for Zcash; but no promises. At the least, it would provide a supported way for users to move the largest, fastest-growing data off their primary storage (perhaps SSD) onto inexpensive external hard disks (rotating rust).
The only alternative now is attempting a footgun dance with back-and-forth symlinked directories, and hoping that the node doesn’t get confused, or using [an extremely ugly old kludge that I do not recommend](https://en.bitcoin.it/wiki/Splitting_the_data_directory#If_your_data_directory_is_on_an_SSD:_Moving_the_blocks_database_to_save_space). (I may be mistaken, but AFAIK, it is *not* safe to symlink `index` within `blocks` to a target outside of it?)
Heavy random IOPs are only needed by the databases unaffected by this option. The `-blocksdir` flag has an effect **intentionally** limited to large files that mostly need sequential read/write, with very little random access.
If there are no merge conflicts requiring deep changes in Zcash, I respectfully request that this be prioritized; indeed, I suggest that it would be suitable for a v5.1.1 rapid point release to help users who are struggling with sudden, rapid blockchain growth. This is especially important, because **Zcash has no option to prune without disabling the wallet (zcash/zcash#4080, zcash/zcash#2225).**
The foregoing list of PRs/commits is from a cursory initial search. I have not yet examined the code on either side, so I apologize in advance if I missed anything. If comments on this issue correct any errors of commission or omission on my part, I will edit this OP.
Thanks.
----
Some “@sipa said so” documentation for advanced users who want to understand what is in this directory: [[0]](https://bitcoin.stackexchange.com/a/57981), [[1]](https://bitcoin.stackexchange.com/a/92141).
As a separate issue, the status of pruning in zcashd:
opened 06:36AM - 31 Jul 19 UTC
A-wallet
pruning
@str4d wrote:
> [Wallet support] was disabled [in Bitcoin Core] when pruning wa… s added in Feb 2015, and then re-enabled in June 2015 in one of the first PRs in the 0.12 series: https://github.com/bitcoin/bitcoin/pull/6057
We would need to also look for subsequent stability and security (and possibly performance) fixes in Bitcoin Core that might interact with pruning.
How does that help users who want for their own Zcash wallets to have the full privacy and security of a full node?
In Bitcoin, the principal argument for individuals and businesses to run nodes is self-interest aligned with the common good: Be Your Own Bank. Bitcoin Validators who enforce the consensus rules don’t need any direct financial compensation, because the security and privacy benefits of your own full node are payment enough—and the costs of running a Bitcoin Validator are so low .
Multiply and exponentiate this for Zcash. I sometimes run a zcashd but no bitcoind, because running your own node on your own hardware, under your physical control is critical for gaining the full privacy benefits of Zcash. And privacy is the reason to use Zcash. If you can’t run your own Zcash node, why bother?
3 Likes