Minimum memory requirement in a new PoW algorithm


Regardless of the algorithm to be used, with a memory-bound PoW algorithm comes a requirement on the minimum amount of memory to generate work. Going below this minimum will usually mean a steep increase in the time to generate work (usually exponential), and that's if the implementation can deal with it.

Since this affects the whole community, we're opening up the discussion to figure out what would be an acceptable amount of required memory. The choice will have some impacts:

  • Some nodes on the network will no longer be able to generate work. Remember that nodes that don't generate work won't need any memory;
  • With a higher requirement, it gets harder and more expensive to parallelize the algorithm, including FPGAs and ASICs
  • A higher requirement will also help with botnets

Moreover, the node currently supports work peers and we plan to extend this support to potentially provide DNS resolution and authentication. Generating work is a critical part of Nano.

Curious to hear your thoughts.


I think it's important to hear from service providers (exchanges, wallets, payment processors, etc) on this particular topic since PoW changes affect them the most. Individual senders like myself that only send a few transactions a week with local PoW generation aren't really affected.

That being said, I prefer to keep the PoW requirements relatively light and rely more on dynamic PoW. That keeps Nano more environmentally friendly, and if the network isn't saturated why not let people use it.

Is it possible to only increase the PoW requirements for transactions that shouldn't happen as often (e.g. opening accounts and sending to unopened accounts)? That might help limit ledger bloat will limiting the impact to normal users who send to people with already opened accounts

8GB would be my starter.

Also interested in how this will change over time as memory increases on devices.

1 Like

Many algorithms scale difficulty with time and not more memory. That is, they establish a minimum memory requirement, and in order to get a higher difficulty you just have to spend more time repeating the same sequence. I would say that is both fortunate and unfortunate.

On the bright, someone with much more memory available (say, 1TB of RAM) cannot stop other nodes from having their transactions accepted simply because it has more memory - it has to spend time doing it instead.

However, that does mean we must increase the minimum memory requirement in order to provide the benefits outlined in the OP.

Ledger bloat and related discussions are offtopic here given the above.

1 Like

To be clear, I meant the memory requirement of the PoW algorithm. I imagine you'd like to change the number? :smiley: something in the order of 1GB provides some assurances against ASICs for the time being, not so much for botnets.

Wait a second - I thought one of the design goals would be to reduce the benefit for ASICS (compared to the current computing intensive PoW) and not to make the new algorithm ASIC proof.
Did I get that wrong?

Yep, I went with a high requirement for the PoW algorithm.

When I talk to BTC maximalists their argument against Nano is it could be spammed into oblivion, anything that makes the burden higher helps in my opinion if the vision is to be a global payment system.


I'm not an expert but here's what I have found.

ASICs can be built very similarly to GPUs - for example using GDDR or HBM memory, in which case the largest benefit is mostly one of energy efficiency by removing parts of the GPU that are not useful for the algorithm.

By having large enough memory requirements, it will discourage ASICs being built with all that memory as SRAM, which would be devastating for memory-bound algorithms since it's much faster - and has less latency - than DRAM.

1 Like

Thanks for digging deeper!
So in the end ASICs for a memory hard PoW would be (slightly?) more energy efficient than GPUs when using the same RAM technology, but otherwise expensive and limited in usability.
Using faster RAM like SRAM would make them even more expensive.

I don't know about average RAM sizes of computers, servers, mobile phones, but based on the hardware I own (nothing too fancy here) a minimum between a few GB and a dozen GB should work for most people.
It would be nice to compute the memory bound PoW on mobile phones. I suppose the current PoW algo is not very suitable for average mobile phones.

Just throwing a random idea out:

Would a temporary increase of PoW difficultly require more RAM to be used? Would this counter ASIC spammers by making their hardware useless at higher difficulty levels?

@gak as explained in this reply, it's generally more plausible to have a base amount of memory that must be used, and to increase the difficulty all it takes is more time.

@zergtoshi mostly we would be worried about VPS with low amounts of memory. People have those for $5-15 a month and they'd need another setup to make transactions. Granted, they're slow even on the current PoW and people have sought other solutions, but it's something to keep in mind. But it's interesting to see more people supporting even higher amounts of memory here.

1 Like

It depends a little on whether an expiry time is implemented for PoW.
If it is, then the memory requirement can probably be kept on the lower end.
To enable clients to still compete at a higher network difficulty during a spam attack, having to spend a long period of time at the base difficulty would presumably make them even less able to compete at higher difficulties.

@Dotcom my understanding of the Nano network might be off, but I don't perceive those low-end VPS nodes as an integral part. VPS in that range of up to $15 might be powerful enough to host a Principal Representative, but that doesn't require PoW, right? If Principal Representatives require PoW for whatever reason, those VPS need to be taken into account of course. Otherwise I don't think we should care much about low-end VPS nodes when defining the memory requirements.
Dynamic PoW is a real gem, but I'd rather not solely rely on that and advocate making spam attacks as hard as possible, hence the call for lots of minimum RAM.

In my opinion both end users and services and their ability to use Nano are paramount for the success of Nano.
Services (e.g. exchanges, payment service providers) that rely heavily on the ability to generate lots of PoW will either contract services or have a dedicated setup of PoW hardware.
And although I'm utmost glad that Nano is without transaction fees, I foresee a fee market arising in which highly specialized hardware gets used to generate PoW at a charge for those who can't or don't want to do that on their devices.
DPOW comes to mind.
So whatever PoW gets implemented, there will be a solution for users and services.

1 Like

I like the minimum memory requirement. I'm not too bothered by $5-$15 VPS with low memory not being able to process work.

It’s a tough call. If the memory requirement is too high for a client side PoW on a medium spec’d mobile device it starts moving away from its ideal as an equitable access feeless value transfer protocol.

I beg to differ.
Client side PoW currently plays no role for mobile devices and although I hope with memory bound PoW this will change, I have some doubts.
App providers shy away from using client side PoW, because the apps would be flagged for mining and removed from the stores. I don't know how this will be affected by memory bound PoW.
For now PoW for transactions by mobile devices is relayed to the app back end. So the burden is shifted to the service provider. This can remain the same with a new PoW algorithm.

Or to put it this way: we already have a working solution for mobile devices.

1 Like

I'd still implement client-side PoW and have a separate APK download...
It's not Nano's fault that other cryptocoins are mining based.

Off-topic: I hope that after pruning the light wallets will be self contained.


Understand where you’re coming from, although it’s only currently working in the feeless paradigm on mobile because of the good will of those providing the dist PoW which is not sustainable.
The issue with mobile devices and “mining” as I understand it, Is background processing. It may be fine as long as the app is open.

This is one of the things we are interested in more discussion around as new Equihash research becomes be available soon, see Equihash as a new PoW algorithm - #2 by clemahieu for an update.


Is the idea to revisit the memory requirement every so often as hardware/avg device memory improves?