Data chains: what? why? how?


A chain is an image we all know. It represents strength and reliability. Bitcoin has made use of such imagery in the implementation of a blockchain. A blockchain is a chain of links where each link couples transactions (blocks of transactions) in a reliable and cryptographically secured manner.


Data chains represent, instead, links that couples together data identifiers. A data identifier is not the data. As the blockchain does not hold bitcoins a data chain does not hold data.

This post discusses an overview of data chains, there is also an RFC covering some basic use of DataChains and also a codebase to implement DataChains, as well as Data handling (recognition) and long term storage.


What use is that then? If these things hold no data then what use are they?

This is a critical question to answer and resist writing off as irrelevant, just yet. If we can be assured a transaction happened in a blockchain, then it allows us to know where a bitcoin should exist as if it were a real thing. It is the same with a data chain, if we can be sure a piece of data should exist and where it should exist. However with data chains, identified data is real (documents, videos, etc). That is, if we know these files should exist and can identify them, then we just need to get the data and validate it.With a network that both stores and validates data and their IDs, we gain a lot in efficiency and simplicity as compared to blockchains which cannot store significant amounts of data such as files. Data chains would additionally allow cross network/blockchain patterns, but one must ask why do that, duplication is not efficient?

Data handling 

Therefore if a block identifies indisputable information about a file, such as (naively) a hash of the content, then we can be presented with data and compare to a valid block. If the block says the data is recognised, then it was created by whatever mechanism the network agreed to assume responsibility for the data.

Now we can historically validate that data belongs on the network and it was paid for or otherwise accepted, i.e. it is valid network data. This is a great step, some will think, oh I can do that with XYZ, but hang on for a few minutes.

Network handling

Here, we separate from a standard one truth chain and look at chain parts, or a decentralised chain on a decentralised network. A chain where only a very small number of nodes will know of the validity of some small sets of data, but the network as a whole knows everything and all data. Ok, we can see now this is a bit different.

We need now to look again at the chain a little closer, here is another picture to help. We can see here that there seems to be links and blocks. This is an important issue to cement in our thinking.  In a blockchain for instance the link is simple (simple is good, in security the simpler the stronger in many cases).


Here though, a link is another agreement block. These links are actually a collection of names and signatures of the group who agreed on the chain at this time. Each link must contain at least a majority of the previous link members. With every change to the group then a new link is created and added to the chain. Please see the consensus overview blog for an overview of these groups and their importance.

Between these links, lie the data blocks, these represent data identifiers (hash, name, type etc.) of real data. Again these are signed by a majority of the previous link (in actual fact they can be slightly out of order as required in an out of order network, or planet🙂 ).

Now the picture of a DataChain should be building. But how does it split into a decentralised chain?

Splitting up

The easy way here is to consider just the above chain picture, but also remember back to a xor network13706-20c, or plain binary tree, here is one as a reminder.

Remember also we have a notion of groups of nodes. So lets take a group size of 2 as an example.

The process would be:

  • Node 1 starts the network, there is a link with one member.
  • Node 2 starts and gets the chain so far (it’s small with only node1 listed). Node 1 then sends a link to node 2 signed by node 1.
  • node 2 then sends a link to node 1 signed by node 2.

So now the chain has two links, one with node 1 alone and the next with nodes 1 and 2, both signed by each other. This just continues, so no need for me to bore you here,

However, then node 4 joins and assuming all nodes have a purely even distribution (meaning 2 nodes address starts with 0 and the other two nodes address start with 1) the chain splits! two nodes go down the 0 branch and two go down the 1 branch. The chain has split, but maintains the same “genesis” block. The link with node 1 only. Between these links the data blocks are inserted as data is added (Put), edited (POST) or Deleted from the network, each data block again is signed by the majority of the previous link block (to be valid).

So as more nodes join then this process continues, with the chain splitting as the network grows (for detail see RFC and code). This allows some very powerful features, which we will not dive too deeply in but to name a few as example:

  • Nodes can be shown to exist on the network (i.e. not fake nodes).
  • Nodes can prove group membership.
  • Nodes can have a provable history on the network.
  • Nodes can restart and republish data securely that the network can agree should exist.
  • Network can react to massive churn and still recover.
  • Network can recover from complete outage.
  • Network can handle Open ledgers for publicly verifiable data.
  • Network can individually remember a transaction (so for instance a single safecoin transaction can be remembered as a receipt, at a cost though).
  • Network can handle versioning of any data type (each version is payed for though).
  • Fake nodes cannot forge themselves onto a chain without actually taking over a group (meaning they cannot be fake nodes🙂 ).
  • As data blocks are held between verifiable links then data validity is guaranteed.
  • As data is guaranteed some nodes can hold only identifiers and not the data, or a small subset of data.
  • As not all nodes are required to store data, churn events will produce significantly less traffic as not all nodes need all data all the time.
  • The network can handle nodes of varying capabilities and use the strongest node in a group to handle the action it is strongest with (i.e. nodes with large storage, store lots, nodes with high bandwidth transfer a lot etc.).
  • Archive nodes become a simple state of a capable node that will be rewarded well in safecoin, but have to fight for its place in the group, too many reboots or missed calls and others will take its place.
  • Nodes can be measured and ranked easily by the network (important security capability)

There is a lot more this pattern allows, an awful lot more, such as massive growth or an immediate contraction in the number of nodes. It is doubtful the full capability of such a system can be quantified easily and certainly not in a single blog post like this, but now it’s time to imagine what we can do?


Moving forward we need many things to happen, these include, but are not limited to:

  1. Design in detail must be complete for phase 1 (data security and persistence)
  2. Open debates, presentations and discussion must take place.
  3. Code must be written.
  4. Code must be tested.
  5. Integration into existing system.
  6. End to End testing
  7. Move to public use.

Of these points 1, 2, 3 & 4 are ongoing right now. Point 5 requires changes to the existing SAFE routing table starting with an RFC. Point 4 will be enhanced as point 2 gets more attention and input. Point 6 is covered by community testing and point 7 is the wider community tests (i.e. Alpha stages).


Data chains would appear to be something that is a natural progression for decentralised systems. They allow data of any type, size or format to be looked after and maintained in a secure and decentralised manner. Not only the physical data itself (very important), but the validity of such data on the network.

Working on the data chains component has been pretty tough with all the other commitments a typical bleeding edge project has to face, but it looks like it has been very much worth the effort and determination.  The pattern is so simple (remember simple is good) and when I tried to tweak it for different problems I thought may happen, the chain fixed itself. So it is a very simple bit of code really, but provides incredible amount of security to a system as well as historical view of a network, republish capability etc. and all with ease. The single biggest mistake in this library/design would be to try any specialisation for any special situation, almost every time, it takes care of itself, at least so far.

This needs a large scale simulation, which we will do in MaidSafe for sure prior to user testing, but seems to provide a significant missing link from many of today’s networks and decentralised efforts. I hope others find this as useful, intriguing and interesting as I do.

We think there will be many posts depicting various aspects of this design pattern over the next while as we get the ability to explain what it offers in many areas. (i.e. when we understand it well enough to explain it easily)



Posted in Uncategorized

Introduction & Technical Overview of SAFE Consensus

The features included in decentralized networks can be quite varied based on the proposed goals of the technology. From the sharing capabilities offered by Bittorrent to user privacy enabled via To…

Source: Introduction & Technical Overview of SAFE Consensus

Posted in Uncategorized

Structuring Networks with XOR


A prerequisite to understanding the SAFE Network on a technical level, including the consensus process, requires knowledge of the underlying structure which powers it as a decentralized, autonomous system. Peer-to-peer networks can be categorised into two general types: structured and unstructured. In unstructured networks, there is no explicit organization of nodes and the process of joining and forming connections to others is random. In structured networks, like those which use a distributed hash table (DHT) such as Bittorrent or the SAFE Network, the overlay protocol includes a structure for organizing the network and makes purposeful connections to specific nodes more efficient.

One of the most widely adopted DHT’s, named Kademlia, was originally popularised through its implementation in Bittorrent’s Mainline DHT which removed dependence on central trackers for finding the locations of nodes and data stored on the network. Kademlia employs a rather simple operation called “exclusive or” (XOR) to establish…

View original post 1,574 more words

Posted in Uncategorized

The language of the network

Another quick post, I hope this makes sense, it is perhaps the most exiting aspect of MaidSafe I have found so far and the consequences of this are far reaching indeed. It will not be obvious, but please ask questions on and I will try and explain more of why this is very important, not only to launch with but to move forward and also model system components very quickly.

The notes we never heard

MaidSafe, that strangely named bunch of folks who are looking to change the world with something that sounds:

  • Amazing
  • Impossible
  • Frightening

Yes the vision that is rock solid and unmoving against all odds and all comers no matter what. The vision to give to all the people of the world Privacy Security and Freedom, but how do they do it? how do they explain it?

Well until now, not very well. There are tests, experimental data, research, 18 months of network simulations modelling, papers, interviews, videos, blog posts, comments and answers, email trails, presentations and all in all it still sounds … too good to be true! For many it sound’s like an impossibility. Well it works, it produces results and we still cannot explain it. Is this about to change ?

The network critical parts

Routing is a critical and central part of the codebase, it provides routing information and security of the network, handles churn and ensures the xor relationships are intact and accurate. It is the workhorse of the network relying heavily on a very efficient reliable UDP implementation underneath. Crux, our new rudp is that implementation. I wanted to check this code in detail. I was particularly interested in the consensus checks and ensuring they were solid and as efficient as possible (they will always be more efficient as time goes by, but for now they need to be rock solid, so worth the effort), Consensus groups and checks are a very important part of the network for group based actions to ensure the correct authority is network agreed. This along with client digital signatures makes all the various authorities work in unison and provide harmony out of apparent chaos when you look at the network.

In routing we have a GroupSize and QuorumSize, the Quorum is the number we require to validate a groups intentions as an acceptable level of comfort the intent is agreed with the group.

Software development

Many who know me or know of me will know I am an Engineer, as happy with a hammer or soldering iron as I am with a compiler. I like Engineering and I think I act like an Engineer, what cannot be fixed? give it here, I accept the challenge!, Impossible great that will be fun, lets work out how to do it!.

Software development to me is Engineering, I care not if I am trying to loosen a nut with a damp dish-towel or making code do something for me. I see a problem, look at what is available and attack! Then though you have to build amazing things and it is different, you plan, build, test, build, plan, build test, build and so on, getting to the place where it makes sense. Then start all over again and implement the answer, neat repeatable and stunning.

With MaidSafe the problem we took on is, the Internet (web etc.) is fundamentally broken and taking the wrong route, answer, well fix it! OK yer on.

So we did, with many years of build, test, plan, build etc. we got a system that could fix this issue and went though testnets. On testnet2 I decided with a lot of coaxing to get back to code and re-factor routing for stability and security analysis in particular. In doing so I went though all sorts of hell, no sleep and fighting logic every day asking why like this? why like that? (not the code the sheer complexity) Ok rewrite part of routing, I can do this fast, I always can when I focus. So no xmas for me, there’s work to be done (and the lines of “the band played waltzing Matilda” resonates, especially “never knew there were worse things than dyin”).

Tough days, harder nights and I was in a familiar place, deep deep thought, what are these types in the code (c++ has types, they are called classes), why do they exist, what fundamental facets make them unique enough to exist as a type? Yes questioning God, gravity and C being a limiting factor of the universe, this was all familiar. I was in innovation mode again, that dark place where nothing can get in the way of your thoughts, not even a million blog posts and comments, questions etc. nothing. You are in cruise control, focussed on a burning question, why so complex? why? What am I missing?

The MaidSafe issue was again prevalent, I Cannot explain this to anyone, it is stunning and beautiful, but so so complex.

Back to school

Then it was back to school thinking, I remembered the huge equations of experimental data on a blackboard and what we did to it. We factored it. What starts out as a massive multi variable mess of junk, eventually factors to x = 2y + 6.

This is what MaidSafe is, un-factored (well not factored enough). This is why we cannot explain it, it’s why changes to the code are so hard. It is doing something nothing else has done and doing it well, but with such huge complexity. I am not happy, we never factored the equation. How though, how?

Back to types, what are these and why?

I deviate from some software developers here, I see types not as useful code helpers to stop you typing the wrong name or something into a functions. I see types as a thing and that thing has a particular Genus, you are making something with a type, something unique and with purpose, different from any other thing you have made. So it needs thought. Really think hard, what is it and why.

So back to routing, I am looking at the network as an electron or message would, the vast array of connections all held together in xor space, I know I can do certain things, but what can the network tell of me. Can it recognise where I have been, or where I am and if so what am I when I am here at this place in space and time?

I know we have consensus groups, I know folk do not find it easy,  but they are there all over the place inter-lapping, constantly changing and deterministic (well if you can stop time and just analyse the network fully, you may be able to identify the state, but like Zeno’s arrow it will give more questions than answers). I know these groups exist, I know what they do and I know there are lots of them, each interwoven with others in a dance that makes your head spin in this cable.

I then notice something, something that makes everything stop. I see a familiar thing, a pattern, a repeatable, explainable pattern and it is describable. In the mist there is a view coming to me and it’s taking a form, what is it?

It’s a consensus group type, not only that but it stamps itself on a message until the next group gets to it. There is something I can see and more importantly name. These patterns are everywhere. I look at the vault code. Over 260 c++ files, beautiful code, amazing skill, but it’s doing something I can see. Most of the time this code is trying to work out all the functions and features available at any stage in a messages travel. It’s looking for the answer, but not always the same way. It’s not hearing the music and it makes up for it with more code and more algorithms.

Now I am in shock, I always knew we would uncover the secrets of the network, I knew it was our path to follow and find this, but was this it? I had to take time out, Dude needs a walk on the beach, off we go. I end up running back to the code, I was right this is it. I need to think.

Ok what is it

So the revelation is this and it is quite simple. There are several persona types, all personas are actually one of these regardless of what code we put in it. A persona group is a certain and guaranteed thing that the network in the real world can see, validate and secure. This all happens very dynamically and the network knows these things. Even though we have calculated this, the network knows and it knows better that any amount of advanced code we can throw at it. This is one of those, “of course it is“! moments. The network can tell us who we are with respect to a message, we do not need to calculate it in upper layers, routing knows already it just needs to tell us and we must listen. This is such an under-researched area that this is a truly amazing find, in the group consensus model we have this really focusses thinking and allows significant improvements in explaining also everything about the network. Of course self authentication, encryption and data types etc. are all still very new, but this is a huge aspect (several man years of effort to find this) and it will transform not only us, but hopefully this industry of decentralised approaches to software and services based on it.

People will (and should) look at this now and say, well that’s obvious. I can assure you, it only is after you see it (like a wheel or boat).  So what are these types and why do they exist?

Here we go.

We have (4 type, only 4, no more no less)

Client Manager – This is a type of persona this is the group of routing nodes closest to a client node. They can tell as they have a connection that is not a routing table node, so it must be a client! Examples of these types are MaidManager (the group that looks after a Maid account), MpidManager (the group that looks after public name and public shares/drive for public clients)

Nae Manager – Network Addressable Element manager groups. They know they are this type of group as they are close to the address that equals the name of the network addressable element (not a Network Addressable Node, but data or function elements). Examples of these are DataManagers (look after data pointers) and VersionManagers (looks after directory versions and any other mutating directly addressable node)

Node Manager – This is the group surrounding a node and they know as the node appears in their routing table. An example is a PmidManager (the group looking after nodes holding data).

Managed Node – This is a routing node in a group of Node Managers such as a PmidNode (i.e. a node actually supposed to be holding a data element). Future, ComputeNode to handle computations (using zk-snark etc.)

That’s is it. Now we call these authorities as they represent a particular authority. So lets look at a client putting data on the network.

  • Client sends message to his own address on the network
  • ClientManagers receive this and check it is a client he has enough storage available (paid enough safecoin)
  • They send to the DataManagers
  • DataManagers check the from Authority is a ClientManager group and look to see if data is already stored. If so then Finish, else
  • DataManagers send to a PmidManager group.
  • PmidManagers check from authority was DataManagers and they store in a node close to the address of the group.
  • PmidNode receives this Put and checks the from authority was his PmidManager group.
  • Pmid Node stores data. Finish.

“Hold on! I spot a problem”. It is OK these nodes can confirm who they are, but here we mention from authority. It seems the from authority is required to confirm the chain of deterministic actions is correct, otherwise people can claim to be anyone.

This is the other neat part actually. We know and have proven experimentally many times the quorum of a group is secure. So you know what group you are (remember the network can absolutely tell you with incredible accuracy what persona you are). So you send your persona type in the message to the next group. The next group then accumulate results, check your signature and validate all your group said they were persona type X. So this seals the chain of events into a secure deterministic chain. This provides great security, but more importantly the language now becomes simple.


Client -> ClientManager<->NeaManager->NodeManager->ManagedNode


Client <->NaeManager<->ManagedNode

We can add in symbols such as ->>>> to represent going to a group and some more small symbols (such as <-> meaning may return result from here) and we have a complete language to describe the vault code (to be published soon). Importantly given such strict rules and types this can be coded very quickly with a strict specification. We have tried to do some things that would break security and guess what, this language stops it dead in it’s tracks. So we can develop very quickly new persona types for these categories for many things, safecoin, compute, AI engine, Search and many more. This speeds up development to a point we should be able to test different ideas in days, not weeks and months as it is with the huge un-factored code base. Please do not misunderstand this does not mean code in days (although a massive reduction in time for code is obvious), I mean we can write down data flows and analyse them in a manner people understand easily. This allows  many people to be involved in such thought experiments prior to implementation. This is a huge step, no longer does one or perhaps two people understand what is happening, but everyone can (within reason).

This is huge and the most significant find I have had in 9 years working hard on these problems. It is still very exciting to me, even now. For instance our vault code will now go from over 260 template heavy and complex source files to a handful of very simple header files.  Testnet3 will include this, Crux and routing_V2 which adds in a sentinel, this is a crucial accumulation and security check. So we can confirm cryptographic authority (a client has signed and action on something he owns) and group / consensus based authority. A description of the sentinel is probably required now, so sorry for the inordinately long post.

Sentinel overview

Quick intro to network consensus, authority and crypto usage.

In a decentralised autonomous network there are many challenges to face. One such challenge is the range of attacks that consist of Sybil / Spartacus and forgery attacks (did the message really come from who you think). One of the simplest attack to foil is the forgery attack, thanks to asymmetric cryptography. This allows for a public key to be known by everyone and when anything is encrypted with this key it can only (supposedly) be decrypted by the private key of that keypair. Assuming a reasonable algorithm, keysize and implementation this holds true.

This also removes the Spartacus type attacks (claim to be another identity)., but not necessarily sybil attacks, where an attack on a bit of a network is enough to persuade the rest of the network that any request is valid or indeed anything asked of that part of the network is done as expected. To overcome this MaidSafe have several techniques used in parallel. These boil down to

  1. Have nodes create key chains (a chain of keys each signing the next until one is selected). We call these Fobs. A Publicfob consists of a public_key & signature as well as a name field. The name is the SHA512HASH(public_key+signature) making forging a key crypto hard (we can confirm the signature is also signed by a valid key pair by checking the signature there, where this ‘pure key’ is self signed). The Fob type is this PublicFob + the private key.
  2. Ask network to store the PublicFob for a node. The network will accept this if the node has certain characteristics (based on rank – later discussion) and the key is less than 3 leading bits different from the current group of nodes. This makes key placement distribute equally across the address range (as for rank consider only a single non ranked node allowed per group, and failure to increase rank means the key is deleted from the network and has to be re-stored if possible).
  3. This now resembles a PKI network where to speak to node ABC you go get the PublicFob at ABC and either encrypt a message to the node or check a message from the node is signed by using that PublicFob.public_key. The difference being no central authority exists and the network distributes and collects keys as any DHT would (except in this case the DHT is secured by the very PKI it manages). So this is very secure and does not require any human intervention (unlike a certificate authority)
  4. Assemble nodes into groups that will act in unison on any request/response. So these groups are selected to be large enough to ensure a Sybil attack would require at least 3X network size of attackers to be able to join (a single attacker with no other node types joining). The magic number here is 28, realistically this number is closer to 17.
  5. Allow a failure rate as failures will definitely happen. This is done by having a GroupSize of say 32 and set the QuorumSize to 28. This means for any action we require 28 nodes close to a target address to agree and carry out an action.

This Quorum creates a mechanism where another group or node can believe the action is correct and valid. This is called group consensus.

The group consensus provides the network a way to request or carry out actions and ensure such requests are valid and actions actually done. This is required as the network looks after itself (autonomous).

A client has a close group and requires to persuade this group to request the network take an action which Puts something on the network (a data element/message etc.) Clients create data and messages, the network handles these. As the client cannot just connect to an arbitrary group and demand something be done, they connect to their close group and register themselves (with their Fob) an account. The close group can then be persuaded by the client to request another part of the network create something (a Put). In the case of Maidsafe the close group request the client pay via safecoin (it used to be they paid with storage that another group managed an agreed). So the client persuades the close group to put data. (ignore how payment is made, it actually requires client send safecoin to a provable recycle part of the network (another group confirms this)).

So a client can sign request to the group (crypto secure) and the group can check validity of the request and then ask the appropriate group close to the address of the data or message to accept this request.

After anything is put the client can mutate this thing directly (if they have signed it). This is the case for directory entries, where a client can add versions to a list (StructuredDataVersion) as it was Put signed by the client. So the owner of the signature can sign a request to alter this. This is crypto secured authority and does not require the close group for consensus.

In the case of groups requesting actions then we have group based consensus and the network grants authority based on a group that can be measured as a valid close group, where each member has signed a request as being from that close group. This authority is what the sentinel confirms prior to the routing object processing an action request. Almost all messages are Sentinel checked, with the exception of get_group as this fetches Fob’s which are self validating and it fetches a copy of all Fobs from all group members and confirms they agree and validate. Get_group is only used for making sure we connect to our close group as a client or node.

Sentinel components

The sentinel consists of few components and requires no network connection. This is to allow for such a crucial element to be fully tested. The elements are limited to two (2)accumulator pairs. There are two pairs for two different authority types,

  1. Node level direct authority (i.e. could be a client)
  2. Group base consensus

In 1 we just accumulate a single message and get the Fob to check a signature. In 2 We require to get at least QuorumSize messages and this is for group based consensus and then we get the Fobs and again check signature to confirm the group. We also check the nodes are as close to each other in xor space as our own group is (with varying error rate)

To achieve this the process is

  1. Message Arrives
  2. Check Accumulator has seen it, if not Send a GetKey request (for a group or single node)
  3. Add to accumulator. If return is true then check the key accumulator of that pair -> if true then confirm the signature with the Fob (asymm::CheckSignature(Fob.public_key, message)

If the key accumulator did not have the key(s) accumulated (i.e. accumulator.CheckQuorumReached) then we do nothing and continue with other work. Then though

  1. Key arrives (from GetKey response)
  2. Check value accumulators have(address) the address is the source_id+message_id of the request, may be a group ID or nodeId
  3. If not found then ignore message
  4. Otherwise accumulator.Add(key) to the proper key accumulator of the pair
  5. If this returns true, then we get the keys and values (via accumulator.GetAll() calls from both accumulators and confirm signatures. group and return a valid message to the object holding the sentinel (the sentinel add call will be async)

The accumulators are LRU cache based and will empty old messages that do not confirm in this manner.


This language which describes the vaults and consensus logic will help us get closer to formal proofs, explaining the network and moving much much faster with a significant reduction in codebase. It also allows with a crtp template pattern a complete separation of vault logic and the network, so at last we can test fully logic and then attach it to the network. The last few months have been a special hell for me as we are in launch mode and then this. The opportunity is way to large to bypass so we are implementing this as we speak ( at breakneck speed ) and it’s looking fantastic. I will be posting to the community forum with updates, but next week I am taking a few days off and heading North for a break. I will do so in a huge sigh of relief and inner peace after this discovery. It is still something that has shook me to the bones in its elaborate beauty and simplicity. Truly amazing.

Posted in complex systems, MaidSafe, strategy

Experts and the corruption of truth!

This is another observation post and not a member of MaidSafe series. I need to get around to writing more on that. This is related though for sure. It’s also a rant which may not be very useful. This should perhaps be entitled Why David Irvine is absolutely rubbish at answering questions. As usual, like presenting I do not research, read up or prepare this stuff so expect mistakes.

Show me the maths proof!

I hear this a lot with respect to MaidSafe and generally from ‘experts’. I get very frustrated by it which seems to show a lack of ability to some. I argue this is not the case. We have recently developed some maths equations for the security of close groups in MaidSafe, they are far from simple, but agree with results. I must add they are probably not understandable by many, not really. (we will publish these in papers, but believe me it’s a tiny part of a large story, a headline, not full research). I am not putting it in this story for the reason I am writing this story, it’s a badge, like standing in front of a whiteboard with prepared equations, or people who speak in unknown languages of maths to people, in attempt to meet an ‘expert’ status. I will place these equations in papers where they fit for maths people, to portray part of a story, but only part.

You see, to me it seems a complex equation, preferably with some calculus and well placed greek letters can look amazing. It also can be a complete bluff, smoke and mirrors. A good example of this is I was recently chatting to a lecturer/researcher in a local Uni, he is a leading expert in DHT technology and well read and published (even in the peer-to-peer handbook – a bible of DHT tech). This person who for years, along with the community of industry ‘experts’ figured D1HT was a truly amazing, scalable, fast and very efficient DHT. This was published in many places and well-regarded, the maths was impressive and ‘proved’ the case.

For years we had maths that proved bees could not fly. We had maths to prove aeroplanes flew by splitting molecules of air and the longer areas of the top of the wing made these go faster lifting the wing up (well I am reducing this a little). Prior to this we had maths that showed how everything worked (Newton provided much physics to prove this),  we also had a ton of maths to prove zero did not exist (in fact was the devils number) and the world was flat.

Prove it by measurement!

Another field of physics/maths to prove things by experimentation. I was watching a Stephen Hawkins series there and heard a few times, “this measurement proved my thesis”, I also read that a lot in a book called why does e=mc^2 by the professor Brian Cox (the pop band chap, very entertaining and great). These tests do not prove any theory, they agree with a thesis within the confines of the variables involved in this test, which necessarily is limited. So it’s a limited agreement with a thesis, at best.

Make it repeatable!

OK, repeatable experiments are really good, but !

We repeatedly seen a bee fly, we repeated measured planes flying, we repeatedly built things using Newtonian maths/physics, we repeatedly worked for 600 years after Aristotle without the number zero (lets not even discuss complex numbers of negative, and infinity, well …), well maybe not all of us, the Chinese had gaps in numbers to represent zero, but not a name for it (as the mafia would say).

So the question is repeat what ?

Make it intelligent!

Aha, lets prove stuff by giving them, either a complex name or better a complex name with a muckle big equation with loads of components and if it does not fit, shove in a constant or two (it was good enough for Einstein). Now there you go we are experts, nearly nobody knows what we are talking about and we can stand beside a blackboard full of chalk, or even publish a ton of scientific peer-reviewed papers. We are set, experts, proof and above all a satisfied (for now) ego.

Hold on

  • The bee flew (we now believe it flaps its wings really hard)
  • D1HT failed (yes somebody built it and it does not work)
  • Aircraft wings now apparently are believed to behave like a sail on a boat (are we surprised molecules are not splitting in some weird dance with matter ?)
  • Einstein ‘proves’ Newton was wrong
  • Hawkings ‘proves’ Einstein was wrong
  • Recent ‘proof’ shows Newton was right

A single test or maths equations that agrees with a theory does not prove a theory and make a law.

So does e=MC^2, well we don’t know! but we all believe it to be true as though it were a law or proven theory, we teach it as such. Well all this is a problem, there seems to be no agreement. We also need to be careful of peer review and field testing as the NSA / NIST have shown that what is reported and agreed is not necessarily the truth, so this is a huge problem. A huge talk on its own, suffice to say, you need to believe the people who measure and give results (Pharma companies are already known to misrepresent results and actually throw away bad results)

Make it simple

This is the crux of the matter, it just is not simple.

We all need to be able to understand our first principles are probably wrong. We need to realise field testing only tells us a bit of what we need to know within limits. It is just not simple, if its simple it need to be a belief like religion and that leads to people holding onto something that is not proven. Those people will stop innovation and improvement on our global knowledge base.

What do we need to know

Maths is hugely important and is a must, but do not use it as a badge, it’s a tool like a spanner, it may be beautiful to you, but don’t shove it in folks faces.

Measurements are also hugely important to home in on improving the validity of a theory, but should never be stated as proof of a theory in their own right, unless they cover 100% of variables. We live in a pretty variable universe so it would be a brave person …

Repeated measurements really help, but repeat with what variables, do you use the same seed values or make them random (for many tests)?  This is why experimental physics is hard (very hard), there is a huge amount of things to consider.

Another important thing to consider is change, not only of your field but all around you. For instance RSA was very secure and beyond feasible for a computer to break. Now there are at least three things I know of that influence this a lot

  • Computers are exponentially more capable of solving factors via brute force.
  • Discreet maths is moving very fast, so the amount of work to solve these primes is way less than was thought possible when the RSA algorithm was created.
  • Cloud / grid computing allows huge resources to be applied and it can be costed (so we know its circa $5 of amazon time to solve a 256 RSA key)

Never mind far off quantum computing and all that clever sounding chat about qubits and shor’s algorithms etc. (oh nearly became an expert there!), it’s all part of a large pot of stuff we need to know.


There is no short-cut, there is no final proof, we are merely allowed to see only part of what makes the universe work, we do not know gravity, anti matter, black holes or even if any of these things exist! We cannot even tell why prime numbers happen in the order they do, what we do not know is very simple things that we really should know. So how on earth could we know the big stuff? Bottom line, this game we are playing only shows us a few of the rules at any one time, things will change as we discover more rules, but they force us to reconsider all our previous moves continually and as nature shows us more rules it will force us to be humble and start again.

The number of unknowns is enormous and trying to ignore them by simply an equation, fancy word for something, a measurement or even a series of experiments is simply not enough. All together they offer an ability to start to ask, none of them offer a final answer (and never will). So don’t be an expert, be an explorer and if you are nice to your fellow explorers they may even show you ways you have not yet considered. If they talk in maths riddles and hide behind fancy papers and equations then they are safe to ignore. There is no easy answer, only more information and potentially all you know may be wrong, certainly the majority is certainly wrong, so don’t be a believer, be ready to infer new conclusions as you find out more info, which may not even look related. So look at everything and prepare for massive surprises, they will happen!

This is why I struggle to give simple answers to folk, I hate lies and part of a truth is closer to a lie that saying nothing. Many understand this position, but many don’t yet. It is interesting to see though that the experts seem to be the very people who are the believers and not explorers, when folk also realise what they know is trivial and likely wrong then perhaps things will move along faster.

In saying that I also agree that the inability to easily explain something is an indication of a lack of understanding. A quandary, well yes … Just another thing I don’t know, I wish I did.

Posted in Uncategorized

MaidSafe part III – Joining & anonymity

This is a large area of the network, partially covered  in a small post. I hope it makes sense. My intent is lots of posts and all small, I think it works better.

A lot of chat about, is the system really anonymous is based on tracking IP addresses etc. I was surprised recently when I heard that Tor/i2p exposed users ip address at compromised web sites. Not because there was a flaw, that happens, but because the source IP address was available at all.  I thought further and it made sense. There is a significant difference and this issue will always exist in those systems as they are currently designed.  This is not an anti Tor or i2p post in any way, but a foray into a different approach. I would love the TOR/i2p folks to be part of this journey, so poking a stick in their eyes is not an intent of mine.

A different approach

As we covered in earlier parts of this series, MaidSafe uses a secured DHT implementation, based on XOR networking.  This is hugely important, the DHT has the ability to hold information. Some of that is encrypted and secured (in our case all of it bar, public data and public keys).  So lets not dive too deeply in that for now. Keep in mind though this is not an encryption mechanism to traverse todays Internet (web services), its very different.

This is peoples data we are talking about, it is very important!

It may be a debate to some, but it should be restricted to pure logic where possible.

 Types of nodes on MaidSafe

There are two main node types for now (to keep it simple), a client and a vault. So lets recap

Client -> Unique and private ID that has no link to any public ID or name. This ID is used to GET and PUT data. It is not linked to a person or a name, it is a unique 512 bit id. Even owners will probably not know what it is.  A client does not perform routing tasks, that means it is like a passive producer/consumer of information.

Vault-> Unique and private ID that has no link to any public ID or name. This ID is used to store data. These ID’s are the routing infrastructure and what we all connect to, essentially.

Connection to network

Both node types join the network in fundamentally the same way. They read from either a locally cached list of previously known nodes, or they fall back to hard coded nodes in the source code. The nodes they list have IP:PORT and Public keys. The node will encrypt a message to one of these nodes requesting login (or connect).  The bootstrap node gathers this info and returns it to the joining node (encrypted).

The joining node then connects (encrypted) to the closest nodes as returned by the bootstrap node.

So there you have it, 100% encrypted communications from the very first message.  [note the node connects to multiple bootstrap nodes to confirm the answers match and a user can be emailed a connection list from a friend if they wish. This gets away from arguments about centralised root nodes etc, which is pretty silly, but folk do argue that point].

Operate on the network

As a client you will join / login (explained in a later post) as above and be connected. Many people ask, can a client store data (for the network) etc. or be part of routing and we say no. This seems harsh, but important.  I will explain.

A client connects to its close nodes (with an anonymous ID as explained) and then requests data etc. The request goes to the close nodes (who do know the IP:PORT)  and is then relayed across the network (with the IP:PORT stripped).  At the end or location where the data exists, it’s sent back to the anonymous ID. Each node sends this closer to the ID and the close nodes eventually deliver it.

So on the network there is no notion of IP:PORT for messages unless you are close to the node (XOR close).

So then people say, I will get close and then get the IP address. Well this is not simple, close to where? You cannot connect or ask for connection info to a client, it cannot answer, it is not part of routing.  Where is it located geographically for you to snoop on? Can you become a close node vault? That’s going to take a huge amount of work now. It will mean getting a vault ID close to the node. You do not choose your vault ID the network does and this is random across the address range. Even then you are not part of routing either until you have enough rank. This is not an easy feat at all, very likely millions of computers running correctly for a while with a random ID  and to potentially get close to a single node, which may change its ID anyway. A very hard task indeed. At the end of such an attack, who are you monitoring, you will have zero clue as any public name info is further encrypted inside the messages encrypted by the anonymous ID. We could get into reams and reams of what ifs here, I intentionally don’t as it makes the post too long and boring for most.  The system docs go into great detail and are continually updated for those answers.  TL;DR a targeted attack like this is not easy. Non targeted attacks are covered later in the consensus chain mechanism, this is a good precursor to that.

We could go further and create a random client ID every time, or even easier create a data-getter/putter id every time. I do not think it necessary, but very simple if required.  So you cannot see an IP address or tie a data ID to a person, so already it feels a bit secure. As every single message is encrypted, who cares if you compromise the routers etc. We don’t.

Vaults are persistent on the network and connect to more than just their close nodes, but each node decides to respond to a request for connection or not. It will only connect if the request looks good, i.e. improves the routing table. To put this in perspective after a node starts the first such accepted connection will be 1 in 1 million, after that its circa 1 in several million and increases quickly. What this means is that to improve a nodes routing table you will need a huge amount (100’s of millions) of connection requests and these have to be from valid well ranked nodes.

I hope this small post helps people put the network into perspective. The fact the IP address does not traverse the network is important. This is all down to the fact everything lives on a decentralised addressable network where all communications and exchanges of messages are encrypted by mechanism that ensure in transit encryption and end to end identification of every network hop.  If people ‘get’ that part then it makes this journey so much simpler, but also shows this path has not been trodden, so there is a huge amount to consider. A simplification is to say, this is a fully encrypted system that includes the data within it, as data is included there is no leak out to any third parties at any point (no server or machines that know or choose what they store).

So there you go another 6am post, I am off for a sleep now.

[edit fixed typo i2c/i2p too much arduino recently🙂 Thanks  @anonymouscoin (Kristov Atlas)



Posted in complex systems, MaidSafe

Proof Of Storage (maidsafe part II), follow up video

This is a mini post to show how MaidSafe uses hashes to identify data after processing it in a way that’s invisible to end users. I hope it is at least a little bit useful. (note the use of encryption to obfuscate and later I may get into a debate about why we consider it only for obfuscation and creation of non repeating data). This is relevant to the previous post, where we describe hashes and their use for proof of retrievability and corruption free data.

How to make data safe?

Ok, to make this a shorter entry, I have embedded a video Shona in the office did for us to explain self encryption. It confuses many people, but it quite straightforward.

It should be noted, this process is a very small part of the “securing data” story. This will most likely secure data beyond any known decryption ability known today, but, and a big but!

 This is logical security, what I mean is where do you store the actual data? On Dropbox, Google, some other provider, on your hard drive etc. Well no!

None of these give what you want, physical security! Physical security (to me) means that nobody can know where your chunks of data are, so this means that this data has to be scattered to the 4 corners of the planet, on many machines, owned by many people, non of whom know what they hold or can disable or corrupt it in a way that affects the network copies of the data. It also means nobody can ban access, monitor or affect your relationship with your data in any form. This data is yours, it belongs to nobody else and there is no logical reason that anyone gets between you and your data, none whatsoever. This fundamental issue lies at the heart of MaidSafe and it’s design. It is not something people ask for, most likely because they do not realise it is possible.  It is possible, it works and its coming to everyone.

Why is it needed?

Well now we can start seeing the need for not only logically secure data, but also physical security. This about this for a minute, when in history of computing could we have private, physically secured data, accessible across the world? A mechanism where you can log in or access privately and without any third party get your private data securely. It is amazing, but never is the answer. You could argue, use truecrypt, backup tapes, copy to off-line and on-line backups etc.. All of which are hard, leak information about your actions at the very least and most importantly depend on great technical knowledge.

This is where you need an autonomous network geographically distributed and on peers that are monitored, not by humans, but by the network. This allows people to physically damage chunks, but the network spots that very quickly and creates a new copy and at the same time de-ranks your machine. Nothing to gain, except loss of safecoin earning now.  So vandals can happily vandalise, they can use their vandalism energy on that task, that’s fine.

Without an autonomous network this system of protection is only 50% of the job, only logical encryption, worse than that the upload and downloads are monitored in on-line cloud providers, so leak of security is certain. On disks and tapes, then a quick search will find info, if it ever was really secure to begin with.

The point it we need to secure data physically and logically, logical security on its own is at best a hassle.

In later parts of this series, when I get some time. I will explain again self authentication, the vital third part of the network after self encryption and an autonomous secure network. This is where your data maps are made available to you in a pretty fascinating structure. Next week though, I will continue the series on the network itself, that is a very large body of work with a lot of innovation (I believe).

Further details on self encryption can be found here

and of course the code is all on github


Posted in complex systems, MaidSafe

Member of The Internet Defense League

Follow Metaquestions on

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,672 other followers

BTC address