Avoid double spending

I’ve read through the blog post on consensus http://blog.maidsafe.net/2015/01/29/consensus-without-a-blockchain/
and the FAQ. But I still have some questions on how you avoid double spending?

Let’s say I send a safecoin to Alice and then 5 min later send the same coin to Bob. How does Bob know I sent the same coin to Alice? Asked a different way. How do you make sure everyone knows the coin has been spent?

You cannot, when sent the network changes owner. You cannot now say you are owner :wink:
So new person checks if the cash is sent to them, it cannot be unless it’s now owned by them so atomic on the network.


Hello, welcome to the forum.

Safecoins are actually data, and they’re stored on the network. So, to keep it simple, there are 10 coins, and each coin has an address. The addresses are 1,2,3,4,5,6,7,8,9,10. You have the ownership of coin nr. 9. So when people look in box nr. 9, they’ll see that the owner is “GkiuNBbmfghLKJm,bkhgkouyoyo”. And that’s you! So when you want to pay to me, you’ll sign a message using a “digital signature” which says: "Hi, I’m GkiuNBbmfghLKJm,bkhgkouyoyo and I want to give the ownership of this coin to CghHJGjhkjkjPJopjpRYYRkjklj. A close group of transaction managers will get your message, check the digitale signature and lookup who owns the coin at address 9. Now they see that it’s indeed you. So they’ll execute your request and change the ownership from your address to mine (the group signs that request as well). So as long you can prove to be you (have the private key to create the digital signature), you can do transactions when you have coins. But when you send your coins to someone else, it’s registered in the network that you no longer have the ownership.


OK that was absolutely a nicer & better explanation :smiley:


I was almost done when I saw yours coming in hahahaha.

Thanks that was quick :slight_smile: So the coins are stored in something like a DHT? (new to maidsafe)

No, more like address spaces on the network. Although they use hashes. Maybe this one is a bit off, but on the normal internet you have a site like cnn.com. It’s free and open for everyone to view. And everyone can loop-up who the owner of the website is. Same for Safecoins. So groups and nodes in the network can lookup a Safecoin-address and see who the owner is. If there’s no owner (no Safecoin) at a particular space, that means that that Safecoin is not yet created. This also makes sure the number of maximum Safecoins is capped. Because when you run out of addresses, no new Safecoins can be created.

No worries, feel free to ask.

Okay I thought transaction managers were on the way out? And safecoin was going to have its own unique data type. Am I incorrect here and could you please explain?


Yup, I think that’s correct. I’m describing the older way, I’m not really in to the new way yet :wink: But after all, it still works with ownership etc. So even without transaction managers, you still need groups consensus, addresses etc.


Can you point me to a place I can read about this?

I would like to know more about how these addresses work

It can be very difficult to pull one aspect of this out an look at it out of context. I suggest a good study of the Wiki at https://safenetwork.wiki. It’s in there in an understandable sequence. This will give a foundation to build on, even if things shift a bit. It is a very intricate and elegant system designed to be autonomous, so it’s hard to go deep without getting a bigger context.

Ok I’ll start reading then :slight_smile:

1 Like

Yes this is the case, there may be a persona called StructuredDataManager, basically like a transaction manager, but instead of a set of proprietary elements these elements will all be data types (StructuredData). It allows for persistent storage later on which is something we must consider (worldwide electricity outage etc.). The issue is republishing in non persistent vaults, but it’s surmountable for sure.

This also means TransactionManager capability now exists for even user defined data types (the data part of StructuredData). So much more flexibility.


Which from what I’m understanding allows the ability to cryptographically sign over any type of data? ie Signing over/revoking the rights to a song or ownership of information/more control of data. This is all great info I feel pretty well caught up with the recent changes mostly

I’ll take the like as a yes, Thank you sir!

1 Like

Okay this part is news to mean (or perhaps it’s better to say this is the first time it’s been explained in such a way the implications would make sense) so do you mind explaining a bit more and elaborating?

yes, put it between “quotation marks” though :slight_smile:

Hey @Blindsite2k I gained the bulk of my understanding exactly here from David
RFC - Unified Structured Data
And there is another link I’ll try to add later
I’ll try to sum up even more, hopefully without messing it up. So instead of having your ID on some very ‘general’ piece of data, data types allow for ‘specificity’ and therefore to the program’s understanding, more control. Crypto keys from your ID that are signed to a certain data type lets you basically watermark any piece of data easily and have more control over it. ie sign over/revoke data(I’m not sure specifically how revocation works but I’m almost positive this is part of it), multi-sig data, make public or private (I believe this falls under this as well) etcetera. So as you can see way more control and granularity, so much better than legacy web. Brilliant in fact!


Is it possible to send a coin to two different recipients at the exact same time (i.e. parallel actions)?

If so, the two separate groups of nodes dedicated to validating the transactions might both think they are valid (if the new coin owner information hasn’t propagated throughout the system). How would the system determine what to do? In blockchain this is handled because only one of the blocks is confirmed (https://coinsutra.com/wp-content/uploads/2017/06/Bitcoin-Confirmations-e1498718174774.jpg).

If not, is it similar to a transaction lock (think: databases) around the transfer?

Any info appreciated. Cheers.

No, it is impossible.

Paraphrasing a little, but a section is responsible for each coin and participant nodes must reach consensus before ownership of the coin can be changed. No other section can change the coin and the coin can’t be reassigned without consensus within its section.


As @Traktion says this is not possible as you are imagining it. The transfer of the coin will need to go to the section the owners the coin. In both cases, this is the same section so it’s not parallel to 2 different sections if that makes sense.