only distributed groups of 32 anonymous nodes are needed for consensus, compared to every full node on a standard blockchain.
both data and it hash can be stored on the network without any additional software, compared with only the hash generated by a supplementary application and separate data storage.
transaction times are of negligible resource cost, compared with high resource cost.
transactions are near instant due to small consensus pool, compared with delay (usually minutes) for full network consensus.
sequence chains can be built from hashes of previous data being stored in subsequent data (along with time stamps etc), compared with having to compete for block space.
anonymous transactions, due to atomic data transfer operations, compared with a public ledger with blockchains.
So, it seems safe net can do the following better than blockchains:
Cryptocurrencies more like cash.
immutable storage of event sequences.
hashed storage of data to time stamp and protect against fraud/corruption of data.
There may be others and safe net can do far more beyond this sort of transactional behaviour.
In conclusion, I suspect safe net will make blockchains obsolete, as the core use cases can be handled more efficiently via safe net.
One of the points of safecoin is that there is no history to analyze. Each safecoin knows who its last owner was and who its current owner is. That’s as far back as the history goes. And I for one do not want any kind of extra layers on top of it to make snooping or other analysis possible.
The Bitcoin network’s reliance on ASICs really makes it difficult for the unbanked to gain access to the bitcoin network. Mining is now pretty much for the privileged and having a mechanism (like farming) that makes obtaining a transferable token of value (safecoin) remain accessible is really significant.
@Traktion Now that is fascinating! Is it already in the most wanted app pile? This exact subject comes about the triple ledger over and over but it never seems to be suggested that SAFE attempt it. Why not?! Build it in Rust. Already seen it in action and know the concepts works. Now just try to translate and possibly improve it. What was suggested before is that the bitcoin platform is inherently better for it. Is that still the case?
Sure, but you can insist that the transaction must be published publicly for it to be recognised. Ofc, safe coin transfers are always going to potentially happen secretly, but if you want a ledger to represent asset transfers, the ledger is the proof of ownership.
To put it another way, on a blockchain, there is no physical transfer of data - the ledger is the only place that ownership is derived.
@Seneca actually put the thought in my head earlier in the week. We can create linked lists, where the hash of transaction n defines the address of transaction n+1. This allows us to define a sequence of transactions and define a standard format to describe the payload. Each transaction in the sequence could be first come, first serve for simplicity.
As for what the payload could be, it could be anything really, as long as it fit the specification.
As there would be a PUT fee, there is natural spam protection built in.
True, this way it could be done. Though it’s opposite of native ownership of a digital asset on SAFE, which is determined by the owner field of a StructuredData object. I suppose to transform (import) such a native SAFE digital asset to a ledger asset, the owner field of the native SAFE asset could set to the hash of the ledger transaction that determines initial ownership inside the ledger. The native SAFE digital asset then permanently “belongs” the the ledger itself, at least on core SAFE level. On the ledger level, the transactions in it determine the actual owner.
To clarify to anyone wondering, because on SAFE a PUT is an atomic action this effectively solves the double spending problem. One cannot be unaware of any existing transactions when making a new one, because if one is then the address of one’s new transaction is already in use.
Its kind of like finding a black swan, the first instance means we can’t insist Swans are White. When the last reservation is removed the dam breaks.
May be worth noting that this means that the “block” speed per second approximates the network speed of one GET plus one PUT. A “block” may be just a single transaction, but can also be many transactions put into one “block”. I suppose centralized exchanges and such will put many transactions into one record, but individuals or actors who prefer to operate without a middle-man may submit such a block with just a single transaction. If the latter will be commonplace this type of ledger would merely have 2 or perhaps 3 transactions per second.
Interesting! It would be great to be able to combine the actual digital assets with the ledger in some way.
I am not aware of how or whether you can do what you suggest with the owner field, but it would be interesting to try it!
One other thought I had was that the transaction payload itself could be encrypted. At least this could transfer some data without making the details of the transaction public. That is, you would know a transfer had taken place, but you wouldn’t know what the content was.
I think there may be a few ways to skin this rabbit! What is obvious is that being able to store large amounts of data within the transaction (or directly addressable at the safe network level) is a huge advantage over blockchain technology - the cost of storing anything large directly in the ledger is prohibitive, as every node has to store it forever. Safe net only needs a hand full of nodes to store a copy, making it massively more scalable.
Moreover, there is nothing stopping us having many ledgers, storing a number of different things. They all would share the same client (safe net client) and storage space will essentially be massive (i.e. as much as vaults can provide).
With this in mind, why not have a different ledger fpr tracking different things? You could hve one for diamonds, one for cattle, one for title deeds on properties, etc. You could even have regional/subsets of needed.
What would this mean? Any transaction speed issues could be side stepped by going parallel and creating another ledger. Which, in a decentralised network, makes perfect sense of course!
[Edit: ofc, we still have an upper bound for transaction speed based on @Seneca notes above, but it would mean this would be less likely to be an issue. Considering Bitcoin can only process a handful of transactions per second (iirc), we will only be improving on this also]
What if you want to buy some cows with diamonds? If they’re on the same ledger you can exchange them in a single transaction, but if they’re on separate ledgers you can’t.
Anyway, odds are that most transactions on SAFE won’t be using a public ledger and are done natively, with anonymity. Organization using a public ledger for a proof of transparency are less likely to constantly make micropayments, and are more likely to group payments in one “block”. So speed may not be an issue.
A current owner can put anything in the owner field, though I just realized it’s only 256 bits long, so using the address of a “block” (512 bits) won’t be possible. I guess using the SHA-256 of the address might be adequate though?
Another issue with this simple plan of importing native SAFE assets into such a ledger is that you can’t import SafeCoins, because a representation of a SafeCoin in a ledger that isn’t an actual SafeCoin isn’t recognized by the core network as such and thus can’t be used to buy resources from the network.
Maybe this approach is silly and using native SAFE assets in a ledger is as easy as putting the receipt (the proof of transaction traditionally created by the Transaction Managers) of a native SAFE asset transaction into a block. This way it is proven that the receiving party got ownership of the asset.
The status of that ownership can be tested by simply GETting the StructuredData info of the asset and checking the owner field. If the owner has changed and there is no record of another transaction in the public ledger then that’s proof of lack of transparency. A simple script that uses this method can then be run by anyone to automatically audit the assets of an organization.
Maybe using this approach organizations may just as well start their very own public ledger rather than all of them using the same one(s). Because when providing proof of transparency the only thing that matters is that particular organization’s inputs and outputs.
So an organization would merely need to publish a “genesis block” of their public ledger on their website/portal and their account address. Anyone sending assets to that organization can find their public ledger using the genesis block. Then they send assets to the organization’s address and append the receipt (proof of transaction) to their public ledger. When a company transfers that asset elsewhere they also put that receipt in the public ledger. They can then be held accountable for that transaction, or lack of transaction if the ownership changed without a receipt being in the ledger.
Using this method, is there anything left that the blockchain offers that SAFE can’t?
Blockchain technology is a time tested solution to the double-spend problem.
From the Bitcoin Whitepaper:
A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem …
Fill in the blank: SAFEcoins solve the double spend problem by __________________________________________
The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they’ll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.
So far there has been no concise, easy to memorize, repeat and explain answer to this question:
How does MAIDSAFE solve the double spend problem?
It’s sort of embarrassing when trying to explain maidsafe as a potential replacement for bitcoin when you get to this question, because it is the obvious keystone question upon which everything depends. Would appreciate candidate answers to prevent future embarrassment.
