Bitcoin Core Github
42 subscribers
126K links
Download Telegram
💬 maflcko commented on pull request "cmake: Introduce `WITH_PYTHON` build option":
(https://github.com/bitcoin/bitcoin/pull/31669#issuecomment-2595671323)
Yeah, I suggested this for reasons other than the CI fix, because it could be useful outside the CI as well. But no strong opinion.
💬 Detroitin commented on issue "Testnet4 consensus failure due to timewarp related "softfork"":
(https://github.com/bitcoin/bitcoin/issues/30786#issuecomment-2595678247)
> > Anyone have an asic to reorg that?
>
> MARA hash on the way! Luxor also said they are willing to help as well. Shout out to Nick to even turning me onto this problem.

I have/had some pointed, probably 120TH and mempool displayed 20-25TH/s so when I see the hashrate that is being displayed on mempool. space, THERE IS ALOT! WELL OVER 1 PH/S. and MARA you are the only other miner who has a pool with statistics showing?? what ive seen so far is this guy I grabbing his nuts flipping us off.
...
💬 laanwj commented on pull request "test: Add mockable steady clock, tests for PCP and NATPMP implementations":
(https://github.com/bitcoin/bitcoin/pull/31022#discussion_r1918551760)
For sake of completeness. i think it's uglier to fall through to the parent class, which would do an actual `getsockopt` call on an invalid socket if in the future the called code would use `GetSockOpt`.

i kind of wish there was a purely virtual `BaseSock` and `PosixSock` and `TestSock` etc were a subclass of this, so every subclass would be forced to implement everything.
💬 maflcko commented on pull request "Added rescan option for import descriptors":
(https://github.com/bitcoin/bitcoin/pull/31668#issuecomment-2595683931)
This needs a test and the tests fixed
💬 glozow commented on pull request "p2p: track and use all potential peers for orphan resolution":
(https://github.com/bitcoin/bitcoin/pull/31397#discussion_r1918560208)
Done in followup, and also think we can `EraseTx` here. See #31666
💬 laanwj commented on pull request "test: Add mockable steady clock, tests for PCP and NATPMP implementations":
(https://github.com/bitcoin/bitcoin/pull/31022#discussion_r1918567089)
Yes. It makes no sense, it doesn't even use `m_socket`.
i copied this destructor from `StaticContentsSock`, which i think also does it redundantly.
💬 fanquake commented on pull request "depends: Qt 5.15.16":
(https://github.com/bitcoin/bitcoin/pull/30774#issuecomment-2595719301)
Guix build (x86_64):
```bash
e80422975315244b3365bf9eddb9e6e5d9da08f4b1a5fba34430c6f3021c6b8a guix-build-31a0e5f0905b/output/aarch64-linux-gnu/SHA256SUMS.part
db53cd0057bf0048534e3daea2e39130cdf64a140becaa5c6ff4f98fdfa5936a guix-build-31a0e5f0905b/output/aarch64-linux-gnu/bitcoin-31a0e5f0905b-aarch64-linux-gnu-debug.tar.gz
fa061afbd1dac25c739a63a1644f2af1ad5dab36ea5e4245a7b0bb9008ca4f79 guix-build-31a0e5f0905b/output/aarch64-linux-gnu/bitcoin-31a0e5f0905b-aarch64-linux-gnu.tar.gz
f286a74
...
🚀 fanquake merged a pull request: "p2p: track and use all potential peers for orphan resolution"
(https://github.com/bitcoin/bitcoin/pull/31397)
💬 laanwj commented on pull request "test: Add mockable steady clock, tests for PCP and NATPMP implementations":
(https://github.com/bitcoin/bitcoin/pull/31022#discussion_r1918601053)
Ok, will just make it do nothing and return -1. That's just as valid, no need fo the memset.
📝 vasild opened a pull request: "rpc: add cpu_load to getpeerinfo"
(https://github.com/bitcoin/bitcoin/pull/31672)
Add a new field `cpu_load` to the output of `getpeerinfo` RPC.

It represents the CPU time spent by the message handling thread for the given peer, weighted for the duration of the connection. That is, for example, if two peers are equally demanding and one is connected longer than the other, then they will have the same `cpu_load` number.

---

Monitoring CPU usage is useful on its own. Also related to https://github.com/bitcoin/bitcoin/issues/31033.
💬 brunoerg commented on pull request "wallet: Utilize IsMine() and CanProvide() in migration to cover edge cases":
(https://github.com/bitcoin/bitcoin/pull/31495#discussion_r1918646257)
88b67c95cbc9c3ae75ccbc39e4aba215b9910b8b: Since you're checking the "descriptors" field into `migrate_and_get_rpc`, you could also assert the wallet is sqlite and then remove the duplicated code along the test. e.g.:

```py
_, multisig0 = self.migrate_and_get_rpc("multisig0")
assert_equal(multisig0.getwalletinfo()["descriptors"], True)
self.assert_is_sqlite("multisig0")
```

```py
_, multisig0 = self.migrate_and_get_rpc("multisig0")
assert_equal(
...
💬 jonatack commented on pull request "rpc: add cpu_load to getpeerinfo":
(https://github.com/bitcoin/bitcoin/pull/31672#issuecomment-2595869832)
Concept ACK if this can be a reliable, useful metric and help pave the path to https://github.com/bitcoin/bitcoin/issues/31033.
💬 laanwj commented on pull request "test: Add mockable steady clock, tests for PCP and NATPMP implementations":
(https://github.com/bitcoin/bitcoin/pull/31022#issuecomment-2595871882)
Updated for @darosior's suggestions.
💬 darosior commented on pull request "test: Add mockable steady clock, tests for PCP and NATPMP implementations":
(https://github.com/bitcoin/bitcoin/pull/31022#discussion_r1918705629)
clang-tidy complains about this:
> [09:51:32.084] [584/666][11.5s] clang-tidy-19 -p=/ci_container_base/ci/scratch/build-x86_64-pc-linux-gnu -quiet -load=/tidy-build/libbitcoin-tidy.so /ci_container_base/src/test/pcp_tests.cpp
[09:51:32.084] /ci_container_base/src/test/pcp_tests.cpp:96:5: error: use '= default' to define a trivial destructor [modernize-use-equals-default,-warnings-as-errors]
[09:51:32.084] 96 | ~PCPTestSock() override { }
[09:51:32.084] | ^
...
💬 laanwj commented on pull request "test: Add mockable steady clock, tests for PCP and NATPMP implementations":
(https://github.com/bitcoin/bitcoin/pull/31022#discussion_r1918717853)
Yes, this is really silly. Linters are useful for preventing constructs that have high risk of bugs but this just seems like busywork.
Anyhow, removed the destructor completely and re-pushed.
🚀 fanquake merged a pull request: "kernel: Move kernel-related cache constants to kernel cache"
(https://github.com/bitcoin/bitcoin/pull/31483)
💬 maflcko commented on pull request "test: Add mockable steady clock, tests for PCP and NATPMP implementations":
(https://github.com/bitcoin/bitcoin/pull/31022#discussion_r1918740367)
I added this in 3333bae9b2a, because it allows compiler optimizations according to the docs (https://clang.llvm.org/extra/clang-tidy/checks/modernize/use-equals-default.html). Obviously the performance doesn't matter in most cases (like in the context of this pull). Though, it is also one less thing to bikeshed about. Still, I am happy to have it taken out again.
💬 Sjors commented on pull request "wallet: `addhdkey` RPC to add just keys to wallets via new `void(KEY)` descriptor":
(https://github.com/bitcoin/bitcoin/pull/29136#issuecomment-2596004758)
Concept ACK. This seems like a step in the right direction.

I tried updating the multisig tutorial to take advantage of this in https://github.com/Sjors/bitcoin/commit/7bb9a172c6539de5c02ac70f9e38724a0e3e82dc. It also uses `gethdkeys` and the new `<0;1>` notation.

But it's still a massive pain for two reasons:
1. There's no way to get the xpub at `m/87'/1'/0'`; I create a workaround which inserts a dummy `pk()` with that derivation, but this is ugly and requires passing the master xprv a
...
💬 maflcko commented on pull request "p2p: track and use all potential peers for orphan resolution":
(https://github.com/bitcoin/bitcoin/pull/31397#discussion_r1918744397)
Looks like this fails CI https://cirrus-ci.com/task/4584274617171968?logs=ci#L2784:

```
[15:13:20.370] test 2025-01-16T15:13:19.950000Z TestFramework (ERROR): Assertion failed
[15:13:20.370] Traceback (most recent call last):
[15:13:20.370] File "/ci_container_base/test/functional/test_framework/test_framework.py", line 135, in main
[15:13:20.370] self.run_test()
[15:13:20.37
...
💬 instagibbs commented on pull request "p2p: track and use all potential peers for orphan resolution":
(https://github.com/bitcoin/bitcoin/pull/31397#discussion_r1918746739)
wait until?