Possible attacks on Safecoin

crypto
safecoin

#5

And this would require collusion. Once you can make nodes collude then a ledger is not even secure and it can be forged. No security if collusion occurs and we forget using the network.

Since the coin is a data object, you cannot initiate a double spend since you no longer own the object.


#6

That’s my question. What’s preventing A and C from figuring out what nodes to buy off and say that A does still own the object? At one point A owned the object, and paid B, so if A knows exactly who to pay off, they can just make them “forget” this transaction.

There are going to be millions of parties A and C (in fact C may be accounts that belong to the same person, which they can pick specifically to make it easier to find the nodes).

Is the process of figuring out what group of nodes record the transaction from A to C deterministic? Is it something like finding nodes on a Kademlia tree for a specific id?

Sorry if I’m not making myself clear … maybe I can ask this way: if a file goes through several revisions and I at some point had access to a previous revision, then why can’t I just re-upload the previous revision of the file, and own that myself? That’s the same thing as double-spending a coin. The network is storing both forks of the file revision DAG, how does it know which one is “the real one”?

PS: I should add that for file storage, this is not really a problem. Only for coins. Normally if someone re-uploads a previous revision to the network and owns that fork of my revision tree, that doesn’t bother me unless there are copyright violations. Basically the whole challenge of preventing double-spending in crypty is because copying files is so easy that it’s hard to have a singleton in a distributed network :smiley:


#7

Can I suggest you read the primer first then come back with the questions. You might find a number of answers in there first. If it were possible to “buy off” nodes then the netowrk is insecure and we go home. So this issue is at the core of the network design and its best to read further so that you can find answers or expose the flaws better

No its a big problem for files/data. The coins are only data so if it can be done for data then it can be done for coins. Also many secure databases will be on the network and to be able to break into them would be worth more than a number of coins help by a section/group.


#8

Thank you, I will definitely read though it.


#9

Great to see more technical exposure and engagement! I’m happy to have you here and discussing interesting ideas.

This topic grew quickly but here are my answers which took longer to type than the speed at which the topic grew so apologies for any duplicates.

Can they collude? This is discussed in Analysing the google attack and it turns out to be very difficult to actually collude on the safe network.

And even if they can collude, would they? The cost to do so is more than the benefit. Like bitcoin miners doing a 51% attack, it’s most likely if they’re in a position to do that attack there’s almost certainly more utility in being a benevolent / neutral actor than a malicious one and undermining the very network which forms the basis of their investment.

Could this happen alongside the existing mechanism for transfer, like a third-party neighbourhood watch service?

The overhead to keep history is probably not too high, but why include it if it’s not needed?

Currently datachains are designed to track the history of network participation (vaults joining and departing the network), but it may be extended to track history of data, specifically safecoin.

I don’t think the history mechanism is necessary, but I can see the appeal and reckon even if it’s not natively included someone will implement it and store coin history on the network for their own use anyhow. Whether this actually happens depends if coin history is valuable or not!

I think this is true in some sense but there’s a distinction to be made here which is quite economically difficult to grok (I have not yet fully grasped the economic interplay of safecoin). The safe network does not have consumers directly paying service providers. The users pay the network, then the network pays the service providers. The user and service provider are related, but not directly. So in this case the users pay the network [to record they own the token] and the network pays the vaults [to record the owner of the token]. This is the payment flow, not the data flow! It’s important because it’s not like a section dealing with high tx volume is necessarily paid more for that. This affects the economic relationships and behaviours of all actors.

This mechanism is also important because it makes ‘network operations on data’ fungible. So the security of one piece of data is the same as any other. It’s not like adding safecoin history necessarily makes it more secure, since the history is subject to the same security conditions as the safecoin itself. So just secure the safecoin in the first place.

It’s a tricky question with no direct answer. But a lot of conversation in these topics.

There are a few aspects, but ultimately the answer is ‘maybe they will collude’ which I know is unpleasant, but that’s just how it is.

