Update 22nd July, 2021

In this week’s update we’re delving into everyone’s least favourite topic – bugs. Bugs are not an easy topic to pin down because in a complex, multifaceted, cutting-edge system like Safe it can be hard to know where one bug starts and another ends. Is this bug in our code or a third-party library, or perhaps in how they fit together? Is that really a bug fix or just an optimisation waiting to happen?

That said, it is something we get asked about a fair bit, and since a major point of the testnets is to enable us track down and exterminate the wee blighters, we should at least have a go at describing the situation. So this week we’ll have a look at one of the things really has to be 100% in place before Fleming – eliminating data loss – and the fixes we’re putting in place to get there.

General Progress

@Chriso has been working away on ARM builds for aarch64, not helped by the fact that his new Raspberry Pi arrived with a duff microSD card. A replacement arrived on Tuesday so shouldn’t be too long to wait now. Thanks to @folaht, @stout77 and others for trying out the existing builds.


We’ve been making progress on anonymous transactions using Pedersen commitments and blinded values to hide amounts. More on those at a later date!


@JimCollinson has been looking at rejigging the UX flows based on the evolution of the network to include DBCs, prepaid uploads, multisig transactions and CRDT-enabled online/offline capabilities.

NRS updates

@Anselme and @bochaco have been updating the client API and Name Resolution System, tidying up the code and removing the old Map data type.

Speaking of no-longer-the-new-boy Anselme, here’s a bit from him:

Coming from a systems programming specialisation (UNIX), I’ve hopped from field to field going from blockchain to back-end programming, data engineering and machine learning. I’m passionate about computer viruses, systems programming, software security, decentralisation, machine learning and programming languages.
I like to think code as poetry, despite that, I want to code for a greater goal, for things that matter. That’s why I’m here at MaidSafe.

Eliminating data loss

It goes without saying that data loss is an absolute no-no for Safe (data vanishing from the permaweb would be a particularly bad look). Data chunks stored on Safe nodes all around the world must be able to survive churn events, local outages and Byzantine actors. Those of you who have helped out with testing (:thankyou:) will know we’re not there yet with eliminating data loss.

So what are the bugs that lead data to disappear over time? As we hinted at above, it is likely many things overlapping.

One of the bugs – fixed this week – happened on section split, where Adults trying to replicate data would sometimes communicate with what they thought was another Adult but which on split had been promoted to an Elder - and so ignored the message. Testing suggests that this one may have gone to meet its maker. Good riddance. This type of bug should be much rarer when Anti-Entropy is fully implemented. And rarer still now we have a reliable test for this.

Other fixes to tackle data loss issues have included changing the routing flow between different Adults in a section and between Adults and Elders to ensure that chunks are actually where we think they are and have not been lost due to faulty logic.

But we’ve also seen that the out of memory issue was also likely a cause of data loss. We think we’re on top of that one now, but a few questions remain. There may be more.

As you can hopefully see, these bugs are a tricky thing to nail down. They can exist in multiple places, overlap, and one can trigger another. They can be hard to reproduce, requiring specific network conditions or messages crossing over at specific times.

We’re getting there though, and wouldn’t have a chance of tracking them down without all the people who have stepped up to help with the testing. Even when they are short lived, the information the testnets provide the team is invaluable, so thanks once again for all the debugging so far!

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!



:partying_face: :partying_face: :partying_face: :rofl: :rofl: :rofl: :rofl:

What luck,

@Chriso has been working away on ARM builds for aarch64, not helped by the fact that his new Raspberry Pi arrived with a duff microSD card. A replacement arrived on Tuesday so shouldn’t be too long to wait now. Thanks to @folaht, @stout77 and others for trying out the existing builds.

Thank you!!!


Thanks team!! Its amazing so far!


My favourite kind of updates are those about bugs… wish I had more time.

?? Would a transition through new elder not help… still action but reply with a note that was an old job and I’m now an elder. Otherwise the catch-up creates an overhead and a risk of a run of elders all denying they want to help.


