You’ve seen the delights of Troon… surely one Troon is more than enough?! 
4 Likes
Yeah - I’m gradually coming round to your way of thinking here (and you’re right @neo, I was mistakenly talking about responses going all the way back to the client rather than just a refund).
I had my suspicions when I wrote that part of the RFC that there might be kickback
Possibly there’s a middle ground where a client is allowed a few “mistakes” before we start not refunding. Or we refund a decreasing percentage of the transaction as failed attempts increase. More complexity is bad, I know, but I also don’t want to encourage a malicious client to squander network resources by transferring to a myriad of non-existent accounts.
5 Likes
I think @draw has already nailed the answers here and here (although just ignore the bits where talks about lack of understanding! ).
Just to give my view; I’d say the new approach is a wee bit weaker than the old in terms of a malicious user getting control of a section. This is mainly because of the ease with which they could dump coins into their account though. It’d also be easier for them to create more coins than should exist. I don’t think the old approach was immune to these problems, it’d just be more work for a malicious section to achieve its goals. (With the old approach, they couldn’t really create more coins than should exist, but I think they could spend a coin held by their section from an account held by their section mutiple times, which would be almost equivalent, although probably more detectable.)
It would indeed. But with the old proposal, you’d be able to do similarly. You’d just create a wallet in your section and pretend it holds every coin that can exist in your section (you don’t need to actually create the coins). Then when you want to spend the coins, the destination section where the recipient’s wallet lives assigns those coins to the recipient, but your malicious section is still free to pretend you own them. You can pretend to transfer ownership of those same coins to as many different destination wallets as you choose.
To me, safecoin (in whatever form) incentivises malicious actors to try and get control of a section, but even without safecoin the temptation is pretty high. I think we need to mitigate against malicious sections under all circumstances, so I’d see the details of how we approach that as outwith the scope of the safecoin RFC. As in, if we decide for example neighbouring sections should monitor each other, then I think they should monitor more than just their handling of safecoin.
Having said all that, I may be missing something (I wasn’t thinking much about mitigating against a mailcious section when forming the RFC) and the new approach possibly does offer even greater incentives. If so, we’d definitely want to document those in the RFC and they may be severe enough to be grounds for preferring the old approach.
6 Likes
This is very similar to ideas we had for ImmutableData a while back. We had RFC-0013 and RFC-0023 describing this.
3 Likes
“Nano” coin has free transactions but requires a proof-of-work for each transaction - but these can be done in advance and stored, so they don’t cause any delay in the transaction speed. I have no idea on the details, but it’s an interesting idea.
3 Likes
Yea, I am getting the impression that the reduced protection compared with the inherent protection that MDs gave needs to be offset with involving at least 2 sections when dealing with the coin accounts and “farmed” amount.
With the MDs only one ID (or set of IDs) could own the MD and the compromised section could only change ownership of the MDs it had control over. Didn’t matter what any wallet said it had, the coin could only be spent if you had the private key for it. So the taken over section would simply change the owner of the MD.
Now with the coin accounts as you and others mentioned can simply keep sending (made up) coins from that section to the attacker’s account.
There needs to be a secondary check to ensure a taken over section cannot just create a coin account and it have billions of coins in it. Obviously the attacker would have the keys to this account. Maybe the coin account is actually kept by two sections and version number can be used to verify sync. Both sections have to agree on any spend. If a taken over section just creates a coin account with coins in it then the other section has no record and so no spending can be validated and executed. You could have the secondary record of the account use the inverse of the ID so that it is located elsewhere in the network in another section (except when you only have one section 
)
4 Likes
Instead of using multiple sections for governing a single network coin account, would a fuzzy form of the classic approach help minimize damage? This would involve using multiple network coin accounts per section that are restricted so that each of them could never contain more than a single safecoin (I think this is what your original balance idea for divisibility did right?).
In a broader context, we’ve discussed how all bets are off within a section once it gets compromised, for safecoin or anything else. I recall mav or tfa doing some work to show what percentage of the global network needed to consist of adversary nodes in order for a single section to become compromised. Using dual or multi-section checks on transactions would appear to fix this issue, drastically reducing the probability that a single section could ever become compromised and help identify bad nodes for removal. A way to do this may be analogous to RAID 1 mirroring at the network level. MAID 1 anyone? 
A simple and naive way to approach this would be to partition the network globally. Client requests and commands get simultaneously issued to each and parsec runs independently in each half, then each section checks the work of it’s partner in the other partition to make sure they same end result was found. Inconsistencies would get flagged and corrective measures could then be implemented. In a perfect world you might have two exact copies of the network running side by side. Sections and nodes would likely differ due to the complexities of dynamic section membership, so it’s highly unlikely the network structure would be identical in both halves but the data chunks must be. I’m sure there are more elegant ways to go about this, but I think you get the basic idea. As an analogy, consider the human brain with its two hemispheres, or bilateral symmetry in general where the right hand can tend to the left, or vice versa.
3 Likes
Maybe you store every chunk on 2 sections: the ‘official’ one and a backup: determined using the ‘inverse’ (XOR address) or something similar. This way everyone who has the XOR address of the chunk knows where to find the backup. And the ‘backup’ of a section as a whole is distritubed over the complete network and not all concentrated around the same address space/section.
The backup can also be used to check against, like in the case of SafeCoins.
It could be that this kind of approach introduces bigger problems then it tries to solve, but I certainly see advantages.
Though this ‘inverse’ solution probably doesn’t work for Safecoin Id’s. An attacker can make a Safecoin id where the inverse falls in the same section or in another section he also controls.
Instead of inverse addresses, if you used a 512 bit address space, the first 256 bits could be for the chunk address in the “primary” safe network, and the second 256 bits could be for the location of it’s sibling in the “mirrored” safe network. If primary chunks were first encrypted before being mirrored, then the new hash could be used to form the mirrored address. Under this scenario I don’t think the attacker would be able to target a section they might also control. The full 512 bit address would follow both chunks, so that the mirror sections knew where to locate the primary chunk, and vice versa if need be. The primary vs. mirror designation on a node would just indicate which half of the 512 bits they use for routing.
Because if the section is taken over then the attacker can do as they please and just keep sending one coin to their account elsewhere, over and over again.
Has to be taken over for all bets off. Compromised will just allow disruption of the consensus process and decisions can be indeterminate if the attacker decides so.
1 Like
Not if the attacker can try the same encryption and check the resulting second address.
And if he is able to change the data to be encrypted enough until he gets a second address he wants.
I think we have to be clear why a rogue section can cause more trouble for SAFECoin than for user data. A compromised section can forge data, but it cannot read private data; even when compromised, encrypted data cannot be read. Rogue nodes could also drop data, but afaik, good nodes could not be convinced to do the same, as request signatures couldn’t be forced.
So, I think not needing to care about reading data creates this data forgery vulnerability on compromised sections. With that in mind, perhaps it will help us to focus on a solution?
Perhaps just making it increasingly hard for a section to be compromised is ideal, e.g.
- Sections watching sections to decrease impact of rogue nodes.
- Merging sections with low consensus between nodes into one with high consensus, thus diluting the rogue nodes.
Alternatively, duties could be split between sections, reducing the impact of compromised sections, by neutering their ability to act unanimously. This may slow transactions down and consume more resources, but it would make forgery much harder to pull off - the more the duties are split, the harder it becomes.
Anyway, just spit balling here.
3 Likes
I call a compromised section that has 34-66% bad actor nodes and they cannot do any data changes. They can only stop consensus or drop their vaults
I call sections with 67% or more bad actor nodes as a taken over section and they can change data including removing encrypted data.
So a compromised section cannot steal coin. But it could stop transactions happening.
A taken over section can destroy/change data held by the section, but for coins could create virtually unlimited number of coins because they can create coin accounts with any amount of coins and send the coins to coin-accounts in other sections where those incorrectly created coins can be kept safe for the attacker. This is the big problem.
So really the big issue is to protect coin accounts from a rouge section. The attackers get little benefit/joy from modifying data compared to the MASSIVE benefit/joy from millions/billions of ill gotten coins.
3 Likes
After the network has been pretty well established, the mathematics doesn’t support the ability to take over a section from all the but the most well funded intelligence agencies, or possibly Apple and a handful of other extremely wealthy companies who would have no vested interest in doing so.
Even for intelligence agencies, I don’t see what they would have to gain from spending the resources to attempt to take over a section. A bunch of encrypted blocks are still just that, a bunch of encrypted blocks. Perhaps they could manipulate Safecoin in some way, but to what end? Unless their goal is to completely destabilize the entire network to make it unreliable, which could theoretically be a viable reason, they have no other real actionable reason to bother.
So, why are we bothering to spend time mitigating an attack that is incredibly unlikely? In the event that the the few intelligence agencies with the funding to do so decide to attack the network, is having sections check each other really going to help? Between the US intelligence agencies and the DoD (who also have their own intelligence pieces), they have ~$750B a year in funding. If they decided it was necessary to put in the resources to basically take over the entire Safe Network, they could do so, sections checking each other or not. I’m not sure if any other country even has the necessary resources to accomplish such a task. Maybe a couple others, but certainly not many. Out of the obvious “bad actors” with significant intelligence operations (Iran, China, Russia), only China has even close to enough resources to accomplish such a task, and I still doubt they could pull it off unless the significantly increase their defense and intelligence budget.
Anyway, I guess my point is, your run of the mill spammers will not have the resources to affect the network. It would take an incredibly well funded concerted effort to do so. If such an attempt was made, I’m not sure there is anything that could really be done to stop it. Sure, it could be slowed down, but anyone with enough resources to spend to be able to take over a section is likely going to have the resources to spend to take over the whole network, or at least get the necessary 34% in a enough sections to essentially cease network operations.
1 Like
Are you certain on this? Would good node still delete data, even if they could not be convinced that the owner requested it? I did assume that such a change request would require the owner to sign the transaction to change the data.
Still, I think the primary concern with safecoin is the forging of wallets and transactions.
I’m not sure if this applies in this case, since the difficulty is so much higher. The attacker would need to brute force the combination of addresses for two sections that they have taken over. If all sections are mirrored from launch day, then any rogue behavior would get detected after that point. Thus, it may not be possible to take over a section when the network has a mirroring defense. You would just need to ensure that the initial launch nodes are in no way compromised… right?
Feel free to prove me wrong. Spit-balling…
Thanks for the terminology update. I was saying compromised but meant “taken over”.
1 Like
The attacker would need to brute force the combination of addresses for two sections that they have taken over.
I’m not sure.
In your proposal the Safecoin CoinAccount data structure is (only) guarded by 1 data copy on another CoinManager section: the one responsible of the range the id’s mirror address is part of?
That value of the id field of CoinAccount, is that part of the XOR range where the CoinAccount data structure is stored?
If both answers yes, then after +/- ‘total number of sections / 2’ tries with different id’s of your 1st section, you get one where the mirror address is part of your 2nd section, no?
If all sections are mirrored from launch day, then any rogue behavior would get detected after that point.
If I’m not mistaken, if you can get control of 2 sections and create new CoinAccounts like described above, then you won’t be detected with the current proposals.
To be clear, let me try to explain the kind of attack I’m thinking of to get control of a section.
No need to control a high percentage of the total number of vaults with this attack.
Maybe it is unrealistic, but I’m not (yet) convinced it is.
It is certainly not an easy nor cheap attack. But the reward can be high.
Certainly if the Safe Network becomes a big success and Safecoin has a lot of value.
You, the attacker, create a number of vaults. You then have the IP addresses of the ‘elder’ vaults of the sections your vaults are part of. You investigate the IP addresses: which ones can I track/detect the owner of?
I guess this is difficult, but paying the responsible ISP for this information could help. Or some ISP want to help for free to get rid of that annoying (for them) Safe Network.
If you’ve found a section you know all/most ‘elder vault’-owners of: you contact them and offer a lot of money to take over their vaults (e.g. remotely with ssh on a Linux). You could even try to promise the owners to pay them with part of the reward the attack will give, if it succeeds. You have to convince 2/3 of the owners. Or a bit more, in case one of them has to leave the section due to the normal ‘churn’ in the near future.
Remember: you only have to control 2 sections.
Then you replace the elder vaults software, while it is still running and operating normally, with a version that does what you want (of course you’ve tested this before on a test network).
This won’t be easy, but again I’m not convinced it is impossible: see this post.
Maybe a succesful attack is more complicated than described here, but I think the idea is clear.
With regards to this, it would make more sense that elders keep churning, not that they churn less the more desirable they are for take over.
So, sure the vaults have gained trust in a technical manner, but the elders have also increased in value, becoming targets, and if the network is about removing the faults and errors of corruptible humans… then it makes sense to not equal proven technical performance (over time) with low risk of corruptibility.
With kept higher churn rate even as the vaults age, the window of opportunity for the above attack would decrease and the feasibility dramatically decreased.
But then of course, a few other things are tied to the concept of churning to decrease, as vaults stay online longer. So that would not be a small change.
You must control two specific sections. That’s the big problem for the attacker and the great security that comes from needing two sections. If controlling one section cost X, controlling two cost X².
4 Likes
Quadratic of course is nice, but the original cost must still be substantial for the quadrant to be prohibitive. There is a slight difference between the attack draw is talking about, and a ‘regular’ take over, in that it potentially requires much much less resources.
It’s more social engineering than the regular attack. And that’s the angle I consider important as well, if the goal is to lessen the influence of corruptible humans.
6 Likes