These things make collusion difficult:

  1. XOR space addresses cannot easily be mapped to IPs. It can be done but it’s not easy. And even if you do know all the IPs for the section you want to collude with, how do you actually contact those vault operators and coordinate with them? It’s possible but it’s definitely not easy. Maybe there will be some out-of-band behaviour that allows collusion to be coordinated, eg safe_vault_collusion_service.exe that runs alongside safe_vault.exe…?!

  2. The network nodes are regularly moving so collusion is temporal. Collusion now does not mean collusion in the future.

  3. There are punishments to vaults for not cooperating, which may be costly. It takes a lot of work to become influential over section decision making (see the ‘vault ageing’ feature). If the collusion attempt fails, it would be very costly to the misbehaving vaults. It’s a bit of a prisoners dillema type situation. Honest nodes have incentives to weed out malicious colluders, so they may say “I’ll collude” but then don’t and punish the colluders.

  4. MutableData objects (which is what safecoins are stored as) have a version number that’s incremented each time the owner changes. If two transactions with the same version number come in, there’s a race condition that must be resolved. I don’t know the details of that resolution, but the ‘double spend’ idea depends on that race concept. A second spend five minutes later would simply be rejected because a) the signature from the old owner doesn’t match the new owner and b) the version bit would not be incremented correctly. That version flag for mutable data is a very important mechanism and is worth reading more about.

If it’s possible then yes it may inflate the currency, but never more than the number of coins the section is responsible for. If there are one hundred sections, any particular section is responsible for (on average) 1% of all coins. The more sections, the less coins each one is responsible for. So a very large network may have most sections only being responsible for a few coins.

Again, it’s a shitty answer because you don’t want to admit coins can be minted for free but they can (if collusion is possible).

However, due to the way coins are issued, there should be even distribution of coins across xorspace (within a certain variation). If a particular section has issued way more than they should have it would be detectable. Likewise if client balances suddenly changed due to colluders taking ownership it would be detectable.


#10

Thanks @mav , this answer clarifies a lot more for me.

I have read part 4 of the primer by the way. I am glad to say overall it matched the mental picture of the architecture I had from the blog posts. I realize that this is just an overview, and there are tons of little details.

So as I understand it, the followings prevent collusion:

  • Nodes move around between sections after they first join the network
  • Nodes may also move around for other reasons (e.g. if they go offline and then reappear)
  • Honest nodes may trick dishonest nodes about colluding
  • IP address of nodes is hard to find and contact based on their id only
  • A section may only control a small amount of coins anyway
  • MutableData objects have a version number, which enforces a linear ordering of states

I will tell you why I am super-interested in SAFE network. At Qbix, we started a new spinoff project called Intercoin, to let any community launch and manage its own currency. Intercoin serves as the “bridge currency” between communities, so each community can have its own rules, inflate its currency, and make (democratic or not) decisions about its monetary policy.

So, we are looking at which technology we should use to run these communities. When a community first launches with only a few nodes, they might perform what I call an #EarlyAttack. Namely, they make a fork and double-spend the currency, but when other nodes join, they join one or the other branch of the fork and don’t know that the other fork exists. After all, you can never really know if the network you’re joining is “the” network, or if another fork is out there somewhere whose participants don’t know about you and vice versa (think about Bitcoin Cash or something). Only the original members know they’ve forked, and they keep quiet. Then, one day the two branches find each other, and they have equally valid histories. Normally, this is very hard to do – for example, Ripple publishes a Unique Node List (UNL) in a public way, so everyone can be sure what is “the” network. But, in our system, any community can start its own currency from scratch, and we want as much as possible for it to operate autonomously, even without a link to the Internet. So we are trying to keep collusion to a minimum.

As you can see, there is a lot of overlap in our ethos with SAFE network, and I think you have the right technology. We have been working to implement authentication and decentralization using local mesh networks, without the need for the Internet. However, you use of Kademlia trees and self-healing nodes is really a huge step forward. It will revolutionize not just file storage but, hopefully, will have an entire application layer for realtime collaboration. I am just trying to understand if it’s enough by itself to implement a currency.


#11

