✅ pinheadmz closed an issue: "I am sharing 'OKX_1753235667059' with you"
(https://github.com/bitcoin/bitcoin/issues/33327)
(https://github.com/bitcoin/bitcoin/issues/33327)
💬 hebasto commented on pull request "Fix compatibility with `-debuglogfile` command-line option":
(https://github.com/bitcoin/bitcoin/pull/33215#discussion_r2328354097)
Thanks! Fixed.
(https://github.com/bitcoin/bitcoin/pull/33215#discussion_r2328354097)
Thanks! Fixed.
💬 hebasto commented on pull request "Fix compatibility with `-debuglogfile` command-line option":
(https://github.com/bitcoin/bitcoin/pull/33215#discussion_r2328354145)
Thanks! Fixed.
(https://github.com/bitcoin/bitcoin/pull/33215#discussion_r2328354145)
Thanks! Fixed.
💬 Raimo33 commented on pull request "refactor: unify container presence checks (without PR conflicts)":
(https://github.com/bitcoin/bitcoin/pull/33192#issuecomment-3263190690)
ACK f70d2c7faa8f7d724e146e4c409de9c6778b7299
This is a no brainer for me. It makes code easier to read and therefore mantain. Also, as already mentioned, for multisets and multimaps, `::contains` will avoid extra iterations with early exits.
The changes are relatively trivial so very little surface for subtle errors.
(https://github.com/bitcoin/bitcoin/pull/33192#issuecomment-3263190690)
ACK f70d2c7faa8f7d724e146e4c409de9c6778b7299
This is a no brainer for me. It makes code easier to read and therefore mantain. Also, as already mentioned, for multisets and multimaps, `::contains` will avoid extra iterations with early exits.
The changes are relatively trivial so very little surface for subtle errors.
📝 iajhff opened a pull request: "Mapping for Lockedpool"
(https://github.com/bitcoin/bitcoin/pull/33328)
support: Optimize LockedPool::free with O(log n) arena lookup
Replace O(n) linear search with O(log n) map-based lookup using
arena base addresses. Improves performance for frequent
allocation/deallocation patterns in wallet operations.
(https://github.com/bitcoin/bitcoin/pull/33328)
support: Optimize LockedPool::free with O(log n) arena lookup
Replace O(n) linear search with O(log n) map-based lookup using
arena base addresses. Improves performance for frequent
allocation/deallocation patterns in wallet operations.
💬 l0rinc commented on issue "-loadblock doesn't work":
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3263193876)
I'm not sure I can follow what versions you're using in the examples and what you're trying to achieve high level - could you please update the title and issue description and start with the zoomed out problem definition for what you're trying to achieve and what you tried and what versions you have used for which operation etc?
(https://github.com/bitcoin/bitcoin/issues/33280#issuecomment-3263193876)
I'm not sure I can follow what versions you're using in the examples and what you're trying to achieve high level - could you please update the title and issue description and start with the zoomed out problem definition for what you're trying to achieve and what you tried and what versions you have used for which operation etc?
💬 Raimo33 commented on pull request "crypto: optimize SipHash Write() method with chunked processing":
(https://github.com/bitcoin/bitcoin/pull/33325#issuecomment-3263344271)
I just realized somebody had my same idea on knots28. But in the latest version it got reset to match Core's implementation. 🤔.
https://github.com/Raimo33/bitcoinknots/commit/8463aef09fe4c6e3806e3b8a4c967c297302b96f
(https://github.com/bitcoin/bitcoin/pull/33325#issuecomment-3263344271)
I just realized somebody had my same idea on knots28. But in the latest version it got reset to match Core's implementation. 🤔.
https://github.com/Raimo33/bitcoinknots/commit/8463aef09fe4c6e3806e3b8a4c967c297302b96f
💬 Raimo33 commented on pull request "crypto: optimize SipHash Write() method with chunked processing":
(https://github.com/bitcoin/bitcoin/pull/33325#issuecomment-3263377003)
> We may be able to use more C++20 alignment-specific methods there (e.g. like the `std::assume_aligned` we used in
I tried with
```diff
- uint64_t chunk;
- std::memcpy(&chunk, ptr, 8);
+ auto aligned_ptr = std::assume_aligned<8>(ptr);
+ uint64_t chunk = *reinterpret_cast<const uint64_t *>(aligned_ptr);
```
but no luck. performance is identical. `memcpy` is extremely optimized.
(https://github.com/bitcoin/bitcoin/pull/33325#issuecomment-3263377003)
> We may be able to use more C++20 alignment-specific methods there (e.g. like the `std::assume_aligned` we used in
I tried with
```diff
- uint64_t chunk;
- std::memcpy(&chunk, ptr, 8);
+ auto aligned_ptr = std::assume_aligned<8>(ptr);
+ uint64_t chunk = *reinterpret_cast<const uint64_t *>(aligned_ptr);
```
but no luck. performance is identical. `memcpy` is extremely optimized.
💬 systemic-threat commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3263510323)
Concept NACK
I've educated myself on the issue.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3263510323)
Concept NACK
I've educated myself on the issue.
💬 stwenhao commented on issue "Potential systemic risk: OP_RETURN outputs as unintended governance signaling":
(https://github.com/bitcoin/bitcoin/issues/33323#issuecomment-3263529896)
The same things can be done without OP_RETURN. Even if you have P2PK-only, old, plain, ECDSA signatures, then still: they can commit to arbitrary data, through their R-values.
> Each UTXO could embed a short marker in its OP_RETURN.
Not only in OP_RETURN. Since miners started accepting out-of-band transactions, then different transaction versions can be used to signal things, just like they are used during soft-forks, to check, how many miners are ready to support some BIP.
> These markers co
...
(https://github.com/bitcoin/bitcoin/issues/33323#issuecomment-3263529896)
The same things can be done without OP_RETURN. Even if you have P2PK-only, old, plain, ECDSA signatures, then still: they can commit to arbitrary data, through their R-values.
> Each UTXO could embed a short marker in its OP_RETURN.
Not only in OP_RETURN. Since miners started accepting out-of-band transactions, then different transaction versions can be used to signal things, just like they are used during soft-forks, to check, how many miners are ready to support some BIP.
> These markers co
...
💬 ybaidiuk commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3263615631)
Gloria destroying bitcoin.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3263615631)
Gloria destroying bitcoin.
💬 maflcko commented on pull request "ci: Checkout latest merged pulls":
(https://github.com/bitcoin/bitcoin/pull/33303#discussion_r2328596111)
Not sure what your question is, can you link to logs that explain what you are observing and asking about?
(https://github.com/bitcoin/bitcoin/pull/33303#discussion_r2328596111)
Not sure what your question is, can you link to logs that explain what you are observing and asking about?
💬 maflcko commented on pull request "ci: Checkout latest merged pulls":
(https://github.com/bitcoin/bitcoin/pull/33303#discussion_r2328596193)
ah, restored doc
(https://github.com/bitcoin/bitcoin/pull/33303#discussion_r2328596193)
ah, restored doc
💬 maflcko commented on pull request "ci: Checkout latest merged pulls":
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3263622408)
(doc-only force push to restore the explanation)
(https://github.com/bitcoin/bitcoin/pull/33303#issuecomment-3263622408)
(doc-only force push to restore the explanation)
🤔 maflcko reviewed a pull request: "test/refactor: use test deque to avoid quadratic iteration"
(https://github.com/bitcoin/bitcoin/pull/33313#pullrequestreview-3194368277)
I don't think this will ever be a measurable difference, but it seems fine to change. (Left some comments)
(https://github.com/bitcoin/bitcoin/pull/33313#pullrequestreview-3194368277)
I don't think this will ever be a measurable difference, but it seems fine to change. (Left some comments)
💬 maflcko commented on pull request "test/refactor: use test deque to avoid quadratic iteration":
(https://github.com/bitcoin/bitcoin/pull/33313#discussion_r2328618853)
I am not sure if this needs a rename.
* Generally, we avoid putting the type name in the variable name
* This just says that there is a list of tests (what exact type the list has should not matter for the code)
* It creates a conflict with the other pull request
So it would be better to leave this as it was previously, or at least not include the exact type in the name.
(https://github.com/bitcoin/bitcoin/pull/33313#discussion_r2328618853)
I am not sure if this needs a rename.
* Generally, we avoid putting the type name in the variable name
* This just says that there is a list of tests (what exact type the list has should not matter for the code)
* It creates a conflict with the other pull request
So it would be better to leave this as it was previously, or at least not include the exact type in the name.
💬 maflcko commented on pull request "test/refactor: use test deque to avoid quadratic iteration":
(https://github.com/bitcoin/bitcoin/pull/33313#discussion_r2328614372)
i don't think this is right, as explained previously. This block of code is about `self.jobs`, which *is* a list, even after the changes here.
It is just a sanity check, so a shorter way to write it would be `assert(self.jobs) # Can not and must not be empty here`.
(https://github.com/bitcoin/bitcoin/pull/33313#discussion_r2328614372)
i don't think this is right, as explained previously. This block of code is about `self.jobs`, which *is* a list, even after the changes here.
It is just a sanity check, so a shorter way to write it would be `assert(self.jobs) # Can not and must not be empty here`.
⚠️ maflcko opened an issue: "Intermittent tsan CI timeout in p2p_1p1c_network.py", line 155, self.sync_mempools()"
(https://github.com/bitcoin/bitcoin/issues/33329)
https://github.com/bitcoin/bitcoin/actions/runs/17526806361/job/49778354104?pr=33303#step:9:17166:
```
2025-09-07T10:22:31.1900795Z [0;36m test 2025-09-07T10:22:26.326636Z TestFramework (ERROR): Unexpected exception [0m
2025-09-07T10:22:31.1900932Z [0;36m Traceback (most recent call last): [0m
2025-09-07T10:22:31.1901180Z [0;36m File "/home/admin/actions-runner/_work/_temp/test/functional/test_framework/test_framework.py
...
(https://github.com/bitcoin/bitcoin/issues/33329)
https://github.com/bitcoin/bitcoin/actions/runs/17526806361/job/49778354104?pr=33303#step:9:17166:
```
2025-09-07T10:22:31.1900795Z [0;36m test 2025-09-07T10:22:26.326636Z TestFramework (ERROR): Unexpected exception [0m
2025-09-07T10:22:31.1900932Z [0;36m Traceback (most recent call last): [0m
2025-09-07T10:22:31.1901180Z [0;36m File "/home/admin/actions-runner/_work/_temp/test/functional/test_framework/test_framework.py
...
💬 fanquake commented on issue "Intermittent tsan CI timeout in p2p_1p1c_network.py", line 155, self.sync_mempools()":
(https://github.com/bitcoin/bitcoin/issues/33329#issuecomment-3263695603)
Dupe of #33318?
(https://github.com/bitcoin/bitcoin/issues/33329#issuecomment-3263695603)
Dupe of #33318?
✅ maflcko closed an issue: "Intermittent tsan CI timeout in p2p_1p1c_network.py", line 155, self.sync_mempools()"
(https://github.com/bitcoin/bitcoin/issues/33329)
(https://github.com/bitcoin/bitcoin/issues/33329)