Some serious bug in validation of transaction in nodes

[vaibhavch]

❏ block 628923 …0009748c228e8655…77d4 txs 9 insert at 21:08:52 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240
❏ block 628923 …000658c7caf910b2…8890 txs 9 insert at 21:13:28 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240
❏ block 628923 …000a7657b4c28eb3…6bbd txs 9 insert at 21:36:24 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240
[P2P] 4 public 0 subnet nodes connected, key(ce1d) => rustndbj<182.92.163.225:3337>(d72d), hne000ac35<62.113.200.176:3337>(e000), rust_node<47.242.254.135:3337>(fd45), Pool<173.255.224.178:3337>(0f2a).
❏ block 628923 …000825afa2012f1d…345e txs 4 insert at 22:02:23 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240
❏ block 628923 …0004f7674906868b…2368 txs 0 insert at 22:06:26 ok.
❏ block 628924 …00020751caa5e210…f08b txs11 insert at 22:08:08 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240
[P2P] Searching nodes...find 1 nearest nodes, try connect...
[Peer] hn_09cec2a743<192.99.21.36:3337> connected, total 4 public 0 subnet.
❏ block 628924 …000b4728569a9658…9b6a txs 0 insert at 22:13:02 ok.
❏ block 628925 …0002712d954e7891…e47d txs12 insert at 22:17:45 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240
❏ block 628925 …00032576936aafaa…b818 txs12 insert at 22:23:56 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240
❏ block 628925 …0005feae9be71dce…2f23 txs 1 insert at 22:24:36 ok.
❏ block 628926 …000aa2918ff4690e…6869 txs11 insert at 22:28:36 Error: address 1EuGe2GU8tDKnHLNfBsgyffx66buK7PP6g balance 0:0 is insufficient, at least 27199959931:240

@jojoin My guess is that one malicious miner ( we all know who) forcing other nodes to accept this transaction during p2p txpool (may be because of poor validation initial stage ) but failing in later stages block acceptance after mining a block. This is causing other miners unable to update chain after finding a block. why nodes can accept such transaction in the first place?

Please fix this bug ASAP.

[jojoin]

After preliminary analysis, all block data and ledger balances were free of errors. There are two possibilities for this error:

1. When updating to the new version of the full node, all block data is not deleted and resynchronized, or other reasons, resulting in the corruption of the ledger data, and the balance recorded by some nodes is wrong, resulting in the blocks mined by other nodes cannot be passed.

2. Due to an error in the tx pool to identify and check transactions, the newly mined block contains two transfers (or even the same transaction may be included twice), the first transfer is successfully verified, but the second transfer will fail due to insufficient balance.

For now, the second reason is more likely. No one is attacking the network, this problem will disappear after restarting the full node, please notify every miners to restart the full node.

If quickly find out where the bug is, a fixed version will be released soon.

[vaibhavch]

After preliminary analysis, all block data and ledger balances were free of errors. There are two possibilities for this error:

1. When updating to the new version of the full node, all block data is not deleted and resynchronized, or other reasons, resulting in the corruption of the ledger data, and the balance recorded by some nodes is wrong, resulting in the blocks mined by other nodes cannot be passed.

2. Due to an error in the tx pool to identify and check transactions, the newly mined block contains two transfers (or even the same transaction may be included twice), the first transfer is successfully verified, but the second transfer will fail due to insufficient balance.

For now, the second reason is more likely. No one is attacking the network, this problem will disappear after restarting the full node, please notify every miners to restart the full node.

If quickly find out where the bug is, a fixed version will be released soon.

I have restarted my node when this happened. Multiple times. Our Pool found block during this time and same happened with other miners also except the one. Lot of POW computation is wasted because of this.

[jojoin]

There is indeed a block generation bug here: invalid or duplicate transactions are not culled. The issue has been fixed, and here is the fix record for the code commit and the new full node download:

Repair code commit

Fullnode releases v0.2.2

Thank you very much.

[vaibhavch]

Issue is not solved. same error and segmentation core dumped.

./hacash_fullnode_ubuntu [Config] Load: /root/hacash.config.ini 2025-02-17 17:47:29. [Version] full node v0.2.2, build time: 2025/02/18(1), database type: 1. [Engine] Data: /root/./hacash_mainnet_data, rebuild (629118)➢629119➢629120➢629121➢629122 ok. [Http Api Server] Listening on http://0.0.0.0:8081 [P2P] Start and listening on 3337. [P2P] Connect 3 boot nodes, 54.193.49.59:3337, 182.92.163.225:3337, 54.219.80.127:3337. [Peer] hn_rust_dev<54.193.49.59:3337> connected, total 1 public 0 subnet. [Peer] rustndbj<182.92.163.225:3337> connected, total 2 public 0 subnet. [Peer] .Diarust<54.219.80.127:3337> connected, total 3 public 0 subnet. Segmentation fault (core dumped) root@localhost:~# ./hacash_fullnode_ubuntu [Config] Load: /root/hacash.config.ini 2025-02-17 17:47:40. [Version] full node v0.2.2, build time: 2025/02/18(1), database type: 1. [Engine] Data: /root/./hacash_mainnet_data, rebuild (629118)➢629119➢629120➢629121➢629122 ok. [Http Api Server] Listening on http://0.0.0.0:8081 [P2P] Start and listening on 3337. [P2P] Connect 3 boot nodes, 54.193.49.59:3337, 182.92.163.225:3337, 54.219.80.127:3337. [Peer] hn_rust_dev<54.193.49.59:3337> connected, total 1 public 0 subnet. [Peer] rustndbj<182.92.163.225:3337> connected, total 2 public 0 subnet. [Peer] .Diarust<54.219.80.127:3337> connected, total 3 public 0 subnet. [P2P] Searching nodes...find 12 nearest nodes, try connect... [Peer] hne000ac35<62.113.200.176:3337> connected, total 4 public 0 subnet. [Peer] Diamand_09936736<43.156.110.145:3307> connected, total 4 public 0 subnet. [Peer] hn9b5dab11<149.50.101.58:21013> connected, total 4 public 0 subnet. [Peer] Diamand_96513062<170.106.137.26:43337> connected, total 4 public 0 subnet. [Peer] hnaa73e3b0<83.229.120.53:3337> connected, total 4 public 0 subnet. [Peer] D<135.181.97.41:5557> connected, total 4 public 0 subnet. [Peer] hn736d7c70<176.40.120.221:3337> connected, total 4 public 0 subnet. [Peer] hn7450efc6<8.152.192.27:3337> connected, total 4 public 0 subnet. [Peer] hn_09cec2a743<192.99.21.36:3337> connected, total 4 public 0 subnet. [Peer] hn86c3c554<146.19.24.186:21018> connected, total 4 public 0 subnet. [Peer] hn6edfb597<45.207.45.4:3337> connected, total 4 public 0 subnet. [Peer] rust_node<47.242.254.135:3337> connected, total 4 public 0 subnet. ❏ block 629123 …000874d94e042257…871f txs34 insert at 17:48:03 Error: address 1GstxbwyysbPXUwbNddfjxM8aemKN2kH3v balance 614633001:241 is insufficient, at least 18528:246

[taras5888]

hey @jojoin, have a fast question, robotpool now owning 51%, will auction solution work at all after 107000 block? or he can attack 51 on auctions? As well question what exactly can he do now with 51%

[vaibhavch]

@joijoin Actually this is a serious concern. intentionally abusing using the bug making other miners irrelevant which can lead to forking chain whenever they want. Please test it and make an announcement so that all miners will update their nodes.

❏ block 629145 …0007826d93929dbf…f175 txs 5 insert at 22:34:46 ok.
[TxPool] tx count: normal(4), diamond mint(0).
❏ block 629146 …000487abd2523aea…6f8f txs89 insert at 22:37:39 Error: diamond BZYXZT not belong to address 1KsnugbSS2R29j4QwTFsp83sjqCUnS8X6V
❏ block 629146 …0007b3f5d03c29fa…3c22 txs35 insert at 22:40:31 Error: diamond IMBEZK not belong to address 1KsnugbSS2R29j4QwTFsp83sjqCUnS8X6V
❏ block 629146 …0007771c6e3a4d18…b39d txs38 insert at 22:44:17 Error: diamond IMBEZK not belong to address 1KsnugbSS2R29j4QwTFsp83sjqCUnS8X6V

[hacashaddcit]

is the latest node still version 0.2.2?

[jojoin]

@vaibhavch

This requires all miners to update their full nodes, and as long as one miner is minting an incorrect block, the updated full node will still receive and print this error message.

If it is confirmed that this version of the software has solved the problem, then it is necessary to notify all miners to update.

[jojoin]

@taras5888
There will be a hard fork across the network, and even if it is a longer chain, other honest miners and full nodes will not approve of it.

[BevRigby]

What if one miner will not update his Fullnode software?

Im not a dev and my thinking is pretty straightforward, but is there a possibility to implement in fullnode some kind of "update checker"? Fullnode will randomly check lets say once per day if new version is available, and pop out some notification/commend that its needed to be updated?

[taras5888]

@jojoin thx for respond, btw that problem with forks is still there. What if robotpool trying to attack the chain when he can add any amount of blocks ahead?

[jojoin]

@wilk023 Nothing bad will happen, miners who don't update will just waste their hashrates.
@taras5888 This is a fork by consensus change, in fact, two different chains. RobotPool can mine its own chain all the time, but the other miners don't play with it anymore.