[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:

    clientversion.cpp:19:10: fatal error: 'obj/build.h' file not found
    #include <obj/build.h>
             ^~~~~~~~~~~~~
    1 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

    <!--e57a25ab6845829454e8d69fc972939a-->

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

    <!--174a7506f384e20aa4161008e828411d-->

    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:

    comm -23 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
             <(make --no-print-directory -C src print-libbitcoin_node_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
    arith_uint256.cpp
    bitcoin-chainstate.cpp
    chainparamsbase.cpp
    chainparams.cpp
    clientversion.cpp
    coins.cpp
    compat/glibcxx_sanity.cpp
    compressor.cpp
    consensus/merkle.cpp
    consensus/tx_check.cpp
    core_read.cpp
    deploymentinfo.cpp
    fs.cpp
    hash.cpp
    init/common.cpp
    key.cpp
    logging.cpp
    netaddress.cpp
    policy/feerate.cpp
    policy/policy.cpp
    primitives/block.cpp
    primitives/transaction.cpp
    pubkey.cpp
    random.cpp
    randomenv.cpp
    scheduler.cpp
    script/interpreter.cpp
    script/script.cpp
    script/script_error.cpp
    script/standard.cpp
    support/cleanse.cpp
    support/lockedpool.cpp
    sync.cpp
    threadinterrupt.cpp
    uint256.cpp
    util/asmap.cpp
    util/bytevectorhash.cpp
    util/getuniquepath.cpp
    util/hasher.cpp
    util/moneystr.cpp
    util/rbf.cpp
    util/serfloat.cpp
    util/settings.cpp
    util/strencodings.cpp
    util/syscall_sandbox.cpp
    util/system.cpp
    util/thread.cpp
    util/threadnames.cpp
    util/time.cpp
    util/tokenpipe.cpp
    warnings.cpp
    

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

    comm -13 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
             <(make --no-print-directory -C src print-libbitcoin_node_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
    addrdb.cpp
    addrman.cpp
    banman.cpp
    blockencodings.cpp
    httprpc.cpp
    httpserver.cpp
    i2p.cpp
    index/txindex.cpp
    init.cpp
    mapport.cpp
    net.cpp
    net_processing.cpp
    node/caches.cpp
    node/coin.cpp
    node/context.cpp
    node/interfaces.cpp
    node/miner.cpp
    node/minisketchwrapper.cpp
    node/psbt.cpp
    node/transaction.cpp
    noui.cpp
    rest.cpp
    rpc/blockchain.cpp
    rpc/mining.cpp
    rpc/misc.cpp
    rpc/net.cpp
    rpc/rawtransaction.cpp
    rpc/server.cpp
    rpc/server_util.cpp
    torcontrol.cpp
    txorphanage.cpp
    txrequest.cpp
    wallet/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.

    comm -13 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
             <(make --no-print-directory -C src print-libbitcoinconsensus_la_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
    crypto/aes.cpp
    crypto/chacha20.cpp
    crypto/chacha_poly_aead.cpp
    crypto/hkdf_sha256_32.cpp
    crypto/hmac_sha256.cpp
    crypto/hmac_sha512.cpp
    crypto/muhash.cpp
    crypto/poly1305.cpp
    crypto/ripemd160.cpp
    crypto/sha1.cpp
    crypto/sha256.cpp
    crypto/sha256_sse4.cpp
    crypto/sha3.cpp
    crypto/sha512.cpp
    crypto/siphash.cpp
    script/bitcoinconsensus.cpp
    

    Appendix

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

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

    comm -23 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
             <(make --no-print-directory -C src print-libbitcoin_common_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
    arith_uint256.cpp
    bitcoin-chainstate.cpp
    blockfilter.cpp
    chain.cpp
    chainparamsbase.cpp
    clientversion.cpp
    compat/glibcxx_sanity.cpp
    consensus/merkle.cpp
    consensus/tx_check.cpp
    consensus/tx_verify.cpp
    dbwrapper.cpp
    deploymentstatus.cpp
    flatfile.cpp
    fs.cpp
    hash.cpp
    index/base.cpp
    index/blockfilterindex.cpp
    index/coinstatsindex.cpp
    logging.cpp
    node/blockstorage.cpp
    node/chainstate.cpp
    node/coinstats.cpp
    node/ui_interface.cpp
    policy/fees.cpp
    policy/packages.cpp
    policy/rbf.cpp
    policy/settings.cpp
    pow.cpp
    primitives/block.cpp
    primitives/transaction.cpp
    pubkey.cpp
    random.cpp
    randomenv.cpp
    script/interpreter.cpp
    script/script.cpp
    script/script_error.cpp
    script/sigcache.cpp
    shutdown.cpp
    signet.cpp
    support/cleanse.cpp
    support/lockedpool.cpp
    sync.cpp
    threadinterrupt.cpp
    timedata.cpp
    txdb.cpp
    txmempool.cpp
    uint256.cpp
    util/asmap.cpp
    util/bytevectorhash.cpp
    util/getuniquepath.cpp
    util/hasher.cpp
    util/moneystr.cpp
    util/rbf.cpp
    util/serfloat.cpp
    util/settings.cpp
    util/strencodings.cpp
    util/syscall_sandbox.cpp
    util/system.cpp
    util/thread.cpp
    util/threadnames.cpp
    util/time.cpp
    util/tokenpipe.cpp
    validation.cpp
    validationinterface.cpp
    versionbits.cpp
    

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

    comm -13 <(make --no-print-directory -C src print-bitcoin_chainstate_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u) \
             <(make --no-print-directory -C src print-libbitcoin_common_a_SOURCES | cut -d= -f2 | tr ' ' '\n' | grep -v '\.h$' | sort -u)
    
    base58.cpp
    bech32.cpp
    common/bloom.cpp
    core_write.cpp
    external_signer.cpp
    key_io.cpp
    merkleblock.cpp
    netbase.cpp
    net_permissions.cpp
    net_types.cpp
    outputtype.cpp
    protocol.cpp
    psbt.cpp
    rpc/external_signer.cpp
    rpc/rawtransaction_util.cpp
    rpc/util.cpp
    script/descriptor.cpp
    script/sign.cpp
    script/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 🔟

    <details><summary>Show signature</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512
    
    re-ACK 0ad6a3e81265ef2ad5353c4e0f6553955980d2bc 🔟
    -----BEGIN PGP SIGNATURE-----
    
    iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
    pUjLOgwAjdvJIwihxHSRaKHl0iVEsfH9gOsvngLNiBtqBBlXbooA0NFaFXMKce5f
    v17lIZqfNLCfyIEZFSrgb4cTRAMURDJNTyVg4pFBCEVcmSxmcGniff8v9Y+pbPj7
    Z7WYljWzVJpZeuAQyFwiAr9AerIYUZVndLX5X+QKf+JMBqg1Vv7G7SIfgdlUAzl8
    +hIPW144xzl6xZRsTJrBp91GdAAY/vyAz+8EfFay82SAJC6ZE9CGtUEzrYyOQ8S/
    vD+5ach5xi2FbOQgXYX+49Hqgx+x0VzAhEI4XeUm0NDKaiRlK15oPegyPXjL+obT
    wmE+N1AzpeYJ60Wih64XyT7NB3DaMpExoybmMlgPaOyfLZvC+nMlhjffPG5M3sni
    Xl1ffLN873bQgYJf8mT/vO/U+PHTD6iJBk9LzhMYTF5ltW94j7/2XCCB3/3nRCFn
    2R0jz8wJxovw2a/MDkI3mdfvzzWQeIugGNZie2fs+Vtn5cgyWfdburKq4d2bUEum
    MuiehY0A
    =PeLI
    -----END PGP SIGNATURE-----
    

    </details>

  64. DrahtBot commented at 11:40 AM on February 14, 2022: member

    <!--9cd9c72976c961c55c7acef8f6ba82cd-->

    Guix builds

    File commit 3bb93940703e9d0f4bffda98f4fe22fb1487db34<br>(master) commit 9a7960ddf173b3b53f6b7e21d3ecc0e20372e64c<br>(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:

    -    // Initialize signatureCache cuz it's used by...
    -    //     <- VerifyECDSASignature
    -    //     <- CheckECDSASignature
    -    //     <- EvalChecksigPreTapscript
    -    //     <- EvalScript
    -    //     <- VerifyScript
    -    //     <- CScriptCheck::()
    -    //     <- CheckInputScripts
    -    //     <- ConnectBlock
    -    //     <- ConnectTip
    -    //     <- ActivateBestChainStep
    -    //     <- ActivateBestChain
    -    //     <- ProcessNewBlock
         InitSignatureCache();
    -
    -    // Initialize g_scriptExecutionCache{,Hasher} cuz it's used by...
    -    //     <- CheckInputScripts
    -    //     <- ConnectBlock
    -    //     <- ConnectTip
    -    //     <- ActivateBestChainStep
    -    //     <- ActivateBestChain
    -    //     <- ProcessNewBlock
         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 🏔

    <details><summary>Show signature</summary>

    Signature:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512
    
    re-ACK 2c03cec2ff8cdbfd5da92bfb507d218e5c6435b0 🏔
    -----BEGIN PGP SIGNATURE-----
    
    iQGzBAEBCgAdFiEE+rVPoUahrI9sLGYTzit1aX5ppUgFAlwqrYAACgkQzit1aX5p
    pUjqVQv9GTYBZ644zKBR/8+NgZAZqR/vzNuVLzgPo9UWDexF6M1LZRVpQaoaz831
    PxJui5vAF4Eegt6OPhOEzmW4jpd6s5MpURCBL8BzKiyRxe0uT0MPnzufwpZn3iBP
    SVpmoAcgG0ZjM9cdY2iJsLqhf47AHqAqh2K8f9gCoObqloHgjIb5fiK5gXowWLDd
    B/zlZgmIaxlS/rgyUkpLa/5kIEOONyO56abJ9PhAlXYKm1GIX5+/GgB0Yb/BJEwL
    bP843qBy511C07usDLKp3pPMPAFakDFJPJlmE7evSE5DEKcoXVTQGTjoK1JQ/j4t
    Pa2bESI48/V7dBOGYDsEd0AdoW3J2Mkhkbzk1lp6Fu+vCQQbEqIVw5F05p3hUmuJ
    RyDJROFVjvONophU2MMLOkL7xlfmNQzXY56ONDsd3OhPWG7bX82Kf0XPZ5rDqDGn
    9FWDiAf5/mTscazQ0wcwLZlIHX9gx0v0XOZNcLiStfaeAPq4X3U2cEN+2oPHHQtg
    8CMkgV6s
    =nVUh
    -----END PGP SIGNATURE-----
    

    </details>

  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: 2026-04-13 15:14 UTC

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