kernel: Streamline util library #29015

ryanofsky · 2023-12-06T22:26:39Z

Remove fees.h, errors.h, and spanparsing.h from the util library. Specifically:

Move Split functions from util/spanparsing.h to util/string.h, using util namespace for clarity.
Move remaining spanparsing functions to script/parsing.h since they are used for descriptor and miniscript parsing.
Combine util/fees.h and util/errors.h into common/messages.h so there is a place for simple functions that generate user messages to live, and these functions are not part of the util library.

Motivation for this change is that the util library is a dependency of the kernel, and we should remove functionality from util that shouldn't be called by kernel code or kernel applications. These changes should also improve code organization and make functions easier to discover. Some of these same moves are (or were) part of #28690, but did not help with code organization, or made it worse, so it is better to move them and clean them up in the same PR so code only has to change one time.

DrahtBot · 2023-12-06T22:26:42Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	TheCharlatan, hebasto
Concept ACK	Sjors

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#bitcoin-core/gui/599 (Translate unit names & fix external signer error by luke-jr)
#30214 (refactor: Improve assumeutxo state representation by ryanofsky)
#30212 (rename TransactionErrors: MISSING_INPUTS and ALREADY_IN_CHAIN by willcl-ark)
#30200 (Introduce Mining interface by Sjors)
#30157 (Fee Estimation via Fee rate Forecasters by ismaelsadeeq)
#30058 (Encapsulate warnings in generalized node::Warnings and remove globals by stickies-v)
#30043 (net: Replace libnatpmp with built-in PCP+NATPMP implementation by laanwj)
#29473 (refactor: Speed up Base58 encoding/decoding by 400%/200% via preliminary byte packing by paplorinc)
#29432 (Stratum v2 Template Provider (take 3) by Sjors)
#29415 (Broadcast own transactions only via short-lived Tor or I2P connections by vasild)
#29365 (Extend signetchallenge to set target block spacing by starius)
#29346 (Stratum v2 Noise Protocol by Sjors)
#29278 (Wallet: Add maxfeerate wallet startup option by ismaelsadeeq)
#28710 (Remove the legacy wallet and BDB dependency by achow101)
#22838 (descriptors: Be able to specify change and receiving in a single descriptor string by achow101)
#21283 (Implement BIP 370 PSBTv2 by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

ajtowns · 2023-12-07T03:13:25Z

Motivation for this change is that the util library is a dependency of the kernel, and we should remove functionality from util that shouldn't be called by kernel code or kernel applications.

Is the idea here that util should be for generic code, and that these bits and pieces (like fees and error) are specific bitcoin features that are only relevant to wallet/p2p, so aren't generic?

ryanofsky · 2023-12-07T23:23:00Z

Updated 0e64745 -> 778c021 (pr/rmutil.1 -> pr/rmutil.2, compare) fixing CI errors from forgitting to add new files to git

re: #29015 (comment)

Motivation for this change is that the util library is a dependency of the kernel, and we should remove functionality from util that shouldn't be called by kernel code or kernel applications.

Is the idea here that util should be for generic code, and that these bits and pieces (like fees and error) are specific bitcoin features that are only relevant to wallet/p2p, so aren't generic?

I do think that's generally a good thing to do, but it's not really the goal of this PR. The main thing this PR is trying to do is provide a better kernel API and reduce the size of the kernel library.

Because libbitcoin_kernel depends on libbitcoin_util, any external application using the kernel will also depend on util. So we should try to avoid including functions and types in util that are not likely to be useful to external applications, or are unstable and meant for internal use. The common library is usually a better place for these things.

ajtowns · 2023-12-07T23:58:39Z

Motivation for this change is that the util library is a dependency of the kernel, and we should remove functionality from util that shouldn't be called by kernel code or kernel applications.

Is the idea here that util should be for generic code, and that these bits and pieces (like fees and error) are specific bitcoin features that are only relevant to wallet/p2p, so aren't generic?

I do think that's generally a good thing to do, but it's not really the goal of this PR. The main thing this PR is trying to do is provide a better kernel API and reduce the size of the kernel library.

Does that mean that things should only go in util if they're going to be used by the kernel library then? That would presumably mean util/bitdeque.h and util/sock.cpp should also eventually go elsewhere, for example? That seems like a bad approach to me (in that it means code has to move into and out of util based on whether it's relevant to the kernel, rather than due to any changes to the code itself, and users then potentially have to deal with it moving into/outof the util:: namespace).

ryanofsky · 2023-12-08T00:53:49Z

Does that mean that things should only go in util if they're going to be used by the kernel library then?

No, I don't think so, and I don't think much else is going to move after this PR. I think only code that shouldn't be used by the kernel or kernel applications should be moved out of util, not just code that isn't used by the kernel. I agree just moving any code that isn't used by the kernel would be a bad approach, and wrote basically the same comment as you recently in #27989 (comment), so I think we are in agreement.