Thanks all for the continuing hard work everyone.

Intrigued to see Map data type getting removed. Is that being replaced by Multimap?

Does that mean we’ll have blob, sequence, multimap and tree data types to go at???

I’m fairly ignorant on the technicalities, but between multimap and tree types that sounds kind of like potential for computing on the network!


It’s always been clear to me that debugging (once the network parts started to come together) would be a huge task, so no surprises here.

Safe Network is one of the most (if not THE most) complicated networking projects ever conceived – and to David’s credit, he has not taken any shortcuts or otherwise pared back it’s aims since the beginning.

Of course it’s also frustrating how long the journey has taken - but serious respect to David and the team for all of their perseverance in bringing this game changing network into existence.

Humanity won’t be the same post Safe Network (development stage) - believe it.


Great work, thanks team!


This is Safe Network’s decade! Just think of the progress throughout each of its years ahead.


Not sure what you mean here.

Yes it is :+1:


Thanks for the update. Keep up the good work.


Exactly, yep. This and sequence eventually will be replaced by CRDT types built atop the register. So there will be only one non-chunk type inside the network. But in terms of use there will still be map/sequence + register for end user use :+1: (aka app use)


Finally back in the land of the living and did not fall off any mountains. (Apologies to those who are disappointed :crazy_face:)

One bug that interests me other than data loss is why each successive upload takes longer.
Are there any ideas to why that happens?


Might be solved now but just a thought that requests are not ignored… and for a few iterations the new elder continues to acknowledge it was an adult and transitions through a [new elder]. Perhaps more complex than worthwhile, especially if it’s shifted position and cannot take the same action. I don’t know well enough what tasks each flavour is doing.


I ran @southside’s test on sn_cli 0.33.1 & safe_network 0.9.1 and it looks pretty good to me :slight_smile:, fixed? tagging @Vort

+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynypzd1yizac8ouqpsazc1ntkp83668wqxhtyhqxgu8cioy5533frfw 
FilesContainer created at: "safe://hyryyrbj8h1zqm1xwqheqxywqwzta5su1mmer88y4sz1f4cedfaf7s3ncbanra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynyq4o1a45wj46ibcp9ju7es1aw5y83z7fjaeocembodqskfzmirzye 
FilesContainer created at: "safe://hyryyrbm7y8b1hsuwn1idt7o86enu9gnxak8hnks1tkssoasucq3538rz6hnra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynypjah5sjbyrbqqz5rpi4tzmccndrowjqeq8xnaeh36t6wy38hmwhc 
FilesContainer created at: "safe://hyryyrbkccwpzsj5aoxumkapmh5o4rkfbfaph96eup91upm9wgnqegohmcwnra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynyk3qi445feww4h543h5idouc1h7ff4qbzof5sik9qtdom4nq44pjw 
FilesContainer created at: "safe://hyryyrbxp7p9eputgrz86wg8qy6tsd3xjb1fcaxur4n11uhfrxtnd93tfwonra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynyxq79mgr78eq7by53jb7jnfgjcbmjethz8om4s5repbik3i7jk3zh 
FilesContainer created at: "safe://hyryyrbjizugdriee7j78xcn71zypwq1ypt8hyhr68k8d9owpxbeyn76jgonra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynyxjkdxykyies99xfejrdiabnri9yprd6bpg7yx3x6n65qwbg3kstw 
FilesContainer created at: "safe://hyryyrbm5xghs5ic3b8p9jc1cbtfpwfk4bpfqdzbrtjbek4ozetwtwydbfanra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynykpyaipz3au1wsh336wukb7qqqdjdywxrq8espnt7arnz5awhokac 
FilesContainer created at: "safe://hyryyrbjk54p5no686zga7gfeh5wna68r8g1dpayx7nk3xbhn94b6o7yt6ynra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynyk5cb1sj41jiso8dbj9hn8g6swdiqitdfu3dcnmjgfypb7nbortmr 
FilesContainer created at: "safe://hyryyrbxerk6hbt4pf6inw6jb8ogdr9uxobmoatrtub81b7u9hpd8ot49rcnra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynyetpn9fwuwcnbk4g3x8z17fs1d31ipijqizrzqjn63kfg7y7hxbwo 
FilesContainer created at: "safe://hyryyrbqz5ejto3db1fdqsz43qz6cf8ob7wexmdg7df59k3u5eo6bq1f9oynra"
+  /home/josh/tmp/testnet-file-uploads-20210722_2030/100.dat  safe://hyfeynymg6gajihji5acjm6rxwkrd5cyuxncj766puc171aezz9zhrd53ee 

