bitcoind should always relay blocks from rpc call, even it is orphan. #3658

1. 
   wangchun commented at 10:28 am on February 12, 2014: none

   I lost a block due to this. I have a python scripts listen on major mining pools’ stratum connection, this morning the script heard ghash.io found a new block from their stratum mining.notify, and from the stratum connection the script immediately decoded the height, previousblockhash and bits that needed for mining the next block and send out notification to its own miners. Only after a couple of seconds, someone submitted the next block. However, local bitcoind had not receive that previous block from ghash.io. The submitblock request was then quietly ignored by local bitcoind. And even after a few seconds it got the previous block, the broadcast of the later block never happened. I lost $20k due to this.
2. laanwj added the label Improvement on Feb 17, 2014
3. 
   fcicq commented at 6:26 pm on February 17, 2014: contributor

   Sorry to hear that, but you should have retried submit the block in your mining pool program, and used more bitcoind(s) for redundancy.
4. 
   gmaxwell commented at 7:10 pm on February 17, 2014: contributor

   @wangchun GHash.io has relay problems and is frequently orphaned. If you are mining on top of blocks without validating them you are effectively attacking the network.

   I am glad you were orphaned.

5. 
   wizkid057 commented at 8:38 pm on February 17, 2014: none

   As a pool operator, I find this to be an annoying abuse of the service provided by the pool. The pool is not there to help you mine your own blocks without actually using your own bitcoind. The pool is there for pooled mining, and you’re effectively just leeching pool resources without helping the pool or its miners at all.

   Do it like the rest of us and either mine on a pool or solo mine to a bitcoind. But don’t blindly build blocks.

   I am also glad you were orphaned.

6. 
   laanwj commented at 7:40 am on February 18, 2014: member

   The consensus is clear here, closing as “works as intended”.
7. laanwj closed this on Feb 18, 2014

   ---

8. 
   jsarenik commented at 3:16 pm on September 9, 2020: none

   Dear gentlemen, excuse me for commenting on this closed issue. Nevertheless I would like to ask you to consider following question:

   My understanding is that if a miner uses a particular coinbase address then already this address is offsetting the computation to a whole different set of results… Can someone, mathematically speaking, gain anything from watching what others compute given that every pool or solo-miner is computing in their own interest, their own corner of computation universe?

   Thank you.

   PS: Just stumbled upon this issue while looking for something else. Reminds me of LBC.

9. MarcoFalke removed the label Refactoring on Sep 9, 2020
10. MarcoFalke added the label Mining on Sep 9, 2020
11. MarcoFalke added the label Questions and Help on Sep 9, 2020
12. 
    MarcoFalke commented at 3:28 pm on September 9, 2020: member

    Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. Keep in mind that general bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange or the #bitcoin IRC channel on freenode.
13. MarcoFalke locked this on Sep 9, 2020

Contributors
wangchun fcicq gmaxwell wizkid057 laanwj jsarenik MarcoFalke

Labels
Mining Questions and Help