1

The core team is implementing the changes to the Firo network as per community feedback. We are giving notice to the community of these changes so that it’s all in one place and to give a final chance for feedback if any:

Change of dev fund address:

https://github.com/firoorg/firo/pull/1646

The dev fund will be moving to a new address (just to keep the UTXOs manageable) and the spark name registration fee will be paid to the correct address (where it was mistakenly paid to the dev fund previously).

Cap GPU memory requirements on FiroPoW so that it can run on 8gb cards

[POLL] What should the VRAM requirement for mining FIRO be?

Increase Spark spend to transparent limits per block

This is to increase the limits to 30,000 as 10,000 limit is becoming limiting in transactions and as Spark becomes more battle testedwe are opening the limits up gradually.

Implement Spark Name Transfer protocol

PR coming soon but it will allow users to to interactively transfer Spark Names to someone else or to another address.

3 Likes
2

Some notes on the FiroPoW GPU VRAM memory consumption part of this hardfork:
Id like to point out a potential issue with the GB value chosen for the new Firo mining DAG file size - and also ask if testing was done on all platforms - including Windows as well as Linux. Microsoft has refused to change their code that reserves approximately 1GB of VRAM for Windows use - ‘just in case they need it’. I’m assuming we want Firo mining to be as easily accessible to Windows users as Linux users. While the number 7.1GB seems reasonable (if you haven’t had to deal with unreasonable Windows updates) - and I’m sure will work very well on Linux based GPUs (I have; howeverseen Linux systems be able to mine Firo for 6 months or more longer than with the same sized GPU running under Windows because of the Windows reserved VRAM issue (I responded to a Firo Forum post in May 2024 - Stated Official reference miner with Epoch : 685 non-working ). The post specifically talks about a DAG file size of 7.26GB failing on a Win 10 machine. This is too close to the proposed 7.1GB for most people’s comfort level - especially since we know Microsoft makes seemingly random changes to code that could ‘tweak’ the amount of VRAM reserved by Windows with no consultation to the public.
There will be a LOT of pissed off miners using Windows if we announce 8GB cards will work again - only to find that it will only work on Linux systems because Windows now reserves enough VRAM so that only DAG file sizes up to 7.0GB will work.
Another note - VRAM on GPUs varies depending not only on GPU manufacturer but also VRAM manufacturer within the same brand and even model number. Some GPU models can get many more Epocs of successful mining on the same sized card - so choosing a cutoff point too close to being ‘perfect’ may shoot us in the foot for some Windows users.
In summary - 7.1GB seems way too close to the 7.26GB failure value we were seeing a little over a year ago. Picking a number closer to something like 6.8GB - or maybe even lower - might be much safer - certainly a DAG file size of 6.5GB or something similar won’t work on a 6GB Linux based GPU - but has enough ‘wiggle room’ in case Windows gets tweaked a little too much in one of Microsoft’s updates. I wish I had the time and hardware setup to be able to help test this - but both my hardware and time budgets are pretty tight right now. Hope this helps.

1 Like
3

Hey @Zed thanks for your concerns. For safetywe’ve lowered size to 6.76 GB which should be sufficient and address your concerns while keeping the spirit of the community decision.

3 Likes
4

Hi,

I saw some commits in the last few months about sigma strip. Will it be also include in the next hardfork?

Thank you,

1 Like
5

They aren’t a hard fork but is intended to be in as soon we can. Sigma is already deprecated so we can skip all the heavy checks of Sigma since there will be no more Sigma spends/mints.

1 Like
6

@reuben all seems good from my point except this one:

**Increase Spark spend to transparent limits per block
**
The limit shouldn’t be 30,000 but more like 500,000. You can’t make high value transactions with Firo it’s literally shooting ourselves in the foot. If Firo grows and people start using it and the price rises the 30,000 is really going to annoy a lot of serious whales. No such problem exists with XMR.

Before anyone says send it in multiple transactions - stop. This isn’t a serious solution. It also impacts the privacy of transactions as the timings can potentially be linked. Increase of this limit multiple times is very much needed but 30,000 isn’t enough by a long shot.

7

500,000 defeats the purpose of a limit in the first place though but we are increasing it to 50,000 first with your feedback.

2 Likes
8

Hi!

Is the hardfork still planned for around septembre 25? Is everything going well on testnet?

Thank you,

9

May be pushed back a bit some of our tests are failing a bit so want to get it right! Sorry for the delay!