💬 hebasto commented on pull request "deploy: remove some tools when cross-compiling for macOS":
(https://github.com/bitcoin/bitcoin/pull/29890#discussion_r1567171605)
https://github.com/bitcoin/bitcoin/blob/c7567d9223a927a88173ff04eeb4f54a5c02b43d/contrib/macdeploy/macdeployqtplus#L231

💬 fanquake commented on pull request "deploy: remove some tools when cross-compiling for macOS":
(https://github.com/bitcoin/bitcoin/pull/29890#discussion_r1567172725)
Did you read the description? Neither of these code paths are hit when cross compiling.

💬 hebasto commented on pull request "deploy: remove some tools when cross-compiling for macOS":
(https://github.com/bitcoin/bitcoin/pull/29890#discussion_r1567178023)
> Did you read the description?

I did.

> Neither of these code paths are hit when cross compiling.

It is not obvious from reading the ``macdeployqtplus` code. Maybe add a few comments to make it clear?

💬 instagibbs commented on pull request "fuzz: explicitly cap the vsize of RBFs for diagram checks":
(https://github.com/bitcoin/bitcoin/pull/29879#discussion_r1567200048)
done

💬 instagibbs commented on pull request "fuzz: explicitly cap the vsize of RBFs for diagram checks":
(https://github.com/bitcoin/bitcoin/pull/29879#issuecomment-2058873450)
@glozow was waiting for positive feedback. Squashed.

💬 instagibbs commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1559187981)
newline?

💬 instagibbs commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1559188232)
newline?

💬 instagibbs commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1567205749)
> The other benefit is extensibility in the future. In more general ancestor package relay, we could reject a parent+child for being too low feerate, but later accept it as parent+child+grandchild (where the grandchild is very high feerate).

Perhaps this doesn't matter but I'm not sure I understand the distinction here. We need the combined hash committed *somewhere* in a bloom filter to not fetch the same ancestor package again. If it's different at all, we'll fetch it regardless of which fi
...

💬 laanwj commented on pull request "ZMQ: Support UNIX domain sockets":
(https://github.com/bitcoin/bitcoin/pull/27679#discussion_r1567251185)
fwiw, i prefer having only a single consistent syntax for unix sockets throughout the RPC settings. Outside of zmq i've never heard of a `ipc://` scheme. It's better to just document this.

💬 laanwj commented on pull request "guix: remove `gcc-toolchain static` from Windows build":
(https://github.com/bitcoin/bitcoin/pull/29828#issuecomment-2058958011)
ACK 05da2460db895374ea1fd89e4b8b4b73689f8faf

- i get the same build output as @hebasto
- compared the import headers between this PR and the commit before it, no changes at all:
```
$ x86_64-w64-mingw32-objdump -p bitcoin-05da2460db89/bin/bitcoin-qt.exe > b
$ x86_64-w64-mingw32-objdump -p bitcoin-f0794cbd4056/bin/bitcoin-qt.exe > a
$ diff -du a b
--- a 2024-04-16 14:15:13.713101675 +0200
+++ b 2024-04-16 14:15:06.641040571 +0200
@@ -1,5 +1,5 @@

-bitcoin-f0794cbd4056/bin/bitcoin
...

💬 fanquake commented on pull request "depends: swap some cctools tools for LLVM tools":
(https://github.com/bitcoin/bitcoin/pull/29739#issuecomment-2058963767)
> Fixed up.

This was actually just masking a bug. Dropped and rebased on #29890, which has simplified things here.

💬 laanwj commented on pull request "ZMQ: Support UNIX domain sockets":
(https://github.com/bitcoin/bitcoin/pull/27679#discussion_r1567266789)
Let's move this prefix to some zmq specific header or implementation file, no need for it to be in `netbase.h`.

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1567269406)
Hm I think you're right, it wouldn't make a difference with downloads. Crossing that part out. Were we thinking of this within validation maybe? Linearize + chunk the package, see that a chunk has already been rejected as too low feerate, drop it?

💬 laanwj commented on pull request "ZMQ: Support UNIX domain sockets":
(https://github.com/bitcoin/bitcoin/pull/27679#discussion_r1567269978)
Is `ReplaceAll` the right function to use here?
Sure, it's unlikely for it to appear multiple times, but from a principle of least surprise angle, it'd make sense to only replace the prefix.

💬 theStack commented on pull request "util: remove unused cpp-subprocess options":
(https://github.com/bitcoin/bitcoin/pull/29865#issuecomment-2058973410)
Thanks a lot for you feedback @laanwj, @hebasto, I've now removed support for all options that we don't use. Especially for the environment option, lots of Windows-specific code can be removed.

⚠️ achow101 unpinned an issue: "Release schedule for 27.0"
(https://github.com/bitcoin/bitcoin/issues/29028)
Here is a proposed release schedule for `v27.0`, the next major release of Bitcoin Core. Dates roughly chosen as discussed in the most recent IRC meeting.

## 2024-02-01 :heavy_check_mark:
- Open Transifex translations for `v27.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v25.0`

## 2024-02-12 :heavy_check_mark:
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source
...

⚠️ achow101 opened an issue: "Release Schedule for 28.0"
(https://github.com/bitcoin/bitcoin/issues/29891)
Here is a proposed release schedule for `v28.0`, the next major release of Bitcoin Core. The dates are set to target a release in early October as was previously discussed.

## 2024-08-01 :construction:
- Open Transifex translations for `v28.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v26.0`

## 2024-08-12 :construction::
- Feature freeze (bug fixes only until release)
- Translation string freeze (no
...

⚠️ achow101 pinned an issue: "Release Schedule for 28.0"
(https://github.com/bitcoin/bitcoin/issues/29891)
Here is a proposed release schedule for `v28.0`, the next major release of Bitcoin Core. The dates are set to target a release in early October as was previously discussed.

## 2024-08-01 :construction:
- Open Transifex translations for `v28.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `v26.0`

## 2024-08-12 :construction::
- Feature freeze (bug fixes only until release)
- Translation string freeze (no
...

💬 maflcko commented on pull request "refactor: rpc: Remove unnecessary uses of ParseNonRFCJSONValue() and rename it":
(https://github.com/bitcoin/bitcoin/pull/27256#discussion_r1567356943)
You can't check equality on a floating point value that can not be represented exactly.

Compilers are free to pick whatever precision and rounding they want. They don't even have to be self-consistent. See https://eel.is/c++draft/expr.const#15

Please either remove the test, or restore it so that this works on integral values via `AmountFromValue`.

Otherwise, the test may fail on some compilers:


```
# ./src/univalue/test/object
object: univalue/test/object.cpp:424: void univalue_
...

💬 andrewtoth commented on pull request "index: race fix, lock cs_main while 'm_synced' is subject to change":
(https://github.com/bitcoin/bitcoin/pull/29867#issuecomment-2059115444)
utACK cbcb2c82669deaad71e739c64b1baf687e76e604

> I didn't do it because the revert is not clean. It conflicts with https://github.com/bitcoin/bitcoin/commit/bbe82c116e72ca0638751e063bf564cd1fe5c4d5 and it would require an extra commit for the added doc (which, based on the regression, is a must have for me).

Not a blocker, but I think it would be cleaner if this PR was the following 3 commits:
```
revert bbe82c116e72ca0638751e063bf564cd1fe5c4d5
revert 0faafb57f8298547949cbc0044ee9e925ed
...