NoClientGossipNet [22/11/23 Testnet] - [Offline]

In the past couple of testnets we’ve been verifying RoyaltyPayments have been processed and are being received at maidsafe controlled nodes.

That part of the testnets has been successful, though they haven’t been particularly usable for very long.

We’ve been debugging this, looking at memory issues in nodes etc. The last testnet had far too much replication, which has been dialed back. And we’ve been looking at an excess of connectivity…

It appears that clients may well have been inserting themselves into the gossip portion of the network, and so adding to the load for each and every node for each and every royalty payment.

Here we want to test out this theory with clients that are now refusing themselves from gossip. We’ll be evaluating the load at nodes as we progress.

In addition to this, there are a few other notable tweaks since the last testnet:

  • the default batch size has been increased (which should use a bit more client mem, but speed up uploads some)
  • royalty payments are now 15% of storage cost
  • replication has been dialed back from the previous excessive rate

If you’re running a node, memory looks to be in the 200-300mb range.

And we’ve a sample 5gb file uploaded:

safe files download ubuntu.iso 3911604a5798de6e7f591a6c9e44097e9f4979c0a1ef439d02d17494d7f41886

Network Details

Node version: 0.98.25
Client version: 0.86.13
Faucet url:

We have 101 droplets running a total of 2001 nodes. One droplet has 4vcpu and 8GB of memory.

If you are a regular user, see the ‘quickstart’ section for getting up and running.

If you are a first-time user, or would like more information, see the ‘further information’ section.


If you already have safeup, you can obtain the client and node binaries:

safeup client --version 0.86.13
safeup node --version 0.98.25

Run a Node





Check local node’s reward balance

Your local node’s peer id will be printed to the terminal on startup with an example command). (You can also retrieve this from the node directory.)

safe wallet balance --peer-id="<local-node-peer-id>"

Connect to the Network as a Client


safe wallet get-faucet
safe files upload <directory-path>


safe wallet get-faucet
safe files upload <directory-path>

To do this with non-default concurrency or batch-sizes (along with SAFE_PEERS set as above):

safe files upload -c 10 --batch-size 40 <directory-path> 

10 and 40 being the integer values you want to set for each

Further Information

You can participate in the testnet either by connecting as a client or running your own node.

Connecting as a client requires the safe client binary; running a node requires the safenode binary.

Obtaining Binaries

We have a tool named safeup which is intended to make it easy to obtain the client, node, and other utility binaries.

Installing Safeup

On Linux/macOS, run the following command in your terminal:

curl -sSL | bash

On Windows, run the following command in a Powershell session (be careful to use Powershell, not cmd.exe):

iex (Invoke-RestMethod -Uri "")

On either platform, you may need to restart your shell session for safeup to become available.

Installing Binaries

After obtaining safeup, you can install binaries like so:

safeup client # get the latest version of the client
safeup client --version 0.86.13 # get a specific version

safeup node # get the latest version of the node
safeup node --version 0.98.25 # get a specific version

safeup update # update all installed components to latest versions

When participating in our testnets, it is recommended to use a specific version. In our project we release a new version of the binaries every time we merge new code. This happens frequently, so over the lifetime of a testnet, many new releases will probably occur. So for participating in this particular testnet, you may not want the latest version.

The binaries are installed to ~/.local/bin on Linux and macOS, and on Windows they go to C:\Users\<username>\safe. Windows doesn’t really have a standard location for binaries that doesn’t require elevated privileges.

The safeup tool will modify the PATH variable on Linux/macOS, or the user Path variable on Windows. The effect of this is that the installed binaries will then become available in your shell without having to refer to them with their full paths. However, if you’re installing for the first time, you may need to start a new shell session for this change to be picked up.

Running a Node

You can participate in the testnet by running your own node. At the moment, you may not be successful if you’re running the node from your home machine. This is a situation we are working on. If you run from a cloud provider like Digital Ocean or AWS, you should be able to participate.

You can run the node process like so:

# Linux/macOS

# Windows

This will output all the logs to the filesystem, with the location of logs being platform specific:

# Linux
~/.local/share/safe/node/<peer id>/logs

# macOS
/Users/<username>/Library/Application Support/safe/node/<peer id>/logs

