-
Notifications
You must be signed in to change notification settings - Fork 35.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce disable-wallet / no-wallet mode. #2901
Conversation
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/116c9582760e1fc37408ce74abd0769062aa9025 for binaries and test log. |
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/588e13c40f4e66b3d789f9b426ef173acc21d9ed for binaries and test log. |
Completed review of all RPCs for require-wallet status, and fixed a couple bugs found in testing. disable-wallet mode should be working in bitcoind now. These are the RPCs that remain available:
|
Updating CreateNewBlock() to take a script, rather than a CReserveKey, should make it possible to enable getblocktemplate RPC. |
disable-wallet mode now skips BDB environment setup, reducing startup RSS here by over 40MB (h/t @gmaxwell) |
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/db2b19ee838cdab513a6503ddefc16d985b59e87 for binaries and test log. |
Interesting how little code changes were necessary. |
Is there a good reason why this isn't intended to be merged? :p |
Cannot be merged... as-is. I wouldn't mind merging a cleaned up version, which attention paid to indentation and such. |
Only argument I can make against it is that it's more configurations to test and getting the 40mbytes back from BDB on walletless nodes would be nice. |
Also, my paranoid fear is that I missed a spot in review and testing, and someone will figure out a way to crash a node by triggering a wallet lookup somehow, somewhere. |
All P2P-induced calls from main to wallet should go through the registration interface. |
Code cleaned up, and perhaps merge-worthy. |
TODO list:
|
Thoughts on just removing getwork, since it's useless with mainnet and getblocktemplate's use of CreateNewBlock doesn't need a generation transaction at all? |
Internal miner needs a generation transaction. :-/ But yea, removing getwork sounds great to me, except for the whole not solving the needing a generation transaction bit... |
Why are we keeping the internal miner at all? |
Because we have not provided an adequate replacement with the package, and it's commonly used and perfectly reasonable on testnet. |
@gmaxwell Agreed, it's the only miner I use with Testnet as it's so damn easy to use and JUST works. |
With getblocktemplate and submitblock working, this type of node could still be used for p2pool or pools, with the payout address arbitrarily elsewhere for security. That is already possible today with normal nodes with a wallet, but this at least shrinks the memory requirement per p2pool node, which is great. |
The mining-removal discussion is outside the scope of this pull request, and is better discussed in active mailing list threads or pull req #2905 getblocktemplate can work just fine in disablewallet mode; just needs additional work appended here. Hence "TODO" |
Nice. Incidentally this would also be the "no wallets loaded" case for multi wallet support. Haven't tested yet, but from looking at the code: validateaddress does a IsMine check (dereferencing pWalletMain) when the address is valid. Will this crash? |
if (r == CDBEnv::RECOVER_FAIL) | ||
return InitError(_("wallet.dat corrupt, salvage failed")); | ||
} | ||
} // (1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does that (1) mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look at the commits one-by-one. In the code movement commit, you see a "if (1) { ... }" change. This comment is a remnant of that change (that should be removed).
Rebased on top of #2928 and fixed @Diapolo 's nit. getblocktemplate now works in no-wallet mode. OP updated accordingly. Should be merge ready, modulo another IsMine() review. I reviewed quickly based on @laanwj 's comment, but did not see the case. Will look more closely with brain fully engaged before saying it is 100% merge-ready :) |
Rebased, and fixed the bug found by @laanwj |
no-wallet mode is now ready for reviewing and merging. |
Nit / pet peeve: negative options, because I hate double-negatives (-disablewallet=0 means "yes I want a wallet please"). Suggest that the option be: -wallet= to mean "no wallet, please." (default right now is -wallet=wallet.dat). |
What about "-nowallet"? |
@laanwj |
I change my mind. I like -disablewallet the way it is now. -disablewallet is best as a distinct parameter for a specific purpose. It is more confusing to overload -wallet= with another possible meaning, and you don't want it to attempt load a wallet file of that name if you have a typo. Bleh, before we bikeshed on the name, could folks please review the actual code? |
As I said, -foo=0 is -nofoo for every parameter we use, why special case this one? |
-nowallet is fine with me, as long as it does not break, or otherwise require contortions of, the existing wallet pathname support. "-nowallet" seems quite natural, but a concern is that people were discussing -wallet=foo.dat -wallet=bar.dat and similar extensions for multiple wallet support. I'm happy to go with whatever most people prefer. |
@@ -1034,6 +1037,8 @@ void ServiceConnection(AcceptedConnection *conn) | |||
const CRPCCommand *pcmd = tableRPC[strMethod]; | |||
if (!pcmd) | |||
throw JSONRPCError(RPC_METHOD_NOT_FOUND, "Method not found"); | |||
if (pcmd->reqWallet && !pwalletMain) | |||
throw JSONRPCError(RPC_METHOD_NOT_FOUND, "Method not found (disabled)"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "Method requires wallet" or something explicitly mentioning why it is disabled is more useful.
Code looks good, apart from a few nits (see inline), needs rebase though. I don't feel strongly about -disablewallet or -nowallet or -wallet=. We just need to know how it may later integrate with multiwallet (which naturally extends nowallet). |
Rebased. This is merge-ready, except for option-naming shed-painting. |
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/5d4f3a1f0cbdf52257b41ea09d175c0018ad9434 for binaries and test log. |
-disablewallet is a fine shade of paint for the shed; I think you should rebase, sanity test one last time, and merge. |
https://github.com/wtogami/bitcoin/commits/btc-0.8.5-disablewallet Please |
https://bitcointalk.org/index.php?topic=320695.0 |
|
s/Wallet disabled.../Wallet disabled!/ |
@jgarzik Can you rebase please? |
See #3240 |
Goal: As one goal is to eventually separate wallet/GUI from public blockchain engine, it is useful to explore what such an engine would look like. As such, disablewallet=1 will enforce pwalletMain==NULL, or "no-wallet mode."
Many RPCs are disabled. getblocktemplate does continue to work, permitting no-wallet mining.