[kernel 0/n] Introduce bitcoin-chainstate #24304

pull dongcarl wants to merge 2 commits into bitcoin:master from dongcarl:2022-02-libbitcoinkernel-p0-minimal changing 6 files +380 −4
  1. dongcarl commented at 9:00 pm on February 9, 2022: member

    Part of: #24303

    This PR introduces an example/demo bitcoin-chainstate executable using said library which can print out information about a datadir and take in new blocks on stdin.

    Please read the commit messages for more details.


    You may ask: WTF?! Why is index/*.cpp, etc. being linked in?

    This PR is meant only to capture the state of dependencies in our consensus engine as of right now. There are many things to decouple from consensus, which will be done in subsequent PRs. Listing the files out right now in bitcoin_chainstate_SOURCES is purely to give us a clear picture of the task at hand, it is not to say that these dependencies belongs there in any way.

    TODO

    1. Clean up bitcoin-chainstate.cpp It is quite ugly, with a lot of comments I’ve left for myself, I should clean it up to the best of my abilities (the ugliness of our init/shutdown might be the upper bound on cleanliness here…)
  2. dongcarl marked this as a draft on Feb 9, 2022
  3. dongcarl force-pushed on Feb 9, 2022
  4. dongcarl force-pushed on Feb 9, 2022
  5. DrahtBot added the label Build system on Feb 9, 2022
  6. DrahtBot added the label Utils/log/libs on Feb 9, 2022
  7. in src/bitcoin-chainstate.cpp:33 in 518c876efe outdated
    39+        state = stateIn;
    40+    }
    41+};
    42+
    43+
    44+int main(int argc, char* argv[]) {
    


    MarcoFalke commented at 8:13 pm on February 10, 2022:
    What would happen if this function was empty? If it builds, then the changes here are minimal and build-system only and wouldn’t need to concern itself with (C++) code yet.

    dongcarl commented at 8:26 pm on February 10, 2022:
    If it’s empty, then we would be able to remove all files in libbitcoinkernel_la_SOURCES and it would still compile and link. It being not empty is to enforce that we’ve linked at least the set of files necessary for this functionality.
  8. in src/bitcoin-chainstate.cpp:91 in 518c876efe outdated
    103+                             false,
    104+                             false,
    105+                             [](){ return false; });
    106+    if (rv.has_value()) {
    107+        std::cerr << "Failed to load Chain state from your datadir." << std::endl;
    108+        goto epilogue;
    


    MarcoFalke commented at 8:18 pm on February 10, 2022:
    Wouldn’t the code be easier to read by replacing this with return; and letting a destructor of an object that lives in this scope take care of the cleanup?

    dongcarl commented at 8:28 pm on February 10, 2022:
    Unfortunately, with our codebase right now if we don’t do the shutdown process in a very carefully sequenced way, there will be nullptr dereferences and other undefined behaviour.

    MarcoFalke commented at 8:42 pm on February 10, 2022:
    I don’t mean to reorder the sequence. It is just a suggestion to remove goto, which in my eyes is impossible to review. I am convinced that any code using goto can be rewritten in a way that doesn’t use goto and is at the same time easier to read. I can look into this in the future, unless someone beats me to it.

    ryanofsky commented at 4:21 pm on February 11, 2022:

    I don’t mean to reorder the sequence. It is just a suggestion to remove goto, which in my eyes is impossible to review.

    IMO, it is ok to use goto in a limited way to exit a block, and not worse than break. This can be cleaner and better than more convoluted alternatives and there are good practices build around it https://www.kernel.org/doc/html/latest/process/coding-style.html#centralized-exiting-of-functions


    MarcoFalke commented at 5:13 pm on February 11, 2022:

    I don’t think we should be using the style guide of the kernel (a project written in C) for a project written in C++.

    But given that the code here isn’t used for anything after compilation (other than to prove that linking works), I think any style is fine here.


    dongcarl commented at 7:11 pm on February 13, 2022:
    Leaving this thread open for the benefit of future reviewers.

    laanwj commented at 1:47 pm on February 14, 2022:
    IMO goto is acceptable in C, which has no RAII and other scope-based ways of handling errors, but not in C++, generally. The only current use of goto we have in the code is in src/crypto/poly1305.cpp which is effectively included C code. So i’d really like to avoid it if remotely possible.

    ryanofsky commented at 4:46 pm on February 14, 2022:

    In commit “build: Add example bitcoin-chainstate executable” (ac43dd0c8ed4b85e5fea359f1d584678bbc9378f)

    I guess the goto is kind of a shiny object. You can get rid of gotos by improving code (refactoring out functions, using RAII) but you can also get rid of gotos by making code worse (adding layers of nesting and loops and confusing variables). Exciting to see what is in this little goto’s future!


    dongcarl commented at 8:01 pm on February 14, 2022:

    Agree that this goto is a shiny object 😅 . It’s actually the reason why I added the developer note at the beginning of the file here: https://github.com/bitcoin/bitcoin/blob/095aa6ca37bf0bd5c5e221bab779978a99b2a34c/src/bitcoin-chainstate.cpp#L9-L10

    I think that since this binary is a “demo-only” executable (that will actually later be moved to src/kernel/examples/bitcoin-chainstate) we can not bother too much with its style. However, I do agree that this wouldn’t be acceptable if it were not “demo-only”.

    If people feel very strongly about it, please speak up and I can make the necessary modifications, but it might make things a bit less readable.


    ajtowns commented at 7:10 pm on February 17, 2022:
    Here’s a simple way of avoiding goto without (I think) making things less readable: https://github.com/ajtowns/bitcoin/commit/5d7d8de713961a88a40c236346bbfad4ad2906f0

    dongcarl commented at 10:22 pm on February 17, 2022:
    @ajtowns Hmmm good point… Well since I’m going to introduce a kernel::Context object anyway, might be good to just move the init/shutdown logic over there and let RAII handle it. Will play around with it, thanks for the hint!!
  9. in src/bitcoin-chainstate.cpp:190 in 518c876efe outdated
    185+        }
    186+
    187+        bool new_block;
    188+        auto sc = std::make_shared<submitblock_StateCatcher>(block.GetHash());
    189+        RegisterSharedValidationInterface(sc);
    190+        bool accepted = chainman.ProcessNewBlock(chainparams, blockptr, /* fForceProcessing */ true, /* fNewBlock */ &new_block);
    


    MarcoFalke commented at 8:19 pm on February 10, 2022:
    wrong argument names?
  10. MarcoFalke approved
  11. MarcoFalke commented at 8:20 pm on February 10, 2022: member
    Concept ACK. Left some questions.
  12. MarcoFalke commented at 8:25 pm on February 10, 2022: member

    Would it be appropriate to add a CI job that enables –enable-experimental-util-chainstate?

    Do you need to add one? What about adding it to the existing nowallet task?

  13. dongcarl force-pushed on Feb 10, 2022
  14. dongcarl commented at 8:33 pm on February 10, 2022: member

    Pushed 518c876efe…1d9faa8fc7:

  15. dongcarl commented at 8:34 pm on February 10, 2022: member

    @MarcoFalke

    Do you need to add one? What about adding it to the existing nowallet task?

    I’m happy to add it to the existing nowallet task if you think it’s appropriate! Lmk!

  16. MarcoFalke commented at 8:42 pm on February 10, 2022: member

    I’m happy to add it to the existing nowallet task if you think it’s appropriate! Lmk!

    Yeah, I don’t think there are any downsides and only upsides to it, right?

  17. MarcoFalke commented at 9:49 pm on February 10, 2022: member

    From ci:

    0clientversion.cpp:19:10: fatal error: 'obj/build.h' file not found
    1#include <obj/build.h>
    2         ^~~~~~~~~~~~~
    31 error generated.
    
  18. dongcarl force-pushed on Feb 10, 2022
  19. dongcarl force-pushed on Feb 10, 2022
  20. dongcarl force-pushed on Feb 10, 2022
  21. dongcarl force-pushed on Feb 11, 2022
  22. dongcarl force-pushed on Feb 11, 2022
  23. in .cirrus.yml:262 in d8f2e52387 outdated
    258@@ -259,13 +259,13 @@ task:
    259     FILE_ENV: "./ci/test/00_setup_env_i686_multiprocess.sh"
    260 
    261 task:
    262-  name: '[no wallet] [bionic]'
    263+  name: '[no wallet, libbitcoinkernel] [bionic]'
    


    MarcoFalke commented at 7:59 am on February 11, 2022:
    in the ci commit: pls remove the @MarcoFalke

    dongcarl commented at 6:53 pm on February 11, 2022:
    I removed the “@” from the commit message, is that sufficient?
  24. DrahtBot commented at 12:04 pm on February 11, 2022: member

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

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #24322 ([kernel 1/n] Introduce initial libbitcoinkernel by dongcarl)
    • #24164 (build: Bump minimum required clang/libc++ to 8.0 by MarcoFalke)

    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.

  25. in src/bitcoin-chainstate.cpp:41 in 01840e6161 outdated
    40+    }
    41+};
    42+
    43+
    44+int main(int argc, char* argv[]) {
    45+    assert(argc == 2);
    


    ryanofsky commented at 3:55 pm on February 11, 2022:

    In commit “build: Add example bitcoin-chainstate executable” (01840e6161396ed0ab30a122921f67b8dce45499)

    Would be nicer to print a “Usage:” message


    dongcarl commented at 10:04 pm on February 11, 2022:
    Done as of 0d90128a3b6acab0fd9d1bc39518e2783b55fdf3
  26. in src/bitcoin-chainstate.cpp:94 in 01840e6161 outdated
    89+
    90+    GetMainSignals().RegisterBackgroundSignalScheduler(scheduler);
    91+
    92+    ChainstateManager chainman;
    93+
    94+    auto rv = LoadChainstate(false,
    


    ryanofsky commented at 4:06 pm on February 11, 2022:

    In commit “build: Add example bitcoin-chainstate executable” (01840e6161396ed0ab30a122921f67b8dce45499)

    The LoadChainstate and VerifyLoadedChainstate calls here would be cleaner with b7c7f64dc86f0fcdf07cb1e765f7cccc3a3c8897 suggested in #23280#pullrequestreview-825684290 and would let this code print specific error messages instead failing generically and discarding the return codes.

  27. in src/bitcoin-chainstate.cpp:1 in 01840e6161 outdated
    0@@ -0,0 +1,255 @@
    1+#include <iostream> // for cout and shit
    


    ryanofsky commented at 4:28 pm on February 11, 2022:

    In commit “build: Add example bitcoin-chainstate executable” (01840e6161396ed0ab30a122921f67b8dce45499)

    Should add the commit description “The bitcoin-chainstate executable serves to…” to the top of this file so it is not lost in git history. Or bitcoin-chainstate could accept “-help” option and describe its purpose there.


    dongcarl commented at 10:04 pm on February 11, 2022:
    Done as of 0d90128a3b6acab0fd9d1bc39518e2783b55fdf3
  28. in src/bitcoin-chainstate.cpp:20 in 01840e6161 outdated
    15+#include <scheduler.h>                // for CScheduler
    16+#include <script/sigcache.h>          // for InitSignatureCache
    17+
    18+using node::fReindex;
    19+using node::LoadChainstate;
    20+using node::VerifyLoadedChainstate;
    


    ryanofsky commented at 4:30 pm on February 11, 2022:

    In commit “build: Add example bitcoin-chainstate executable” (01840e6161396ed0ab30a122921f67b8dce45499)

    I think it would be clearer to drop these using statements, and use the full names symbol below. Especially because node::fIndex looks like a local variable, not a global variable without the namespace component.


    dongcarl commented at 8:36 pm on February 11, 2022:
    Done as of 9050346f04d0435ad71d93ba1df4f5c126c0337b
  29. in src/bitcoin-chainstate.cpp:22 in e5579f11b7 outdated
    18@@ -19,7 +19,7 @@ using node::fReindex;
    19 using node::LoadChainstate;
    20 using node::VerifyLoadedChainstate;
    21 
    22-const extern std::function<std::string(const char*)> G_TRANSLATION_FUN = nullptr;
    23+__attribute__ ((visibility("default"))) const extern std::function<std::string(const char*)> G_TRANSLATION_FUN = nullptr;
    


    ryanofsky commented at 4:38 pm on February 11, 2022:

    In commit “f” (e5579f11b702ad978cd4f672b362e6346c699234)

    I don’t think extern belongs here. Maybe if you drop the extern you could drop the visibility attribute as well?


    dongcarl commented at 6:56 pm on February 11, 2022:

    You’re right! I’ve removed it.

    However, we still need the visibility attribute for the reasons detailed in the commit message for 7f7f92f81d06b0a3888fad102d3bc09a64483995

  30. ryanofsky approved
  31. ryanofsky commented at 4:44 pm on February 11, 2022: member
    Code review ACK e5579f11b702ad978cd4f672b362e6346c699234 with caveat that I mostly focused on the first commit and did not very closely review the build changes. (I think it could be a good idea to put first commit and other commits into two separate PRs, because the reviewers who are best able to give feedback about the code in the first commit are not necessarily the same people who can provide best feedback about the build commits.)
  32. dongcarl force-pushed on Feb 11, 2022
  33. dongcarl force-pushed on Feb 11, 2022
  34. dongcarl force-pushed on Feb 11, 2022
  35. dongcarl renamed this:
    [kernel 0/n] Introduce `bitcoin-chainstate` and `libbitcoinkernel`
    [kernel 0/n] Introduce `bitcoin-chainstate`
    on Feb 11, 2022
  36. dongcarl force-pushed on Feb 11, 2022
  37. in configure.ac:1634 in da90564230 outdated
    1629@@ -1622,6 +1630,10 @@ AC_MSG_CHECKING([whether to build bitcoin-util])
    1630 AM_CONDITIONAL([BUILD_BITCOIN_UTIL], [test $build_bitcoin_util = "yes"])
    1631 AC_MSG_RESULT($build_bitcoin_util)
    1632 
    1633+AC_MSG_CHECKING([whether to build experimental bitcoin-chainstate])
    1634+AM_CONDITIONAL([BUILD_BITCOIN_CHAINSTATE], [test x$build_bitcoin_chainstate = xyes])
    


    MarcoFalke commented at 7:29 pm on February 11, 2022:
    nit: remove x and add missing “quotes” like everywhere else?

    dongcarl commented at 8:36 pm on February 11, 2022:
    Done as of 9050346f04d0435ad71d93ba1df4f5c126c0337b
  38. in src/Makefile.am:774 in da90564230 outdated
    767@@ -764,6 +768,102 @@ bitcoin_util_LDADD = \
    768 bitcoin_util_LDADD += $(BOOST_LIBS)
    769 #
    770 
    771+# bitcoin-chainstate binary #
    772+#
    773+# TODO: Remove blockfilter.cpp and index/blockfilterindex.cpp after merge of
    774+#       "Improve Indices on pruned nodes via prune blockers" #21726
    


    MarcoFalke commented at 7:32 pm on February 11, 2022:
    nit: Maybe remove this TODO and either create a review comment (after merge) on 21726, or create a tracking comment in the parent b-cs issue?

    dongcarl commented at 8:38 pm on February 11, 2022:
    Comment removed as of 9050346f04d0435ad71d93ba1df4f5c126c0337b Added to “Project-wide TODOs”: https://github.com/bitcoin/bitcoin/issues/24303
  39. dongcarl force-pushed on Feb 11, 2022
  40. in src/Makefile.am:841 in da90564230 outdated
    844+  util/syscall_sandbox.cpp \
    845+  util/system.cpp \
    846+  util/thread.cpp \
    847+  util/threadnames.cpp \
    848+  util/time.cpp \
    849+  util/tokenpipe.cpp \
    


    MarcoFalke commented at 7:37 pm on February 11, 2022:

    question: This means that the “util library” will be compiled twice? Maybe it could make sense to split libutil out from libcommon and make libkernel depend on libutil?

    Similarly, the consensus stuff will be compiled twice. Maybe it could make sense to remove consensus stuff from libnode and instead make libnode depend on libkernel?


    dongcarl commented at 8:27 pm on February 11, 2022:

    This means that the “util library” will be compiled twice?

    Yes, as it stands currently at least these few files of the util library will be compiled twice.

    Maybe it could make sense to split libutil out from libcommon and make libkernel depend on libutil?

    Unfortunately, there are plenty of util/*.cpp that libbitcoinkernel doesn’t use, and I wish to prevent any futher coupling in that regard especially since the files under util/*.cpp are largely unrelated.

    Maybe it could make sense to remove consensus stuff from libnode and instead make libnode depend on libkernel?

    Unfortunately bitcoin-chainstate or libbitcoinkernel requires quite a lot of .cpp files that libnode doesn’t, and also vice versa (both ends of the venn diagram are non-empty). So there’s no clear hierarchy that we can establish without linking in a large number of unnecessary .cpp files which I want to prevent.

    The following invocation (in a shell that supports process substitution) will print all the .cpp that bitcoin-chainstate/libbitcoinkernel requires but libnode doesn’t:

    0comm -23 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
    1         <(make --no-print-directory -C src print-libbitcoin_node_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
     0arith_uint256.cpp
     1bitcoin-chainstate.cpp
     2chainparamsbase.cpp
     3chainparams.cpp
     4clientversion.cpp
     5coins.cpp
     6compat/glibcxx_sanity.cpp
     7compressor.cpp
     8consensus/merkle.cpp
     9consensus/tx_check.cpp
    10core_read.cpp
    11deploymentinfo.cpp
    12fs.cpp
    13hash.cpp
    14init/common.cpp
    15key.cpp
    16logging.cpp
    17netaddress.cpp
    18policy/feerate.cpp
    19policy/policy.cpp
    20primitives/block.cpp
    21primitives/transaction.cpp
    22pubkey.cpp
    23random.cpp
    24randomenv.cpp
    25scheduler.cpp
    26script/interpreter.cpp
    27script/script.cpp
    28script/script_error.cpp
    29script/standard.cpp
    30support/cleanse.cpp
    31support/lockedpool.cpp
    32sync.cpp
    33threadinterrupt.cpp
    34uint256.cpp
    35util/asmap.cpp
    36util/bytevectorhash.cpp
    37util/getuniquepath.cpp
    38util/hasher.cpp
    39util/moneystr.cpp
    40util/rbf.cpp
    41util/serfloat.cpp
    42util/settings.cpp
    43util/strencodings.cpp
    44util/syscall_sandbox.cpp
    45util/system.cpp
    46util/thread.cpp
    47util/threadnames.cpp
    48util/time.cpp
    49util/tokenpipe.cpp
    50warnings.cpp
    

    All the .cpp that libnode requires but bitcoin-chainstate/libbitcoinkernel doesn’t:

    0comm -13 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
    1         <(make --no-print-directory -C src print-libbitcoin_node_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
     0addrdb.cpp
     1addrman.cpp
     2banman.cpp
     3blockencodings.cpp
     4httprpc.cpp
     5httpserver.cpp
     6i2p.cpp
     7index/txindex.cpp
     8init.cpp
     9mapport.cpp
    10net.cpp
    11net_processing.cpp
    12node/caches.cpp
    13node/coin.cpp
    14node/context.cpp
    15node/interfaces.cpp
    16node/miner.cpp
    17node/minisketchwrapper.cpp
    18node/psbt.cpp
    19node/transaction.cpp
    20noui.cpp
    21rest.cpp
    22rpc/blockchain.cpp
    23rpc/mining.cpp
    24rpc/misc.cpp
    25rpc/net.cpp
    26rpc/rawtransaction.cpp
    27rpc/server.cpp
    28rpc/server_util.cpp
    29torcontrol.cpp
    30txorphanage.cpp
    31txrequest.cpp
    32wallet/init.cpp
    

    However, if we perform a similar analysis on libbitcoinconsensus.la we’ll see that it compiles the crypto/*.cpp files, which can be eliminated by https://github.com/bitcoin/bitcoin/pull/24322/commits/7c2b41e9f81e52cb30efc2d90ebb4b414b97617f, after that change there’s just script/bitcoinconsensus.cpp left.

    Potential followup PR: Extract out a libbitcoinconensus_internal.la which doesn’t include script/bitcoinconsensus.cpp that libbitcoinkernel can link against and avoid unnecessary compilation.

    0comm -13 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
    1         <(make --no-print-directory -C src print-libbitcoinconsensus_la_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
     0crypto/aes.cpp
     1crypto/chacha20.cpp
     2crypto/chacha_poly_aead.cpp
     3crypto/hkdf_sha256_32.cpp
     4crypto/hmac_sha256.cpp
     5crypto/hmac_sha512.cpp
     6crypto/muhash.cpp
     7crypto/poly1305.cpp
     8crypto/ripemd160.cpp
     9crypto/sha1.cpp
    10crypto/sha256.cpp
    11crypto/sha256_sse4.cpp
    12crypto/sha3.cpp
    13crypto/sha512.cpp
    14crypto/siphash.cpp
    15script/bitcoinconsensus.cpp
    

    Appendix

    For reference, here’s the .cpp comparison for libcommon:

    All the .cpp that bitcoin-chainstate/libbitcoinkernel requires but libcommon doesn’t:

    0comm -23 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
    1         <(make --no-print-directory -C src print-libbitcoin_common_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
     0arith_uint256.cpp
     1bitcoin-chainstate.cpp
     2blockfilter.cpp
     3chain.cpp
     4chainparamsbase.cpp
     5clientversion.cpp
     6compat/glibcxx_sanity.cpp
     7consensus/merkle.cpp
     8consensus/tx_check.cpp
     9consensus/tx_verify.cpp
    10dbwrapper.cpp
    11deploymentstatus.cpp
    12flatfile.cpp
    13fs.cpp
    14hash.cpp
    15index/base.cpp
    16index/blockfilterindex.cpp
    17index/coinstatsindex.cpp
    18logging.cpp
    19node/blockstorage.cpp
    20node/chainstate.cpp
    21node/coinstats.cpp
    22node/ui_interface.cpp
    23policy/fees.cpp
    24policy/packages.cpp
    25policy/rbf.cpp
    26policy/settings.cpp
    27pow.cpp
    28primitives/block.cpp
    29primitives/transaction.cpp
    30pubkey.cpp
    31random.cpp
    32randomenv.cpp
    33script/interpreter.cpp
    34script/script.cpp
    35script/script_error.cpp
    36script/sigcache.cpp
    37shutdown.cpp
    38signet.cpp
    39support/cleanse.cpp
    40support/lockedpool.cpp
    41sync.cpp
    42threadinterrupt.cpp
    43timedata.cpp
    44txdb.cpp
    45txmempool.cpp
    46uint256.cpp
    47util/asmap.cpp
    48util/bytevectorhash.cpp
    49util/getuniquepath.cpp
    50util/hasher.cpp
    51util/moneystr.cpp
    52util/rbf.cpp
    53util/serfloat.cpp
    54util/settings.cpp
    55util/strencodings.cpp
    56util/syscall_sandbox.cpp
    57util/system.cpp
    58util/thread.cpp
    59util/threadnames.cpp
    60util/time.cpp
    61util/tokenpipe.cpp
    62validation.cpp
    63validationinterface.cpp
    64versionbits.cpp
    

    All the .cpp that libcommon requires but bitcoin-chainstate/libbitcoinkernel doesn’t:

    0comm -13 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
    1         <(make --no-print-directory -C src print-libbitcoin_common_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
     0base58.cpp
     1bech32.cpp
     2common/bloom.cpp
     3core_write.cpp
     4external_signer.cpp
     5key_io.cpp
     6merkleblock.cpp
     7netbase.cpp
     8net_permissions.cpp
     9net_types.cpp
    10outputtype.cpp
    11protocol.cpp
    12psbt.cpp
    13rpc/external_signer.cpp
    14rpc/rawtransaction_util.cpp
    15rpc/util.cpp
    16script/descriptor.cpp
    17script/sign.cpp
    18script/signingprovider.cpp
    

    dongcarl commented at 7:18 pm on February 13, 2022:
    Leaving this thread open for the benefit of future reviewers.
  41. MarcoFalke approved
  42. MarcoFalke commented at 7:38 pm on February 11, 2022: member
    review ACK da9056423079bcbdcfb23133a6063c37469d58b1
  43. dongcarl force-pushed on Feb 11, 2022
  44. ryanofsky approved
  45. ryanofsky commented at 8:54 pm on February 11, 2022: member
    Code review ACK 9050346f04d0435ad71d93ba1df4f5c126c0337b. Main difference since last review is build changes have been scaled back to just add the new executable without the new library for now. There are also a few minor tweaks to bitcoin-chainstate, removing using statements and simplifying the G_TRANSLATION_FUN declaration
  46. dongcarl force-pushed on Feb 11, 2022
  47. in src/bitcoin-chainstate.cpp:50 in 0d90128a3b outdated
    46+
    47+int main(int argc, char* argv[]) {
    48+    if (argc != 2) {
    49+        std::cerr
    50+            << "Usage: " << argv[0] << " DATADIR" << std::endl
    51+            << "Display DATADIR information, and process hex-encoded blocks on standard input." << std::endl;
    


    MarcoFalke commented at 7:25 am on February 12, 2022:

    Could clarify that this is experimental, for testing only, and expected to break in future versions?

    Otherwise someone might accidentally pass the configure option and then open a bug that their mainnet utxo database is corrupted.


    dongcarl commented at 7:17 pm on February 13, 2022:
    Fixed as of: f0f78cb20b49f0a022bf3661538db17eb58ad280
  48. in src/bitcoin-chainstate.cpp:5 in 0d90128a3b outdated
    0@@ -0,0 +1,263 @@
    1+// The bitcoin-chainstate executable serves to surface the dependencies required
    


    MarcoFalke commented at 7:25 am on February 12, 2022:
    missing copyright header?

    dongcarl commented at 7:17 pm on February 13, 2022:
    Fixed as of: f0f78cb20b49f0a022bf3661538db17eb58ad280
  49. MarcoFalke commented at 7:27 am on February 12, 2022: member
    Can be taken out of draft now?
  50. MarcoFalke added the label DrahtBot Guix build requested on Feb 12, 2022
  51. dongcarl force-pushed on Feb 13, 2022
  52. dongcarl force-pushed on Feb 13, 2022
  53. dongcarl marked this as ready for review on Feb 13, 2022
  54. dongcarl force-pushed on Feb 13, 2022
  55. dongcarl force-pushed on Feb 13, 2022
  56. dongcarl commented at 7:40 pm on February 13, 2022: member

    Pushed 0ad6a3e81265ef2ad5353c4e0f6553955980d2bc:

    • Lots of cleanup in bitcoin-chainstate.cpp:
      • Added copyright header
      • More information in header comment
      • Removed personal comments
      • Added comments separating the stages of setup
      • Sorted headers
      • Moved submitblock_StateCatcher to where it’s used so there’s more context
      • Addressed some review comments
  57. MarcoFalke added this to the milestone 24.0 on Feb 14, 2022
  58. MarcoFalke commented at 9:07 am on February 14, 2022: member
    Assigned 24.0, as this missed the 0.23 feature freeze
  59. in src/Makefile.am:861 in 0ad6a3e812 outdated
    856+  $(LIBUNIVALUE) \
    857+  $(LIBSECP256K1) \
    858+  $(LIBLEVELDB) \
    859+  $(LIBLEVELDB_SSE42) \
    860+  $(LIBMEMENV) \
    861+  $(BOOST_LIBS)
    


    MarcoFalke commented at 9:40 am on February 14, 2022:
    Needs rebase after #24301

    dongcarl commented at 7:55 pm on February 14, 2022:
    Done as of 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0
  60. in src/bitcoin-chainstate.cpp:10 in 0ad6a3e812 outdated
     5+// The bitcoin-chainstate executable serves to surface the dependencies required
     6+// by a program wishing to use Bitcoin Core's consensus engine as it is right
     7+// now.
     8+//
     9+// DEVELOPER NOTE: Since this is a "demo-only", experimental, etc. executable,
    10+//                 it may diverge from Bitcoin Core's coding style.
    


    MarcoFalke commented at 9:45 am on February 14, 2022:
    I think this can be removed and if there was any reason to use a different coding style for this binary, it can be explained in the pull request, a review comment, or a code comment.

    dongcarl commented at 8:01 pm on February 14, 2022:
    Some discussion here: #24304 (review)
  61. in src/bitcoin-chainstate.cpp:33 in 0ad6a3e812 outdated
    28+#include <functional>
    29+#include <iosfwd>
    30+
    31+const std::function<std::string(const char*)> G_TRANSLATION_FUN = nullptr;
    32+
    33+int main(int argc, char* argv[]) {
    


    MarcoFalke commented at 9:45 am on February 14, 2022:
    clang-format?

    dongcarl commented at 7:55 pm on February 14, 2022:
    Done as of 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0
  62. MarcoFalke approved
  63. MarcoFalke commented at 9:52 am on February 14, 2022: member

    re-ACK 0ad6a3e81265ef2ad5353c4e0f6553955980d2bc 🔟

    Signature:

     0-----BEGIN PGP SIGNED MESSAGE-----
     1Hash: SHA512
     2
     3re-ACK 0ad6a3e81265ef2ad5353c4e0f6553955980d2bc 🔟
     4-----BEGIN PGP SIGNATURE-----
     5
     6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
     7pUjLOgwAjdvJIwihxHSRaKHl0iVEsfH9gOsvngLNiBtqBBlXbooA0NFaFXMKce5f
     8v17lIZqfNLCfyIEZFSrgb4cTRAMURDJNTyVg4pFBCEVcmSxmcGniff8v9Y+pbPj7
     9Z7WYljWzVJpZeuAQyFwiAr9AerIYUZVndLX5X+QKf+JMBqg1Vv7G7SIfgdlUAzl8
    10+hIPW144xzl6xZRsTJrBp91GdAAY/vyAz+8EfFay82SAJC6ZE9CGtUEzrYyOQ8S/
    11vD+5ach5xi2FbOQgXYX+49Hqgx+x0VzAhEI4XeUm0NDKaiRlK15oPegyPXjL+obT
    12wmE+N1AzpeYJ60Wih64XyT7NB3DaMpExoybmMlgPaOyfLZvC+nMlhjffPG5M3sni
    13Xl1ffLN873bQgYJf8mT/vO/U+PHTD6iJBk9LzhMYTF5ltW94j7/2XCCB3/3nRCFn
    142R0jz8wJxovw2a/MDkI3mdfvzzWQeIugGNZie2fs+Vtn5cgyWfdburKq4d2bUEum
    15MuiehY0A
    16=PeLI
    17-----END PGP SIGNATURE-----
    
  64. DrahtBot commented at 11:40 am on February 14, 2022: member

    Guix builds

    File commit 3bb93940703e9d0f4bffda98f4fe22fb1487db34(master) commit 9a7960ddf173b3b53f6b7e21d3ecc0e20372e64c(master and this pull)
    SHA256SUMS.part dd60a2a6ddc05117... c66e790fb18446a3...
    *-aarch64-linux-gnu-debug.tar.gz 8bc5bcfefab76715... 3bb32eacda2bb05c...
    *-aarch64-linux-gnu.tar.gz 710321dcf5f0a4e9... 0c1e5fe5616aa830...
    *-arm-linux-gnueabihf-debug.tar.gz d0b5b74e80a06c13... 2ecf253ec6fa0271...
    *-arm-linux-gnueabihf.tar.gz 7540ec432bbe611b... 47199eb27f02243c...
    *-arm64-apple-darwin.tar.gz 20bd3de56c122dab... 814782a35b36f1ab...
    *-osx-unsigned.dmg 238a67aa27f7ed54... a9458756f40d3ddc...
    *-osx-unsigned.tar.gz ab189b2d1873f62f... b95e1130224420d3...
    *-osx64.tar.gz c25bd3526668fd5b... 3f19b8883178fa1e...
    *-powerpc64-linux-gnu-debug.tar.gz d8f9c7a39538f196... 02db19de98581b1e...
    *-powerpc64-linux-gnu.tar.gz 751c0e3f4371b425... a7a169f4c644fabf...
    *-powerpc64le-linux-gnu-debug.tar.gz 0b3a07e161da8e65... bd69f38a7f2666fc...
    *-powerpc64le-linux-gnu.tar.gz df8899cbe9059ccd... 43a74a88dc35429c...
    *-riscv64-linux-gnu-debug.tar.gz 0cb9b3fe2626bac2... add199d090229d79...
    *-riscv64-linux-gnu.tar.gz 08296f18f18113e9... ad4aa3496b4e2659...
    *-x86_64-linux-gnu-debug.tar.gz 41ecc738e3c92499... 92972e36cb96a7cc...
    *-x86_64-linux-gnu.tar.gz 9e1179bfc7d06e08... 456f9cc530993ded...
    *.tar.gz b7698539ff204a66... 7c8b49704e80e812...
    guix_build.log a288ed44440d4dfb... 546ce6009e648f76...
    guix_build.log.diff 81641e662291152b...
  65. DrahtBot removed the label DrahtBot Guix build requested on Feb 14, 2022
  66. in src/bitcoin-chainstate.cpp:42 in ceb9fe7a64 outdated
    36+        std::cerr
    37+            << "Usage: " << argv[0] << " DATADIR" << std::endl
    38+            << "Display DATADIR information, and process hex-encoded blocks on standard input." << std::endl
    39+            << std::endl
    40+            << "IMPORTANT: THIS EXECUTABLE IS EXPERIMENTAL, FOR TESTING ONLY, AND EXPECTED TO" << std::endl
    41+            << "           BREAK IN FUTURE VERSIONS. DO NOT USE ON YOUR ACTUAL DATADIR." << std::endl;
    


    ryanofsky commented at 4:40 pm on February 14, 2022:

    In commit “build: Add example bitcoin-chainstate executable” (ac43dd0c8ed4b85e5fea359f1d584678bbc9378f)

    I like the disclaimer. Good to think of the user! All the documention updates here look great.


    dongcarl commented at 8:02 pm on February 14, 2022:
    Marco’s idea, and I agree! 😄
  67. ryanofsky approved
  68. ryanofsky commented at 4:51 pm on February 14, 2022: member

    Code review ACK 0ad6a3e81265ef2ad5353c4e0f6553955980d2bc with same caveat that mostly focused on first commit, paid less attention to build changes in second commit. Only changes since last review were documentation changes which all looked very good to me.

    Some comments about dependencies were lost, but it is probably better not to have the level of detail they were going into here:

     0-    // Initialize signatureCache cuz it's used by...
     1-    //     <- VerifyECDSASignature
     2-    //     <- CheckECDSASignature
     3-    //     <- EvalChecksigPreTapscript
     4-    //     <- EvalScript
     5-    //     <- VerifyScript
     6-    //     <- CScriptCheck::()
     7-    //     <- CheckInputScripts
     8-    //     <- ConnectBlock
     9-    //     <- ConnectTip
    10-    //     <- ActivateBestChainStep
    11-    //     <- ActivateBestChain
    12-    //     <- ProcessNewBlock
    13     InitSignatureCache();
    14-
    15-    // Initialize g_scriptExecutionCache{,Hasher} cuz it's used by...
    16-    //     <- CheckInputScripts
    17-    //     <- ConnectBlock
    18-    //     <- ConnectTip
    19-    //     <- ActivateBestChainStep
    20-    //     <- ActivateBestChain
    21-    //     <- ProcessNewBlock
    22     InitScriptExecutionCache();
    
  69. build: Add example bitcoin-chainstate executable
    The bitcoin-chainstate executable serves to surface the dependencies
    required by a program wishing to use Bitcoin Core's consensus engine as
    it is right now.
    
    More broadly, the _SOURCES list serves as a guiding "North Star" for the
    libbitcoinkernel project: as we decouple more and more modules of the
    codebase from our consensus engine, this _SOURCES list will grow shorter
    and shorter. One day, only what is critical to our consensus engine will
    remain. Right now, it's "the minimal list of files to link in to even
    use our consensus engine".
    
    [META] In a future commit the libbitcoinkernel library will be extracted
           from bitcoin-chainstate, and the libbitcoinkernel library's
           _SOURCES list will be the list that we aim to shrink.
    095aa6ca37
  70. ci: Build bitcoin-chainstate
    ...to make sure that the linker errors that arise from coupling
    regressions are caught by CI.
    
    Adding to the "no wallet" ci job as suggested by MarcoFalke.
    2c03cec2ff
  71. dongcarl force-pushed on Feb 14, 2022
  72. dongcarl commented at 8:12 pm on February 14, 2022: member

    Pushed 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0

    • Rebased over master to account for header-only boost change
    • Some comment and formatting changes to bitcoin-chainstate.cpp
  73. ryanofsky approved
  74. ryanofsky commented at 9:26 pm on February 14, 2022: member
    Code review ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0. Just rebase, comments, formatting change since last review
  75. in configure.ac:631 in 2c03cec2ff
    626@@ -626,6 +627,12 @@ AC_ARG_ENABLE([util-util],
    627   [build_bitcoin_util=$enableval],
    628   [build_bitcoin_util=$build_bitcoin_utils])
    629 
    630+AC_ARG_ENABLE([experimental-util-chainstate],
    631+  [AS_HELP_STRING([--enable-experimental-util-chainstate],
    


    Sjors commented at 8:49 am on February 17, 2022:

    You may want to document this in the PR description and elsewhere.

    Also should be in the ./configure summary.


    ryanofsky commented at 10:18 am on February 17, 2022:

    re: #24304 (review)

    You may want to document this in the PR description and elsewhere.

    Also should be in the ./configure summary.

    I believe this is only temporarily built as part of our build system and later moves to an examples folder (and built with cmake!) So that may a reason not to add it to --configure help, though I guess it you could have a comment saying the option is temporary and will be removed later. Agree it makes sense to document in PR description and elsewhere (maybe at the top of bitcoin-chainstate.cpp) so it’s obvious how to build & test this


    fanquake commented at 10:46 am on February 17, 2022:

    So that may a reason not to add it to –configure help,

    This option is already included in ./configure --help output, that’s done automatically by autotools.

    Also should be in the ./configure summary.

    I don’t think it needs to be.

  76. Sjors commented at 9:14 am on February 17, 2022: member

    Did some light testing of 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0. Very cool! I fed it block 1 and 2 on a fresh datadir and it was happy. I fed it a duplicate block and it exited. I fed it block 4 and it complained it didn’t have the previous block. All fine for now I would say.

    Can you add a short documentation, e.g. contrib/KERNEL.md, that includes a link to #24303, the configure flag and one example incantation how to use this binary? It doesn’t have to explain the entire kernel project.

    It might also be good to add a basic functional test for the binary. test/functional/tool_wallet.py should be a good template. You may need to add something to good_prefixes_re depending on how you name the test file.

    A skeleton manpage might be nice too, see plumbing example in #20913.

  77. ryanofsky commented at 10:40 am on February 17, 2022: member

    Can you add a short documentation, e.g. contrib/KERNEL.md, that includes a link to #24303, the configure flag and one example incantation how to use this binary? It doesn’t have to explain the entire kernel project.

    You already know this since you commented there, but for anyone else I started writing up some things about libbitcoinkernel design in #24352 (with a lot of “probably” hedging which I’ll remove because it was before I talked to Carl and was guessing about some things).

    I think existing https://github.com/bitcoin/bitcoin/blob/master/doc/shared-libraries.md will be a good place to document libbitcoinkernel usage when it gets added by the next PR.

    It might also be good to add a basic functional test for the binary. test/functional/tool_wallet.py should be a good template. You may need to add something to good_prefixes_re depending on how you name the test file.

    A skeleton manpage might be nice too, see plumbing example in #20913.

    I think this is only temporarily built as part of our build system, and later moving to an examples folder with a CMake file, so that would be a reason not to do the test, manpage, etc in this style.

  78. fanquake commented at 10:47 am on February 17, 2022: member

    I think this is only temporarily built as part of our build system, and later moving to an examples folder with a CMake file, so that would be a reason not to do the test, manpage, etc in this style.

    I agree with Russ. I don’t really see a reason to add tests, let alone a manpage for this binary.

  79. Sjors commented at 10:59 am on February 17, 2022: member

    later moving to an examples folder with a CMake file

    Having untested examples could lead to code rot though.

    I could also imagine this bitcoin-chainstate binary actually being useful, especially when you add ZMQ support. In a micro-service like architecture you would feed it blocks from another source (like an edge node) and it would spit out ZMQ feeds. All this without the menace of p2p connections and without the need for using RPC communication. But maybe this is a bit too contrived.

    (ZMQ of course doesn’t belong in a kernel, but some sort of notification interface probably does, and this binary can demo that)

  80. ryanofsky commented at 11:04 am on February 17, 2022: member

    Having untested examples could lead to code rot though.

    Agreed. I definitely think this should be continue to be built by CI at the very least, and maybe a have a little script feeding it a test block.

    I could also imagine this bitcoin-chainstate binary actually being useful, especially when you add ZMQ support.

    This could be great, but I believe it should be a separate tool cloned / inspired from this one. When you are using a new library it’s helpful to have a simple minimal example along with the fancy demo example.

  81. ryanofsky commented at 11:10 am on February 17, 2022: member

    (ZMQ of course doesn’t belong in a kernel, but some sort of notification interface probably does, and this binary can demo that)

    Stdout is my favorite notification interface 😏

  82. MarcoFalke commented at 12:55 pm on February 17, 2022: member
    Not sure if this needs a manpage and test, since there is already a test for it (see second commit). The goal of the binary right now is to confirm that the compiler and linker doesn’t fail. I don’t think that the binary should be considered stable for end users. Also, the interface is mostly a playground, as I understand it, and not the interface that will be shipped when it is final and ready for end users. Thus, adding a test will make it harder to change the interface later on.
  83. MarcoFalke approved
  84. MarcoFalke commented at 12:55 pm on February 17, 2022: member

    re-ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0 🏔

    Signature:

     0-----BEGIN PGP SIGNED MESSAGE-----
     1Hash: SHA512
     2
     3re-ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0 🏔
     4-----BEGIN PGP SIGNATURE-----
     5
     6iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
     7pUjqVQv9GTYBZ644zKBR/8+NgZAZqR/vzNuVLzgPo9UWDexF6M1LZRVpQaoaz831
     8PxJui5vAF4Eegt6OPhOEzmW4jpd6s5MpURCBL8BzKiyRxe0uT0MPnzufwpZn3iBP
     9SVpmoAcgG0ZjM9cdY2iJsLqhf47AHqAqh2K8f9gCoObqloHgjIb5fiK5gXowWLDd
    10B/zlZgmIaxlS/rgyUkpLa/5kIEOONyO56abJ9PhAlXYKm1GIX5+/GgB0Yb/BJEwL
    11bP843qBy511C07usDLKp3pPMPAFakDFJPJlmE7evSE5DEKcoXVTQGTjoK1JQ/j4t
    12Pa2bESI48/V7dBOGYDsEd0AdoW3J2Mkhkbzk1lp6Fu+vCQQbEqIVw5F05p3hUmuJ
    13RyDJROFVjvONophU2MMLOkL7xlfmNQzXY56ONDsd3OhPWG7bX82Kf0XPZ5rDqDGn
    149FWDiAf5/mTscazQ0wcwLZlIHX9gx0v0XOZNcLiStfaeAPq4X3U2cEN+2oPHHQtg
    158CMkgV6s
    16=nVUh
    17-----END PGP SIGNATURE-----
    
  85. ajtowns commented at 7:17 pm on February 17, 2022: member
    ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0
  86. MarcoFalke merged this on Mar 3, 2022
  87. MarcoFalke closed this on Mar 3, 2022

  88. sidhujag referenced this in commit d25bd6c5bb on Mar 5, 2022
  89. ariard commented at 11:51 pm on March 5, 2022: member
    Post-merge ACK 2c03cec
  90. dongcarl added this to the "WIP PRs" column in a project

  91. dongcarl moved this from the "WIP PRs" to the "Done" column in a project

  92. fanquake referenced this in commit dd17c42a16 on Apr 28, 2022
  93. DrahtBot locked this on Apr 27, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-12-19 00:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me