I saw your create validator tx hash. The fields are correct. It’s an explorer issue. So not to worry about your validator. We’re currently fixing the issue now.
As for the 100fx as mentioned earlier, 100fx is the Min self-delegation. The reason why your validator showed 0 voting power on the explorer is because past a certain decimal place, it doesn’t show so that too is nothing to worry about too. Your validator voting power should be non-zero once you’ve fulfilled those requirements
This is a great contingency plan! But just to avoid any kind of issues, here are some of my suggestions or notes:
- Always make sure you don’t have both instances with the same validator keys running at the same time. Make sure the other is completely shutdown before booting the other.
- You may refer to here for more best practices
- Do a dry run to cover all your corner cases on the testnet
Does anyone have any experience setting up a sentry node system for security with the current deployment? Anything I should be on the lookout for?
Congratz everyone !
Our French node will be up and running this week-end normally !
I just want to add some extra security layers…
FRENCH AND ROMANS LEND ME YOUR EARS!
I have created 3 separate threads for Mainnet Validators.
f(x)Core Mainnet Validator Updates
General Discussion and Enquiries
This thread will still serve as the main thread for any Testnet related questions. So lets shift the discussion over!
The recent snapshot for Testnet (from today, which is 29th Nov) consist full path of ‘/home/ubuntu/.fxcore/’ when extracting (in my case it’s extracting into the wrong path now), the previous one didn’t have this, and before that had it opposite again. I haven’t tested mainnet files, but possibly it has the same issue.
Would be possible to make the snapshot more consistent? I prefer the format that was previously (without path assumptions), so the extract can be done directly into data/ (without moving unnecessary files).
the snapshot is a compressed
data directory. so you should be unpacking it into .fxcore/ directory.
I know it suppose to be a data directory, but the latest testnet snapshot has absolute paths in it. Is this going to be addressed (you didn’t mention that)? And it isn’t possible to unpack into .fxcore/, because it’ll generate “~/.fxcore/home/ubuntu/.fxcore/data” dir instead. My scripts rely on these snapshots and consistency paths (and if the paths keep changing, I’ll need to setup my own snapshots). I’ve checked, and mainnet snapshot is fine. Can you do how it was previously for testnet (without hardcoded ubuntu user)?
Will we have a live update in testnet? I would like to see how it works
Yes! we will have a live testnet update very soon, so for those of you who dont already have a fully synced node on testnet please do so soon!
let me get back to you on this and also on on your other snapshot questions
The home/ubuntu being part of it is really annoying.
You have to extra it and then delete ur own data folder inside .fxcore and then copy the one out of home/ubuntu/.fxcore/data and paste it in the actual ~/.fxcore/data or wherever they stored it.
we will change that. you should see the update by next week. if it still isnt fixed, do let me know
I think fx wallet need costumize themes
So people can choice themes they love
@Richard I am want to be a validator to, currently going over the materials.
Hi @Richard !
I eventually managed to get the node monitor working fine (it was just a matter of source that was designated as “Prometheus” instead of “prometheus”, thus driving me crazy…).
What’s the formula to compute the uptime of my node using Tendermint ?
Do you have any idea to transform a validator address in this format “fxvaloperaaabbbbcccdddeeefff” to the “missed_blocks” validator address format (hexa) ? → I’d like to compare my uptime to others…
Which (default fxcored) ports should we forward on a local network to have a node working ?
New proposal: Making f(x)Core EVM compatible for Testnet
The process will be as such:
The team will initiate a proposal on 9 DEC 2021 at 11:00am (GMT+8)
For Testnet, the proposal voting period is 48 hours.
By the end of the voting period, a tutorial on how to upgrade your nodes to be EVM compatible will be up
The nodes will need to complete upgrading by 13 DEC 2021, 10:00am (GMT+8) i.e. block height 408000
There will be another proposal on 13 DEC 2021, 10:00am (GMT+8) to confirm this change and to initialize EVM compatibility.
The nodes who have not upgraded by then will not be part of the consensus and if your validator node experiences too long a downtime, it will be jailed and slashed (more on this you may refer to here “What are the slashing conditions?”)
This entire process will be very similar to how an upgrade will be on the Mainnet so do try it out on Testnet!
the update is just after proposal approve right ?
yes correct. it has already passed governance so you can start upgrading your node