Maidsafecoin is blockchain-less? Someone explain that to me?

How Does Safecoin Differ From Bitcoin?

David Irvine explains… “User Defined data” of a SafeCoin
can hold a file/directory (no blockchain bloat issues cos SafeCoin
confess with its own storage, accessible to everyone, free, all the time

  • nothing to pre-download as in bitcoin-QT).

“Coins are held as group data and maintained by that group, so not
distributed like immutable chunks, but managed more like
structured_data_versions.” ~ David Irvine (forum post2)

How is “user defined data” and “group data” secure from money printers and double spenders?

1 Like

Maybe you can start here:

It’s been a while since I’ve read it so not sure if it answers your specific questions but it’s a good read!


Dude listen to this

John Ferguson is our legendary voice, it also useful to listen to his other podcast

@Melvin why read when you can listen? Have fun bro’s :stuck_out_tongue:


This one might help as well.


Short answer is that user defined data is not protected in the same way.

The key datum you seem to be missing is that safecoin is a “reserved type-tag” of structured data. It and its parameters will be defined in the core software. It and how it is to be handled is therefore recognized by all actors. Any mishandling of it would be recognized by the relevant consensus/monitoring groups and the perpetrator’s error/intention would not prevail, and the errant actor would be deranked or disconnected.

The quote you refer to is about user-defined, or application-defined structured data.

I think there actually must be ways to make user-defined currencies which are pretty well protected from counterfeiting, etc., but that’s honestly over my head just now.

But safecoin is a data type which is defined and uniformly recognized and handled at all relevant levels of the core software.


That’s a really good summation Rene. I’ll put it in my tool kit. :grin:


A lot of answers are already posted. I just want to add one more thing…

Unlike bitcoin, safecoin does not move anywhere. The coin virtually stay in the same place forever. It uses structure data (key / value). When it is exchanged, the ownership key is changed. It then propagate through the network by using flood algorithm. It is very similar to usenet. That’s it. With this, it theoretically can do up to million transactions per second. All it has to change is one line in the coin whereas bitcoin, the transactions hashes are changed, stored in a block, and then wait for up to 10 minutes for approval by the consensus. It’s like analog virtual coin. It’s slow, and bloat fairly quickly. Blockchain size continues to grow exponentially. Safecoin size remains the same forever.

Edited: I got a new question

Each safecoin holds 1mb, right?

So that means it will be 8 billion mb in the network? That’s about 8000gb?


Small precision: They do not move in the XOR space, but associated SDs will physically move from vaults to vaults when churn events are triggered.

Each safecoin is stored in a SD whose size is 100 Kb max. The real size will depend on the payload but I guess it will be largely less, let us say 1KB. If we suppose the SD will be stored 6 times (regular + sacrificial + backup, 2 of each), then 4 billion safecoins will need 24 TB. This is a maximum size that will never be reached because not yet issued safecoins do not exist in the network, and recycled safecoins are deleted. The initial size will be 1/10th of this for safecoins issued from IPO and otherwised reserved, then the size will permanetly increase and decrease depending on farming and recycling.


I track with the rest, but I think this is not correct. As I understand it, all safecoins will be created and exist on the network at the time of implementation. (Not sure about sacrificial copies on structured data, but we’ll assume them for now.) The only changes will be in ownership–or lack there of, in the case of new or recycled safecoins.

My point is that the amount of storage that safecoin will take up should not change, at least till divisibility is introduced. Then it will grow by whatever multiples are enabled.

Why do you think this? To me, it doesn’t make sense to do it this way. Much better to create the data when a coin is first issued.

I concur about deletion though - I do not believe coins are ever deleted, though I’m not sure it would be a problem to do so when returned/recycled to the network.


Not sure what you’re talking about here. Safecoins are structured data which have their XOR address in multiple copies. As these are transacted the update to ownership is made by the holders of those data, whomever is involved are informed of the successful transaction, and it’s done. No further propagation is needed.


I thought they didn’t exists from farming attempt description:

This is confirmed at the receiving group and they check for the existence of a safecoin space (ie, there is no safecoin with this name). If this is successful then a further check is made to confirm there is a DataManager group (implicit as routing does this). A safecoin is then created and a message sent to the wallet holder of the request

I interpret “existence” and “created” words literally but maybe I am wrong.

Following is a quote from a portion of the Class IX podcast. I ran the whole section past @dirvine before doing it because I wanted to ensure I had the whole thing straight before I did and he gave the whole bit the thumbs up.

“Upon implementation, all safecoin’s will exist in the network as specific type_tag’d network addresses. Initially, they are unowned. They contain fields for current owner and previous owner. (If there’s any other data in them, it’s not relevant to this example).”

Perhaps he skimmed and missed this point, but it made sense to me that it would be this way because of the fact that elsewhere it says a random safecoin address is queried to see if it is owned. This would mean that the address had to be at least accounted for, but if not already there, a mechanism for creating it at that moment would have to also be in place. That’s much more complex than just creating them all at the same time, so that they are then placeheld, etc.

Of course, I definitely could have this wrong. It’s also possible that this point hasn’t really been decided in exact detail.

EDIT: I also preambled the whole lifecycle of a safecoin bit with the following disclaimer:

“The following description is not accurate in exact technical details, but is effectively how it will work.”

It doesn’t really make a difference from a higher level of safecoin function, but when it gets down to discussing exact implementation, it does. So I’d have been better off not making the point here, I guess. :blush:

Very good point. I see what you mean. Oops on my part, I guess.:blush:

Though I’m pretty sure I ran into it elsewhere phrased as checking to see if that safecoin was “owned”. But the reference you quote is the RFC so likely more accurate.

I don’t think this should be taken to mean the coin itself is stored, so I’m not surprised David would ok this if the coin itself is not stored at this point.

The reason I was skeptical is that it makes more sense to allocate storage as coins are issued. Creating them from the start would be difficult technically, and put unnecessary strain on the network. I can’t imagine how it could work technically! :slightly_smiling:


It would seem your reading is correct. But since this has yet to be implemented in code, there is every possibility that it can easily change. Its not something that will affect the actual operations of safecoin and issuance attempts if changed to never deleted.

I would not be surprised to see only the IPO coins stored and as a coin is issued it is created. But when recycled it is simply marked as unissued and the issuance attempt algorithm simply checks for non-existence or unissued.

The reason I say this may stem from my ignorance on the topic of SD deletion. Do they get deleted or set to an unused state?

1 Like

Yes, safecoin is a specific type tag so we can tell if it exists (then it’s owned) or does not exist (and can be farmed). So it is blocked out by the network from normal users uploads of this type but farmed on demand. So basically it does not exist unless farmed, but the type tag in it’s entirety cannot be created by users/clients and is only created by the network.

Hope that makes sense.


So when it is spent on storage, etc., it is destroyed, i.e., erased completely?

1 Like

Yes exactly, so again able to be farmed.
[edit] I should say it is created by a group for a client (not signed by the original owner) but then on xfer signed by origin owner to new owner.

Other data types can follow the same pattern if coded into vaults (pretty easy now, so watch for computation)


You are right, of course, Mark. I’m just taking the opportunity to be the simpleton who knows just enough to be certain of wrong things. :wink:

1 Like