Refactor: separate wallet from node #10973

pull ryanofsky wants to merge 4 commits into bitcoin:master from ryanofsky:pr/wipc-sep changing 22 files +373 −137
  1. ryanofsky commented at 10:17 pm on August 1, 2017: member

    This PR is the last in a chain of PRs (#14437, #14711, and #15288) that make the wallet code access node state through an abstract Chain class in src/interfaces/ instead of using global variables like cs_main, chainActive, and g_connman. After this PR, wallet code no longer accesses global variables declared outside the wallet directory, and no longer calls functions accessing those globals (as verified by the hide-globals script in #10244).

    This PR and the previous PRs have been refactoring changes that do not affect behavior. Previous PRs have consisted of lots of mechanical changes like:

    0-    wtx.nTimeReceived = GetAdjustedTime();
    1+    wtx.nTimeReceived = m_chain->getAdjustedTime();
    

    This PR is smaller, but less mechanical. It replaces last few bits of wallet code that access node state directly (through CValidationInterface, CRPCTable, and CCoinsViewMemPool interfaces) with code that uses the Chain interface.

    These changes allow followup PR #10102 (multiprocess gui & wallet PR) to work without any significant updates to wallet code. Additionally they:

    • Provide a single place to describe the interface between wallet and node code.
    • Can make better wallet testing possible, because the Chain object consists of virtual methods that can be overloaded for mocking. (This could be used to test edge cases in the rescan code, for example).
  2. ryanofsky force-pushed on Aug 2, 2017
  3. ryanofsky referenced this in commit dd4896e35b on Aug 2, 2017
  4. jonasschnelli commented at 9:41 am on August 3, 2017: contributor
    Concept ACK
  5. jonasschnelli added the label Wallet on Aug 3, 2017
  6. jonasschnelli added the label Refactoring on Aug 3, 2017
  7. ryanofsky force-pushed on Aug 14, 2017
  8. ryanofsky renamed this:
    WIP: Add IPC layer between node and wallet
    Add IPC layer between node and wallet
    on Aug 14, 2017
  9. ryanofsky referenced this in commit d97fe2016c on Aug 14, 2017
  10. practicalswift referenced this in commit eedffefa63 on Aug 15, 2017
  11. practicalswift referenced this in commit 9c5bca3091 on Aug 15, 2017
  12. practicalswift referenced this in commit e03c9b0c3d on Aug 15, 2017
  13. practicalswift referenced this in commit bc60c2c228 on Aug 16, 2017
  14. practicalswift referenced this in commit d1010e6ab3 on Aug 16, 2017
  15. ryanofsky force-pushed on Aug 16, 2017
  16. practicalswift referenced this in commit b664be4ba8 on Aug 22, 2017
  17. ryanofsky force-pushed on Aug 25, 2017
  18. laanwj referenced this in commit 07c92b98e2 on Aug 25, 2017
  19. ryanofsky force-pushed on Aug 25, 2017
  20. ryanofsky force-pushed on Aug 29, 2017
  21. ryanofsky commented at 5:05 pm on September 1, 2017: member
    @jnewbery, the change to stop deduping link arguments is in Makefile.am here
  22. in src/ipc/local/bitcoind.cpp:178 in c1194635c6 outdated
    105+        auto it = ::mapBlockIndex.find(hash);
    106+        if (it == ::mapBlockIndex.end()) {
    107+            return false;
    108+        }
    109+        if (block) {
    110+            if (!ReadBlockFromDisk(*block, it->second, Params().GetConsensus())) {
    


    JeremyRubin commented at 9:32 pm on September 5, 2017:
    Maybe block && !ReadBlockFromDisk

    ryanofsky commented at 4:54 pm on September 21, 2017:

    Maybe block && !ReadBlockFromDisk

    Thanks, done in f98a13387d8c409153748996a64eb6051cfecfec

  23. in src/ipc/interfaces.h:39 in c1194635c6 outdated
    25@@ -23,6 +26,68 @@ class Chain
    26     {
    27     public:
    28         virtual ~LockedState() {}
    29+
    


    JeremyRubin commented at 9:50 pm on September 5, 2017:
    Maybe this would be a good place to use boost::option to simplify this API – would be much clearer to get back Some(Height) | Nothing or Some(Depth) | Nothing than having semantics around if the invalid return is -1 or 0.

    ryanofsky commented at 9:47 pm on September 22, 2017:

    Maybe this would be a good place to use boost::option to simplify this API – would be much clearer to get back Some(Height) | Nothing or Some(Depth) | Nothing than having semantics around if the invalid return is -1 or 0.

    Done in 4b2ae4761c9e75e2d39ce46671d4562b28e54e6f. I’m not sure if it is a simplification, but it is definitely safer and probably clearer. Leaving it unsquashed for now, since there might be differing opinions.

  24. in src/init.cpp:885 in 5269b56ec4 outdated
    887@@ -887,7 +888,7 @@ bool AppInitBasicSetup()
    888     return true;
    889 }
    890 
    891-bool AppInitParameterInteraction()
    892+bool AppInitParameterInteraction(ipc::Chain& ipc_chain, ipc::Chain::Clients& ipc_clients)
    


    JeremyRubin commented at 11:02 pm on September 5, 2017:
    Can we have something that wraps both ipc_chain and ipc_clients for passing in? Is there a reason to have them separate? I don’t want to add another useless class, it just seems they are always passed around together & are created together.

    ryanofsky commented at 4:53 pm on September 21, 2017:

    Can we have something that wraps both ipc_chain and ipc_clients for passing in? Is there a reason to have them separate? I don’t want to add another useless class, it just seems they are always passed around together & are created together.

    Good suggestion. I wrapped these in the InitInterfaces struct which simplified some things.

  25. in src/ipc/interfaces.h:35 in e26e00bd3f outdated
    13@@ -14,6 +14,26 @@ class Chain
    14 public:
    15     virtual ~Chain() {}
    16 
    17+    //! Interface for querying locked chain state, used by legacy code that
    18+    //! assumes state won't change between calls. New code should avoid using
    19+    //! the LockedState interface and instead call higher-level Chain methods
    20+    //! that return more information so the chain doesn't need to stay locked
    21+    //! between calls.
    22+    class LockedState
    


    JeremyRubin commented at 11:22 pm on September 5, 2017:
    nit: semantics of name LockedState is maybe a bit clearer as ChainStateLock?

    ryanofsky commented at 4:53 pm on September 21, 2017:

    nit: semantics of name LockedState is maybe a bit clearer as ChainStateLock?

    This is now named Chain::Lock, which hopefully is clearer. I kind of wanted to chose a shorter name because locked_chain variables so commonly used in https://github.com/ryanofsky/bitcoin/blob/pr/wipc-sep/src/wallet/wallet.cpp after this.

  26. JeremyRubin commented at 11:27 pm on September 5, 2017: contributor

    I did a superficial review of the code & the approach seems reasonable to me!

    utACKs from me for the commits checked below…

    • 40afc26350 Add skeleton chain and client classes
    • 5269b56ec4 Pass chain and client variables where needed
    • 7bfb409ad9 Remove uses of wallet functions in init.cpp
    • e26e00bd3f Remove uses of cs_main in wallet code
    • 0a3464bce7 Pass chain locked variables where needed
    • c1194635c6 Remove uses of chainActive and mapBlockIndex in wallet code
    • 2dd492b580 Remove uses of CheckFinalTx in wallet code
    • ebb23cbe04 Remove use of IsWitnessEnabled in wallet code
    • dd180da24b Remove use of AcceptToMemoryPool in wallet code
    • 83be2e6552 Remove uses of GetVirtualTransactionSize in wallet code
    • 8931629480 Remove use of IsRBFOptIn in wallet code
    • 684e807240 Remove use of GetCountWithDescendants in wallet code
    • f3f36e8b5f Remove use of g_connman / PushInventory in wallet code
    • c9d049c7e4 Remove use of TransactionWithinChainLimit in wallet code
    • 04f6a9ecc1 Remove use of CalculateMemPoolAncestors in wallet code
    • c510dde004 Remove uses of fee globals in wallet code
    • 9849c4d441 Remove uses of fPruneMode in wallet code
    • ab488c8229 Remove uses of g_connman in wallet code
    • 090411ad7c Remove uses of GetAdjustedTime in wallet code
    • 64ad91dbf5 Remove uses of InitMessage/Warning/Error in wallet code
    • 3ab3335d38 Remove use CValidationInterface in wallet code
    • 8756810d58 Remove use of CRPCTable::appendCommand in wallet code
    • 35bfb7f189 Remove use of generateBlocks in wallet code
    • 8fb011e3fb Remove uses of ParseConfirmTarget in wallet code
  27. ryanofsky force-pushed on Sep 21, 2017
  28. ryanofsky force-pushed on Sep 21, 2017
  29. ryanofsky force-pushed on Sep 21, 2017
  30. ryanofsky force-pushed on Sep 22, 2017
  31. ryanofsky force-pushed on Sep 22, 2017
  32. ryanofsky referenced this in commit 2015123310 on Sep 22, 2017
  33. ryanofsky force-pushed on Sep 27, 2017
  34. ryanofsky referenced this in commit 4b2ae4761c on Sep 27, 2017
  35. mempko referenced this in commit 7454f784fa on Sep 28, 2017
  36. mempko referenced this in commit bdbd3fff37 on Sep 28, 2017
  37. practicalswift referenced this in commit 27a54eacc0 on Oct 2, 2017
  38. practicalswift referenced this in commit da4b7a5c4c on Oct 17, 2017
  39. practicalswift referenced this in commit ad6d73b342 on Oct 18, 2017
  40. practicalswift referenced this in commit 86179897e2 on Nov 9, 2017
  41. ryanofsky force-pushed on Nov 28, 2017
  42. ryanofsky renamed this:
    Add IPC layer between node and wallet
    Refactor: separate wallet from node
    on Dec 1, 2017
  43. ryanofsky force-pushed on Dec 1, 2017
  44. ryanofsky force-pushed on Dec 12, 2017
  45. ryanofsky force-pushed on Dec 14, 2017
  46. ryanofsky force-pushed on Dec 31, 2017
  47. ryanofsky force-pushed on Jan 11, 2018
  48. ryanofsky force-pushed on Jan 11, 2018
  49. ryanofsky force-pushed on Feb 1, 2018
  50. ryanofsky force-pushed on Feb 9, 2018
  51. ryanofsky force-pushed on Feb 12, 2018
  52. ryanofsky force-pushed on Feb 14, 2018
  53. ryanofsky force-pushed on Feb 14, 2018
  54. ryanofsky force-pushed on Feb 23, 2018
  55. ryanofsky force-pushed on Feb 26, 2018
  56. ryanofsky force-pushed on Mar 2, 2018
  57. ryanofsky force-pushed on Mar 7, 2018
  58. ryanofsky force-pushed on Mar 7, 2018
  59. HashUnlimited referenced this in commit c42321bc79 on Mar 9, 2018
  60. ryanofsky force-pushed on Mar 12, 2018
  61. HashUnlimited referenced this in commit f767ebe622 on Mar 13, 2018
  62. ryanofsky force-pushed on Mar 14, 2018
  63. ryanofsky force-pushed on Mar 14, 2018
  64. ryanofsky force-pushed on Mar 14, 2018
  65. ryanofsky force-pushed on Mar 23, 2018
  66. ryanofsky force-pushed on Mar 31, 2018
  67. ryanofsky force-pushed on Apr 6, 2018
  68. ryanofsky force-pushed on Apr 7, 2018
  69. ryanofsky force-pushed on Apr 9, 2018
  70. in src/interfaces/chain.cpp:33 in 419308f3c8 outdated
    36+#endif
    37+
    38+#include <algorithm>
    39+#include <future>
    40+#include <map>
    41+#include <memory>
    


    MarcoFalke commented at 3:54 pm on April 9, 2018:
    0Include(s) from src/interfaces/chain.h duplicated in src/interfaces/chain.cpp:
    1#include <memory>
    2Include(s) from src/interfaces/wallet.h duplicated in src/interfaces/wallet.cpp:
    3#include <memory>
    4#include <string>
    5#include <utility>
    6#include <vector>
    7Include(s) from src/wallet/init.h duplicated in src/wallet/init.cpp:
    8#include <walletinitinterface.h>
    9^---- failure generated from contrib/devtools/lint-includes.sh
    

    ryanofsky commented at 10:45 am on April 10, 2018:

    failure generated from contrib/devtools/lint-includes.sh

    I’ll try to submit a pr to simplify the developer guideline and this lint check. This check is incompatible with the iwyu tool, and I think “include what you use” is a better and simpler policy than “include what you use most of the time but not if the same include line appears in a different file”


    MarcoFalke commented at 1:07 pm on April 10, 2018:
    @ryanofsky Agree with you here. I merged that pull request because it had some acks and no nack, afaics. I am happy to ACK a pull that adjusts the developer guidelines and removes the lint check.
  71. ryanofsky force-pushed on Apr 10, 2018
  72. ryanofsky commented at 1:38 pm on April 10, 2018: member

    @skeees, this PR might be relevant to the GetDepthInMainChain discussion from #12801 (comment). This PR replaces direct accesses to chainActive and cs_main global variables in the wallet with calls to a Chain::Lock interface:

    https://github.com/bitcoin/bitcoin/blob/6efd1524caf008641c4ffc15e8a2b2c2586c6d0f/src/interfaces/chain.h#L42-L111

    If you look at wallet.cpp and search for locked_chain, you can see all the things the wallet is currently doing while assuming the chain is locked.

    Ideally we would like to eliminate these locked_chain objects, or make them very rarely used. I think the single change that would eliminate most uses of locked_chain would be to add an m_last_block_processed_height member to CWallet and an m_block_height member to CMerkleTx. These variables could get updated in BlockConnected, so methods like GetDepthInMainChain, IsInMainChain, and GetBlocksToMaturity could be implemented without external locking.

    This is a change which I think could be implemented right now in a new PR that doesn’t depend on anything. And there are probably other similar changes which could eliminate more locking and which your #12801 notifier might come in handy for.

  73. JeremyRubin commented at 6:24 pm on April 10, 2018: contributor
    It might also be decent to use a RW-lock – I’d imagine all of the wallet code is only in read mode, and a good chunk of other code can run in read mode as well.
  74. MarcoFalke referenced this in commit 3cf76c23fb on Apr 11, 2018
  75. ryanofsky force-pushed on Apr 11, 2018
  76. ryanofsky commented at 3:22 pm on April 11, 2018: member

    It might also be decent to use a RW-lock – I’d imagine all of the wallet code is only in read mode,

    This is a really interesting suggestion and observation. The benefit of using a RW lock would be that multiple wallets could hold the lock at same time, though I think we’d also need to prevent the wallets from blocking the SingleThreadedSchedulerClient notification thread to really take advantage of this.

    Another way to take advantage of the read-only nature of the wallet client might be to change the Chain::Lock class to not even hold onto cs_main at all, but just present a locked view of the chain while still allowing updates to happen, mvcc-like. This would actually be pretty easy to implement by just saving the current chain tip in the constructor, and using it in all the other methods. But I imagine this could create subtle bugs and make generally things harder to reason about, so I’m still inclined to think getting rid of Chain::Lock is the best outcome, even though it will involve storing more state in the wallet. Getting rid of Chain::Lock could also be a nice way to avoid IPC overhead in addition to lock contention.


    Rebased 6efd1524caf008641c4ffc15e8a2b2c2586c6d0f -> 085519d9893a928c6bf60596305d6c257bf58725 (pr/wipc-sep.41 -> pr/wipc-sep.42) due to conflicts with #12749, #12920, #12925 Rebased 085519d9893a928c6bf60596305d6c257bf58725 -> 22e6aad5b62545bf254df97f885635eb42f5abdd (pr/wipc-sep.42 -> pr/wipc-sep.43) due to conflicts with #12977 Rebased 22e6aad5b62545bf254df97f885635eb42f5abdd -> daa337627f2181c360d775761a8d6829803ab915 (pr/wipc-sep.43 -> pr/wipc-sep.44) due to conflicts with #12949 Updated daa337627f2181c360d775761a8d6829803ab915 -> 337d4535fe7a319f9628379378704e407dffa254 (pr/wipc-sep.44 -> pr/wipc-sep.45) to remove orphaned wallet/init.h header file from previous rebase. Rebased 337d4535fe7a319f9628379378704e407dffa254 -> d061f3511060996421bec36bc83b701fbd47bb64 (pr/wipc-sep.45 -> pr/wipc-sep.46) due to conflict with #13017 Rebased d061f3511060996421bec36bc83b701fbd47bb64 -> 16f0e2fa5530848e48ad4d9359430f5156966da9 (pr/wipc-sep.46 -> pr/wipc-sep.47) due to conflicts with #12909, #12953, #12830 Rebased 16f0e2fa5530848e48ad4d9359430f5156966da9 -> 60c7f5eb5af9390e16307796e05c13a24a63fdee (pr/wipc-sep.47 -> pr/wipc-sep.48) due to conflict with #13033 Rebased 60c7f5eb5af9390e16307796e05c13a24a63fdee -> b4245a5697ed2006c3bc92a2183563264e0632ed (pr/wipc-sep.48 -> pr/wipc-sep.49) due to conflict with #13090 Rebased b4245a5697ed2006c3bc92a2183563264e0632ed -> ce6af5dd9e70db2dfcd5d5f1ae10494b5129ff88 (pr/wipc-sep.49 -> pr/wipc-sep.50) due to conflict with #13106

  77. ryanofsky force-pushed on Apr 17, 2018
  78. ryanofsky force-pushed on Apr 17, 2018
  79. ryanofsky force-pushed on Apr 20, 2018
  80. ryanofsky force-pushed on Apr 23, 2018
  81. ryanofsky force-pushed on Apr 25, 2018
  82. ryanofsky force-pushed on Apr 25, 2018
  83. ryanofsky force-pushed on Apr 26, 2018
  84. ryanofsky force-pushed on Apr 27, 2018
  85. in src/qt/test/wallettests.cpp:149 in a0279e4074 outdated
    143@@ -144,7 +144,9 @@ void TestGUI()
    144     for (int i = 0; i < 5; ++i) {
    145         test.CreateAndProcessBlock({}, GetScriptForRawPubKey(test.coinbaseKey.GetPubKey()));
    146     }
    147-    CWallet wallet("mock", WalletDatabase::CreateMock());
    148+    auto node = interfaces::MakeNode();
    149+    node->parseParameters(0, nullptr);
    150+    CWallet wallet(&node->getChain(), "mock", WalletDatabase::CreateMock());
    


    jamesob commented at 6:58 pm on April 30, 2018:

    (in https://github.com/bitcoin/bitcoin/pull/10973/commits/a0279e40745dfb8692e92c5cac0848a25b37f930)

    I think we’ll need to make an equivalent change in addressbooktests.cpp as well.


    ryanofsky commented at 9:28 pm on May 5, 2018:

    #10973 (review)

    I think we’ll need to make an equivalent change in addressbooktests.cpp as well.

    Thanks, moved this change to the right commit (it was in c917d976c039c3bb79bb4a1b7aff72117b066597 instead of a0279e40745dfb8692e92c5cac0848a25b37f930)

  86. in src/interfaces/chain.h:50 in ba1e24b718 outdated
    35+        //! chain only contains genesis block, nothing if chain does not contain
    36+        //! any blocks).
    37+        virtual Optional<int> getHeight() = 0;
    38+
    39+        //! Get block height above genesis block. Returns 0 for genesis block,
    40+        //! for following block, and so on. Returns nothing for a block not
    


    jamesob commented at 8:09 pm on May 1, 2018:

    ryanofsky commented at 9:28 pm on May 5, 2018:

    #10973 (review)

    Should be “1 for following block …”?

    Thanks, fixed in 7f2f5cc41aa05e6f2ad7bfa74173c11136b67cf9

  87. in src/interfaces/chain.h:86 in ba1e24b718 outdated
    71+        //! nothing if no block in the range is pruned. Range is inclusive.
    72+        virtual Optional<int> findPruned(int start_height = 0, Optional<int> stop_height = nullopt) = 0;
    73+
    74+        //! Return height of the highest block on the chain that is an ancestor
    75+        //! of the specified block. Also return the height of the specified
    76+        //! block as an optinal output parameter.
    



    ryanofsky commented at 9:28 pm on May 5, 2018:

    #10973 (review)

    optinal

    Fixed in 6bb7af9b1e41f833389f6d4d7ceb02b947dbfd07

  88. in src/wallet/rpcwallet.cpp:3774 in ba1e24b718 outdated
    3794     }
    3795     UniValue response(UniValue::VOBJ);
    3796-    response.pushKV("start_height", pindexStart->nHeight);
    3797-    response.pushKV("stop_height", stopBlock->nHeight);
    3798+    response.pushKV("start_height", start_height);
    3799+    response.pushKV("stop_height", stop_height ? UniValue(*stop_height) : tip_height ? UniValue(*tip_height): UniValue());
    


    jamesob commented at 8:40 pm on May 1, 2018:
    Are the UniValue calls necessary?

    ryanofsky commented at 9:30 pm on May 5, 2018:

    #10973 (review)

    Are the UniValue calls necessary?

    Good catch, removed in 63dd8abdf822026a4a93356546ff1220e6c00e9e

  89. ryanofsky force-pushed on May 2, 2018
  90. in src/wallet/wallet.cpp:1781 in 7f08793608 outdated
    1806-                if (pindex && !chainActive.Contains(pindex)) {
    1807+                if (!locked_chain->getBlockHeight(block_hash)) {
    1808                     // Abort scan if current block is no longer active, to prevent
    1809-                    // marking transactions as coming from the wrong block.
    1810-                    ret = pindex;
    1811+                    // marking transac<tions as coming from the wrong block.
    



    ryanofsky commented at 9:30 pm on May 5, 2018:

    #10973 (review)

    transac<tions

    Fixed in 62f15da95f7abb4ae0a02517885d7fb69097f698

  91. jamesob commented at 2:47 pm on May 3, 2018: member
    Needs rebase.
  92. ryanofsky force-pushed on May 3, 2018
  93. ryanofsky commented at 3:13 pm on May 3, 2018: member

    Needs rebase.

    Rebased ce6af5dd9e70db2dfcd5d5f1ae10494b5129ff88 -> af8f8087699c30ec83995c54112955253bcaba84 (pr/wipc-sep.50 -> pr/wipc-sep.51) due to conflicts with #12639 and #12507.

    (Reminders to rebase this are welcome, but not needed. Since this conflicts with most wallet prs, I tend to check this frequently and rebase it a few times per week).

  94. in src/interfaces/chain.cpp:381 in 7a6069a3c5 outdated
    339+        // inside the RPC request for wallet name and sending it directly to the
    340+        // right handler), but right now all wallets are in-process so there is
    341+        // only ever a single handler, and in the future it isn't clear if we
    342+        // will want we want to keep forwarding RPCs at all (clients could just
    343+        // listen for their own RPCs).
    344+        for (auto it = m_commands.begin(); it != m_commands.end();) {
    


    jamesob commented at 5:56 pm on May 3, 2018:

    Any reason you don’t just want to do

    0for (const CRPCCommand* command : m_commands) { ... }
    

    here?


    ryanofsky commented at 9:31 pm on May 5, 2018:

    #10973 (review)

    Any reason you don’t just want to do for (const CRPCCommand* command : m_commands) { … }

    Having access to the iterator makes it possible to detect the last loop iteration and let RPC_WALLET_NOT_FOUND exceptions from the last wallet process get reraised instead of being suppressed.

  95. in src/interfaces/chain.cpp:355 in 604c567e3c outdated
    298@@ -296,6 +299,13 @@ class ChainImpl : public Chain
    299     void initMessage(const std::string& message) override { ::uiInterface.InitMessage(message); }
    300     void initWarning(const std::string& message) override { InitWarning(message); }
    301     void initError(const std::string& message) override { InitError(message); }
    302+    UniValue generateBlocks(std::shared_ptr<CReserveScript> coinbase_script,
    303+        int num_blocks,
    304+        uint64_t max_tries,
    305+        bool keep_script) override
    306+    {
    307+        return ::generateBlocks(coinbase_script, num_blocks, max_tries, keep_script);
    


    jamesob commented at 8:58 pm on May 3, 2018:

    Seems like these instances of straight pass-through to some underlying function may be good cases for templated argument forwarding. I don’t feel strongly either way, but maybe worth considering to cut down on interface duplication?

    I guess if the end objective is to come up with a cross-process interface, duplicating these arguments in the meantime is actually what we want to do.


    ryanofsky commented at 7:36 pm on October 18, 2018:

    re: #10973 (review)

    Seems like these instances of straight pass-through to some underlying function may be good cases for templated argument forwarding.

    I think fully specifying the interface in chain.h is nicer than having to look in different files to see names and types of the arguments. Writing the arguments explicitly also means internal functions can potentially change while the external interface remains stable. And C++ doesn’t really support virtual template functions, so you’d have to rig something up with varargs and std::any to forward arguments without listing names or types. Also, many chain functions here are not just passing their arguments verbatim, so this forwarding couldn’t be used in many cases.

  96. jamesob commented at 9:15 pm on May 3, 2018: member

    utACK https://github.com/bitcoin/bitcoin/pull/10973/commits/af8f8087699c30ec83995c54112955253bcaba84

    I completed a commit-by-commit readthrough of the code and don’t have any substantial feedback aside from a few typos.

    Reviewers will notice that dealing in the more primitive datatypes returned by chain methods (block heights and hashes as opposed to, say, full CBlockIndex values) results in more fiddling at callsites (null checks, arithmetic, subsequent lookups, etc.). This is an obvious drawback, but if we imagine that these calls are happening over a process boundary - as, god willing, they someday will - then the simpler the datatype the better. The stripped-down return types also more tightly accommodate the data requirements of the callers. For these two reasons, this changeset is a big step towards system decomposition IMO.

    Small additional notes:

    • there are some lingering references to chainActive in wallet/test/wallet_tests.cpp; not sure if we want to remove those or not.
    • there’s a forward declaration of CBlockIndex in wallet/wallet.h that doesn’t look necessary anymore.

    I’ll be doing a manual test of this branch in the next few days.

  97. in src/interfaces/node.cpp:55 in af8f808769 outdated
    50@@ -50,6 +51,7 @@ class NodeImpl : public Node
    51 {
    52     void parseParameters(int argc, const char* const argv[]) override
    53     {
    54+        m_interfaces.chain = interfaces::MakeChain();
    


    jnewbery commented at 3:52 pm on May 4, 2018:
    I don’t understand why this is in parseParameters(), rather than a constructor for NodeImpl

    ryanofsky commented at 9:32 pm on May 5, 2018:

    #10973 (review)

    I don’t understand why this is in parseParameters(), rather than a constructor for NodeImpl

    Good suggestion. Moved to constructor in 53a5d3e48093b366e4a227fc9c3e50d7729ba461. An earlier version of #10102 initialized m_interfaces here in order to be able to use the argv[0] directory from the bitcoin-gui process to spawn bitcoin-wallet processes from the bitcoin-node process. But the current version uses bitcoin-node’s argv[0], which is simpler and doesn’t require access to the GUI’s argv.

  98. in src/interfaces/chain.h:220 in af8f808769 outdated
    215+        virtual void registerRpcs() = 0;
    216+
    217+        //! Prepare for execution, loading any needed state.
    218+        virtual bool prepare() = 0;
    219+
    220+        //! Start client execution and provide a scheduler. (Scheduler is
    


    jnewbery commented at 4:15 pm on May 4, 2018:
    I think the (Scheduler is ignored if client is out-of-process). comment can be saved for #10102

    ryanofsky commented at 9:32 pm on May 5, 2018:

    #10973 (review)

    I think the (Scheduler is ignored if client is out-of-process). comment can be saved for #10102

    Sure, removed in 0d9ba1a093e30d77348efc55f0ff6599cef76621.

  99. in src/interfaces/chain.h:70 in af8f808769 outdated
    34+    //! Interface for querying locked chain state, used by legacy code that
    35+    //! assumes state won't change between calls. New code should avoid using
    36+    //! the Lock interface and instead call higher-level Chain methods
    37+    //! that return more information so the chain doesn't need to stay locked
    38+    //! between calls.
    39+    class Lock
    


    jnewbery commented at 6:16 pm on May 4, 2018:
    I find the name of this class quite confusing, since it’s not actually a lock. How about renaming this to LockedChain and renaming LockingStateImpl to ChainLockImpl?

    ryanofsky commented at 9:31 pm on May 5, 2018:

    #10973 (review)

    I find the name of this class quite confusing, since it’s not actually a lock. How about renaming this to LockedChain and renaming LockingStateImpl to ChainLockImpl?

    It is really a lock, analogous to std::unique_lock (and the implementation will even inherit from a class called UniqueLock after #11599 renames CCriticalBlock to UniqueLock).

    I think LockedChain would be a good name if this were not an inner class, but Chain::Lock is less redundant than Chain::LockedChain (or Chain::LockedState, which was what this was called before #10973 (review)).

    LockingStateImpl is temporary (it will go away when assumeLocked is removed), and it’s also internal to chain.cpp, so I can rename it, but I don’t think should be too much concern about it.

  100. in src/wallet/rpcwallet.cpp:3420 in af8f808769 outdated
    3416@@ -3388,7 +3417,8 @@ UniValue fundrawtransaction(const JSONRPCRequest& request)
    3417     CAmount nFeeOut;
    3418     std::string strFailReason;
    3419 
    3420-    if (!pwallet->FundTransaction(tx, nFeeOut, changePosition, strFailReason, lockUnspents, setSubtractFeeFromOutputs, coinControl)) {
    3421+    auto locked_chain = pwallet->chain().assumeLocked();  // Temporary. Removed in upcoming lock cleanup
    


    jnewbery commented at 6:18 pm on May 4, 2018:
    There are 4 of these Temporary. Removed in upcoming lock cleanup comments. Sorry if I missed the answer to this, but what’s the plan for removing them?

    ryanofsky commented at 9:33 pm on May 5, 2018:

    #10973 (review)

    There are 4 of these Temporary. Removed in upcoming lock cleanup comments. Sorry if I missed the answer to this, but what’s the plan for removing them?

    These are introduced in commit 4d11732cc453b8ad5db571491909259fbacd1f51 (Remove uses of cs_main in wallet code), which like other commits in this PR, is just supposed to be mechanical change that doesn’t change behavior.

    The fixes for these comments will depend on the individual situation but will just mean adding required locks that are missing or removing recursive locks that are redundant. As an example, if #10605 is merged, the temporary comment in ListLocked can go away.

  101. in src/interfaces/chain.h:86 in af8f808769 outdated
    81+        //! nothing if no block in the range is pruned. Range is inclusive.
    82+        virtual Optional<int> findPruned(int start_height = 0, Optional<int> stop_height = nullopt) = 0;
    83+
    84+        //! Return height of the highest block on the chain that is an ancestor
    85+        //! of the specified block. Also return the height of the specified
    86+        //! block as an optinal output parameter.
    


    jnewbery commented at 6:35 pm on May 4, 2018:
    s/optinal/optional

    ryanofsky commented at 9:28 pm on May 5, 2018:

    #10973 (review)

    s/optinal/optional

    Fixed in 6bb7af9b1e41f833389f6d4d7ceb02b947dbfd07

  102. in src/wallet/wallet.h:699 in af8f808769 outdated
    696@@ -698,7 +697,7 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
    697 
    698     /* Used by TransactionAddedToMemorypool/BlockConnected/Disconnected.
    699      * Should be called with pindexBlock and posInBlock if this is for a transaction that is included in a block. */
    


    jnewbery commented at 6:42 pm on May 4, 2018:
    Comment is wrong. Needs to be updated to Should be called with non-zero block_hash and posInBlock...

    ryanofsky commented at 9:33 pm on May 5, 2018:

    #10973 (review)

    Comment is wrong. Needs to be updated to Should be called with non-zero block_hash and posInBlock…

    Thanks, fixed in 77cd28c7f5043ff82500fe59936d7a6abc8d0bf6

  103. in src/wallet/wallet.h:752 in af8f808769 outdated
    750@@ -744,7 +751,7 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
    751      *
    752      * Protected by cs_main (see BlockUntilSyncedToCurrentChain)
    


    jnewbery commented at 6:43 pm on May 4, 2018:
    Remove comment

    ryanofsky commented at 9:33 pm on May 5, 2018:

    #10973 (review)

    Remove comment

    Removed in cc2290887af57d60640e7ec90afe2a87dcee3ed7

  104. in src/wallet/rpcdump.cpp:756 in af8f808769 outdated
    755@@ -747,8 +756,9 @@ UniValue dumpwallet(const JSONRPCRequest& request)
    756     // produce output
    757     file << strprintf("# Wallet dump created by Bitcoin %s\n", CLIENT_BUILD);
    758     file << strprintf("# * Created on %s\n", FormatISO8601DateTime(GetTime()));
    759-    file << strprintf("# * Best block at time of backup was %i (%s),\n", chainActive.Height(), chainActive.Tip()->GetBlockHash().ToString());
    760-    file << strprintf("#   mined on %s\n", FormatISO8601DateTime(chainActive.Tip()->GetBlockTime()));
    761+    const Optional<int> tip_height = locked_chain->getHeight();
    762+    file << strprintf("# * Best block at time of backup was %i (%s),\n", tip_height ? *tip_height : -1, tip_height ? locked_chain->getBlockHash(*tip_height).ToString() : "(missing block hash)");
    


    jnewbery commented at 8:46 pm on May 4, 2018:
    The “missing block hash” and “missing block time” outputs here are a change in behaviour (and could potentially break clients using the dumpwallet API)

    ryanofsky commented at 9:32 pm on May 5, 2018:

    #10973 (review)

    The “missing block hash” and “missing block time” outputs here are a change in behaviour (and could potentially break clients using the dumpwallet API)

    I don’t think there is a risk of clients breaking, since the change in behavior is outputting “(missing block hash)” and “(missing block time)” where previously the code would segfault.

  105. in src/wallet/rpcwallet.cpp:1624 in af8f808769 outdated
    2226@@ -2214,39 +2227,41 @@ UniValue listsinceblock(const JSONRPCRequest& request)
    2227 
    2228     bool include_removed = (request.params[3].isNull() || request.params[3].get_bool());
    2229 
    2230-    int depth = pindex ? (1 + chainActive.Height() - pindex->nHeight) : -1;
    2231+    const Optional<int> tip_height = locked_chain->getHeight();
    2232+    int depth = tip_height && height ? (1 + *tip_height - *height) : -1;
    


    jnewbery commented at 9:26 pm on May 4, 2018:
    Can you use locked_chain->getDepth(blockId) here?

    ryanofsky commented at 9:33 pm on May 5, 2018:

    #10973 (review)

    Can you use locked_chain->getDepth(blockId) here?

    I think so, but it seems like it would be deviating unnecessarily from current code and also obscuring relationship between height and depth which is currently explicit here.


    jamesob commented at 7:53 pm on May 8, 2018:
    We need tip_height for later and so using getDepth() would do an extra getHeight() call. But agree that it’s a shame to see the depth arithmetic repeated…
  106. jnewbery commented at 9:39 pm on May 4, 2018: member

    I’ve reviewed the first 5 commits, and everything in Remove uses of chainActive and mapBlockIndex in wallet code except for wallet.cpp. Will continue on Monday.

    A few questions/comments inline.

  107. in src/wallet/wallet.cpp:1786 in af8f808769 outdated
    1778-            LOCK(cs_main);
    1779-            tip = chainActive.Tip();
    1780-            dProgressStart = GuessVerificationProgress(chainParams.TxData(), pindex);
    1781-            dProgressTip = GuessVerificationProgress(chainParams.TxData(), tip);
    1782+            auto locked_chain = m_chain->lock();
    1783+            if (Optional<int> tip_height = locked_chain->getHeight()) {
    


    jnewbery commented at 2:42 pm on May 7, 2018:
    Would it make sense to have a Chain::Lock.getTip() to just return the tip hash?

    ryanofsky commented at 4:40 pm on May 8, 2018:

    #10973 (review)

    Would it make sense to have a Chain::Lock.getTip() to just return the tip hash?

    I started to implement this and look for different places where getTip could be used, and found that this was actually the only place it would remove any code. So I think it doesn’t make sense to add for now.

  108. in src/wallet/wallet.cpp:3822 in af8f808769 outdated
    3817@@ -3795,8 +3818,9 @@ void CWallet::GetKeyBirthTimes(std::map<CTxDestination, int64_t> &mapKeyBirth) c
    3818     }
    3819 
    3820     // map in which we'll infer heights of other keys
    3821-    CBlockIndex *pindexMax = chainActive[std::max(0, chainActive.Height() - 144)]; // the tip can be reorganized; use a 144-block safety margin
    3822-    std::map<CKeyID, CBlockIndex*> mapKeyFirstBlock;
    3823+    const Optional<int> tip_height = locked_chain.getHeight();
    3824+    const int pindexMax = tip_height && *tip_height > 144 ? *tip_height - 144 : 0; // the tip can be reorganized; use a 144-block safety margin
    


    jnewbery commented at 3:42 pm on May 7, 2018:
    This variable isn’t a pointer to a CBlockIndex, and should be named max_height or similar.

    ryanofsky commented at 4:40 pm on May 8, 2018:

    #10973 (review)

    This variable isn’t a pointer to a CBlockIndex, and should be named max_height or similar.

    Renamed as suggested in 63158224c69bd3d3621569a42132012ad186eb76.

  109. in src/wallet/wallet.cpp:4185 in af8f808769 outdated
    4191+        if (chain.getPruneMode())
    4192         {
    4193-            CBlockIndex *block = chainActive.Tip();
    4194-            while (block && block->pprev && (block->pprev->nStatus & BLOCK_HAVE_DATA) && block->pprev->nTx > 0 && pindexRescan != block)
    4195-                block = block->pprev;
    4196+            int block = *tip_height;
    


    jnewbery commented at 5:49 pm on May 7, 2018:
    would block_height or block_index be a better variable name here?

    ryanofsky commented at 4:41 pm on May 8, 2018:

    #10973 (review)

    would block_height or block_index be a better variable name here?

    Yes, I think so and went with block_height in b2224a586fd6d9f186f9b45a778f70b7294bb83c.

  110. in src/interfaces/chain.h:67 in af8f808769 outdated
    62+        virtual int64_t getBlockTime(int height) = 0;
    63+
    64+        //! Get block median time past.
    65+        virtual int64_t getBlockMedianTimePast(int height) = 0;
    66+
    67+        //! Check if block is empty.
    


    jnewbery commented at 5:51 pm on May 7, 2018:

    I think this comment should make clear that the block must be available on disk:

    Check that the full block is available on disk (ie has not been pruned), and contains transactions.


    jnewbery commented at 5:59 pm on May 7, 2018:
    In fact, I think this function is misnamed. What we’re interested in is whether the block is available on disk or not. The ‘block contains transactions’ conditional test was added here: https://github.com/bitcoin/bitcoin/commit/7e6569ea5be8cb26454ede3efb6a50b393aaa9be (comment here: #6057 (comment)). I suggest renaming the function to haveBlockOnDisk() or similar.

    ryanofsky commented at 4:39 pm on May 8, 2018:

    #10973 (review)

    I think this comment should make clear that the block must be available on disk:

    Renamed as suggested and added your comment in 731b02dd1885e5d7242c894d14054ead91044550.

  111. in src/interfaces/chain.h:76 in af8f808769 outdated
    71+        //! greater than the given time, or nothing if there is no block with a
    72+        //! high enough timestamp.
    73+        virtual Optional<int> findEarliestAtLeast(int64_t time) = 0;
    74+
    75+        //! Return height of last block in chain with timestamp less than the
    76+        //! given, and height less than or equal to the given, or nothing if
    


    jnewbery commented at 6:05 pm on May 7, 2018:
    Shouldn’t this be “height greater than or equal to the given”? The implementation starts at start_height and moves forwards along the chain.

    ryanofsky commented at 4:39 pm on May 8, 2018:

    #10973 (review)

    Shouldn’t this be “height greater than or equal to the given”?

    Yes you’re right. Updated comment and renamed method to reflect this in d1ea68d7aa0e8a5b7389a38c4176b38bff5e94b4.

  112. jnewbery commented at 6:13 pm on May 7, 2018: member
    Finished reviewing Remove uses of chainActive and mapBlockIndex in wallet code. A few more comments inline.
  113. in src/interfaces/chain.cpp:370 in af8f808769 outdated
    339+        m_commands.erase(std::remove(m_commands.begin(), m_commands.end(), &command));
    340+    }
    341+
    342+    UniValue forwardRequest(const JSONRPCRequest& request) const
    343+    {
    344+        // Simple forwarding of RPC requests. This just sends the request to the
    


    jnewbery commented at 8:23 pm on May 7, 2018:

    Supporting multiple clients makes this more complex than it needs to be.

    This PR would be easier to review if it initially supported just a single client (as we do today). A future PR could extend the RPC forwarding to support multiple clients.


    ryanofsky commented at 4:40 pm on May 8, 2018:

    #10973 (review)

    Supporting multiple clients makes this more complex than it needs to be.

    This PR would be easier to review if it initially supported just a single client (as we do today). A future PR could extend the RPC forwarding to support multiple clients.

    RPC forwarding is complex I think mostly because I tried to make few changes to src/rpc/ and instead do forwarding to wallet clients in a new layer. Making the src/rpc/ code aware of clients and able to disconnect handlers might be a way to make dispatching simpler overall, but would require a larger diff. I’m also not sure it would be useful in the longer run, because it’s probably better for wallet processes to just listen for RPC requests directly instead of having the node process listen and forward requests to them.

    Supporting only one client per RPC method instead of multiple seems like it would be sacrificing correctness and only providing a minor simplification. It would allow getting rid of the try/catch in RpcForwarder::forwardRequest and replacing std::vector<const CRPCCommand*> m_commands; with const CRPCCommand* m_command; but I think that’s it.


    ryanofsky commented at 2:23 am on March 20, 2019:

    re: #10973 (review)

    Supporting multiple clients makes this more complex than it needs to be.

    This should be a lot simpler with commit f157e7a73ba746c38c5437540806151fbfa4b286 replaced by 4e4d9e9f85eaf9c3bec48559bd4cad3e8a9333ca (pr/wipc-sep.101 -> pr/wipc-sep.102).

    Adding a new rpc server removeCommand method allowed dropping the m_rpc_forwarders map and merging the RpcHandler and RpcForwarder classes. Changing rpc server appendCommand to accept multiple commands was also not too hard and allowed getting rid of the RpcForwarder loop and m_commands vector.

  114. jnewbery commented at 8:30 pm on May 7, 2018: member
    Finished initial review of all commits. One more comment inline that I think the RPC forwarding code would be a lot easier to review if it was limited to a single client. Future PRs could add support for multiple clients.
  115. jnewbery commented at 8:33 pm on May 7, 2018: member

    Overall, I think this is a huge improvement. It gives us a well-defined interface between the wallet and node and is a huge step towards separating out the different subsystems. Whether or not we decide to go ahead with process separation, this is very useful work.

    The wallet<->node interface could certainly be tidied up in future PRs. Since this is an internal interface, that shouldn’t stop this PR from being merged as the first step.

  116. ryanofsky force-pushed on May 8, 2018
  117. ryanofsky commented at 10:35 pm on May 8, 2018: member

    Thanks for the reviews!

    Rebased af8f8087699c30ec83995c54112955253bcaba84 -> 1c597aab8749c95f6ceef24d6795781c913f74a3 (pr/wipc-sep.51 -> pr/wipc-sep.52) due to conflicts with #13163 and #13079 Added 15 commits 1c597aab8749c95f6ceef24d6795781c913f74a3 -> 46593b55552f40dfbb72868c822aafd9834e45ee (pr/wipc-sep.52 -> pr/wipc-sep.53, compare) Squashed 46593b55552f40dfbb72868c822aafd9834e45ee -> 1bf534a9f53e5ba6f12f05f5e18739715c821576 (pr/wipc-sep.53 -> pr/wipc-sep.54) Rebased 1bf534a9f53e5ba6f12f05f5e18739715c821576 -> b13720a225f50f9fa96b7e10fda181b1d2770cb8 (pr/wipc-sep.54 -> pr/wipc-sep.55) due to conflicts with #13081 and #12560

  118. ryanofsky force-pushed on May 14, 2018
  119. sipa commented at 7:40 pm on May 17, 2018: member
    Concept ACK on a better defined interface between wallet and node.
  120. promag commented at 7:45 pm on May 17, 2018: member
    Concept ACK, makes sense!
  121. jonasschnelli commented at 7:48 pm on May 17, 2018: contributor
    Concept ACK
  122. MarcoFalke commented at 8:02 pm on May 17, 2018: member
    In case there is agreement to do this change, there should be a plan on how to review and merge without wasting a lot of (re)review and rebase resources. Even though the commits make little sense on their own without the large picture, I assume it would help to split out the mechanical-diff part from the actual code-review part? Also, it should probably wait for the current conflicting high-priority pulls to go in.
  123. jnewbery commented at 8:02 pm on May 17, 2018: member

    Great. 3 concept ACKs!

    Splitting first 6 commits into their own PR could make this easier to review: https://botbot.me/freenode/bitcoin-core-dev/2018-05-17/?msg=100176268&page=4 @ryanofsky - let me know if I can help with that.

  124. ryanofsky force-pushed on May 18, 2018
  125. ryanofsky commented at 8:10 pm on May 18, 2018: member
    Rebased b13720a225f50f9fa96b7e10fda181b1d2770cb8 -> a71c5b8e73d991f28945280c8812fa0c2898a710 (pr/wipc-sep.55 -> pr/wipc-sep.56) due to conflict with #10740
  126. in src/interfaces/chain.h:197 in a71c5b8e73 outdated
    181@@ -182,6 +182,9 @@ class Chain
    182         uint64_t max_tries,
    183         bool keep_script) = 0;
    184 
    185+    //! Parse confirm target.
    186+    virtual unsigned int parseConfirmTarget(const UniValue& value) = 0;
    


    jimpo commented at 9:19 pm on May 18, 2018:
    This feels like a weird method to put in the chain interface because it’s just an RPC helper function. I’d actually rather it be duplicated (though that might still require a maxConfirmTarget method on the interface).

    ryanofsky commented at 8:05 pm on October 29, 2018:

    re: #10973 (review)

    This feels like a weird method to put in the chain interface

    Agree, removed this method.

  127. jimpo commented at 9:22 pm on May 18, 2018: contributor

    Wow, this is heroic. Big Concept ACK. But I would like to see it split into multiple PRs.

    Also, I’ll note that the lowercasing of method names on the interfaces conflicts with the Coding Style.

  128. MarcoFalke commented at 7:50 pm on May 22, 2018: member

    utACK f06a3cc9190bcac4f6109bf9a9f03f92edf1d1fd (not the head commit)

    Will leave two one questions for clarification.

  129. in src/wallet/rpcwallet.cpp:73 in a71c5b8e73 outdated
    65@@ -66,11 +66,6 @@ bool EnsureWalletIsAvailable(CWallet * const pwallet, bool avoidException)
    66     if (pwallet) return true;
    67     if (avoidException) return false;
    68     if (!HasWallets()) {
    69-        // Note: It isn't currently possible to trigger this error because
    70-        // wallet RPC methods aren't registered unless a wallet is loaded. But
    71-        // this error is being kept as a precaution, because it's possible in
    72-        // the future that wallet RPC methods might get or remain registered
    73-        // when no wallets are loaded.
    


    MarcoFalke commented at 7:51 pm on May 22, 2018:
    Mind to explain why this is removed? I believe Construct will still return without creating a chain client and thus RegisterWalletRPCCommands is never called.
  130. ryanofsky force-pushed on May 24, 2018
  131. ryanofsky force-pushed on Jun 4, 2018
  132. DrahtBot added the label Needs rebase on Jun 11, 2018
  133. ryanofsky force-pushed on Jun 14, 2018
  134. DrahtBot removed the label Needs rebase on Jun 14, 2018
  135. ryanofsky force-pushed on Jun 19, 2018
  136. in src/optional.h:9 in 4a1c901c7e outdated
    0@@ -0,0 +1,18 @@
    1+// Copyright (c) 2017 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.
    4+
    5+#ifndef BITCOIN_OPTIONAL_H
    6+#define BITCOIN_OPTIONAL_H
    7+
    8+#include <boost/none.hpp>
    9+#include <boost/optional/optional.hpp>
    


    ken2812221 commented at 5:39 pm on June 20, 2018:

    Maybe replace these two lines as #include <boost/optional.hpp> to pass travis tests.

    In commit ‘Remove uses of chainActive and mapBlockIndex in wallet code '

  137. jnewbery commented at 6:16 pm on June 20, 2018: member
    @ryanofsky - are you still maintaining this? What are your thoughts about splitting the first 6 commits into a separate PR (https://github.com/bitcoin/bitcoin/pull/10973#issuecomment-389991584)?
  138. DrahtBot added the label Needs rebase on Jun 24, 2018
  139. ryanofsky force-pushed on Jun 26, 2018
  140. ryanofsky commented at 5:24 pm on June 26, 2018: member
    Rebased a71c5b8e73d991f28945280c8812fa0c2898a710 -> 7e906d547788bddb9a7993d98e310c65cf6b6604 (pr/wipc-sep.56 -> pr/wipc-sep.57) due to conflict with #13063 Rebased 7e906d547788bddb9a7993d98e310c65cf6b6604 -> f8bdedf99707d9317cb600a99ccdece63bea33f8 (pr/wipc-sep.57 -> pr/wipc-sep.58) due to conflict with #13112 Rebased f8bdedf99707d9317cb600a99ccdece63bea33f8 -> 79b723888a0ea349fb25ffdeb2ca015f85120e96 (pr/wipc-sep.58 -> pr/wipc-sep.59) due to conflicts with #12634 and #13120 Rebased 79b723888a0ea349fb25ffdeb2ca015f85120e96 -> 4a1c901c7e4bd9e2e5545d1a1ab155e86d72faea (pr/wipc-sep.59 -> pr/wipc-sep.60) due to conflict with #13437 Rebased 4a1c901c7e4bd9e2e5545d1a1ab155e86d72faea -> 6ee6221aa5adaf643c0d856e9b8a0480f5d6e150 (pr/wipc-sep.60 -> pr/wipc-sep.61) due to conflict with #13111 Updated 6ee6221aa5adaf643c0d856e9b8a0480f5d6e150 -> 7e59fa372968009d8b4df29ce9893b4038f9c2cd (pr/wipc-sep.61 -> pr/wipc-sep.62) to fix lint errors Rebased 7e59fa372968009d8b4df29ce9893b4038f9c2cd -> 7f9fabce8fa33aae220f9cdeb40c540ef0ef849d (pr/wipc-sep.62 -> pr/wipc-sep.63) due to conflict with #13235 Rebased 7f9fabce8fa33aae220f9cdeb40c540ef0ef849d -> 56e391398edc617042d910a2433ccd08c6a05d44 (pr/wipc-sep.63 -> pr/wipc-sep.64) due to conflict with #13570 Rebased 56e391398edc617042d910a2433ccd08c6a05d44 -> d8abd3c2a9378968d258b8beb33b6516eb2257fa (pr/wipc-sep.64 -> pr/wipc-sep.65) due to conflict with #13622 Rebased d8abd3c2a9378968d258b8beb33b6516eb2257fa -> 635bc2d32ea2a5e67bef8669cc4b4466489d72d1 (pr/wipc-sep.65 -> pr/wipc-sep.66) due to conflicts with #13630, #13566, #13651, #13072, and #12944. Also added g_interfaces global variable to be able to access chain and chain interface pointers from RPC handlers like setmocktime and loadwallet that need access to the interfaces but don’t have any other way of getting access to bitcoin state. Rebased 635bc2d32ea2a5e67bef8669cc4b4466489d72d1 -> 3344aa65fc6179dabc6fa736fe6c81043466f221 (pr/wipc-sep.66 -> pr/wipc-sep.67) due to conflicts with #13822, #9662, #13786. Also replaced g_interfaces with g_rpc_interfaces. Updated 3344aa65fc6179dabc6fa736fe6c81043466f221 -> fb60d4fbbe5f5e588618a41b858e376f938a02a5 (pr/wipc-sep.67 -> pr/wipc-sep.68) to work around circular dependency lint error Rebased fb60d4fbbe5f5e588618a41b858e376f938a02a5 -> 1528b74cdc7425d84911b748e32daaf1d9ce3be6 (pr/wipc-sep.68 -> pr/wipc-sep.69) due to conflict with #12992 Rebased 1528b74cdc7425d84911b748e32daaf1d9ce3be6 -> 78250d158075f0a71dfef64cfdecc6ef042caf03 (pr/wipc-sep.69 -> pr/wipc-sep.70) due to conflict with #13657 Rebased 78250d158075f0a71dfef64cfdecc6ef042caf03 -> abe06d8140ec74e3ad0736a3721a97b4a08f6919 (pr/wipc-sep.70 -> pr/wipc-sep.71) due to conflict with #13911 Rebased abe06d8140ec74e3ad0736a3721a97b4a08f6919 -> 2789833b2114af13881e3949e9c0211ff80a0ec1 (pr/wipc-sep.71 -> pr/wipc-sep.72) due to conflict with #13634 Rebased 2789833b2114af13881e3949e9c0211ff80a0ec1 -> 4910f87ee994741004a50e9394dd321771fbbff2 (pr/wipc-sep.72 -> pr/wipc-sep.73) due to conflict with #12559 Updated 4910f87ee994741004a50e9394dd321771fbbff2 -> 49214aa0a0a20676fa1d9ff0324912374058adfc (pr/wipc-sep.73 -> pr/wipc-sep.74) to fix msvc / appveyor link errors Updated 49214aa0a0a20676fa1d9ff0324912374058adfc -> 3ce12080c3a7413f03df2212f1d58f405489e894 (pr/wipc-sep.74 -> pr/wipc-sep.75) to fix msvc / appveyor compile error Rebased 3ce12080c3a7413f03df2212f1d58f405489e894 -> 2f6bf5cd2b6dd4c8a148887afd0aa51237f79a4c (pr/wipc-sep.75 -> pr/wipc-sep.76) due to conflicts with #13631, #13083, #14062, and #14023 Updated 2f6bf5cd2b6dd4c8a148887afd0aa51237f79a4c -> b344a2e3d1b16f08c97edb96fc64b6b6b65c310e (pr/wipc-sep.76 -> pr/wipc-sep.77) to fix appveyor error Rebased b344a2e3d1b16f08c97edb96fc64b6b6b65c310e -> bea29712919f5216ffc6096ef715db4d82594032 (pr/wipc-sep.77 -> pr/wipc-sep.78) due to conflict with #13825 Rebased bea29712919f5216ffc6096ef715db4d82594032 -> 249bf5006184f81d77d40ee0ede0924c628bf33e (pr/wipc-sep.78 -> pr/wipc-sep.79) due to conflicts with #10605 and #11599 Rebased 249bf5006184f81d77d40ee0ede0924c628bf33e -> 0219d88970afa3dd39501fe5fb9eb1266a0a4830 (pr/wipc-sep.79 -> pr/wipc-sep.80) due to conflicts with #14204 and #14168 Rebased 0219d88970afa3dd39501fe5fb9eb1266a0a4830 -> 2da040ee454e1393050607921d625a9d60a0f960 (pr/wipc-sep.80 -> pr/wipc-sep.81) due to conflict with #14208 Rebased 2da040ee454e1393050607921d625a9d60a0f960 -> e44e639558b1084f14a97847592616c3df9fff38 (pr/wipc-sep.81 -> pr/wipc-sep.82) due to conflict with #12493 Rebased e44e639558b1084f14a97847592616c3df9fff38 -> 18c5bba238abc5dbca900eb792b8239bc40f505f (pr/wipc-sep.82 -> pr/wipc-sep.83) due to conflicts with #13424 and #14310 Rebased 18c5bba238abc5dbca900eb792b8239bc40f505f -> 45b23efaada081a7be9e255df59670f4704c45d1 (pr/wipc-sep.83 -> pr/wipc-sep.84) due to conflict with #14282 Rebased 45b23efaada081a7be9e255df59670f4704c45d1 -> 1461fcacbc441f1abb782406bd6dcd48edf36aa6 (pr/wipc-sep.84 -> pr/wipc-sep.85) with various updates, and due to conflicts with #11634 and #14146 Rebased 1461fcacbc441f1abb782406bd6dcd48edf36aa6 -> 158ec814077c80bcc29e019f51af566504df1395 (pr/wipc-sep.85 -> pr/wipc-sep.86) due to conflicts with #14350 and #14555 Rebased 158ec814077c80bcc29e019f51af566504df1395 -> 3a2668b7bb63f26ee17873a83eaf5b4e97820f56 (pr/wipc-sep.86 -> pr/wipc-sep.87) due to base PR #14437 being merged, on top of new base PR #14711, tag pr/wchain2.1 Rebased 3a2668b7bb63f26ee17873a83eaf5b4e97820f56 -> 30fe0bbc3c4ad370567b2072338a2f54f3b4b7dd (pr/wipc-sep.87 -> pr/wipc-sep.88) due to conflict with #14530 Rebased 30fe0bbc3c4ad370567b2072338a2f54f3b4b7dd -> 7e498129c701b5daf4cd55be70131a8852c7c70b (pr/wipc-sep.88 -> pr/wipc-sep.89) on top of base PR #14711 tag pr/wchain2.2 Rebased 7e498129c701b5daf4cd55be70131a8852c7c70b -> 9e096b9b014ab571476e4da8d8f289b38455725d (pr/wipc-sep.89 -> pr/wipc-sep.90) on top of base PR #14711 tag pr/wchain2.3 Rebased 9e096b9b014ab571476e4da8d8f289b38455725d -> bbd4ec6a7e5a23f83b79b9cecfd26c96b4c37c88 (pr/wipc-sep.90 -> pr/wipc-sep.91) on top of base PR #14711 tag pr/wchain2.4 Rebased bbd4ec6a7e5a23f83b79b9cecfd26c96b4c37c88 -> 108a56aa073921250a4742524d7493e9233e0f5a (pr/wipc-sep.91 -> pr/wipc-sep.92) on top of base PR #14711 tag pr/wchain2.6 Rebased 108a56aa073921250a4742524d7493e9233e0f5a -> 732552ae1eac358cabe21d4dceee19d7aced984c (pr/wipc-sep.92 -> pr/wipc-sep.93) due to conflicts with #14556 and #14906 Rebased 732552ae1eac358cabe21d4dceee19d7aced984c -> 8d434a2edd61fd55f07d6d778c11e59b27bdad03 (pr/wipc-sep.93 -> pr/wipc-sep.94) on top of base PR #15288 tag pr/wchain3.1 Rebased 8d434a2edd61fd55f07d6d778c11e59b27bdad03 -> 91ef0101b38dc530d92c6cd19be62095a0c8dea9 (pr/wipc-sep.94 -> pr/wipc-sep.95) on top of base PR #15288 tag pr/wchain3.5 Rebased 91ef0101b38dc530d92c6cd19be62095a0c8dea9 -> 016b121b447d5383614ef77d6a050bd66994170b (pr/wipc-sep.95 -> pr/wipc-sep.96) after base PR #15288 merged Rebased 016b121b447d5383614ef77d6a050bd66994170b -> 6898f5376071dcd84ce4aea980e170b4953c18bb (pr/wipc-sep.96 -> pr/wipc-sep.97) due to conflict with #15531
  141. ryanofsky force-pushed on Jun 27, 2018
  142. DrahtBot removed the label Needs rebase on Jun 27, 2018
  143. unknown approved
  144. DrahtBot added the label Needs rebase on Jul 7, 2018
  145. ryanofsky force-pushed on Jul 10, 2018
  146. ryanofsky force-pushed on Jul 10, 2018
  147. DrahtBot removed the label Needs rebase on Jul 11, 2018
  148. DrahtBot added the label Needs rebase on Jul 11, 2018
  149. ryanofsky force-pushed on Jul 12, 2018
  150. DrahtBot removed the label Needs rebase on Jul 12, 2018
  151. DrahtBot added the label Needs rebase on Jul 13, 2018
  152. ryanofsky force-pushed on Jul 18, 2018
  153. DrahtBot removed the label Needs rebase on Jul 18, 2018
  154. DrahtBot added the label Needs rebase on Jul 20, 2018
  155. ryanofsky force-pushed on Aug 3, 2018
  156. ryanofsky force-pushed on Aug 3, 2018
  157. DrahtBot removed the label Needs rebase on Aug 3, 2018
  158. DrahtBot added the label Needs rebase on Aug 6, 2018
  159. ryanofsky force-pushed on Aug 6, 2018
  160. DrahtBot removed the label Needs rebase on Aug 6, 2018
  161. DrahtBot added the label Needs rebase on Aug 7, 2018
  162. ryanofsky force-pushed on Aug 7, 2018
  163. DrahtBot removed the label Needs rebase on Aug 7, 2018
  164. DrahtBot added the label Needs rebase on Aug 9, 2018
  165. ryanofsky force-pushed on Aug 9, 2018
  166. DrahtBot removed the label Needs rebase on Aug 9, 2018
  167. DrahtBot added the label Needs rebase on Aug 13, 2018
  168. ryanofsky force-pushed on Aug 14, 2018
  169. DrahtBot removed the label Needs rebase on Aug 14, 2018
  170. DrahtBot added the label Needs rebase on Aug 23, 2018
  171. ryanofsky force-pushed on Aug 23, 2018
  172. ryanofsky force-pushed on Aug 23, 2018
  173. DrahtBot removed the label Needs rebase on Aug 23, 2018
  174. ryanofsky force-pushed on Aug 24, 2018
  175. DrahtBot added the label Needs rebase on Aug 25, 2018
  176. in src/wallet/wallet.cpp:2636 in 2aa964dc53 outdated
    2740@@ -2726,7 +2741,8 @@ bool CWallet::CreateTransaction(interfaces::Chain::Lock& locked_chain, const std
    2741     // enough, that fee sniping isn't a problem yet, but by implementing a fix
    2742     // now we ensure code won't be written that makes assumptions about
    2743     // nLockTime that preclude a fix later.
    2744-    txNew.nLockTime = chainActive.Height();
    2745+    const Optional<int> tip_height = locked_chain.getHeight();
    2746+    txNew.nLockTime = tip_height ? *tip_height : std::numeric_limits<uint32_t>::max();
    


    jamesob commented at 9:10 pm on August 28, 2018:
    Probably out-of-scope nit: I wish the uint32_t max was instead a named constant that had meaning relative to use with nLockTime (e.g. IGNORE_NLOCKTIME).

    ryanofsky commented at 4:47 pm on November 1, 2018:

    re: #10973 (review)

    Probably out-of-scope nit: I wish the uint32_t max was instead a named constant

    Added LOCKTIME_MAX constant here and in #14636.

  177. ryanofsky force-pushed on Aug 28, 2018
  178. DrahtBot removed the label Needs rebase on Aug 28, 2018
  179. ryanofsky force-pushed on Aug 29, 2018
  180. DrahtBot added the label Needs rebase on Aug 30, 2018
  181. ryanofsky force-pushed on Aug 30, 2018
  182. DrahtBot removed the label Needs rebase on Aug 30, 2018
  183. DrahtBot added the label Needs rebase on Aug 31, 2018
  184. ryanofsky force-pushed on Aug 31, 2018
  185. DrahtBot removed the label Needs rebase on Aug 31, 2018
  186. ken2812221 commented at 7:14 am on September 5, 2018: contributor
  187. DrahtBot added the label Needs rebase on Sep 11, 2018
  188. ryanofsky force-pushed on Sep 12, 2018
  189. DrahtBot removed the label Needs rebase on Sep 12, 2018
  190. laanwj commented at 3:37 pm on September 13, 2018: member
    Concept ACK
  191. DrahtBot added the label Needs rebase on Sep 13, 2018
  192. ryanofsky force-pushed on Sep 13, 2018
  193. DrahtBot removed the label Needs rebase on Sep 13, 2018
  194. DrahtBot added the label Needs rebase on Sep 14, 2018
  195. ryanofsky force-pushed on Sep 14, 2018
  196. DrahtBot removed the label Needs rebase on Sep 14, 2018
  197. in src/Makefile.bench.include:48 in e0854fc5ba outdated
    40@@ -41,6 +41,11 @@ bench_bench_bitcoin_LDADD = \
    41   $(LIBBITCOIN_COMMON) \
    42   $(LIBBITCOIN_UTIL) \
    43   $(LIBBITCOIN_SERVER) \
    44+  $(LIBBITCOIN_COMMON) \
    45+  $(LIBBITCOIN_UTIL) \
    46+  $(LIBBITCOIN_WALLET) \
    47+  $(LIBBITCOIN_SERVER) \
    48+  $(LIBBITCOIN_UTIL) \
    


    ken2812221 commented at 8:29 am on September 15, 2018:
    In commit “Remove use of g_connman / PushInventory in wallet code”: unnecessary changes
  198. ken2812221 approved
  199. ken2812221 commented at 9:09 am on September 15, 2018: contributor
    utACK e44e639558b1084f14a97847592616c3df9fff38
  200. practicalswift commented at 7:53 am on September 21, 2018: contributor
    This PR does not seem to compile when rebased on master :-)
  201. in src/wallet/test/wallet_test_fixture.cpp:20 in e44e639558 outdated
    18 
    19-    RegisterWalletRPCCommands(tableRPC);
    20+    m_chain_client->registerRpcs();
    21 }
    22 
    23 WalletTestingSetup::~WalletTestingSetup()
    


    practicalswift commented at 7:54 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/wallet/test/wallet_test_fixture.cpp:20:21: warning: use '= default' to define a trivial destructor [hicpp-use-equals-default]
    
  202. in src/interfaces/chain.cpp:81 in e44e639558 outdated
    76+    int64_t getBlockTime(int height) override { return ::chainActive[height]->GetBlockTime(); }
    77+    int64_t getBlockMedianTimePast(int height) override { return ::chainActive[height]->GetMedianTimePast(); }
    78+    bool haveBlockOnDisk(int height) override
    79+    {
    80+        CBlockIndex* block = ::chainActive[height];
    81+        return block && (block->nStatus & BLOCK_HAVE_DATA) && block->nTx > 0;
    


    practicalswift commented at 7:56 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:81:25: warning: implicit conversion 'unsigned int' -> bool [readability-implicit-bool-conversion]
    
  203. in src/interfaces/chain.cpp:105 in e44e639558 outdated
    100+    Optional<int> findPruned(int start_height, Optional<int> stop_height) override
    101+    {
    102+        if (::fPruneMode) {
    103+            CBlockIndex* block = stop_height ? ::chainActive[*stop_height] : ::chainActive.Tip();
    104+            while (block && block->nHeight >= start_height) {
    105+                if (!(block->nStatus & BLOCK_HAVE_DATA)) {
    


    practicalswift commented at 7:56 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:105:22: warning: implicit conversion 'unsigned int' -> bool [readability-implicit-bool-conversion]
    
  204. in src/interfaces/chain.cpp:126 in e44e639558 outdated
    116+        auto it = ::mapBlockIndex.find(hash);
    117+        if (it != ::mapBlockIndex.end()) {
    118+            block = it->second;
    119+            fork = ::chainActive.FindFork(block);
    120+        }
    121+        if (height) {
    


    practicalswift commented at 7:56 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:121:13: warning: implicit conversion 'Optional<int> *' (aka 'boost::optional<int> *') -> bool [readability-implicit-bool-conversion]
    

    flack commented at 4:42 pm on September 23, 2018:

    @practicalswift You know, the signal/noise ratio of these comments would be higher if you omitted the timestamp (which isn’t interesting), the PR number and the file path (which are redundant, because that’s where the comment is attached). Currently in the web UI, you always have to scroll each comment horizontally to see what it’s actually about.

    status quo:

    proposed:


    practicalswift commented at 5:22 pm on September 23, 2018:
    @flack Good point! I’ll implement that!
  205. in src/interfaces/chain.cpp:168 in e44e639558 outdated
    163+};
    164+
    165+class HandlerImpl : public Handler
    166+{
    167+public:
    168+    HandlerImpl(Chain::Notifications& notifications) : m_forwarder(notifications) {}
    


    practicalswift commented at 7:57 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:168:5: warning: single-argument constructors must be marked explicit to avoid unintentional implicit conversions [hicpp-explicit-conversions]
    

    practicalswift commented at 8:30 am on September 21, 2018:
    02018-09-20 04:12:32 cppcheck(pr=10973): [src/interfaces/chain.cpp:168]: (style) Class 'HandlerImpl' has a constructor with 1 argument that is not explicit.
    

    practicalswift commented at 8:23 am on September 23, 2018:
    02018-09-22 22:50:20 cpplint(pr=10973): src/interfaces/chain.cpp:168:  Single-parameter constructors should be marked explicit.
    
  206. in src/interfaces/chain.cpp:182 in e44e639558 outdated
    177+    }
    178+    void disconnect() override { m_forwarder.disconnect(); }
    179+
    180+    struct Forwarder : CValidationInterface
    181+    {
    182+        Forwarder(Chain::Notifications& notifications) : m_notifications(&notifications)
    


    practicalswift commented at 7:57 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:182:9: warning: single-argument constructors must be marked explicit to avoid unintentional implicit conversions [google-explicit-constructor]
    

    practicalswift commented at 8:30 am on September 21, 2018:
    02018-09-20 04:12:32 cppcheck(pr=10973): [src/interfaces/chain.cpp:182]: (style) Struct 'Forwarder' has a constructor with 1 argument that is not explicit.
    

    practicalswift commented at 8:24 am on September 23, 2018:
    02018-09-22 22:50:20 cpplint(pr=10973): src/interfaces/chain.cpp:182:  Single-parameter constructors should be marked explicit.
    
  207. in src/interfaces/chain.cpp:212 in e44e639558 outdated
    207+        void BlockDisconnected(const std::shared_ptr<const CBlock>& block) override
    208+        {
    209+            m_notifications->BlockDisconnected(*block);
    210+        }
    211+        void ChainStateFlushed(const CBlockLocator& locator) override { m_notifications->ChainStateFlushed(locator); }
    212+        void ResendWalletTransactions(int64_t best_block_time, CConnman* connman) override
    


    practicalswift commented at 7:57 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:212:74: warning: parameter 'connman' is unused [misc-unused-parameters]
    
  208. in src/interfaces/chain.cpp:315 in e44e639558 outdated
    310+        size_t nLimitDescendantSize = gArgs.GetArg("-limitdescendantsize", DEFAULT_DESCENDANT_SIZE_LIMIT) * 1000;
    311+        std::string errString;
    312+        LOCK(::mempool.cs);
    313+        if (!::mempool.CalculateMemPoolAncestors(entry, setAncestors, nLimitAncestors, nLimitAncestorSize,
    314+                nLimitDescendants, nLimitDescendantSize, errString)) {
    315+            return false;
    


    practicalswift commented at 8:11 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:315:20: warning: redundant boolean literal in conditional return statement [readability-simplify-boolean-expr]
    
  209. in src/interfaces/chain.cpp:362 in e44e639558 outdated
    357+
    358+//! Forwarder for one RPC method.
    359+class ChainImpl::RpcForwarder
    360+{
    361+public:
    362+    RpcForwarder(const CRPCCommand& command) : m_command(command)
    


    practicalswift commented at 8:11 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:362:5: warning: single-argument constructors must be marked explicit to avoid unintentional implicit conversions [google-explicit-constructor]
    

    practicalswift commented at 8:30 am on September 21, 2018:
    02018-09-20 04:12:32 cppcheck(pr=10973): [src/interfaces/chain.cpp:362]: (style) Class 'RpcForwarder' has a constructor with 1 argument that is not explicit.
    

    practicalswift commented at 8:24 am on September 23, 2018:
    02018-09-22 22:50:20 cpplint(pr=10973): src/interfaces/chain.cpp:362:  Single-parameter constructors should be marked explicit.
    
  210. in src/interfaces/chain.cpp:373 in e44e639558 outdated
    368+
    369+    void addCommand(const CRPCCommand& command) { m_commands.emplace_back(&command); }
    370+
    371+    void removeCommand(const CRPCCommand& command)
    372+    {
    373+        m_commands.erase(std::remove(m_commands.begin(), m_commands.end(), &command));
    


    practicalswift commented at 8:12 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:373:9: warning: this call will remove at most one item even when multiple items should be removed [bugprone-inaccurate-erase]
    
  211. in src/interfaces/chain.cpp:432 in e44e639558 outdated
    427+            m_forwarder->removeCommand(m_command);
    428+            m_forwarder = nullptr;
    429+        }
    430+    }
    431+
    432+    ~RpcHandler() { disconnect(); }
    


    practicalswift commented at 8:13 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:432:5: warning: annotate this function with 'override' or (rarely) 'final' [hicpp-use-override]
    

    practicalswift commented at 8:14 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/interfaces/chain.cpp:432:21: warning: Call to virtual function during destruction [clang-analyzer-optin.cplusplus.VirtualCall]
    
  212. in src/wallet/wallet.cpp:950 in e44e639558 outdated
    946@@ -945,19 +947,19 @@ void CWallet::LoadToWallet(const CWalletTx& wtxIn)
    947     }
    948 }
    949 
    950-bool CWallet::AddToWalletIfInvolvingMe(const CTransactionRef& ptx, const CBlockIndex* pIndex, int posInBlock, bool fUpdate)
    951+bool CWallet::AddToWalletIfInvolvingMe(interfaces::Chain::Lock& locked_chain, const CTransactionRef& ptx, const uint256& block_hash, int posInBlock, bool fUpdate)
    


    practicalswift commented at 8:15 am on September 21, 2018:
    02018-09-19 14:39:06 clang-tidy(pr=10973): src/wallet/wallet.cpp:950:65: warning: parameter 'locked_chain' is unused [misc-unused-parameters]
    
  213. in src/threadsafety.h:62 in e44e639558 outdated
    53@@ -54,4 +54,15 @@
    54 #define ASSERT_EXCLUSIVE_LOCK(...)
    55 #endif // __GNUC__
    56 
    57+// Utility class to indicate mutex is locked for thread analysis when it can't
    58+// be determined otherwise.
    59+struct SCOPED_LOCKABLE LockAnnotation
    60+{
    61+    template <typename Mutex>
    62+    LockAnnotation(Mutex& mutex) EXCLUSIVE_LOCK_FUNCTION(mutex)
    


    practicalswift commented at 8:29 am on September 21, 2018:
    02018-09-20 04:12:32 cppcheck(pr=10973): [src/threadsafety.h:62]: (style) Struct 'LockAnnotation' has a constructor with 1 argument that is not explicit.
    

    practicalswift commented at 8:24 am on September 23, 2018:
    02018-09-22 22:50:20 cpplint(pr=10973): src/threadsafety.h:62:  Single-parameter constructors should be marked explicit.  [runtime/explicit] [5]
    
  214. in src/interfaces/chain.h:209 in e44e639558 outdated
    204+            const std::vector<CTransactionRef>& tx_conflicted)
    205+        {
    206+        }
    207+        virtual void BlockDisconnected(const CBlock& block) {}
    208+        virtual void ChainStateFlushed(const CBlockLocator& locator) {}
    209+        virtual void Inventory(const uint256& hash) {}
    


    practicalswift commented at 8:31 am on September 21, 2018:
    02018-09-20 04:12:32 cppcheck(pr=10973): [src/interfaces/chain.h:209]: (style) The function 'Inventory' is never used.
    
  215. in src/interfaces/chain.cpp:5 in e44e639558 outdated
    0@@ -0,0 +1,453 @@
    1+#include <interfaces/chain.h>
    


    practicalswift commented at 8:23 am on September 23, 2018:
    0
    12018-09-22 22:50:20 cpplint(pr=10973): src/interfaces/chain.cpp:0:  No copyright message found.
    
  216. in src/interfaces/chain.h:5 in e44e639558 outdated
    0@@ -0,0 +1,265 @@
    1+#ifndef BITCOIN_INTERFACES_CHAIN_H
    


    practicalswift commented at 8:24 am on September 23, 2018:
    02018-09-22 22:50:20 cpplint(pr=10973): src/interfaces/chain.h:0:  No copyright message found.
    
  217. DrahtBot added the label Needs rebase on Sep 24, 2018
  218. ryanofsky force-pushed on Sep 26, 2018
  219. DrahtBot removed the label Needs rebase on Sep 26, 2018
  220. DrahtBot added the label Needs rebase on Sep 26, 2018
  221. ryanofsky force-pushed on Sep 27, 2018
  222. DrahtBot removed the label Needs rebase on Sep 27, 2018
  223. jamesob commented at 7:29 am on October 10, 2018: member
    Should this be closed now that #14437 has been opened?
  224. ryanofsky commented at 7:45 am on October 10, 2018: member

    Should this be closed now that #14437 has been opened?

    I updated the PR description above to make it obvious that review comments be added in #14437. I’d still like to keep updating this PR though. I think for example being able to see the complete Chain interface added here is useful for understanding the direction #14437 is starting to go in.

  225. in src/interfaces/chain.cpp:324 in 45b23efaad outdated
    319+    }
    320+    CFeeRate estimateSmartFee(int num_blocks, bool conservative, FeeCalculation* calc) override
    321+    {
    322+        return ::feeEstimator.estimateSmartFee(num_blocks, calc, conservative);
    323+    }
    324+    int estimateMaxBlocks() override { return ::feeEstimator.HighestTargetTracked(FeeEstimateHorizon::LONG_HALFLIFE); }
    


    practicalswift commented at 5:24 am on October 11, 2018:
    An implicit conversion from unsigned int to int takes place here. Return an unsigned integer instead?
  226. in src/interfaces/chain.cpp:410 in 45b23efaad outdated
    405+        // This will only be reached if m_commands is empty. (Because the RPC
    406+        // server provides an appendCommand, but no removeCommand method, it
    407+        // will keep sending requests here even if there are no clients left to
    408+        // forward to.)
    409+        throw JSONRPCError(RPC_METHOD_NOT_FOUND, "Method not found");
    410+    };
    


    practicalswift commented at 5:27 am on October 11, 2018:
    Nit: Remove ; :-)
  227. in src/rpc/rawtransaction.cpp:768 in 45b23efaad outdated
    764+public:
    765+    CoinFill(CCoinsViewCache& cache, const COutPoint &output, Coin&& coin, CCoinsView &backend) : m_cache(cache), m_output(output), m_coin(std::move(coin)), m_backend(backend) {
    766+        m_cache.SetBackend(*this);
    767+        m_cache.AccessCoin(output);
    768+    }
    769+    ~CoinFill() {
    


    practicalswift commented at 5:28 am on October 11, 2018:
    Should be marked override?
  228. jnewbery commented at 5:42 am on October 11, 2018: member

    @practicalswift - see note in PR description:

    This PR is based on #14437, so review comments for initial commits should be posted there.

    I recommend you don’t spend time reviewing this until #14437 is merged.

  229. practicalswift commented at 7:22 am on October 11, 2018: contributor
    @jnewbery Oh, thanks!
  230. in src/interfaces/chain.cpp:311 in 45b23efaad outdated
    306+    bool checkChainLimits(CTransactionRef tx) override
    307+    {
    308+        LockPoints lp;
    309+        CTxMemPoolEntry entry(tx, 0, 0, 0, false, 0, lp);
    310+        CTxMemPool::setEntries setAncestors;
    311+        size_t nLimitAncestors = gArgs.GetArg("-limitancestorcount", DEFAULT_ANCESTOR_LIMIT);
    


    practicalswift commented at 12:16 pm on October 15, 2018:
    Make this and the conversions on the lines below explicit?
  231. in src/wallet/fees.cpp:95 in 45b23efaad outdated
    88@@ -90,10 +89,10 @@ CFeeRate GetMinimumFeeRate(const CWallet& wallet, const CCoinControl& coin_contr
    89     return feerate_needed;
    90 }
    91 
    92-CFeeRate GetDiscardRate(const CWallet& wallet, const CBlockPolicyEstimator& estimator)
    93+CFeeRate GetDiscardRate(const CWallet& wallet)
    94 {
    95-    unsigned int highest_target = estimator.HighestTargetTracked(FeeEstimateHorizon::LONG_HALFLIFE);
    96-    CFeeRate discard_rate = estimator.estimateSmartFee(highest_target, nullptr /* FeeCalculation */, false /* conservative */);
    97+    unsigned int highest_target = wallet.chain().estimateMaxBlocks();
    


    practicalswift commented at 12:17 pm on October 15, 2018:
    Implicit sign conversion here: see comment on estimateMaxBlocks above.
  232. DrahtBot added the label Needs rebase on Oct 20, 2018
  233. ryanofsky force-pushed on Nov 1, 2018
  234. ryanofsky commented at 9:04 pm on November 1, 2018: member

    re: #10973#pullrequestreview-116397255

    there are some lingering references to chainActive in wallet/test/wallet_tests.cpp

    Maybe some of these could be changed, but I think it’s fine if test code manipulates chain state directly. Alternatives would be extending the Chain interface or writing a new interface to manipulate chain state, which would add complexity and overhead, or having tests create mock chain objects, which might make sense but could result in more test code and less realistic tests.

    re: #10973#pullrequestreview-116397255

    there’s a forward declaration of CBlockIndex in wallet/wallet.h that doesn’t look necessary anymore.

    Thanks, removed this.

    re: #10973 (comment)

    Also, I’ll note that the lowercasing of method names on the interfaces conflicts with the Coding Style.

    Thanks, sipa also commented on this in #14437 (comment). Will try a PR to update the style.

  235. DrahtBot removed the label Needs rebase on Nov 1, 2018
  236. ryanofsky referenced this in commit 8041cd39f0 on Nov 1, 2018
  237. DrahtBot added the label Needs rebase on Nov 5, 2018
  238. ryanofsky referenced this in commit 90a9e72807 on Nov 5, 2018
  239. ryanofsky referenced this in commit 535203075e on Nov 5, 2018
  240. ryanofsky force-pushed on Nov 6, 2018
  241. DrahtBot removed the label Needs rebase on Nov 6, 2018
  242. MarcoFalke referenced this in commit e8d490f27e on Nov 7, 2018
  243. HashUnlimited referenced this in commit e1ed1eb7d1 on Nov 7, 2018
  244. MarcoFalke referenced this in commit cbf00939b5 on Nov 9, 2018
  245. in src/init.cpp:1320 in 158ec81407 outdated
    1257@@ -1243,7 +1258,11 @@ bool AppInitMain()
    1258     }
    1259 
    1260     // ********************************************************* Step 5: verify wallet database integrity
    1261-    if (!g_wallet_init_interface.Verify()) return false;
    1262+    for (const auto& client : interfaces.chain_clients) {
    1263+        if (!client->verify()) {
    1264+            return false;
    


    practicalswift commented at 6:31 pm on November 9, 2018:
    Nit: Looks like a potential opportunity for std::any_of? :-)

    ryanofsky commented at 6:34 pm on November 12, 2018:
    Discussed in base PR: #14437 (review)
  246. in src/init.cpp:1644 in 158ec81407 outdated
    1580@@ -1562,7 +1581,11 @@ bool AppInitMain()
    1581     }
    1582 
    1583     // ********************************************************* Step 9: load wallet
    1584-    if (!g_wallet_init_interface.Open()) return false;
    1585+    for (const auto& client : interfaces.chain_clients) {
    1586+        if (!client->load()) {
    1587+            return false;
    


    practicalswift commented at 6:32 pm on November 9, 2018:
    Nit: Looks like a potential opportunity for std::any_of? :-)

    ryanofsky commented at 6:34 pm on November 12, 2018:
    Discussed in base PR: #14437 (review)
  247. meshcollider commented at 11:16 am on November 11, 2018: contributor
    Concept ACK, will this PR be rebased and ready for review now #14437 has been merged, or will you make another smaller PR for the next steps and leave this just to track overall?
  248. ryanofsky force-pushed on Nov 12, 2018
  249. ryanofsky commented at 7:43 pm on November 12, 2018: member

    will this PR be rebased and ready for review now #14437 has been merged, or will you make another smaller PR for the next steps and leave this just to track overall?

    I made a new PR #14711 containing the first commit from this PR, but I’m also maintaining this.

  250. DrahtBot added the label Needs rebase on Nov 13, 2018
  251. peepeemlove approved
  252. jfhk referenced this in commit af421299e2 on Nov 14, 2018
  253. JeremyRubin referenced this in commit b03e4e75d6 on Nov 24, 2018
  254. HashUnlimited referenced this in commit 992d4c03ca on Nov 26, 2018
  255. ryanofsky force-pushed on Nov 26, 2018
  256. DrahtBot removed the label Needs rebase on Nov 26, 2018
  257. DrahtBot added the label Needs rebase on Nov 30, 2018
  258. ryanofsky force-pushed on Dec 6, 2018
  259. DrahtBot removed the label Needs rebase on Dec 6, 2018
  260. DrahtBot added the label Needs rebase on Dec 12, 2018
  261. peepeemlove approved
  262. ryanofsky force-pushed on Dec 17, 2018
  263. DrahtBot removed the label Needs rebase on Dec 17, 2018
  264. DrahtBot added the label Needs rebase on Dec 18, 2018
  265. ryanofsky force-pushed on Dec 18, 2018
  266. DrahtBot removed the label Needs rebase on Dec 18, 2018
  267. DrahtBot added the label Needs rebase on Jan 10, 2019
  268. ryanofsky force-pushed on Jan 10, 2019
  269. DrahtBot removed the label Needs rebase on Jan 10, 2019
  270. DrahtBot added the label Needs rebase on Jan 15, 2019
  271. ryanofsky force-pushed on Jan 23, 2019
  272. DrahtBot removed the label Needs rebase on Jan 23, 2019
  273. meshcollider referenced this in commit 72ca72e637 on Jan 30, 2019
  274. DrahtBot added the label Needs rebase on Jan 30, 2019
  275. ryanofsky force-pushed on Jan 30, 2019
  276. DrahtBot removed the label Needs rebase on Jan 30, 2019
  277. DrahtBot added the label Needs rebase on Feb 10, 2019
  278. ryanofsky force-pushed on Feb 11, 2019
  279. DrahtBot removed the label Needs rebase on Feb 11, 2019
  280. DrahtBot added the label Needs rebase on Feb 15, 2019
  281. MarcoFalke referenced this in commit 45f434f44d on Mar 4, 2019
  282. ryanofsky force-pushed on Mar 4, 2019
  283. DrahtBot removed the label Needs rebase on Mar 4, 2019
  284. Remove use CValidationInterface in wallet code
    This commit does not change behavior.
    91868e6288
  285. Remove use of CRPCTable::appendCommand in wallet code
    This commit does not change behavior.
    4e4d9e9f85
  286. Remove use of CCoinsViewMemPool::GetCoin in wallet code
    This commit does not change behavior.
    b1b2b23892
  287. ryanofsky force-pushed on Mar 5, 2019
  288. MarcoFalke deleted a comment on Mar 6, 2019
  289. DrahtBot commented at 7:07 pm on March 6, 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:

    • #15606 ([experimental] UTXO snapshots by jamesob)
    • #15557 (Enhance bumpfee to include inputs when targeting a feerate by instagibbs)
    • #15329 (Fix InitError() and InitWarning() content by hebasto)
    • #15157 (rpc: Bumpfee units change, satoshis to BTC by benthecarman)
    • #14942 (wallet: Make scan / abort status private to CWallet by Empact)
    • #14912 ([WIP] External signer support (e.g. hardware wallet) by Sjors)
    • #14053 (Add address-based index (attempt 4?) by marcinja)
    • #13804 (WIP: Transaction Pool Layer by MarcoFalke)
    • #12911 (wallet: Show fee in results for signrawtransaction* for segwit inputs by kallewoof)
    • #12096 ([rpc] [wallet] Allow specifying the output index when using bumpfee by kallewoof)

    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.

  290. MarcoFalke commented at 7:16 pm on March 6, 2019: member
    utACK 6898f53760
  291. Remove remaining wallet accesses to node globals d358466de1
  292. fanquake added this to the "Blockers" column in a project

  293. in src/rpc/rawtransaction.cpp:806 in 6898f53760 outdated
    801+    }
    802+    ~CoinFill() override {
    803+        m_cache.SetBackend(m_backend);
    804+    }
    805+
    806+    private:
    


    promag commented at 10:40 am on March 11, 2019:
    nit, align.

    ryanofsky commented at 6:09 pm on March 11, 2019:

    re: #10973 (review)

    nit, align.

    Removed in simplification.

  294. in src/rpc/rawtransaction.cpp:807 in 6898f53760 outdated
    802+    ~CoinFill() override {
    803+        m_cache.SetBackend(m_backend);
    804+    }
    805+
    806+    private:
    807+    bool GetCoin(const COutPoint &output, Coin &coin) const override {
    


    promag commented at 10:40 am on March 11, 2019:
    nit, format.

    ryanofsky commented at 6:10 pm on March 11, 2019:

    re: #10973 (review)

    nit, format.

    Removed in simplification.

  295. in src/interfaces/chain.h:167 in 6898f53760 outdated
    162@@ -160,6 +163,9 @@ class Chain
    163         int64_t* time = nullptr,
    164         int64_t* max_time = nullptr) = 0;
    165 
    166+    //! Get unspent outputs associated with a transaction.
    167+    virtual std::vector<Coin> findCoins(const std::vector<COutPoint>& outputs) = 0;
    


    promag commented at 11:11 am on March 11, 2019:
    I wonder if this should return an std::vector<std::pair<COutPoint, Coin>>? Otherwise could note in the comment that result follows outputs order.

    ryanofsky commented at 6:09 pm on March 11, 2019:

    re: #10973 (review)

    I wonder if this should return an std::vector<std::pair<COutPoint, Coin»? Otherwise could note in the comment that result follows outputs order.

    Agree this was awkward. Replaced with in/out param in simplification.

  296. in src/rpc/rawtransaction.cpp:814 in 6898f53760 outdated
    809+        coin = std::move(m_coin);
    810+        return true;
    811+    }
    812+    CCoinsViewCache& m_cache;
    813+    const COutPoint& m_output;
    814+    Coin&& m_coin;
    


    promag commented at 11:11 am on March 11, 2019:
    Why?

    ryanofsky commented at 6:10 pm on March 11, 2019:

    re: #10973 (review)

    In commit “Remove use of CCoinsViewMemPool::GetCoin in wallet code” (016b121b447d5383614ef77d6a050bd66994170b)

    Why?

    Removed in simplification. & would have worked here too, but && seemed to make sense since this was a reference to a temporary that was moved from.

  297. in src/rpc/server.cpp:198 in 6898f53760 outdated
    192@@ -193,9 +193,8 @@ std::string CRPCTable::help(const std::string& strCommand, const JSONRPCRequest&
    193         jreq.strMethod = strMethod;
    194         try
    195         {
    196-            rpcfn_type pfn = pcmd->actor;
    197-            if (setDone.insert(pfn).second)
    198-                (*pfn)(jreq);
    199+            if (setDone.insert(pcmd->unique_id).second)
    


    promag commented at 11:11 am on March 11, 2019:
    nit, {

    ryanofsky commented at 6:09 pm on March 11, 2019:

    #10973 (review)

    nit, {

    Will leave since I’m just replacing pfn with pcmd->unique_id here and I think it’s nice that this function uses a consistent style.

  298. in src/rpc/rawtransaction.cpp:830 in 6898f53760 outdated
    831-            view.AccessCoin(txin.prevout); // Load entries from viewChain into view; can fail.
    832+            outputs.emplace_back(txin.prevout);
    833+        }
    834+        std::vector<Coin> coins = chain.findCoins(outputs);
    835+        for (size_t i = 0; i < coins.size(); ++i) {
    836+            CoinFill(view, outputs[i], std::move(coins[i]), viewDummy);
    


    promag commented at 11:23 am on March 11, 2019:

    Can you explain why not do the following:

    0CoinFill view(...);
    1for (...) {
    2   view.AccessCoin(...)
    3}
    

    ryanofsky commented at 6:10 pm on March 11, 2019:

    re: #10973 (review)

    Can you explain why not do the following:

    Prefer short lifetimes and less persistent state. In any case, this has been removed in a simplification.

  299. in src/interfaces/chain.cpp:436 in 6898f53760 outdated
    439+
    440+std::unique_ptr<Handler> ChainImpl::handleRpc(const CRPCCommand& command)
    441+{
    442+    auto inserted = m_rpc_forwarders.emplace(
    443+        std::piecewise_construct, std::forward_as_tuple(command.name), std::forward_as_tuple(command));
    444+    if (inserted.second && !inserted.first->second.registerForwarder()) {
    


    promag commented at 11:32 am on March 11, 2019:
    When can inserted.second fail?

    ryanofsky commented at 6:08 pm on March 11, 2019:

    re: #10973 (review)

    When can inserted.second fail?

    Added comment, but inserted.second being false isn’t a failure. It’s just checked to prevent work being repeated when there are multiple wallet processes.

  300. in src/wallet/rpcwallet.cpp:4162 in 6898f53760 outdated
    4155@@ -4156,8 +4156,8 @@ static const CRPCCommand commands[] =
    4156 };
    4157 // clang-format on
    4158 
    4159-void RegisterWalletRPCCommands(CRPCTable &t)
    4160+void RegisterWalletRPCCommands(interfaces::Chain& chain, std::vector<std::unique_ptr<interfaces::Handler>>& handlers)
    4161 {
    4162     for (unsigned int vcidx = 0; vcidx < ARRAYLEN(commands); vcidx++)
    4163-        t.appendCommand(commands[vcidx].name, &commands[vcidx]);
    4164+        handlers.emplace_back(chain.handleRpc(commands[vcidx]));
    


    promag commented at 11:33 am on March 11, 2019:
    handleRpc can return an “empty” handler.

    ryanofsky commented at 6:09 pm on March 11, 2019:

    re: #10973 (review)

    handleRpc can return an “empty” handler.

    Not sure if there is a suggested change, but handleRpc will return null if CRPCTable::appendCommand returns false. There should be no change in behavior as this is.


    promag commented at 1:45 am on March 12, 2019:
    But why let handlers have a null entry?

    ryanofsky commented at 2:59 am on March 12, 2019:

    But why let handlers have a null entry?

    What is the suggestion? This condition won’t happen and it wouldn’t be a problem if it did happen. I’m trying not to change behavior and this is a straight translation of the previous code. Neither the old code nor the new code cares about this condition. If there are concerns about rpc registration they would probably be better to address in another PR.

  301. in src/interfaces/chain.cpp:341 in 6898f53760 outdated
    342@@ -254,8 +343,111 @@ class ChainImpl : public Chain
    343     void initWarning(const std::string& message) override { InitWarning(message); }
    344     void initError(const std::string& message) override { InitError(message); }
    345     void loadWallet(std::unique_ptr<Wallet> wallet) override { ::uiInterface.LoadWallet(wallet); }
    346+    std::unique_ptr<Handler> handleNotifications(Notifications& notifications) override
    347+    {
    348+        return MakeUnique<HandlerImpl>(notifications);
    349+    }
    350+    void waitForNotifications() override { SyncWithValidationInterfaceQueue(); }
    351+    std::unique_ptr<Handler> handleRpc(const CRPCCommand& command) override;
    


    promag commented at 11:34 am on March 11, 2019:
    nit, maybe a bit late, but should be uppercase RPC?

    ryanofsky commented at 6:08 pm on March 11, 2019:

    re: #10973 (review)

    nit, maybe a bit late, but should be uppercase RPC?

    IMO, strict camel case without exceptions for acronyms is easier to read. (JSONRPCRequest JsonRpcRequest)

  302. promag commented at 11:40 am on March 11, 2019: member

    Looks good, as @jnewbery points out, a bit hard to review, but I think it’s worth the effort. Sorry for these nits, feel free to ignore them.

    After this PR, wallet code no longer accesses global variables declared outside the wallet directory, and no longer calls functions accessing those globals (as verified by the hide-globals script in #10244).

    Do you think this should be committed and verified in CI?

  303. ryanofsky force-pushed on Mar 12, 2019
  304. ryanofsky commented at 0:55 am on March 12, 2019: member

    Thanks for reviews!

    Updated 6898f5376071dcd84ce4aea980e170b4953c18bb -> 244edfe470d8b6a4c449649952bb2130e0d10bd5 (pr/wipc-sep.97 -> pr/wipc-sep.98, compare).

    • Main change is adding a new commit “Remove remaining wallet accesses to node globals” (244edfe470d8b6a4c449649952bb2130e0d10bd5).
    • Commit “Remove use CValidationInterface in wallet code” (5c7f4118ef82248f50ff112828638e0a99247cd9, formerly fce0e3cfd1a8616e1c2c05052af277ae8cd7a574) is simplified to remove workaround for UnregisterValidationInterface crash fixed by 2196c51821e340c9a9d2c76c30f9402370f84994 in #13743.
    • Commit “Remove use of CRPCTable::appendCommand in wallet code” (a15a7bf8093c9841aed2e51a6655fc5be5b7d783, formerly 53a730ab0c37354db1333f436761fb81f94e3657) is unchanged except for a code comment.
    • Commit “Remove use of CCoinsViewMemPool::GetCoin in wallet code” (9863ddc7dbec47d57967544979f694e740d83916 formerly 6898f5376071dcd84ce4aea980e170b4953c18bb) has been simplified by replacing a custom CCoinsView subclass with a plain std::map.

    re: #10973#pullrequestreview-212761964

    After this PR, wallet code no longer accesses global variables declared outside the wallet directory, and no longer calls functions accessing those globals (as verified by the hide-globals script in #10244).

    Do you think this should be committed and verified in CI?

    I’d like to verify this, but not with a script, since it would be awkward to set up and maintain. Instead, I’d like to just add a new libbitcoin_node.a library, analogous to the existing libbitcoin_wallet.a library, and move symbol definitions like cs_main pcoinsTip chainActive there that wallet and gui code shouldn’t access. That way any bad references will just result in link errors while building bitcoin-wallet and bitcoin-gui executables.

    Since we have src/node/ src/wallet/ and src/qt/ folders we could also set up rules preventing source files in one of these folders including headers in the other folders. This would provide the clearest separation, but would also require moving a bunch of code around, so would not be a short-term goal.

  305. ryanofsky force-pushed on Mar 12, 2019
  306. ryanofsky commented at 1:02 am on March 12, 2019: member
    Updated 244edfe470d8b6a4c449649952bb2130e0d10bd5 -> 591434b72c3b0ec218fbe30969ae5a819ca224c4 (pr/wipc-sep.98 -> pr/wipc-sep.99, compare) to fix travis error with old boost.
  307. MarcoFalke commented at 4:15 pm on March 12, 2019: member

    nit: In commit 591434b

    Could also update the TODO comment for GetAvailableCredit and remove the cs_main from it?

  308. ryanofsky force-pushed on Mar 12, 2019
  309. ryanofsky commented at 6:01 pm on March 12, 2019: member
    Updated 591434b72c3b0ec218fbe30969ae5a819ca224c4 -> b7c78217ca7aa861b58fddcfdb82a09ca56f8023 (pr/wipc-sep.99 -> pr/wipc-sep.100, compare) with Marco’s GetAvailableCredit suggestion from #10973 (comment)
  310. promag commented at 10:58 pm on March 17, 2019: member

    Instead, I’d like to just add a new libbitcoin_node.a library, analogous to the existing libbitcoin_wallet.a library, and move symbol definitions like cs_main pcoinsTip chainActive there that wallet and gui code shouldn’t access.

    Nice!

  311. in src/interfaces/chain.h:250 in b7c78217ca outdated
    245+    {
    246+    public:
    247+        virtual ~Notifications() {}
    248+        virtual void TransactionAddedToMempool(const CTransactionRef& tx) {}
    249+        virtual void TransactionRemovedFromMempool(const CTransactionRef& ptx) {}
    250+        virtual void BlockConnected(const CBlock& block,
    


    jnewbery commented at 3:02 pm on March 18, 2019:
    Can you simplify this interface to (cont CBlock& block, const std::vector<CTransactionRef>& tx_conflicted)? The client can get the block hash using CBlock->GetHash().

    ryanofsky commented at 4:49 pm on March 18, 2019:

    re: #10973 (review)

    Can you simplify this interface to (cont CBlock& block, const std::vector<CTransactionRef>& tx_conflicted)?

    Simplified as suggested

  312. in src/wallet/wallet.cpp:4386 in b7c78217ca outdated
    4383@@ -4386,7 +4384,7 @@ std::shared_ptr<CWallet> CWallet::CreateWalletFromFile(interfaces::Chain& chain,
    4384     chain.loadWallet(interfaces::MakeWallet(walletInstance));
    4385 
    4386     // Register with the validation interface. It's ok to do this after rescan since we're still holding cs_main.
    


    jnewbery commented at 3:17 pm on March 18, 2019:

    I think this comment could be changed slightly now, since ‘we’ (the wallet) don’t ever hold cs_main now.

    since we're still holding cs_main -> since we're still holding the Chain::Lock interface.


    ryanofsky commented at 4:49 pm on March 18, 2019:

    re: #10973 (review)

    I think this comment could be changed slightly now, since ‘we’ (the wallet) don’t ever hold cs_main now.

    Changed this to reference locked_chain instead of cs_main (it seemed to good to reference the actual variable name).

  313. in src/wallet/wallet.h:813 in b7c78217ca outdated
    808@@ -808,6 +809,9 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
    809 
    810     std::set<COutPoint> setLockedCoins GUARDED_BY(cs_wallet);
    811 
    812+    /** Validation event callback handler. */
    813+    std::unique_ptr<interfaces::Handler> m_handler;
    


    jnewbery commented at 3:34 pm on March 18, 2019:
    I don’t really like this name m_handler, (or the class name HandlerImpl), since the name handler is generic for any interface handler. It’s more verbose, but I think m_validation_interface_handler and ValidationInterfaceHandlerImpl are more explicit.

    ryanofsky commented at 4:49 pm on March 18, 2019:

    re: #10973 (review)

    I don’t really like this name m_handler, (or the class name HandlerImpl)

    Renamed to m_chain_notifications_handler to match Chain::Notifications, Chain::handleNotifications, Chain::waitForNotifications.

  314. jnewbery commented at 3:51 pm on March 18, 2019: member

    I’ve reviewed 5c7f4118ef82248f50ff112828638e0a99247cd9 (Remove use CValidationInterface in wallet code) and it looks good so far! A few comments inline.

    Incidentally, this github PR is pretty unwieldly - the notes are very long, and without reading through them all it’s difficult to tell which comments are for the overall approach and which are for the commits under review now. I don’t know if’s worth it at this point, but it might be clearer to open one final PR for the last commits, and close this or leave it as the overarching PR.

  315. ryanofsky force-pushed on Mar 18, 2019
  316. ryanofsky commented at 5:46 pm on March 18, 2019: member

    Updated b7c78217ca7aa861b58fddcfdb82a09ca56f8023 -> 1a1036a5b3bc48715a5f3955e87203287c37210a (pr/wipc-sep.100 -> pr/wipc-sep.101, compare) with suggestions from #10973#pullrequestreview-215654868.

    Incidentally, this github PR is pretty unwieldly

    A downside of making a new PR is that comments that show up in the diffs will be gone. I think the diff comments are probably more useful than other historical comments which appear above, which I think no one will look at unless they are counting acks. (And if anyone is counting ACKs, there is only one so far from Marco in #10973 (comment) (pr/wipc-sep.97) before some recent cleanups.

  317. in src/wallet/wallet.h:1228 in 0ca5446db3 outdated
    1223@@ -1220,6 +1224,8 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
    1224 
    1225     /** Add a KeyOriginInfo to the wallet */
    1226     bool AddKeyOrigin(const CPubKey& pubkey, const KeyOriginInfo& info);
    1227+
    1228+    friend struct WalletTestingSetup;
    


    jamesob commented at 7:09 pm on March 18, 2019:
    Maybe outdated? Since m_chain_notifications_handler is public I don’t see why we’d need this.

    ryanofsky commented at 10:00 pm on March 18, 2019:

    re: #10973 (review)

    Maybe outdated? Since m_chain_notifications_handler is public I don’t see why we’d need this.

    It’s needed to avoid “error: cannot cast ‘CWallet’ to its private base class ‘interfaces::Chain::Notifications’” in the WalletTestingSetup constructor:

    https://github.com/bitcoin/bitcoin/blob/0ca5446db3cda7f911e911a094482311f6a71221/src/wallet/test/wallet_test_fixture.cpp#L16

    because the relevant base class is private:

    https://github.com/bitcoin/bitcoin/blob/0ca5446db3cda7f911e911a094482311f6a71221/src/wallet/wallet.h#L641

  318. jamesob approved
  319. jamesob commented at 9:41 pm on March 18, 2019: member

    utACK https://github.com/bitcoin/bitcoin/commit/1a1036a5b3bc48715a5f3955e87203287c37210a

    Changes look fine to me - feel free the ignore the nit. I’ll do some manual testing of this tomorrow.

  320. in src/wallet/wallet.h:949 in 1a1036a5b3 outdated
    945@@ -942,7 +946,7 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
    946     ScanResult ScanForWalletTransactions(const uint256& first_block, const uint256& last_block, const WalletRescanReserver& reserver, bool fUpdate);
    947     void TransactionRemovedFromMempool(const CTransactionRef &ptx) override;
    948     void ReacceptWalletTransactions();
    949-    void ResendWalletTransactions(int64_t nBestBlockTime, CConnman* connman) override EXCLUSIVE_LOCKS_REQUIRED(cs_main);
    950+    void ResendWalletTransactions(int64_t nBestBlockTime) override EXCLUSIVE_LOCKS_REQUIRED(cs_main);
    


    jnewbery commented at 4:57 pm on March 19, 2019:

    Is this EXCLUSIVE_LOCKS_REQUIRED(cs_main) still required? ResendWalletTransactions() grabs a locked_chain interface.

    See also the LOCKS_EXCLUDED(cs_main annotation on BlockUntilSyncedToCurrentChain() and the comment above it. Can that also go?

    The BlockUntilSyncedToCurrentChain() function can definitely use some clean-up after this PR to remove the locked_chain and move isPotentialTip out of the Chain::Lock interface, but that can wait for later.


    ryanofsky commented at 2:24 am on March 20, 2019:

    re: #10973 (review)

    Is this EXCLUSIVE_LOCKS_REQUIRED(cs_main) still required? ResendWalletTransactions() grabs a locked_chain interface.

    It’s not required and should have been removed. I replaced EXCLUSIVE_LOCKS_REQUIRED(cs_main) with a locked_chain argument.

    I also added todos in https://github.com/ryanofsky/bitcoin/blob/pr/wipc-sep.102/src/interfaces/chain.h#L46-L50 and https://github.com/ryanofsky/bitcoin/blob/pr/wipc-sep.102/src/interfaces/chain.cpp#L208-L212 for simplifying BlockUntilSyncedToCurrentChain and removing ResendWalletTransactions.

  321. in src/rpc/rawtransaction.cpp:800 in 1a1036a5b3 outdated
    793@@ -793,20 +794,11 @@ static UniValue combinerawtransaction(const JSONRPCRequest& request)
    794 UniValue SignTransaction(interfaces::Chain& chain, CMutableTransaction& mtx, const UniValue& prevTxsUnival, CBasicKeyStore *keystore, bool is_temp_keystore, const UniValue& hashType)
    


    jnewbery commented at 8:32 pm on March 19, 2019:

    I don’t very much like that:

    Those can both be done in a future PR.


    ryanofsky commented at 2:24 am on March 20, 2019:

    re: #10973 (review)

    Those can both be done in a future PR.

    Added todo (https://github.com/ryanofsky/bitcoin/blob/pr/wipc-sep.102/src/rpc/rawtransaction.cpp#L794-L799) and also moved findCoins code into a global method so it will be easier to get rid of the Chain argument later.

  322. in src/interfaces/chain.cpp:264 in 1a1036a5b3 outdated
    259+        assert(pcoinsTip);
    260+        CCoinsViewCache& chain_view = *::pcoinsTip;
    261+        CCoinsViewMemPool mempool_view(&chain_view, ::mempool);
    262+        for (auto& coin : coins) {
    263+            if (!mempool_view.GetCoin(coin.first, coin.second)) {
    264+                coin.second.Clear();
    


    jnewbery commented at 8:47 pm on March 19, 2019:

    Might be worth a comment here:

    0// Either the coin is not in the CCoinsViewCache or is spent. Clear it.
    

    ryanofsky commented at 2:21 am on March 20, 2019:

    re: #10973 (review)

    // Either the coin is not in the CCoinsViewCache or is spent. Clear it.

    Added comment

  323. jnewbery commented at 9:00 pm on March 19, 2019: member

    I’ve reviewed:

    • 0ca5446db3cda7f911e911a094482311f6a71221 (Remove use CValidationInterface in wallet code) utACK
    • f157e7a73ba746c38c5437540806151fbfa4b286 (Remove use of CRPCTable::appendCommand in wallet code)
    • 0bafbfcdd4b7d2393dc3e8a40b4ba7632117463a (Remove use of CCoinsViewMemPool::GetCoin in wallet code) and utACK
    • 1a1036a5b3bc48715a5f3955e87203287c37210a (Remove remaining wallet accesses to node globals)

    I found the Remove use of CRPCTable::appendCommand in wallet code quite hard to review, probably due to my C++ ineptitude. I certainly wouldn’t want to hold up this PR because I’m not able to fully work out what’s going on in that commit. I think it could be made marginally simpler by removing support for multiple clients (https://github.com/bitcoin/bitcoin/pull/10973#discussion_r186538449), but Russ points out that most of the complexity is elsewhere. I also think some additional commenting in the RpcForwarder class could help.

    Russ is going to look at moving more code into the RPC server to simplify that commit, but again, I don’t want to hold this up because of my inability to review. If other reviewers are happy to ACK this, then it should stay as it is.

  324. ryanofsky commented at 11:28 am on March 20, 2019: member

    Updated 1a1036a5b3bc48715a5f3955e87203287c37210a -> bffd676263953c662245be82c13a06c9bf5fbb20 (pr/wipc-sep.101 -> pr/wipc-sep.102, compare) with John’s suggestions. Updated bffd676263953c662245be82c13a06c9bf5fbb20 -> d358466de15ef29c1d2bccb9aebab360d574d1d0 (pr/wipc-sep.102 -> pr/wipc-sep.103, compare) renaming new src/node/coin.h file to be consistent with existing src/node/transaction.h file.

    I found the Remove use of CRPCTable::appendCommand in wallet code [f157e7a73ba746c38c5437540806151fbfa4b286] quite hard to review

    New version of this commit (4e4d9e9f85eaf9c3bec48559bd4cad3e8a9333ca) should be a lot simpler. I was too reluctant before to change rpc server code. Should be much more straightforward now.

  325. ryanofsky force-pushed on Mar 20, 2019
  326. ryanofsky force-pushed on Mar 20, 2019
  327. jnewbery commented at 8:27 pm on March 20, 2019: member

    utACK d358466de15ef29c1d2bccb9aebab360d574d1d0. This version is much clearer to me than the previous branch. Thank you!

    I still think that handling multiple clients is an unnecessary complication for this PR. The RPC_WALLET_NOT_FOUND catch/throw in the RpcHandlerImpl actor and the last_handler bool passed to the actor seem particularly strange to me.

    That said, I’ve reviewed the code and it all seems fine. I wouldn’t want to hold this PR up because of my own aesthetic inclinations.

    Very nice work Russ. Thanks for seeing this through!

  328. meshcollider commented at 7:57 am on March 21, 2019: contributor
    I think this is ready 🎉
  329. meshcollider merged this on Mar 21, 2019
  330. meshcollider closed this on Mar 21, 2019

  331. meshcollider referenced this in commit 2607d960a0 on Mar 21, 2019
  332. jnewbery removed this from the "Blockers" column in a project

  333. ryanofsky commented at 5:07 pm on March 22, 2019: member

    re: #10973#pullrequestreview-213000398

    Instead, I’d like to just add a new libbitcoin_node.a library, analogous to the existing libbitcoin_wallet.a library, and move symbol definitions like cs_main pcoinsTip chainActive there that wallet and gui code shouldn’t access

    To follow up, I did this in #15638 and #15639, only using the existing libbitcoin_server.a library for simplicity instead of adding a new libbitcoin_node.a library.

  334. domob1812 referenced this in commit 69e327b36b on Mar 25, 2019
  335. PastaPastaPasta referenced this in commit 30eec06098 on Sep 19, 2019
  336. PastaPastaPasta referenced this in commit e712a34b7e on Dec 22, 2019
  337. PastaPastaPasta referenced this in commit 9efa568833 on Dec 22, 2019
  338. PastaPastaPasta referenced this in commit d7df373a0b on Jan 2, 2020
  339. PastaPastaPasta referenced this in commit 1f29aae2eb on Jan 4, 2020
  340. PastaPastaPasta referenced this in commit ac94b9b4a8 on Jan 4, 2020
  341. PastaPastaPasta referenced this in commit 05ccd98663 on Jan 10, 2020
  342. PastaPastaPasta referenced this in commit c43d581347 on Jan 10, 2020
  343. PastaPastaPasta referenced this in commit fc4ab83c83 on Jan 10, 2020
  344. PastaPastaPasta referenced this in commit 20e8ce81db on Jan 12, 2020
  345. deadalnix referenced this in commit 39c9afd531 on Apr 28, 2020
  346. deadalnix referenced this in commit a7aad1a3ba on May 1, 2020
  347. deadalnix referenced this in commit a6069ab2ad on May 2, 2020
  348. deadalnix referenced this in commit 5cf1cf93d7 on May 3, 2020
  349. PastaPastaPasta referenced this in commit 27ea6bd998 on Jul 17, 2020
  350. PastaPastaPasta referenced this in commit 897a6ee5eb on Jul 17, 2020
  351. PastaPastaPasta referenced this in commit 81ba40cead on Jul 19, 2020
  352. PastaPastaPasta referenced this in commit 7b091fb99f on Jul 21, 2020
  353. ckti referenced this in commit 052ebdb7fd on Mar 28, 2021
  354. gades referenced this in commit d4a6c7a3c6 on Jun 30, 2021
  355. 5tefan referenced this in commit fe1aa6fe0e on Jul 28, 2021
  356. 5tefan referenced this in commit d1ea7d9e4c on Jul 28, 2021
  357. 5tefan referenced this in commit c64f797467 on Jul 28, 2021
  358. PastaPastaPasta referenced this in commit 59cfd5263a on Jul 28, 2021
  359. PastaPastaPasta referenced this in commit 1ada50fee0 on Oct 23, 2021
  360. PastaPastaPasta referenced this in commit 3e8670d81a on Oct 24, 2021
  361. PastaPastaPasta referenced this in commit df0373cd76 on Oct 25, 2021
  362. PastaPastaPasta referenced this in commit 1834aa9a9a on Oct 25, 2021
  363. kittywhiskers referenced this in commit ab6f8fe9c1 on Oct 31, 2021
  364. kittywhiskers referenced this in commit ab7f283b5d on Nov 1, 2021
  365. kittywhiskers referenced this in commit 528698a475 on Nov 1, 2021
  366. kittywhiskers referenced this in commit 50a3c20f50 on Nov 1, 2021
  367. kittywhiskers referenced this in commit ee24b4ca9e on Nov 1, 2021
  368. PastaPastaPasta referenced this in commit 75fda781df on Nov 1, 2021
  369. PastaPastaPasta referenced this in commit 051bdef7f5 on Nov 1, 2021
  370. PastaPastaPasta referenced this in commit 48826b429d on Nov 3, 2021
  371. kittywhiskers referenced this in commit 49a8b953bc on Nov 4, 2021
  372. kittywhiskers referenced this in commit af9baa6544 on Nov 4, 2021
  373. malbit referenced this in commit 8310ffb44e on Nov 5, 2021
  374. kittywhiskers referenced this in commit dcc6876fd8 on Nov 6, 2021
  375. kittywhiskers referenced this in commit d2c1848946 on Nov 14, 2021
  376. kittywhiskers referenced this in commit 0ecb450232 on Nov 14, 2021
  377. kittywhiskers referenced this in commit 721458dc39 on Nov 14, 2021
  378. kittywhiskers referenced this in commit 438c93bd9a on Nov 14, 2021
  379. UdjinM6 referenced this in commit a3a8bfee08 on Nov 15, 2021
  380. pravblockc referenced this in commit a7a32011d3 on Nov 18, 2021
  381. pravblockc referenced this in commit bd6dfe8e34 on Nov 18, 2021
  382. 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-07-01 10:13 UTC

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