👍 fanquake approved a pull request: "Revert "depends: Fetch miniupnpc sources from an alternative website""
(https://github.com/bitcoin/bitcoin/pull/30603#pullrequestreview-2232604323)
ACK 4c2cc63d84dc1c8bae1b620f34188b7c20b70019 - please don't @ mention anyone in your pull request descriptions, otherwise they are likely to just get spammed with notifications.
(https://github.com/bitcoin/bitcoin/pull/30603#pullrequestreview-2232604323)
ACK 4c2cc63d84dc1c8bae1b620f34188b7c20b70019 - please don't @ mention anyone in your pull request descriptions, otherwise they are likely to just get spammed with notifications.
🚀 fanquake merged a pull request: "Revert "depends: Fetch miniupnpc sources from an alternative website""
(https://github.com/bitcoin/bitcoin/pull/30603)
(https://github.com/bitcoin/bitcoin/pull/30603)
📝 maflcko opened a pull request: "ci: Use clang-19 from apt.llvm.org"
(https://github.com/bitcoin/bitcoin/pull/30634)
A new clang version generally comes with bugfixes, new sanitizer features, as well as new features.
Upgrade the sanitizer tasks to use the new version.
A follow-up can explore if the tidy task, the msan tasks, or the valgrind tasks can also use a newer compiler version.
(https://github.com/bitcoin/bitcoin/pull/30634)
A new clang version generally comes with bugfixes, new sanitizer features, as well as new features.
Upgrade the sanitizer tasks to use the new version.
A follow-up can explore if the tidy task, the msan tasks, or the valgrind tasks can also use a newer compiler version.
📝 fanquake locked a pull request: "Revert "depends: Fetch miniupnpc sources from an alternative website""
(https://github.com/bitcoin/bitcoin/pull/30602)
This reverts commit 21b8a14d37c19ce292d5529597e0d52338db48a9.
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
s
...
(https://github.com/bitcoin/bitcoin/pull/30602)
This reverts commit 21b8a14d37c19ce292d5529597e0d52338db48a9.
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
s
...
📝 fanquake locked a pull request: "get miniupnpc from ssl, this reverts commit 21b8a14d37c19ce292d5529597e0d52338db48a9"
(https://github.com/bitcoin/bitcoin/pull/30564)
the tuxfamily mirror is back up, revert back to an SSL source
(https://github.com/bitcoin/bitcoin/pull/30564)
the tuxfamily mirror is back up, revert back to an SSL source
🚀 fanquake merged a pull request: "doc: Add note about distro's `g++-mingw-w64-x86-64-posix` version"
(https://github.com/bitcoin/bitcoin/pull/30580)
(https://github.com/bitcoin/bitcoin/pull/30580)
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#issuecomment-2283641349)
Rebased and restored signalling `g_best_block_cv` on shutdown.
I created `interfaces/types.h`, moved `BlockKey` there and renamed it to `BlockRef`. I then renamed `getTipHash()` to `getTip()` instead of adding `getTipHeight()`. `waitTipChanged` also returns a `BlockKey`.
Addressed inline comments, except that I still need to look into the tests.
(https://github.com/bitcoin/bitcoin/pull/30409#issuecomment-2283641349)
Rebased and restored signalling `g_best_block_cv` on shutdown.
I created `interfaces/types.h`, moved `BlockKey` there and renamed it to `BlockRef`. I then renamed `getTipHash()` to `getTip()` instead of adding `getTipHeight()`. `waitTipChanged` also returns a `BlockKey`.
Addressed inline comments, except that I still need to look into the tests.
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527845)
`getTip()` and `waitTipChanged()` now both return `BlockRef`.
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527845)
`getTip()` and `waitTipChanged()` now both return `BlockRef`.
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527921)
Done. I also simplified the `waitfornewblock` (etc) RPC call to just call getTip() and then pass that into `waitTipChanged`. That gets rid of `struct CUpdatedBlock`.
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527921)
Done. I also simplified the `waitfornewblock` (etc) RPC call to just call getTip() and then pass that into `waitTipChanged`. That gets rid of `struct CUpdatedBlock`.
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527986)
Done
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713527986)
Done
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528130)
I don't fully understand the original test either. Will look into it later.
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528130)
I don't fully understand the original test either. Will look into it later.
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528797)
I made a note to either add that argument in this PR or make a followup.
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528797)
I made a note to either add that argument in this PR or make a followup.
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528958)
I moved it to `StopRPC()`.
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713528958)
I moved it to `StopRPC()`.
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713529075)
Done
(https://github.com/bitcoin/bitcoin/pull/30409#discussion_r1713529075)
Done
💬 maprezentalok commented on issue ""heapleakdetection" entry in registry for bitcoin-qt.exe":
(https://github.com/bitcoin/bitcoin/issues/30629#issuecomment-2283688931)
Actually the hex LastDetectionTime translates to:
LDAP: 133626153101189582
Epoch/Unix time: 1718141710
GMT: 2024. June 11., Tuesday 21:35:10
so it cannot be v27.1 as it wasn't released yet, i used v27.0 at that time.
(https://github.com/bitcoin/bitcoin/issues/30629#issuecomment-2283688931)
Actually the hex LastDetectionTime translates to:
LDAP: 133626153101189582
Epoch/Unix time: 1718141710
GMT: 2024. June 11., Tuesday 21:35:10
so it cannot be v27.1 as it wasn't released yet, i used v27.0 at that time.
💬 agroce commented on issue "fuzz: `script`: Assertion `!extract_destination_ret' failed.":
(https://github.com/bitcoin/bitcoin/issues/30615#issuecomment-2283704534)
> I think we have a few harnesses that exit early if the input size is smaller or larger than expected, e.g.:
Not sure the equivalent in AFL++, but in libFuzzer (and Eclipser) for some targets really limiting the size of input gives the mutator a much better chance at finding lots of things. This is a good example of very different time-to-find depending on max_len. It might be a good idea to either add a (rare) config for targets with some appropriate "very short but long enough to be inte
...
(https://github.com/bitcoin/bitcoin/issues/30615#issuecomment-2283704534)
> I think we have a few harnesses that exit early if the input size is smaller or larger than expected, e.g.:
Not sure the equivalent in AFL++, but in libFuzzer (and Eclipser) for some targets really limiting the size of input gives the mutator a much better chance at finding lots of things. This is a good example of very different time-to-find depending on max_len. It might be a good idea to either add a (rare) config for targets with some appropriate "very short but long enough to be inte
...
💬 glozow commented on pull request "cluster mempool: optimized candidate search":
(https://github.com/bitcoin/bitcoin/pull/30286#discussion_r1713603196)
@sipa thanks this is really helpful, particularly this part:
> 4. anc(t) will always include at least one UL transaction (*)
> (*) The jump ahead is exactly what guarantees that anc(t) always includes a UL transaction. If anc(t) was entirely within UH, it would be topologically valid, and thus the parent work item's jump ahead step would have moved it to I already.
However I'm still having trouble with this part:
> Compare this to what happens in an exclusion branch ...
> 4. desc(t) m
...
(https://github.com/bitcoin/bitcoin/pull/30286#discussion_r1713603196)
@sipa thanks this is really helpful, particularly this part:
> 4. anc(t) will always include at least one UL transaction (*)
> (*) The jump ahead is exactly what guarantees that anc(t) always includes a UL transaction. If anc(t) was entirely within UH, it would be topologically valid, and thus the parent work item's jump ahead step would have moved it to I already.
However I'm still having trouble with this part:
> Compare this to what happens in an exclusion branch ...
> 4. desc(t) m
...
📝 Sjors opened a pull request: "rpc: add optional blockhash to waitfornewblock"
(https://github.com/bitcoin/bitcoin/pull/30635)
The `waitfornewblock` is inherently racy as the tip may have changed since the last RPC call, and can even change during initial processing of this call.
Add an optional `blockhash` argument so the called can specify their current tip. Return immediately if our tip is different.
I've made it fail if `LookupBlockIndex` fails. This should never happen if the user got the block hash from our RPC in the first place.
Builds on #30409.
(https://github.com/bitcoin/bitcoin/pull/30635)
The `waitfornewblock` is inherently racy as the tip may have changed since the last RPC call, and can even change during initial processing of this call.
Add an optional `blockhash` argument so the called can specify their current tip. Return immediately if our tip is different.
I've made it fail if `LookupBlockIndex` fails. This should never happen if the user got the block hash from our RPC in the first place.
Builds on #30409.
💬 0xB10C commented on issue "Intermittent failures in interface_usdt_mempool.py":
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-2283747252)
Thanks! Did a few CI run of https://github.com/0xB10C/bitcoin/commit/3d806eafa04415791b95ed20525eed2fd54f5b38. Your patch doesn't seem to improve the situation.
- Attempt 1 failed: https://github.com/0xB10C/bitcoin/actions/runs/10348240621/attempts/1 (test iteration 4/100)
- Attempt 2 failed: https://github.com/0xB10C/bitcoin/actions/runs/10348240621/attempts/2 (test iteration 18/100)
- Attempt 3 succeded: https://github.com/0xB10C/bitcoin/actions/runs/10348240621/attempts/3
- Attempt 4 su
...
(https://github.com/bitcoin/bitcoin/issues/27380#issuecomment-2283747252)
Thanks! Did a few CI run of https://github.com/0xB10C/bitcoin/commit/3d806eafa04415791b95ed20525eed2fd54f5b38. Your patch doesn't seem to improve the situation.
- Attempt 1 failed: https://github.com/0xB10C/bitcoin/actions/runs/10348240621/attempts/1 (test iteration 4/100)
- Attempt 2 failed: https://github.com/0xB10C/bitcoin/actions/runs/10348240621/attempts/2 (test iteration 18/100)
- Attempt 3 succeded: https://github.com/0xB10C/bitcoin/actions/runs/10348240621/attempts/3
- Attempt 4 su
...
💬 Sjors commented on pull request "Introduce waitTipChanged() mining interface, replace RPCNotifyBlockChange and drop CRPCSignals":
(https://github.com/bitcoin/bitcoin/pull/30409#issuecomment-2283747278)
As for race conditions with RPC calls that rely on `waitForBlock()`:
* `waitforblock [hash]`: the while loop breaks if `block.hash == hash`, which together with the early return inside `waitTipChanged` should prevent any blockage
* `waitforblockheight`: similar to `waitforblock`, the while loop checks `block.height >= height`
* `waitfornewblock`: I opened a draft PR to add an optional `blockhash` argument #30635
(https://github.com/bitcoin/bitcoin/pull/30409#issuecomment-2283747278)
As for race conditions with RPC calls that rely on `waitForBlock()`:
* `waitforblock [hash]`: the while loop breaks if `block.hash == hash`, which together with the early return inside `waitTipChanged` should prevent any blockage
* `waitforblockheight`: similar to `waitforblock`, the while loop checks `block.height >= height`
* `waitfornewblock`: I opened a draft PR to add an optional `blockhash` argument #30635