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

💬 jsarenik commented on issue "not punishing manually connected peer":
(https://github.com/bitcoin/bitcoin/issues/30426#issuecomment-2222249865)
Yes! Calling `gettxoutsetinfo muhash` triggered this:

```
2024-07-11T07:36:31Z Fatal LevelDB error: Corruption: block checksum mismatch: /home/b/.bitcoin/chainstate/13938982.ldb
2024-07-11T07:36:31Z You can use -debug=leveldb to get more complete diagnostic messages
2024-07-11T07:36:31Z *** System error while flushing: Fatal LevelDB error: Corruption: block checksum mismatch: /home/b/.bitcoin/chainstate/13938982.ldb
2024-07-11T07:36:31Z Error: A fatal internal error occurred, see debug.lo
...

✅ 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-2222253823)
Thank you for support, @maflcko !

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

💬 maflcko commented on pull request "rpc, rest: Improve getblock error when only header is available":
(https://github.com/bitcoin/bitcoin/pull/30410#issuecomment-2222264395)
> Makes sense to me, so concept a c k to that! Depending on how large this PR is going to be and how long it's going to take to complete it, I could either close this simple PR, which changes return errors and is not a refactor, or it could be a pure refactor on top of it? Let me know what you prefer.

Ok, I'll give it a try.

Another thing to check before closing the issue is the RPC return code: https://github.com/bitcoin/bitcoin/issues/20978#issuecomment-764846601 to confirm it is accurat
...

👍 darosior approved a pull request: "descriptors: Be able to specify change and receiving in a single descriptor string"
(https://github.com/bitcoin/bitcoin/pull/22838#pullrequestreview-2168736128)
ACK 00337ef0e115f8bd8c1ede425f21ae7a1b6d30de

💬 darosior commented on pull request "descriptors: Be able to specify change and receiving in a single descriptor string":
(https://github.com/bitcoin/bitcoin/pull/22838#discussion_r1672053063)
nit: not dramatic but could have used a set to avoid `O(n^2)` complexity.

In any case we'll probably have to put some bounds on the number of multipaths steps in the fuzzer to avoid timeouts (as in #30197) as there is a few operations quadratic in the number of steps. Of course, not in this PR.

💬 darosior commented on pull request "descriptors: Be able to specify change and receiving in a single descriptor string":
(https://github.com/bitcoin/bitcoin/pull/22838#discussion_r1673572894)
I still think this behaviour should be documented in the help of `importmulti` and `importdescriptors`.

💬 Sjors commented on pull request "net: additional disconnect logging":
(https://github.com/bitcoin/bitcoin/pull/28521#issuecomment-2222360783)
Rebased after #29431

@davidgumberg this PR makes it easier to do something like `cat ~/.bitcoin/debug.log | grep disconnect`, and avoid the need for e.g. `grep -n2` (or more) to get additional context.

I switched to `LogDebug` in the lines touched by this PR.

💬 Sjors commented on pull request "refactor: add coinbase constraints to BlockAssembler::Options":
(https://github.com/bitcoin/bitcoin/pull/30356#discussion_r1673640115)
Thanks.

💬 Sjors commented on pull request "Stratum v2 Template Provider (take 3)":
(https://github.com/bitcoin/bitcoin/pull/29432#issuecomment-2222418506)
@ryanofsky wrote:

> If it would help, I could make a draft PR for a test program that will do what you describe: connect to bitcoin-node over a unix socket if it is running, or start bitcoin-node if it is not running, and then call a mining interface function like `getTipHash()` and print the result.

Yes that would be very helpful.

At least one large objection I have to the sidecar approach is that it tends to be very clunky, having to deal with our p2p, rpc and zmq interfaces which are
...

💬 glozow commented on pull request "system: use %LOCALAPPDATA% as default datadir on windows":
(https://github.com/bitcoin/bitcoin/pull/27064#discussion_r1673700081)
Not a big deal, just don't want it to get missed when releasing 28.0

💬 brunoerg commented on pull request "Tr partial descriptors":
(https://github.com/bitcoin/bitcoin/pull/30243#issuecomment-2222479283)
You can squash some commits.

💬 Sjors commented on pull request "refactor: add coinbase constraints to BlockAssembler::Options":
(https://github.com/bitcoin/bitcoin/pull/30356#issuecomment-2222490758)
Spurious CI / ASan failure, see #30419.

💬 Eunovo commented on pull request "locks: introduce mutex for tx download, flush rejection filters on UpdatedBlockTip":
(https://github.com/bitcoin/bitcoin/pull/30111#discussion_r1673668471)
IIUC `ActivateBestChain` will fire `ActiveTipChange` as long as the current instance is the active chain state. `InvalidateBlock` and `ActivateBestChain` are both called on active chain state so it doesn't seem like there's a situation where `ActiveTipChange` won't be fired before this point. Could this comment be misleading?