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

💬 orangesurf commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-2059120917)
An update to @petertodd's stats from July, at least 97.7 % of hashrate (monthly average) is now running FullRBF based on FullRBF'd transactions from within the past 24 hours.

|Miner|Miner Hash (%)|
|-----|--------------|
|[AntPool](http://mempool.space/tx/c004c39d2d83884397e1ed35ef40a79338adcd32dd68eb23e184d6e14bcf1849)|22.7|
|[BTC.com](http://mempool.space/tx/080e59af2e6ad8066bb7bf5ee5ba41675415f4ef906cb99951c6539f26454d4b)|1.7|
|[Binance Pool](http://mempool.space/tx/9696ee89cd20b6281d
...

💬 ryanofsky commented on pull request "index: block filters sync, reduce disk read operations by caching last header":
(https://github.com/bitcoin/bitcoin/pull/28955#discussion_r1567420767)
In commit "index: decrease ThreadSync cs_main contention" (0faafb57f8298547949cbc0044ee9e925ed887ba)

Note: This commit introduces a race condition, because it is no longer locking cs_main while calling `NextSyncBlock` and setting `m_synced = true`. As a result, a new block could be connected by another thread after `NextSyncBlock` returns null in this thread, but before `m_synced` is set to true, so the block will never be indexed because BlockConnected notifications are ignored while m_synce
...

💬 pinheadmz commented on pull request "netbase: clean up Proxy logging":
(https://github.com/bitcoin/bitcoin/pull/29882#discussion_r1567454897)
Restoring the check, without the log and revising the PR description.

💬 achow101 commented on pull request "wallet: Implement independent BDB parser":
(https://github.com/bitcoin/bitcoin/pull/26606#issuecomment-2059220656)
> That's good to have. It does look like the newly added check trips up in the CI in some places:
>
> ```
> unknown location(0): fatal error: in "db_tests/db_cursor_prefix_range_test": class std::runtime_error: LSNs are not reset, this database is not completely flushed. Please reopen then close the database with a version that has BDB support
> ```

Fixed

💬 pablomartin4btc commented on pull request "assumeutxo, rpc: Improve EOF error when reading snapshot metadata in loadtxoutset":
(https://github.com/bitcoin/bitcoin/pull/28670#discussion_r1567469129)
Thanks! I agree, I'll update it if I have to retouch it and if not, could be done in a follow-up.

📝 maflcko opened a pull request: "test: Fix failing univalue float test"
(https://github.com/bitcoin/bitcoin/pull/29892)
Currently the test may fail for some compilers, because `1e-8` may not be possible to represent exactly/consistently.

```
$ ./src/univalue/test/object
object: univalue/test/object.cpp:424: void univalue_readwrite(): Assertion `v.read("0.00000000000000000000000000000000000001e+30 ") && v.get_real() == 1e-8' failed.
Aborted (core dumped)
```

Fixes https://github.com/bitcoin/bitcoin/pull/27256#discussion_r1567356943

💬 maflcko commented on pull request "refactor: rpc: Remove unnecessary uses of ParseNonRFCJSONValue() and rename it":
(https://github.com/bitcoin/bitcoin/pull/27256#discussion_r1567489469)
Fixed in #29892