💬 jaonoctus commented on pull request "init: point out -stopatheight may be imprecise":
(https://github.com/bitcoin/bitcoin/pull/33993#issuecomment-3608878395)
tACK e4703863655135856d0d6ad54a7021d3326bf071

I would love to fix the issue mentioned tho, but updating the description is a good start

📝 ryanofsky opened a pull request: "test: interface_ipc.py minor fixes and cleanup"
(https://github.com/bitcoin/bitcoin/pull/34003)
This PR cleans up the `interface_ipc.py` test, fixing broken checks, fixing missing await calls, removing to_dict calls, renaming variables, reducing `.result` accesses, and giving template objects explicit lifetimes. More details are in the commit message.

👍 pablomartin4btc approved a pull request: "init: point out -stopatheight may be imprecise"
(https://github.com/bitcoin/bitcoin/pull/33993#pullrequestreview-3537008041)
utACK e4703863655135856d0d6ad54a7021d3326bf071

I'd also go with @stickies-v's [version](https://github.com/bitcoin/bitcoin/pull/33993#discussion_r2580857428) if you have to retouch.

💬 ryanofsky commented on pull request "mining: add getMemoryLoad() and track template non-mempool memory footprint":
(https://github.com/bitcoin/bitcoin/pull/33922#issuecomment-3608940825)
Concept ACK e8f8f7f677bcde0179526be3ed9a657c44998b93. All the changes here seem good and mostly straightforward. The `getMemoryLoad()` function seems useful by itself and the underlying tracking would seem to provide almost everything needed to limit memory used by block templates.

I am a little concerned about the idea of proactively deleting block templates in FIFO order on behalf of clients, since it seems like this could increase complexity server-side, and client-side if clients have to
...

✅ pinheadmz closed an issue: "Request to help mining two Nonstandard UTXO which fails cleanstack"
(https://github.com/bitcoin/bitcoin/issues/34002)

💬 pinheadmz commented on issue "Request to help mining two Nonstandard UTXO which fails cleanstack":
(https://github.com/bitcoin/bitcoin/issues/34002#issuecomment-3609010449)
The Bitcoin Core issue tracker is reserved for specific software issues like bug reports and feature requests. Individual help inquiries or general Bitcoin usage questions are more appropriate at https://bitcoin.stackexchange.com https://reddit.com/r/bitcoin or IRC channels such as `#bitcoin`

💬 mzumsande commented on issue "ASN-based bucketing of the network nodes":
(https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3609099274)
> a conceivable scenario entails a non-negligible share of Bitcoin nodes not being able to sustain ten outbound connections because they are in constant competition with other nodes for inbound slots on „small-AS“ nodes although ample unused inbound resources are available on „large-AS“ nodes.

This would likely lead to a "ping-pong" effect of evictions:

When most popular reachable nodes are full (125 peers), and other nodes seeking for outbound peers will connect to them, they will usually ac
...

💬 hodlinator commented on pull request "rest: allow reading partial block data from storage":
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3609114450)
Been running some benchmarks:

```shell
₿ cmake --build build -t bench_bitcoin && ./build/bin/bench_bitcoin -filter=ReadRawBlockBench -min-time=15000
```
(Usually second run has lower error rate).

### baseline - master - `07b82782~` = d30f149360

```
| ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark
|--------------------:|--------------------:|--------:|----------------:|--------------
...

💬 sipa commented on issue "ASN-based bucketing of the network nodes":
(https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3609129125)
> When most popular reachable nodes are full (125 peers), and other nodes seeking for outbound peers will connect to them, they will usually accept the connection, but at the same time evict another peer to make room. The evicted peer then looks for a new outbound peer, which, if also full, evicts yet another one and so on, leading to long chains of churning through peers which would obviously be bad for the network.

Is that really what happens? That sounds undesirable, independent of this issu
...

💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-3609135872)
FWIW, I'm writing a Python version of SFL with simpler data structures and less optimizations. It needs some polishing, but I'll post it here. It could be used as a form of documentation, or live in the functional test framework.

💬 mzumsande commented on issue "ASN-based bucketing of the network nodes":
(https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3609156243)
> Is that really what happens?

I think so, at least with the default `-maxconnections` (we protect a fixed number of peers with the inbound eviction logic, so with `-maxonnections=30` things may be different). The upside of this is that even if you manage to eclipse a node, keeping it eclipsed is much harder, because every new inbound could break the eclipse (and would immediately get protected from eviction if it provided us a new block the other nodes were withholding from us).

🤔 stickies-v reviewed a pull request: "kernel: don't use assert to handle invalid user input"
(https://github.com/bitcoin/bitcoin/pull/33943#pullrequestreview-3537340582)
> but not sure about adding more error handling surface to the API with the current approach

One design goal of this PR was to minimize increasing the error handling surface while achieving the goal of making these functions more testable, but it seems like the current solution is not striking the right balance. I'm converting this PR to draft while I'm exploring other options, including implementing (global or local) error/illegal callbacks similar to secp256k1 (but that would be a pretty bi
...

💬 stickies-v commented on pull request "kernel: don't use assert to handle invalid user input":
(https://github.com/bitcoin/bitcoin/pull/33943#discussion_r2586954327)
I think you're right that there is no strict consistency wrt return codes in the API, and that's also why I defined the status codes inside the function rather than in the header. A function-specific enum like `btck_ScriptPubkeyVerifyResult` could be an alternative, though. I didn't do it to minimize overhead, but am open to doing that if preferred.

💬 stickies-v commented on pull request "kernel: don't use assert to handle invalid user input":
(https://github.com/bitcoin/bitcoin/pull/33943#discussion_r2586957013)
I'm keeping the behaviour as-is as the default stance, but yes, I'm also not 100% sure on the boundary between `INVALID_REQUEST` and `INVALID_SCRIPT` here. I mention this at the end of the PR description, too. I'd like to understand that rationale better - perhaps @sedited can chime in?

💬 stickies-v commented on pull request "kernel: don't use assert to handle invalid user input":
(https://github.com/bitcoin/bitcoin/pull/33943#discussion_r2586951045)
The API is in C, and C doesn't have exceptions, so we have to make sure no exceptions cross the C++/C boundary.

📝 stickies-v converted_to_draft a pull request: "kernel: don't use assert to handle invalid user input"
(https://github.com/bitcoin/bitcoin/pull/33943)
Crashing with `assert` for invalid user input is problematic for a library, e.g. this is impossible for FFI users to recover from, forcing them to re-implement the error handling logic client-side. See e.g. the [go](https://github.com/stringintech/go-bitcoinkernel/blob/88105c69b32c48919a45bb07fc05ca2c79d2728b/kernel/script_pubkey.go#L91-L102) and [.net](https://github.com/janb84/BitcoinKernel.NET/blob/4ba1ff802fe9a3b7c0af0012e6fdc33e5bc4f961/src/BitcoinKernel.Core/ScriptVerification/ScriptVerifi
...

💬 Jonatanc05 commented on issue "kernel: feedback on using kernel in alternative implementations":
(https://github.com/bitcoin/bitcoin/issues/31878#issuecomment-3609448765)
I have been developing a [recreational implementation of a bitcoin node](https://github.com/Jonatanc05/ZiglyNode) and it's getting to a point where I could use it to make some naive tooling and maybe research futurely. I don't have anything concrete but I think the mentioned "unsafe mode" would greatly benefit students, beginners and people starting a modest project with no big commitments. We have seen many good things arise from modest projects

Linux:
> I'm doing a (free) operating system (ju
...

💬 Ataraxia009 commented on pull request "init: Changing the rpcbind argument being ignored to a pop up warning":
(https://github.com/bitcoin/bitcoin/pull/33813#issuecomment-3610175681)
closing this, this is resolved by: https://github.com/bitcoin/bitcoin/commit/fa45a1503eee603059166071857215ea9bd7242a

✅ Ataraxia009 closed a pull request: "init: Changing the rpcbind argument being ignored to a pop up warning"
(https://github.com/bitcoin/bitcoin/pull/33813)

💬 Ataraxia009 commented on pull request "init: Changing the rpcbind argument being ignored to a pop up warning":
(https://github.com/bitcoin/bitcoin/pull/33813#issuecomment-3610178112)
closing this, this is resolved by: https://github.com/bitcoin/bitcoin/commit/fa45a1503eee603059166071857215ea9bd7242a