⚠️ paboum opened an issue: "Tx blockout"
(https://github.com/bitcoin/bitcoin/issues/31077)
### Please describe the feature you'd like to see added.

Maybe it's silly, but I suppose Bitcoin protocol could introduce via soft fork a possibility (a new script opcode) for specifying that the new transaction should either be mined in block number less than X or void (X is an user-defined value). Miners could, perhaps, demand more fee for X values significantly larger than the current block number.

I understand this would be a huge change in blockchain whatsoever and expect complex analys
...

✅ pinheadmz closed an issue: "Tx blockout"
(https://github.com/bitcoin/bitcoin/issues/31077)

💬 pinheadmz commented on issue "Tx blockout":
(https://github.com/bitcoin/bitcoin/issues/31077#issuecomment-2408546351)
See relevant discussions:

https://delvingbitcoin.org/t/op-checkmaxtimeverify/581/8

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022042.html


I'm going to close this issue since it is not relevant to bitcoin core as a software project. Protocol ideas like this are better expressed on the mailing list or Delving.

💬 jonatack commented on issue "Bitcoin Core "not opened" after software update to macOS Sequoia 15.0.1 (24A348)":
(https://github.com/bitcoin/bitcoin/issues/31069#issuecomment-2408582520)
@diivvy I am running current Bitcoin Core with macOS 15.0.1 without issues. I can see the wallets via either the Finder or the command line (i.e. with Terminal, iTerm2, etc.)

🤔 marcofleon reviewed a pull request: "p2p: Fill reconciliation sets (Erlay) attempt 2"
(https://github.com/bitcoin/bitcoin/pull/30116#pullrequestreview-2363929991)
I fuzzed the `txreconciliation` class with `-DSANITIZERS=fuzzer,undefined,integer` and two related runtime errors occurred:

<details>
<summary>errors</summary>

```bash
../../src/node/txreconciliation.cpp:457:46: runtime error: unsigned integer overflow: 1 - 3 cannot be represented in type 'size_t' (aka 'unsigned long')
#0 0x55ddab3b7d99 in TxReconciliationTracker::Impl::ShouldFanoutTo(transaction_identifier<true> const&, long, unsigned long, unsigned long) erlayfuzzbuild/src/../../s
...

💬 marcofleon commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1797721753)
Can `outbounds_fanout_tx_relay` ever be greater than 1 here? I think if we have two (or more) unregistered outbound peers and at least one registered peer, then this results in an unsigned integer overflow. Which then overflows `targets_size` in `IsFanoutTarget`.

💬 LarryRuane commented on pull request "netinfo: add peer services column and outbound-only peers list":
(https://github.com/bitcoin/bitcoin/pull/30930#discussion_r1797381849)
I like @vasild's observation that having a separate option (instead of using level 5) allows 0-4 to be used in both modes -- that's very flexible.

However, I suggest that the new option be `netinfo-outonly` (instead of `outonly`) and it would imply `netinfo` (`netinfo` wouldn't need to be specified) because it would be weird to have an option (`outonly`) that does nothing without `netinfo`. It would also be less convenient to have to specify both.

If both `netinfo` and `netinfo-outonly` ar
...

📝 TheCharlatan opened a pull request: "build: Fix kernel static lib component install"
(https://github.com/bitcoin/bitcoin/pull/31078)
Fixes the installation of the pkgconfig file and the static library when installing only the `Kernel` component.

This is a followup to fix #30835 and #30814, which were merged shortly after one another, but are interrelated. Can be tested with:
```
cmake -B build -DBUILD_SHARED_LIBS=OFF -DBUILD_KERNEL_LIB=ON
cmake --build build --target bitcoinkernel
cmake --install build --component Kernel
```

🤔 hebasto reviewed a pull request: "build: Fix kernel static lib component install"
(https://github.com/bitcoin/bitcoin/pull/31078#pullrequestreview-2364230778)
Concept ACK.

⚠️ Phoenix1969 opened an issue: "several vulnerabilities identified."
(https://github.com/bitcoin/bitcoin/issues/31079)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

1. Memory Management
Potential Vulnerability: Bitcoin Core is written primarily in C++, which can lead to memory management vulnerabilities (e.g., buffer overflows, memory leaks).
Improvement: Ensure that critical components like cryptographic functions, wallet code, and networking code use safe memory allocation patterns. For instance:
Audit the use of malloc() and free() for possible
...

📝 willcl-ark opened a pull request: "fees: document non-monotonic estimation edge case"
(https://github.com/bitcoin/bitcoin/pull/31080)
Closes: https://github.com/bitcoin/bitcoin/issues/11800

In scenarios where data is available for higher targets but not for lower ones, this method *may* return lower fee rates for higher confirmation targets. This could occur if `estimateCombinedFee` returns no valid data (`-1`) for some estimates for a low target, but **does** return valid data for a higher target.

Users of this function should be aware of this potential, if unlikely, inconsistency in behaviour in data-sparse scenarios.

✅ willcl-ark closed an issue: "several vulnerabilities identified."
(https://github.com/bitcoin/bitcoin/issues/31079)

💬 diivvy commented on issue "Bitcoin Core "not opened" after software update to macOS Sequoia 15.0.1 (24A348)":
(https://github.com/bitcoin/bitcoin/issues/31069#issuecomment-2408698108)
@jonatack which version of bitcoin core are you using?

💬 sipa commented on issue "Bitcoin Core "not opened" after software update to macOS Sequoia 15.0.1 (24A348)":
(https://github.com/bitcoin/bitcoin/issues/31069#issuecomment-2408698932)
@diivvy Did you seem the notes about running Bitcoin Core on macOS in the Bitcoin Core 28.0 release notes?

⚠️ tuttheking81 opened an issue: "Bumps [loader-utils](https://github.com/webpack/loader-utils) from 1.2.3 to 1.4.2."
(https://github.com/bitcoin/bitcoin/issues/31081)
Bumps [loader-utils](https://github.com/webpack/loader-utils) from 1.2.3 to 1.4.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/webpack/loader-utils/releases">loader-utils's releases</a>.</em></p>
<blockquote>
<h2>v1.4.2</h2>
<h3><a href="https://github.com/webpack/loader-utils/compare/v1.4.1...v1.4.2">1.4.2</a> (2022-11-11)</h3>
<h3>Bug Fixes</h3>
<ul>
<li>ReDoS problem (<a href="https://github-redirect.dependabot.com/webpack/loader-utils/issues/226
...

⚠️ tuttheking81 opened an issue: "- Fixed a minor bug that incorrectly printed the wrong status message to the user during remote verification."
(https://github.com/bitcoin/bitcoin/issues/31082)
- Fixed a minor bug that incorrectly printed the wrong status message to the user during remote verification.

_Originally posted by @swaroop-osec in https://github.com/Ellipsis-Labs/solana-verifiable-build/pull/53_

_Originally posted by @tuttheking81 in https://github.com/crypto-org-chain/cronos/issues/1426_

💬 rebroad commented on pull request "p2p: When close to the tip, download blocks in parallel from additional peers to prevent stalling":
(https://github.com/bitcoin/bitcoin/pull/29664#issuecomment-2408766991)
> > I'm still not sure why it failed, tried to bump a mocktime with the last push, but poking in the dark since it doesn't fail locally for me...
>
> Hopefullly fixed now, I believe that there was a missing sync in the added test.
>
> > Rather than the crude 10 minute timeout - why not actually check if the block is being downloaded from the chosen peer - i.e. work out the throughput and make a decision based on this (compared to typical throughput from other peers)?
>
> I'm not sure wh
...

📝 willcl-ark opened a pull request: "doc: add doxygen for m_args in tests"
(https://github.com/bitcoin/bitcoin/pull/31083)
Closes: #25055

Add a doxygen comment to the `m_args` member in the unit test framework, clarifying its purpose and providing usage guidelines.

💬 l0rinc commented on pull request "Don't zero-after-free `DataStream`: Faster IBD on some configurations":
(https://github.com/bitcoin/bitcoin/pull/30987#issuecomment-2408875704)
I reran it on the same platform until 840000 with 1GB dbcache with the latest commits.

<details>
<summary>benchmark</summary>

```bash
hyperfine \
--runs 1 \
--export-json /mnt/my_storage/ibd_full-zero_after_free_allocator_change.json \
--parameter-list COMMIT 1e096b30da808d6b0691f5cde14c529e1c85ff1b,906e67b95157fd557438c37b3085cf5dec2ae135 \
--prepare 'git checkout {COMMIT} && git clean -fxd && git reset \
--hard && cmake -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_UTIL=OFF -DBUILD_
...

💬 l0rinc commented on pull request "validation: write chainstate to disk every hour":
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2408917989)
I redid the benchmarks on an SSD with 100-120 second range:
* (before) 5e90501abe test: chainstate write test for periodic chainstate flush
* (write every 50-70 minutes) ffc9df87a0 validation: add randomness to periodic write interval
* (write every 100-120 minutes) f5e7b1508a Increase DATABASE_WRITE_INTERVAL MIN/MAX to 100/120

<details>
<summary>benchmark</summary>

```bash
hyperfine \
--runs 1 \
--export-json /mnt/my_storage/ibd_full-write-chainstate-every-hour.json \
--parameter-
...