Does safe net make blockchain technology obsolete?

I don’t mean to be obtuse, but banks have existed without blockchains for centuries. The concept of transactions, completed without public ledgers, has been a standard definition for even longer.

I am sure there is a use case for smart contracts, public transactions and the sort, but I don’t think we need to exaggerate the case for them. Anonymously, instantly, transferable digital cash/property is an extremely powerful concept, which imo, does not need the crutch of a blockchain for the vast majority of transactions.

I look forward to blockchains being implemented natively on safe net, but I see many trades being completed successfully without them.


I think what @et4te means is that when there is a need for a trusted ledger, something other than Safecoins are going to be the choice of medium, simply because they do have a trusted ledger, and Safecoins don’t. The fact that Safecoins don’t need such a ledger is a strength, but it would sure be useful if we had something like that optionally, just for when we need it.

1 Like

You can make public ledgers for SafeCoin.

But they will be optional

Nail on head. Safecoins are great at representing transferrable disk space which was their intended purpose but we should not forget the benefits that blockchain based currencies have which in the SAFE Net we lack by default. Finding a better solution than blockchains for what blockchains were designed for is not as easy as one would expect, even given the SAFE infrastructure and this is also my point here. I would love to be proved wrong though.

1 Like

Please elaborate. Do you mean you can make a blockchain which transacts with SafeCoin? Because we already have that. Or do you mean we can make a blockchain on the SAFE network?

Blockchains aren’t that scalable though. They can’t handle thousands of transactions a second, and it’s rather inconvenient that one needs a small datacenter to carry the chain. On the decentralization front, pool mining isn’t that hot, either (except the ASICs.) They are awesome settlement systems though.

1 Like

Yeah, you can make any or all of those.

I described something like that a few posts above, though it’s more of a directed multi-tree of transactions than a chain of blocks containing the transactions. I would be interested in hearing who thinks where it breaks, and what can be done about it :smirk_cat:

1 Like

I agree with both the above posts. Blockchains have inherent limitations as well of course like the ones you mentioned, however with SAFE you can make the blockchain stored on the SAFE network which would help the decentralisation of the transaction data at least - but yeah you get the problems that come with a blockchain as well.

@Tim87 Can you possibly elaborate on how this multi tree works? I might be able to help here. The post above this one was not precise enough technically for me to envisage implementing it.

A blockchain was originally a means to an ends - it is a design pattern which allowed the Bitcoin, the digital currently, to be implemented. Blockchains provide a mechanism to gain network wide consensus. That this could only be done in a pseudo anonymous way seems more like a design trade-off, than a design feature.

Ofc, there are use cases for having public transactions, but this is not what most people want in a currency. People don’t usually want other people snooping on their transactions and would rather they remained private.

That doesn’t mean we can’t create a blockchain on Safe Net. I just don’t see it as a requirement for people making Safecoin transactions.

1 Like

A native blockchain on Safe Net could be relatively efficient though. We don’t need every node confirming every transaction, as the safe network itself will take care of consensus. Primarily, we need to know is that some data was saved after some other data, which you can do by using the hash of the previous transaction as the key to the next (as discussed on this forum - Public Ledgers and Proof of Transparency on SAFE).

Let’s start with this this (stolen) image of a multitree:

The nodes (letters from A to U) are the transaction records. Let’s say ours is G, and only A, B, and C exist at the moment.

So, I want to add a record of my transaction (G) to the ledger. I attach the original details, but I also add a reference to B and C. I sign it and I throw it in the pool. With this:

  • I proved that this transaction was added to the ledger after both B and C existed
  • I proved that both B and C existed before G, which I’m aware is the same thing kinda, but it is semantically different :pouting_cat:

In the meantime came a couple other transactions: D, E, … H – they also signed some or all of the existing three. and this further increases our assurance about their place in the timeline.

With enough references between the nodes, it becomes very hard to pretend something was not where everybody else is saying it was.

When M and L arrives, my G is getting pinned down from the future as well, not just the past. Then comes P and Q and R, and S and T and U, and now good luck if somebody’s trying to say G didn’t come before M: nobody can disregard this many independent (as we want to believe they are) proofs.

Anyway, it’s a graph, in general, and a multi-tree, specifically: every node can have any number of parents and any number of children, and references can only go in one direction (you can’t reference a parent node.)

