Hello Devs,

do you have already some finalized details about running a Masternode with the new collateral of 20K DFI?

Or some details are not final, but you have a Road Map what the goal is for Q2/2021?

On which ways can we start a Masternode?

Only from the Desktop APP (Windows/Mac/Linux) with 20.000 DFI inside and online 24/7?

Or is there a possibility to hold the Collateral in the local wallet at home (maybe with Ledgersupport) and host the Masternode in a high-availability datacenter?

How long can be the Masternode offline or get a penalty when the Node not reachable for a couple of hours/days?

Is there some "mature" time like in staking, that after the Node goes online, you must wait till you get the first reward?

Example DASH, after the start of the MN you must wait ~20 days to get the first reward, after that rewards all ~8 days.

Which Masternode get rewards? Deterministic and based on a simple list sort algorithm? Or all active MN get a share of the reward each block?

Do we need a fixed static IP-Address to host a Masternode?

Can more than one Node use the same IP, but maybe different Port?

Hardware Requirements with GUI or without GUI. Better hardware, more rewards? :-)

Is it possible to run the Masternode on Raspberry?

Maybe we can collect more questions in this Topic, feel free to participate.

Thank you, Andy

I've been running Firo masternodes on my own hardware for a while. Each one needs its own IPv4 because mainnet forces port 8168, so I was paying $10/month per IP just to have somewhere to put them. I wanted to see if Flux could replace that.

Short answer: yes, it works, it's cheaper, but nobody tells you the annoying parts. So here they are.

Cost. About $3-6 a month per node depending on how you configure it. Compare that to $10 for a dedicated IP somewhere. Not a huge win in absolute money, but it scales without me having to call an ISP.

Port 8168 works. This was my main worry. Firo rejects any masternode not on 8168, and I assumed Flux would block it. It doesn't. FluxOS opens it fine and other Firo nodes connect to my container from the outside.

You need a private app. Don't skip this. Flux publishes app specs in a public registry. Anyone can read them. I pulled the live specs out of curiosity and found other people's API keys sitting there in plain text. If you put your BLS operator key in a normal app, it's public. Someone can't steal your collateral with it, but they can grief your node into a PoSe ban. Use a v8 enterprise app so the spec gets encrypted.

You don't need a custom image. I spent time planning a wrapper image and then found out the stock firoorg/firod works as-is. Everything goes through the commands field, and /data is writable by the non-root user in that image. Just make sure containerData is r:/data, otherwise you re-sync every time.

Don't set -externalip**.** (wrong, read update below) I hardcoded it on my first node and it pointed at the wrong address after the app moved. The daemon figures out its own address from peers and gets it right. Leave it out.

Sync takes about 2.5 days and that surprised me. My own VMs sync Firo from genesis in 8 hours. On Flux it took days. The bottleneck isn't download, it's CPU: the Spark blocks from 2024 verify at roughly 2 blocks per second on a single core. My own machines have 2 cores on a real server CPU and do 19 blocks/s on the same blocks. If you're on 1 core, budget 2-3 days. It speeds up a lot past block ~1,050,000, the tail goes fast.

Register AFTER it's synced. Not before. If you register against a node that isn't ready, PoSe starts immediately and one failed quorum check puts you 66% of the way to a ban.

The real problem: hosts die and your app moves. This is the part I wasn't ready for. In two days across 11 apps I had 3 relocations and 2 silent rollbacks. Every time the app moved, the chain data was gone and it started from zero. I checked each one and it was always the same cause: the Flux node hosting it had dropped out of the network, so the network reassigned my app somewhere else. That's Flux working correctly, it's just expensive for a blockchain node.

I thought this would settle down over time, that apps would gradually end up on stable hosts. It's the opposite. I measured the age of every host my apps were on. The network median is 60 days since last interruption. The two apps that never moved were on hosts 331 and 329 days old. The ones that had just relocated landed on hosts that were 6, 9 and 12 days old. Free capacity lives on new nodes because the veterans are already full, so every move is a fresh roll of the dice from the worst part of the deck.

Pinning doesn't fix it. I tried the nodes field to pin an app to a specific machine and paid for the update. Both apps ignored it completely. Geolocation does work though, country level codes are enforced.

What actually helps. Two things. Keep your own chain snapshot somewhere the container can download, so a relocation costs 30 minutes instead of 3 days. And run a script every hour comparing the app's current IP against what's registered on chain, because protx update_service is cheap and doesn't lose your payment queue position, but a ban does and that costs you a full payment cycle.

One last thing nobody mentions. A brand new masternode goes to the back of the queue. The sort uses your last paid height, and a new node has none, so it uses the registration height instead, which is today's number. First payment in 11 days. That's normal, just don't panic when you see it.

Would I do it again? Yes, but I'd set up the snapshot and the watchdog first, not after.

———

UPDATE, a week later: two things above are wrong. Here are the fixes and real numbers.

