:lock: fanquake locked an issue: "ihsota ottomakan"
(https://github.com/bitcoin/bitcoin/issues/27606)

💬 hebasto commented on pull request "refactor: Replace global find_value function with UniValue::find_value method":
(https://github.com/bitcoin/bitcoin/pull/27605#issuecomment-1539824898)
Concept ACK.

💬 GregTonoski commented on issue "Bitcoin Core startup is interrupted if there is the setting mintxfee=0 in bitcoin.conf":
(https://github.com/bitcoin/bitcoin/issues/26797#issuecomment-1539850711)
I confirm that the bug is fixed 25.0rc1 (I have verified on the https://bitcoincore.org/bin/bitcoin-core-25.0/test.rc1/bitcoin-25.0rc1-win64.zip).

💬 TheCharlatan commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1188449666)
That works :)

💬 TheCharlatan commented on pull request "refactor: Move chain constants to the util library":
(https://github.com/bitcoin/bitcoin/pull/27491#issuecomment-1539887649)
Updated 43dec8806f679005d4484b229f433687526c9133 -> 1ae4d9a37b46a5e69ed79066408a6002c2cc0f73 ([kernelChainType_5](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_5) -> [kernelChainType_6](https://github.com/TheCharlatan/bitcoin/tree/kernelChainType_6), [compare](https://github.com/TheCharlatan/bitcoin/compare/kernelChainType_5..kernelChainType_6))

* Addressed @MarcoFalke's [comment](https://github.com/bitcoin/bitcoin/pull/27491#discussion_r1188242770), changed throwing an excepti
...

👍 hebasto approved a pull request: "refactor: Replace global find_value function with UniValue::find_value method"
(https://github.com/bitcoin/bitcoin/pull/27605#pullrequestreview-1418388106)
ACK fa0d180f48d4e5253f58aced32768369f963d1c7, tested on Ubuntu 23.04 using GCC 13.0.1.

💬 MarcoFalke commented on pull request "refactor: Replace global find_value function with UniValue::find_value method":
(https://github.com/bitcoin/bitcoin/pull/27605#issuecomment-1539948491)
> Ubuntu 23.04 using GCC 13.0.1

I think it ships with 12.2? https://packages.ubuntu.com/lunar/gcc

👍 stickies-v approved a pull request: "refactor: Replace global find_value function with UniValue::find_value method"
(https://github.com/bitcoin/bitcoin/pull/27605#pullrequestreview-1418401022)
ACK fa0d180f48d4e5253f58aced32768369f963d1c7

I can't see any behaviour change, and as far as I can tell using references in fa0d180f48d4e5253f58aced32768369f963d1c7 doesn't introduce any (potential) lifetime issues.

💬 stickies-v commented on pull request "refactor: Replace global find_value function with UniValue::find_value method":
(https://github.com/bitcoin/bitcoin/pull/27605#discussion_r1188470576)
I think this should be `LIFETIMEBOUND`?

💬 MarcoFalke commented on pull request "refactor: Replace global find_value function with UniValue::find_value method":
(https://github.com/bitcoin/bitcoin/pull/27605#discussion_r1188513782)
Maybe in a follow-up for the whole univalue interface?

💬 willcl-ark commented on pull request "refactor: Remove unused GetTimeMillis":
(https://github.com/bitcoin/bitcoin/pull/27594#issuecomment-1539994241)
tACK fae1d9cded

Also removes `GetSystemTime` which because unused after faf3f12424.

Curious if you have any plans for `GetTime()` (marked deprecated since [16046](https://github.com/bitcoin/bitcoin/pull/16046))?

💬 Sjors commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#issuecomment-1539999879)
The first commit tends to confuses me, so I'll just note a clarification here. I'm not fully convinced that blocks near the tip can't end up getting processed by the background chainstate. And if they do, I'm not sure if that's bad.

When a block comes in near the tip, we know the header so `LookupBlockIndex` will return a `pblock`. This header is _not_ contained in `m_chain`, because headers are only added to `m_chain` by `ConnectTip()`. So a potential tip block is sent to the snapshot chains
...

💬 Sjors commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#discussion_r1188458662)
426ebe830b3bb076182505b60233e8c8f6d35069: the `m_snapshot_chainstate` check is now redundant: https://github.com/bitcoin/bitcoin/pull/24008/commits/426ebe830b3bb076182505b60233e8c8f6d35069#r1171549876

💬 MarcoFalke commented on pull request "refactor: Remove unused GetTimeMillis":
(https://github.com/bitcoin/bitcoin/pull/27594#issuecomment-1540006864)
> Curious if you have any plans for GetTime()

Yeah, I guess it can be removed as well, assuming there are no merge conflicts with other open pulls?

💬 Sjors commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1540014195)
@ArmchairCryptologist do you have `peerbloomfilters` on?

💬 ArmchairCryptologist commented on issue "CPU DoS on mainnet in debug mode":
(https://github.com/bitcoin/bitcoin/issues/27586#issuecomment-1540022998)
> @ArmchairCryptologist do you have peerbloomfilters on?

Nope. The nodes are pretty much running with the default settings except for maxconnections.

💬 instagibbs commented on issue "Parallel compact block download":
(https://github.com/bitcoin/bitcoin/issues/25258#issuecomment-1540028533)
This also seems to happen with spy(?) nodes which are the first to send a header, but then never end up responding to requests for the full block. Due to recent mempool chop, the chances of requiring a round-trip for slightly-later-but-behaving high bandwidth peer's cb goes way up, and currently cannot be accommodated.

couple of questions to think about:
1) should the 2nd download only work for outbound connections? currently there are 3 hb peers possible, and only one outbound is "protected
...

🤔 Sjors reviewed a pull request: "assumeutxo: net_processing changes"
(https://github.com/bitcoin/bitcoin/pull/24008#pullrequestreview-1418514150)
26cb32c02d76d6635c67942a5eeb70a6199df69d is missing a comment for the use of `ActiveChainstate` in `ProcessGetBlockData` and after receiving a `GETBLOCKS` message.

💬 Sjors commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#discussion_r1188522463)
c7cdc7ca833ce1b5ce9a696fb4ef633c55528023: this line does more than "add commentary". Maybe move this to 3a7a714721a593e271ce70d4612c995968dbb0da or its own commit directly after that one?

The code comment could clarify why we care about this even for the background sync: "with insufficient work" -> "with less than the minimum chain work."

💬 sdaftuar commented on pull request "assumeutxo: net_processing changes":
(https://github.com/bitcoin/bitcoin/pull/24008#issuecomment-1540089055)
> @sdaftuar did you have Current Thoughts about this approach? Trying to bridge IRC discussions to the blocking PR

I was trying to come up with my own proof-of-concept to demonstrate an alternate approach before commenting, but just to get everyone up to speed on what I'm thinking:

* The first commit "validation: introduce ChainstateManager::GetChainstateForNewBlock" seems like something we don't conceptually need. I think the underlying issue is that `AcceptBlock` should be chainstate-agn
...