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:
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).
ryanofsky force-pushed
on Aug 2, 2017
ryanofsky referenced this in commit
dd4896e35b
on Aug 2, 2017
jonasschnelli
commented at 9:41 am on August 3, 2017:
contributor
Concept ACK
jonasschnelli added the label
Wallet
on Aug 3, 2017
jonasschnelli added the label
Refactoring
on Aug 3, 2017
ryanofsky force-pushed
on Aug 14, 2017
ryanofsky renamed this:
WIP: Add IPC layer between node and wallet
Add IPC layer between node and wallet
on Aug 14, 2017
ryanofsky referenced this in commit
d97fe2016c
on Aug 14, 2017
practicalswift referenced this in commit
eedffefa63
on Aug 15, 2017
practicalswift referenced this in commit
9c5bca3091
on Aug 15, 2017
practicalswift referenced this in commit
e03c9b0c3d
on Aug 15, 2017
practicalswift referenced this in commit
bc60c2c228
on Aug 16, 2017
practicalswift referenced this in commit
d1010e6ab3
on Aug 16, 2017
ryanofsky force-pushed
on Aug 16, 2017
practicalswift referenced this in commit
b664be4ba8
on Aug 22, 2017
ryanofsky force-pushed
on Aug 25, 2017
laanwj referenced this in commit
07c92b98e2
on Aug 25, 2017
ryanofsky force-pushed
on Aug 25, 2017
ryanofsky force-pushed
on Aug 29, 2017
ryanofsky
commented at 5:05 pm on September 1, 2017:
member
@jnewbery, the change to stop deduping link arguments is in Makefile.am here
in
src/ipc/local/bitcoind.cpp:178
in
c1194635c6outdated
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
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.
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.
in
src/ipc/interfaces.h:35
in
e26e00bd3foutdated
13@@ -14,6 +14,26 @@ class Chain
14 public:
15 virtual ~Chain() {}
1617+ //! 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?
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.
ryanofsky force-pushed
on Apr 10, 2018
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:
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.
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.
MarcoFalke referenced this in commit
3cf76c23fb
on Apr 11, 2018
ryanofsky force-pushed
on Apr 11, 2018
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
ryanofsky force-pushed
on Apr 17, 2018
ryanofsky force-pushed
on Apr 17, 2018
ryanofsky force-pushed
on Apr 20, 2018
ryanofsky force-pushed
on Apr 23, 2018
ryanofsky force-pushed
on Apr 25, 2018
ryanofsky force-pushed
on Apr 25, 2018
ryanofsky force-pushed
on Apr 26, 2018
ryanofsky force-pushed
on Apr 27, 2018
in
src/qt/test/wallettests.cpp:149
in
a0279e4074outdated
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());
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)
in
src/interfaces/chain.h:50
in
ba1e24b718outdated
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
Thanks, fixed in 7f2f5cc41aa05e6f2ad7bfa74173c11136b67cf9
in
src/interfaces/chain.h:86
in
ba1e24b718outdated
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.
Good catch, removed in 63dd8abdf822026a4a93356546ff1220e6c00e9e
ryanofsky force-pushed
on May 2, 2018
in
src/wallet/wallet.cpp:1781
in
7f08793608outdated
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.
jamesob
commented at 2:47 pm on May 3, 2018:
member
Needs rebase.
ryanofsky force-pushed
on May 3, 2018
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).
in
src/interfaces/chain.cpp:381
in
7a6069a3c5outdated
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();) {
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.
in
src/interfaces/chain.cpp:355
in
604c567e3coutdated
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:
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.
jamesob
commented at 9:15 pm on May 3, 2018:
member
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.
in
src/interfaces/node.cpp:55
in
af8f808769outdated
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.
in
src/interfaces/chain.h:220
in
af8f808769outdated
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
I think the (Scheduler is ignored if client is out-of-process). comment can be saved for #10102
Sure, removed in 0d9ba1a093e30d77348efc55f0ff6599cef76621.
in
src/interfaces/chain.h:70
in
af8f808769outdated
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
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?
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.
in
src/wallet/rpcwallet.cpp:3420
in
af8f808769outdated
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?
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.
in
src/interfaces/chain.h:86
in
af8f808769outdated
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.
696@@ -698,7 +697,7 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
697698 /* 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. */
Comment is wrong. Needs to be updated to Should be called with non-zero block_hash and posInBlock…
Thanks, fixed in 77cd28c7f5043ff82500fe59936d7a6abc8d0bf6
in
src/wallet/wallet.h:752
in
af8f808769outdated
750@@ -744,7 +751,7 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
751 *
752 * Protected by cs_main (see BlockUntilSyncedToCurrentChain)
The “missing block hash” and “missing block time” outputs here are a change in behaviour (and could potentially break clients using the dumpwallet API)
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.
in
src/wallet/rpcwallet.cpp:1624
in
af8f808769outdated
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.
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…
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.
in
src/wallet/wallet.cpp:1786
in
af8f808769outdated
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()) {
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.
in
src/wallet/wallet.cpp:3822
in
af8f808769outdated
3817@@ -3795,8 +3818,9 @@ void CWallet::GetKeyBirthTimes(std::map<CTxDestination, int64_t> &mapKeyBirth) c
3818 }
38193820 // 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
I think this comment should make clear that the block must be available on disk:
Renamed as suggested and added your comment in 731b02dd1885e5d7242c894d14054ead91044550.
in
src/interfaces/chain.h:76
in
af8f808769outdated
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
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.
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.
in
src/interfaces/chain.cpp:370
in
af8f808769outdated
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
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.
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.
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.
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.
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.
ryanofsky force-pushed
on May 8, 2018
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
Concept ACK on a better defined interface between wallet and node.
promag
commented at 7:45 pm on May 17, 2018:
member
Concept ACK, makes sense!
jonasschnelli
commented at 7:48 pm on May 17, 2018:
contributor
Concept ACK
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.
jnewbery
commented at 8:02 pm on May 17, 2018:
member
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
in
src/interfaces/chain.h:197
in
a71c5b8e73outdated
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:
This feels like a weird method to put in the chain interface
Agree, removed this method.
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.
MarcoFalke
commented at 7:50 pm on May 22, 2018:
member
utACKf06a3cc9190bcac4f6109bf9a9f03f92edf1d1fd (not the head commit)
Will leave two one questions for clarification.
in
src/wallet/rpcwallet.cpp:73
in
a71c5b8e73outdated
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.
Mind to explain why this is removed? I believe Construct will still return without creating a chain client and thus RegisterWalletRPCCommands is never called.
ryanofsky force-pushed
on May 24, 2018
ryanofsky force-pushed
on Jun 4, 2018
DrahtBot added the label
Needs rebase
on Jun 11, 2018
ryanofsky force-pushed
on Jun 14, 2018
DrahtBot removed the label
Needs rebase
on Jun 14, 2018
ryanofsky force-pushed
on Jun 19, 2018
in
src/optional.h:9
in
4a1c901c7eoutdated
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>
DrahtBot added the label
Needs rebase
on Jun 24, 2018
ryanofsky force-pushed
on Jun 26, 2018
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
ryanofsky force-pushed
on Jun 27, 2018
DrahtBot removed the label
Needs rebase
on Jun 27, 2018
unknown approved
DrahtBot added the label
Needs rebase
on Jul 7, 2018
ryanofsky force-pushed
on Jul 10, 2018
ryanofsky force-pushed
on Jul 10, 2018
DrahtBot removed the label
Needs rebase
on Jul 11, 2018
DrahtBot added the label
Needs rebase
on Jul 11, 2018
ryanofsky force-pushed
on Jul 12, 2018
DrahtBot removed the label
Needs rebase
on Jul 12, 2018
DrahtBot added the label
Needs rebase
on Jul 13, 2018
ryanofsky force-pushed
on Jul 18, 2018
DrahtBot removed the label
Needs rebase
on Jul 18, 2018
DrahtBot added the label
Needs rebase
on Jul 20, 2018
ryanofsky force-pushed
on Aug 3, 2018
ryanofsky force-pushed
on Aug 3, 2018
DrahtBot removed the label
Needs rebase
on Aug 3, 2018
DrahtBot added the label
Needs rebase
on Aug 6, 2018
ryanofsky force-pushed
on Aug 6, 2018
DrahtBot removed the label
Needs rebase
on Aug 6, 2018
DrahtBot added the label
Needs rebase
on Aug 7, 2018
ryanofsky force-pushed
on Aug 7, 2018
DrahtBot removed the label
Needs rebase
on Aug 7, 2018
DrahtBot added the label
Needs rebase
on Aug 9, 2018
ryanofsky force-pushed
on Aug 9, 2018
DrahtBot removed the label
Needs rebase
on Aug 9, 2018
DrahtBot added the label
Needs rebase
on Aug 13, 2018
ryanofsky force-pushed
on Aug 14, 2018
DrahtBot removed the label
Needs rebase
on Aug 14, 2018
DrahtBot added the label
Needs rebase
on Aug 23, 2018
ryanofsky force-pushed
on Aug 23, 2018
ryanofsky force-pushed
on Aug 23, 2018
DrahtBot removed the label
Needs rebase
on Aug 23, 2018
ryanofsky force-pushed
on Aug 24, 2018
DrahtBot added the label
Needs rebase
on Aug 25, 2018
in
src/wallet/wallet.cpp:2636
in
2aa964dc53outdated
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();
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:
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]
in
src/interfaces/chain.cpp:81
in
e44e639558outdated
@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:
practicalswift
commented at 7:57 am on September 21, 2018:
02018-09-1914: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-2004: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-2222:50:20 cpplint(pr=10973): src/interfaces/chain.cpp:168: Single-parameter constructors should be marked explicit.
in
src/interfaces/chain.cpp:182
in
e44e639558outdated
practicalswift
commented at 7:57 am on September 21, 2018:
02018-09-1914: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-2004: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-2222:50:20 cpplint(pr=10973): src/interfaces/chain.cpp:182: Single-parameter constructors should be marked explicit.
in
src/interfaces/chain.cpp:212
in
e44e639558outdated
in
src/interfaces/chain.cpp:362
in
e44e639558outdated
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-1914: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-2004: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-2222:50:20 cpplint(pr=10973): src/interfaces/chain.cpp:362: Single-parameter constructors should be marked explicit.
in
src/interfaces/chain.cpp:373
in
e44e639558outdated
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]
in
src/interfaces/chain.cpp:432
in
e44e639558outdated
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]
in
src/wallet/wallet.cpp:950
in
e44e639558outdated
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]
in
src/threadsafety.h:62
in
e44e639558outdated
53@@ -54,4 +54,15 @@
54 #define ASSERT_EXCLUSIVE_LOCK(...)
55 #endif // __GNUC__
5657+// 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-2004: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-2222:50:20 cpplint(pr=10973): src/threadsafety.h:62: Single-parameter constructors should be marked explicit. [runtime/explicit] [5]
in
src/interfaces/chain.h:209
in
e44e639558outdated
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.
DrahtBot added the label
Needs rebase
on Sep 24, 2018
ryanofsky force-pushed
on Sep 26, 2018
DrahtBot removed the label
Needs rebase
on Sep 26, 2018
DrahtBot added the label
Needs rebase
on Sep 26, 2018
ryanofsky force-pushed
on Sep 27, 2018
DrahtBot removed the label
Needs rebase
on Sep 27, 2018
jamesob
commented at 7:29 am on October 10, 2018:
member
Should this be closed now that #14437 has been opened?
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.
in
src/interfaces/chain.cpp:324
in
45b23efaadoutdated
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?
in
src/interfaces/chain.cpp:410
in
45b23efaadoutdated
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 ; :-)
in
src/rpc/rawtransaction.cpp:768
in
45b23efaadoutdated
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.
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?
ryanofsky force-pushed
on Nov 12, 2018
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.
DrahtBot added the label
Needs rebase
on Nov 13, 2018
peepeemlove approved
jfhk referenced this in commit
af421299e2
on Nov 14, 2018
JeremyRubin referenced this in commit
b03e4e75d6
on Nov 24, 2018
HashUnlimited referenced this in commit
992d4c03ca
on Nov 26, 2018
ryanofsky force-pushed
on Nov 26, 2018
DrahtBot removed the label
Needs rebase
on Nov 26, 2018
DrahtBot added the label
Needs rebase
on Nov 30, 2018
ryanofsky force-pushed
on Dec 6, 2018
DrahtBot removed the label
Needs rebase
on Dec 6, 2018
DrahtBot added the label
Needs rebase
on Dec 12, 2018
peepeemlove approved
ryanofsky force-pushed
on Dec 17, 2018
DrahtBot removed the label
Needs rebase
on Dec 17, 2018
DrahtBot added the label
Needs rebase
on Dec 18, 2018
ryanofsky force-pushed
on Dec 18, 2018
DrahtBot removed the label
Needs rebase
on Dec 18, 2018
DrahtBot added the label
Needs rebase
on Jan 10, 2019
ryanofsky force-pushed
on Jan 10, 2019
DrahtBot removed the label
Needs rebase
on Jan 10, 2019
DrahtBot added the label
Needs rebase
on Jan 15, 2019
ryanofsky force-pushed
on Jan 23, 2019
DrahtBot removed the label
Needs rebase
on Jan 23, 2019
meshcollider referenced this in commit
72ca72e637
on Jan 30, 2019
DrahtBot added the label
Needs rebase
on Jan 30, 2019
ryanofsky force-pushed
on Jan 30, 2019
DrahtBot removed the label
Needs rebase
on Jan 30, 2019
DrahtBot added the label
Needs rebase
on Feb 10, 2019
ryanofsky force-pushed
on Feb 11, 2019
DrahtBot removed the label
Needs rebase
on Feb 11, 2019
DrahtBot added the label
Needs rebase
on Feb 15, 2019
MarcoFalke referenced this in commit
45f434f44d
on Mar 4, 2019
ryanofsky force-pushed
on Mar 4, 2019
DrahtBot removed the label
Needs rebase
on Mar 4, 2019
Remove use CValidationInterface in wallet code
This commit does not change behavior.
91868e6288
Remove use of CRPCTable::appendCommand in wallet code
This commit does not change behavior.
4e4d9e9f85
Remove use of CCoinsViewMemPool::GetCoin in wallet code
This commit does not change behavior.
b1b2b23892
ryanofsky force-pushed
on Mar 5, 2019
MarcoFalke deleted a comment
on Mar 6, 2019
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:
#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.
MarcoFalke
commented at 7:16 pm on March 6, 2019:
member
utACK6898f53760
Remove remaining wallet accesses to node globalsd358466de1
fanquake added this to the "Blockers" column in a project
in
src/rpc/rawtransaction.cpp:806
in
6898f53760outdated
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.
in
src/wallet/rpcwallet.cpp:4162
in
6898f53760outdated
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.
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.
in
src/interfaces/chain.cpp:341
in
6898f53760outdated
nit, maybe a bit late, but should be uppercase RPC?
IMO, strict camel case without exceptions for acronyms is easier to read. (JSONRPCRequestJsonRpcRequest)
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?
ryanofsky force-pushed
on Mar 12, 2019
ryanofsky
commented at 0:55 am on March 12, 2019:
member
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.
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_mainpcoinsTipchainActive 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.
ryanofsky force-pushed
on Mar 12, 2019
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.
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?
ryanofsky force-pushed
on Mar 12, 2019
ryanofsky
commented at 6:01 pm on March 12, 2019:
member
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_mainpcoinsTipchainActive there that wallet and gui code shouldn’t access.
Nice!
in
src/interfaces/chain.h:250
in
b7c78217caoutdated
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().
Can you simplify this interface to (cont CBlock& block, const std::vector<CTransactionRef>& tx_conflicted)?
Simplified as suggested
in
src/wallet/wallet.cpp:4386
in
b7c78217caoutdated
4383@@ -4386,7 +4384,7 @@ std::shared_ptr<CWallet> CWallet::CreateWalletFromFile(interfaces::Chain& chain,
4384 chain.loadWallet(interfaces::MakeWallet(walletInstance));
43854386 // Register with the validation interface. It's ok to do this after rescan since we're still holding cs_main.
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.
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.
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.
ryanofsky force-pushed
on Mar 18, 2019
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.
in
src/wallet/wallet.h:1228
in
0ca5446db3outdated
1223@@ -1220,6 +1224,8 @@ class CWallet final : public CCryptoKeyStore, public CValidationInterface
12241225 /** Add a KeyOriginInfo to the wallet */
1226 bool AddKeyOrigin(const CPubKey& pubkey, const KeyOriginInfo& info);
1227+
1228+ friend struct WalletTestingSetup;
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:
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.
// Either the coin is not in the CCoinsViewCache or is spent. Clear it.
Added comment
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.
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.
ryanofsky force-pushed
on Mar 20, 2019
ryanofsky force-pushed
on Mar 20, 2019
jnewbery
commented at 8:27 pm on March 20, 2019:
member
utACKd358466de15ef29c1d2bccb9aebab360d574d1d0. 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!
meshcollider
commented at 7:57 am on March 21, 2019:
contributor
I think this is ready 🎉
meshcollider merged this
on Mar 21, 2019
meshcollider closed this
on Mar 21, 2019
meshcollider referenced this in commit
2607d960a0
on Mar 21, 2019
jnewbery removed this from the "Blockers" column in a project
ryanofsky
commented at 5:07 pm on March 22, 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
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.
domob1812 referenced this in commit
69e327b36b
on Mar 25, 2019
PastaPastaPasta referenced this in commit
30eec06098
on Sep 19, 2019
PastaPastaPasta referenced this in commit
e712a34b7e
on Dec 22, 2019
PastaPastaPasta referenced this in commit
9efa568833
on Dec 22, 2019
PastaPastaPasta referenced this in commit
d7df373a0b
on Jan 2, 2020
PastaPastaPasta referenced this in commit
1f29aae2eb
on Jan 4, 2020
PastaPastaPasta referenced this in commit
ac94b9b4a8
on Jan 4, 2020
PastaPastaPasta referenced this in commit
05ccd98663
on Jan 10, 2020
PastaPastaPasta referenced this in commit
c43d581347
on Jan 10, 2020
PastaPastaPasta referenced this in commit
fc4ab83c83
on Jan 10, 2020
PastaPastaPasta referenced this in commit
20e8ce81db
on Jan 12, 2020
deadalnix referenced this in commit
39c9afd531
on Apr 28, 2020
deadalnix referenced this in commit
a7aad1a3ba
on May 1, 2020
deadalnix referenced this in commit
a6069ab2ad
on May 2, 2020
deadalnix referenced this in commit
5cf1cf93d7
on May 3, 2020
PastaPastaPasta referenced this in commit
27ea6bd998
on Jul 17, 2020
PastaPastaPasta referenced this in commit
897a6ee5eb
on Jul 17, 2020
PastaPastaPasta referenced this in commit
81ba40cead
on Jul 19, 2020
PastaPastaPasta referenced this in commit
7b091fb99f
on Jul 21, 2020
ckti referenced this in commit
052ebdb7fd
on Mar 28, 2021
gades referenced this in commit
d4a6c7a3c6
on Jun 30, 2021
5tefan referenced this in commit
fe1aa6fe0e
on Jul 28, 2021
5tefan referenced this in commit
d1ea7d9e4c
on Jul 28, 2021
5tefan referenced this in commit
c64f797467
on Jul 28, 2021
PastaPastaPasta referenced this in commit
59cfd5263a
on Jul 28, 2021
PastaPastaPasta referenced this in commit
1ada50fee0
on Oct 23, 2021
PastaPastaPasta referenced this in commit
3e8670d81a
on Oct 24, 2021
PastaPastaPasta referenced this in commit
df0373cd76
on Oct 25, 2021
PastaPastaPasta referenced this in commit
1834aa9a9a
on Oct 25, 2021
kittywhiskers referenced this in commit
ab6f8fe9c1
on Oct 31, 2021
kittywhiskers referenced this in commit
ab7f283b5d
on Nov 1, 2021
kittywhiskers referenced this in commit
528698a475
on Nov 1, 2021
kittywhiskers referenced this in commit
50a3c20f50
on Nov 1, 2021
kittywhiskers referenced this in commit
ee24b4ca9e
on Nov 1, 2021
PastaPastaPasta referenced this in commit
75fda781df
on Nov 1, 2021
PastaPastaPasta referenced this in commit
051bdef7f5
on Nov 1, 2021
PastaPastaPasta referenced this in commit
48826b429d
on Nov 3, 2021
kittywhiskers referenced this in commit
49a8b953bc
on Nov 4, 2021
kittywhiskers referenced this in commit
af9baa6544
on Nov 4, 2021
malbit referenced this in commit
8310ffb44e
on Nov 5, 2021
kittywhiskers referenced this in commit
dcc6876fd8
on Nov 6, 2021
kittywhiskers referenced this in commit
d2c1848946
on Nov 14, 2021
kittywhiskers referenced this in commit
0ecb450232
on Nov 14, 2021
kittywhiskers referenced this in commit
721458dc39
on Nov 14, 2021
kittywhiskers referenced this in commit
438c93bd9a
on Nov 14, 2021
UdjinM6 referenced this in commit
a3a8bfee08
on Nov 15, 2021
pravblockc referenced this in commit
a7a32011d3
on Nov 18, 2021
pravblockc referenced this in commit
bd6dfe8e34
on Nov 18, 2021
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2024-12-18 15:12 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me