📝 ryanofsky opened a pull request: " Update libmultiprocess subtree to fix intermittent mptest hang"
(https://github.com/bitcoin/bitcoin/pull/33412)
Includes:
- https://github.com/bitcoin-core/libmultiprocess/pull/207
- https://github.com/bitcoin-core/libmultiprocess/pull/208
- https://github.com/bitcoin-core/libmultiprocess/pull/211
- https://github.com/bitcoin-core/libmultiprocess/pull/201
The last change fixes the test hang reported https://github.com/bitcoin/bitcoin/issues/33244
The changes can be verified by running `test/lint/git-subtree-check.sh src/ipc/libmultiprocess` as described in [developer notes](https://github.com/
...
(https://github.com/bitcoin/bitcoin/pull/33412)
Includes:
- https://github.com/bitcoin-core/libmultiprocess/pull/207
- https://github.com/bitcoin-core/libmultiprocess/pull/208
- https://github.com/bitcoin-core/libmultiprocess/pull/211
- https://github.com/bitcoin-core/libmultiprocess/pull/201
The last change fixes the test hang reported https://github.com/bitcoin/bitcoin/issues/33244
The changes can be verified by running `test/lint/git-subtree-check.sh src/ipc/libmultiprocess` as described in [developer notes](https://github.com/
...
💬 danielabrozzoni commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2355023220)
> The max value is only validated on 64 bits, since it's not unreasonable for 32 bits to have max memory, but on 64 bits it's likely an error.
This wasn’t immediately clear to me :) Maybe add that sentence to the commit message to make it clearer.
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2355023220)
> The max value is only validated on 64 bits, since it's not unreasonable for 32 bits to have max memory, but on 64 bits it's likely an error.
This wasn’t immediately clear to me :) Maybe add that sentence to the commit message to make it clearer.
💬 fanquake commented on pull request "ci: re-add Valgrind job to the CI":
(https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302327390)
The runtime isn't too bad, and it's just blown out by `wallet_miniscript.py`, which is ~4 times slower than the next slowest running test (`signet_miner.py`):
```bash
tool_signet_miner.py | ✓ Passed | 536 s
wallet_miniscript.py | ✓ Passed | 2086 s
```
(https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302327390)
The runtime isn't too bad, and it's just blown out by `wallet_miniscript.py`, which is ~4 times slower than the next slowest running test (`signet_miner.py`):
```bash
tool_signet_miner.py | ✓ Passed | 536 s
wallet_miniscript.py | ✓ Passed | 2086 s
```
💬 ismaelsadeeq commented on issue "RFC: Bitcoin Core Node `BlockTemplateManager`":
(https://github.com/bitcoin/bitcoin/issues/33389#issuecomment-3302349836)
> Overall, notion of a shared cache seems useful. In terms of the implementation approach, I think it'd be nice if new code were integrated with existing code sooner rather than later (for example if waitNext could call this in the same PR it was introduced, or if this could be used to replace static BlockAssembler variables) to avoid having duplicate functionality, and make sure the new code is well tested and the interface is practically useful
I will be working on polishing the branch and op
...
(https://github.com/bitcoin/bitcoin/issues/33389#issuecomment-3302349836)
> Overall, notion of a shared cache seems useful. In terms of the implementation approach, I think it'd be nice if new code were integrated with existing code sooner rather than later (for example if waitNext could call this in the same PR it was introduced, or if this could be used to replace static BlockAssembler variables) to avoid having duplicate functionality, and make sure the new code is well tested and the interface is practically useful
I will be working on polishing the branch and op
...
💬 fanquake commented on issue "Slow unit tests delay functional tests and leave CPU unused":
(https://github.com/bitcoin/bitcoin/issues/32770#issuecomment-3302352281)
> Same for wallet_miniscript.py in the functional tests. Under Valgrind, it is the slowest test by at least 2x any other test.
Seems to be ~4 times slower than the next slowest test: https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302327390.
(https://github.com/bitcoin/bitcoin/issues/32770#issuecomment-3302352281)
> Same for wallet_miniscript.py in the functional tests. Under Valgrind, it is the slowest test by at least 2x any other test.
Seems to be ~4 times slower than the next slowest test: https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302327390.
⚠️ nerses-asaturyan opened an issue: "Support Multiple OP_RETURNs or Raise OP_RETURN Limit"
(https://github.com/bitcoin/bitcoin/issues/33413)
### Please describe the feature you'd like to see added.
Bitcoin currently restricts transactions to a single OP_RETURN output of 80 bytes. This is too limiting for practical use cases like cross-chain swaps and DeFi, where OP_RETURN serves as a lightweight log (e.g. destination token addresses, proofs, parameters).
The restriction also creates inequality: miners with custom policies already accept multiple or larger OP_RETURNs, while standard users cannot. This is similar to MEV and reduces n
...
(https://github.com/bitcoin/bitcoin/issues/33413)
### Please describe the feature you'd like to see added.
Bitcoin currently restricts transactions to a single OP_RETURN output of 80 bytes. This is too limiting for practical use cases like cross-chain swaps and DeFi, where OP_RETURN serves as a lightweight log (e.g. destination token addresses, proofs, parameters).
The restriction also creates inequality: miners with custom policies already accept multiple or larger OP_RETURNs, while standard users cannot. This is similar to MEV and reduces n
...
💬 TheCharlatan commented on pull request "coins: warn on oversized `-dbcache`":
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2355054943)
Mmh, I'm not sure about this check, wouldn't it make more sense to check that it measures something at all, i.e. is greater than 0?
(https://github.com/bitcoin/bitcoin/pull/33333#discussion_r2355054943)
Mmh, I'm not sure about this check, wouldn't it make more sense to check that it measures something at all, i.e. is greater than 0?
📝 vasild opened a pull request: "tor: enable PoW defenses for automatically created hidden services"
(https://github.com/bitcoin/bitcoin/pull/33414)
Enable [PoW defenses](https://tpo.pages.torproject.net/onion-services/ecosystem/technology/security/pow/) for hidden services that we create via Tor Control using the [`ADD_ONION` command](https://spec.torproject.org/control-spec/commands.html#add_onion).
The ability to do that has been added in [tor-0.4.9.2-alpha](https://gitlab.torproject.org/tpo/core/tor/-/commit/02c18044464bfe45f168b55297a785244094cfd5). Previous versions return a syntax error to the `ADD_ONION` command with `PoWDefensesE
...
(https://github.com/bitcoin/bitcoin/pull/33414)
Enable [PoW defenses](https://tpo.pages.torproject.net/onion-services/ecosystem/technology/security/pow/) for hidden services that we create via Tor Control using the [`ADD_ONION` command](https://spec.torproject.org/control-spec/commands.html#add_onion).
The ability to do that has been added in [tor-0.4.9.2-alpha](https://gitlab.torproject.org/tpo/core/tor/-/commit/02c18044464bfe45f168b55297a785244094cfd5). Previous versions return a syntax error to the `ADD_ONION` command with `PoWDefensesE
...
💬 fanquake commented on pull request "ci: re-add Valgrind job to the CI":
(https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302417796)
With `wallet_miniscript` skipped, this finishes faster than the ASAN job, and ~roughly the same time as msan & fuzzer.
(https://github.com/bitcoin/bitcoin/pull/33411#issuecomment-3302417796)
With `wallet_miniscript` skipped, this finishes faster than the ASAN job, and ~roughly the same time as msan & fuzzer.
📝 fanquake opened a pull request: "[28.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/33415)
Further backports for `28.x`.
(https://github.com/bitcoin/bitcoin/pull/33415)
Further backports for `28.x`.
💬 brunoerg commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2355204852)
@TheCharlatan I tried to run this target and got 0 exec/s which is pretty bad. I was expecting a bad performance due to the number of tasks and the pool overhead btw.
(https://github.com/bitcoin/bitcoin/pull/26966#discussion_r2355204852)
@TheCharlatan I tried to run this target and got 0 exec/s which is pretty bad. I was expecting a bad performance due to the number of tasks and the pool overhead btw.
💬 waketraindev commented on pull request "net: Provide block templates to peers on request":
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2355215514)
```suggestion
HelpExampleCli("gettemplateinfo", "")
```
Fix for rpc examples string
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2355215514)
```suggestion
HelpExampleCli("gettemplateinfo", "")
```
Fix for rpc examples string
💬 waketraindev commented on pull request "net: Provide block templates to peers on request":
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2355224390)
Prefer throwing an RPC exception here instead of returning default TemplateStats
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2355224390)
Prefer throwing an RPC exception here instead of returning default TemplateStats
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2355234167)
No, that's included in `sizeof(Cluster)` above.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2355234167)
No, that's included in `sizeof(Cluster)` above.
💬 TheCharlatan commented on pull request "RFC: Riscv bare metal CI job":
(https://github.com/bitcoin/bitcoin/pull/31425#issuecomment-3302609393)
Rebased a577bbe5df766a4e0e5a36fc997b7880eec45c0e -> e254de76ac0a390569bc5b561f61babb6d021dcb ([bare_metal_support_3](https://github.com/TheCharlatan/bitcoin/tree/bare_metal_support_3) -> [bare_metal_support_4](https://github.com/TheCharlatan/bitcoin/tree/bare_metal_support_4), [compare](https://github.com/TheCharlatan/bitcoin/compare/bare_metal_support_3..bare_metal_support_4))
(https://github.com/bitcoin/bitcoin/pull/31425#issuecomment-3302609393)
Rebased a577bbe5df766a4e0e5a36fc997b7880eec45c0e -> e254de76ac0a390569bc5b561f61babb6d021dcb ([bare_metal_support_3](https://github.com/TheCharlatan/bitcoin/tree/bare_metal_support_3) -> [bare_metal_support_4](https://github.com/TheCharlatan/bitcoin/tree/bare_metal_support_4), [compare](https://github.com/TheCharlatan/bitcoin/compare/bare_metal_support_3..bare_metal_support_4))
💬 sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2355242458)
I'd rather keep the external selector (`Level level`) and internal identifier (`int level`) separate, as it may allow adding more external ones later if need be (e.g. a `Level::SINGLE` which requires there to be only the main level and asserts otherwise, or a `Level::STAGING` which requires a staging level to exist). Also, if we'd add a third level (which may be needed to implement `testmempoolaccept` with package RBF) there may be even more level selectors to add.
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2355242458)
I'd rather keep the external selector (`Level level`) and internal identifier (`int level`) separate, as it may allow adding more external ones later if need be (e.g. a `Level::SINGLE` which requires there to be only the main level and asserts otherwise, or a `Level::STAGING` which requires a staging level to exist). Also, if we'd add a third level (which may be needed to implement `testmempoolaccept` with package RBF) there may be even more level selectors to add.
💬 TheCharlatan commented on pull request "log: always print initial signature verification state":
(https://github.com/bitcoin/bitcoin/pull/33336#issuecomment-3302633627)
Approach ACK
(https://github.com/bitcoin/bitcoin/pull/33336#issuecomment-3302633627)
Approach ACK
💬 ArmchairCryptologist commented on pull request "policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee":
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3302812634)
FWIW, one very well-connected node I have running with minrelaytxfee+incrementalrelayfee of 0.1 sats/vB has had 81.64% successful compact block reconstructions without any requested transactions in all of September, counting 2032 of 2489 blocks as of this writing. And of the remaining 457 blocks, 315 only requested a single transaction.
As far as I can tell, around 10% of nodes that report a minfeefilter are already using 0.1 sats/vB or less at this point, so it should improve rapidly.
(https://github.com/bitcoin/bitcoin/pull/33106#issuecomment-3302812634)
FWIW, one very well-connected node I have running with minrelaytxfee+incrementalrelayfee of 0.1 sats/vB has had 81.64% successful compact block reconstructions without any requested transactions in all of September, counting 2032 of 2489 blocks as of this writing. And of the remaining 457 blocks, 315 only requested a single transaction.
As far as I can tell, around 10% of nodes that report a minfeefilter are already using 0.1 sats/vB or less at this point, so it should improve rapidly.
💬 dergoegge commented on pull request "tor: enable PoW defenses for automatically created hidden services":
(https://github.com/bitcoin/bitcoin/pull/33414#issuecomment-3302853723)
Should we then also add PoW to the connections that we make to other nodes running behind hidden services?
(https://github.com/bitcoin/bitcoin/pull/33414#issuecomment-3302853723)
Should we then also add PoW to the connections that we make to other nodes running behind hidden services?
💬 ryanofsky commented on pull request "multiprocess: Don't require bitcoin -m argument when IPC options are used":
(https://github.com/bitcoin/bitcoin/pull/33229#issuecomment-3302921594)
Unfortunately this conflicted with #33407 due to cmake change on adjacent line, so needed to rebase.
<!-- begin push-25 -->
Rebased f9685d6a1389938b0cceb31d9eef201ab3dd2e86 -> 453b0fa286e5dce0af682b7b73684dd6415a50de ([`pr/ipc-auto.24`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-auto.24) -> [`pr/ipc-auto.25`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-auto.25), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-auto.24-rebase..pr/ipc-auto.25))<!-- end --> due to
...
(https://github.com/bitcoin/bitcoin/pull/33229#issuecomment-3302921594)
Unfortunately this conflicted with #33407 due to cmake change on adjacent line, so needed to rebase.
<!-- begin push-25 -->
Rebased f9685d6a1389938b0cceb31d9eef201ab3dd2e86 -> 453b0fa286e5dce0af682b7b73684dd6415a50de ([`pr/ipc-auto.24`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-auto.24) -> [`pr/ipc-auto.25`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-auto.25), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-auto.24-rebase..pr/ipc-auto.25))<!-- end --> due to
...