Suspicious spike in Zcash transactions

[Shawn]

It looks like people are discovering that since Zcash shares a lot in common with Bitcoin they can re-tool existing Bitcoin BRC-20 infrastructure into Zcash tokens.

Zcash hype + mint ZRC-20 token + marketplace to trade ZRC-20s = profit

The Only BRC-20 Guide You Will Need

[shieldedmark]

Right, I knew about ordinals and BRC-20… just hadn’t heard the “runes” term yet.

[dismad]

@shieldedmark

We’re seeing the same on our infra (zcashd).

zebrad 3.0:

toCurl.sh getrawmempool | jq '. | length'
389

zcashd 6.10

zcash-cli getrawmempool | jq '. | length'
111

Shouldn’t these be the same? Looks like someone has found a bug

[hanh]

Except that if it goes into a shielded transaction … bye bye

[shieldedmark]

Nice, yeah. This is a verification of what @conradoplg noted here:

Suspicious spike in Zcash transactions

Ah yes, that’s exactly it, thanks! @james_katz that’s not an invalid tx per se, the txid won’t appear in zcashd-backed block explorers due to the issue hanh mentioned, but it is showing up in my zebra mempool for example. I’ll surface this to the Zebra team. (For anyone reading, while it would be better to filter those, they’re not super harmful since they need to pay the ZIP-317 fee anyway. The dust filtering rule is not a consensus rule) Also I’d guess this is related to the zerdinals thin…

Mempool dust limits aren’t consensus-enforced so each node implementation has different rules.

[dismad]

@shieldedmark

Mempool dust limits aren’t consensus-enforced

Edge case players having fun I see

[shieldedmark]

Get your favorite monitoring tools ready, folks!

Zerdinals

[zancas]

Maybe it’s time for a short explanation of exactly what is happening here, that’s posted more prominently than on this thread?

If I Understand Correctly (IIUC), Zcashd filters less-than-dust-value-transfer transparent outputs (UTXOs) from its responses, and zebra does not.

It’s also my understanding that zerdinals use zcash-script with transparent transactions to mint? and burn? BRC-20-like tokens.

If both of these assertions are (at least partially) correct then it seems to me that monitors shouldn’t be filtering less-than-dust value-transfers in the shielded pool. Assuming those UTXOs are paying the ZIP317 fee (and they shouldn’t last long in the mempool if they aren’t), then they’re interesting on-chain behavior.

So, maybe I am misunderstanding, but in this case it seems that Zcashd’s behavior is sub-optimal relative to Zebrad’s.

Caveat, since this activity requires ZIP317 fees, it contributes to ZEC demand.

[Shawn]

More to come:

[shieldedmark]

It’s the Zypherpunk hackathon participants

I forgot that hackathon teams these days start with “Make a Twitter account” first

[conradoplg]

Where would you like to see this posted?

I think most people that care about this are already in this thread…

TL;DR

• Zebra accepts txs with zero-valued outputs in its mempool. Zcashd does not (it has a “dust filter”). Those txs are still accepted by the consensus rules, so Zebra is not wrong per se, but it would be better to be consistent with zcashd
• Most miners run Zcashd, so this means that those txs won’t ever get mined
• Someone is creating a lot of transactions in order to create “Zordinals” or whatever. Their minting script probably initially used zero-valued outputs (because they just need the txs to exist) to minimize their costs, but then realized the txs weren’t get mined (due to the previous item) and eventually fixed their scripts
• Since their script also did not set an expiry height for the txs, those txs with zero-valued outputs now linger in Zebra mempools without ever get mined
• That is not a big issue because Zebra has a bounded mempool and new txs will eventually replace these old ones
• This might have some performance impact on some software that is not prepared to handle big mempools, but they should really be improved to handle that possibility

Zebrad does offer a GRPC interface which allows streaming the mempool without resorting to querying. But even with querying it should be possible to have functioning software, we’re talking about hundreds and not millions of transactions. If you have suggestions on how to improve the Zebra mempool interface please reach out.

Regardless, all of this will go away when we introduce the dust filter in Zebra. But we don’t want to rush that into the next release which needs to happen before NU6.1 activation monday next week.

[shieldedmark]

I wonder what’s happening here:

Nothing in the mempool data in the last 2 days suggests that the network is causing 80% of transactions to fail. What am I missing?

[zancas]

That’s a great question! I don’t know.

[hanh]

@conradoplg

Zebrad does offer a GRPC interface which allows streaming the mempool without resorting to querying. But even with querying it should be possible to have functioning software, we’re talking about hundreds and not millions of transactions. If you have suggestions on how to improve the Zebra mempool interface please reach out.

that is not sufficient. The streaming interface will resend the same tx at least every new block and sometimes inside the same block.

[dorianvp]

Could this be due to mempool policy/filters? Although this wouldn’t explain @dismad’s output for zebra…

[l0vvkey]

Just found out about this. Always knew about Ordinals on BTC, but this can really be an issue since it will generate a lot of Dust transactions.

[zancas]

ZIP317 makes dust generation expensive. That will prevent it from being an issue for Zcash.

[shieldedmark]

Zerdinals fought the law and the law won It helped standardize our mempool filtering across zcashd and zebra, and then yeah ZIP-317 took care of the rest.

[aaal]

@shieldedmark Only if it is easy to answer, is there a place to read about the mempool filtering standard?

[conradoplg]

There is no standard for it, really. Zcashd filters out transactions with outputs with “dust” amounts but Zebra didn’t, but now it does too.