Avoid double spending

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.


Also, if the section doesn’t achieve consensus of the transaction (because you sent the same coin to different addresses), you basically lose that coin.
So it is a natural deterrent to even attempt to do something like that.

Ok so if I understand correctly:

It’s not possible for two simultaneous transfers because the transfer of a coin (e.g. A to B, A to C) will always resolve to the same section of nodes (e.g. S1) – and therefore the two transactions will be handled sequentially (as opposed to simultaneously by different sections). If handled sequentially, it’s trivial to see if a coin was previously transferred and the coin is lost.

I was under the impression two simultaneous transfers (e.g. A to B, A to C) would be handled in parallel by two completely different sections (e.g. S1, S2), which don’t have any knowledge of the other – and therefore both believe each transaction is valid because ownership of the coin still belongs to A (i.e. hasn’t been updated by S1 or S2 yet).


Unlike Bitcoins which are numbers on a blockchain, Safecoins are actual files called MutableData (MD) entities (see Chapter 9). When a Safecoin changes hands the transaction is recorded as an entry in the MD. The full history of the coin is not recorded, unlike with blockchain-based currencies, just the previous and current owner, making Safecoin more like cash

@akumadevil you can see the SAFE network Primer here:


You can not give cash to two people at once, and SafeCoin is a digital cash :slight_smile:


SAFENetwork can be considered as a network of networks. Each section being its own small network which maintains data assigned to it. Sections can change in shape and size, splitting and merging as needed, but they always have authority over the data they maintain.

As the section is relatively small in size, it means consensus can be gained quickly without having to wait for the request to propagate around the entire network before a decision can be made (like a blockchain does).

The security model is more weighted to not knowing which section has any specific data combined with them being invite only to prevent people targeting the section to join. It is rather elegant compared to the brute force approaches of blockchains.

1 Like

Also the coin is an actual data object and as such there is only ever one coin. So no matter what happens there can only be one owner. So even if it was done in parallel the owner is still only one because it is only one physical data object stored on the network at a specific address (the coin address)