As you know, proof of work is a security mechanism--someone needs to (essentially) match the hashing power of the rest of the network, and then they can freely fork blocks, create double-spends, etc. I know you're planning to implement another security mechanism, "proof of reliability," which I haven't seen explained yet, but understand it as an improvement over proof of stake. But until that's implemented (or even afterwards, depending on your implementation), your network's security only comes from the cost (in servers) of attacking the network.
It's not so much about pushing the chain along to process transactions, but to keep those transactions locked in the chain safely.
100milion is like month+- of mining with mid range CPU. So its not that much after all also. Can you code in wallet to have ICO coins locked in for a like 365 days and then only like 10% gets released and so on.
We are considering changing up the tactics, however we must be very considerate about it as to not upset the community either, no one will want to wait a year to get their coins. Here's the kicker though. Once we go PoR, your balance will impact what you earn per block like PoS. Just in different manner
Also PoW ends just at over half way of the total count. The rest is PoR. So PoW only takes the chain just over half way
People would probably be perfectly fine with the 100 billion coins paid out over a longer period of time, perhaps for as long as you think it'll take to get new security measures in place.
Right however if you've tested a 51% attack like we have it doesn't work very well as 51% gives a CHANCE at messing with the chain which legitimate nodes tthat we hardcode in will immediately reject the attackers. Trust me we have extensively tested an attack on our private network on several test clones. Please advise if I'm missing something as I'm not Einstein but attacking achain is not as easy as it sounds.
And I'd like to clarify I'm not trying to attack your project or anything--I'm excited about it, I love the dev activity, the roadmap is interesting.
What kind of heuristics do your legitimate nodes use to recognize attacker blocks? Is it a checkpointing system? Even if you do have nodes that can recognize these blocks somehow, unless it's actively communicating to the network to ignore the blocks (like signing a message as some form of authority that denounces the block, or something of the like), passively refusing to propagate the blocks won't stop a well-connected network from forking.
Attacking a chain isn't necessarily easy, but I wouldn't imagine it being much harder than running your own pool, blocking the daemon's outgoing traffic, mining a bunch of blocks faster than the rest of the network, and bringing it back online to propagate.
You're correct that 51% gives a chance of messing with the chain, not a guarantee. Variability could throw a wrench in it, but over the long term a slightly-higher-than-50% hashrate would outstrip the chain, and the attacker could simply wait until variability works in their favor to bring their attacking node(s) back online. The attacker has time on his/her side, because they decide when to submit their growing chain to the network.
Imagine you're attacking a network with a private pool. The legitimate network is at block 10,000 (which includes the transaction you want to double-spend), with 100 MH/s of mining power. You bring 102 MH/s online for your private pool. The legitimate pool has no knowledge of your private pool. In the beginning, due to random chance, the legitimate network gets ahead, and hits block 10,010 when your private pool has only gotten to block 10,008. You bring a bit more mining power online (or just wait for the inevitable swing of randomness), and by block 10,030 on the legitimate network, your private pool has hit block 10,032. You bring your node back online, the network forks back 32 blocks. What if you were still behind at block 10,030? Maybe you'd be ahead at block 10,040, and do even more damage. The naive solution to this is simply have peers refuse to fork past more than x blocks, but that can become dangerous if the network does, during normal operation, get that far out of sync due to something like a protocol disagreement (something like a BIP update gone awry), since the network would permanently divide into two (or more) fragments. And it doesn't necessarily have to be a user who's providing all of the hashing power--it could be an existing, popular pool who decides to "go rogue," feed bad data to miners, and use them to fork the network.
Let's now say your network's seed nodes have the ability to detect this, and not propagate the 32 malicious blocks. Unless all of the nodes are connected to one another through your controlled nodes, those blocks will still propagate on the network. Basically the litmus test here is whether the network would continue to run if your seed nodes went down. If so, then passive refusal won't prevent the attack. Now, in the event that your nodes are actively managing the network--either by signing a message that checkpoints blocks as an authority that the rest of the network trusts, or by some other similar mechanism that either marks blocks as guaranteed-legitimate or certainly-illegitimate. Mechanisms like this would also raise concerns about centralization and the network being brittle and subject to break during non-malicious but unpredicted conditions.
I have no idea how your proof-of-reliability mechanism will function when launched (do you have any literature on it to read, or a brief summary anywhere?), but for now I'll just discuss it as if it is proof of stake, although I understand you're planning to make significant improvements/modifications on top of that protocol.
Proof of stake introduces an interesting complication to network forking, but also creates a new attack vector. Proof of stake (as it traditionally is implemented) gives priority/weight to transactions which consume larger quantities of coin-days. As such, an attacker could buy a large quantity of coin on an exchange and transfer it to addresses they own, wait until they reach max stake age, and then attack the network with significantly less than 51% of the total network float. The amount it would require depends on how active other people are with staking and how much outstanding coin age will be consumed by others legitimately while they attempt their fork, but under certain conditions such a fork could be successful with a quite small portion of the network float.
Additionally, when combined with proof-of-work, proof-of-stake blocks could be the extra 'icing on the cake' to push their network power over 51%--stake weight saved in reserve to use if variability doesn't work in the attacker's favor. Even non-malicious but greedy nodes (who spend time offline until reaching maximum stake age on lots of transactions, then coming online) could cause grief for a laggy network. One proposal for eliminating (or greatly reducing) this issue is to require that the blockchain is 'layered' (something like a minimum number of proof-of-stake and proof-of-work blocks in any given 'frame' of contiguous blocks). This would at least require an attacker to have mining power AND stake weight. Other solutions involve coin-age being only used to calculate reward but not "priority" (in the form of a greater chance of mining a block with x coins).
Anyhow I'm rambling, but if you want to discuss the types of attacks you've tested that your network has been able to thwart on testnet, or the security features your hard-coded nodes have, I'm all ears. But exchanges (a primary entry point for new users to get involved) are hesitant to list coins that have particularly low difficulties, because of the responsibility they have for user balances, which even non-malicious forks could disrupt.
And at the end of the day, if miners don't expect to at least break even on their efforts, they're unlikely to mine. Which makes all of the above attacks much easier. I understand price not being your primary goal--and that's a great approach to crypto-currency in general, and means you care about development, features, long-term support, etc. But a secure network is the foundation for the entire project, so there needs to be some acceptable security mechanism. Whether that be some semi-centralized checkpointing solution, or some alternate miner incentive (like a 'colored coin' or address reputation to give them voting power on something important), or your proof-of-reliability, this is certainly something to think about before those 100B coins hit the markets.
