💬 Sjors commented on pull request "[WIP] Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#issuecomment-1952644105)
In the context of Stratum v2 #29432 I'm looking for a more efficient way to decide when to generate a new block template.

The current implementation looks at the mempool's `GetTransactionsUpdated()` every `-sv2interval` seconds. If there was any update, it calls `CreateNewBlock()` on `BlockAssembler`. It then checks if fees increased by at least `-sv2feedelta` since the last template and if so, pushes it to connected clients.

`GetTransactionsUpdated()` changes all the time, especially with
...

💬 sipa commented on pull request "[WIP] Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#issuecomment-1952653016)
> Would it be easy to keep track of that (approximate) number every time something is added or removed from the mempool?

After clustermempool, yes. Today doing that inherently requires running the mining algorithm to figure out what transactions to put there.

💬 Sjors commented on pull request "[WIP] Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#issuecomment-1952657689)
Indeed, I meant on top of this PR (or a later incarnation).

💬 hebasto commented on pull request "ci: Avoid CI failures from temp env file reuse":
(https://github.com/bitcoin/bitcoin/pull/29441#discussion_r1494723144)
This comment got outdated, no?

🚀 fanquake merged a pull request: "[26.1] final changes for 26.1rc1"
(https://github.com/bitcoin/bitcoin/pull/29440)

💬 gdiscord commented on issue "Guix build script incorrectly reporting there is no Mac SDK":
(https://github.com/bitcoin/bitcoin/issues/29449#issuecomment-1952703183)
sure, will oblige.

📝 fanquake opened a pull request: "doc: document that BIP324 on by default for v27.0"
(https://github.com/bitcoin/bitcoin/pull/29452)
Addresses: https://github.com/bitcoin/bitcoin/pull/29347#issuecomment-1952335331.

💬 maflcko commented on pull request "ci: Avoid CI failures from temp env file reuse":
(https://github.com/bitcoin/bitcoin/pull/29441#discussion_r1494748529)
`git` is still installed unconditionally, otherwise, it wouldn't be present, no?

Might replace "install" with "require" if I re-touch, or in a follow-up?

👍 hebasto approved a pull request: "ci: Avoid CI failures from temp env file reuse"
(https://github.com/bitcoin/bitcoin/pull/29441#pullrequestreview-1888734489)
ACK fa91bf2559d2e839592bf1dc1d423d5fb1c3573e.

💬 maflcko commented on pull request "doc: document that BIP324 on by default for v27.0":
(https://github.com/bitcoin/bitcoin/pull/29452#issuecomment-1952731929)
lgtm ACK 0d3e18bcd6639d0752a15078d2ba76fbaaa94417

👍 theStack approved a pull request: "doc: document that BIP324 on by default for v27.0"
(https://github.com/bitcoin/bitcoin/pull/29452#pullrequestreview-1888744127)
ACK 0d3e18bcd6639d0752a15078d2ba76fbaaa94417

💬 sipa commented on pull request "doc: document that BIP324 on by default for v27.0":
(https://github.com/bitcoin/bitcoin/pull/29452#issuecomment-1952747820)
ACK 0d3e18bcd6639d0752a15078d2ba76fbaaa94417

💬 hebasto commented on pull request "RFC: build: remove confusing and inconsistent disable-asm option":
(https://github.com/bitcoin/bitcoin/pull/29407#issuecomment-1952767863)
> Our docs (developer-notes.md and fuzzing.md) mention the use of `--disable-asm` to avoid address sanitizer failures.

In the libsecp repo, the `--with-asm=no` option is still required to avoid MSan warnings. If this is a common issue for builtin assembly code, it seems possible that the `sha256_sse4.cpp` might cause similar issues in the future without an option to disable it.

Maybe gate the `sha256_sse4::Transform` function with `#if !defined(DISABLE_OPTIMIZED_SHA256)`?

🚀 glozow merged a pull request: "doc: document that BIP324 on by default for v27.0"
(https://github.com/bitcoin/bitcoin/pull/29452)

🤔 josibake reviewed a pull request: "wallet: cache IsMine scriptPubKeys to improve performance of descriptor wallets"
(https://github.com/bitcoin/bitcoin/pull/26008#pullrequestreview-1888853780)
ACK https://github.com/bitcoin/bitcoin/pull/26008/commits/e041ed9b755468d205ed48b29f6c4b9e9df8bc9f

Reviewed diff, looks good!

💬 josibake commented on pull request "Silent Payments: Implement BIP352":
(https://github.com/bitcoin/bitcoin/pull/28122#issuecomment-1952864224)
I've updated this to use https://github.com/bitcoin-core/secp256k1/pull/1471 for the cryptography needed for silent payments. This way, we don't need make any changes to `CKey`/`CPubKey` and keeps all of the low-level cryptography in `libsecp256k1`. This simplifies this PR to creating the necessary wrappers for the libsecp silent payments module and implementing the non-cryptography parts of the protocol (i.e. the client code).

Putting this PR in draft for now, until https://github.com/bitcoi
...

✅ ariard closed a pull request: "Add issuer-selected opt-in txn / pckg policy checks"
(https://github.com/bitcoin/bitcoin/pull/29448)

💬 ariard commented on pull request "Add issuer-selected opt-in txn / pckg policy checks":
(https://github.com/bitcoin/bitcoin/pull/29448#issuecomment-1952864387)
> It's not really clear to me what you're trying to achieve in this PR - some kind of way for transactions to specify what their > ancestor/descendant limits are? There are no tests, the CI is failing, and a lot of the code comments are incorrect/irrelevant > to the adjacent lines.

Yeah some kind of way for transactions to specify what their ancestor / descendant / max weight / limits, in the hard limits of current mempool ones. I know no test and CI failing, it’s just proof-of-concept code t
...

📝 josibake converted_to_draft a pull request: "Silent Payments: Implement BIP352"
(https://github.com/bitcoin/bitcoin/pull/28122)
This PR is part of integrating silent payments into Bitcoin Core. The project is tracked in https://github.com/bitcoin/bitcoin/issues/28536

## BIP352

This PR focuses strictly on the BIP logic and attempts to separate it from the wallet and transaction implementation details. This is accomplished by working directly with public and private keys, instead of needing a wallet backend and transactions for testing. Labels for the receiver are optional and thus deferred for a later PR.

Test ve
...

💬 fjahr commented on pull request "rpc: Do not wait for headers inside loadtxoutset":
(https://github.com/bitcoin/bitcoin/pull/29345#issuecomment-1952876404)
ACK faa30a4c56

Thanks, as @pablomartin4btc found, I had a slight preference for this simpler solution when reviewing the original PR.

I wrote a test for this (and also removed a `sync_block` call that seemed unnecessary in the process), can be pulled in here or I can open it as a follow-up: https://github.com/fjahr/bitcoin/commits/pr29345/