💬 furszy commented on pull request "Return EXIT_FAILURE on post-init fatal errors":
(https://github.com/bitcoin/bitcoin/pull/27708#discussion_r1206869341)
The reason behind that is https://github.com/bitcoin/bitcoin/pull/27607#discussion_r1199624849.
But.. could not expose it and move the caller to use `AbortNode()` instead. Same as we do with the external block import failures.

💬 joostjager commented on pull request "Allow accepting non-standard transactions on mainnet":
(https://github.com/bitcoin/bitcoin/pull/27578#issuecomment-1564482472)
Agreed that the option isn't the most relevant in typical scenarios. But if a restriction can be lifted safely and benefit a specific group of users, why not?

💬 furszy commented on pull request "Return EXIT_FAILURE on post-init fatal errors":
(https://github.com/bitcoin/bitcoin/pull/27708#discussion_r1206881682)
Still, in order to do that in the cleanest possible way, will need to refactor `shutdown.cpp`, so `AbortNode` is placed after the static `StartErrorShutdown` function. Which I'm not so sure that worth it due the conflicts that could cause with your PRs. Thoughts?

💬 pinheadmz commented on pull request "wallet: improve IBD sync time by skipping block scanning prior birth time":
(https://github.com/bitcoin/bitcoin/pull/27469#issuecomment-1564497329)
@furszy awwwwwesome thank you for catching that. Ok, passing test is now at https://github.com/pinheadmz/bitcoin/commit/f1238700a1f3d3e88b7f20bc51f0088783d53595

💬 pinheadmz commented on pull request "wallet: improve IBD sync time by skipping block scanning prior birth time":
(https://github.com/bitcoin/bitcoin/pull/27469#discussion_r1205652539)
I'm curious if `.load()` is necessary for the atomic value? Is this the correct reason? https://stackoverflow.com/a/44288045/1653320

👍 pinheadmz approved a pull request: "wallet: improve IBD sync time by skipping block scanning prior birth time"
(https://github.com/bitcoin/bitcoin/pull/27469#pullrequestreview-1444104729)
ACK 82bb7831fa6052620998c7eef47e48ed594248a8

Reviewed code and tested locally, wrote a test. I am running this branch side-by-side with master on a VPS and will report who wins the race in a day or so ;-)

<details><summary>Show Signature</summary>

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

ACK 82bb7831fa6052620998c7eef47e48ed594248a8
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmRwxNIACgkQ5+KYS2KJ
yTq5nhAA3dJDzRO4VmDUA8n9YO4RtpcQBHT/t9NOs
...

💬 D33r-Gee commented on issue "25.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/27736#issuecomment-1564503293)
> Thank you @evansmj and @D33r-Gee for all your feedback the guide has been updated.

with pleasure!

💬 fanquake commented on issue "25.0 RC Testing Guide Feedback":
(https://github.com/bitcoin/bitcoin/issues/27736#issuecomment-1564505208)
25.0 has been tagged. So closing this issue (conversation/testing of final can continue).

✅ fanquake closed an issue: "25.0 RC Testing Guide Feedback"
(https://github.com/bitcoin/bitcoin/issues/27736)

⚠️ fanquake unpinned an issue: "Release schedule for 26.0"
(https://github.com/bitcoin/bitcoin/issues/27758)
Here is a proposed release schedule for `v26.0`, the next major release of Bitcoin Core. I've aimed for a release roughly 6 months after the planned release of `v25.0` (#26549).

## 2023-09-01 :construction:
- Open Transifex translations for `26.0`
- Soft translation string freeze (no large or non-critical string changes until release)
- Finalize and close translations for `24.0`

## 2023-10-01 :construction:
- Feature freeze (bug fixes only until release)
- Translation string fre
...

⚠️ fanquake pinned an issue: "BIP324 tracking issue"
(https://github.com/bitcoin/bitcoin/issues/27634)
This issue will be updated to reflect the current state of [BIP324](https://github.com/bitcoin/bips/blob/master/bip-0324.mediawiki) integration.

PRs ready for review:
* #27479 (depends on ellswift support in libsecp256k1, though)
* #26222

Overall plan:
* [x] Support for not wasting ChaCha20 stream bytes: #26153
* [ ] ElligatorSwift integration in Bitcoin Core: #27479
* [ ] Dependency: ElligatorSwift support in libsecp256k1: bitcoin-core/secp256k1#1129
* [ ] Cipher suite implement
...

💬 TheCharlatan commented on pull request "Return EXIT_FAILURE on post-init fatal errors":
(https://github.com/bitcoin/bitcoin/pull/27708#discussion_r1206916333)
So IIRC, this call [here](https://github.com/bitcoin/bitcoin/commit/ca3041984cf3665e27b6783c923ab1c32682500a#diff-b1e19192258d83199d8adaa5ac31f067af98f63554bfdd679bd8e8073815e69dR1669) would call `StartErrorShutdown`?

💬 MarcoFalke commented on pull request "ci: Add missing set -e to 01_base_install.sh":
(https://github.com/bitcoin/bitcoin/pull/27739#issuecomment-1564529747)
Thanks, the last commit should fix your bug.

I wonder if env's like USER(NAME) and PATH should also be excluded, but this can be done later?

💬 furszy commented on pull request "Return EXIT_FAILURE on post-init fatal errors":
(https://github.com/bitcoin/bitcoin/pull/27708#discussion_r1206928091)
Yeah [here](https://github.com/bitcoin/bitcoin/commit/bc2315d86f13e6e15f681ecaf5efc9b33e6128a3#diff-b1e19192258d83199d8adaa5ac31f067af98f63554bfdd679bd8e8073815e69dR1675), I just rebased #27607 on top of this one.

Np on using `AbortNode` there. Just would need to bubble up the indexes error so it can be provided to `AbortNode`.

👍 instagibbs approved a pull request: "p2p: Log addresses of stalling peers"
(https://github.com/bitcoin/bitcoin/pull/27761#pullrequestreview-1446443265)
utACK fb02a3cd1a105bdf60ca39e1858e77685be88976

💬 instagibbs commented on issue "Frequent "Timeout downloading block" with 24.1":
(https://github.com/bitcoin/bitcoin/issues/27705#issuecomment-1564537951)
> Which on this particular node is ~1GB of logs per 2-3 hours.

Another annoying way to find it is detect when node is stalled, then do `getpeerinfo` and see who has a block "inflight", then ban them.

That said, this should not happen regularly post #27626

💬 MarcoFalke commented on pull request "fuzz: Change LIMIT_TO_MESSAGE_TYPE from a compile-time to a run-time setting":
(https://github.com/bitcoin/bitcoin/pull/27766#discussion_r1206947004)
thx, done

💬 furszy commented on pull request "wallet: improve IBD sync time by skipping block scanning prior birth time":
(https://github.com/bitcoin/bitcoin/pull/27469#discussion_r1206948915)
It's merely about consistency and readability.

The explicit `load` call tells the reader that this is an atomic variable, which could prevent some issues. E.g.
```c++
if (block.chain_time_max < m_birth_time - (TIMESTAMP_WINDOW * 2)) return;
else (m_birth_time > something_esle) // do something else..
```
Here there are two atomic reads performed. And the `m_birth_time` could have changed in-between them.

⚠️ joostjager opened an issue: "Allow accepting non-standard transactions on mainnet via local rpc"
(https://github.com/bitcoin/bitcoin/issues/27768)
### Please describe the feature you'd like to see added.

To mitigate mempool divergence between nodes and miners, node operators should have the ability to submit non-standard transactions to their local mempools. One of the reasons to do so is to improve the quality of fee estimates.

Acceptance via the p2p network has been discussed in https://github.com/bitcoin/bitcoin/pull/27578 and is deemed to be problematic. This issue is for enabling non-standard transaction submission for the `sendra
...

👍 dergoegge approved a pull request: "fuzz: Change LIMIT_TO_MESSAGE_TYPE from a compile-time to a run-time setting"
(https://github.com/bitcoin/bitcoin/pull/27766#pullrequestreview-1446480815)
ACK 1111c9ac97ca0f0afeb5df45bc0970b761c3c9ff