💬 maflcko commented on pull request "test: Fix intermittent failure in p2p_v2_misbehaving.py":
(https://github.com/bitcoin/bitcoin/pull/30420#discussion_r1673460520)
A more involved alternative would be to add a passing connection after the misbehaving one, then wait for the disconnect of the misbehaving one after the passing one is fully connected. This should allow to avoid using the debug log polling to sync on and proceed with the test.

💬 maflcko commented on pull request "test: fix inconsistency in fundrawtransaction weight limits test":
(https://github.com/bitcoin/bitcoin/pull/30353#issuecomment-2222128215)
The test failure looks unrelated:

```
2024-07-10T23:36:07.2558178Z test_framework.authproxy.JSONRPCException: 'stop' RPC took longer than 1200.000000 seconds. Consider using larger timeout for calls that take longer to return. (-344)
```

https://github.com/bitcoin/bitcoin/actions/runs/9882674449/job/27296008093?pr=30353

```
2024-07-10T23:36:12.6566166Z test 2024-07-10T23:16:06.381000Z TestFramework (INFO): Stopping nodes
2024-07-10T23:36:12.6566491Z test 2024-07-10T23:16:06.381
...

⚠️ jsarenik opened an issue: "not punishing manually connected peer"
(https://github.com/bitcoin/bitcoin/issues/30426)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour



The only peer (via `connect=IP` in `bitcoin.conf`) is another local node also running this same aba504759caa version and that node has 94 other peers at the moment so I guess there is no problem there.

I do not know if it is related, but since I run aba504759caa (the testnet4 commit) also for mainnet, here is link to testnet4: https://github.com/bitcoin/bitcoin/pull/29775

### Expec
...

💬 maflcko commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222145194)
You'll have to enable at least the `net` debug log category to get some more details on the type of misbehaviour. (C.f. `PeerManagerImpl::Misbehaving`)

💬 GBKS commented on pull request "Bugfix: Correct first-run free space checks":
(https://github.com/bitcoin/bitcoin/pull/29678#issuecomment-2222160247)
> The GUI now uses "GB" (SI prefix) as a unit, based on the mindset of non-technical/non-CS users.

`GB` is standard for general audiences, and `GiB` for technical, scientific, or engineering contexts. I'd recommend keeping `GB` in the GUI.

I am curious about use cases where it is essential for the user to know the `GiB` value in order to make decisions.

✅ jsarenik closed an issue: "not punishing manually connected peer"
(https://github.com/bitcoin/bitcoin/issues/30426)

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222166663)
Thanks, closing for now. This may be something local related to my setup. Thanks for `debug=net` hint as it is showing me interesting things but there is so much it wouldn't make sense to write here until I understand it slightly better.

⚠️ jsarenik reopened an issue: "not punishing manually connected peer"
(https://github.com/bitcoin/bitcoin/issues/30426)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour



The only peer (via `connect=IP` in `bitcoin.conf`) is another local node also running this same aba504759caa version and that node has 94 other peers at the moment so I guess there is no problem there.

I do not know if it is related, but since I run aba504759caa (the testnet4 commit) also for mainnet, here is link to testnet4: https://github.com/bitcoin/bitcoin/pull/29775

### Expec
...

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222170006)
Ah, I have something:

```
2024-07-11T06:50:34Z initload thread exit
2024-07-11T06:50:34Z [net] sending getheaders (1029 bytes) peer=0
2024-07-11T06:50:34Z [net] initial getheaders (851623) to peer=0 (startheight:851650)
2024-07-11T06:50:34Z Leaving InitialBlockDownload (latching to false)
2024-07-11T06:50:34Z [net] received: headers (2188 bytes) peer=0
2024-07-11T06:50:34Z [net] Misbehaving: peer=0: invalid header received
2024-07-11T06:50:34Z Warning: not punishing manually connected
...

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222173245)
How can I receive an invalid header from a perfectly running node?

mainnet, I just use the same version which I use for testnet4

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222191303)
```
2024-07-11T07:02:21Z UpdateTip: new best=000000000000000000036686ffd324b99fa90f190f48c7372e14738bda739383 height=851624 version=0x2462e000 log2_work=95.031625 tx=1038976733 date='2024-07-11T02:42:12Z' progress=0.999901 cache=17.4MiB(151149txo)
2024-07-11T07:02:21Z initload thread exit
2024-07-11T07:02:21Z [net] sending getheaders (1029 bytes) peer=0
2024-07-11T07:02:21Z [net] initial getheaders (851623) to peer=0 (startheight:851650)
2024-07-11T07:02:21Z Leaving InitialBlockDownload (la
...

💬 maflcko commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222191711)
ugh. Why is the `BlockValidationState` not logged?

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222192561)
Already on Bitcoin 27.1 binary release from bitcoincore.org

💬 maflcko commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222197175)
> ugh. Why is the `BlockValidationState` not logged?

You'll also have to enable validation logging. (C.f. `ChainstateManager::AcceptBlockHeader`)

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222210269)
```
2024-07-11T07:15:41Z UpdateTip: new best=000000000000000000036686ffd324b99fa90f190f48c7372e14738bda739383 height=851624 version=0x2462e000 log2_work=95.031625 tx=1038976733 date='2024-07-11T02:42:12Z' progress=0.999896 cache=17.2MiB(151149txo)
2024-07-11T07:15:41Z [validation] Enqueuing BlockConnected: block hash=000000000000000000036686ffd324b99fa90f190f48c7372e14738bda739383 block height=851624
2024-07-11T07:15:41Z [validation] Enqueuing UpdatedBlockTip: new block hash=00000000000000000
...

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222218220)
```
2024-07-11T07:20:02Z [validation] AcceptBlockHeader: block 00000000000000000000c29870d6f87b9aca6577e25ab2a780603e605db99ae4 is marked invalid
2024-07-11T07:20:02Z [net] Misbehaving: peer=0 (0 -> 100) DISCOURAGE THRESHOLD EXCEEDED: invalid header received
2024-07-11T07:20:02Z Warning: not punishing manually connected peer 0!
```

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222220690)
marked invalid here on this run, but not by mempool https://mempool.space/block/00000000000000000000c29870d6f87b9aca6577e25ab2a780603e605db99ae4

💬 maflcko commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222222527)
You'll have to check the debug log when `00000000000000000000c29870d6f87b9aca6577e25ab2a780603e605db99ae4` was first connected to see the error reason.

But my guess would be corruption on your machine.

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222226878)
OK, data corruption is possible. How can I tell Bitcoin to redownload that block again?

💬 maflcko commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222239736)
re-downloading the block may not be enough, depending on the data corruption.

For example, if the utxo db is corrupt, you'll have to build it from scratch.

I think calling the RPC `gettxoutsetinfo muhash` on both nodes (when they are synced to the same block) and it matches for all, then the chainstate leveldb at that point in time is probably fine.

To recreate the block connection to get the failure again, I think you can use `invalidateblock`+`reconsiderblock`.