ryanofsky · 2023-12-08T18:23:04Z

Updated 778c021 -> 8b21f41 (pr/rmutil.2 -> pr/rmutil.3, compare) to fix clang-tidy error https://cirrus-ci.com/task/4602567305461760. Also switched to using declarations more places to avoid creating conflicts and make the PR easier to review
Updated 8b21f41 -> 8748d63 (pr/rmutil.3 -> pr/rmutil.4, compare) to fix another clang-tidy error https://cirrus-ci.com/task/4950555420786688 and making other small cleanups
Updated 8748d63 -> b234094 (pr/rmutil.4 -> pr/rmutil.5, compare) to try to fix another clang-tidy error

hebasto · 2023-12-10T11:20:33Z

@ryanofsky

#29015 (comment):

the util library is a dependency of the kernel, and we should remove functionality from util that shouldn't be called by kernel code or kernel applications.

#29015 (comment):

only code that shouldn't be used by the kernel or kernel applications should be moved out of util, not just code that isn't used by the kernel.

#27989 (comment):

I think util/ is a good home for general purpose code providing basic data structures and cross platform capabilities, and I think common/ is good home for project-specific code that needs to be shared between bitcoind, bitcoin-cli, and bitcoin-wallet.

Does it make sense to improve https://github.com/bitcoin/bitcoin/blob/master/doc/design/libraries.md by expressing the idea from the quotes above more clearly? As for now, it reads:

In general, if it is ever unclear whether it is better to add code to util or common, it is probably better to add it to common unless it is very generically useful or useful particularly to include in the kernel.

TheCharlatan · 2023-12-10T17:22:08Z

Re #29015 (comment)

Does it make sense to improve https://github.com/bitcoin/bitcoin/blob/master/doc/design/libraries.md by expressing the idea from the quotes above more clearly? As for now, it reads:

This seems like the right place to talk about the relationship between the util and kernel library. My work on the kernel library has been focusing on reducing its essence to validation code, pruning external dependencies, and stripping out as much system related functionality as possible. I think if the goal is to have the kernel be capable of running on as many platforms as possible, potentially beyond the number of platforms that Bitcoin Core is capable of today and extending into embedded environments, this last point becomes crucial.

Looking at the content of util it provides roughly two types of functionality: Utilities for basic data structures and their serialization, and cross-platform system related utilities, like file handling, threading, process handling, etc.

In my opinion, making the util library a proper dependency of the kernel should not introduce new cross-platform system-related content into the kernel library. Besides potentially limiting use cases of the kernel, providing cross-platform utilities beyond what the kernel strictly requires seems like a potentially unreasonable future maintenance burden. This would be contrary to our incremental process of creating a minimal kernel library.

The asterisk here is that some of the utilities that are not currently used by the kernel do not introduce new dependencies, since they entirely rely on code that is already used by the kernel. I also generally think that some utilities could remain in the util library even though they are not currently used by validation code. The criteria I propose for evaluating if modules should remain in util after this PR are:

The module is directly used by kernel code.
The module contains basic data structure utilities for interacting with kernel code.
The module does not contain system-related utilities that are not directly used by the kernel.
The module does not contain project-specific code that is not relevant to the kernel.
The module does not introduce new dependencies beyond the current dependencies of the kernel.

Looking at @hebasto's comment here, threadinterrupt.cpp and readwritefile.cpp would violate the 3rd criteria in my eyes, while the spanparsing and bytevectorhash modules could potentially remain in util.

Between this PR and #28690 I think it would be nice if common criteria for util would be defined and documented. All this said, I think it would be acceptable too if things were kept purposefully vague as they are now until the need for more concrete structures arises.

ajtowns · 2023-12-11T02:00:19Z

Would it make sense to just merge common into util; but have a "stripped" version of util available for the kernel, that excludes stuff that doesn't match the 5 points above? That way the difference is just at the build system level, it doesn't involve moving files around or moving code between namespaces...

Then the advice would be: (a) just put things in util, (b) but only add things to the "util-core" section of the build file when they're needed by the kernel; (c) keep things in the util:: namespace; (d) split stuff into different .h/.cpp files pretty aggressively?

That would imply a different approach for the util: move fees.h and error.h to common/messages.h commit here.

ryanofsky · 2023-12-11T16:37:24Z

re: #29015 (comment)

Would it make sense to just merge common into util; but have a "stripped" version of util available for the kernel

Idea to build util and util-core (or util-lite?) libraries is interesting, because then it would be easy to add/remove things from util library depending on whether the kernel needs them, and it would never require renaming anything. I could see this being useful in the future if util library started growing a lot and accumulating more features of over time.

But for now, IMO, just sticking with the current util/common separation and using the cleanup in this PR would organize things better and be less confusing than having two util versions, and it would require moving fewer things. Even though the libraries.md document is currently ambiguous, I think it should be pretty easy to remove the ambiguity here.

