One of the original features of the Safecoin design was stronger transaction privacy, compared to Bitcoin.
From what I understand of Data Chains, mutable data (which includes safecoin) will have their entire history encoded in a data chain. Is that correct?
So, anonymity would still be greater than Bitcoin, but degraded somewhat?
No
You maybe able (not confirmed) to request a receipt which will be a copy of the safecoin (not a coin but a MD). But this is optional and will also invovle a feee since a PUT is done.
David has said that safecoin transactions will be free of fees.
5 Likes
Not quite. The chain is not the data itself but Data Identifiers. This is an identifier to identify the type and hash of data, but not owners or content. In option B where we do not lock all records in place these can also be deleted/removed to save space. The point of data chains in terms of data is
Proof that data was previously agreed to be valid on the network.
So no need to keep old identifiers (even) as versioned data versions as it’s wasteful.
However as @neo said as he ninja’d me above 
This now makes it easy to introduce a “ledger” field in mutable data. This was in the early data chains POC code and allows you to say I wish to keep this old identifier (for a put cost or similar) and it wont be deleted. Then with the data itself and this identifier you can prove a transaction, so a receipt basically that never goes away. This can easily be improved to make the receipt cost free as well (user can keep the identifier plus the data and it will validate on the chain), but needs fully fleshed out.
22 Likes
OK, thanks. Deleting old blocks is a tricky prospect. I will be looking forward to seeing that algorithm…
Data chains are an interesting turn of events.
Vitalik Buterin came close to predicting this a year ago: Vitalik Buterin on MaidSafe's consensus mechanism
One could make an even more tortured argument that I predicted it 3 years ago 
https://groups.google.com/d/msg/maidsafe-development/hz30YduO4I0/1pEER7p2shAJ
It seems like Maidsafe and Ethereum are closing in on a similar solution, Maidsafe data chains and Ethereum shards. They are just approaching it from the opposite direction.
Maidsafe started with a highly scalable solution, and is adding blockchain inspired techniques for security and consistency.
On the other hand, Ethereum started with a highly consistent and secure system, and is adding sharding techniques (inspired by Maidsafe?) to make it scalable.
I am a much bigger fan of the Maidsafe approach for a number of reasons. However, Ethereum has the funding and marketing edge.
The race is on. Exciting times ahead.
12 Likes
I just have one question,
If you cant see the coins cause they are anonymous and there is no blockchain, how do we know that there wont be more coins for example caused by a bug or a leak found somewere. Happend to some other coins think it was Zcoin.
1 Like
You can see the coins if you enquire the address of the coin(s)
You’re right we will not know for sure the total count.
We can estimate the count by enquiring on a segment of the coin address space.
Bug or coin leak will become obvious because no farming rewards will be occurring when all the coins get created because of the BUG I know its too late then.
So we need to test the guts out of SAFEcoin before going live.
7 Likes
Oke thanks for the answer, working without a blockchain is even harder to understand i guess
1 Like
I’ve been thinking about data chains and safecoin a bit and I have a prediction. I don’t think old blocks will be pruned from safecoin data chains.
As explained elsewhere, the security of the network is built upon the security of the section. It is critical to ensure no section is ever subverted. One way to improve security is to reduce the profitability of an attack.
If safecoin data chains are pruned, the validity of a safecoin record is left entirely up to the section that manages that record. A subverted section can steal all safecoins under its management.
On the other hand, if safecoin data chains are fully maintained, anyone can verify that a safecoin record has a direct chain to the original GET request proof used to create the coin. Assuming the forgery of a GET request proof is expensive to perform, this would massively increase the amount of effort and time required to steal safecoin by subverting a section.
So, maintaining the entire data chain history for all currently valid safecoin will considerably increase the security of the network as a whole.
There might be a way to prune intermediate blocks transferring ownership while maintaining a cryptographically secure link between the original safecoin creation block and the latest ownership record. Along the lines of the concept of cut-through in MimbleWimble. I don’t think that exact solution will be applicable, but there might be another clever solution to do something similar.
2 Likes
As i understand the option B of datachain, at least the section part, will be pruned almost immediately.
And in reference to the idea of MimbleWinble, the last weeks I cannot help thinking that, join the commutative and associative properties of Elliptic Curve Cryptography, as in MinbleWinble, with a binary tree of variable value transactions, can be the ideal solution for all the problems of the Safecoin. Including anonymity, division, ease of reward even with the increase of farmers and, using a Tree Signatures with the Schnorr signatures of Ed25519, multisign.
If I have enough time, maybe one day I dare to expose these ideas.
4 Likes
Please do so. It may be way over my head, but surely very interesting.
3 Likes
This is overly confusing at the moment as the nomenclature is not well established, but “Option B” is referring to blocks related to network topology and membership. They are not yet discussing blocks that manage the data itself (such as safecoin ownership). Option B is complicated by the allowing sections to be in multiple valid but non-conflicting states at the same time.
This is the opposite of what we want for data management blocks (two valid owners for a safecoin would be bad).
Regardless of wether they go with “Option A” or “Option B,” for section state blocks, when they get around to the data management side of things, I expect it will probably look more like “Option A” than “Option B.”
Even in this case we have the version to know who is the actual owner. This is why the MD is all versioned. And the immutable data are Self-verifiable.
Is it possible for Maidsafe to go with option B for data identifyiers and option A for safecoins ?
Some team member might come by and correct me, this is my current understanding:
Sure. Personally, I think trying to conflate the two pieces of functionality makes it harder to understand.
I talk about it a bit here: Data Chains documentation summary - #7 by oillio
They are really two different features with different goals and trade-offs.
Think of the section blocks as a more fundamental piece of infrastructure. It is the root of truth, security, and time for the network. It defines what nodes belong to which sections at any given time.
The data management blocks ride on top of this, referencing section blocks to anchor data change events in time, creating an immutable order of events.
Data management blocks must be aware of and reference section blocks, as the section is providing the security to enforce data management rules. Section blocks don’t need to know data management blocks even exist and have no need to reference them.
The Data management chain design will be informed by the section block design, but doesn’t need to use the exact same implementation.
4 Likes
Spot on. the data part is a block similar to a simple section block. It contains the data identifier (type, id, hash) and a list of public keys (node Id’s) and signatures (signature of the data identifier). So all that needs happen there is that for this block to be valid, the signatories have to provably been at least a quorum of the correct valid group for this data identifier. This proof exists in the section part of the data chain.
The data identifier does not hold any owner information but it does hold the hash. A bit like a crypto commitment in some ways. It states this “thing” is valid, but only the holder (includes network nodes) of the data can reveal what it is (unless it’s encrypted then only the owner) or who was involved in the transaction.
Another advantage of this scheme is that as an owner of some versioned data (e.g. safecoin ) you may wish to keep a receipt. The nodes do not have to keep current version - n of any data (simple pruning) however as the user you can keep the whole block (including proofs). With this block, even though the network does not hold it, you can prove it happened and happened on the network. This opens up a few possibilities such as anyone being able to hold versions of say websites, documents, contracts etc. and prove them at least once valid on the network. They cannot prove this is the latest version, but anyone can ask the live network for that, but it opens many doors for app devs and apps like contracts, project planning, meeting minutes, land transfers etc.
Anyway I ramble, but this is a quick view of the data elements and their possible features that can be exploited.
16 Likes
So that’s how we do smart contracts on the Safenetwork !
3 Likes
Yep. Maidsafe and Ethereum are really building the same thing, coming from very different technical and philosophical directions.
Maidsafe is building a distributed computing platform, the first application of which is data storage.
Other applications can be built upon the infrastructure by defining different data types, with different rules determining what makes a valid update to the data. You also get to dial in how much security each application needs.
The problem is, smart contracts are really hard to get right. Ethereum skipped a bunch of steps and just pushed out the first thing they could get to work reasonably well. They have a number of really hard technical problems to solve and deploy on a network current worth $34B, before it crushes itself under its own weight. I don’t envy them.
Judging by their past behavior, one thing I can say about Maidsafe is that they will only release when it is done, and done well. It takes longer, but the final product will be much safer. Assuming they ever actually get it out, that is.
10 Likes
But for that you must prove that signatories existed in the past and this implies at least 2 problems to solve:
-
the complete chain of historical blocks must be maintained and I thought that only latest ones were kept and older ones were thrown away. Maybe I am wrong on this because I am not able to retrieve were I got this feeling, but anyway who will pay for their storage in the network?
-
a query language must be implemented in the nodes to retrieve this information, which could be the source of DDoS attacks by overloading nodes with such queries.
1 Like
Yes the complete chain will be available on the network, each group maintains the tip of it’s own “branch”. given the chain from the genesis you can validate all blocks. For current join etc. only a few blocks are required to be sent between nodes, however nodes will require to get the complete chain from genesis for their branch. Then they require to get all the data for that group to become full nodes. We are looking at logical groups within each section, but ignore that for now. Nodes can have more data than this (archive nodes) and get more reward for providing out of branch data, if required.
Not really, all nodes and clients need to do is to iterate the chain using the rules of the data chain, which are kept as simple as possible. I imagine an impl of partialEq / PartialOrd will allow a simple mechanism to achieve this simply. We will however provide helper functions to make this as simple as possible to begin with. I do hope we get to impl Eq/Ord though.
Hope that helps.
4 Likes
So how large will these chains become? Is this “genesis” from the start of the network or ???