💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925140605)
@andrewtoth but `nproc` command gives the answer 4. Is it still worth will to set `rpcthreads` to 16?

💬 andrewtoth commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925144203)
Yes, since the requests are io bound they will mostly be waiting concurrently and not using much CPU.

💬 sean-k1 commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#issuecomment-2925148327)
@achow101 @maflcko
we fixed the lint error.
There seems to be a lot of discussion, let me know when it's clear.

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925149364)
OK, thanks a lot. I will remove it sooner or later!

💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2925180422)
@instagibbs @ismaelsadeeq @gmaxwell FWIW, I didn't include apples-to-apples comparison because the large-scale comparison [benchmarks](https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/73) I did (especially, [this one](https://delvingbitcoin.org/uploads/default/original/2X/2/22ad16f71db37fcb8cadb8a8f73c4acfd3def203.png)) were just overwhelmingly in favor of SFL over the existing one. The benchmarks were mostly done to decide between SFL and another replacement algorithm, GGT, but se
...

💬 ismaelsadeeq commented on issue "test: `feature_fee_estimation` failure after duplicate coinbase tx weight reservation fix [AssertionError: Estimated fee (0.00923427) out of range]":
(https://github.com/bitcoin/bitcoin/issues/32461#issuecomment-2925282272)
> Also, it's quite strange that the test started failing on this commit: [https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c](https://github.com/bitcoin/bitcoin/commit/6b165f5906fc53bd10bedff85a6ef26e0aabdc5c)
> I haven't looked into that yet.

I’ve debugged the issue and discovered why this seed only fails on commit 6b165f5906fc53bd10bedff85a6ef26e0aabdc5c

This is because, prior to that commit, we reserved only 8000 WU only when using the default `-blockmaxweigh
...

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925284510)
Increasing `options.block_cache` and `options.write_buffer_size` didn't (really) help. Back to removing the LevelDB max file size increase.

💬 pinheadmz commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#issuecomment-2925310556)
Should I try to build and sign again? Recent just looks like a repository change.

💬 fanquake commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#issuecomment-2925315157)
Yea, just a rebase on the Guix repo change. If you don't mind building again, that'd be great. Can debug.

📝 ismaelsadeeq opened a pull request: "init: deprecate `-blockmaxweight` startup option"
(https://github.com/bitcoin/bitcoin/pull/32654)
This PR deprecate `-blockmaxweight` option marked it for removal in the future as discussion in https://github.com/bitcoin/bitcoin/pull/31384#discussion_r1945280589

The plan is to deprecate it in v30 and remove it in v31.

Miners can lower the block weight using `-blockreservedweight` option.

💬 l0rinc commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925382555)
> shouldn't options.block_cache and options.write_buffer_size be increased?

I have experimented a lot with these and they all just slowed down IBD for me. Definitely let us know if it's different on your system.

Compaction could theoretically be a problem, but my understanding is that it would just mean that a few spikes are larger, most other processing should be significantly faster. Is this your only complain? On average this made IBD and block processing in general ~30% faster - but there'
...

💬 tnndbtc commented on pull request "fee estimate test: fix #31944 by handling a legitimate scenario that …":
(https://github.com/bitcoin/bitcoin/pull/32615#discussion_r2118030536)
@ismaelsadeeq Agree. So, I took a list of good fees that will guarantee to pass the check of fees and smart fees and hard code them for the test. This way the randomness is gone and it's deterministic now.

🤔 polespinasa reviewed a pull request: "init: deprecate `-blockmaxweight` startup option"
(https://github.com/bitcoin/bitcoin/pull/32654#pullrequestreview-2884321525)
cACK

Needs release note

💬 polespinasa commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118049736)
If the plan is to remove on v31 maybe specifying it is a good idea.
See https://github.com/bitcoin/bitcoin/blob/4b1d48a6866b24f0ed027334c6de642fc848d083/src/wallet/wallet.cpp#L3006-L3007

💬 pinheadmz commented on pull request "[28.x] Backport #31407":
(https://github.com/bitcoin/bitcoin/pull/32563#issuecomment-2925427970)
same issue, `RuntimeError: File size too large, try using force_zip64`

💬 hMsats commented on issue "bitcoind 29.0 much slower than 28.0 on my system: cause found":
(https://github.com/bitcoin/bitcoin/issues/32455#issuecomment-2925466140)
@l0rinc My experience is that it's best to just leave the LevelDB max file size as it always was (never a spike or complaints from Fulcrum or CLN) but I've never verified that for more than 110 blocks. So I will now just let the whole system run 29.0 (without the LevelDB max file size increase to 32MiB) for a longer time (a week or so) and see what happens and report back. Thanks for the feedback!

💬 ajtowns commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#issuecomment-2925674473)
Concept NACK. Lowering the block max weight can be a useful thing to do to (eg, signet blocks are limited to 1M weight units in order to help generate fee pressure, and mildly discourage wasteful usage), and having to pretend to pad the coinbase is a very awkward alternative.

💬 ajtowns commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118212646)
To preserve the same behaviour these values should be increased by `DEFAULT_BLOCK_RESERVED_WEIGHT` (8000), I think.

💬 fjahr commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118221266)
This looked kind of confusing to me: The node is restarted without `blockmaxweight` but the deprecation warning from init is still expected to show here. Looking at how this works in `restart_node` explains why: The warning is checked during stopping of the node and not during starting of node. I think it would be good to add at least some comment here how this works. Maybe there is also a more expressive way to handle it but I think a comment is good enough.

💬 jonasschnelli commented on issue "seeds: seed.bitcoin.jonasschnelli.ch not returning results":
(https://github.com/bitcoin/bitcoin/issues/32590#issuecomment-2925699813)
Thanks for reporting.
VM ran out of RAM again... increased RAM and restarted.
Let’s see.