💬 maflcko commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162949886)
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.

💬 pinheadmz commented on issue "Add bitcoind and bitcoin-cli to macOS release":
(https://github.com/bitcoin/bitcoin/issues/30262#issuecomment-2162955737)
@emc99 bitcoin development is complicated and busy with hundreds of people focused on different things in harmony. This issue is about macos releases. Your comment is about data usage and therefore does not belong here, in a thread where developers are discussing releases. Sipa has directed you very precisely to the best place to raise your concerns about data usage. If you have any more comments about macOS releases you are in the right place for an organized work as a team.

Further off top
...

💬 sipa commented on issue "Enable `importprivkey`, `addmultisigaddress` in descriptor wallets":
(https://github.com/bitcoin/bitcoin/issues/30175#issuecomment-2162981138)
@achow101 Hmm, what would happen if `addmultisigaddress` for descriptor wallets just imports the computed descriptor as it does now (with RPC arguments that must be existing addresses or hex pubkeys)? Would it support (participating in) signing for the resulting multisig address (assuming signing for one of specified addresses/pubkeys was possible prior to the RPC call)? Would `listdescriptors true` reveal the corresponding private key?

Agreed about `importmulti`. It's nontrivial to map to de
...

💬 m3dwards commented on pull request "ci: move ASan job to GitHub Actions from Cirrus CI":
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636456192)
Done

💬 m3dwards commented on pull request "ci: move ASan job to GitHub Actions from Cirrus CI":
(https://github.com/bitcoin/bitcoin/pull/30193#discussion_r1636456663)
No strong feelings, switched it back to sed approach.

💬 willcl-ark commented on pull request "rename TransactionErrors: MISSING_INPUTS and ALREADY_IN_CHAIN":
(https://github.com/bitcoin/bitcoin/pull/30212#discussion_r1636456867)
I did consider this, but it felt much less exposed to the user, only via `testmempoolaccept` AFAIK:

```cpp
result_inner.pushKV("reject-reason", "missing-inputs");
```

Therefore as an "internal error", `TX_MISSING_INPUTS` (for any reason) it felt more accurate to me to leave as is? Very happy to be persuaded away from this viewpoint though :)

💬 maflcko commented on issue "Enable `importprivkey`, `addmultisigaddress` in descriptor wallets":
(https://github.com/bitcoin/bitcoin/issues/30175#issuecomment-2163011779)
I think the issue remains that the rescan argument is boolean and optional in `importaddress`, which IIRC was one of the reasons to move toward `importdescriptors`. Yes, the `importdescriptors` interface is non-trivial, but I don't see how the burden can be taken off the user to think about the rescan timestamp of the descriptor. It needs to be accurate, because if it is too late, funds/txs may be missed, if it is too early, hours/days may be spent on a rescan.

If this is done, I'd say that `
...

💬 maflcko commented on pull request "fuzz: Use std::span in FuzzBufferType":
(https://github.com/bitcoin/bitcoin/pull/30229#issuecomment-2163013314)
Thanks for spotting the silent merge conflict. Rebased.

📝 fanquake opened a pull request: "Update minisketch subtree to eb37a9b8e79f9e49d73b96a49bf97a96d9eb676c"
(https://github.com/bitcoin/bitcoin/pull/30270)
Includes https://github.com/sipa/minisketch/pull/87 which is used in https://github.com/bitcoin/bitcoin/pull/30234.
Includes https://github.com/sipa/minisketch/pull/88 which is used in https://github.com/bitcoin/bitcoin/pull/29876.

💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1636499615)
taken

💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1636499712)
defined it inline

💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1636499798)
Added delving link but for Future Work I'm wondering longer term where cluster mempool design stuff should live.

💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1636499902)
squashed and lightly re-ordered

💬 marcofleon commented on pull request "i2p: fix and improve logs":
(https://github.com/bitcoin/bitcoin/pull/29833#discussion_r1636502596)
Should this not be `*m_interrupt`?

👍 theuni approved a pull request: "Update minisketch subtree to eb37a9b8e79f9e49d73b96a49bf97a96d9eb676c"
(https://github.com/bitcoin/bitcoin/pull/30270#pullrequestreview-2113093414)
utACK 89464ad59cf11f68315ea3104236989e5b429d15

💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#issuecomment-2163071996)
Added a release note

📝 maflcko opened a pull request: "doc: Mention EOL policy in release notes template"
(https://github.com/bitcoin/bitcoin/pull/30271)
Currently the release notes template does not link to the EOL policy. Not sure if anyone still isn't aware of it, but I guess it can't hurt to link to it from the release notes.

💬 ryanofsky commented on pull request "p2p: For assumeutxo, download snapshot chain before background chain":
(https://github.com/bitcoin/bitcoin/pull/29519#discussion_r1636522532)
re: https://github.com/bitcoin/bitcoin/pull/29519#discussion_r1635456871

Good points. My suggested change was premised on the false assumption that the node would be able to seamlessly reorg to the most-work chain. But that's not true because of missing undo data.

Your philosophical point is interesting. I believe that:

- Loading snapshots should not affect how nodes come to consensus, it should only affect what order they download blocks, and help them compute the latest UTXO sets soon
...

📝 glozow opened a pull request: "doc: use TRUC instead of v3 and add release note"
(https://github.com/bitcoin/bitcoin/pull/30272)
Draft because this will conflict with #28984. Will mark green after that is merged.

Adds a release note for TRUC policy which will be live in v28.0.

Also, for clarity, replaces mentions of "v3" with "TRUC" in most places. I changed error strings from "v3-violation" to "TRUC-violation" but left v3 in the debug strings because I think it might be clearer for somebody who is debugging. Similarly, I left some variables unchanged because I think they're more descriptive this way, e.g. `tx_v3_fr
...

📝 vasild opened a pull request: "fuzz: FuzzedSock::Recv() don't lose bytes from MSG_PEEK read"
(https://github.com/bitcoin/bitcoin/pull/30273)
Problem:

If `FuzzedSock::Recv(N, MSG_PEEK)` is called then `N` bytes would be
retrieved from the fuzz provider, saved in `m_peek_data` and returned
to the caller (ok).

If after this `FuzzedSock::Recv(M, 0)` is called where `M < N`
then the first `M` b
...