Update 19 January, 2023

[maidsafe]

It’s one of those weeks where there’s lots of bits and pieces going on, but nothing major to report, so we’ll just settle for a brief update.

Mostafa has been putting his consensus algorithms through the wringer. Random tests are all passing now and it’s ready to be merged. As a reminder, this will be used to handle mass leaves and joins in an orderly fashion.

@Anselme has also been making good progress refactoring DBCs. He’s removed ringct which was problematic for a number of reasons we may explain at a later date - or just ask below. On the other hand, we are keeping amount hiding and one time keys for DBCs.

@bochaco continues to look at messaging and this week was playing with having AE responses as part of a node_msg response type. His weeks of testing various fixes have come to fruition in another pr which re-enables multi-threaded testing in CI. Before this, tests were wholly unreliable, but with all the fixes in the last months things are now much more stable there!

@oetyng has also been looking at messaging, specifically cleaning up the code around join logic - when nodes try to join the network - which has for a long time been a special case which has had knock-on complexity throughout the node and communications code. This change should open the door to further simplifications.

@bzee is still deep in qp2p, simplifying it and stripping it from some functionality that we’re not using. Which should knock on and simplify things on the node side.

@joshuef is looking at a better way around identifying and penalising faulty nodes.

And finally, thanks for all the feedback on the Token Distribution RFC! After considering the pros and cons we’ve decided to stick with the plan outlined in that post and have put it to the Swiss authorities.

---

Useful Links

• Safe Network Website
• Safe Network Primer
• Network Fundamentals
• Roadmap
• Glossary

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

Russian ; German ; Spanish ; French; 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!

[TAZAXEL]

first,now to read

[Dimitar]

OpenAI Summary:

The team is working on various tasks including consensus algorithms, refactoring DBCs, messaging, and network functionality. Mostafa is focusing on consensus algorithms and Random tests are passing. Anselme is making progress on refactoring DBCs and removing ringct. Bochaco is working on messaging, specifically looking at having AE responses as part of a node_msg response type. Oetyng is cleaning up the code around join logic in messaging. Bzee is simplifying and stripping functionality from qp2p. Joshuef is working on identifying and penalizing faulty nodes. The team has received feedback on the Token Distribution RFC and has decided to stick with the plan outlined and has submitted it to Swiss authorities.

---

Privacy. Security. Freedom

[Secretariat415]

Thanks so much to the entire Maidsafe team for all of your hard work!

[Southside]

Thanks as always to the team for all the hard work.
I say this most weeks but I think what is often forgotten is the fact that most if not all of the devs could be earning a LOT more working on other projects in different sectors.
I have no empirical evidence for this but I believe it to be the case - so BIG thanks again to all the devs.

[TylerAbeoJordan]

Thank you for the update team. What’s the next set of things being aimed at before next test net? Hoping there will be something we can test soon.

Is the removal of ringCT temporary or permanent? This seems a big change and a reduction of privacy in transactions - hoping that’s not the case. So I wouldn’t mind a brief explanation of the problems it’s causing if that’s not too much trouble. Also what triggered the refactor of DBC’s in the first place?

Cheers and thanks again for your efforts.

[19eddyjohn75]

Thx 4 the update Maidsafe devs & all your hard work.

Even a brief update should be cherished.

Taking less of your precious time to write an update, means more of your time writing code…

@maidsafe

On the other hand, we are keeping amount hiding and one time keys for DBCs.

Keep hacking super ants

[dirvine]

@TylerAbeoJordan

Is the removal of ringCT temporary or permanent?

For now, it’s permanent. Decoys are a horrible idea it’s really security through obscurity, and it’s not good. We need a long discussion at some point over regulations and some other hard-felt feelings over anti-government issues.

Personally, I am against decoy-type mixer nonsense, but if there is solid maths that obfuscates sender/receiver pairs (lie full FHO) then I am all for it,but acting like a wee secret does not do it for me.

I feel we should be secure, private and free but not use weird fantasy tech to hide stuff, that is just a battle we will lose. However, solid maths-type hiding is great. and as such FhE seems to offer a much better way.

tl;dr The battle for 100% anonymous currencies is not one we are fighting right now. We are looking to make data private secure, and free to everyone, Money later, but can anyone break one-time keys and hidden values? I don’t think so and the code is much simpler than decoys.

[neo]

@dirvine

Decoys are a horrible idea it’s really security through obscurity,

Just so I am understanding right, the issue boils down to the history left in network? And this history is needed for checking a DBC is not or is spent already?

Then all one needs to do is track the DBC spend to addresses (child DBCs) and follow the trail similar to how one tracks through a blockchain. Once the tracker can match a transaction with an actual person or network account then a lot of info can be found out whether one time keys are used of not?

