Hi,
I want to run multiple masternodes on my local machine to avoid paying monthly fees from hosting providers.
The problem is that i only have one IP address that is not even dedicated.
I would like to know if it is possible to run a masternode behind an Hidden Onion Service ? (in the firo masternode list, i don’t see any onion address)
If yes do you have any documentation ?
Or do you have any other solution ?
Also thank you for this amazing project.
I think it miss some marketing/advertising(paid or free) to acquire a bigger user base.
When looking at the news, it seem like its mostly present in SEA but not so much in Eastern countries. Crypto will regain attractivity during the next months, so it should be the ideal moment to do it.
One problem is that being listed on Binance is amazing, but they delisted privacy coins in many countries, which mean that it doesn’t benefit all of the binance users. But many other "offshore " exchanges still resist, and its a very good entry for new users.
Most exchanges ask for money to get listed ? or some are free ?
What does the community can do to improve Firo user base and ranking ?
I run my masternodes using provider allnodes.com . It is easy. Just pay for basic hosting 5$ and easy to set up and I can connect my masternodes to my telegram to easy monitoring masternodes I run. When I got reward, there is notification I got from the bot telegram who connect with my masternode. I can run many masternodes with easy set up and monitoring and make all same for payee address.
5$/month is way too much. That’s 60$/year, per 2000$ invested. Its like getting 3% fee per year on your whole capital.
It might sound nothing but if you run 10+ masternodes thats a lot of money going out.
I would prefer to find a way to host myself to get that 3% back.
Anwar, I heard that from @reuben (the founder of Firo) himself.
@Oscar77 , I was wanting to do that same thing as you on my home network. I don’t have a dedicated IP address but I wanted to run multiple masternodes. I was informed that this is not possible and it is a feature of FIRO, not a bug.
To be honest I think it’s a good thing because it prevents centralizations.
Can you imagine if folks could host multiple Firo masternodes on a single IP address? That would cause massive concentration of block rewards to a single IP address. It would discourage small players that could only afford to stake a single masternode as we wouldn’t wins as many rewards.
Hence by setting the rule “1 Masternode, 1 IP address”, it improves the overall network decentralisation and makes it more fair for FIRO masternode maintainers because it created an even playing field.
I started on allnodes, but now I have everything on VPS for $4.5 each.
Never had problems with allnodes, other that they sometimes dont have availability for the $5 hosting.
The setup really isn’t that hard, just follow the instructions.
The thing is, you can also run masternodes for other projects alongside firo, so I can split that cost in 2
A cheap VPS might be able to run 3 or 4 different nodes on 1 IP (each for a different coin) before you run out of ram/cpu, but you may not have enough disk-space included to do so.
I limit them to 2 projects per VPS/IP, works well for me.
With the halving of firo comming up, if price doesnt pick up, running a masternode will be more of a hobby than a way to make some passive income.
Need to support the project, getting paid to wait is/was a nice bonus tho.
remember IP address are an attack vector even though now 1 IP == 1 Master-node for decentralization as said by others
for future i bet more improvement of node privacy by tor i2p and veilid hidden networks will be used more along with noise protocol + dandelion++ already present
One consideration is how reliable these tor/i2p networks are and how much latency it adds. Dandelion++ already adds quite a bit of latency to transactions.
If we are continuing to use ‘Instant-send’ as secured by LLMQs, our developers have expressed that they are concerned how reliable these instant locks are or whether these masternodes will be able to contribute to instant locks in a timely manner if they’re behind tor/i2p. We originally wanted to use Meson mixnet but that project appears to be discontinued so we have some initial implementations and integrations with Nym.
The concern with Nym is that there are several configurations for it, one which offers little added privacy and the other which has much more delays but much more privacy. Another concern is the future requirement to have NYM to use the network which adds a lot of friction.
I believe perusing more Tor integration in Firo is a must, if it wants to stay in the privacy currency game.
Even if ditching Dandelion++ is a prerequisite, since Dandelion++ does not really add much privacy, tor does.
Registering a Firo masternode via onion hidden service should be added to the roadmap asap. At least as a long term goal, even if it takes years to implement.
Having a registration tx for ever on chain with the IPv4 address is a really bad idea. I believe every user should have the ability to run a masternode, even in oppressing regimes. The current situation with IPv4 only does not allow that. Enabling someone to run multiple nodes because of this might not be ideal, but its the price to pay for real privacy.
PIVX for example achieved masternodes via .onion, and it has faster block times, why can’t Firo? The latency can’t be that bad?
Thanks i’ll have a look at how PIVX does it but do note that PIVX doesn’t have their instant transactions working at all so I’m not sure if their masternode quorums are working…I may be wrong on the masternode quorums but recently checked with them that private instant transactions don’t work.
It would be nice to clear up a bit, what is wanted for firo. I am just one guy with an opinion
I would consider this Firo MN IPv4 setup as a big issue considering its supposed to be a privacy coin. What is your and others opinion on this?
Regarding instant, how instant do we want it to be? Is there a technical reason that its impossible over tor? Or would instant become 15 seconds instead of 5 seconds. What are the actual trade-offs?
Also, maybe a step in the right direction would at least be to change the way a masternode is registered, to omit the IPv4 address from the TX (that stays on the chain forever) and exchage the IPv4 address via the p2p network in some form of DHT, or for example Ethereums “EIP-778: Ethereum Node Records (ENR)” or something similar…
Sure i totally agree that having IPv4 setups are an issue though it’s usually hosted on VPSes but totally undersatnd. It’s not actually the ‘instant’ transactions but there needs to be a reliable connection between the masternodes to form quorums which involve communication between them. The way the masternodes communicate with each other should be relatively quick to make sure these quorums form reliably since they perform key functions in securing the network. Without the quorums, it falls back to pure PoW which has significantly less security.
We’ll need to do some simulations with several hundreds of nodes in the TOR network to see if they can communicate with each other reliably.
I’m all in for testing it out, but where to begin?
A hybrid clearnet and tor model like pivx uses would be good to test. If the .onion nodes will have issues they will just get banned, which is not such an issue(?).
I guess the registration TX should allow onion v3 addresses? But also Tor has some issues with firo, even after the last update (which mentions tor to be updated), there is no way to get a .onion address in firo, I opened a seperate topic here: Firo and Tor (.onion address)
Until this works reliably there is no way forward with this idea anyway…
So we had a discussion with our developer team on this. The forming of quorums requires relatively fast communications between large groups of masternodes. Having them on .onion addresses introduces a lot of latency and reliability concerns. Tor generally adds routing latency (often hundreds of milliseconds up to a few seconds per message).
Tor circuits can be less stable than direct connections – they might break and need rebuilding, especially if running for long durations. LLMQ members are supposed to keep connections open throughout the quorum’s life (which could be hours or days). An onion service that goes down or loses its circuit will temporarily be cut off. During DKG, if a node disconnects for even a single phase, it will miss required messages and be dropped. During signing sessions, if a Tor-connected node’s circuit resets, it may fail to share its signature in time. Frequent disconnections could also cause repeated DKG failures for that masternode.
In short, running masternodes as Tor hidden services boosts privacy (hiding their IP addresses), but it injects latency and fragility into the quorum system. DKG and threshold signing are interactive protocols with strict time windows; Tor nodes are more likely to miss those windows. The immediate impacts could be more frequent quorum member dropouts during DKG (those nodes would get PoSe penalized), slightly longer wait times for InstantSend locks or ChainLocks to finalize, and a need for larger safety margins in phase timing.
The quorum protocol was engineered for low-latency, high-reliability communication, and using Tor requires careful consideration of those trade-offs.
Why not IPv6? An IPv6 node cannot communicate with an IPv4 node and right now the adoption of IPv6 is still only about 50% (although it’s rising). It’s the reason why Dash still hasn’t moved to IPv6 masternodes yet as well.
Your concerns are well noted though and we are trying to think of alternative ways to improve privacy for masternode hosters though to me, the best defense right now against this is to find VPS providers that respect privacy. Similarly, masternode hosting services typically do not require you to give up your identity or payment details and often accept FIRO as well which means that there are still ways to anonymously host FIRO masternodes. This trade-off ensures a very fast and robust system while privacy can still be maintained if used with the right infrastructure. Remember masternodes are never meant to be hosted on your home computer.
We will still of course allow regular nodes (and even masternodes) listen on .onion addresses just that they cannot participate in quorum formation.
Thanks for looking into this. I still believe its worth looking into this more and testing it in the real world.
With a clear disclaimer that the chances of getting pose banned are much higher maybe, its up to the node operator if he wants to take that risk. I am up to take that risk and test things out if we get to that phase one day.
My guess is that latency for .onion would not be so high if there are many normal IPv4 nodes that also have an .onion address. I see the problem your developers see, if a .onion only node is connected only to IPv4 nodes, that means the connection has to go out through a tor exit relay - and exit relays are usually overwhelmed and are bandwidth bottlenecks. Not to mention there can be ddos attempts coming from tor exit relays, which makes the situation even worse. But a direct onion to onion connection, does not go through en exit realy - it stays inside the tor network, so its a different bandwidth and latency situation.
So like I said before, once the .onion addresses are resolved and stable with firo, maybe we can start playing with this idea a bit more.
What are your thoughts on changing the registration TX, so it does not contain the IPv4 address? This could be addressed sooner than the tor situation. Even if you hire a VPS, you are usually still exposed in some way, the hosting provider might be obliged to tell a state (that might be ok today, but might go crazy totalitarian in five years) who was the person that had a masternode registered five years ago on the IP x.x.x.x. Holding this forever in the chain just doesn’t feel right…
+1. Note to those reading it’s about masternodes not normal nodes there is no information there.
@mus_tard is completely right and I agree with him. Latency is a small price to pay if the project offers privacy all around not only on the transactions side but the network side too. I’m not only talking about masternodes behind Tor/I2P but seed nodes, other peers, the entire network being able to fully live and breathe. It’ll help the censorship angle too for people. @reuben
What do others think of this? Should we poll if privacy is more important than latency? In my mind privacy is worth sacrificing some seconds for transactions to go through. Voice your thoughts please.
Anwar, I heard that from 
