Raiblocks Lack of Settlement Finality

in raiblocks •  7 years ago  (edited)

Raiblocks lacks settlement finality.

The main issue is that only the receiver is responsible for the final signature to confirm a transaction.

What problems could this lead to?

Raiblocks acocunts manage their own blockchain in order to achieve asynchronous updates and the scaling efficiencies. The downside is that unless the receiver wallet is online, the sent transaction will never be acknowledged and verified. This is the first major issue of the lack of settlement finality. A transaction could be unconfirmed indefinitely.

Raiblocks also places the balance in the send transaction. This means that given enough colluding sender and receiving accounts, negative balances can be hidden unless the entire ledger is verified. Though the protocol does not verify the entire ledger and sacrifices security for performance. This is the second issue of the lack of settlement finality.

Potential Attack Vector

Combining the 2 issues aboves results in flight unconfirmed transactions and a loophole to exploit the actual balance. Combining these attack vectors with a well places denial of service attack against the network (to hide the propagation of the malicious send transactions and also to take down the representatives) makes for an attack vector to tamper with the ledger and even potentially rewriting the ledger.

In the case of such an attack, how will it be determined who is the honest and malicious balances? An attacker could mix honest and malicious accounts to make it difficult to decide.

Where to go from Here?

It's hard to ignore that Raiblocks made a design design to perform balance updates asynchronously. The fact that the balance itself is included in the sent transaction as a store of record is not explained. What makes this secure? Sure it might be fast though seems like a pretty important design decision to sacrifice performance for speed.

Blockchains verify the ledger in each block and take 6 blocks to ensure to strange behavior (in Bitcoin).

Have All Receivers Verify the Entire Ledger?

This hardly seems practical or possible. Especially since a receiver might not be online to confirm a transaction.

Go to epochs and have the ledger validated?

This would make Rablocks a blockchain and no longer a DAG.

In conclusion, Raiblocks seems to only be concerned in the whitepaper with double spends and not the balancing of the ledger itself.

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

I view them as a PoS consensus. I haven't seen what was the interest of the DAG over a blockchain.

One of the first points to address should be how the ledger is balanced. Many of these DAGs sidestep the issue and focus on alternative security attacks.

At least with PoS we can formalize a model. Many of these DAGs just simply choose to sidestep these particular ledger issues, a little too slick for comfort.

What I don't like is how they say: yay we have a DAG it's awesome. The real question is how to choose from two concurrent block or chain? They vote hence PoS. So how do they fix PoS issues? I was really disappointed by the attacks they studied in the whitepaper.