Prevent double spend without Close Group Consensus

Just trying to get my head round how double spends are prevented without a blockchain. In particularly after reading https://blog.maidsafe.net/2015/01/29/consensus-without-a-blockchain/.

It says that Close Group Consensus is not used for sending safecoin to another user. I understand a cryptographic signature proves the sender is who he claims to be but how do we verify he owns the coins without looking up ownership from the distributed hash tables?

If we do have to lookup ownership info how do we trust without getting consensus from the close group?

I have searched the old forums as well, I found https://groups.google.com/d/msg/maidsafe-development/BO5OIGd4zjk/S7svAJZhoVMJ but it really only says “the network atomically transfers ownership” without explaining how it confirms the current ownership (or records the new ownership) before doing the transferring.

2 Likes

It’s actually super simple

The SAFE Network won’t verify a transaction unless the coin info (addresses, etc) are valid and pass consensus.

If it does, then the transaction goes through and the coins are moved.

Don’t need a blockchain. Just need to check the coin addresses and make sure they’re correct, pretty much. Then the changes are made in the network. A super super condensed explanation.

1 Like

You are the owner of address “kdgkdhasgkdskdas” in the network. This address is looked after by the group that’s most close to this address. So let’s say it’s group 0100 that’s responsible for this address. They know:

  • We are group 0100 and are responsible for this address: “kdgkdhasgkdskdas”
  • It’s in their list of ownership and assigned to you as user “XYZ”

So when you want to transfer your coins (address) to me it goes like this:

  • send a message to your own group saying; I own 1 Safecoin with address: “kdgkdhasgkdskdas”
  • your close nodes connect with group 0100 and ask them it that is correct.
  • when it’s confirmed by group 0100 your close nodes will forward your signed message to transfer the ownership from your wallet_address to my wallet_address.
  • group 0100 now learns that address “kdgkdhasgkdskdas” is owned by me instead of you and sends a confirmation back to your close nodes.

You no longer own the coin now :+1:.

12 Likes

The coin doesn’t move like bitcoin does. It stays in one’s place. The only thing that is moved is the signature of the coin.

5 Likes

That’s one part, but how do you know for sure that the data you’re receiving is true? In Bitcoin if you’re being fed a fake block by a node you’re connected to you can detect it by looking at the proof of work inside the block. How do you know an ImmutableData’s owner isn’t being changed by one of the intermediary routing nodes? My own understanding of that part might not be up to date so I won’t try to answer that question here myself.

3 Likes

I’ve been away from the project for a while unfortunately, but it would stand to reason that signing the message would solve this problem. Sure, an intermediary may modify something, but then the signature wouldn’t be valid. Depending on how its implemented, the recipient group could be waiting for 28 of 32 signed messages (group consensus) or an N of M single signed message. Both of which would prevent falsification.

1 Like

Yes, but how do you verify that the signatures really belong to the genuine close group?

1 Like

This was one of the reasons for Disjoint Groups:

More secure group messages

The group messages do not provide a high level of protection against attacks on the network, even under the additional assumptions that routes are disjoint and that a quorum of the individual messages need to be intercepted. Assume that an attacker controls 10% of all nodes in the network, and group size is 8 and quorum size is 5. Consider a section message sent via 10 hops.

In that scenario, the chance to intercept any given group request is 71%. With the section-to-section hops proposed here, it will be just 0.43%. Further adjusting the section size and quorum size parameters, this can be reduced to a negligible number, making this kind of attack virtually impossible.

And every group that routes the message needs to group_sign it as well. So if an address is 6 HOPS away you’ll see 6 groups group_sign the message before it gets to it’s destination. Groups know more about their close_groups as well with DJG implemented. So taking over 1 group wouldn’t even be enough to fool the network IMO.

9 Likes

For retrieving data we get consensus from at least 28 of the 32 closest nodes. However, when it comes to moving safecoin it specifically says it doesn’t use this close group consensus for efficiency reasons. I presume because we don’t move coins from one address to another but rather change the ownership of the actual coin. Therefore, if I wanted to send, say, 1000 coins the network would need to verify ownership of each individual coin which would involve 32,000 requests to the nodes to get consensus.

Your answer introduces a group that is responsible for the “address”, when you say address do you mean the coin id or address? Who makes up this group and what keeps them honest? It can only be some kind of consensus, most likely another close group.

  • If, when you said address, you meant the coin ID then you have the same problem, you need to reach consensus for every coin in the transaction. You haven’t gained anything by introducing the group.

  • If you meant the group is responsible for the address the coins are stored at (i.e. keeping a record of the address balance) it would begin to make sense. However, this would also be the first time I’ve seen this explanation with Maidsafe and I suspect it is not what you meant because you say “group 0100 now learns that address “kdgkdhasgkdskdas” is owned by me instead of you” which suggests you did mean the coin id because you wouldn’t transfer ownership of a wallet address.

1 Like

This is the old paradigm where every node had 32 close nodes from it’s own perspective. Since late 2016 we’ve moved to Disjoint Groups:

Minimum group_size is 8 nodes.

Yes, this will be implemented in some way as you can’t split an address. But assume for now that group 0100 is responsible for all coin_addresses that start with the letter A. So it’s something like:

We are group 0100 and we are responsible for all addresses that start with an A.

Address “Afhjgfkjghfkjaghfkjhgrjebvhnjdfn” is owned by public key: “00xxhwbglqwhgbwqhbghqwbg”

So they have registered that you own the coin as you own the private key of that public key.
Next you write a message to your close nodes (let’s assume it’s 12 of them) and they will connect group 0100 to see if you (with your private key) indeed own address “Afhjgfkjghfkjaghfkjhgrjebvhnjdfn”.

if this is the case you send another signed message that says: I’m the current owner, this is my private key, please change ownership to “00xxgsjbhsgjbhgjsbhgjsbhjsb”. If all is checked and signed 0100 know has in its register:

Address “Afhjgfkjghfkjaghfkjhgrjebvhnjdfn” is owned by public key: “00xxgsjbhsgjbhgjsbhgjsbhjsb”

Something like that.

1 Like

Thank you for the reply.

We may have to add some comments to a lot of existing docs and blog posts because there is a lot of stuff out there with the old info which will lead to misinformation on how things work.

Is it correct that this only makes getting consensus more efficient and network attacks less effective but in itself doesn’t change the workflow of transferring coins?

To say it will be implemented in some way sounds like either the solution has not been found yet or there is more than one solution and a decision hasn’t been made. Considering this is the whole premise of eliminating the blockchain need, this is an important issue that needs clarification.

I’m not saying it can’t be done. A triple signed receipt in the way Open Transactions intended to implement Ricardian Contracts might well work, just using the distributed network as the validation server. This just isn’t how I understood the Safecoin system had been presented previously so it would be nice to what we are invested in.

2 Likes