Some thoughts - I’ve not been paying attention in recent months so if this has already been done or in progress, sorry about that…
Nodes should filter txns before accepting to mempool, relying on wallets to do that seems silly & its passing the buck. Stuff like :-
stupid expiry times
insufficient fee
ridiculous size
It should be default for nodes to disconnect peers running OLD versions in favour of newer ones, especially peers forwarding txns that should have been filtered out already - which is clearly malicious.
Also time to embrace a fee market 'cos that makes spam expensive, already part way there with wallets doing custom fees so lets go all the way.
Reluctant to mention ycash has already done some of these things, their filters work before txns get into the mempool - but that’s what they did & so far so good.
I say this constructively because of how it looks,
I hope folks in ycash aren’t responsible for causing chaos in regards to using orchard. Would be a shame for a friendly fork to do so. The awful spamming in zecpages certainly follows a disturbing pattern. And in the telegram group.
The timing of everything makes my imagination go wild. I’d hope I’m wrong and fellow DEV’s can work together on a solution for the eco.
I strongly doubt that, none of the ycash people I know would do anything like that.
They also have trolls to deal with, including zecpages, the southx trollbox, various other channels - but fortunately they’re ruthless when it comes to culling idiots from channels they control.
Connecting a project to social media (especially anonymous) is like hooking it up to a sewer.
I would suggest now that blocks are being filled up (albeit with spam) that things have changed to make a fee market quite effective.
A small fee increase for a real txn would help it into the next block, while a spammer would have to pay more on all their txns to consume the full block and cause congestion - which can quickly get expensive - plus they have to keep doing it which makes it worse (for them).
Anyway - these are just ideas I thought I’d share, do with them as you wish, or not.
So predictable. First off, don’t equate “folks in ycash” with some random troll spamming an anonymous message board who purports to own Ycash.
Second, let’s be real here. It’s not like Zcash users are going to migrate to Ycash in any appreciable way because of issues with the Zcash network. It has been proven over and over again during the last 4 years that Zcash users don’t much care about Ycash (as evidenced by the fact that most pre-fork coins have never been moved on the Ycash side).
With apologies to Jay-Z, Zcash appears to have 99 problems but Ycash ain’t one.
My point is it seems coordinated. To keep at it this long is interesting and is an observation I wanted to point out.
I wouldn’t go that far either. I’ve been attracted to ycash since I first learned of it. I love other coins in similar circumstances , ala VTC. I dont like that it seems to attract the behaviors I posted above about though.
I was reading a little more about the expiry height.
According to zip-203 an expiry height is a height which a transaction can’t be mined anymore and become invalid. nExpiryHeight is a transaction field which is calculated as CURRENT_BLOCK_HEIGHT + EXPIRY_DELTA. A standard Zcash transaction uses a EXPIRY_DELTA of 40. A transaction created a block height 2198403, if not mined, will become invalid at block height 2198403 + 40, i.e. block 2198443.
If you use a block explorer to see the raw data of a spam transaction, you can see the expiryheight field set to 2398471, approximately 210000 block from now (if not mined, will stay in the mempool for 182 days).
But, once again, accordingly to zip-203, this is consensus behavior:
Minimum: No minimum
Maximum: 499999999, which is about 1185 years from now at 75 seconds/block.
No limit: To set no limit on transactions (so that they do not expire), nExpiryHeight should be set to 0.
I don’t know if they’re willing to change that.
I’m also for a fee market, I believe a Zcash transaction fee should be understood like: “How much you value your privacy?”. But the problem is that Zcash transactions are huge (because zk proofs).
A (serialized) bitcoin transactions with 1 input 2 outputs is something like 500 bytes. Where a (serialized) Zcash transaction with 1 input and 2 outputs is something like 4000 bytes.
Assuming 8 satoshis per byte, a bitcoin transaction fee would be 0,00004 BTC. Assumming the same 8 zatoshis per byte, a Zcash transaction fee would be 0,00032 ZEC. (I’m not an expert, I can be wrong on this, I pick random transactions on blockchair to do this calculations).
The only wallet right now that supports custom fee is YWallet, they would need to implement a fee estimation to avoid users needing to do the fee calculation themselves.
But i digress, I can’t even remember what is the point I was trying to make
If you block stupid expiry times, you could also block some legitimate transactions. And more importantly, it wouldn’t make any difference. The attacker would change it to +40 blocks and the attack will keep working almostly exactly the same. It’s easy to fill the mempool with low fee txs even with a standard expiry time.
If you block txs with insufficient fees, all wallets would stop working since they haven’t updated fees, and that would be catastrophically bad. And if we do that after they update we might still block legitime transactions because there is probably some unmaintained code out there not setting the updated fees.
If you block txs with ridiculous size, you might still block legitimate txs. See for example the Ywallet spam filter which has been known to block some legitimate txs. It can happen with regular Zcash usage: you receive a bunch of ZEC via different txs, and then decide to spend them all: you will create a big tx with multiple inputs.
That being said, ZIP-317 already did a great job of mostly solving this. But wallets need to update their fees.
Yes, I am aware of this and this was a transaction made for the testing staff of the ECC. They were given coins in order to do ad-hoc testing.
Obviously, there could be a reason for receiving coins as part of 50-output transaction and you may feel the need to deactivate the spam filter. You can. The filter is optional. It is entirely up to you.
However, I haven’t heard a compelling case for a regular user to receive such transactions.
This is almost what ZIP-317 does, but ZIP-317 does it more effectively, by requiring a fee proportional to the number of actions and only allowing 50 “unpaid” (paying less then the proportional fee) actions per block.
