NU5 and Sandblasting retrospective

Hey folks,

I’m sorry for the confusion about the NU5 and Sandblasting retrospective. We think it is a good idea to have a public retrospective about the process of deciding on and deploying NU5 and of handling the Sandblasting. We have already done and are still doing an internal retrospective process ourselves, and by next week we’ll have organized our ideas from that.

Since the ECC team were the creators of NU5 and were also responsible for responding to the Sandblasting situation, we could lead this discussion. However, since we are also responsible for any failings in it, we think there should be an independent discussion leader. We’ve asked Mark Henderson—formerly of Equilibrium Labs—if he would serve as an independent leader. Mark has a strong engineering background, having led efforts for multiple other blockchains, Ziggurat, and the Zcash Sustainability Fund.

Mark has offered to host a conversation about this next week, on Wednesday, the 13th, at 5pm Eastern Time. I’ll let him follow up with the invitation details. See you there!


Hey everybody. Mark here!

As Zooko said above, I’ll be hosting the NU5 and Sandblasting Retrospective and it will be held on Weds, Dec 13 at 5pm EST. Below is the link for the meeting, looking forward to seeing you all there!


Hello @aphelionz!

As marked above ECC has taken main responsibility for deploying NU5 and the sandblasting incident response, and this retro will cover those.

And also the blogpost section “additional challenges” mentions:

  • The ECC Core team had three different managers during Emergency Mode.

Were these people notified individually of the retrospective? Have they confirmed their attendance?

Since their work and decisions will be under the spotlight, it would be important that they are present so that they can give their insight.

What about other members of the mentioned teams like Core, Infrastructure or Wallet that are no longer actively contributing to the community but were part of the mentioned sequence of events ? Were they notified of the upcoming retrospective?

Would you mind sharing the agenda of the retrospective so attendees can start preparing their notes?

Thanks for stepping for this important event for our ecosystem


Can anyone share some light on why there were three different managers? I assume something related to the layoffs?

It looks like emergency mode wasn’t mentioned until October yet the supposed attack started over the summer. I would hope this question gets answers during the discussion.


IMO, it’s also a bit disingenuous to omit that

  1. Ywallet was working during all this time,
  2. Emergency mode is exited primarily because the spam is over. Running SbS over the spam period is impossible (out of memory, desync, and too slow).
  3. SbS does not do Spend before Sync as reported ZCash wallet sync performance - #85 by refinance

Users will undoubtedly notice these issues themselves at some point.


We discussed the first two of these topics in the Sandblasting retrospective today. Too bad you weren’t there! The people who were there mentioned a few things that contradict some of the things you assert in this comment. It is being recorded, so you could watch the recording if you want. Maybe you could follow up with them/us in a future meeting. If you’re interested, maybe reach out to Mark Henderson.


Is the call recording or transcript available?


Not yet, will post link as soon as available

my recordin here: Zcash Sandblast retrospective call - 13th December 2023


also notes from @squirrel here:


Well, I could not find any user scenarios, design docs, function specs, or ZIP regarding SbS, but I may have missed them. All I could find was a blog entry about DagSync. DAGSync: Graph-aware Zcash wallets - HackMD

Therefore, I cannot tell what SbS is supposed to do. As a user, I have some expectations for a wallet and it seems that you want to do something else.

The blog says:

As a user of multiple cryptocurrencies, I don’t think it’s reasonable to change the definition of a wallet just for one coin. Imagine if every coin had a different wallet behavior…

1 Like

Prolonging the longevity of the dev fund with busy work seems to be the goal. At least that’s what it seems from my end (I’m sure I’m not alone).

I think there is an important point being brought up by @hanh

My hypothesis is that given Zcash spearheading nature in terms of cryptographical development, it has a tendency to think it is special in every way and this gets in the way in technical implementation and conspires against generalization and adoption.

Unix/Linux, MacOS and windows have things to teach us here.

Unix/Linux are great Operating Systems, yet people wanted windows which sucked pretty much at everything, was insecure, unstable and could make you lose all your work in a second.

Many years ago the MacOS team understood that the way out of this dilemma was figuring out how make Unix/Linux more like Windows and not put efforts in making “normal” people appreciate Unix/Linux and making the effort to meet Unix/Linux’s ends.

This debate has decades already. We should be better at learning from past experiences of things that are not “cutting-edge” but worked.

The same thing happens with Zcash. We are special, yes. We are cutting-edge. But that doesn’t mean that people have to unlearn all they know and works for them to pay us some sort of tribute or idolatry.

We say to ourselves that Zcashers are humble and collaborative folks. But I have learned that this tendency to see ourselves as “special” is a way of expressing ego. We need to learn that our value will be multiplied 10x if we focus on undoing this notion of specialty. Because, as Hanh pointed out, users don’t care. They want to get things done.

We don’t have to re-define everything even though sometimes our zero-knowledge tech may require us to. Probably when confronted with that reality, is that we need to keep innovating and developing breakthroughs so that it is not the case.

UAs and no trusted setup HALO2 crypto are good examples of this pursue. But we need to keep going further. UAs won’t be “complete” until its is as simple to use one as a BTC address. HALO2 won’t be “complete” until it choosing to use an MPC trusted setup instead of HALO2 it’s seen unreasonable by any means.

Our “definition of Done” must be revised as well.


There is a case-study of your observation about how the royal we Zcashers tend to feel special, and by some divine powers are entitled to special treatments and outcomes. (the below is only one example from many)

If we know that one exchange now has compliance problems with Z-2-T interactions, then we should probably assume that eventually they all will.

I’m not referring to that case because is not my area of expertise and neither the topic of the thread.

Also please let me disagree with you on the example you picked. Binance is actually having problems with the one thing that makes zcash different from other coins: REAL PRIVACY

So this might even not have much to do with what I’m referring to

If you are referring to:

  1. I had a mitigation in case this was a problem (you could import a specific tx if needed). However, the only case reported came from one of your test team members who received ZEC as part of a distribution of test coins.

Let’s be realistic, does anyone use ZEC in payroll besides the ECC?

  1. It is an optimization. You can turn off the filtering. The scan will still complete but it will take much longer.

  2. This doesn’t really justify not mentioning YWallet.


I had not had the opportunity to read this post in the forum and I am going to look at the meeting they did to find out who are those people who contradict the two points mentioned by Hanh.

  1. In the days of full spam, 3-4 months, YWallet was the only wallet that worked, did it have problems, yes, it had some problems, but none as relevant as not working for more than a year -All other wallets using the SDK-.
  2. In over a year YWallet was and still is the best working wallet within the zcash ecosystem, I repeat, none of the wallets using the ECC SDK have worked well in the last year and today they still fail, both in production with the new SbS, and in beta where not even SbS works, and I’m sure you know what I’m talking about.

To say that Hanh’s statement is contradictory is simply being locked in a room thinking how great Zcash is and not seeing how in more than a year the community was up to their necks solving problems of users with bugs in their wallets and what was the salvation in those days, YWallet, there was no other. ECC knows it, ZF knows it and the whole community knows it, covering that up is impossible and it is not going to change just because in a recent meeting about the Sandblasting retrospective they say otherwise.


@hanh is a breath of fresh air in the Zcash dev ecosystem.

1 Like