Word :smiley_cat: I hope you don’t mind my more rambling illustration of the concept.


Big problem is that Bob does NOT know the closed group handling the transfer of ownership for the coin.

Second Big problem is that Bob does not know the remote group verifying the coin transfer.

Your closed group will not be looking after the coin addresses of your coins, but a remote group in XOR space and normal IP space. Then the verifying group is yet another group.

1 Like

How do we verify the validity of transactions in a decentralised manner?

In your model, what is to prevent someone from adding X twice or to add a bogus transaction?

The nodes are SD blocks.

The validity of the transactions is already verified in the Safecoin layer. Here, we’re only concerned about the timeline.

You wouldn’t need to stop people from adding a transaction again: first, it would cost them money (the cost of adding an SD block), and then when somebody looked up the transaction, both the old and the new one would come up as a result. So yes, you could add it twice, but there would be no point.

For this to work, we’ll need to be able to search for contents in some way; it is currently missing, but @dirvine commented on something I wrote earlier today, and he said that stuff like that will be possible.

1 Like

You mean closed group consensus? What do you mean by the validity of transactions is already verified in the Safecoin layer? If you mean that Safecoin being owned by a particular person (i.e how the coins when transferred have owners), this doesn’t verify any validity of transaction it simply ensures that a particular coin is unique to its owner.

One of the main ideas behind having a blockchain is decentralised consensus. If you use quorum of 32 to reach consensus on financial transactions this has huge security implications. Besides this, I’m not sure I understand why ‘only the timeline’ is important.

I can’t talk for Tim, but I wouldn’t necessarily mix Safecoin with the ledger. I would just use the ledger itself to define whatever is being owned. Then you don’t have to tally the ledger with the assets.

This would then be like a regular blockchain, except that clients would have to validate the transaction authenticity, as anyone could contribute to a public chain. A bad transaction (invalid signature, invalid address, etc) could then be skipped over/ignored.

Note that these are fag packet ideas. I am sure more thought could/should go into creating a robust native transaction chain, which would do everything a blockchain does.

However, of you just want to present an audit trail, which can be interrogated against the actual state, you could do this (will collaboration of the parties involved).

Security is derived from how the quorums are formed. The entire network security rests on this, not just for any transaction chains. A blockchain is a brute force method of gaining consensus - ask all nodes and get a majorty decision. Safe net uses a more nuanced approach, which if sound, provides additional security over this approach (as targeting a group associated with the data is a hard problem).

Re the timeline, the sequence of events is the critical component. Obviously who and what was involved is also key, but sequencing is critical. Every link in the chain is key.


In SAFE we can have a ledger per product (coin/token) I believe. I think Traktion is also saying that?


Like @Traktion said, it all depends on how those 32 are decided upon; you can’t do much if you have no knowledge of or control over who’s in the quorum (i.e. whom to hack, bribe, etc.)

This ledger is just a web of certificates about arbitrary documents; if some (or most) of those documents are Safecoin transactions, so be it. It’s like colored coins, in a sense.

However, some could tie the ledger to external references, such as Bitcoin blocks, or blocks of other blockchains, or they could be timestamps by “trusted” entities (but everybody can decide whom to trust, so: no pressure, these are just random pieces of data, until somebody cares about them.)

That was in the context of entering a document about an already quorum verified transaction; if we already established the validity of a transaction (i.e. “X transferred Y N coins”), then all what’s left is to verify when it was done. In the absence of a globally trusted timestamp, that is only possible in relation to other things (but the blockchain does the same.)

I don’t claim this system will give you blockchain level confidence about the ordinality of all transactions, but I argue that it is not necessary in most cases (contributes to bloat), and unwanted in many (compromises privacy). In the cases when it is required by the parties for personal, business, legal, or any other reasons, they can just agree to use the ledger; in this system, the public ledger is not the basis of the transactions, it’s just an add-on, a clerical tool. Again, like colored coins: nobody forces us to use them, but when I want to enter a certificate about something in the blockchain, I have the choice.


block chain software are going to have side chains like RADS and IOC coin that is having unlimited side-chains. the choice will be if you want anonymous data or public data on the block chain In general I think business will choose blockchain over anonymous data. until humanity evolves…