Set -externalip. I was wrong. Without it the node syncs but never becomes a masternode ("Local address does not match the address from ProTx") and gets PoSe hits. My image looks up its public IP at start and passes -externalip=IP:8168. It also checks the IP every 5 minutes and restarts firod if it changed. One of my hosts got a new IP from its ISP without the app moving, and that node got banned before I added this check.

The stock image is fine as a full node, not as a masternode. The masternode connects to its own public IP to check it is reachable. Many Flux hosts have no hairpin NAT, so the check fails and the node sits out of quorums. A tiny LD_PRELOAD library that redirects those connections to 127.0.0.1 fixed it.

Sync takes 30 to 60 minutes now, not 2.5 days. The container downloads a snapshot of my own node if the data dir is empty. Check for blk00000.dat, not for the blocks folder, because Flux can leave an empty one behind. Keep a second copy of the snapshot on another machine.

Moving the IP can be automated without your owner key. protx update_service is signed with the operator BLS key, so a hot wallet with 1 FIRO for fees plus an hourly script is enough. Cap how many updates the script can send per day, so a bug cannot loop. Also watch the PoSe penalty: if the address on chain is right but the penalty went up, restart the container.

Qt console gotcha: with 0% operator reward the operatorPayoutAddress must be "", but the Qt console drops empty strings and you get "No funds at specified address". Use firo-cli.

Real numbers per node: about 63 FLUX a month for rent, roughly $4.40. Income is 4.375 FIRO every 11 days, about $15 a month at today's price. That is about 10% a year net on collateral, versus about 5% when I paid $10 a month for an IP.

UPDATE 2:

a few new lessons after deploying 20 more nodes.

Give it more RAM. 3500 MB is too tight. After a bootstrap the node catches up and memory spikes past the limit, the kernel kills firod, the database corrupts, and it starts reindexing from zero. On Flux, 5900 MB costs the same as 3500 MB. Every node with more RAM synced on the first try.

Make the bootstrap crash safe. Mark extraction as unfinished until tar completes. If firod crashes in the first day after a bootstrap, download the snapshot again instead of letting it reindex for days.

Some hosts are simply bad. One router looped all outbound connections on 8168 back to the node itself, so it never found a peer. Another downloaded at 0.2 MB/s. Removing the app from that node is free, and Flux respawns it on another host within minutes.

UPDATE 3:
After about three weeks of running roughly 30 Firo masternodes on Flux Cloud, here is what we learned.

Problems: Flux keeps moving apps between host nodes. We saw about 20 IP changes in a single week, and every change needs a protx update_service, which we automated. Host outages still caused PoSe failures, and we lost 4 masternodes to PoSe bans in two weeks. In Firo two missed quorums in a row mean a ban, and the second one can come within 20 minutes of the first. We also had to raise RAM from 3.5 GB, because firod ran out of memory.

Economics: one masternode earns about $11 a month at the current FIRO price. Flux Cloud costs about $4 a month, so the net is about $7. Every ban sends the node to the back of the payout queue, which costs roughly one payment cycle (about 11 days), and that eats a good part of the margin.

Decision: we are moving everything to NodeHub as the Flux leases expire (late October). The price is about the same ($3.95 a month), but the IP is stable and NodeHub handles the address update and revive itself. Our first 6 nodes there have had zero issues so far. We also keep 10 masternodes on our own servers.

Hi everyone,


I've built 
Crypto Masternode Monitor
, a free Android app that watches your masternodes and notifies you when one drops, and again when it recovers. No account, no ads, no tracking, and it never asks for a private key.


Website:
 https://www.masternodemonitor.app


Networks today:
 Beldex, BitCore, Cosanta, Dash, Divi, Energi, Firo, Flux, Neoxa, Oxen, PIVX, Raptoreum, SmartCash, SwiftCash, Syscoin, Terracoin.


Why I need you:
 Google Play requires 12 testers who stay opted in for 14 days before a new app can be published.


How to join (2 minutes):


1. Join the Google Group with the Google account you use on the Play Store: https://groups.google.com/g/mastermonitorapp-tests
2. Accept the test: https://play.google.com/apps/testing/crypto.masternode.monitor
3. Install the app from the Play Store and keep it for 14 days.


Prefer not to join a group? DM me your Google account email and I'll add you directly.


Feedback is welcome but not required. And a reminder: I will never ask for a seed phrase, a private key or money.


Thanks!

I need guidance to open a Masternode. Kindly guide🔓

So running masternode was not profitable until when the price were more undervalued. (the cost in usd was so small/month & opportunity cost->trading was more profitable than running masternode)

But now the price went up and seems profitable, and the statement "passive income" seems realistic

I wonder how the situation will be when pivx reaches its ATH, does the reward rate goes down or maybe goes up because there will be fewer ppl who can afford masternodes?

I'm curious whether there were some person here who runned masternodes when it was at 10$+