Raiblocks Security Thoughts
Raiblocks promises "unlimited scalability and no transaction fees". What about security?
Potential Balance attack
Cliff notes - there isn't sufficient information to claim that Raiblocks is as robust against double spend attacks compared to blockchains such as Bitcoin's proof of work or Peercoin's proof of stake. There are hidden trust assumptions that users of Raiblocks must accept upon using Raiblocks.
Double Spend Background
Fundamentally, the double spend problem must be addressed in any payment infrastructure. The system topology increases the difficulty of solving and adequately addressing the double spend problem.
Centralized systems which rely on a payment processor achieve high scalability though require strong trust assumptions.
Decentralized or distributed systems must address a further spectrum of issues, namely those revolving around byzantine agreement.
Bitcoin gave a probabilistic solution to the Byzantine agreement problem by the introduction of a proof of work system that dynamically increases the difficulty. An adversary must control greater than 51% of the hash power for a period of time in order to successfully execute a double spend attack. It should be noted that if a double spend attack was executed, the entire network would be aware, as Bitcoin is a peer to peer network where transactions are broadcasted and propagated across the network.
Peercoin pioneered proof of stake. Rather than relying on proof of work to secure the network, Peercoin's proof of stake security guarantees hold as long as the adversary does not control 51% or more of the networks stake for a period of time. Such a stake attack more expensive than a proof of work attack. In addition, proof of stake has lower energy requirements compared to proof of work.
Raiblocks Security Claims
Now, let's take a look first at how the "unlimited scalability" claim is made in Raiblocks and what type of security properties we can expect.
Double Spend Prevention Claim
First, let's examine what is a Raiblock and the novel "block-lattice" structure and see if in fact all that's required to solve the byzantine agreement problem is a novel data structure (and no new consensus algorithms).
Let's summarise the design so far.
Basically, as long as the network functions honestly, well we can expect no double spends. Ok, how about protecting against double spends?
A weighted vote system is used. What exactly are the network requirements for a representative?
Who exactly can be a representative?
Not clear on how someone decides which representative to choose and how the selection process should be carried out?
However, it's clear that by consolidating the voting power to those network powerful nodes Raiblocks is not distributed and borders on being centralized, or at least controlled by a handful of nodes. It is NOT peer to peer.
Why is this an issue?
As the paper points out, consolidating the voting power amongst a few opens the door to denial of service attacks. However, the paper handwaves regarding potential numbers of actual stake required. Without knowing the real distribution of Raiblocks and the allocation and voting distribution of representatives, the number can't be clearly specified.
Is this a concern?
For someone that cares about targeted security attacks, yes.
Free Transactions
Second, transaction fees.
The paper mentions no transaction fees as a positive point. However, are no transaction fees really advantageous for security?
Raiblocks relies on a minimal proof of work before sending each transaction, it claims similar to Hashcash.
However, from an attacker's perspective having to spend the cryptocurrency's money as opposed to using cheap electricity to generate PoW, the spent transaction fee will mitigate and defer transaction spam more than PoW. The spent transaction fee requires a stake in the network being attacked.
Incentives and Coin Distribution
Third, incentives and coin distribution.
The protocol does not provide any rewards for running a node. Who will provide and run the nodes? We would expect a type of centralization to occur, especially as the number of transactions increases with network usage.
Furthermore, the number of coins has already been distributed.
As the security relies on a type of delegated proof of stake, the question arises of what financial incentives do the representatives have to not spend their coins? Either the representatives hold their coins (meaning they are not able to spend their wealth) or they spend their coins over time. If the representatives spend their coins over time, we would expect the coins to be distributed to multiple account holders. This means the threshold for attacking the system decreases over time as well.
Prediction we will see several large scale denial of service attacks attempted. Attacker will have the opport
unity to affect the price and make serious money.
To execute an attack either a large mining pool or a cloud service can be rented for cheap.
Other concerns
C++ Codebase
"Raiblocks code is totally new and completely built from scratch" (in C++)
Maybe the bug bounty can help with this.
Exchanges
What's the point of no transaction fees when exchanges charge 20% fees and require minimum balances for withdrawal?
Very much appreciated this post in the midst of the hype of this coin. I've played a bit with the wallets and functionally it's great to see XRB moving so fast without fees. I also changed my representative to a random one further down the list and this made me wonder how the default representative is selected. I think this is key to the security of the network and the team should expand on this in the whitepaper or elsewhere. Another issue is I self-representation which seems to be possible. If many wallets do this they become dead-end-streets when offline and all balances eventually routed to these will not be able to assert their voting power which reduces decentralization.
I think this is a serious concern that needs to be fully addressed. What you described in combination with a denial of service attack could potentially allow someone to take advantage of the ledger due to the lack of settlement finality.
I wrote up these concerns here https://steemit.com/raiblocks/@selfdrivingsandp/raiblocks-lack-of-settlement-finality