There has been talk of changing the algo to something asic-resistant.
I believe ProgPoW to be overkill at this time, I like my GPU being cool as do many others. I don’t believe an algo switch is needed until Iron Fish is worth quite a bit more, than being said I think we might as well take the time now to plan what algo would be best if ASICs come.
What the experts I have talked to suggest is a modification of Blake3 that will increase power use somewhat that goes in this order:
blake3
light DAG lookup for matrix
matrix math
blake3
A DAG helps keep ASICs off as ASIC manufacturers are behind on random access memory accessing technology compared to Nvidia/AMD. Making a DAG-capable ASIC is a lot more investment than just making a Blake3 one and as we saw on ethash it took a while for them to develop a good one. Matrix math incorporates what Kaspa uses which uses tensor cores and is fairly cool.
Overall we believe this results in minimal power increases over current the current Iron Fish Blake3 while making the algo ASIC-resistant.
I think this is the perfect solution to kill two birds with one stone, on the one hand the ASICs, and on the other hand the unknown hashrate. I’m in with this proposal. Thanks
I like the proposal for an algo change. I’d recommend the Autolykos algo that Ergo currently uses. The algo is mem intensive, uses more power than alot of core heavy algos, but not as much power as many other gpu algos. I think it offers a nice middle ground.
I’d love to hear why. I think it would help encourage most at home miners and potentially reset the network hashrate to a more healthy point, thus allowing normal GPU miners to participate.
The huge unknown hashrate has a lot of people spooked and with that the only way to profitably mine the coin is via FPGA. This eliminates a huge number of GPU miners from participating and hurts the community overall. We need more people involved not less.
I had thought about randomx as it is probably one of the most asic resistant algorithm, but people inform me that it is also GPU resistant so what are people’s thoughts?
The problem is we’re pretty sure the unknown miner is a GPU miner. Given the timing it’s unlikely to be a FGPA farm. Even if it is it may be a memory bus heavy FGPA farm. So Ergo’s algo may work for them.
An algo change isn’t really meant to stop the unknown hashrate just future ASICs.
If the unknown hashrate is from a big GPU miner then I don’t see the issue. Why should we decide who can or can’t participate in the network? As far as I’m aware this unknown hashrate has not done anything disruptive to the project other than spook people and push away at home miners. My understanding is that the goal is to redistribute the hashrate not eliminate people from participating.
I am under the impression and had heard several people hint that they were aware of it being a big FPGA farm. In that case they have an advantage over most GPU miners and I can understand if the community wants to try and level the playing field. Ergo does have FPGA bitstreams available but are practically the same efficiency as the current gen GPU’s.
An algo change doesn’t remove the potential for the unknown hashrate to participate but could help level the playing field for everyone, resulting in a more decentralized network.
To sum up some of the stuff that was discussed or going on in Discord the last days:
It is quite unlikely the hashrate comes from GPU miners, as no one of the established GPU miner devs has a market share that would fit to the high unknown hashrate. Also even with energy prices close to 0 all current market available GPUs would operate close to a loss and have better mining opportunities. If one standardizes to mass market cards like a Nvidia 3060ti and see the income before power draw for this GPU in comparison with other coins the return is only about 1/3rd of that a GPU only coin usually produces and it is 1/2 of those where we know there are FPGA implementations.
There had been a graph shown showing a short dump down of hashrate of Ironfish and Kaspa both happening at almost exactly the same time centered around midnight UTC on June 26th. the suggestion is that the two dump downs might be connected (like a power out in a large datacenter)
With regard to an algorithm choice it is known that all algorithms that rely on computational operations only without a random order in it will eventually be adopted by FPGAs and - in case the network is large enough - also by asics. The goto seems to involve more operations requiring a memory access, if this is supposed to be GPU friendly.
Autolykos v1 based blake2b would be an amazing fit for IR to improve decentralisation of block production. While, bypassing non-outsourceabilty, was possible on Ergo, it might not be possible on IF (due to the limited scripting ability of notes).
Something I’ve just considered: The above assumption that miners can “bypass non-outsourceable Proof-of-Work schemes if the underlying blockchain platform supports smart contracts in a sufficiently
advanced language” might in fact not hold true in the presence of a protocol like Lithos (still in development) … but I’ll need think about that, but if that’s the case, Autolykos version 2 would be the way to go and you’ll still get asic-resistance.
I want to summarize last week’s miner’s call here on this topic (Aug 22nd).
Every week until Iron Fish completes its transition to a new hashing algorithm, or until the community decides to stop, we are going to have a weekly miner’s call on Discord. To sign up for subsequent calls, check out the Events tab in the Iron Fish Discord, or use this link (hopefully this link works for all future events, if not you can find it on Discord directly).
