Thank you for these excellent explanations. I have a much stronger grasp of this now.
Now Im going to go take a strong grasp on a cool bottle of lager.
9 Likes
I think so as well. So, there are at least two different things here, subtly different:
One thing is regular sybil attack, starting nodes and trying to get them all in the same section. As someone pointed out just recently in another topic, sections overseeing eachother doesn’t seem to add much protection there. And increasing number of Elders in a section doesn’t seem to add much improvement either.
But another thing is simple “fishing”, you know just become Elder in one section, contact the other Elders and try convince them that “becoming filthy rich is nice”. Looking at the world, it is not that hard to imagine that you’d be able to find a quorum, in one section or another, who are rather easily convinced.
That’s where adding numbers actually makes it harder. If we assume a majority of Elders in the network will want to stifle such behaviour, and act together in self interest to keep the network viable, with some validation of transfers, then that small trick will be much harder.
Maybe there’s some easy fix, maybe there are some tougher problems there, but that’s an area I think we should to look into eventually.
Aye! Exactly what I had in mind, and now am proceeding to.
14 Likes
And will PUTs work the same way? Does a customer ask for a transaction that requires a payment and send both the transaction and the payment or will the Elders take care of deducting the payment?
What about GETs?
4 Likes
We are finalising this at the moment, but it’s likely to be get the payment receipt with a reason and then send the actual data with this agreement. i.e. agree to an operation that has a hash, get agreement on that then send the actual data + payment. The op is checked it hashes to the agreed operation as part of the final check.
We can think like this. We offer to debit our own account for a reason., The reason can be
- To pay somebody else (transfer)
- To pay the network (network data mutation)
So the agreement we get is to debit our own account (with a casual order to our last transaction) and that agreement includes the reason, which is 1 of the above.
With 1. The network will forward the deposit. With 2 the client can and do so at any time, so if it goes offline then it will be OK. This is what we are coding/testing right now. @oetyng is all over this area like a deamon
Gets are always free, so we treat them as now.
16 Likes
Nice…Pay today upload tomorrow.
About the GETs, I was thinking about the payments to the Vaults.
Any changes without the parsec consensus?
5 Likes
It takes a greater genius to employ a simpler system to achieve the same (in this case, better) outcome, e.g., ease of use, greater features, accessibility to a greater number of participants, etc. 
So hats off to all of you.
On the communication of PARSEC’s deprecation, it would’ve made sense to structure a brief explanation of the reasons why (with examples) and the replacement for it into the update itself rather than doing so in the comments after community angst. Otherwise, it all makes sense (and not much of a surprise given hints dropped in previous updates regarding using bft crdt’s to improve section membership).
12 Likes
Thanks to @dirvine and the team for expanding on the plans in the comments. It really sounds like the team has the bit between the teeth and are moving forward well. Exciting stuff!
13 Likes
Can’t adults be part of them? I mean can’t they check validity of transactions provided by elders and refuse to store invalid ones?
If bitcoin analogy was valid, elders could be compared to miners and adults to full nodes. In bitcoin network full nodes don’t propagate invalid transactions provided by rogue miners. So maybe we could implement something similar in safe network. But for that adults should:
-
store safecoin transactions themselves (like other data)
-
have all the info to do these verifications. Even if they don’t define the transactions, they should be able to check they are fine. But this has many implications not implemented by safe network:
-
usage of original senders’ signatures instead of elders’ ones
-
storage of a ledger containing all the historical transactions.
-
So maybe this solution is a dead-end (I mean adults checking elders’ behavior). I am just thinking out loud without reaching a good conclusion, just in case someone has a better idea.
5 Likes
This is 100% what we all need to be doing all the time. It’s best in brainstorm mode to vocalise it without fear. I get your drift above, but we need to remember Adults are not trusted much and the replicant count there for data is likely less (3) than quorum (4) of elders, again just more info/thinking.
11 Likes
Just because parsec isn’t being used for SAFE doesn’t mean it can’t be used for other projects. Perhaps it should be bundled into a stand alone library (if it hasn’t been already) that can be easily bundled into other pieces of software. Also the parsec logic could be applied to other non software related systems perhaps so writing an essay type paper on it or breaking it down into an instruction manual of sorts might be of use. How to apply PARSEC to a social organization for example.
While SAFE may require instantaneous, or near instant, transmission rates not every application for PARSEC may have such demanding time constraints.
9 Likes
Oh well, Parsec only took us so far…
7 Likes
It was actually quite important in some ways. Some folk, even Devs had doubts of a fully decentralised network for all data. Parsec at least proved, given knowledge of all data types (no opaque votes) then it is actually possible. So remove the impossible, so now we just implement it as an even more fully (read actual ) decentralised network with the correct form of data types.
That proof to folk was good in many ways as it showed, even if we needed some very smart complex algorithms we can come up with them. It also showed Engineers there is another way to think, albeit initially hard to grasp there is another way.
So the optimist in me thinks ti was of some value, but did become increasingly a debate point for sure with the exactness requirements of many parts of the system. It brought a significant fragility to the message handling etc, I think we could have got around that, but this is now quicker and as I said in line with original network design.
25 Likes
Something is often learned from climbing certain mountains (parsec) even if only to survey the surrounding terrain. Often takes longer to survey if you do not climb certain mountains.
I am certain @dirvine that many things were learned and that makes it easier to implement more efficient mechanisms and have confidence they are going to work the way you want
15 Likes
That is a personal matter and we will not discuss somebodies health publicly. In fact I will strongly defend a persons right to privacy. There was a guy here for a while that made such points!
I advise you focus on delivery of the network and not on individuals lives. I sends a very bad picture and not one MaidSafe will agree to.
21 Likes
If you are new to the forum, why do you care if one person isn’t here any more. There have been many others who have left after making great contributions. People come and people go. The world keeps turning
9 Likes
This is our old friend Starsmick… Here for his weekly dose of drama 
10 Likes
11 Likes
Are data chains still needed or are they gonna be removed as well?
Other question: What’s the latest news on DBC’s (offline transactions). Doest that fit with AT2?
3 Likes
Data chains were not taken any further then the code/papers etc. and not implemented by the team. However section chains are and these give us the ability now to handle the data chain even more efficiently. It’s the same principle, i.e. a mechanism that allows data to republish. So the data itself is signed by the network (as data chains) but instead of the network keeping the chain of data each data element has the section signature.
This is more efficient and is in line with a notion @AndreasF had when he did look at data chains way back in 2015. I was not as sure at that time, but as we have progressed the answer is obvious, especially with node age in place.
Not forgotten right now. We have a sort of offline transaction already happening with our crdt/at2 types, where the client can have the ability to pay for data storage and send that whenever he wants. So part DBC but not anonymous (yet). This is an area that is quite interesting for us to dive into as we impl that code, which is well underway.
15 Likes
Thanks for your answers! I like the way you are going now. Sounds good.
I think safenetwork.tech and primer will need some updates soon 
11 Likes