Hey @GregMagarshak. Welcome to the forum! I think you’re getting up to speed really quickly but I noticed you have an interest or ideal vision of coin implementation/design. There are a couple developers here that made an alt coin generator and wallet that uses that tree like structure. Check it out. Project Decorum - Wallet Release and https://docs.google.com/presentation/d/17WCbtCiShXN9xVYEWJOve5m3QIeCyOjfvytX1nQuyiM/

I do think the fact this network is optimized for data security that it takes guts to make the networks coin rely solely on that same design. That really says something imo. So many facets, all very dynamic, to make collusion highly unlikely and costly to boot.


#12

Yeah, it definitely takes guts to do that, the data security is pretty impressive indeed :slight_smile:


#13

I thought about it some more. It seems to me that other coins can be implemented on top of the SAFE network. You guys might want to advertise that fact.

In fact, if SAFE could be a drop-in replacement for the Web by using the HTTP protocol, that would be awesome! What we are building at Qbix and Intercoin is complementary to what you all are building, which is a back end, essentially, for various web apps. We are building the platform for actual social apps on top of the Web, using HTML/JS/CSS/client side crypto, but we would like to integrate with SAFE network as a backend if possible. This is sort of going into another topic, so I will probably make another post asking how we could do that. So we don’t have to build the full stack ourselves, but rather use the SAFE network for the storage.


#14

@neo wrote in the recent topic Analyzing the Google Attack

This is what I was asking about, when it came to double-spending coins, and so on.

If a coin file will contain a history of valid transactions, however, at least every honest recipient can check it for themselves and eliminate the possibility of the coin suddenly appearing in someone’s hands. What that means is that every holder of a coin can know that no one will “steal” the coins from them, even if an attacker takes over the consensus of an entire section. Yes, dishonest recipients might still “accept” payment, but they’d only be screwing themselves, because they can’t forge an invalid history without also controlling the devices of some earlier recipients of the coin (i.e. their actual client devices to sign the coin away, which makes things much harder even than before), so recipients down the line won’t accept their token.

So I think it’s a worthwhile addition, to improve the safety of the coins.

PS: However, it is true that if an attacker is able to control at least one of the previous recipients A, and make the network forget that A signed away the coin (e.g. by sabotaging that section) then they’ll be able to double-spend it. It could be A themselves, who let a very valuable set of coins pass through them and then do it. So, to recover, the network should accept proofs that some other fork happened earlier, but this requires the Permissionless Timestamping Network to be added, which might be too much work


#15

But as @mav said better than myself, the problem is geting control over a section. And if you can get control over 2 specific sections then no data is really secure at all and the network data is not secure and thus your ledger is open to modifications and is not beneficial for the purpose of securing transactions.

Much of the design of the network is to stop the control of the sections by anyone or anything.

Any good hacker not only knows how to hack into a system but to also remove traces of that hack from the logs. And so to will any hacker who can crack section control they will cover their tracks of stealing safecoins and modify the ledger.

And once the hack to steal coins is known then it will be known by so many the network is useless. EDIT: They will produce scripts for the script kiddies to run and then the safe network will be toast. So we must secure the sections from control and as @macv says the ledger is not helping much but introduces quite a bit (a hell’a of a lot) of complexity that is not needed if you just secure the data

What you say here would be the norm of these hacks


#16

Have you also read the inventors blog, some nuggets in there.


#17

But as @mav said better than myself, the problem is geting control over a section. And if you can get control over 2 specific sections then no data is really secure at all and the network data is not secure and thus your ledger is open to modifications and is not beneficial for the purpose of securing transactions.

Out of curiosity, why 2 specific sections?

I would like to propose an additional mechanism for “random” machines in the network to make sure the sections they’re watching didn’t suddenly fork or do something bad. They would keep track of the head of a section’s data chain, and make sure that each addition (“block”) is built on the previous head and doesn’t violate any rules (it can allow arbitrary rules to be written in some deterministic language like Javascript without random number generator or access to Date() etc.)

