detach wallet from miner #5994

jonasschnelli · 2015-04-10T11:02:43Z

This will interfere with #5993.
if this makes sense (conceptual), i'll rebase this after merging of @sipa's #5993 or @jtimon's #4793.

Next steps would be to add a argument pubkeyhash for generate to completely decouple.
generate could check over CMainSignals if a registered "device" can provide a pubkey in case of no given key over the rpc argument.

jgarzik · 2015-04-12T15:31:26Z

lightly tested ACK

Thanks for doing this. I coded this a while ago, then set it aside. Your version, with registration, is cleaner.

Diapolo · 2015-04-12T20:36:14Z

src/wallet/wallet.cpp

@@ -1208,7 +1208,7 @@ CAmount CWalletTx::GetCredit(const isminefilter& filter) const
 }

 CAmount CWalletTx::GetImmatureCredit(bool fUseCache) const
-{
+{    


Nit: This seems to have sneaked in?

jonasschnelli · 2015-04-13T13:06:53Z

fixed @Diapolo's nits.

jtimon · 2015-04-14T11:25:13Z

Concept ack.
Given that you're touching their interfaces already, could CreateNewBlockWithScript() ProcessBlockFound(), BitcoinMiner() and GenerateBitcoins() take const CChainParams& chainparams as parameter?

jonasschnelli · 2015-04-14T12:16:59Z

Added a commit on top to help improve global state independence by passing CChainParams for the touched functions.

jtimon · 2015-04-14T13:19:40Z

ut ACK, it is very nice to decouple miner.o from the wallet.

jtimon · 2015-04-16T01:09:42Z

Needs rebase

jonasschnelli · 2015-04-16T07:36:58Z

Rebased and squashed [squashme] commit.

jtimon · 2015-04-16T08:50:12Z

I would also squash the second commit, leaving the note in the commit descrption. Specially, you never want to create CreateNewBlockWithScript.
In any case, minor nit, re-utAck.

jonasschnelli · 2015-04-16T08:52:47Z

Agreed. Squashed.

sipa · 2015-04-24T09:46:44Z

src/validationinterface.h

@@ -35,6 +36,8 @@ class CValidationInterface {
    virtual void Inventory(const uint256 &hash) {};
    virtual void ResendWalletTransactions(int64_t nBestBlockTime) {};
    virtual void BlockChecked(const CBlock&, const CValidationState&) {};
+    virtual void GetScriptForMining(CScript &script) {};


I would say this needs to be able to fail (if no wallet is connected), and have the miner code deal with that case. Otherwise you can't really make it independent of the wallet (if it needs to assume a wallet that can provide a script output for mining is present).

I think it can fail. If no listening module provides a CScript through signal ScriptForMining the miner will continue with a empty script which should result in a unspendable coinbase? But i didn't tested that. Will do.

I would not want to create a block with an unspendable coinbase.

I mean the call should return a boolean, or the resulting script should at least be tested for non-emptiness, and the miner should exit if that is the case.

Wouldn't it be nice if you could use generate() in a non-wallet environment? Regarding RPC test in a post-wallet-split-off world: this could make sense.

If somone uses the internal miner (which has no productive usage IMO) in a wallet-disable mode he probably uses it for testing only.

I agree with adding a warning to the log. But throwing an error would block testing.

I think the right solution for that is having a trivial not-really-a-wallet provider that explicitly allows you to set the script output to mine to. It just looks incorrect to have a provider interface for something, and a default implementation that results in the least expected result.

Agreed. Maybe it would be most efficient by adding a argument to generate() and setgenerate() RPC calls where one could provide a output script to mine to?

Adding a validation interface implementation for non-wallet-mining could be over the top.

Yes, generate can just be changed to not need the GetScriptForMining interface. And setgenerate could just be deleted IMHO and replaced with a simple proof of concept Python or C miner in the tree.

I just don't like an interface that can clearly fail, but doesn't have a clear way to indicate failure.

jonasschnelli · 2015-04-29T12:24:51Z

Updated.
Decoupled wallet (over signaling) from miner and rpcmining commands.
It still uses signaling to allow different wallet/pubscript-generation implementations, though, mining without pubScript providing listener will generate a error and stops mining.

Now it reserves and keeps a key when calling setgenerate or generating over cmd arg gen (same key for all generated blocks).

jtimon · 2015-04-30T11:17:53Z

Travis is failing for the build without wallet: https://travis-ci.org/bitcoin/bitcoin/jobs/60528797#L1557

jonasschnelli · 2015-04-30T11:52:08Z

@jtimon: Thanks for the report. Fixed.

jonasschnelli · 2015-04-30T12:23:48Z

Now the miner is completely decoupled from the wallet.
There are no more #ifdef ENABLE_WALLET checks (for mining).
The only check is during runtime if there was a listening device who could provide a CScript over the signal ScriptForMining().

If one tries to use -gen without a wallet compiled in or enabled, it then will throw an exception during init phase. Current master would just ignore the cmd arg -gen if no wallet is present.

The RPC commands setgenerate, generate, getgenerate works in wallet-disabled mode but also throw a exception error: {"code":-32601,"message":"Use the generate method instead of setgenerate on this network"}

jonasschnelli · 2015-05-19T11:30:38Z

Rebased.
Seeks testers to escape the rebase hamster wheel.