If a bug in the software somehow made it possible for someone to create new safecoins without being awarded a farming reward, would it be possible to detect? There’s a maximum of 4.3 billion safecoins that can be created, but can we know that somebody didn’t discover a bug and created a billion of them and can it be reverted if it happens?
1 Like
You don’t store your own balance or coins locally. All you store is a private key which you can use to prove to your close nodes and others that you own x-amount of coins at address y. We don’t know how they will workout Safecoin exactly but it has to do with ownership. So the bug needs to make sure you can prove to other nodes that you own that big number of coins. This would need at least several other nodes as well. So it has to be a bug that works in several groups, in your favor with maybe 100 other nodes involved. And the nodes are in different groups. So quite hard, but who knows.
4 Likes
Knowing the safecoin creation algorithm can deduce, approximately, the number total of safecoin that must exist in each moment. And asking, more checks the better, if a safecoin exist or not in enough randomly positions, can calculate, approximately too, the real number of safecoin.
A divergence between both calculation can show that exist a problem.
4 Likes
Yeah I guess that should detect any problem. The good thing is that it at least should in any case never be possible to create more safecoins than the cap.
If there was such a bug it would then be detected if an attacker were to create a huge amount of safecoins, that would cause serious disruption and decrease the value of the safecoin, so it would be in the attacker’s interest to create a small enough amount of coins that it wouldn’t be detected and then the bug would probably be found and fixed within some reasonable time. Worst case scenario unless someone intentionally wanted to destroy the network is then a small inflation that would basically steal a small amount of safecoins from everyone and that’s a worst case unlikely scenario anyway, so I guess this probably isn’t anything to worry about.
@intrz The only way you can be rewarded SafeCoins is through the Proof of Resource, and you would have to fake the Proof of Resource to be able to game the system. How are you gonna do that? Let’s focus to the proof of storage for now: you are hosting a single copy of an encrypted chunk that the network randomly assigned to you, which is also backed up in several other computers in the network.
For the proof of storage the network checks if your chunk is exactly the same as the other ones around the network, and if yours is different, you get penalized.
How does it know you are hosting the right chunk? Comparing filenames? That would be silly isn’t it? Then what? Checking the hashes? What if you collisioned it? It would have the same hash but it would be the wrong chunk.
So what they came up is with this scheme: they don’t need to know the contents and they don’t need to rely on the hashes either. What they do is to append some random string at the end of the file and rehash it. All the chunks around the network will contain the same encrypted gibberish, and they will all have appended the same randomized string, therefore the new hash must be the same. If this new hash is matched among all nodes, they know exactly that you are serving the right uncorrupted chunk, and you are granted a SafeCoin by randomly generating a 32 bit hash which is the SafeCoin ID. If the SafeCoin ID generated is unused, you become the new owner of it. If it already belongs to someone else, good luck the next time your resources are checked again.
That is just how the proof of storage works, and this is just one aspect of the Proof of Resource, they will be also checking for your CPU and bandwidth.
So how are you planning to “accidentally” issue yourself a SafeCoin without going through the PoR?
Now, regarding to “accidentally” expanding the supply by issuing more than 4,294,967,296 SafeCoins.
There is no way there can be more than 2^32 SafeCoins simply because its total possible supply is the consequence of the address space of the SafeCoin “ID”, it is how each Safecoin is identified in the network (the SafeCoin “ID” is 32 bits long, hence 2^32 possible combinations). So if you somehow altered it by making your SafeCoin ID 33 bits long, the network wouldn’t be able to recognize what the hell is that, but even this hypothetical is unreachable for anyone.
For both scenarios to happen you would have to launch Sybil attack so large that you would have to create almost three times the total size of the network to reliably take over the network.
The only way to modify the SafeCoin supply is by achieving a major consensus to upgrade the network by the whole community.
5 Likes
I’m not talking about any Sybil attack and I know extending the supply shouldn’t be possible since the address space is a set size.
What I mean is if there’s a bug in the implementation, not a design flaw, that for example could cause the proof of resource check to fail in some weird case or made it possible bypass proof of resource all together and create new SafeCoins directly. Implementing it in Rust instead of C++ should prevent a lot of possible bugs, having extensive unit test coverage also helps, still, implementation flaws that causes security holes in very non-obvious ways do happen regularly in software, so what I was wondering about is just what would be the consequence if there was a bug, somewhere in process of creating new SafeCoins, that could make it possible for someone to create SafeCoins in non-intended ways.
In zcash, they have the issue that if it’s compromised, it could possibly lead to undetectable secret inflation, at least that not the case with SafeNet.
The value overflow incident in bitcoin made new bitcoins appear, but it could be reverted. If something similar were to happen in SafeNet there might not be a way to revert it since there’s no blockchain to fork.
How can you mess that up? It is a logical impossibility.
It is like asking: “dude what if… we accidentally… I don’t know, like, end up squeezing out more more orange juice than the amount contained in the orange itself… What THEN?.. I mean, I know that that it shouldn’t be possible because the orange has a set size but, what if you do it like accidentally?”
Is it hard to believe that the only way to get more orange juice is to get a larger orange?, there are no logical ways of fucing that up even if you really want to do try your best to make it happen. Even if you infiltrate the team with stealthy saboteurs and ninjas.
The design in blockchain is weaker in that aspect and the potential of messing it up is always there. The blockchain is like a blank sheet of paper where you could write down whatever you want, so you have to really think really hard all the edge cases to prevent all the ways of accidentally writing something there that shouldn’t be. You could some how accidentally write an extra zero in the piece of paper.
But the SafeCoin design is the orange, you can’t really mess that up.
Now regarding to flaws in the farming, well, there are more moving parts there, so there could be some bugs around, who knows maybe some extremely sloppy bug (zcash ninja scenario) that allows you to bypass the whole PoR logic…
That’s why you need to test them like crazy in these alfa and beta stages, and this also reflects the importance of taking their sweet time and not rushing it out.
But I think your question wasn’t really about this, but about how the SafeNetwork would handle upgrades.
1 Like
I never disagreed with you on that 
Unless if it was stored in a 32 bit int and someone accidentaly changed it to an int64 and nobody noticed, but I don’t think that would happen and I don’t think it would cause that much damage before it was reverted in any case.
What I was really thinking of when I asked this question is if there’s some ways that a bug could bring the state of the network into a bad state that would be difficult or impossible to recover from. Some of big advantages of SafeNet is how data is encrypted and spread all around in a secure way, state is distributed. With blockchains, state is instead centralized in the blockchain. There’s many advantages to having the state distributed, scalability, privacy etc. Where having state distributed is not an advantage is if the network somehow gets in a bad or invalid state. Where’s the bad data? Nobody known. Can it be reverted? Perhaps with datachains or whatnot there is a way to revert the network back to an earlier state. That’s one of the things I’m wondering about.
First I was thinking what if there’s a bug temporarily causing a spammer to have free PUTs, well that would be annoying and there would be more junk that there should be, but it’s unlikely that one person will manage to fill any damaging amounts of data to the network before the bug is fixed.
So I was thinking about SafeCoins. That’s maybe where most damage would be done if the network somehow got in a bad state. If SafeCoins could magically be created, how bad would that be? So as we’ve seen we can estimate the amount of existing SafeCoins, so at least it would be detectable. I think that should also be a consideration when it comes to divisibility, to still ensure that the existing money supply can be estimated. If divisibility was implemented in such a way that you could for example know the approximate amount of SafeCoin data structures on the network, but that they could each represented an amount of SafeCoins as an encrypted decimal number, so that you’d have no idea how many SafeCoins it actually represented, that would be less than ideal.
Testing it like crazy in the alpha and beta stages in one thing, but a bug could be introduced at any point. In the future there might even be a popular client not made by MaidSafe, what if 50% of the users used that one, but they had sloppy testing practices and suddenly one day pushed a version that introduced a new bug. For groups formed by a mix of clients it wouldn’t be a problem, but some would be formed by only users of the buggy client, I’m not sure though, maybe the rest of the network would then help prevent this problem. In any case I think the network would be more resilient if there was a number of different clients as a bug in one wouldn’t likely exist in another, though of course there might be bugs causing incompatibilities, that has caused some issues in Ethereum for example, but I think SafeNet is actually better protected against issues stemming from incompatible clients than blockchains are.
Still, my question remains, what if there at some point was a bug that made it possible for someone to create say 80% of the possible SafeCoin supply. It’s a bit similar to The Dao situation on ethereum, there an attacker managed to steal a quite large percentage of the ethers in existene. Will there be any indication the SafeCoin about when it was created, not a timestamp but something like a network time, so that it would be possible to say, all SafeCoins created after this event will now be invalided? That would mean farmers would also lose legitimate farming rewards and some legitimate payments might be reverted, both very bad situations, but still better than an attacker with the intention of destroying the network owning 80% of SafeCoins.
Anyways I guess my question can be made more general. If the network somehow get into a bad or invalid state, are there cases where it can’t be detected and if the network is found to be in a bad state is there a way to revert it, if it otherwise would have catastrophic consequences?
Changing to 64bit simply would not work, the node that did this would be rejected by the others for “being wrong”. A client could not do this since any SAFEcoin work is only done by nodes.
This is always possible, and the reason that testing is needed and code checks are needed.
Potentially it is possible that someone could work out a suite of router hacks etc and bring down the internet. Potentially there could be a number of cracks that could cause SAFE or its coin to fail.
So what I am saying is that we need to find these before going live. And I agree with you that there could be bugs and putting ones head in the sand will not be good enough.
But if you read the dev updates you will see that the development team spend a lot of time, well most of the time to ensure that the programs/protocols are secure. And of course this involves testing and public tests.
1 Like
What I meant is a change where all nodes would have the change. Anyway it’s not important.[quote=“neo, post:10, topic:14097”]
So what I am saying is that we need to find these before going live. And I agree with you that there could be bugs and putting ones head in the sand will not be good enough.
[/quote]
Let’s hope the worst bugs will be caught before launch. What would be bad is if the network has been out for a couple years, everything running fine, then suddenly someone found a bug could threaten the network. The worst I think would be either creating SafeCoins or corrupting/deleting other users data, most other things should be easy to recover from.
There is something dirvine mentioned a few years back, one of his ultimate goals in the future was to make the network so autonomous that it would itself vet if the proposed upgrades are adequate or not, depending on how it affected the network performance.
That would take the self-healing aspect of the network to completely new heights.
But yeah, of course, mistakes can always happen.
1 Like
That sounds pretty rad.[quote=“piluso, post:12, topic:14097”]
But yeah, of course, mistakes can always happen.
[/quote]
The question then is if it is possible to recover without any catastrophic consequences. The cool and also scary part of SAFE is how it is a completely autonomous, decentralized and distributed. It’s not like with bitcoin, where you can download the blockchain and put it on a USB stick, then you essentially have all that bitcoin is on that USB stick, of course there’s the whole network of miners etc, but in a way they don’t really do anything very interesting. SAFE will just exist there out on the internet, almost like some weird artificial life form.
2 Likes