SafeNetwork DBC Technical Series

[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.