Our primary PoW of Cuckatoo31+ is intended to be mined by ASICs.
As such, it is important to have all rules regarding validity of cycles, validity and weighing of graph sizes, and allocation of block rewards, clearly set out, implemented, and immutable for the foreseeable future, so that ASIC manufacturers can feel confident to invest in ASIC development.
The rules for cuckatoo validity are codified in C at
and in Rust at
The rules for phasing out smaller sizes are codified in
The rules for balancing block rewards, are codified in
And of course the supply is fixed at 1 Grin per second.
The Grin developers currently have no intention of changing these rules in the foreseeable future, unless Cuckatoo is shown to be broken (e.g. by exhibiting a sublinear time-memory tradeoff), or unless the phasing out of smaller sizes should be delayed in order to ensure public availability of >= 1 GPS miners.
Wait wait hear me out on this, what if you generated a large number of graphs, you store it on cheap media like tape drives. Sort them using a metric that somehow put “similar” graphs next to each other, somehow you reuse a tiny amount of work if graphs look alike( and given the birthday pardox, you would only need the square root of the total possiblity space and as we know O() really likes sub linear inputs like that)
If you managed to reuse graph logic in such a way, you would only need to sort thru square root of 2^31 on tape drives which we all know a sort function is n log n, and therefore negligible.
You may need to slow down the network speed to enable this asic design for the start up time this system would need; but 1 minute was kinda fast anyway.