search

DMDcoin / diamond-node

bit.diamonds node software for network version 4
GNU General Public License v3.0
0 stars 3 forks source link

Incompabible Networks keep P2P Communication #102

Open SurfingNerd opened 3 months ago

SurfingNerd commented 3 months ago

Signed Block gossiping during a Fork results that the other Network cannot process the Block, which is Fine: this comes from a Fork happening at block 15.

 Stage 3 block verification failed for #16 extra data: [93, 109, 72, 24, 220, 5, 68, 221, 0, 88, 142, 123, 161, 118, 129, 67, 171, 184, 197, 79, 158, 73, 195, 235, 188, 26, 108, 16, 22, 236, 112, 42] (0x3b54…05d1)

Those seem to pup up only once, then the System knows that this Block does not have a valid signature. However, the Networks still exchange Tranactions (to be verified)

Uncles are not supported in HBBFT, so the "ability" to be still in the multi head network that eventually merges back after a fork.

SurfingNerd commented 3 months ago

a possible solution might be to always switch the Network ID, that will mark transactions invalid, that do use the chain ID

SurfingNerd commented 3 months ago

also interferes with the early epoch end feature, since the contracts don't know about the new nodes during the epoch.

SurfingNerd commented 3 months ago

Also triggers "Protecting from hang":

2024-03-18 18:47:24 Worker devp2p1 WARN sync protected from hang. peer 22, did send wrong information ( td=Some(2800), our td=111) for blockhash latest=0x29df…bb9e 127.0.0.1:30302 originated by us: true. clie nt_version: OpenEthereum/v3.3.5-hbbft-0.9.4-unstable-4e791aff9-20240317/x86_64-linux-gnu/rustc1.75.0, protocol version: 5

SurfingNerd commented 3 months ago

investigation if it is possible to change the Chain ID when an Fork happens: The Chain ID seems to be the only value we could use to distinguish between the 2 forks. However, the chain ID comes from the configuration file and is cached several times. currently there is no support for updating the ChainID on a running client.