Possible attacks on Safecoin

Autonomi Network Token (incl (e)MAID)
,
1

Hey all. I just introduced myself in the Beginner section, and I thought I would post here some of my concerns / questions about Safecoin. Keep in mind, I am still learning about the SAFE project, so I might be wrong about a few things, and that’s why I’m bringing it up here. I’m a developer myself and my background is in web development and decentralized networks (see https://intercoin.org, Qbix Platform (https://qbix.com/platform) and this video)

When I looked at the SAFE project, I really thought you guys had just the right architecture for file storage. It is the closest in spirit to the kind of technology we aim to build. It is actually decentralized and secure in the most effective way. When I was designing Intercoin’s payment system, I came across very similar ideas. Kademlia trees, DAGs for histories permissions and rules, and local rather than global consensus. We also added some new concepts, such as the Permissionless Timestamping Network, which you guys might like.

However, one point which I think is a bit off in SAFE is how it implements its currency: unlike bitcoin, which has to keep appending transactions to a growing ledger, in SAFE the Safecoins are just files whose ownership is changing based on a local consensus about editing-in-place. There doesn’t seem to be any growing history of signed transactions.

This seems, to me, to risk a serious problem. When A pays B some token T, it is not enough to know that T was issued as a valid token in the past, and now belongs to A. That’s because the nodes in a close consensus can collude and simply lie that A owns the token, after B has accepted payment from A, by “forgetting” the changes. They can also steal it from its previous owners, since the history of previous owners’ signatures is not required or even stored.

This problem is easily rectified by having each token be a file whose history is constantly growing. Files should be able to split into multiple new files with a shared history, allowing fractional spending. This does introduce an endlessly growing ledger, but not everyone has to keep everything. Each token has its own history. Now B can verify this history for themselves. And they know that no one can steal their tokens - at worst, the datachain can be prevented from making further progress by a majority of malicious nodes in the quorum feigning unavailability, but the sender can try to cancel the transaction and issue a new one, which would be checked by a completely different set of nodes.

Even better if each new state of the token can have its own id (with the hash of the contents plus some random value) and verification of transaction must be done by consensus of nodes close to that id. When sending 5 cents, only a few nodes are needed. But when sending $1MM, the recipient would require a lot of nodes before accepting payment, and perhaps even ask that their friends join the consensus for that transaction.

Remember, in a payment network, the recipients pay for someone to record that they now own the token. These notaries or their successors have to be around to store the transactions. Thus, a recipient (or the system) can require a minimum number of notaries based on how much value is being transferred. They can split off some value from the tokens they are storing information about. In your system, this last part seems to already happen, but how can you subdivide SAFE tokens?

7 Likes
2

There has been numerous talks on divisibility and in February @jlpell summarized them here -Safecoin divisibility - #314 by jlpell

Just giving you this information while you wait on a response to your post.

4 Likes
3

If this happened then the network is insecure at all levels and we go home saying that was a good idea.

This is the essence of the work being done and that is to make this collusion very hard and unlikely to ever occur. There is a number of factors that work against this collusion and does take time to absorb the details. Search on “primer” for a document that has a lot of good info in it

How do you steal something from a previous owner? Being previous they no longer own it anyhow.

Not sure how. If groups collude they can steal and all that happens is that you can see a history of it. They still stole and obviously cash out ASAP so by the time you see it its too late. The issue is collusion and not ledger in my view.

Already the process of moving coins requires 2 groups of nodes to confirm the transaction.

6 Likes
4

According to the FAQ,

“The SAFE Network allows many millions of transactions per second and the larger the network the more transactions per second can be executed. A safecoin only holds the last and current owner. It does this to make sure the current owner has signed authority from the last owner to take ownership. This allows coins to be transferred between people very easily and without delay.”

So let’s say a legitimate Safecoin is issued in some event, and is eventually transferred to user A. A spends it to B, but then once they get the goods, decides to double-spend it to a colluding party C. A and C together can figure out what group of nodes will participate in close consensus for this fictional transaction, and contacts them. Now this group of nodes is bought off (with the large value of whatever is about to be double-spent) and now represent a “fork” of the token. So, it involved collusion between A, C and their bought-off nodes only, not the whole network.

What is the way in which A and C together cannot figure out who to buy off, before preparing this fake fork between themselves? After the fork is created, how is the forked token less legitimate than the real one (which B may have continued to spend)? And if this attack is possible, why can’t it be repeated endlessly inflating the currency?

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.

1 Like
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.

7 Likes
8

Thank you, I will definitely read though it.

1 Like
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.

22 Likes
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.

13 Likes
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 Alt-Coins on Safe final.pptx - Google Slides

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.

13 Likes
12

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

5 Likes
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.

6 Likes
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

1 Like
16

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

3 Likes
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.

1 Like
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.

2 Likes
20

Coins are treated specially with added processing.

safe041
safe041614×579 25.6 KB
safe040
safe040973×856 109 KB

2 Likes