💬 fanquake commented on pull request "refactor: Remove Span operator==, Use std::ranges::equal":
(https://github.com/bitcoin/bitcoin/pull/29071#issuecomment-1864170372)
> Does anyone know what version(s) of clang can be expected to be available on macOS normally?

GIven our minimum supported macOS (11.x), you could run anything from Xcode 12.5+ onwards, which is roughly LLVM/Clang 12+. Although I'd expect most users compiling from source on macOS, would be using a much more recent Xcode, so likely Clang ~14+ at least.

Also, anyone should be able to install and run the latest LLVM/Clang via brew.

💬 VojtechMyslivec commented on issue "gettransaction details does not include send to myself balance changes for imported addresses":
(https://github.com/bitcoin/bitcoin/issues/28555#issuecomment-1864179337)
Is there anything more I can provide to investigate this problem?

I would label this with ~bug, ~descriptors and ~wallet

Thanks

💬 ismaelsadeeq commented on pull request "RPC: Add maxfeerate and maxburnamount args to submitpackage":
(https://github.com/bitcoin/bitcoin/pull/28950#issuecomment-1864179391)
Concept ACK

💬 maflcko commented on pull request "[WIP] C++20 std::views::reverse":
(https://github.com/bitcoin/bitcoin/pull/28687#issuecomment-1864192035)
Though, on GHA it says XCode 14.3, see https://github.com/bitcoin/bitcoin/actions/runs/7171999335/job/19528203033?pr=28687#step:3:14

```
clang --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode_14.3.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

💬 fanquake commented on pull request "[WIP] C++20 std::views::reverse":
(https://github.com/bitcoin/bitcoin/pull/28687#issuecomment-1864200442)
> Though, on GHA it says XCode 14.3

According to https://developer.apple.com/xcode/cpp/#c++20, "Ranges" have been available on macOS since Xcode 14.3.

💬 fanquake commented on pull request "build: Bump guix time-machine to unlock riscv64 metal":
(https://github.com/bitcoin/bitcoin/pull/29078#issuecomment-1864204382)
> Looks like this fails with:

Given that the problem here is compiling cctools on RISC-V, I think this will ultimately be solved by switching to LLVM/LLD (#21778).

💬 maflcko commented on pull request "logging: Simplify API for level based logging":
(https://github.com/bitcoin/bitcoin/pull/28318#issuecomment-1864250140)
re-ACK e60fc7d5d34f23cccbff6e4f5f3d716fa8dad50c 🌚

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: re-ACK e60fc7d5d34f23cccbff
...

⚠️ ManuelSchneid3r opened an issue: "Weird focus rect displayed on inital sync"
(https://github.com/bitcoin-core/gui/issues/783)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

<img width="891" alt="Bildschirmfoto 2023-12-20 um 11 41 09" src="https://github.com/bitcoin-core/gui/assets/3252315/74c17ab2-460d-4eba-8151-3f19c35b71a7">


### Expected behaviour

<img width="866" alt="Bildschirmfoto 2023-12-20 um 11 43 55" src="https://github.com/bitcoin-core/gui/assets/3252315/7748c491-e0be-4f34-bb4e-c6e39f7c1244">


### Steps to reproduce

Start Bitcoin-Qt

### Rele
...

💬 ManuelSchneid3r commented on issue "Weird focus rect displayed on inital sync":
(https://github.com/bitcoin-core/gui/issues/783#issuecomment-1864257245)
Just updated to 26. still there.

🚀 glozow merged a pull request: "[doc]: add doxygen comment describing what `CheckPackageLimits` returns"
(https://github.com/bitcoin/bitcoin/pull/29115)

✅ maflcko closed an issue: "bitcoind ubuntu generating fake addresses ?"
(https://github.com/bitcoin/bitcoin/issues/29116)

💬 maflcko commented on issue "bitcoind ubuntu generating fake addresses ?":
(https://github.com/bitcoin/bitcoin/issues/29116#issuecomment-1864265280)
Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base.

General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat, or one of the Bitcoin subreddits, or any other place that you feel is well suited.

💬 glozow commented on pull request "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/28885#discussion_r1432569676)
That's fine for lines that you're adding or already changing (which iiuc is what jonatack was suggesting as well). To make review easier, I wouldn't recommend reformatting other lines, as it crowds the diff.

💬 fanquake commented on pull request "build: switch to using LLVM 17.x for macOS builds":
(https://github.com/bitcoin/bitcoin/pull/28880#issuecomment-1864277320)
Added more patching to Qt. There is one issue left to fixup:
```bash
_void std::__1::__buffered_inplace_merge[abi:v160006]<std::__1::_ClassicAlgPolicy, bool (*&)(QPersistentModelIndex const&, QPersistentModelIndex const&), QPersistentModelIndex*>(QPersistentModelIndex*, QPersistentModelIndex*, QPersistentModelIndex*, bool (*&)(QPersistentModelIndex const&, QPersistentModelIndex const&), std::__1::iterator_traits<QPersistentModelIndex*>::difference_type, std::__1::iterator_traits<QPersistentMod
...

💬 glozow commented on pull request "Policy: Report reason inputs are non standard":
(https://github.com/bitcoin/bitcoin/pull/29060#discussion_r1432576558)
Maybe just use `TxValidationState`?

✅ glozow closed a pull request: "rpc: Add options argument to listtransactions, with paginatebypointer options"
(https://github.com/bitcoin/bitcoin/pull/19443)

💬 glozow commented on pull request "rpc: Add options argument to listtransactions, with paginatebypointer options":
(https://github.com/bitcoin/bitcoin/pull/19443#issuecomment-1864299069)
Closing due to lack of activity. Feel free to ping if this is picked up again.

💬 glozow commented on pull request "RPC: Add universal options argument to listtransactions":
(https://github.com/bitcoin/bitcoin/pull/22807#issuecomment-1864300507)
Are you still working on this?

💬 c0deright commented on issue "Old wallet.dat: Error reading wallet database: keymeta found with unexpected path / All keys read correctly, but transaction data or address metadata may be missing or incorrect":
(https://github.com/bitcoin/bitcoin/issues/29109#issuecomment-1864352916)
I used https://github.com/dan-da/hd-wallet-derive to derive

* 301 keys in path `m/0'/0'/0'` to `m/0'/0'/300'`
* 301 keys in path `m/0'/1'/0'` to `m/0'/1'/300'`

from the **xprv** like so:
```
php hd-wallet-derive.php -g --cols=path,privkey --key=xprv... --path="m/0'/0'/x'" --numderive 301 > xprv-0.txt
php hd-wallet-derive.php -g --cols=path,privkey --key=xprv... --path="m/0'/1'/x'" --numderive 301 > xprv-1.txt
```

Then I took all the private keys from the `walletdump` output and gre
...

🤔 glozow reviewed a pull request: "RPC: Add maxfeerate and maxburnamount args to submitpackage"
(https://github.com/bitcoin/bitcoin/pull/28950#pullrequestreview-1790751210)
Concept ACK

My ideal approach would be to not check client-side stuff inside validation, e.g. by adding a helper that loads coins (probably not extensible to chunk feerate but could maybe be a sufficient sanity check), or a test package accept + real submit (like the way `BroadcastTransaction` does it). But if it's unavoidable, then this seems fine. AFAICT it's extensible to checking chunk feerate in the future.