⚠️ 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

💬 Sjors 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-2059278946)
utACK cbcb2c82669deaad71e739c64b1baf687e76e604

Holding on to `cs_main` in this particular spot, when index catches up to the tip, is not a big deal performance wise. The other, much more frequently called `Commit()` in `Sync()` was already done without holding `cs_main`.

💬 ryanofsky commented on pull request "indexes: Stop using node internal types and locking cs_main, improve sync logic":
(https://github.com/bitcoin/bitcoin/pull/24230#discussion_r1567499444)
In commit "indexes: Rewrite chain sync logic, simplify index sync code" (ffa9e452ac7cfe08deecaae409eca3369dcccb76)

This commit has the same race condition reported in #29767 (which was introduced in #14121 and fixed in #29776), so when this PR is rebased it needs to incorporate a fix similar to #29776.

The problem is that index is considered synced before the last block is commited so new blocks could attached from the validationinterface thread while this thread is still committing. Proba
...

💬 Sjors commented on pull request "wallet: add `seeds` argument to `importdescriptors`":
(https://github.com/bitcoin/bitcoin/pull/27351#issuecomment-2059296060)
Now that we have a `createwalletdescriptor` RPC call #29130, this could be expanded to take private key material, as suggested by @ryanofsky: https://github.com/bitcoin/bitcoin/pull/29130#discussion_r1435607572

codex32 then be one of the import formats.

💬 apoelstra commented on pull request "wallet: add `seeds` argument to `importdescriptors`":
(https://github.com/bitcoin/bitcoin/pull/27351#issuecomment-2059322038)
Thanks! The next time I am working on codex32 wallet support I will try that approach instead.

💬 stickies-v commented on pull request "RPC: access RPC arguments by name":
(https://github.com/bitcoin/bitcoin/pull/29277#issuecomment-2059323658)
> Does it work with `OBJ_NAMED_PARAMS`?

Nope. I think we should just address the general use case of getting `OBJ`/`ARR` args with the `Arg` helpers, and then that should help with `OBJ_NAMED_PARAMS` too?

💬 maflcko commented on pull request "RPC: access RPC arguments by name":
(https://github.com/bitcoin/bitcoin/pull/29277#discussion_r1567534464)
It could make sense to remove the index-based access and require the name-based access?

💬 sipa commented on pull request "fuzz: explicitly cap the vsize of RBFs for diagram checks":
(https://github.com/bitcoin/bitcoin/pull/29879#issuecomment-2059335680)
utACK 9d76d77ba04450e8b5b5a528b448b61c61346193

💬 Sjors commented on pull request "depends: suggest GNU patch for macOS <= 13":
(https://github.com/bitcoin/bitcoin/pull/29814#discussion_r1567544335)
Yes I left that out, because the command will tell you to.

(also agree that we should at least wait until someone else runs into this)