Why RaiBlocks is not secure.In this article I will try to explain why RaiBlocks is not secure and why its technology is any better neither comparable than the Bitcoin technology.
1. Decentralized paymentsDecentralized payment networks are, in opposite of centralized payment network like banks, a way to secure your money without having the risk that a central authority could steal your money or manipulate the money in the market. Decentralized payment networks use asymmetric cryptography to ensure that you are the only one who can spend your money.
When you create a cryptocurrency wallet you are given a public key and a private key. The public key allows other people to send you money, while the private key allows you to spend them.
But how other users know how many money do you have?To accomplish this, every user of a decentralized payment network must download the entire transaction database which is replicated on the entire network. When you send a payment over the network, it is received by all the users connected on the network allowing them to know your updated wallet balance and allowing them to discard that payment if you don’t own enough funds.
2. Double SpendingThe main problem that afflicts decentralized payment networks is double spending: the ability of an user to spend his money multiple times. In the real world, when you pay someone you give him the real cash. In a centralized payment network, like VISA, the central database is updated every time you make a payment, and they will not allow you to spend more money than your balance.
In a decentralized payment network what happens if you send the same amount of money on two users of the network in the same time? Since their database takes time to update for a small amount of time they both will receive the payment and accept it. In a later moment, when the network tells them that you double spent your money, they will cancel the payment, this is possible because every payment is broadcasted to the entire network, not only the receiver.
Without any other security layer, if a malicious user double spends his money and succeeds to block a payment receiver to know that he sent the same money to someone else (or even better, to another wallet of his own), the payment receiver will accept the payment and ship the good. This is so bad, since even a network connection problem could temporarily lead a payment receiver to undetect double spendings.
3. The Bitcoin SolutionTo solve this problem, Bitcoin relays on the fact that after you receive a payment you need to wait a confirmation block, the confirmation block tells you that the payment you have received has been accepted by the entire network and you are allowed to spend it. To create a confirmation block, the miners create a list of all the pending unconfirmed transactions and solve a very difficult mathematical puzzle. The miner who solves the puzzle first, sends the block he found with all the list of confirmed transaction and the solved puzzle to the network, the users of the network will check if the puzzle solution is valid and then reward him with some free coins plus the sum of all the payment fees of each transaction in the block. The miners must create a valid list of payments to be accepted by the network, so double spend attempts are just discarded.
In Bitcoin an attacker, to make a succesful double spending, should not just stop you from receiving a double spend attempt message, but he should also solve the puzzle to create a confirmation block in a reasonable time frame. Currently solving that puzzle with a single computer would take years; at writing time to solve that puzzle a network of thousands dedicated hardware is used, an attacker would require a billionaire investment to replicate that network. Moreover, it would not only need to create one confirmation block but six of them (6 confirmation blocks are required in the Bitcoin network to trust a payment).
Critics of Bitcoin say that all the computation power used to make the Bitcoin network secure is just a waste of energy because there are other reliable and better technologies. Is that true?
4. What is RaiBlocks?RaiBlocks is a crypto currency that advertises itself as a fast, fee-less and secure currency, unlikely Bitcoin which is currently slow and high-fee (usually requires 1 hour to a full payment confirmation).
But the key point is that Bitcoin has been made that way to guarantee his users a certain amount of security to prevent double spendings.
RaiBlocks completely ignores the Bitcoin technology and relies on a special version of the Proof Of Stake concept.
When you receive a payment in the RaiBlocks network you have to wait a certain amount of time to be sure that a double spending has not been attempted (and remember the first problem, if an attacker stops you from receiving the double spend you would never know!)
When a double spent is detected, the RaiBlocks network starts a vote. Every peer connected to the network vote to accept the payment A or payment B; every user vote is weighted with the amount of his balance. Usually each peer votes for the first transaction he receives. The transaction which the sum of votes reaches the 51% of online amount of currency wins. The winning transaction is accepted by the network and the other one is discarded. (Reference
https://github.com/clemahieu/RaiBlocks/wiki/Double-spending-and-confirmation)
The payment receiver, if his network has not been compromised, will then know if he can trust the payment or not, and will ship the good accordingly. This system leads to an unsolvable problem.
5. The Man in the Middle attack.If an attacker succeeds to put himself between a merchant and the RaiBlocks network he can just filter the double spending payment packets, and the merchant will never know that he is receiving a double spending. The Raiblocks network will discard that payment while the merchant will accept it.
https://s18.postimg.org/7pnm6yweh/doublespend.png6. Solutions proposed by the RaiBlocks teama) The merchant should ask a vote for each payment he receives and wait for the confirmation.
The problem is that the attacker could manipulate the vote by telling the merchant that only his peers are connected to the network thus he will win the vote by filtering only his votes. Plus, asking a vote for each payment would cause a huge increment of bandwidth usage that many peers could not handle.
b) The merchant should have a remote node verifying the payment.
The attacker could just attack that network too.
c) The merchant should ask the RaiBlocks.net website if the payment has been accepted.
The attacker can hack the RaiBlocks.net website. Also if you have to rely on a website you can no longer consider RaiBlocks a decentralized network.
Other solutions1) A payment to be accepted should require a vote with a minimum weight quorum.
It's difficult to establish a correct quorum, and if that quorum is offline no payments will be processed.
2) A payment need to be accepted by some trusted representatives.
This will stop the network on being decentralized. Also, if those representatives are offline the payments are not processed.
7. Why Bitcoin is not vulnerable to this type of attackSimply because an attacker, to be trusted by a merchant, would require to solve a very difficult puzzle for six times. An attacker cannot alter the difficulty of that puzzle.
8. Other observationsa) RaiBlocks is just Bitcoins without the Bitcoin securing algorithm. The creator of Bitcoin, Satoshi Nakamoto, describes the double spending problem in the original Bitcoin paper:
https://Bitcoin.org/Bitcoin.pdf. The developer of RaiBlocks just thinks to solve the problem by ignoring the problem.
b) The official representatives of the RaiBlocks network own more than 52% of total voting weight, allowing the developer to manipulate every vote on his will.
Source:
https://dev.RaiBlocks.net/page/representatives.php9. Referenceshttps://RaiBlocks.net/media/RaiBlocks_Whitepaper__English.pdfhttps://github.com/clemahieu/RaiBlocks/wiki/Double-spending-and-confirmation It is about time someone posted this. Watch now as it tumbles.
What is this? It's not just bitcoin. There are no miners. There are no double spend attacks.
POS will ALWAYS be more costlier to attack.
The devs have already addressed this:
https://github.com/clemahieu/raiblocks/wiki/AttacksRaiBlocks has a number of mechanisms built in to protect from a range of possible attacks on the system. Here we go over all attacks there could be on the system and what safeguards are in place.
Block gap synchronization - Low risk, network amplify, denial of service
Description: Each block has a link to its previous block. If a new block arrives where we can't find the previous block, this leaves the node deciding whether it's out of sync or if someone is sending junk data. If a node is out of sync, synchronizing involves a TCP connection to a node that offers bootstrapping which is much more traffic than sending a single UDP packet containing a block; this is a network amplification attack.
Defense: For blocks with no previous link, nodes will wait until a certain threshold of votes have been observed before initiating a connection to a bootstrap node to synchronize. If a block doesn't receive enough votes it can be assumed to be junk data.
Transaction flooding - Moderate risk, high I/O
Description: Transaction flooding is simply sending as many valid transactions as possible in order to saturate the network. Usually an attacker will send transactions to other accounts they control so it can be continued indefinitely.
Defense: Each block has a small amount of work associated with it, around 5 seconds to generate and 1 microsecond to validate. This work difference causes an attacker to dedicate a large amount to sustain an attack while wasting a small amount of resources by everyone else. Nodes that are not full historical nodes are able to prune old transactions from their chain, this clamps the storage usage from this type of attack for almost all users.
Sybil attack to change ledger entries - No risk, completely destructive
Description: A Sybil attack is a person creating a lot of nodes on the network, possibly thousands on a single machine, in order to get a disproportionate vote on networks where each node gets an equal vote.
Defense: The RaiBlocks voting system is weighted based on account balance. Adding extra nodes in to the network will not gain an attacker extra votes.
Penny-spend attack - Moderate risk, large ledger
Description: A penny-spend attack is where an attacker spends infinitesimal quantities to a large number of accounts in order to waste the storage resources of nodes.
Defense: Blocks publishing is rate-limited by work so this limits accounts to a certain extent. Nodes that are not full historical nodes can prune accounts below a statistical metric where the account is probably not a valid account. Finally, RaiBlocks is tuned to use minimal permanent storage space so space required to store one additional account is proportional to the size of an open block + indexing ~ 96b + 32b ~ 128b. This equates to 1GB being able to store 8 million penny-spend account. If nodes want to be aggressive, they can calculate a distribution based on access frequency and delegate infrequently used accounts to slower storage.
>50% attack - Low risk, completely destructive
Description: The metric of consensus for RaiBlocks is a balance weighted voting system. If an attacker is able to gain over 50% of the voting strength, they can cause the network to oscillate their decisions rendering the system useless. An attacker must have at least some value tied up in the network as a balance which they're willing to forfeit as an expense to performing this type of attack since this attack ruins the integrity of the system. An attacker is able to lower the amount of balance they must forfeit by preventing good nodes from voting through a network DDOS.
Defense:
The primary defense against this type of attack is voting weight being tied to investment in the system; attempting to flip the ledger would be destructive to the system as a whole which would destroy their investment.
The second defense against this attack is the cost of this attack is proportional to the market cap of all of RaiBlocks. In proof of work systems, technology can be invented that gives disproportionate control compared to monetary investment and if the attack is successful, this technology could be repurposed after the attack is complete. With RaiBlocks the cost of attacking the system scales with the system and if an attack were to be successful the cost of the attack can't be recovered.
In order to maintain the maximum quorum of voters, the next line of defense is representative voting. Account holders who are unable to reliably participate in voting for connectivity reasons can name a representative who can vote with the weight of their balance.
Forks in RaiBlocks are never accidental so nodes can make policy decisions on how to interact with forked blocks. The only time non-attacker accounts are vulnerable to block forks is if they receive a balance from an attacking account. Accounts wanting to be secure from block forks can wait a little or a lot longer before receiving from an account who generated forks or opt to never receive at all. Receivers could also generate separate accounts for receiving from dubious accounts in order to protect the rest of their balance.
A final line of defense that has not yet been implemented is block cementing. RaiBlocks goes to great efforts to get block forks to settle quickly via voting. Nodes could be configured to cement blocks after a certain period of time, possibly a few minutes, which would prevent them from being rolled back. More research has to be done to figure out of this policy would be beneficial and what type of parameters would be the best. More than likely the network is sufficiently secured through focusing on fast settling time.
The most sophisticated version of a >50% attack is detailed in the diagram below. "Offline" is the percentage of representatives who have been named but are not online to vote. "Stake" is the amount of investment the attacker is voting with and will be lost if they successfully attack the system. "Active" are representatives that are online and voting according to the protocol. An attacker can offset the amount of stake they must forfeit by knocking other voters offline via a network denial of service attack. If this attack can be sustained, the representatives being attacked will become unsynchronized and this is demonstrated by "Unsynced". Finally, an attacker can gain a short burst in relative voting strength by switching their denial of service attack to a new set of representatives while the old set is resynchronizing their ledger, this is demonstrated by "Attacked".
Voting attack
If an attacker is able to cause Stake > Active by a combination of these circumstances, they would be able to successfully flip votes on the ledger at the expense of their stake. We can estimate how much this type of attack could cost by examining the market cap of other systems. If we estimate 33% of representatives are offline or attacked via denial of service, an attacker would need to purchase 33% of the market cap in order to attack the system via voting.
Voting attack cost:
Euro - M1 in 2014 ~6 trillion, attack amount 2 trillion
USD - M0 in 2014 ~4 trillion, attack amount 1.2 trillion
UK pound sterling - M0 in 2007 ~1.5 trillion, attack amount 500 billion
Bitcoin - Market cap 2014 ~3 billion, attack amount 1 billion
Bootstrap poisoning - Low risk, new-user denial of service
Description: The longer an attacker is able to hold an old private key with a balance, the higher the probability of balances that existed at that time no longer having representatives that are participating in voting because their balances or representatives have transferred to new people. This means if a node is bootstrapped to an old representation of the network where the attacker has a quorum of voting stake compare to representatives at that point in time, they would be able to oscillate voting decisions to that node. If this new user wanted to interact with anyone besides the attacking node all of their transactions would be denied since they have different head blocks. The net result is nodes can waste the time of new nodes in the network by feeding them bad information.
Defense: Nodes can be paired with an initial database of accounts and known-good block heads; this is a replacement for downloading the database all the way back to the genesis block. The closer the download is to be current, the higher the probability of accurately defending against this attack. In the end this attack is probably no worse than feeding junk data to nodes while bootstrapping since they wouldn't be able to transact with anyone who has a contemporary database.
***
The voting process is balance-weighted. Each new account selects representative in 1st block (then it can change it with "change" block) & delegate its balance to representative. When an account selects their representative, the vote weight of that account is increased by the balance of the source account. Votes are weighted by account balances. Those who have more funds in the system are inherently incentivized to keep the system honest; a dishonest system would make their investment worthless. You can observe votes to check if representative is honest.
https://www.reddit.com/r/RaiBlocks/comments/7klfoe/raiblocks_double_spend_question/?st=jbvpt9zi&sh=a9f797b4