👋 pablomartin4btc's pull request is ready for review: "script, assumeutxo: Enhance validations in utxo_snapshot.sh"
(https://github.com/bitcoin/bitcoin/pull/28852)

💬 fanquake commented on pull request "build: use macOS 14 SDK (Xcode 15.0)":
(https://github.com/bitcoin/bitcoin/pull/28622#issuecomment-1806868093)
Looks like we'll have to add a `-Wl,-platform_version` into ldflags here.

💬 hebasto commented on pull request "build: Patch Qt to handle minimum macOS version properly":
(https://github.com/bitcoin/bitcoin/pull/28851#issuecomment-1806877028)
My Guix builds:
```
x86_64
ad9dbeabb7fca2c4efa4057b3aee139c4325b6f5fb77c1ee10fe18940491b446 guix-build-05aca093819b/output/aarch64-linux-gnu/SHA256SUMS.part
afddca8689f4d21a08e448dd59ad4fa5329437f4042dd0d1cfc2d2cdc7d59b5f guix-build-05aca093819b/output/aarch64-linux-gnu/bitcoin-05aca093819b-aarch64-linux-gnu-debug.tar.gz
9ea86d3294960c4c442f30259d3c1b17a105902b22d20f874cabeb01bd6bf995 guix-build-05aca093819b/output/aarch64-linux-gnu/bitcoin-05aca093819b-aarch64-linux-gnu.tar.gz
ee100a86
...

💬 lasermind commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806880832)
Ok, now this is exactly what I'm talking about: **on average** a new block is mined every 10 minutes. This is the fundamental assumption, isn't it? So it does not make much sense to arbitrarily decrease this "guessed value" **earlier** than 10 minutes.

At least for the first 10 minutes, it could stay at `100.0000%`.

That's basically all I'm saying here.

💬 sipa commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1806882339)
63% of blocks take less than 10 minutes, and the shorter the interval, the more likely it is (39% takes less than 5 minutes, for example, and 9% takes less than 1 minute). There is nothing special about the value 10 minutes except that's the average internal when averaged over many blocks.

💬 hebasto commented on pull request "contrib: drop GCC MAX_VERSION to 4.3.0 in symbol-check":
(https://github.com/bitcoin/bitcoin/pull/28844#issuecomment-1806900255)
> Reflect the actual symbols used, i.e:
>
> ```shell
> bitcoind: symbol __bswapsi2 from unsupported version GCC_4.3.0(7)
> ```

Is it happening for Guix builds?

💬 fanquake commented on pull request "contrib: drop GCC MAX_VERSION to 4.3.0 in symbol-check":
(https://github.com/bitcoin/bitcoin/pull/28844#issuecomment-1806900818)
> Is it happening for Guix builds?

Yes.

⚠️ solidearthlabs opened an issue: "configure error: cannot find input file: `Makefile.in'"
(https://github.com/bitcoin/bitcoin/issues/28853)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

When I run:
`/configure --with-incompatible-bdb`

I get the following error message:
```
configure: creating ./config.status
config.status: creating libbitcoinconsensus.pc
config.status: error: cannot find input file: `Makefile.in'

```

I've tried with v22.0, v25.1 and the latest master.

### Expected behaviour

Should finish without error

### Steps to reproduce

./configure -
...

💬 solidearthlabs commented on issue "configure error: cannot find input file: `Makefile.in'":
(https://github.com/bitcoin/bitcoin/issues/28853#issuecomment-1806913513)
When I copy the src/Makefile.in into the repository head directory it gets past this step

💬 solidearthlabs commented on issue "configure error: cannot find input file: `Makefile.in'":
(https://github.com/bitcoin/bitcoin/issues/28853#issuecomment-1806915092)
After rerunning `./autogen.sh` I no longer get this issue when running configure

✅ solidearthlabs closed an issue: "configure error: cannot find input file: `Makefile.in'"
(https://github.com/bitcoin/bitcoin/issues/28853)

💬 ajtowns commented on pull request "[refactor] Remove BlockAssembler m_mempool member":
(https://github.com/bitcoin/bitcoin/pull/28843#discussion_r1390312985)
I could see that being an argument for doing away with `BlockAssembler` entirely (at least as a public interface), and replacing `BlockAssembler(chainstate, mempool, options).CreateNewBlock(scriptPubKeyIn)` it with a function: `CreateNewBlock(chainstate, mempool, scriptPubKeyIn, options)` (effectively reverting #7598).

But if you're keeping `BlockAssembler` around, the entire point of that class is to assemble a block with txs from the mempool -- that's why most of its private functions requi
...

💬 ishaanam commented on issue "wallet coin selection: don't mixup coins with absolute timelocks of different types":
(https://github.com/bitcoin/bitcoin/issues/27526#issuecomment-1806999303)
I have started working on fixing this issue and have a solution that seems like it works. I should have a draft PR open soon. The solution involves using `TreeEval` to determine the time locks of a given script, and making sure that coins with absolute timelocks of different types are not mixed using `CoinEligibilityFilter`s.

💬 Mikey4010 commented on issue "Running out of disk space can leave bitcoin in a desynced state":
(https://github.com/bitcoin/bitcoin/issues/26112#issuecomment-1807096155)
61a6c3b0e9a8dab5c5f845af4becde817539133c

📝 hebasto opened a pull request: "depends: Build `capnp` with CMake"
(https://github.com/bitcoin/bitcoin/pull/28856)
This change fixes the `x86_64-w64-mingw32` build (see https://github.com/bitcoin/bitcoin/pull/28735#issuecomment-1790406668) and simplifies the configuration file.

💬 hebasto commented on pull request "depends: Build `capnp` with CMake":
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1807103137)
cc @ryanofsky

💬 maflcko commented on issue "Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`":
(https://github.com/bitcoin/bitcoin/issues/28847#issuecomment-1807115357)
Maybe it could be split into two fields? One with "header progress", which is equal to the number returned here (including presumed existing, but unknown headers), and another one "verification progress", which reflects the blocks fully verified up to all known headers (excluding the presumed existing, but unknown headers)?

🤔 S3RK reviewed a pull request: "wallet: Have the wallet store the key for automatically generated descriptors"
(https://github.com/bitcoin/bitcoin/pull/26728#pullrequestreview-1717079324)
re-review up to the migration commit 18dc28f14ee1de561625913d286d68031ab9b3dd

Left some small nits and suggestion.

Should we spend a bit more time discussing the public API? I.e. what to name `getxpub` method and how we would like to evolve in the future?

Will continue to re-review with the rest of commits soon.

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1384538002)
in 8a2475573270b7bc0a7d99cd94d9908cd48bd6bd

nit: The code would be easier to understand if we drop template and just use `const CPubKey&`, it's trivial to get the right type on the caller side.

💬 S3RK commented on pull request "wallet: Have the wallet store the key for automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/26728#discussion_r1390405493)
Checking my understanding. This assume verifies that we loaded the key we want to set as active. Correct?