Never heard of Pedersen Commitments (why else would I have? :joy:) but this video explains it really succinctly!

@dirvine isn’t Bill a friend and supporter of the project?

Can’t wait to see some updated UX!
Great to hear these bugs are getting exterminated.

Oh and are blinded values the same as blinded signatures? If not, how do they differ?


The “blinding” referred to in the summary is different from traditional blind signature DBC’s which normally require fixed denominations, eg as described in the “Scrit” whitepaper. What we have recently implemented is based on “Confidential Transactions” used in monero and bitcoin elements sidechain, except using BLS for (multisig) encryption. In this scheme amounts are encrypted by sender/reissuer so that only the recipient (holder(s) of secret key) can view them, regardless of who sees the DBCs. Even the mint nodes never see the amounts. The sum of outputs is proved equal to the sum of inputs with pedersen commitments and a bulletproof proves that the amount is non-negative. This adds a great deal of privacy, however I should point out that it does NOT make the transactions unlinkable by mint nodes in the way that a blinded DBC would. For that, something like ring signatures or perhaps snarks of some type may be indicated. In practice this may not be such an issue because no single mint node sees all the Tx, and also (perhaps) the mint nodes will keep the info private, though we should not rely on them doing so, and auditing / proof of payment without public disclosure of reissues remain open issues. Also though, linking together amountless, single-use-key tx does not provide much information by itself.

Another privacy improvement we are considering is to enforce/require the use of one-time public keys, which is a bit similar to “stealth” addresses but conceptually a bit simpler as it does not require a diffie-helman exchange.

With regards to traditional blinded DBCs, the mint only processes fixed amounts, eg 1, 10, 100, 1000, etc. Like cash. For each amount, the mint has a unique key with which it signs and validates DBCs. So the privacy pool is the total number of DBC issued with that amount, which could actually be quite small for very large amounts. (In Scrit, the privacy pool is even smaller because there is also a concept of epoch/expiry.) The blinded mint is unable to link transactions (reissues) together, however it CAN see/log/publicize the amount of every DBC, along with date/time, maybe even IP in a naive implementation. We feel that the route we are taking offers a stronger privacy path going forward, as we have just achieved strong (information theoretic) amount hiding and “good enough” unlinkability seems possible.


Keep up the good work! :racehorse:


Thanks for @danda. You let me know what I was wondering about while reading about confidential transaction, .

I think the one-time public keys could be one of the good solution for unlinkability features

I think your DBC + confidential transaction + one-time public keys( or something) is a better innovation than DBC + blind signature.


one-time-use keys are good for preventing users from accepting multiple payments to the same public-key which can harm privacy. So yes, very helpful in that sense. However, it is orthogonal to the (un)linkability I’m referring to, which is based on the fact that a given DBC id (hash) appears as an input in one reissue (tx) and an output in another, thus linking the tx together and forming a graph that can be studied/followed by anyone holding a full set of all the reissue data. Whether anyone (even a mint node) would be able to get a full set of that data is still an unresolved question, and the answer may depend on what comes of further discussions regarding auditability of the system and proof of payment (receipts).

To my knowledge this is the first time anyone has combined DBCs and amount-hiding aka “Confidential Transactions”. :slight_smile: