SafeNetwork DBC Technical Series

[mav]

A good basic summary of ring signatures from 40m37 to 42m00

17. Anonymity, Coinjoin and Signature Aggregation

More technical details about ring signatures at 61m27 to ~73m (really nice explanation, and imo well worth watching the whole video!)

18. Confidential Transactions

[JayBird]

Thank you @danda for this great resource which I’m (re-)discovering. I’m taking the liberty of bumping, as it is worth refreshing.

@oetyng I wouldn’t be surprised if your nose is in the code, but if there were some therapeutic or other value to you in synthesising where things are at at the moment, I for one would be thrilled to read it. If not I look forward to it in the coming weeks, anyway, and definitely don’t mind me if you’re too busy.

[oetyng]

@JayBird

@oetyng I wouldn’t be surprised if your nose is in the code

Yeah, that’s where it is But I just finished a good PR, and am catching up on todays HO because I couldn’t follow it properly. So I can write something here

---

Small catchup

So, RingCTs was removed, as has been covered in previous dev updates.
The value of it was dubious, and it did add massive complexity.

What we have today, with the derived keys that are not possible to correlate to someones’s public address (the address of your wallet, where people send you tokens), and the Pedersen commitments / bullet proofs, the qualities that have been previously described and sought, are still very much there.

Current work

My work the past days and weeks, has been in making dbcs easier to understand and work with, both for users and devs, to make a wallet for the end users dead simple to use, to have transfer fees, to have an adequate system for price discovery of those very transfer fees - i.e. a true market where clients and node operators find the middle ground.

Now, with the tech stack changes advertised the past couple of weeks, the work has been mostly of porting over the code from the old repo, and wire it all up.

The significant differences, between old and new designs, are how dbc spends are validated, and thus how dbcs overall can be deemed as valid - by anyone.

Confirmation of dbc autenticity

We’ve previously used sections and Elders. That was a vulnerable design, because the 7 Elders of a section had absolute power over that section. Now, above there was a mention of involving at least 2 sections in a dbc transfer. Still, that’s 14 instead of 7 - not a significant difference.

Now though, we don’t have a small number of nodes who control a large number of dbcs together.
What we have is that each and every dbc has a different group of nodes that validate and store them.

Think about that for a moment.

7-14 nodes hold massive number of dbcs, they are the same nodes that decide on the autenticity of all of those dbcs. Controlling them gives the possibility of a near unlimited source of wealth, if played right.

But now, a group of nodes deciding on the validity of a dbc, will seldom - if ever - decide on the validity of another dbc. That will be a new constellation. And for the next dbc, another constellation.

The spread out over the network is close to perfect.

Layers of groups

But that’s not all. As has been mentioned here and there in past updates, there are levers to use if needed.
So, above we talked of one group confirming autenticity of a dbc. That group could be 4-8-16-32 nodes. A number.
What we can do though, is to get another random (but deterministic within a short time span) group to act as a second layer of confirmation. And another, and another. If we find that necessary.

So, number of nodes in a group x number of groups. That will give us the desired level of security and reliability.

Validating history

But it doesn’t end there. We have yet another lever…

For every dbc that someone attempts to spend, there is a source transaction where this dbc was created. The dbcs that were spent in that transaction, are effectively the parents of the dbc in question.

So, for every request to spend a dbc, we can, in addition to validation of that transaction, with all inputs and outputs, also validate each parent transaction. And we might go one generation… or two… or n generations back. The exact number we will end up with is subject to the findings we do in the coming weeks and months when we build out the tests and the testnets to cover the aspects of dbcs’ security.

What ever the level of necessary checks there will be, we will be able to tune it in.

Performance

Not only will we be able to tune it in. Our margins for performance are huge.
Due to the near perfect distribution - or sharding - of the transactions, we will see a tps (transactions per seconds) that gets better and better the larger the network becomes.
I’m not going to give any numbers at the moment, but it will be better than anything we know of.

So, that gives us all the room we need to dial in the necessary level of checks and controls, with plenty of margins to keep the performance attractive AF, to use plain language

---

Let me know if there are things you’d like to know more about. Just shoot. I might be able to answer here and now, if not then later

[Josh]

@oetyng is the genesis DBC automatically created when we run stableset_net, if so can we interact with it yet?
Can you discuss what the plans are for distribution with a test network?

[oetyng]

@Josh

is the genesis DBC automatically created when we run stableset_net, if so can we interact with it yet?

Not quite yet, but moving towards it. Need to strike a balance in “temporary” code and actual code that will be used later.

But we can lean quite heavily towards temporary to begin with.

@Josh

Can you discuss what the plans are for distribution with a test network?

Haven’t been able to think much about that entirely yet. But it’s close.

Allowing for testnet faucets is a milestone (like the community initiatives).

[tobbetj]

If possible it would be wanted if it is possible to add short easy to understand descriptions of the networks underlying most important tech\features to the Twitter channels and other platforms people feel is important. To get the hype going for upcoming releases and test networks and also to educate people on what is about to come.

@JimCollinson

[dirvine]

I think the best approach here is to update the primer. It’s really well written and now can be simplified a lot. That should give us loads of simple to digest pieces of the puzzle. Adding them together gives us the whole network and now that is much simpler to understand, but not only that, show the logical distribution of not only nodes, but as @oetyng says the distribution of security that gives us massive parallelisation of compute, such as DBC transfers (to begin with).

It’s not. hard view to look from here to

• MPC (Multi party communication) covering much more than DBC, so actually computation at scale
• Running AI models
• Using transformers in fault detection (and also sybil defence)

And much much more. All done correctly and as modules to the Safe network.

So update primer, get everyone well informed. Show the testnets to ensure folk know this is real and happening. Then we can show the possibilities of the Safe Network Core Protocols.

In the shorter term and possibly more exciting for people are the apps. Browser, Document viewer etc. all with an inbuilt “Time Machine”. Messengers, chat rooms, (nostr integrations?_ and much much more. Then Decorum and all those projects waiting for years to be able to appear can at last happen and soon. Very soon.

There is going to be a lot to shout about and for Safe I hope that keeps us focussed on information dissemination to the masses, app builders from anywhere in the world with any level of local resources, or even no local resources (SV no longer has the edge).

This is all now with us again. The last 6/7 years are behind us and we can breath again.

[JayBird]

Hey @oetyng - thanks, that was fabulous. I feel spoiled. Your explanation was very clear, I read over a few times and could follow along on a high level, after reading over a few things here and there. Cryptography is a fun subject. I’ll throw out a few questions, and the same rules apply - ignore anything worth ignoring, and ignore all if you’re busy, I’ve enough to keep me going here for a year or two already

1. So the whole Network isn’t the Mint - it just has the capability to create ad hoc Mints as the need arises in an efficient and probably ridiculously scalable way?

2. These lovely little “constellations” then - they’re trustable because they’re built with time-tested cryptographic primitives? I believe it’s true that the trustability of the mint is where the DBCs value comes from, so I’m asking explicitly.

3. I’m presuming XOR closeness plays a role here - I’m imagining a client asks the network “hey, can I get this DBC reissued?” does some hashing itself, maybe a sneaky little Pedersen commitment at this stage (?), and then that hash is used by the Network to find peers that are “close” in XOR-land? If that’s how it works roughly, is the job of selecting nodes close to the address of the DBC done seperately to the job of, say, storing a chunk?

4. The DBC is then just a special data type, with an input and an output field, or some such? I think I saw this somewhere, but just to check.

5. This is perhaps the largest question: where do VRFs, bulletproofs, BLS signatures, Pedersen commitments, etc all fit in? Which key derivation function is used, is that the VRF? Is it possible to describe (from about ten miles up) where each one of these plays its role?

My last question is the one I’m most interested in, I’ve spent the better part of the last 24 hours trying to read up on these and guess where they might fit in to it all. It’s a bit of an onslaught of vocabulary for the moment, but it’s fun riding the waves.

Thanks again for the great explanation, I’ll keep plugging away in any case.

EDIT: rediscovering this now Update 22nd July, 2021 - #17 by danda and answering a lot of my own questions. I was stuck in wikipedia and note-taking yesterday, and hadn’t arced back to reading the forum again and comparing notes etc.

[Southside]

for point 4 https://github.com/maidsafe/safe_network/blob/main/safenode/src/protocol/messages/response.rs may have clues.

I just grepped the entire safe_network dir to try find the DBC data cos
when you run safe -h on the latest from GitHub its got more interesting stuff in it

willie@gagarin:~/projects/maidsafe/safe_network$ safe -h
Usage: safe [OPTIONS]

Options:
      --log-dir <LOG_DIR>
          
      --wallet-dir <WALLET_DIR>
          The location of the wallet file
      --deposit <DEPOSIT>
          Tries to load a hex encoded `Dbc` from the given path and deposit it to the wallet
      --send-to <SEND_TO>
          This must be a hex-encoded `PublicAddress`
      --send-amount <SEND_AMOUNT>
          This shall be the number of nanos to send. Necessary if the `send_to` argument has been given
      --upload-chunks <UPLOAD_CHUNKS>
          
      --get-chunk <GET_CHUNK>
          
      --create-register <CREATE_REGISTER>
          
      --entry <ENTRY>
          
      --query-register <QUERY_REGISTER>
          
      --repeated
          
  -h, --help
          Print help

and now I want to play with DBCs again.

@JayBird

I’ll throw out a few questions

Thank you for articulating the questions I wish I could ask myself.
And above all thank you @oetyng and everyone who helped him produce this work.

[danda]

@Southside

I just grepped the entire safe_network dir to try find the DBC data

I believe the core dbc code is still in a separate repo/crate: GitHub - maidsafe/sn_dbc: Safe Network DBCs

[oetyng]

@Southside

And above all thank you @oetyng and everyone who helped him produce this work.

That’s @danda and @davidrusu who built the dbc code. I’m using that to build the features of the network (transfers, wallet, faucet, data payments etc).
I have been making some cosmetic changes and refactors to dbcs, but the foundation is all them.
Then there is a large change in how dbcs are made valid in the network, and the implementation I did there, but all that comes from @dirvine’s design.

(nanos gigantum humeris insidentes)

[oetyng]

@JayBird

ignore anything worth ignoring, and ignore all if you’re busy, I’ve enough to keep me going here for a year or two already

JayBird, you’re such a nice person

@JayBird

1. So the whole Network isn’t the Mint - it just has the capability to create ad hoc Mints as the need arises in an efficient and probably ridiculously scalable way?

Actually, the whole concept of a Mint is thrown out of the window.
The network isn’t minting anything. There was a birth of all the tokens at a time. The genesis. After that, MaidSafe transferred out all where it was due, to share holders, to MAID and eMAID holders etc.
And after that, everyone does whatever they want with their tokens. The network has no say in that. They just check if your transfer to the guy over there is of the correct amount and your money came from valid places and all history of your tokens check out etc.
And if all is according to protocol they store that transfer, and they will give it to you when you ask for it. And that’s how your pal knows the transfer is good. And everyone else in the world.

@JayBird

2. These lovely little “constellations” then - they’re trustable because they’re built with time-tested cryptographic primitives? I believe it’s true that the trustability of the mint is where the DBCs value comes from, so I’m asking explicitly.

They are fantastic, aren’t they
They are trustable because they come in numbers. And there is no way to get enough number of your corrupted peers into that group, without breaking cryptographic primitives. At least that’s the proposition. And from what I can tell, that’s what’s actually happening in code as well

@JayBird

3. I’m presuming XOR closeness plays a role here - I’m imagining a client asks the network “hey, can I get this DBC reissued?” does some hashing itself, maybe a sneaky little Pedersen commitment at this stage (?), and then that hash is used by the Network to find peers that are “close” in XOR-land? If that’s how it works roughly, is the job of selecting nodes close to the address of the DBC done seperately to the job of, say, storing a chunk?

A client doesn’t really ask the network if they can get it reissued. Sod the network. It tells it, here I’m reissuing this, please tell the world this is all valid!
And the network, as long as they follow the protocol, obeys and does what the client says. IFF the transfer checks out.

(This is the brilliant part of it all.)

And all the rules in that protocol, what constitutes a valid transfer, we’ve covered. But don’t hesitate to ask more about it, because developers always get blind to what is actually percievable by others

@JayBird

5. This is perhaps the largest question: where do VRFs, bulletproofs, BLS signatures, Pedersen commitments, etc all fit in? Which key derivation function is used, is that the VRF? Is it possible to describe (from about ten miles up) where each one of these plays its role?

Ook, I’ll come back to this. I need to go to bed.

Thanks for asking these questions so kindly

[JayBird]

Absolutely wonderful, again!

I’ll need a few days to digest all this but it’s totally great. Great exercise for the ego too to show one’s ignorance and ask questions that are totally beside the point in reality. For example, I had heard ‘genesis’ mentioned and not clocked at all what was being referred to. Now it’s far clearer, goodbye mints, my understanding has inched slowly forward.

What of spentbooks? If I’m reading correctly, there are none anywhere. So I am curious - in what sense are we looking at DBCs? The thing you (and @danda, @davidrusu, @dirvine, etc, in alphabetical order) have finished on here is new, of course, but I wonder if it’s still in the DBC category. In the literal sense of it being digital, and being passable from hand to hand with no obligation on disclosing one’s identity, then yes. Hmm. It might be closer to cash though, in the end, with the kind of “mostly quite anonymous if you’re not being tracked otherwise” feel to it.

@oetyng

They are trustable because they come in numbers. And there is no way to get enough number of your corrupted peers into that group, without breaking cryptographic primitives

This is just the magic of the hash function, I guess? Your node ID gets randomly assigned, you can’t walk back those one-way-functions, therefore no populating a close group of your choosing? The only option available to you then would be flooding the network with new nodes, crossing your fingers and hoping that they end up close to each other and close to the address where the DBC gets randomly assigned to, which is just farcically unlikely in that massive XOR-space? And even if you somehow got those nodes around the DBC, you’d be able to do what… not impact any other DBCs anywhere?

If clarifying the above requires a full description of how the cryptographic security works, maybe do leave it for another day

I’ve been getting a bit lost again trying to understand the maths behind the cryptography today, and looking into these one-way-functions a bit more - I feel I’m only touching off understanding, but it seems quite nuts that it all works. If there’s one thing I’m feeling finally trying to dig into what makes Safe what it is, it’s that - you take a toolbox full of cryptography, all based on some wild mathematics, you shuffle it all together, hunting for simplicity and “natural”-ness all the time, you persevere for 5, 10, 15, 20 years… and then suddenly you’re looking at what you people are looking at in front of your eyes, taking shape. Or maybe, rather, revealing itself

And imagine that our societies produce people who think “numbers” and “computers” are boring subjects! Totally nuts. A quote I came across today from (hyperbolic) mathematician Leopold Kronecker says:
“God made the integers, all else is the work of man”.

[nos]

“God made the integers, all else is the work of man”.

Awesome Phrase

[oetyng]

@JayBird

What of spentbooks? If I’m reading correctly, there are none anywhere.

The spentbook is really the entirety of the network.

A single node stores individual spends.
A close group stores the (completely unrelated, if not then purely by chance) spends that happen to fall into their range of responsibility.
The collective store of all nodes in the network, is effectively “the spentbook”

@JayBird

This is just the magic of the hash function, I guess? Your node ID gets randomly assigned, you can’t walk back those one-way-functions, therefore no populating a close group of your choosing?

Yes, described it in another thread yesterday:

@dirvine

Then what we can do is limit how nodes join, but not prevent any node joining. So list where they join and ensure offline keys are useless. It works like this

• Node creates a keypair (BLS)
• He gets the X closest nodes to the keypair (say X == 4)
• He derives a key from that old key plus the hash of the closest nodes to that key.
• He joins the network at the new key.

As the network churn there is a time limit on him joining as the closest nodes to teh old key will change. So he may need to do this a few times.

This means a node cannot target (easily) a close group and make it infeasible to do so.

@JayBird

The only option available to you then would be flooding the network with new nodes, crossing your fingers and hoping that they end up close to each other and close to the address where the DBC gets randomly assigned to, which is just farcically unlikely in that massive XOR-space?

Yes

@JayBird

And even if you somehow got those nodes around the DBC, you’d be able to do what… not impact any other DBCs anywhere?

Yes

Missed one Q there I see.
If you have majority of the close group, then you can “forget” spends, refuse to take spends, take invalid spends.
The most dangerous of those would be to take and serve invalid spends. But that isn’t dangerous enough, because there should be other layers (like an additional close group, partial DAG audit nodes, full DAG audit nodes).
It should be practically unfeasible by all measures to overcome the collective truth and replace it with your own.

It wouldn’t even be enough to have a majority of the nodes in the network, because in the end those false spends doesn’t actually check out when validated, and there’s enough with one honest DAG node holding it all (or a partial DAG node covering the branch of the counterfeit dbcs), and you’ll be able to mathematically verify the truth.

But then again… theoretically, the attacker can create a new genesis, and hope for people not knowing about the old genesis, and then a user would be standing there with a whole bunch of dishonest DAG nodes, and a single honest one, thinking “well, that’s the majority so…”.
But it requires that the real genesis is “forgotten” so people don’t know what to trust.

It’s somewhat like creating a fork without the world noticing, and somehow making them all switch over to it.

[LOvisWaTer]

Oh, my current projects being developed have the SAFEnetwork in mind. One specific use case in my decentralized applications are all going the direction of integrating zero knowledge proofs, ZK snarks and HALO2 type stuff. Is there any application there to improve the stack even further?

@dirvine we have made significant progress in merging your white paper on self authentication into the Decentralized networks, using our electrophysiologic heartbeat signature that every living being on the planet has.

Once this network is launched, the next step will be identifying a quantum soul signature with enough entropy to identify an individual possibly through a reincarnational event so we would be able to access our unique bSAFE network in future life’s.

[Southside]

@LOvisWaTer

our electrophysiologic heartbeat signature

Proof of Unique Human? - to resurrect an old long-running thread on the forum.

Proof of unique human

Last night there was an interesting discussion about limiting the number of accounts per person. It was started by @dyamanaka and several others started to chime in. @benjaminbollen suggested a captcha type mechanism to at least prevent or hinder bots. The conversation moved on and this is where I think there is an interesting possibility. Imagine the network could take some proof of you as a human and this proof were unique. If this was hashed then the network could allocate you the right to c…

[Southside]

@LOvisWaTer

Once this network is launched, the next step will be identifying a quantum soul signature with enough entropy to identify an individual possibly through a reincarnational event so we would be able to access our unique bSAFE network in future life’s.

The best of luck with that

[LOvisWaTer]

Yes we each have a unique electrical signature and I was just bringing back this research to comparing it to the 2 trillion entropy of IRIS scan.

One product example for HB is https://www.nymi.com/nymi-band

For the Iris scan and proof of human and life can be found at the Port Link crypto project.

Some interesting crypto applications that we will integrate into our bSAFE network is https://fortknoxster.com/

[Southside]

@LOvisWaTer

bSAFE network in future life’s

bhuddistSAFE?

Luckily I am not in grammar-nazi mode or you would be one life down for the abomination that is “life’s”