re: #29015 (comment)

The criteria I propose for evaluating if modules should remain in util after this PR are:

I think these are good rules if you replace "basic data structure utilities" with "basic utilities that to do not require outside dependencies", and also drop the 3rd rule. It seems like with the 3rd rule you are trying to make a distinction between "data structure utilities" and "system-related utilities", and I don't think it helps to draw a dividing line there.

ryanofsky · 2023-12-11T18:17:44Z

Added 1 commits b234094 -> 6d8cb4d (pr/rmutil.5 -> pr/rmutil.6, compare) updating libraries.md to describe differences between util and common libraries better.

re: #29015 (comment)

My work on the kernel library has been focusing on reducing its essence to validation code, pruning external dependencies, and stripping out as much system related functionality as possible.
[...]
In my opinion, making the util library a proper dependency of the kernel should not introduce new cross-platform system-related content into the kernel library.

Just to address these points directly, I think the goals of making the kernel portable and working on any platform, and making the kernel minimal working and in constrained environments are great goals. I just don't you need to rm src/util/sock.cpp to achieve these goals. As long as the util library is distributed as a static library, or built as a static library and linked into a dynamic library, the socket functions will not be part of resulting executables if they are not called. And if the kernel is being built for a platform which doesn't support sockets at all, src/util/sock.cpp can just be stubbed or not compiled at all and there should be no problem for portability either. I do think it's good to keep the util library small and lightweight and remove things which don't fit there. But I don't think it needs to be stripped down in a more extreme way.

TheCharlatan · 2023-12-11T20:40:18Z

Re #29015 (comment)

And if the kernel is being built for a platform which doesn't support sockets at all, src/util/sock.cpp can just be stubbed or not compiled at all and there should be no problem for portability either.

One of the guiding principles for the kernel project so far has been to prohibit future re-couplings of decoupled modules. The tracking issue says "Any further coupling of our consensus engine with non-consensus modules will result in linker errors, preventing this project from becoming a Sisyphean task of battling coupling regressions.". How could this fit in with leaving unused content in the library?

ryanofsky · 2023-12-11T22:08:52Z

One of the guiding principles for the kernel project so far has been to prohibit future re-couplings of decoupled modules.

I reread the issue you linked to, but I don't understand what it implies here. I do think you can rely on linker errors to ensure kernel code isn't calling wallet code or GUI code or P2P code or storing state in global variables. But what else do you want beyond that? And how does removing sock.cpp from the util library help, for example?

ajtowns

Okay, I think I'm on roughly the same page:

keeping Split in util make sense
moving our string stuff into the util namespace seems fine * moving the spanparsing stuff to script mostly makes sense -- though I feel a bit like mixing consensus critical script manipulation and miniscript/descriptor parsing in the same namespace is a bit clunky?
moving fees.h/error.h to "common" makes sense; though if we can make "common" just be a broader part of "util" that seems better long term.
moving TransactionError into node rather than common doesn't make sense to me though

ajtowns · 2023-12-11T23:01:31Z

doc/design/libraries.md

@@ -87,14 +88,15 @@ class bitcoin-qt,bitcoind,bitcoin-cli,bitcoin-wallet bold

 - *libbitcoin_consensus* should be a standalone dependency that any library can depend on, and it should not depend on any other libraries itself.

- *libbitcoin_util* should also be a standalone dependency that any library can depend on, and it should not depend on other internal libraries.
+- *libbitcoin_crypto* should be a standalone dependency that any library can depend on, and it should not depend on any other libraries itself. (It is not shown in diagram above to save space, but has the exact same connections as *libbitcoin_consensus*, which is shown.)


Doesn't libconsensus necessarily depend on libcrypto (for sha256 at least)?

re: #29015 (comment)

Doesn't libconsensus necessarily depend on libcrypto (for sha256 at least)?

Yes that should be right. I think I just deluded myself because I didn't want to update the mermaid diagram. Updated now though.

src/node/types.h

TheCharlatan · 2023-12-12T08:20:13Z

Re #29015 (comment)

But what else do you want beyond that? And how does removing sock.cpp from the util library help, for example?

Maybe removing sock.cpp is a bad example, since it is already impossible to link against it. sock.cpp uses modules that are already not part of the kernel, so trying to link it in will result in errors. Then again, if sock.cpp uses common modules, why is it in util in the first place? To provide another concrete example, there is thread.cpp, which I was hoping to remove from the kernel in #28960. If it is removed, how could the kernel library be guarded from its future re-introduction if it remains in the util library?

DrahtBot · 2024-05-16T17:49:09Z

🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the
documentation.

Possibly this is due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.

Leave a comment here, if you need help tracking down a confusing failure.

