Update 29 June, 2023

A good week of bug fixes and tweaks in preparation for our next testnet: NodeDiscoveryNet, which will look at how nodes find each other on the network.

We’ve found a cause of excessive memory usage. We thought that nodes were only sending messages to the eight closest nodes to them, whereas they were actually sending messages to 20 nodes. We’re not completely sure what all the knock-on effects were, but for any call where we were assuming a close group there were a lot of wasted messages - which translates to increased memory use and may well have affected data replication too.

Because we run lots of nodes per machine on the testnets we have little tolerance for the unexpected. We did see some nodes dying unexpectedly, and that increased memory use is a possible reason.

The other place we saw node death was around replication - this had to do with the default Kademlia/libp2p processes adding crap to the routing table, including nodes that are behind NAT and can’t be reached. This meant that nodes thought they were connected to the network but actually weren’t - a likely cause of the ‘I’ve joined but I have no data’ issue, and also of nodes dying unexpectedly. So, now we are manually adding entries to the routing table instead of relying on Kademlia to do it when a connection is detected. Sometimes you just have to roll up your sleeves and do it yourself. :roll_eyes: It may be that nodes which find themselves stuck in the netherworld will need to restart to properly get onto the network, but that shouldn’t be necessary, we think.

General progress

@Chriso has spent the week working through UX improvements to the installation and logging process, thanks to feedback from the last testnet.

@aed900 is working on a batch file to extract counts of significant log messages/errors from testnet node directories, similar to what @Shu has been doing to create his graphs. He’s also working with @Chriso in making the testnet tool more useful, with the ability to kickoff testnets via the github UI coming soon.

@Anselme has pretty much finished implementing PUT and GET operations and replication for registers following his previous work on chunks and spends. Big news as it sets the infrastructure stage for DBCs! He’s also been refactoring and rationalising the related crates to help with future work here.

@bzee is stripping out our custom code for managing communications with peers (dialling in the jargon) without requiring an ID, replacing it with the native libp2p functionality that prevents dialling a peer if messaging has already been initiated. He’s also changed our APIs so as to not need a peer ID.

Together with @joshuef, Benno has also been looking at manually inserting entries into the routing table rather than having it happen automatically. That process, we have noticed, sometimes inserts junk (see above) with unfortunate side effects.

@qi_ma is working through various scenarios about who verifies what when a client pays for chunks. As always, we want to load as much onto the client as possible, but not to the extent that it can cheat the system.

And @bochaco and @roland are removing bulletproofs from the DBC code, and integrating that into payment processes. That’s a step we feel we can now do without with the significant benefit of simplifying other processes (and one of dubious benefits as store cost will be known, effectively unblinding large swathes of the transactions on the network).

Useful Links

Feel free to reply below with links to translations of this dev update and moderators will add them here:

:russia: Russian ; :germany: German ; :spain: Spanish ; :france: French; :bulgaria: Bulgarian

As an open source project, we’re always looking for feedback, comments and community contributions - so don’t be shy, join in and let’s create the Safe Network together!


Fantastic progress. Certainly seems to be coming together well. Looking forward to the next testnets and particularly when payments / DBCs are being integrated!


Second ! Yupiiiiiii
This is honey on my heart, great news, great work by the team! :ok_hand: :blush:


excellent update- thanks to all for your efforts.

It all seems to be coming together now.


Is the routing table crap a bug in libp2p?

It’s great to see all these pieces coming together, the regular test networks and how these are feeding back into development.

EDIT: @joshuef I do plan to reply to your q about logfile messages. Update: done here.


Couple of wee issues in libp2p but we are pushing boundaries there. No great worry as they are getting there with QUIC hole punch etc. So they are making good progress too.


And at what stage is the problem of double spending in offline transactions?


I’d like to know more about this. Will this compromise anonymity in any way? Make auditing easier? Not sure I fully understand the cost/benefit of this.


It’s the time of the week agaaaaain, good work @maidsafe!


Thanks again to the entire Maidsafe team for all of your hard work! :horse_racing:


Well done to all the team.

Really really looking forward to the next test net. feels like things are just falling into place.


I’m wondering what @JimCollinson is up to these days… :thinking:


I’m all about the launch strategy… much going on!


Well done all! Keep going, very close - can be done this year :smiley:


Offline tx are an issue unless you really spend the DBC you were given. It’s very much like being given a btc wallet plus private key. I am not really a fan of it right now, but amongst trusts friends it may be ok.

There were a few considerations

  • Ease of code (much simpler now)
  • So many transactions will be store data (so unblinded) that in fact blinding only the few folk spend really did not buy as much as we would hope. With a few only blinded the auditing would quickly expose people.
  • Both systems are auditable, but now that is slightly simpler (although commitment and bulletproofs were auditable where we could tell input == output)
  • A tough one for many of us, regulators and exchanges. They seem to be closing down on privacy coins and that is an issue.
  • transaction per second, large increase there, back to the 19000 or so tps (per close group) code now.

So we are left with one time keys and key derivation paths. This is not a bad place to be actually.


If it’s the case that anonymity is threatened or hopefully at most just slightly tuned back, could the DBC code be made to allow for third party bulletproofing or anonymizing that is more effective than Bitcoin anonymization?


Wonderful update team ant! Thank you for your continued efforts. :beers: :partying_face:

Just a hunch, but I suspect that third parties building on Safe could create mixers and/or extra hops (Safe VPN’s) for anonymity.

If the core Safe codebase doesn’t violate rules, then will be harder for govs. or big tech. to justify blocking it … but with third-party Safe-sites that can host apps that allow things outside the scope of the core code, then most anything seems possible.


Okay, thinking of it this way… if accounts can be fully anonymous then the DBC transactions aren’t tied to an identity so you can semi effectively be anonymous in that way. An option for third party, open sourced and verifiable bullet proofing, maybe even with multiple outputs to generated private accounts under your control would be a good addition.

I think the fundamental of privacy of the coin shouldn’t be compromised but what can appease regulators and exchanges to not be labeled or pigeon holed strictly as a privacy coin could be good for overall adoption. Having the privacy as an option is must, imo. Designing to foster that should be highly considered.


Getting closer and closer, I think we can all feel it. Great work team!