Possible improvment to avoid rollback

[ghost]

Rollback are prevented secondary (if DPoS fails) by the amount of PoW for each block.

The node doesn't approve fork with a shorter chain but (maybe) ATM the wallet check only if the current block count is lower or higher than the one proposed by the fork.

Instead of count only the total number of blocks, shouldn't be more safe, count the block for each account?

Ex:

(now)

A: 5tx
B: 10tx

proposed fork

A: 5tx
B: 5tx
C: 20tx

The fork pass

(with the improvment)

A: 5tx
B: 10tx

proposed fork

A: 5tx
B: 5tx
C: 20tx

The fork doesn't pass because the fork propose shorter chain for account A and B

[clemahieu]

An attacker can generate attacks with
longer chains: publishing a long chain generated offline
shorter chains: publishing a shorter chain generated offline

The DPoS can't fail: I think the theoretical basis for RaiBlocks is fine, there must be a bug in the implementation or too few bootstrap nodes that caused the rollbacks.

[SergiySW]

So, how many nodes do we need for network stability and to prevent rollbacks (if this is the cause)?

[ghost]

@clemahieu follow only longer chain should be a fine security measure.

@SergiySW more nodes, more stability, but we need to set more representative too.

Here you can check all rep atm: https://raiblockscommunity.net/page/representatives.php

[HostFat]

@clemahieu please find some little time to come back at your great product :)

Also raiblocks.net is offline now.

[ghost]

@HostFat the website is online, the ssl is out of date. The node itself is offline.

[HostFat]

Ah yes, I saw it now. :)

[ghost]

@clemahieu Yes, @HostFat , please make RaiBlocks "Great again" ;D

[clemahieu]

Rollback should be fixed with 7.6.0