💬 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.
(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.
(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'
...
(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.
(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
(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
(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`
(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!
(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.
(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.
(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.
(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.
(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.
💬 sipa commented on pull request "Replace cluster linearization algorithm with SFL":
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2925757556)
Thanks for all the benchmarks, see some graphs I created to compare their relative performance:
(code & data to generate them is [here](https://gist.github.com/sipa/f002a7e552fedabd5d727eb4a55624f0
...
(https://github.com/bitcoin/bitcoin/pull/32545#issuecomment-2925757556)
Thanks for all the benchmarks, see some graphs I created to compare their relative performance:
(code & data to generate them is [here](https://gist.github.com/sipa/f002a7e552fedabd5d727eb4a55624f0
...
💬 fjahr commented on pull request "index: Check all necessary block data is available before starting to sync":
(https://github.com/bitcoin/bitcoin/pull/29770#discussion_r2118296430)
Ok, I have addressed this by pulling the handing of this special case up and doing a check for block data of genesis if that is what's needed by an index that requires undo data.
(https://github.com/bitcoin/bitcoin/pull/29770#discussion_r2118296430)
Ok, I have addressed this by pulling the handing of this special case up and doing a check for block data of genesis if that is what's needed by an index that requires undo data.
💬 fjahr commented on pull request "index: Check all necessary block data is available before starting to sync":
(https://github.com/bitcoin/bitcoin/pull/29770#issuecomment-2925784992)
Rebased, sorry for the long delay!
(https://github.com/bitcoin/bitcoin/pull/29770#issuecomment-2925784992)
Rebased, sorry for the long delay!
💬 Jezmaul commented on something "":
(https://github.com/bitcoin/bitcoin/commit/2b51dd384b4a2655ee066e8bccd254270d0f5f6c#r158717712)
3E6RsQwEWiCLvZ3Lq33X1dR43VLTzYK9gg
(https://github.com/bitcoin/bitcoin/commit/2b51dd384b4a2655ee066e8bccd254270d0f5f6c#r158717712)
3E6RsQwEWiCLvZ3Lq33X1dR43VLTzYK9gg
✅ fanquake closed an issue: "seeds: seed.bitcoin.jonasschnelli.ch not returning results"
(https://github.com/bitcoin/bitcoin/issues/32590)
(https://github.com/bitcoin/bitcoin/issues/32590)
✅ ismaelsadeeq closed a pull request: "init: deprecate `-blockmaxweight` startup option"
(https://github.com/bitcoin/bitcoin/pull/32654)
(https://github.com/bitcoin/bitcoin/pull/32654)
💬 ismaelsadeeq commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#issuecomment-2926865658)
> 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.
Not sure what you mean by “having to pretend to pad the coinbase is a very awkward alternative.”
The reservedweight isn’t just for the coinbase it also applies to the block header and transaction count. It seems r
...
(https://github.com/bitcoin/bitcoin/pull/32654#issuecomment-2926865658)
> 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.
Not sure what you mean by “having to pretend to pad the coinbase is a very awkward alternative.”
The reservedweight isn’t just for the coinbase it also applies to the block header and transaction count. It seems r
...
💬 ismaelsadeeq commented on pull request "init: deprecate `-blockmaxweight` startup option":
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118919977)
Yes thats correct, this increases the weight by 8000.
(https://github.com/bitcoin/bitcoin/pull/32654#discussion_r2118919977)
Yes thats correct, this increases the weight by 8000.