_{Debug: https://github.com/bitcoin/bitcoin/runs/25060059418}

hebasto · 2024-05-16T20:03:30Z

There seems to be a conflict with #30098. Maybe rebase?

ryanofsky · 2024-05-17T01:50:36Z

There seems to be a conflict with #30098. Maybe rebase?

Thanks! Rebased now.

If other reviewers or maintainers are not happy with introducing a bash script, I could volunteer some time to translate it.

Yes this could be a good idea. The script started out just being a few lines of bash listing symbols exported by one library and imported by another one. But then it grew as it was extended to support multiple libraries and suppress known errors. So now it's no longer a small script, though it is pretty clean and well commented. Other possible followups besides translating the script could be:

Running the script as part of CI
Cleaning up unexpected dependencies listed as suppressions in the script.

Rebased 7689dfd -> 1c26d10 (pr/rmutil.18 -> pr/rmutil.19, compare) due to silent conflict with #30098

TheCharlatan

Re-ACK 1c26d10

hebasto

re-ACK 1c26d10.

hebasto · 2024-05-21T12:21:39Z

My Guix build:

07318f5568a25cf18d6ec29d8fbaba3adc9ddfa23891fbb62d63e136b5d25c7f  guix-build-1c26d10b23bb/output/aarch64-linux-gnu/SHA256SUMS.part
acbc7851322d559b96cca83764ef32f6e7df0f2449b1ca951a54127efea8eaf3  guix-build-1c26d10b23bb/output/aarch64-linux-gnu/bitcoin-1c26d10b23bb-aarch64-linux-gnu-debug.tar.gz
c94cdf25eab02a297f5b25fed2211cf0b35f2b1b6c7d48b154f2ed46720b9abb  guix-build-1c26d10b23bb/output/aarch64-linux-gnu/bitcoin-1c26d10b23bb-aarch64-linux-gnu.tar.gz
2a7aca0c44b234af3f4395591e78e41e06309c9b9a8a9f5e8f68d248b7a45162  guix-build-1c26d10b23bb/output/arm-linux-gnueabihf/SHA256SUMS.part
a741202ad3a1df852035111b20a102fa72b411245b735f330826d908490fdd64  guix-build-1c26d10b23bb/output/arm-linux-gnueabihf/bitcoin-1c26d10b23bb-arm-linux-gnueabihf-debug.tar.gz
068a9b730c1e59449e9b2d52e87df8009fdd33e210c3b02e52d4ec677b9c5f78  guix-build-1c26d10b23bb/output/arm-linux-gnueabihf/bitcoin-1c26d10b23bb-arm-linux-gnueabihf.tar.gz
1fbb2927be3f4f52c46f303f71755f3af7617cdb1ca3988a0bfe7827e743b500  guix-build-1c26d10b23bb/output/arm64-apple-darwin/SHA256SUMS.part
ab004b44ec36a2cb1cc051eed74e4f36026719a452729a0f2ffc74c52164aded  guix-build-1c26d10b23bb/output/arm64-apple-darwin/bitcoin-1c26d10b23bb-arm64-apple-darwin-unsigned.tar.gz
98eb503f1b9d97da2478b7e31b6a6ce54c1d9080cf06f45f5aa1de552ce01805  guix-build-1c26d10b23bb/output/arm64-apple-darwin/bitcoin-1c26d10b23bb-arm64-apple-darwin-unsigned.zip
b4006d722cd71fa709919e7d05f35e4970270ae8369b7e4dc6fd7ea603e73d84  guix-build-1c26d10b23bb/output/arm64-apple-darwin/bitcoin-1c26d10b23bb-arm64-apple-darwin.tar.gz
6a099c53eb043f9cf122497ccfb3822acd4d65a04d7110c1aafbc879d3c5856c  guix-build-1c26d10b23bb/output/dist-archive/bitcoin-1c26d10b23bb.tar.gz
8d9a43ca5f80a71d0c835d61d0beab25565229492fa4fee46e8ec178e00cb658  guix-build-1c26d10b23bb/output/powerpc64-linux-gnu/SHA256SUMS.part
a812d1b8de12d93cc569a89e2420ccc368c8c0ba3b715b13f6ef3fb6b1e1a535  guix-build-1c26d10b23bb/output/powerpc64-linux-gnu/bitcoin-1c26d10b23bb-powerpc64-linux-gnu-debug.tar.gz
e15e92cf6f4cceaed18546255bc362f52cd9ce35dbe676cb57ebee9c883e3180  guix-build-1c26d10b23bb/output/powerpc64-linux-gnu/bitcoin-1c26d10b23bb-powerpc64-linux-gnu.tar.gz
5f874fbe6e466e0b153b082f77b051b93856ccdf212f2ebf81229ff5668656cf  guix-build-1c26d10b23bb/output/riscv64-linux-gnu/SHA256SUMS.part
b30c16dd59a2152130c4d04a23426c77d73af4db1e68b56f61e74c23cbe0b74e  guix-build-1c26d10b23bb/output/riscv64-linux-gnu/bitcoin-1c26d10b23bb-riscv64-linux-gnu-debug.tar.gz
598c942f47a3b32062503fa0a1909eba08603c2437984f681c8948a76eedecd7  guix-build-1c26d10b23bb/output/riscv64-linux-gnu/bitcoin-1c26d10b23bb-riscv64-linux-gnu.tar.gz
f6cbd80a3170d9bfe3df6db7ad6c45a7edf5999d56faf5881917bd2046c659b2  guix-build-1c26d10b23bb/output/x86_64-apple-darwin/SHA256SUMS.part
86c261ee89e1c61a95ed3b90d6547be579ead16d93f56aba5eebeb8ce282c897  guix-build-1c26d10b23bb/output/x86_64-apple-darwin/bitcoin-1c26d10b23bb-x86_64-apple-darwin-unsigned.tar.gz
81b44a879c6982f05a02633a939fd96083f7c59cf34429b3c9d916a32ade1dd9  guix-build-1c26d10b23bb/output/x86_64-apple-darwin/bitcoin-1c26d10b23bb-x86_64-apple-darwin-unsigned.zip
8b76c441ca2fc11573785b2fae007fff2dcae65c8f2cd2fd517e8c4e9dacc086  guix-build-1c26d10b23bb/output/x86_64-apple-darwin/bitcoin-1c26d10b23bb-x86_64-apple-darwin.tar.gz
eae30d8ecc90e29913653fe41634836c36e7fea89c09c22c3b05945c2c30fbbe  guix-build-1c26d10b23bb/output/x86_64-linux-gnu/SHA256SUMS.part
30a74515f8078a81968fd97b723b56d6331f45cd9b104a35d73559ee99666940  guix-build-1c26d10b23bb/output/x86_64-linux-gnu/bitcoin-1c26d10b23bb-x86_64-linux-gnu-debug.tar.gz
bf59e96c6b5b2033a84c2bfa29b97c3972827cb6edcbc484935dd0e9a7b2c28a  guix-build-1c26d10b23bb/output/x86_64-linux-gnu/bitcoin-1c26d10b23bb-x86_64-linux-gnu.tar.gz
0241585f8314adfc7a57bd988199bf2bd0b0cdb2f1b91b0aa9c1b03af1dfa6bd  guix-build-1c26d10b23bb/output/x86_64-w64-mingw32/SHA256SUMS.part
44556b4c3e7140c5d8df64b07b491daa3eef2851b23d19963eb89a48c66adb50  guix-build-1c26d10b23bb/output/x86_64-w64-mingw32/bitcoin-1c26d10b23bb-win64-debug.zip
eb1e6368638f754af7980dd46e3482c9430604df451e819777727b9ad0720fc3  guix-build-1c26d10b23bb/output/x86_64-w64-mingw32/bitcoin-1c26d10b23bb-win64-setup-unsigned.exe
8e2137350f44640bbff5b97216d37673062dbb89f2b3985cb377effc75327e7f  guix-build-1c26d10b23bb/output/x86_64-w64-mingw32/bitcoin-1c26d10b23bb-win64-unsigned.tar.gz
18380b999dfb5eb2b6a8784335553039df4ac3c773b1869e504d22c155ae90bd  guix-build-1c26d10b23bb/output/x86_64-w64-mingw32/bitcoin-1c26d10b23bb-win64.zip

DrahtBot · 2024-05-22T14:39:56Z

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

File	commit `a786fd2` (master)	commit `d1893f6` (master and this pull)
SHA256SUMS.part	`14f282b5bf7ebcd4...`	`6b8304534f742d40...`
*-aarch64-linux-gnu-debug.tar.gz	`b2364625629230d1...`	`7236fe91743fee41...`
*-aarch64-linux-gnu.tar.gz	`b05fc0561baa0966...`	`816af5636f1f4755...`
*-arm-linux-gnueabihf-debug.tar.gz	`4545637daf89882c...`	`71186e35ede72b81...`
*-arm-linux-gnueabihf.tar.gz	`27115f4c7e251175...`	`322e8aa674f6b0aa...`
*-arm64-apple-darwin-unsigned.tar.gz	`cf3950f9d05fb1c0...`	`916b86c91919cf3b...`
*-arm64-apple-darwin-unsigned.zip	`b1c32e004722a3b4...`	`ae490ec387351537...`
*-arm64-apple-darwin.tar.gz	`f09a38acef4b141b...`	`6ecf573cf6708073...`
*-powerpc64-linux-gnu-debug.tar.gz	`75cfe8d73120b00d...`	`477191c62a748459...`
*-powerpc64-linux-gnu.tar.gz	`d4f8c1296886fac4...`	`f081bfeafe7e82b8...`
*-riscv64-linux-gnu-debug.tar.gz	`a8f56aee14e85f29...`	`55992dd6815ca3b5...`
*-riscv64-linux-gnu.tar.gz	`d8a4ae4295e6aa9f...`	`0d3d859cc90faa23...`
*-x86_64-apple-darwin-unsigned.tar.gz	`ff9ae232120c85f9...`	`6b0af8e6122b564c...`
*-x86_64-apple-darwin-unsigned.zip	`9917159a6fd59954...`	`3b4bf085de74d320...`
*-x86_64-apple-darwin.tar.gz	`61112274cace86c4...`	`cee59c641c8de378...`
*-x86_64-linux-gnu-debug.tar.gz	`557d05bc585a2910...`	`6a76262d04675700...`
*-x86_64-linux-gnu.tar.gz	`4928355769a494d7...`	`738635ffec7a993a...`
*.tar.gz	`49c2acd89613cf65...`	`297752c33bf58704...`
guix_build.log	`88d5371b29f8bb75...`	`a238cef1d7cbedfc...`
guix_build.log.diff		`b3866f990e369152...`

DrahtBot · 2024-06-02T17:48:25Z

🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the
documentation.

Possibly this is due to a silent merge conflict (the changes in this pull request being
incompatible with the current code in the target branch). If so, make sure to rebase on the latest
commit of the target branch.

Leave a comment here, if you need help tracking down a confusing failure.

_{Debug: https://github.com/bitcoin/bitcoin/runs/25080673770}

achow101 · 2024-06-05T00:00:35Z

CI failure suggests there's a silent merge conflict.

TheCharlatan

Re-ACK c7376ba

hebasto

re-ACK c7376ba.

My Guix build:

x86_64
f33ae90e6d190245d34712f544cd458f282a2c90890029dfbd88d74e8823fb50  guix-build-c7376babd19d/output/aarch64-linux-gnu/SHA256SUMS.part
ee444d54e0b9cebfa6ab0c91fc8b543d414a98338d46d299f3b302273139c81f  guix-build-c7376babd19d/output/aarch64-linux-gnu/bitcoin-c7376babd19d-aarch64-linux-gnu-debug.tar.gz
fdc7400c04fd6bfec5d0ab3148b0f4da110974ecda0859184adad29f38422f6f  guix-build-c7376babd19d/output/aarch64-linux-gnu/bitcoin-c7376babd19d-aarch64-linux-gnu.tar.gz
9ef394d81127cf5ee2eb64508feb0a96f72763073fe0ed9a0901d6008e51b2b8  guix-build-c7376babd19d/output/arm-linux-gnueabihf/SHA256SUMS.part
40cec39c64338a03e7553bb9734d48061d5d1669ab6a59d6250d0dcd5821fde0  guix-build-c7376babd19d/output/arm-linux-gnueabihf/bitcoin-c7376babd19d-arm-linux-gnueabihf-debug.tar.gz
acc8be16daaecab8fdf96763973b8fe7e3e5e9e8014e1e04cf9133cba9f55375  guix-build-c7376babd19d/output/arm-linux-gnueabihf/bitcoin-c7376babd19d-arm-linux-gnueabihf.tar.gz
791971a7afaef6827d3a2b4da5f92a10aa28ff906efd372ef524b900c6815ba7  guix-build-c7376babd19d/output/arm64-apple-darwin/SHA256SUMS.part
bad59a9c07844fa7b788a8b17063c950fa6e124e046d1bee02959344438350dd  guix-build-c7376babd19d/output/arm64-apple-darwin/bitcoin-c7376babd19d-arm64-apple-darwin-unsigned.tar.gz
41de8c1590fc2479ac52946f61affcc592fa7c187abcef02972933e91487ff73  guix-build-c7376babd19d/output/arm64-apple-darwin/bitcoin-c7376babd19d-arm64-apple-darwin-unsigned.zip
b4e834ae5e563d3cf975a0bc5cae1ba9734b19df387eddc45677f910b8bb5043  guix-build-c7376babd19d/output/arm64-apple-darwin/bitcoin-c7376babd19d-arm64-apple-darwin.tar.gz
5d2928dc2f3b6c5390a2020221f1f069bb4c0b0acff09c0d2c79b35ef486b5c9  guix-build-c7376babd19d/output/dist-archive/bitcoin-c7376babd19d.tar.gz
4b8e4f59977136e23ae0dc20816a671257cee4156d80551cbe1c27024857e8f2  guix-build-c7376babd19d/output/powerpc64-linux-gnu/SHA256SUMS.part
d5ce1a3593408c9eb7d1f2fc3d61e7d400381335faeca5cc6be11999c798e4c6  guix-build-c7376babd19d/output/powerpc64-linux-gnu/bitcoin-c7376babd19d-powerpc64-linux-gnu-debug.tar.gz
e11a741a82205faa1c271aa62f5a20329cf46c30db46bda37ed25dc83cbca662  guix-build-c7376babd19d/output/powerpc64-linux-gnu/bitcoin-c7376babd19d-powerpc64-linux-gnu.tar.gz
6ddd58c3fe5e4c600a65b5b9e4bb7e0b99bd3cd5f8655366bb0e29e498e480fe  guix-build-c7376babd19d/output/riscv64-linux-gnu/SHA256SUMS.part
c35ab4f03e23c3889fac7c1a3a64d979af00cb762f6425599149249e8df7e4fd  guix-build-c7376babd19d/output/riscv64-linux-gnu/bitcoin-c7376babd19d-riscv64-linux-gnu-debug.tar.gz
f46bee10789cb0d2f1df0a386b93ebf92ecbd9faaf3446b2df8dc1c5fa77e46c  guix-build-c7376babd19d/output/riscv64-linux-gnu/bitcoin-c7376babd19d-riscv64-linux-gnu.tar.gz
5ba9da03a94da08d34d20edff2d9dd1de729f4087897d3573d5a17fbb053f0d7  guix-build-c7376babd19d/output/x86_64-apple-darwin/SHA256SUMS.part
4b0a6d20c60ff4bfb85bb143b13b0ad28f9c65d536cdbda96b695abf03a0d268  guix-build-c7376babd19d/output/x86_64-apple-darwin/bitcoin-c7376babd19d-x86_64-apple-darwin-unsigned.tar.gz
9525e7082ae7c691381af6abff1a1733b7a2efd772ffbe9bbd98cb522cd8609d  guix-build-c7376babd19d/output/x86_64-apple-darwin/bitcoin-c7376babd19d-x86_64-apple-darwin-unsigned.zip
a62eb1faf7a413267aab397e0c687016a2055f225f5a07d2780eaa7678e0260e  guix-build-c7376babd19d/output/x86_64-apple-darwin/bitcoin-c7376babd19d-x86_64-apple-darwin.tar.gz
70ec027a5d59eefeedf1943c96504d39739753f367442211d0353512b1ac798d  guix-build-c7376babd19d/output/x86_64-linux-gnu/SHA256SUMS.part
793c670bbd8724271c4966cbcffae13a9c876821aeee9ede7449e705acd463e7  guix-build-c7376babd19d/output/x86_64-linux-gnu/bitcoin-c7376babd19d-x86_64-linux-gnu-debug.tar.gz
4c711b6709ee78686f83296bb1e2596772d103cf4fc9959b50085a7d62652921  guix-build-c7376babd19d/output/x86_64-linux-gnu/bitcoin-c7376babd19d-x86_64-linux-gnu.tar.gz
3562a253c9bc448238aad4bb612c73f4fef6899ef297967b4a77b46fab40e73d  guix-build-c7376babd19d/output/x86_64-w64-mingw32/SHA256SUMS.part
3ae8eb90a5dd6fb50caf0f3df16bc0cb60646d1a126a45b89a70bc5d12d00ec4  guix-build-c7376babd19d/output/x86_64-w64-mingw32/bitcoin-c7376babd19d-win64-debug.zip
23f8f28cc9bb4c63d4c4420d8ccf5c0b2547c34b0ebf4b73b10d3553e7fc3681  guix-build-c7376babd19d/output/x86_64-w64-mingw32/bitcoin-c7376babd19d-win64-setup-unsigned.exe
c709e3dbcf3267a6f18ca984b8308bf7f05d58ddbbae83ae9e024db84693a861  guix-build-c7376babd19d/output/x86_64-w64-mingw32/bitcoin-c7376babd19d-win64-unsigned.tar.gz
2cf7011773d95db8398fdb538a5650eb3abd443c2fc18ea091ab07059c778eaf  guix-build-c7376babd19d/output/x86_64-w64-mingw32/bitcoin-c7376babd19d-win64.zip

DrahtBot added the Validation label Dec 6, 2023

ryanofsky mentioned this pull request Dec 6, 2023

build: Introduce internal kernel library #28690

Draft

DrahtBot added the CI failed label Dec 6, 2023

DrahtBot mentioned this pull request Dec 7, 2023

[WIP] Cluster mempool implementation #28676

Draft

8 tasks

ryanofsky force-pushed the pr/rmutil branch from 0e64745 to 778c021 Compare December 7, 2023 23:09

ryanofsky force-pushed the pr/rmutil branch from 778c021 to 8b21f41 Compare December 8, 2023 17:39

ryanofsky force-pushed the pr/rmutil branch 2 times, most recently from 8748d63 to b234094 Compare December 8, 2023 19:47

DrahtBot removed the CI failed label Dec 8, 2023

ajtowns reviewed Dec 11, 2023

View reviewed changes

pablomartin4btc mentioned this pull request May 16, 2024

refactor: interfaces, make 'createTransaction' less error-prone bitcoin-core/gui#807

Open

ryanofsky force-pushed the pr/rmutil branch from 7689dfd to 1c26d10 Compare May 17, 2024 01:20

DrahtBot removed the CI failed label May 17, 2024

TheCharlatan approved these changes May 17, 2024

View reviewed changes

DrahtBot requested a review from hebasto May 17, 2024 08:33

hebasto approved these changes May 17, 2024

View reviewed changes

maflcko added Build system DrahtBot Guix build requested and removed Validation labels May 17, 2024

DrahtBot removed the DrahtBot Guix build requested label May 22, 2024

This was referenced May 23, 2024

Fee Estimation via Fee rate Forecasters #30157

Draft

Encapsulate warnings in generalized node::Warnings and remove globals #30058

Open

net: Replace libnatpmp with built-in PCP+NATPMP implementation #30043

Open

This was referenced May 31, 2024

Enhance signet chain configuration in bitcoin.conf #30203

Draft

Introduce Mining interface #30200

Open

refactor: Improve assumeutxo state representation #30214

Open

rename TransactionErrors: MISSING_INPUTS and ALREADY_IN_CHAIN #30212

Open

DrahtBot added the CI failed label Jun 2, 2024

ryanofsky force-pushed the pr/rmutil branch from 1c26d10 to c7376ba Compare June 5, 2024 18:51

TheCharlatan approved these changes Jun 5, 2024

View reviewed changes

DrahtBot requested a review from hebasto June 5, 2024 21:01

DrahtBot removed the CI failed label Jun 5, 2024

hebasto approved these changes Jun 6, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

kernel: Streamline util library #29015

kernel: Streamline util library #29015

ryanofsky commented Dec 6, 2023

DrahtBot commented Dec 6, 2023 •

edited

ajtowns commented Dec 7, 2023

ryanofsky commented Dec 7, 2023

ajtowns commented Dec 7, 2023

ryanofsky commented Dec 8, 2023 •

edited

ryanofsky commented Dec 8, 2023 •

edited

hebasto commented Dec 10, 2023

TheCharlatan commented Dec 10, 2023

ajtowns commented Dec 11, 2023

ryanofsky commented Dec 11, 2023 •

edited

ryanofsky commented Dec 11, 2023

TheCharlatan commented Dec 11, 2023

ryanofsky commented Dec 11, 2023

ajtowns left a comment

ajtowns Dec 11, 2023

ryanofsky Dec 12, 2023

TheCharlatan commented Dec 12, 2023

DrahtBot commented May 16, 2024

hebasto commented May 16, 2024

ryanofsky commented May 17, 2024

TheCharlatan left a comment

hebasto left a comment

hebasto commented May 21, 2024

DrahtBot commented May 22, 2024

DrahtBot commented Jun 2, 2024

achow101 commented Jun 5, 2024

TheCharlatan left a comment

hebasto left a comment

kernel: Streamline util library #29015

Are you sure you want to change the base?

kernel: Streamline util library #29015

Conversation

ryanofsky commented Dec 6, 2023

DrahtBot commented Dec 6, 2023 • edited

Code Coverage

Reviews

Conflicts

ajtowns commented Dec 7, 2023

ryanofsky commented Dec 7, 2023

ajtowns commented Dec 7, 2023

ryanofsky commented Dec 8, 2023 • edited

ryanofsky commented Dec 8, 2023 • edited

hebasto commented Dec 10, 2023

TheCharlatan commented Dec 10, 2023

ajtowns commented Dec 11, 2023

ryanofsky commented Dec 11, 2023 • edited

ryanofsky commented Dec 11, 2023

TheCharlatan commented Dec 11, 2023

ryanofsky commented Dec 11, 2023

ajtowns left a comment

Choose a reason for hiding this comment

ajtowns Dec 11, 2023

Choose a reason for hiding this comment

ryanofsky Dec 12, 2023

Choose a reason for hiding this comment

TheCharlatan commented Dec 12, 2023

DrahtBot commented May 16, 2024

hebasto commented May 16, 2024

ryanofsky commented May 17, 2024

TheCharlatan left a comment

Choose a reason for hiding this comment

hebasto left a comment

Choose a reason for hiding this comment

hebasto commented May 21, 2024

DrahtBot commented May 22, 2024

Guix builds (on x86_64) [untrusted test-only build, possibly unsafe, not for production use]

DrahtBot commented Jun 2, 2024

achow101 commented Jun 5, 2024

TheCharlatan left a comment

Choose a reason for hiding this comment

hebasto left a comment

Choose a reason for hiding this comment

DrahtBot commented Dec 6, 2023 •

edited

ryanofsky commented Dec 8, 2023 •

edited

ryanofsky commented Dec 8, 2023 •

edited

ryanofsky commented Dec 11, 2023 •

edited