Move-only: Pull wallet code out of libbitcoin_server #15638

pull ryanofsky wants to merge 9 commits into bitcoin:master from ryanofsky:pr/link changing 72 files +1228 −923
  1. ryanofsky commented at 5:00 am on March 22, 2019: member

    This is a move-only commit. No code is changing and the moves can be easily verified with:

    0git log -p -n1 --color-moved=dimmed_zebra
    

    This commit moves functions and variables that wallet code depends on out of libbitcoin_server.a, so the bitcoin-wallet tool can be built without libbitcoin_server.a in #15639, and attempting to access server state from wallet code will result in link errors instead of silently broken code.

    List of moves:

    • CheckTransaction moves from consensus/tx_verify.cpp to consensus/tx_check.cpp
    • urlDecode moves from httpserver.cpp to util/url.cpp
    • TransactionErrorString moves from node/transaction.cpp to util/error.cpp
    • StringForFeeReason and FeeModeFromString move from policy/fees.cpp to util/fees.cpp
    • incrementalRelayFee dustRelayFee and nBytesPerSigOp move from policy/policy.cpp to policy/settings.cpp
    • SignalsOptInRBF moves from policy/rbf.cpp to util/rbf.cpp
    • fIsBareMultisigStd moves from validation.cpp to policy/settings.cpp
    • ConstructTransaction TxInErrorToJSON and SignTransaction move from rpc/rawtransaction.cpp to rpc/rawtransaction_util.cpp
    • RPCTypeCheck RPCTypeCheckArgument RPCTypeCheckObj AmountFromValue ParseHashV``ParseHashO ParseHexV ParseHexO HelpExampleCli and HelpExampleRpc move from rpc/server.cpp to rpc/util.cpp
    • AmountHighWarn and AmountErrMsg move from ui_interface.cpp to util/error.cpp
    • FormatStateMessage and strMessageMagic move from validation.cpp to util/validation.cpp
    • VerifyWallets LoadWallets StartWallets FlushWallets StopWallets and UnloadWallets move from wallet/init.cpp to wallet/node.cpp
  2. fanquake added the label Refactoring on Mar 22, 2019
  3. ryanofsky force-pushed on Mar 22, 2019
  4. ryanofsky force-pushed on Mar 22, 2019
  5. ryanofsky force-pushed on Mar 22, 2019
  6. DrahtBot commented at 7:25 am on March 22, 2019: 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:

    • #15294 ([moveonly] wallet: Extract RipeMd160 by Empact)
    • #15141 (Rewrite DoS interface between validation and net_processing by sdaftuar)
    • #14837 (Stricter & More Performant Invariant Checking in CheckBlock by JeremyRubin)
    • #14696 (qa: Add explicit references to related CVE’s in p2p_invalid_block test. by lucash-dev)
    • #13949 (Introduce MempoolObserver interface to break “policy/fees -> txmempool -> policy/fees” circular dependency by Empact)
    • #13751 (Utils and libraries: Drops the boost/algorithm/string/split.hpp dependency by 251Labs)
    • #13357 (Define SIGHASH_MASK in validation and determine the use of SIGHASH_SINGLE in signing by jl2012)
    • #12911 (wallet: Show fee in results for signrawtransaction* for segwit inputs by kallewoof)
    • #11413 ([wallet] [rpc] sendtoaddress/sendmany: Add explicit feerate option by kallewoof)
    • #10823 (Allow all mempool txs to be replaced after a configurable timeout (default 6h) by greenaddress)
    • #10443 (Add fee_est tool for debugging fee estimation code by ryanofsky)

    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.

  7. ryanofsky force-pushed on Mar 22, 2019
  8. Empact commented at 9:08 am on March 22, 2019: member

    I split this out for review here: https://github.com/Empact/bitcoin/commits/pr/link-split (you can diff https://github.com/Empact/bitcoin/commit/9d9ad3800da09575a7a058160d1ed0604df9ccc9 for consistency) and came away with 2 proposed changes:

    https://github.com/Empact/bitcoin/commit/3d5f9e943ae5e0da0edc55a7ba6e7d32689563f8 - TransactionErrorString is not used outside rpc/util.cpp, which includes node/transaction.h via rpc/util.h. Seems appropriate to leave it there.

    https://github.com/Empact/bitcoin/commit/173d3c499f5639455293ea53b09677805f6128fe - this moves StringFeeForReason back as it’s only used in wallet/wallet.cpp which includes policy/fees.h directly. It also makes util/fees independent of policy/fees, which seems appropriate re. layering.

  9. ryanofsky commented at 11:51 am on March 22, 2019: member

    @Empact, I can use your branch with split up commits if other people think that is easier to review. But I’m not sure that they will. Personally I would rather scan a single commit with --color-moved=dimmed_zebra, verify that it is move-only, and be able to see the whole picture than to have to verify fragmentary commits.

    The two changes you propose are not good, though. They have some problems conceptually, and I think will break the followup PR #15639, although I didn’t test.

    The point of this PR is to designate a directory (src/node/) and a library (libbitcoin_server.a) which contain node-specific code, which wallet code cannot call, and qt code cannot call. This is enforced by the linker after #15639, and should be clearly explained in the readme and makefile.

    Both wallet code and qt code should be able to translate error codes into strings. So TransactionErrorString belongs in a place like util/error.h and not underneath src/node/. (Beyond #15639, I would like util/error.h to be a common place for defining simple error types and messages that don’t pull in outside dependencies, so error values only need to be defined once, and we don’t need to write unnecessary code to catch exceptions or translate errors to different types when they are passed between wallet/node/rpc/gui code boundaries.)

    Similarly, both wallet code and qt code should be able to call StringForFeeReason, which means it shouldn’t be defined in src/policy/fees.cpp, because that file uses mempool types and would require wallet and qt code to be linked with mempool code, which is what this PR is trying to avoid and would be an error after #15639.

  10. jnewbery commented at 2:14 pm on March 22, 2019: member

    Very strong concept ACK to this and #15639. This is the natural follow-up to #10973. That PR defined a node<->wallet interface and made it so wallet code shouldn’t directly access node functions. This PR with #15639 ensures that wallet code can’t directly access node functions.

    My only question is when these should be merged. This conflicts with a lot of PRs (including high-priority #15141) so perhaps it should wait. On the other hand, rebases will be trivial since this is just a code move.

  11. in test/lint/lint-circular-dependencies.sh:30 in b35ba2c161 outdated
    26@@ -26,6 +27,7 @@ EXPECTED_CIRCULAR_DEPENDENCIES=(
    27     "qt/transactiontablemodel -> qt/walletmodel -> qt/transactiontablemodel"
    28     "qt/walletmodel -> qt/walletmodeltransaction -> qt/walletmodel"
    29     "txmempool -> validation -> txmempool"
    30+    "util/validation -> validation -> util/validation"
    


    l2a5b1 commented at 12:33 pm on March 25, 2019:

    Is there a strong argument that justifies moving helper function FormatStateMessage(const CValidationState &state) to its own translation unit, whilst it depends on the translation unit it was moved from?

    I would prefer not to introduce new circular dependencies if they can be prevented.


    ryanofsky commented at 4:00 pm on March 25, 2019:

    re: #15638 (review)

    Is there a strong argument that justifies moving helper function FormatStateMessage(const CValidationState &state) to its own translation unit, whilst it depends on the translation unit it was moved from?

    Will fix. This is just due to a spurious include. There’s no dependency between the object files.


    ryanofsky commented at 11:59 pm on March 29, 2019:

    re: #15638 (review)

    Removed new circular dependency

  12. in test/lint/lint-circular-dependencies.sh:16 in b35ba2c161 outdated
    12@@ -13,6 +13,7 @@ EXPECTED_CIRCULAR_DEPENDENCIES=(
    13     "checkpoints -> validation -> checkpoints"
    14     "index/txindex -> validation -> index/txindex"
    15     "policy/fees -> txmempool -> policy/fees"
    16+    "policy/policy -> policy/settings -> policy/policy"
    


    l2a5b1 commented at 12:38 pm on March 25, 2019:
    Let’s try not to introduce new circular dependencies. I had a quick look at #15639 and it seems that we can keep all the moved code in the policy translation unit and prevent the circular dependency?

    ryanofsky commented at 4:00 pm on March 25, 2019:

    re: #15638 (review)

    I had a quick look at #15639 and it seems that we can keep all the moved code in the policy translation unit and prevent the circular dependency?

    Will fix in #15639. To keep moves in one PR and actual code changes in the other, so both PRs are easier to review, I am adding a circular dependency here. But with the code refactoring in #15639, this can be dropped.

    Let’s try not to introduce new circular dependencies.

    Thanks, I should have pointed out these were a temporary hacks. In general, though, I am very skeptical about the lint-circular-dependencies check. I think instead of checking for an actual problem (circular symbol dependencies between libraries), it is checking for an imitation of the problem (circular preprocessor includes in pairs of .cpp/.h files). While I think in some cases fixing lint-circular-dependencies errors can make code organization better, it can just as easily make it worse.

    An example would be the circular dependency between txmempool and policy/fees. The fee estimation code needs access to the mempool entry struct, and the mempool code needs to call simple fee estimator add/remove functions when mempool entries get added and removed.

    The simple and obvious way to write this code is to declare the mempool entry struct in txmempool.h and the add/remove functions in fees.h and have a circular dependency between the two object files. As long as both object files are part of the same static library, this is perfectly fine and causes no problems. But if you want to appease the lint checker, you only have bad and mediocre options:

    • Combining files that shouldn’t be combined: merging fees and mempool files.
    • Splitting and scattering code around unnecessarily: declaring mempool entry struct in a separate file from the mempool struct.
    • Introducing unnecessary complexity: Registering fee estimator add/remove functions with the mempool at runtime, affecting runtime performance, and potentially introducing initialization bugs.

    It’s possible changes like these would be good for other reasons, but in general I think cleaning up spew from lint-circular-dependencies is not a good reason to make a code change if you can’t point to another actual reason for the change.


    ryanofsky commented at 11:59 pm on March 29, 2019:

    re: #15638 (review)

    Removed new circular dependency

  13. jnewbery commented at 1:30 pm on March 25, 2019: member

    if other people think that is easier to review

    I think it would be slightly easier to review if this was split into multiple commits, each moving a function with with justification for the move.

  14. in src/consensus/tx_check.h:3 in b35ba2c161 outdated
    0@@ -0,0 +1,16 @@
    1+// Copyright (c) 2017-2018 The Bitcoin Core developers
    2+// Distributed under the MIT software license, see the accompanying
    3+// file COPYING or http://www.opensource.org/licenses/mit-license.php.
    


    Sjors commented at 11:57 am on March 26, 2019:
    tx_check.h and tx_verify.h could use more documentation about what should go where.

    ryanofsky commented at 10:15 pm on March 29, 2019:

    re: #15638 (review)

    tx_check.h and tx_verify.h could use more documentation about what should go where.

    Added longer comment to the header. There was something about “Context-independent validity checks” already, but that was probably too opaque.

  15. Sjors commented at 1:31 pm on March 26, 2019: member

    tACK b35ba2c161b739c0caf9734a5e16123ed7688450

    The dimmed zebra helps with checking the moves. I’m fine with either splitting this into smaller commits that explain which things are are moved and why, or just putting a list in the PR description.

    I’m able to compile on macOS 10.14.3 with and without wallet.

    For some reason the x64 build in Visual Studio 2017 on Windows breaks:

    AppVeyor seems happy though. I did a clean before building. Building the parent commit also breaks, although with different errors. Maybe we recently introduced a problem? cc @ken2812221 & @sipsorcery

  16. sipsorcery commented at 6:32 pm on March 28, 2019: member
    @Sjors this PR builds correctly for me with VS 2017 x64 Debug and Release. Did you re-run the msvc-autogen.py script after pulling the changes? There have been modifications to the makefiles so the VS project files need to be re-generated.
  17. Sjors commented at 7:48 am on March 29, 2019: member
    @sipsorcery I did not. Can’t test it at the moment, but that seems like a plausible explanation.
  18. ryanofsky force-pushed on Mar 30, 2019
  19. ryanofsky commented at 0:21 am on March 30, 2019: member

    Updated b35ba2c161b739c0caf9734a5e16123ed7688450 -> 9742ff8d79402607159488eed362b7eb08580114 (pr/link.5 -> pr/link.6, compare) adding suggested comments, removing circular lint warnings.

    re: #15638#pullrequestreview-218844829

    The dimmed zebra helps with checking the moves. I’m fine with either splitting this into smaller commits that explain which things are are moved and why, or just putting a list in the PR description

    I added a list of moves to the PR description. A few people have requested splitting this PR up, and if someone still thinks this is a good idea, I’d urge them to at least first spend a few minutes looking over the commit with --color-moved=dimmed_zebra.

    I don’t want to break up this PR into a large number of commits, because we have lots of circular dependencies and lots of different binaries (tests, benchmarks, tools, frontends) that pull object files in with different link orders. We also build on many different platforms, so right now any commit that moves a symbol from one object file to another is basically playing russian roullete with travis and appveyor. I spent hours after I first got this PR working locally to eventually get it working on the various travis platforms and appveyor. I don’t want to have to repeat this work again with a bunch of individual commits, or to blindly push a bunch of broken commits. I think splitting the commit up at best would only make it slightly easier to review with --color-moved=dimmed_zebra, and in actuality would just make this more intimidating and more awkward to review and maintain. I think a bitcoin contributor who literally spent 10 minutes looking at the current commit with --color-moved=dimmed_zebra, could fully review the PR, verifying that it is move-only and reading all the new comments.

  20. ryanofsky commented at 5:14 pm on April 2, 2019: member

    John was asking questions about why different functions were moving to various libraries. I’ll describe how I was thinking about this below, but I don’t consider the question to be extremely important, because the libraries are already pretty scrambled up, and I’m not trying to unscramble them here. All I am trying to do is split up .cpp files that have functions called by the wallet, so wallet code that links these .cpp files doesn’t pull in a bunch of node dependencies.

    But just to provide reassurance that I am not messing up the libraries in some way here, here is how I am thinking about the organization:

    • libbitcoin_server.a, libbitcoin_wallet.a, and libbitcoinqt.a should all be terminal dependencies. They should be able to depend on other symbols in other libraries, but no other libraries should depend on symbols in them (and they shouldn’t depend on each other).

    • libbitcoin_consensus.a should be a standalone library that doesn’t depend on symbols in other libraries mentioned here

    • libbitcoin_common.a and libbitcoin_util.a seem very interchangeable right now and mutually depend on each other. I think we should either merge them into one library, or create a new top-level src/common/ directory complementing src/util/, and start to distinguish general purpose utility code (like argument parsing) from bitcoin-specific utility code (like formatting bip32 paths and using ChainParams). Both these libraries can be depended on by libbitcoin_server.a, libbitcoin_wallet.a, and libbitcoinqt.a, and they can depend on libbitcoin_consensus.a. If we want to split util and common up, as opposed to merging them together, then util shouldn’t depend on libconsensus, but common should.

    Over time, I think it’d be nice if source code organization reflected library organization . I think it’d be nice if all libbitcoin_util source files lived in src/util, all libbitcoin_consensus.a source files lived in src/consensus, and all libbitcoin_server.a code lived in src/node (and maybe the library was called libbitcoin_node.a).

  21. jnewbery commented at 9:36 pm on April 2, 2019: member

    I split this PR into smaller commits to help my review: https://github.com/jnewbery/bitcoin/tree/pr15638_8 . I pushed each commit as a separate branch on my fork to be built by travis: https://travis-ci.org/jnewbery/bitcoin/builds.

    I personally find this easier to review as each move is justified by its commit log.

    I’ll describe how I was thinking about this below […] here is how I am thinking about the organization

    This is really useful. Would you mind opening an issue with basically the description you’ve given above. I think it’d be useful to have as a reference for how we think the code organization should be moving, and as a place to solicit feedback from other contributors.

  22. jnewbery commented at 9:39 pm on April 2, 2019: member

    @laanwj has also expressed a desire to reorganize the source code (https://github.com/bitcoin/bitcoin/issues/15465#issuecomment-475850089):

    What kind of frustrates me, personally, is that we didn’t manage to clearly separate out the consensus parts. Not to a library (which would be useful for rust-bitcoin et al), but also not even to a separate directory.

  23. Empact commented at 5:40 am on April 3, 2019: member

    Here are 2 revised proposals, related to the earlier work:

    https://github.com/Empact/bitcoin/commit/c72764eccd5d769f2574bcdc39a992cab11d4048 - Moves TransactionError to its own file, src/transaction_error.h, revises includes to require the more narrow transaction_error rather than node/transaction where appropriate.

    https://github.com/Empact/bitcoin/commit/90293e6c25f691bdf2218b1c37e98f14394f48df - Now just makes util/fees.h the source for FeeEstimateMode, FeeReason, and related methods, so that their declarations and definitions are in a common location.

    Based on the current pr/link

  24. practicalswift commented at 7:42 am on April 3, 2019: contributor
    Concept ACK
  25. ryanofsky force-pushed on Apr 3, 2019
  26. ryanofsky commented at 5:36 pm on April 3, 2019: member
    Updated 9742ff8d79402607159488eed362b7eb08580114 -> fee746f72ba53642bfd1000b6cd215048ad06920 (pr/link.6 -> pr/link.7, compare) to John’s branch pr15638_8, adding a minor fix to the fourth commit (118f5fd992b517d00d7646b3f7da21684541e650), which didn’t compile
  27. DrahtBot added the label Needs rebase on Apr 6, 2019
  28. ryanofsky commented at 9:41 pm on April 8, 2019: member
    Rebased fee746f72ba53642bfd1000b6cd215048ad06920 -> b0ba5d943100857daeb0904a01f096aad0cda697 (pr/link.7 -> pr/link.8) due to conflict with #15508. Text merge conflict was limited to src/Makefile.am, but #15508 also required adding a new commit: “[build] Move AnalyzePSBT from psbt.cpp to node/psbt.cpp” (b0ba5d943100857daeb0904a01f096aad0cda697)
  29. ryanofsky force-pushed on Apr 8, 2019
  30. DrahtBot removed the label Needs rebase on Apr 8, 2019
  31. jnewbery commented at 4:10 pm on April 9, 2019: member
    tested ACK b0ba5d943100857daeb0904a01f096aad0cda697
  32. laanwj commented at 5:50 pm on April 9, 2019: member
    Concept ACK
  33. [build] Move CheckTransaction from lib_server to lib_consensus
    CheckTransaction is a context-free function that does not require access
    to the blockchain or mempool. Move it from src/consensus/tx_verify in
    lib_server to a new unit src/consensus/tx_check in lib_consensus so that
    it can be called by non-server libraries.
    fdf8888b6f
  34. [build] Move policy settings to new src/policy/settings unit
    This moves the following policy settings functions and globals to a new
    src/policy/settings unit in lib_server:
    
    - `incrementalRelayFee`
    - `dustRelayFee`
    - `nBytesPerSigOp`
    - `fIsBareMultisigStd`
    
    These settings are only required by the node and should not be accessed
    by other libraries.
    4a75c9d651
  35. [build] Move rpc utility methods to rpc/util
    Moves the following utility methods to rpc/util and moves that unit to
    libbitcoin_common so they can be accessed by all libraries.
    
    - `RPCTypeCheck`
    - `RPCTypeCheckArgument`
    - `RPCTypeCheckObj`
    - `AmountFromValue`
    - `ParseHashV``ParseHashO`
    - `ParseHexV`
    - `ParseHexO`
    - `HelpExampleCli`
    - `HelpExampleRpc`
    1acc61f874
  36. [build] Move rpc rawtransaction util functions to rpc/rawtransaction_util.cpp
    rpc/rawtransaction.cpp moves to libbitcoin_server since it should not be
    accessed by non-node libraries. The utility following utility methods
    move to their own unit rpc/rawtransaction_util since they need to be
    accessed by non-node libraries:
    
    - `ConstructTransaction`
    - `TxInErrorToJSON`
    - `SignTransaction`
    0509465542
  37. [build] Move several units into common libraries
    Moves the following units into libbitcoin_util or libbitcoin_common
    since they are required by multiple libraries:
    
    - bloom
    - interfaces/handler
    - merkleblock
    - outputtype
    99517866b6
  38. [build] Add several util units
    Adds the following util units and adds them to libbitcoin_util:
    
    - `util/url.cpp` takes `urlDecode` from `httpserver.cpp`
    - `util/error.cpp` takes `TransactionErrorString` from
      `node/transaction.cpp` and `AmountHighWarn` and `AmountErrMsg` from
      `ui_interface.cpp`
    - `util/fees.cpp` takes `StringForFeeReason` and `FeeModeFromString` from `policy/fees.cpp`
    - `util/rbf.cpp` takes `SignalsOptInRBF` from `policy/rbf.cpp`
    - 'util/validation.cpp` takes `FormatStateMessage` and `strMessageMagic` from 'validation.cpp`
    91a25d1e71
  39. [build] Move wallet load functions to wallet/load unit
    Moves the following wallet load functions to a new wallet/load unit in
    the libbitcoin_wallet library. All other functions in wallet/init remain
    in libbitcoin_server:
    
    - `VerifyWallets`
    - `LoadWallets`
    - `StartWallets`
    - `FlushWallets`
    - `StopWallets`
    - `UnloadWallets`
    9eaeb7fb8d
  40. [docs] Document src subdirectories and different libraries fd509bd1f7
  41. [build] Move AnalyzePSBT from psbt.cpp to node/psbt.cpp
    psbt.cpp definitions except for AnalyzePSBT are used by the wallet and need to
    be linked into the wallet binary. AnalyzePSBT is an exception in that it is not
    used by the wallet, and depends on node classes like CCoinsViewCache, and on
    node global variables like nBytesPerSigOp.
    
    So AnalyzePSBT is more at home in libbitcoin_server than libbitcoin_common, and
    in any case needs to be defined in a separate object file than other PSBT
    utilities, to avoid dragging link dependencies on node functions and global
    variables into the wallet.
    4d074e84a2
  42. DrahtBot added the label Needs rebase on Apr 9, 2019
  43. ryanofsky force-pushed on Apr 10, 2019
  44. DrahtBot removed the label Needs rebase on Apr 10, 2019
  45. ryanofsky commented at 12:15 pm on April 10, 2019: member
    Rebased b0ba5d943100857daeb0904a01f096aad0cda697 -> 4d074e84a2cf419510e2920417799f62747f4b07 (pr/link.8 -> pr/link.9) due to conflict with #15632
  46. jnewbery commented at 1:18 pm on April 10, 2019: member
    utACK 4d074e84a2cf419510e2920417799f62747f4b07 (checked by doing the rebase myself and verifying no difference between my branch and 4d074e84a2cf419510e2920417799f62747f4b07)
  47. jnewbery commented at 1:18 pm on April 10, 2019: member

    @laanwj - do you mind moving discussion of source code organization to #15732?

    Edit: done

    Edit: Thanks :slightly_smiling_face:

  48. laanwj commented at 1:52 pm on April 10, 2019: member
    utACK 4d074e84a2cf419510e2920417799f62747f4b07
  49. laanwj merged this on Apr 10, 2019
  50. laanwj closed this on Apr 10, 2019

  51. laanwj referenced this in commit 6a135fbe5b on Apr 10, 2019
  52. meshcollider referenced this in commit 703414994a on Apr 27, 2019
  53. sidhujag referenced this in commit cd95cb552d on Apr 27, 2019
  54. MarcoFalke referenced this in commit 00ffe5aca1 on Aug 19, 2019
  55. deadalnix referenced this in commit a482f6fb1f on May 5, 2020
  56. deadalnix referenced this in commit eb5113eaa6 on May 6, 2020
  57. deadalnix referenced this in commit 6cf20d4d41 on May 6, 2020
  58. deadalnix referenced this in commit 812563f7a7 on May 6, 2020
  59. deadalnix referenced this in commit 7dce6a570d on May 7, 2020
  60. deadalnix referenced this in commit 8865cda0ec on May 7, 2020
  61. deadalnix referenced this in commit 27b02121a3 on May 10, 2020
  62. deadalnix referenced this in commit 11157b13e9 on May 10, 2020
  63. deadalnix referenced this in commit e004892484 on May 16, 2020
  64. jasonbcox referenced this in commit 1f1482f548 on Jun 30, 2020
  65. ftrader referenced this in commit 8a676ac858 on Aug 17, 2020
  66. kittywhiskers referenced this in commit b5337a1f9a on Jun 16, 2021
  67. kittywhiskers referenced this in commit e52cf0848d on Jun 16, 2021
  68. kittywhiskers referenced this in commit 6ccb59aaeb on Jun 24, 2021
  69. kittywhiskers referenced this in commit 53141092a4 on Jun 25, 2021
  70. kittywhiskers referenced this in commit b570fb65bf on Jun 25, 2021
  71. kittywhiskers referenced this in commit debae29066 on Jun 26, 2021
  72. kittywhiskers referenced this in commit 0f7ddfa24d on Jun 26, 2021
  73. kittywhiskers referenced this in commit 7b27be4533 on Jun 27, 2021
  74. kittywhiskers referenced this in commit 138997c8e6 on Jun 27, 2021
  75. UdjinM6 referenced this in commit 7d664c7c53 on Jun 27, 2021
  76. kittywhiskers referenced this in commit 27ec275693 on Aug 5, 2021
  77. kittywhiskers referenced this in commit 8947e014d0 on Aug 5, 2021
  78. kittywhiskers referenced this in commit f10761e9be on Aug 5, 2021
  79. PastaPastaPasta referenced this in commit a4480add0b on Aug 6, 2021
  80. kittywhiskers referenced this in commit 87d805bf18 on Aug 8, 2021
  81. kittywhiskers referenced this in commit 6741d9837a on Aug 11, 2021
  82. 5tefan referenced this in commit 8336e8e59c on Aug 12, 2021
  83. kittywhiskers referenced this in commit 485e0e23b8 on Nov 1, 2021
  84. kittywhiskers referenced this in commit de7ad9c1d3 on Nov 1, 2021
  85. kittywhiskers referenced this in commit 43a684efc5 on Nov 1, 2021
  86. kittywhiskers referenced this in commit bbb9187803 on Nov 1, 2021
  87. kittywhiskers referenced this in commit 1be0455b49 on Nov 1, 2021
  88. kittywhiskers referenced this in commit 8cff32cb44 on Nov 1, 2021
  89. kittywhiskers referenced this in commit 174642b19c on Nov 1, 2021
  90. kittywhiskers referenced this in commit e7e6ba5119 on Nov 1, 2021
  91. kittywhiskers referenced this in commit 4ce91ac0ed on Nov 1, 2021
  92. kittywhiskers referenced this in commit 3f0b22dbea on Nov 1, 2021
  93. kittywhiskers referenced this in commit 7e3424b636 on Nov 1, 2021
  94. kittywhiskers referenced this in commit 0f4ab7ed1f on Nov 1, 2021
  95. kittywhiskers referenced this in commit 90e8dbb8b1 on Nov 1, 2021
  96. kittywhiskers referenced this in commit 482941463f on Nov 1, 2021
  97. kittywhiskers referenced this in commit baa6c60a01 on Nov 2, 2021
  98. kittywhiskers referenced this in commit 0509b1f541 on Nov 2, 2021
  99. kittywhiskers referenced this in commit 031f3d7e91 on Nov 2, 2021
  100. kittywhiskers referenced this in commit f03b14e665 on Nov 2, 2021
  101. kittywhiskers referenced this in commit 980f52b8f6 on Nov 2, 2021
  102. kittywhiskers referenced this in commit 8bb6ceb47f on Nov 2, 2021
  103. kittywhiskers referenced this in commit e206f60a14 on Nov 2, 2021
  104. kittywhiskers referenced this in commit 52ad45dc01 on Nov 4, 2021
  105. kittywhiskers referenced this in commit 78018d85a8 on Nov 4, 2021
  106. kittywhiskers referenced this in commit 823b3ae56a on Nov 4, 2021
  107. kittywhiskers referenced this in commit def23b45c9 on Nov 4, 2021
  108. kittywhiskers referenced this in commit 6e972c2e0b on Nov 4, 2021
  109. kittywhiskers referenced this in commit f34d2dd1cf on Nov 4, 2021
  110. kittywhiskers referenced this in commit 76d6871085 on Nov 4, 2021
  111. kittywhiskers referenced this in commit b4369ed0a5 on Nov 15, 2021
  112. kittywhiskers referenced this in commit de507ee9e1 on Nov 15, 2021
  113. kittywhiskers referenced this in commit da77e27049 on Nov 15, 2021
  114. kittywhiskers referenced this in commit 234bd1cd60 on Nov 15, 2021
  115. kittywhiskers referenced this in commit 10c5ace7a1 on Nov 15, 2021
  116. kittywhiskers referenced this in commit 94587d493e on Nov 15, 2021
  117. kittywhiskers referenced this in commit c40c3b77ec on Nov 15, 2021
  118. PastaPastaPasta referenced this in commit d978259654 on Nov 16, 2021
  119. pravblockc referenced this in commit 667d0fae1f on Nov 18, 2021
  120. vijaydasmp referenced this in commit 868efabd18 on Dec 7, 2021
  121. vijaydasmp referenced this in commit e17c086876 on Dec 11, 2021
  122. vijaydasmp referenced this in commit 6c650b3e48 on Dec 13, 2021
  123. vijaydasmp referenced this in commit 71edeac9d3 on Dec 14, 2021
  124. DrahtBot locked this on Dec 16, 2021

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-18 15:12 UTC

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