API Suggestion: GetBlockRangeWithFilter
Closed this issue · 4 comments
What is your feature request?
Since the beginning of Jul, the blockchain has seen a surge of large transactions with a lot of outputs. The reason remains unknown but it is clear that for most people, these transactions are not relevant.
However, currently, lightwallets must download and process all this data. At this point, the "compact" blockchain is bigger than 5 GB. More than 4 GB are from Jul-Aug alone.
In fact, downloading is the bottleneck for YWallet and when I synchronize from my own local server, I can pull >10 MB/s. But if I use ZWL or NH servers, I usually only get ~1-2 MB/s. Unfortunately, the wallet is waiting for data.
I suggest offering a filter option in LWD which would prune the compact outputs down to the cmu (that is needed for witness maintenance).
There is an ongoing discussion about changing the fee structure in the future. I suggest retroactively applying a similar formula to the existing transactions. Essentially, a client wallet would say: "I am not interested in transactions that would have cost more than X in fees". Either they are not for me, or they are from spam / dust transactions and would waste my phone resources.
Right now, we could make the filter just be a limit on the number of outputs. Then update/improve it when the formula is agreed on.
The client can decide what threshold he accepts.
How would this feature help you?
With this function, the lightwallet will download only 32 bytes instead of 116 (=32+32+52) per output. So ~1/4.
Instead of downloading 5 GB, it would be ~1.5 GB (very rough estimate).
YWallet implements this filtering logic in the client but it still must download all this excess data.
Additionally, the API could also introduce an option to discard all Orchard data from the download. This would be interesting for wallets that currently do not support Orchard.
As a new API, wallets that don't use this feature will not be affected in any fashion.
Thanks,
--h
I totally support this API implementation. Assuming there's no security implication of implementing it, users will have an option to retrieve their old Sapling balance without having to commit huge resources (potentially 10s of GBs of download and storage plus days of trial decrypt).
PR #413 seems to meet your requirements, do you agree? If so, that will make the case for merging that PR stronger.
Yes, this would work fine. As a matter of fact, Ywallet uses the API from this PR if connected to Zecwallet servers, so this would make it work across the board.
We've decided to close this ticket at least for now, please see the explanation at #413 (comment).