💬 fanquake commented on pull request "wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction":
(https://github.com/bitcoin/bitcoin/pull/25273#issuecomment-1846934788)
@josibake @furszy want to take another look here.
(https://github.com/bitcoin/bitcoin/pull/25273#issuecomment-1846934788)
@josibake @furszy want to take another look here.
💬 maflcko commented on pull request "test: doc: follow-up #28368":
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420254059)
Is there an easy way to catch those somehow in CI?
(https://github.com/bitcoin/bitcoin/pull/29013#discussion_r1420254059)
Is there an easy way to catch those somehow in CI?
✅ fanquake closed an issue: "Release schedule for 26.0"
(https://github.com/bitcoin/bitcoin/issues/27758)
(https://github.com/bitcoin/bitcoin/issues/27758)
💬 fanquake commented on issue "Release schedule for 26.0":
(https://github.com/bitcoin/bitcoin/issues/27758#issuecomment-1846942032)
Closing this now, will open a new timeline for 27.0.
(https://github.com/bitcoin/bitcoin/issues/27758#issuecomment-1846942032)
Closing this now, will open a new timeline for 27.0.
⚠️ fanquake opened 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 🚧
- 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 🚧 :
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until
...
(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 🚧
- 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 🚧 :
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until
...
⚠️ fanquake pinned 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 🚧
- 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 🚧 :
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until
...
(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 🚧
- 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 🚧 :
- Feature freeze (bug fixes only until release)
- Translation string freeze (no more source language changes until
...
⚠️ 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 :heavy_check_mark:
- 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-08 :heavy_check_mark:
- Feature freeze (bug fixes only until release)
- Translation st
...
(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 :heavy_check_mark:
- 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-08 :heavy_check_mark:
- Feature freeze (bug fixes only until release)
- Translation st
...
💬 willcl-ark commented on pull request "[26.x] Backports":
(https://github.com/bitcoin/bitcoin/pull/29011#issuecomment-1846951568)
ACK 188e023d2fdab30b4a779a862b2c8b567bb15803
Checked diffs between Rebased-from commit hash and these commits themselves.
(https://github.com/bitcoin/bitcoin/pull/29011#issuecomment-1846951568)
ACK 188e023d2fdab30b4a779a862b2c8b567bb15803
Checked diffs between Rebased-from commit hash and these commits themselves.
🤔 vasild reviewed a pull request: "p2p: adaptive connections services flags"
(https://github.com/bitcoin/bitcoin/pull/28170#pullrequestreview-1769801940)
Concept ACK. I acknowledge this PR resolves the problem. But the situation is somewhat convoluted in `master` and I am not sure this PR makes it any better. There are multiple ways to determine if we are stale:
1. `ChainstateManager::IsInitialBlockDownload()`: uses `-maxtipage` (default 24h). Once it considers out of IBD, it stays like that regardless of the tip age (why? surely it is possible to lag behind again).
2. `g_initial_block_download_completed`
2.1. Set by `Chainstate::Activat
...
(https://github.com/bitcoin/bitcoin/pull/28170#pullrequestreview-1769801940)
Concept ACK. I acknowledge this PR resolves the problem. But the situation is somewhat convoluted in `master` and I am not sure this PR makes it any better. There are multiple ways to determine if we are stale:
1. `ChainstateManager::IsInitialBlockDownload()`: uses `-maxtipage` (default 24h). Once it considers out of IBD, it stays like that regardless of the tip age (why? surely it is possible to lag behind again).
2. `g_initial_block_download_completed`
2.1. Set by `Chainstate::Activat
...
💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1418747776)
nit:
```suggestion
* outbound connection slots or for us to wish to prioritize keeping
```
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1418747776)
nit:
```suggestion
* outbound connection slots or for us to wish to prioritize keeping
```
💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420215938)
Tying together the "extra block-relay-only peers" and the "desirable service flags" seems unnecessary and maybe even wrong, because the conditions should be different. Flipping back to `false` is needed for "desirable service flags", but not for "extra block-relay-only peers" because then this code will be executed more than once:
https://github.com/bitcoin/bitcoin/blob/1d9da8da309d1dbf9aef15eb8dc43b4a2dc3d309/src/net_processing.cpp#L5268-L5269
Which seems innocent, but is confusing and lo
...
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420215938)
Tying together the "extra block-relay-only peers" and the "desirable service flags" seems unnecessary and maybe even wrong, because the conditions should be different. Flipping back to `false` is needed for "desirable service flags", but not for "extra block-relay-only peers" because then this code will be executed more than once:
https://github.com/bitcoin/bitcoin/blob/1d9da8da309d1dbf9aef15eb8dc43b4a2dc3d309/src/net_processing.cpp#L5268-L5269
Which seems innocent, but is confusing and lo
...
💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420201385)
naming: "close to tip" is misleading because there is no "tip" involved here. Just the block time is compared to the current time. `IsBlockRecent()` would be better. Or maybe even `size_t BlockAge(const CBlockIndex& index) { return (GetAdjustedTime() - index.Time()) / consensus.PowTargetSpacing(); }`
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420201385)
naming: "close to tip" is misleading because there is no "tip" involved here. Just the block time is compared to the current time. `IsBlockRecent()` would be better. Or maybe even `size_t BlockAge(const CBlockIndex& index) { return (GetAdjustedTime() - index.Time()) / consensus.PowTargetSpacing(); }`
💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1418751438)
What is meant by "the version of the peer" here?
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1418751438)
What is meant by "the version of the peer" here?
💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420254312)
I find it confusing to have one condition to set the flag to `true` and a different condition to set it to `false`. I mean this:
```cpp
if (A) flag = true;
if (B) flag = false;
```
because, for example, it may happen that `B` is `true` and the flag is `true` (if the first `if` was not executed yet).
In this case it can be simpler:
```cpp
if (C) flag = true;
if (!C) flag = false;
// or just:
flag = C;
```
and C should be just "our highest block is older than 48h" (regardless of w
...
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420254312)
I find it confusing to have one condition to set the flag to `true` and a different condition to set it to `false`. I mean this:
```cpp
if (A) flag = true;
if (B) flag = false;
```
because, for example, it may happen that `B` is `true` and the flag is `true` (if the first `if` was not executed yet).
In this case it can be simpler:
```cpp
if (C) flag = true;
if (!C) flag = false;
// or just:
flag = C;
```
and C should be just "our highest block is older than 48h" (regardless of w
...
💬 vasild commented on pull request "p2p: adaptive connections services flags":
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420242098)
Seems like `!fInitialDownload && ` can be removed? If `IsBlockCloseToTip()` is `true` then that block is 3h20min or younger. In this case `fInitialDownload` will always be `false` because it uses 24h, right?
(https://github.com/bitcoin/bitcoin/pull/28170#discussion_r1420242098)
Seems like `!fInitialDownload && ` can be removed? If `IsBlockCloseToTip()` is `true` then that block is 3h20min or younger. In this case `fInitialDownload` will always be `false` because it uses 24h, right?
💬 fanquake commented on pull request "fuzz: p2p: Detect peer deadlocks":
(https://github.com/bitcoin/bitcoin/pull/29009#issuecomment-1846978003)
cc also @mzumsande @sipa
(https://github.com/bitcoin/bitcoin/pull/29009#issuecomment-1846978003)
cc also @mzumsande @sipa
👍 fanquake approved a pull request: "build: Require C++20 compiler"
(https://github.com/bitcoin/bitcoin/pull/28349#pullrequestreview-1772145687)
ACK fa6e50d6c79633e22ad4cfc75f56aaa40112ecbb
(https://github.com/bitcoin/bitcoin/pull/28349#pullrequestreview-1772145687)
ACK fa6e50d6c79633e22ad4cfc75f56aaa40112ecbb
🚀 fanquake merged a pull request: "wallet: batch all individual spkms setup db writes in a single db txn"
(https://github.com/bitcoin/bitcoin/pull/28894)
(https://github.com/bitcoin/bitcoin/pull/28894)
🚀 fanquake merged a pull request: "test: Extends MEMPOOL msg functional test"
(https://github.com/bitcoin/bitcoin/pull/28485)
(https://github.com/bitcoin/bitcoin/pull/28485)
🚀 fanquake merged a pull request: "test: fix v2 transport intermittent test failure (#29002)"
(https://github.com/bitcoin/bitcoin/pull/29006)
(https://github.com/bitcoin/bitcoin/pull/29006)