Is it possible to only keep history for the DBC ID without the child DBCs IDs that it was spent to within the parent record? The child DBCs will have their own record anyhow and that way one cannot follow a trail through the spends.

[TylerAbeoJordan]

@dirvine

The battle for 100% anonymous currencies is not one we are fighting right now.

I don’t believe that it’s possible to have 100% anon in anything. We exist in this universe with everyone else and there are connections between all of us. Given enough effort all things can be revealed.

So there cannot be any perfect way to do things that gain us anonymity/privacy and perfection is the enemy of the good.

I was wondering that triggered the refactor - was it purely to pull out ringCT? Was ringCT not working or slowing transaction speeds or … ??

Just seems rather specific without reason other than “it’s just not perfect enough” - to paraphrase.

If this removal is about government pressure, regulation, etc. Then it seems it would be fine to just say so. We’d all understand if there are external pressures that might prevent the network from being built.

[dirvine]

@neo

Just so I am understanding right, the issue boils down to the history left in network?

Not in this case, the ringct uses decoy keys (Existing keys) and creates a keyimage. That tells you the DBC was spent but not form which key. It’s kinda complex but in both cases (with and without rinct) we can see history. Ringct adds a layer of obfuscation that hides which key spent the DBC.

tl;dr Both systems are auditable back to genesis.

[scottefc86]

@TylerAbeoJordan

If this removal is about government pressure, regulation, etc.

I really hope not because that’s a slippery slope.

@dirvine

Both systems are auditable back to genesis.

Forgive my ignorance but if data is stored using DBC’s and it might be possible to trace who spent a DBC would it be possible to link the uploaded data in a similar way?

[dirvine]

Uploads are paid with DBCs but no history is kept there. Bad elders could try and keep history and somehow publish that. They would then have to work out who owned the dbc that was spent and so on.

So everything is possible really, it’s down to how hard it is to do and in this case I thin it would be very difficult.

Software though …

Even if we have some amazing, totally hidden and mathematically guaranteed to be anonymous you still have IP addresses and bad actors recording all IP addresses and size of messages to unmask data etc. So this goes on and on for a very long way down.

My view is we focus on a decentralised secure data network that holds data in perpetuity on consumer pcs. Get that stable then look at upgrades with more and more security etc. For instance fully holomorphic encryption is here now and offers some great advances. It’s a massive area though that we cannot take lightly

[Toivo]

@maidsafe

Mostafa has been putting his consensus algorithms through the wringer. Random tests are all passing now and it’s ready to be merged. As a reminder, this will be used to handle mass leaves and joins in an orderly fashion.

Isn’t this kind of big news? When this is in, we can expect the network to tolerate changes in it’s structure much more robustly? I’ve been seeing this as a lynchpin for multi-section testnets, am I oversimpifying things?

[dask]

Consensus being merged is a very big step forward.

@dirvine

My view is we focus on a decentralised secure data network that holds data in perpetuity on consumer pcs. Get that stable then look at upgrades with more and more security etc

Yes. The data network above all things. If that works, the best implementation for DBCs can be bolted into a secure and stable foundation. I have been an outspoken fan of e.g. Monero (RingCT, etc…), for a long time, but will also be the first to admit it is possibly not the right option here. Auditability (I think this is important) is very difficult to square with infosec perfectness. I don’t think this needs to be solved just yet. The last test nets were very encouraging.

Thanks for all the hard work!

[TylerAbeoJordan]

@scottefc86

I really hope not because that’s a slippery slope.

I think, given we see exchanges have delisted coins like Monero, that being more traceable might be the better way to get started at launch.

I suspect that ways to obfuscate can be added later by other entities – perhaps as plugin mixer nodes. In this way it’s not the network as a whole nor Maidsafe that’s being disobedient to some authority, but specific plugin node operators.

There are a range of options here really.

[neo]

@dirvine

Not in this case, the ringct uses decoy keys

Wasn’t thinking about the ringct but at the very base level what the issue is.

[dirvine]

I am not sure there is an issue just yet. Ringct offered further obfuscation at a complexity cost. That is really the bottom line AFAIK

[danda]

Monero (ringct) tx are audited (sum inputs >= sum outputs) by every full node when each block is processed… ie constantly.

The difference vs eg bitcoin is simply that the ringct math has a lot of complexity to validate the sum inputs >= sum outputs result (adding points on a curve, bulletproofs to verify non-negative), whereas with btc, it is literally simple addition one can do by hand.

DBCs (ringct or not) are audited by mintnodes or anyone that cares to obtain and process full log of tx since genesis.

I heard a whlie back that a weakness was discovered re ringct BLS impl (as opposed to ed25519 used by monero). Though I don’t see that stated as a reason for removal in this thread, so will not speculate further.