💬 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

💬 brunoerg commented on pull request "init: point out -stopatheight may be imprecise":
(https://github.com/bitcoin/bitcoin/pull/33993#issuecomment-3610404149)
I just addressed @stickies-v's suggestion: https://github.com/bitcoin/bitcoin/pull/33993#discussion_r2580857428.

💬 brunoerg commented on pull request "mining: add getMemoryLoad() and track template non-mempool memory footprint":
(https://github.com/bitcoin/bitcoin/pull/33922#discussion_r2587699846)
Nice, thank you!

💬 romanz commented on pull request "rest: allow reading partial block data from storage":
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3610528091)
Tested REST throughput using block #900000:
```
ab -k -c 1 -n 10000 'http://localhost:8332/rest/block/000000000000000000010538edbfd2d5b809a33dd83f284aeea41c6d0d96968a.bin'
```
### d30f149360 (baseline - before this PR)
```
Concurrency Level: 1
Time taken for tests: 11.033 seconds
Complete requests: 10000
Failed requests: 0
Keep-Alive requests: 10000
Total transferred: 19208850000 bytes
HTML transferred: 19207770000 bytes
Requests per second: 906.3
...

⚠️ diegoviola opened an issue: "Consider enabling plugin=wayland for bitcoincore.org builds"
(https://github.com/bitcoin-core/gui/issues/916)
### Please describe the feature you'd like to see added.

Wayland is the new standard on Linux these days, pretty much every major distro and DE is on board. And considering that https://github.com/bitcoin-core/gui/pull/914 has solved some of the issues with it that were remaining, I think it's a safe to enable `plugin=wayland` by default for builds in bitcoincore.org.

Furthermore, I would like to point out (again) that https://github.com/bitcoin-core/gui/pull/817 is not a problem with the code
...

💬 ANtutov commented on pull request "refactor: replace manual promise with SyncWithValidationInterfaceQueue":
(https://github.com/bitcoin/bitcoin/pull/33962#discussion_r2587902186)
> @ANtutov are you still working on this?

I'm sorry for the delay, had some problems with laptop, gonna correct

💬 Sjors commented on pull request "mining: getCoinbase() returns struct instead of raw tx":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3610851815)
Applied both suggestions from @ryanofsky: https://github.com/bitcoin/bitcoin/pull/33819#pullrequestreview-3536150722

👍 rkrux approved a pull request: "init: point out -stopatheight may be imprecise"
(https://github.com/bitcoin/bitcoin/pull/33993#pullrequestreview-3538723098)
re-ACK ff06e2468a5d3eeebeffe781904c34c9d1b44385

💬 jsarenik commented on issue "RFC: when to drop testnet3":
(https://github.com/bitcoin/bitcoin/issues/31975#issuecomment-3610987875)
Yes. As for me, it would be a clear sign if testnet3 gets dropped.

But: Testnet4 has many stale blocks currently and most of the mining there seems very different from Bitcoin mainnet, rendering it unusable for anything but experimentation with permissionless mining itself. But fair enough as for app development there is signet.

I think that getting rid of testnet3 may just make any future investigation harder. It was the longest-living testnet so far. See https://github.com/fjahr/test_chain_i
...

💬 plebhash commented on issue "Memory leak when using IPC mining interface":
(https://github.com/bitcoin/bitcoin/issues/33940#issuecomment-3611006053)
> If someone can let me know what code to check out and build, and what commands to run that will show the increasing memory usage over time, that would be great.

- launch Bitcoin Core on `mainnet` (for high mempool activity)
- `git clone https://github.com/stratum-mining/sv2-apps -b v0.1.0`
- edit `sv2-apps/pool-apps/pool/config-examples/mainnet/pool-config-bitcoin-core-ipc-example.toml` to make sure `unix_socket_path` is set correctly
- `cd sv2-apps/pool-apps/pool; cargo run -- -c config-exam
...