Havent seen much posted on the forum other than the persistent requests from members having trouble with their wallets.
I’m confused. Can someone with greater diagnostic talents tell me why “chain spam” is causing problems for zcash? Are there actually problems other than with wallets?
i see 1 zat per byte, and blocks arent full.
Is something else the problem? ECC been silent, yeah?
Not sure I understand what you are asking. Is it:
I think whoever is doing it is trying to make a point, although no clue what that might be.
Transactions with so many shielded outputs are unusual and probably pointless besides consuming space.
The financial cost of doing it is tiny, the impact is high given the CPU load to trial decrypt.
Smells like spam to me, with a hint of ‘Denial Of Service’.
Thank you. Yes, that’s how I see the problem explained.
I guess I don’t understand why that is happening on the wallet facing side. These wallets aren’t nodes.
Yeah, it seems malicious without reason other than because someone can. I’d like to speculate about their intentions, but what I guess I’m publicly wondering is whether or not we’ve properly identified the problem.
I’m a bit surprised that someone from ECC hasn’t offered their opinion considering it seems to be plaguing a lot of people.
Hanh:
Why does your wallet offer a solution when the others don’t?
If this is a proper statement, isn’t the problem more a wallet compatibility issue with zcash upgrades, rather than some chain wide issue?
Thanks for all your volunteerism.
It’s mostly because of its synchronization algorithm. "Warp" Sync - a full scan method
so, as long as we continually use warp sync we can get past the shielded bloat…
sounds like there are some equally great or greater issues with raw data size on the horizon.
can these issues be overcome?
A good example of “why diversity is a good thing” - I’m just glad there’s still a working wallet.
thanks for helping me understand the issue more. the decrypt compute really is that intensive, huh?
is the spammer using messaging feature to accomplish this?
No one can tell how it is done. They could actually be using it as a cheap storage solution for their data. The bottom line is that the protocol allows it.
(My limited understanding) With 10,000 outputs in a TX, the lightwallet has to try each one to see if belongs to the wallet. If the wallet is behind a few days or weeks, or needs to rescan, thats a lot of CPU to burn to catchup. If things are not managed well, like if the sync work blocks the UI thread, then the load will crash the wallet.
Because of what people are reporting about how it affects others, seems mostly likely an attack on the network (to sabotage it, or force devs to improve it in a very rude way)…I won’t spend time looking much, but I’d imagine our ECC geniuses are studying it hard.
But just an alternative idea:
It’s someone’s independent money privacy operation. They’re using the incredible privacy design of shielded Zcash, but instead of default metadata choice, they’re doing their own one (e.g. high no. of actions per tx).
They’re doing this because:
They don’t need to hide in the regular fingerprint of fully shidled tx. (They only need the default tech of Orchard etc.)
They have found - or think they’ve found - a different metadata pattern that helps their particular OPSEC somehow. They might be right, or wrong. We don’t know their objectives.
Blockchain can’t always easily or quickly innovate its way out of corners, even due to non-malicious network strain. Look at Ethereum and gas fees etc.
I have confidence that ECC will solve this fully in time given the other amazing things they do.
I hope they do fix it! Spam is still coming.
ZEC needs to impose fees based on transaction weight in order to make the attacker pay for these giant transactions. Not sure why a flat fee approach was taken, but this is the fallout. The blockchain is expanding at about 8x the normal rate. Over 1GB per day.
If you haven’t kept your mobile wallet up to date, good luck getting it synced by Christmas at this point. Even a full node takes a significant amount of time to catch up on a single days work.
Maybe ask the largest pools to stop mining giant transactions ? Its not like they collect much in fees
It’s not the pool’s job to judge which transactions are “good”. The ZEC client node has responsibility for consensus rules, which would include what you’re talking about.
Agree, but it would ease the problem until a proper solution is deployed 'cos right now it sucks.
Related:
To the spammer: you are why we can’t have nice things!
The Zcash network is just limited in its ability to scale in comprehensive manner, i.e. including mobile light wallets, in its current configuration.
If these issues are apparent with relatively low volume, ~6,000 tx per day, then even without the so called spam it would seem the network would be experiencing similar issues with significant adoption of shielded transactions.
ZEC Orchard txs are currently 9KB apiece, at a minimum. With a 2MB blocksize and 75 second blocks that puts the the theoretical max shielded transactions per second at roughly 3. This ignores bandwidth and processing requirements the likes of which those building the network should be able to further explain. In practice the max shielded txs per second appears to be lower.
Please correct me if the latter figures are in error.
I haven’t done any Orchard transactions.
I can say that a usual Sapling transaction is like 2k or 2.5k. So the speed now is more like 13 shielded transactions per second. The very large transactions we see in the spam are slightly less than 1k per output. I have seen transactions that are 800+ outputs in size, so you get two of those per block.