[mining] allow other signal listeners to provide scripts for mining #6481

1. 
   jonasschnelli commented at 5:07 pm on July 27, 2015: contributor

   This simple change would allow other wallets/signal listeners to providing a scripts for the coinbase output. Currently the main wallet will always overwrite a possible available script.

   Without this PR, RPC test for the new wallet would require to send in funds mined of ther current wallet.

2. [mining] allow other signal listeners/mining key provides to not get overwritten

   This simple change would allow other wallets to providing a scripts for the coinbase output. Currently the main wallet will always overwrite a available script.
   
   Without this PR, RPC test for the new wallet would require to send in funds mined of ther current wallet.

   0e59e3234c
3. laanwj added the label Refactoring on Jul 29, 2015
4. 
   btcdrak commented at 9:00 am on August 15, 2015: contributor

   utACK
5. 
   sipa commented at 1:28 pm on August 15, 2015: member

   Seems strange to put this reponsibility in the wallet, as it means that probably every alternative provider for scripts would also need this logic.

   I think it’s better to institute a rule that there can be at most one provider. You can probably easily implement that as a combiner for the boost signal, making it fail when more than one called handler returns true. That way it becomes the responsibility of the one who registers the providers, rather than of every provider itself.

   Not a NAK though, if this is the easiest solution, ok.

6. 
   luke-jr commented at 7:16 pm on December 28, 2015: member

   What @sipa said.
7. 
   laanwj commented at 11:45 am on April 25, 2016: member

   I think it’s better to institute a rule that there can be at most one provider

   Yes, I had a similar comment. It’s a bit strange to put the responsibility for not returning multiple scripts in the providers.

   The need for a circuitous design like this seems to indicate there is a level violation though. Maybe mining-to-wallet call should be part of the wallet API? Then there is no need to register anything at all.

8. 
   laanwj commented at 2:33 pm on April 28, 2016: member

   My proposal would be to move generate to the wallet (as it needs a wallet, implicitly, anyway), and keep generatetoaddress in the core. See #7965.
9. 
   jonasschnelli commented at 1:02 pm on July 20, 2016: contributor

   My proposal would be to move generate to the wallet (as it needs a wallet, implicitly, anyway), and keep generatetoaddress in the core. See #7965.

   Agree with @laanwj. Closing.

10. jonasschnelli closed this on Jul 20, 2016

    ---

11. MarcoFalke locked this on Sep 8, 2021

Contributors
jonasschnelli btcdrak sipa luke-jr laanwj

Labels
Refactoring