✅ willcl-ark closed an issue: "ihsota ottomakan"
(https://github.com/bitcoin/bitcoin/issues/27606)

💬 Sjors commented on pull request "build: produce a .zip for macOS distribution":
(https://github.com/bitcoin/bitcoin/pull/27099#issuecomment-1539795569)
When I do `make` followed by `make deploy` on e82e73103ce81159f6f1a51408ce5411b88a12b2 on macOS 13.3.1 I end up with three files / folders:
1. Bitcoin-Qt.app (which Finder displays as "Bitcoin Core")
2. Bitcoin-Core.zip
3. dist/Bitcoin-Qt.app

It seems like only the zip file needs to be there?

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

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