📝 achow101 locked a pull request: "v 25.0.3"
(https://github.com/bitcoin/bitcoin/pull/28135)
semgrep ci integration for security and optimized images with AI to reduce storage and enhance quality.
(https://github.com/bitcoin/bitcoin/pull/28135)
semgrep ci integration for security and optimized images with AI to reduce storage and enhance quality.
💬 ariard commented on pull request "policy: make unstructured annex standard":
(https://github.com/bitcoin/bitcoin/pull/27926#issuecomment-1647044629)
> I agree that use cases can help guide the decision making in this PR. That's why I created the demo/explanation mentioned in the PR description: https://github.com/joostjager/annex-covenants.
I understand how the spend transaction can be re-built from the `annex-covenant` stateless tool, and on my side I can opine on the interest of using the chain as a reliable backup fro critical information enabling vaulted funds to be rebuilt, only from standard tools.
I still have a concern on the e
...
(https://github.com/bitcoin/bitcoin/pull/27926#issuecomment-1647044629)
> I agree that use cases can help guide the decision making in this PR. That's why I created the demo/explanation mentioned in the PR description: https://github.com/joostjager/annex-covenants.
I understand how the spend transaction can be re-built from the `annex-covenant` stateless tool, and on my side I can opine on the interest of using the chain as a reliable backup fro critical information enabling vaulted funds to be rebuilt, only from standard tools.
I still have a concern on the e
...
📝 jonatack opened a pull request: "refactor: move GetServicesNames from rpc/util.{h,cpp} to rpc/net.cpp"
(https://github.com/bitcoin/bitcoin/pull/28136)
Move `GetServicesNames()` from `rpc/util.{h,cpp}` to `rpc/net.cpp`, as it is only called from that compilation unit and has no related functions where it is currently, which further allows not including `protocol.h` in that util lib.
This alleviates needlessly compiling both `GetServicesNames()` and the 500 lines of `protocol.h` in the 36 other files that include `rpc/util.h`.
(https://github.com/bitcoin/bitcoin/pull/28136)
Move `GetServicesNames()` from `rpc/util.{h,cpp}` to `rpc/net.cpp`, as it is only called from that compilation unit and has no related functions where it is currently, which further allows not including `protocol.h` in that util lib.
This alleviates needlessly compiling both `GetServicesNames()` and the 500 lines of `protocol.h` in the 36 other files that include `rpc/util.h`.
👋 jonatack's pull request is ready for review: "refactor: move GetServicesNames from rpc/util.{h,cpp} to rpc/net.cpp"
(https://github.com/bitcoin/bitcoin/pull/28136)
(https://github.com/bitcoin/bitcoin/pull/28136)
💬 MarcoFalke commented on issue "Bitcoin Core v25.0 Crashes":
(https://github.com/bitcoin/bitcoin/issues/28119#issuecomment-1647289947)
> Delete all files blk0009.dat and greater. Then also delete rev0009.dat and every rev*.dat with a greater number. This method is essentially will force you to redownload the corrupt file and every block after. This should work with certainty.
There is no need, nor recommendation, to do this manually. A simple `-reindex` (instead of `-reindex-chainstate`) is enough to do rewrite and check all block files on storage.
(https://github.com/bitcoin/bitcoin/issues/28119#issuecomment-1647289947)
> Delete all files blk0009.dat and greater. Then also delete rev0009.dat and every rev*.dat with a greater number. This method is essentially will force you to redownload the corrupt file and every block after. This should work with certainty.
There is no need, nor recommendation, to do this manually. A simple `-reindex` (instead of `-reindex-chainstate`) is enough to do rewrite and check all block files on storage.
💬 MarcoFalke commented on pull request "Remove C-style const-violating cast, Use reinterpret_cast":
(https://github.com/bitcoin/bitcoin/pull/28127#issuecomment-1647295139)
> Can clang-tidy or other tools be helpful in catching such cases in the future?
Yeah, you can use `cppcoreguidelines-pro-type-cstyle-cast` if you want. But that will produce some more warnings in places where a `const` is intentionally and correctly removed. Also, it will warn in some places that should use a `Span` instead. However, I think using `Span` in more places or other fixes can be left for follow-ups.
(https://github.com/bitcoin/bitcoin/pull/28127#issuecomment-1647295139)
> Can clang-tidy or other tools be helpful in catching such cases in the future?
Yeah, you can use `cppcoreguidelines-pro-type-cstyle-cast` if you want. But that will produce some more warnings in places where a `const` is intentionally and correctly removed. Also, it will warn in some places that should use a `Span` instead. However, I think using `Span` in more places or other fixes can be left for follow-ups.
💬 MarcoFalke commented on pull request "fuzz: Re-enable symbolize=1 in ASAN_OPTIONS":
(https://github.com/bitcoin/bitcoin/pull/28124#issuecomment-1647302661)
@emc99 Usually the issue tracker is used to track technical issues and code changes related to the Bitcoin Core code base. General (bitcoin) questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat.
(https://github.com/bitcoin/bitcoin/pull/28124#issuecomment-1647302661)
@emc99 Usually the issue tracker is used to track technical issues and code changes related to the Bitcoin Core code base. General (bitcoin) questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com) or the `#bitcoin` IRC channel on Libera Chat.
💬 russeree commented on issue "Bitcoin Core v25.0 Crashes":
(https://github.com/bitcoin/bitcoin/issues/28119#issuecomment-1647309700)
> > Delete all files blk0009.dat and greater. Then also delete rev0009.dat and every rev*.dat with a greater number. This method is essentially will force you to redownload the corrupt file and every block after. This should work with certainty.
>
> There is no need, nor recommendation, to do this manually. A simple `-reindex` (instead of `-reindex-chainstate`) is enough to do rewrite and check all block files on storage.
Does this still work if the actual disk sector is corrupt or would
...
(https://github.com/bitcoin/bitcoin/issues/28119#issuecomment-1647309700)
> > Delete all files blk0009.dat and greater. Then also delete rev0009.dat and every rev*.dat with a greater number. This method is essentially will force you to redownload the corrupt file and every block after. This should work with certainty.
>
> There is no need, nor recommendation, to do this manually. A simple `-reindex` (instead of `-reindex-chainstate`) is enough to do rewrite and check all block files on storage.
Does this still work if the actual disk sector is corrupt or would
...
💬 MarcoFalke commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1647312889)
> CircleCI looks better than others
Can you elaborate on this? The free plan would give less than 10 hours of macOS and Windows per month. And the paid plan doesn't look cheaper than Cirrus CI, does it?
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1647312889)
> CircleCI looks better than others
Can you elaborate on this? The free plan would give less than 10 hours of macOS and Windows per month. And the paid plan doesn't look cheaper than Cirrus CI, does it?
💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1647315920)
> > CircleCI looks better than others
>
> Can you elaborate on this? The free plan would give less than 10 hours of macOS and Windows per month. And the paid plan doesn't look cheaper than Cirrus CI, does it?
I've made comparison among available free plans. I did not consider paid plans in my comment.
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1647315920)
> > CircleCI looks better than others
>
> Can you elaborate on this? The free plan would give less than 10 hours of macOS and Windows per month. And the paid plan doesn't look cheaper than Cirrus CI, does it?
I've made comparison among available free plans. I did not consider paid plans in my comment.
💬 MarcoFalke commented on issue "Bitcoin Core v25.0 Crashes":
(https://github.com/bitcoin/bitcoin/issues/28119#issuecomment-1647323100)
> Does this still work if the actual disk sector is corrupt or would it still throw the fread failed: iostream error at FlatFilePos(nFile=9, nPos=53762556)
Good point. This may actually still fail. I wonder if it makes sense to change that to make `-reindex` skip on exceptions instead of shutting down.
(https://github.com/bitcoin/bitcoin/issues/28119#issuecomment-1647323100)
> Does this still work if the actual disk sector is corrupt or would it still throw the fread failed: iostream error at FlatFilePos(nFile=9, nPos=53762556)
Good point. This may actually still fail. I wonder if it makes sense to change that to make `-reindex` skip on exceptions instead of shutting down.
💬 MarcoFalke commented on pull request "Bugfix: RPC: Remove quotes from non-string oneline descriptions":
(https://github.com/bitcoin/bitcoin/pull/28123#discussion_r1271848468)
I've modified my suggestion. (Sorry, I don't compile them)
(https://github.com/bitcoin/bitcoin/pull/28123#discussion_r1271848468)
I've modified my suggestion. (Sorry, I don't compile them)
💬 MarcoFalke commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1647360046)
If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.
If the goal is to pay a similar amount as with the previous appveyor task, I think the only options are appveyor or travis.
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1647360046)
If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.
If the goal is to pay a similar amount as with the previous appveyor task, I think the only options are appveyor or travis.
💬 russeree commented on pull request "Bugfix: RPC: Remove quotes from non-string oneline descriptions":
(https://github.com/bitcoin/bitcoin/pull/28123#discussion_r1271859176)
No problem just was testing things. Compiles good but looks like a double quote on the end of the ```m_opts.oneline_description```.
The current PR displays correctly ```"options```
(https://github.com/bitcoin/bitcoin/pull/28123#discussion_r1271859176)
No problem just was testing things. Compiles good but looks like a double quote on the end of the ```m_opts.oneline_description```.
The current PR displays correctly ```"options```
💬 MarcoFalke commented on pull request "Bugfix: RPC: Remove quotes from non-string oneline descriptions":
(https://github.com/bitcoin/bitcoin/pull/28123#discussion_r1271871716)
It should be fine to just drop the `"`, as they serve no purpose. A newline already follows the message to delimit it from the next lines.
```diff
diff --git a/src/util/check.cpp b/src/util/check.cpp
index 795dce7124..c4d4b0cc28 100644
--- a/src/util/check.cpp
+++ b/src/util/check.cpp
@@ -18,7 +18,7 @@
std::string StrFormatInternalBug(std::string_view msg, std::string_view file, int line, std::string_view func)
{
- return strprintf("Internal bug detected: \"%s\"\n%s:%d (%s)\n"
...
(https://github.com/bitcoin/bitcoin/pull/28123#discussion_r1271871716)
It should be fine to just drop the `"`, as they serve no purpose. A newline already follows the message to delimit it from the next lines.
```diff
diff --git a/src/util/check.cpp b/src/util/check.cpp
index 795dce7124..c4d4b0cc28 100644
--- a/src/util/check.cpp
+++ b/src/util/check.cpp
@@ -18,7 +18,7 @@
std::string StrFormatInternalBug(std::string_view msg, std::string_view file, int line, std::string_view func)
{
- return strprintf("Internal bug detected: \"%s\"\n%s:%d (%s)\n"
...
👋 MarcoFalke's pull request is ready for review: "ci: Use qemu-user through container engine"
(https://github.com/bitcoin/bitcoin/pull/28087)
(https://github.com/bitcoin/bitcoin/pull/28087)
💬 MarcoFalke commented on pull request "ci: Use qemu-user through container engine":
(https://github.com/bitcoin/bitcoin/pull/28087#issuecomment-1647420555)
The arm task is now run by @DrahtBot, which should make it green
(https://github.com/bitcoin/bitcoin/pull/28087#issuecomment-1647420555)
The arm task is now run by @DrahtBot, which should make it green
💬 hebasto commented on pull request "kernel: Remove UniValue from kernel library":
(https://github.com/bitcoin/bitcoin/pull/28113#issuecomment-1647437043)
I've restarted the "Win64 native [vs2022]" CI task due to a remote Chocolatey issue.
(https://github.com/bitcoin/bitcoin/pull/28113#issuecomment-1647437043)
I've restarted the "Win64 native [vs2022]" CI task due to a remote Chocolatey issue.
📝 MarcoFalke reopened a pull request: "ci: Switch more tasks to self-hosted"
(https://github.com/bitcoin/bitcoin/pull/21652)
This is recommended by Cirrus CI to reduce the costs. See also https://github.com/bitcoin/bitcoin/issues/28098
(https://github.com/bitcoin/bitcoin/pull/21652)
This is recommended by Cirrus CI to reduce the costs. See also https://github.com/bitcoin/bitcoin/issues/28098
💬 glozow commented on pull request "validate package transactions with their in-package ancestor sets":
(https://github.com/bitcoin/bitcoin/pull/26711#issuecomment-1647523520)
> I'm starting to think that something closer to your idea here is right: trying ancestor sets of every transaction in the linearization in order, if the ancestor set feerate is suffiicently high. This indeed won't deal with multiple-children-pay-for-parent cases perfectly, but including everything connected may be too much as well.
> I don't think handling multiple-children-pay-for-parent cases perfectly should be a goal here
I agree that the non-ancestor-set-shaped submission is not some
...
(https://github.com/bitcoin/bitcoin/pull/26711#issuecomment-1647523520)
> I'm starting to think that something closer to your idea here is right: trying ancestor sets of every transaction in the linearization in order, if the ancestor set feerate is suffiicently high. This indeed won't deal with multiple-children-pay-for-parent cases perfectly, but including everything connected may be too much as well.
> I don't think handling multiple-children-pay-for-parent cases perfectly should be a goal here
I agree that the non-ancestor-set-shaped submission is not some
...