Many of you were there on Tuesday, jostling for virtual space in the Discord Stage, but for those who didn’t make it, or who were late (ahem, @happybeing), here is a summary of @bux’s chat.
With updates to get in and marketing to align, Wave 2 will officially start on July 12th, as the new version of network will then be live (yes, we know, we know, but better to get off on the right foot than have to walk it back).
Any nanos earned before that date by Wave 2 participants (via referrals) will count towards their first leaderboard balance (usually rewards are those earned over a 7-day period). A table of boost (specifically referral) rewards will be published this week, so it’s clear for everyone ahead of time how they work (particularly relevant right now for Wave 1 folks who are sharing in the prize pool).
When Wave 2 is able to start (i.e. when the wave is full), the prize pool for Wave 1 will be doubled (and retro-fitted based on previous ranks/allocations). When Wave 3 fills, Wave 2’s prize pool will also double. Wave 3 will be made up of 1,000 participants. There may be other waves after that too.
As of Tuesday, Autonomi was supported by 66,318 nodes . Each node is 5GB, 3GB of which is dedicated to logs (the joy of beta) - thank you to the increasing number of you who have shared those on request - makes a huge difference to have this type of information to hand!
Speaking of logs - here’s where you will find them
Windows
Node: C:\ProgramData\safenode\logs
Launchpad: %AppData%\safe\launchpad\logs
macOS
Node: ~/Library/Application\ Support/safe/node/[node]/logs
Launchpad: ~/Library/Application\ Support/safe/launchpad/logs
Linux
Node: ~/.local/share/safe/node/[node]/logs
Launchpad: ~/.local/share/safe/launchpad/logs
As well as fixing some bugs (notably the ARM build), the next release will strictly limit the communication between nodes and clients using the same public keys for different functions (e.g. payment forwarding, network royalty payments, etc). We believe this is responsible for some of the spend anomalies we’ve seen.
We’ve pared down the messaging, meaning there will be reduced base traffic (bandwidth) for nodes and also better upload performance. This will result in a higher rate of nano distribution. We expect users who run a smaller number of nodes to receive nanos more often. Potentially this also means we will be able to identify users with node issues more easily.
We’re now exposing more metrics from the node, including: the number of connected peers, number of peers in the routing table, the number of open connections, and the node’s uptime. This will allow us to identify the issues users are facing more effectively.
In safenode-manager
the nat-detection
command can now be run without specifying the server to connect to. A default list of servers is provided. And with Node Launchpad the correct primary storage dir (/
) will now be selected on Linux and macOS. The Launchpad and node versions will also now be displayed.
Finally, we know some of you are having problems with nodes not earning nanos or the wrong earnings showing up, so to help with this we’ve set a way, via a discord bot, to be able to log an issue and to submit your logs so the engineers can take a look and hopefully find a fix.
We hope to be able to switch over to the new network on Monday next week. There will be a period of no data uploads on both networks for 24 hours (or maybe a bit longer) to help ensure the transition is as smooth as possible and that everyone has a chance to join. It’s going to be worth the wait!
Thanks as ever for all your help and feedback . We’re getting there.
General progress
@anselme and @roland have continued to work through scenarios to ensure that spends cannot be exploited, however devious the attacker or unusual the circumstances. The basic approach is to check each spend and its parents. A spend with no parents or a double-spent parent is invalid. However, we don’t want this invalidation to become an attack vector, where a malicious actor can replace a valid parent with an invalid one in order to poison its descendants. This would be a tricky attack but it’s theoretically possible and we have a fix pending to ensure it cannot happen.
@bzee has put in a fix for ARM builds to address the issue of rewards not being registered properly, building on investigative work by @qi_ma. He’s also been looking at re-forwarding of rewards and investigating the status of Libp2p AutoNAT v2
, which should bring connectivity improvements to home nodes but sadly does not yet seem quite ready for primetime. @bzee also helped out a community member who has received no nanos using a VPS. He found the default firewall setting was to blame and the nodes weren’t reachable.
@chriso Has been beavering away on the next testnet release and creating some documentation around that. As we head towards our planned launch, documentation has become a key priority for the team.
@shu is also labouring in this territory, building dashboards for our internal use. He has just implemented a system to efficiently collect data from multiple testnets that can be easily scaled as required, allowing comparisons between experimental and live networks.
@mazzi has deployed a new audit server snapshot collector which now supports multiple audit server addresses. We plan to roll this out next week. DiscordBot users will have noticed the new /leaderboard
and /referral
commands, and @mazzi has fixed a bug where users running the /rank command were shown their weekly nano count instead of their overall count.
And @qi_ma Investigated the non-earning nodes issue raised by the community. This turned out to be due to a mismatched public key. We now need to make changes to the auditor to complete the fix.