✅ gianlucamazza closed an issue: "bitcoin core crashes and restarts syncing from beginning "
(https://github.com/bitcoin/bitcoin/issues/28795)

💬 fanquake commented on pull request "build: use macOS 14 SDK (Xcode 15.0)":
(https://github.com/bitcoin/bitcoin/pull/28622#issuecomment-1838758831)
Should be fixed now. Forgot that, we neeed to revert to including basically the entire SDK here, to accomodate Qt.

⚠️ hebasto opened an issue: "`capnp` fails when cross-compiling"
(https://github.com/bitcoin/bitcoin/issues/28993)
On the master branch @ 160d23677ad799cf9b493eaa923b2ac080c3fb8e, the `native/bin/capnp` fails when cross-compiling with `MULTIPROCESS=1`:
```
GEN /home/hebasto/git/bitcoin/depends/x86_64-pc-linux-gnu/include/mp/proxy.capnp.h
/home/hebasto/git/bitcoin/depends/x86_64-pc-linux-gnu/include/mp/proxy.capnp: File is not in the current directory and does not match any prefix defined with --src-prefix. Please pass an appropriate --src-prefix so I can figure out where to write the output for thi
...

💬 hebasto commented on issue "`capnp` fails when cross-compiling":
(https://github.com/bitcoin/bitcoin/issues/28993#issuecomment-1838761432)
cc @ryanofsky

👋 hebasto's pull request is ready for review: "depends: Build the `native_capnp` and `capnp` packages with CMake"
(https://github.com/bitcoin/bitcoin/pull/28856)

💬 hebasto commented on pull request "depends: Build the `native_capnp` and `capnp` packages with CMake":
(https://github.com/bitcoin/bitcoin/pull/28856#discussion_r1414020173)
While this change is an improvement, I've dropped it in the recent push as it does not related to this PR changes.

💬 hebasto commented on pull request "depends: Build the `native_capnp` and `capnp` packages with CMake":
(https://github.com/bitcoin/bitcoin/pull/28856#issuecomment-1838817927)
Rebased to include recent changes in the depends build system.

The PR description has been updated to mention one more fixed bug.

💬 adjmx commented on issue "macos: dmg not working on macOS Sonoma (14.x)":
(https://github.com/bitcoin/bitcoin/issues/28767#issuecomment-1838834600)
I just did manual install of `v26.0rc1` on M1 [Sonama 14.1.2]
The following commands produced the Bitcoin-QT.app file no problems.
I forgot the command for deploying .dmg

install dependencies
./autogen.sh
make -j 4
make deploy

💬 fanquake commented on pull request "build: use macOS 14 SDK (Xcode 15.0)":
(https://github.com/bitcoin/bitcoin/pull/28622#issuecomment-1838837355)
`4daaed2ef2253c9661779fa40bfff50655dc7ec45801aba5a39653e7bcdde48e Xcode_15.xip`.
`c0c2e7bb92c1fee0c4e9f3a485e4530786732d6c6dd9e9f418c282aa6892f55d Xcode-15.0-15A240d-extracted-SDK-with-libcxx-headers.tar.gz`.

✅ hebasto closed an issue: "macos: dmg not working on macOS Sonoma (14.x)"
(https://github.com/bitcoin/bitcoin/issues/28767)

💬 hebasto commented on issue "macos: dmg not working on macOS Sonoma (14.x)":
(https://github.com/bitcoin/bitcoin/issues/28767#issuecomment-1838840548)
Closing for now. Feel free to reopen if relevant.

💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1838855510)
> I don’t know about automatically flushing out <= 0 fees even when the local mempool is empty. One could add significant computing payload on its mining competitors by throwing buffy packages with 0 fees parent and then replace the high-fee child (in a cycle).

The replacements are paying for those CPU cycles and bandwidth via "incremental feerate", it's equivalent to an entire package simply being RBF'd like normal. Keeping 0-fee parents hanging around in mempool would also allow new entrie
...

🤔 sr-gi reviewed a pull request: "p2p: Fill reconciliation sets (Erlay)"
(https://github.com/bitcoin/bitcoin/pull/28765#pullrequestreview-1762709866)
ACK [f895ae4](https://github.com/bitcoin/bitcoin/pull/28765/commits/f895ae4b7aa7263acba1adb3886c47a36f40b024)

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay)":
(https://github.com/bitcoin/bitcoin/pull/28765#discussion_r1414062310)
nit: if you have created a refactor commit to deal with removing the TODOs, it may be worth moving that change there.

Not sure if you're planning to squash it or not. Feel free to disregard.

💬 hebasto commented on pull request "depends: Include `config.guess` and `config.sub` into `meta_depends`":
(https://github.com/bitcoin/bitcoin/pull/28870#issuecomment-1838878294)
cc @fanquake

📝 furszy opened a pull request: "wallet: skip BnB when SFFO is enabled"
(https://github.com/bitcoin/bitcoin/pull/28994)
Solves #28918. Coming from https://github.com/bitcoin/bitcoin/issues/28918#issuecomment-1838626406 discussion.

The intention is to decouple only the bugfix relevant commits from #28985, allowing them to be included in the 26.x release. This way, we can avoid disabling the coin selection fuzzing test for an entire release.

Note:
Have introduced few changes to the bug fix commit so that the unit tests pass without the additional burden introduced in #28985.

💬 Ayush170-Future commented on pull request "fuzz: wallet, add target for Spend":
(https://github.com/bitcoin/bitcoin/pull/28236#discussion_r1414077590)
Yes, I believe the `LockCoin` function does mutate the global `wallet`. I'll need to figure out how to make this deterministic then.

I apologize for the delayed response, I was/am occupied with something else. But, I'm looking forward to brainstorming this and finding a solution as soon as possible.

💬 Ayush170-Future commented on pull request "fuzz: wallet, add target for Spend":
(https://github.com/bitcoin/bitcoin/pull/28236#discussion_r1414079147)
Thank you! I'll rebase in the next force push.

💬 maflcko commented on pull request "wallet: skip BnB when SFFO is enabled":
(https://github.com/bitcoin/bitcoin/pull/28994#discussion_r1414083527)
Is this used? What would this be used for? Seems easier to use a bool, no?

💬 fanquake commented on pull request "wallet: skip BnB when SFFO is enabled":
(https://github.com/bitcoin/bitcoin/pull/28994#discussion_r1414086098)
In d62d49c605f89a325b929e8fb48091b0b56399ee: is there really no other way to know which coin selection algorithm is being used, than to grep output logs for non-existence? This doesn't seem like the best way to test for a condition.