This can be quite powerful. Now someone can optionally verify the integrity of a section and an update by contacting several independent machines on the network (they don’t have to be part of a section), which they can find by the hash of the actual changeset. The changeset can contain a random nonce from every interested party (e.g. recipient of a token) which makes it essentially unpredictable in advance. And the independent machines will only store violations, to save space. So if a violation is found, then the section is flagged by the autonomous network, as it can verify that, indeed, the section has reported the wrong information. It can be caught red-handed, as it were, by submitting a cryptographically signed receipt. That section signed the receipt of the information, and there is cryptographic proof the information is invalid. So the section can be flagged and at the very least everyone accessing that data can now be suspicious of it. Because everything was signed by the section itself, there is cryptographic proof it misbehaved.


#18

EDIT: I was about to write something and then realised that maybe someone else who knows it better should answer. I could not find the diagram that showed the transfer mechanism.

One reason is the security of having two sections agree for the transfer to take place.


#19

Not sure about that. To make an MD ownership transfer only need the MD Xorname section consensus. If an attacker controls a section do not see how preventing ownership change or the creation of new MD, including Safecoin, in the section XOR range. This is why is critical that control a section was almost impossible.

Maybe future Datachain, or the new DAG routing, will have some feature to prevent that a singe evil section can change ownership or create new MD.

It has been raised, at some time, that the Safecoin could be considered a special MD and that, for its creation or modification, the consensus of two or more sections will required. In this way Safecoin’s safety would grow exponentially.


#20

Coins are treated specially with added processing.


#21

Are coins actually specially treated like that?

It seems to me that this network is only secure once it’s big. And most of the security is in being unable to figure out how to contact and pay off the nodes running a close consensus (eg by their IP).

However, in our Intercoin project, we need to support security for transactons EVEN IF the whole network is only 3 computers. Because a community may start a new network. That’s why it seems we need additional mechanisms, not just trust a consensus of third party computers.


#22

At 3 computers SAFE network is not secure against attacks. Only take a few instances of nodes to take it over. Including any ledgers or watchers since the attacker does whatever they please, since they in effect become the network and the 3 computers are just hanging on and have no valid say


#23

Currently no, since there are no implemented ‘coins’ and there is no implemented ‘treatment’. We can only know how they’re treated once they’re implemented.

The intended design of safecoin depends on features that have since been eliminated (eg sacrificial chunks, old consensus rules) so the way safecoin will actually work cannot be known. The rfcs are out of date. The safecoin whitepaper is out of date. The ideas are there but they don’t have a clear path to implementation in the current codebase.

If you like to read code I’d recommend starting at safe_vault/…/mutation.rs for the current state of transactions / changing data ownership. It inevitably leads to routing/…/mutable_data.rs.

In light of that fairly giant caveat, I’m reasonably confident to guess that coins

  • will use the same secure messaging / routing protocol as all other md ownership changes
  • will operate on a transaction / atomic mechanism so cannot be partially completed
  • will have a built in notification system to alert new and old owners of their new balances
  • will have some built in accounting mechanism for converting safecoin to PUT options

and possible but not certain that coins

  • will have some built-in wallet function for tracking aggregated user-coins at the network level (possibly with additional third-party interfaces added on top of that built-in wallet functionality)
  • may be subject to additional verification rules via datachains based on the history of that coin, but I think this is unlikely

and then there’s the way they’ll be minted which is a whole other conversation…

fwiw I don’t see anything especially wrong with the proposal to have watchers. I’m just not yet convinced if the benefit is worth the cost. Hope this helps understand the current intent vs reality.


#24

The watchers wouldn’t be part of the small network of 3 computers. They would be outside watchers, from other networks. But because they don’t run consensus and only store a very minimal set of information, they would be able to watch many many networks and sections at once. The watcher network would be hard to corrupt because:

  1. You can’t predict which watcher will be asking for the info in advance

  2. It take just one watcher to start to gossip a claim of violation

  3. No honest node would care about a false claim of violation, including honest Recipients, so this can only help, not hurt.

This works for currency in particular because dishonest recipients can only hurt themselves. For other mutable file types with other rules, it may not be as benign.