# Windows

If you wish, you can also provide your own path:

# Linux/macOS
SN_LOG=all safenode --log-output-dest <path>

# Windows
$env:SN_LOG = "all"; safenode --log-output-dest <path>

The advantage of using the predefined data-dir location is you can run multiple nodes on one machine without having to specify your own unique path for each node and manage that overhead yourself.

Connecting as a Client

You can use the safe client binary to connect as a client and upload or download files to/from the network.

Using the Client

You’ll first need to get some Safe Network Tokens:

safe wallet get-faucet

You can now proceed to use the client, by, e.g., uploading files:

safe files upload <directory-path>

To download that same content:

safe files download

This will download the files to the default location, which is platform specific:

# Linux

# macOS
/Users/<username>/Library/Application Support/safe/client/downloaded_files

# Windows

To download to a particular file or directory:

safe file download [directory/filename] [NetworkAddress]



If you’ve used previous versions of the network before and you find problems when running commands, you may want to consider clearing out previous data (worthless DBCs from previous runs, old logs, old keys, etc.).

# Linux
rm -rf ~/.local/share/safe

# macOS
rm -rf ~/Library/Application\ Support/safe

# Windows
rmdir /s C:\Users\<username>\AppData\Roaming\safe

If you encounter a problem running any of our binaries on Windows, it’s possible you need the Visual C++ Redistributable installed.


OK, It’s been like half an hour and nobody has said anything, so I’ll do it: FIRST!

Great thing to have a new testnet up! :tada:

Personally I’m going to focus more on the client work this time. That means uploading and downloading, and I’d like to encourage everybody on the forum to do so - even not-so-technoligically-oriented. It’s not so difficult. :vulcan_salute:

I’ll probably spin up a coupe of nodes too, but later. Actually everything is going to happen a bit later, I got to go to work now.


This :point_up_2:


Be along shortly with some nodes and a beg blag


Ok, found strange message:

“Repaid and reuploaded 223 chunks”
I’m not sure about that “Re” in conjunction with 223.

By the way, progress messages spam is still annoying.
With such fast scrolling of console it is very hard to read text messages.
I’ve found hack - it is possible to make screenshot and read it afterwards.

But it is better to make progress messages at least slower.
Or better use text rewrite features of console, like many other programs are doing.


I’m getting why more bandwidth is needed for upload - for redundancy purposes.

But why downloading 110 MB file uses 1002 MB of bandwidth?
It looks possible to download chunk from single node and only in case if it is corrupted, download it from other node.


faucet is down

🔗 Connected to the Network                                                                                                                                                        Requesting token for wallet address: 90d3f1b7721b1a82b53bf190628d1c999eacfce61bea3d0a07f9387058b6c34db461b5975c3e0832fdd2d03398afaefc...
Failed to get tokens from faucet, server responded with: Failed to send tokens: Transfer Error Failed to send tokens due to The transfer was not successfully registered in the network: CouldNotSendMoney("Network Error Could not retrieve the record after storing it: 05d2f438ac4769474f553fa17e1d2510aad25aab2ab4dd7dafc36465599460a7(7a37b954504be063f0209e7b620b18a43175aaa35a5e147be8bd0123226664e0).").


Same - was working at first though.


Beg Blag test is a pass :slight_smile:

safe files download BegBlagandSteal.mp3 80744b3d25bab269cab54e8baccf4f54f1aa01615230b99171bc3576c1ca7230

we’re looking into this


Party time, the year of the testnets continues. :tada:

Pass it on the clients cannot be gossipers anymore, all the node gossipers need to get in on this juicy deal.


i could be part of the problem the script im running to start nodes on several different vps’s get some coins at the end of the script so could have had several requests for coins hitting it at the same time


it should be tolerant to this, we’ll see though, thanks for the heads up!


thanks to at @Josh


Jeez you lot are way ahead of me!

This thread It didn’t show up for me until just now, foul play… restart, restart :rofl:


Looks like nodes are not pruning data. Not 100% sure, but they’re erroring w/r/t fullness (and proximity to the data :thinking: )

That’s probably the faucet’s issue

Not sure how we’ve not seen this before, we’ve not touched anything here recently… :eyes: