💬 fjahr commented on pull request "prune, rpc: Check undo data when finding pruneheight":
(https://github.com/bitcoin/bitcoin/pull/29668#issuecomment-2221722356)
With this merged, I will take #29770 out of draft mode shortly and also address the left-over comments here. Thanks @stickies-v and @furszy !

👍 tdb3 approved a pull request: "test: Fix intermittent failure in p2p_v2_misbehaving.py"
(https://github.com/bitcoin/bitcoin/pull/30420#pullrequestreview-2170625050)
re ACK 53f43293875de086cd0bd424fd582bc232bec3a3
Repeated test in https://github.com/bitcoin/bitcoin/pull/30420#pullrequestreview-2168907582
Would also re-review if maflcko's suggestions were implemented.

👍 tdb3 approved a pull request: "net: fix race condition in self-connect detection"
(https://github.com/bitcoin/bitcoin/pull/30394#pullrequestreview-2170662623)
ACK 16bd283b3ad05daa41259a062aee0fc05b463fa6

💬 tdb3 commented on pull request "test, assumeutxo: Remove resolved todo comments and add new test":
(https://github.com/bitcoin/bitcoin/pull/30403#discussion_r1673251107)
Yup, seems like its the most likely use case for assumeutxo, so I could see how that could be quite verbose.

👍 tdb3 approved a pull request: "test, assumeutxo: Remove resolved todo comments and add new test"
(https://github.com/bitcoin/bitcoin/pull/30403#pullrequestreview-2170666813)
ACK e1018672672f39910655ab37080bf3213ca55a39

💬 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
...