Raiblocks promises "unlimited scalability and no transaction fees". What about security?

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).

pg 7 "Block Interval: Since each account has its own blockchain, updates can be performed asynchronous to the state of network. Therefore there are no block intervals and transactions can be published instantly."

"We really only need to have transactions for an account ordered with respect to other transactions in the same account and since only one account is involved we don’t need network agreement so proof of work is unnecessary."

"The only agreement remaining is handling misbehaved clients that try to double spend, which in our system is called creating a fork. We use a weighted vote system to pick only one branch of a fork.
This means in the usual case of a well behaved peer your transactions complete instantly without a vote and only the peer is misbehaving are its transactions subject to the slower voting."

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?

pg 7 "Representative: A representative node requires maximum network resources as it observes vote traffic from other representatives and publishes its own votes."

Who exactly can be a representative?

pg 6 "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. "

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.