...and they are right!

Unless that just happened today and I don't know about it.... your 700,000 BTC figure is a straight lie.  I will believe what you said if you post a link to the article (from a reputable source) mentioning the newly discovered 700,000 BTC you're referring to.  That's funny how that is NOT on mtgox's home page, I would expect such news to be there.

Where in the world did you come up with 900,000 number?  All articles say mtgox "found" a wallet with 200,000 BTC.  That's not even a quarter of what Mark Karpeles and his associates lost/stole from people that trusted (WHY???) them. And he tanked bitcoin in the process.

Look at the guy, does he look trustworthy to you? If you say "yes" then good luck with all the money you still have.

Hi Luke,

Which is the latest Stable release of BFGMiner? In your post https://bitcointalk.org/index.php?topic=168174.0 you announce version 3.10.0 but below the latest stable release is listed as 3.5.7 (should I use this one as latest stable release).  Thanks!

Can cgminer be set up to mine with a network device?  (I have ASICminer Block Erupter Cubes)  I wanted to try it but I think I would need a miner that I could connect directly by USB to my computer running cgminer.  I don't see an option to specify a network port where it should listen to my miners...  Or is there a way to use it with BE Cubes?

Well, sometimes I use Chrome Remote Desktop and when I had a lot of active connections (don't remember how many) Chrome RD would hang up and it was really hard to get back in.  So I am trying not to get locked out...   And less than 20 seconds from the moment I see a new block in the blockchain is not bad at all.


I don't think I've ever noticed that, but I did see some new blocks that had timestamps earlier than the previous block.  For example:

292968   2014-03-28 21:38:43
292967   2014-03-28 21:49:41

I tried --scan-time with various values, but that doesn't seem to do anything for me, as far as getting new block information faster from my bitcoind.  The only option that did it was --expiry, and I set it to 10.  That causes BFGMiner to pick up new block information from my bitcoind in less than 10 seconds.  Since solo mining doesn't use shares, I guess it is perfectly OK to set it to 10, maybe even 5 (which was my original question )

As far as setting up a failover pool, I've tried that, and this is what I get:

  [2014-03-31 13:01:27] Block change for http://127.0.0.1:8332 detection via http://stratum.mining.eligius.st:3334 stratum
  [2014-03-31 13:01:27] Pool 0 http://127.0.0.1:8332 alive
  [2014-03-31 13:01:28] Pool 1 http://stratum.mining.eligius.st:3334 alive
  [2014-03-31 13:01:28] Pool 1 is hiding block contents from us

But then the current block in BFGMiner never gets updated.  I think this is because, as the above says, block changes are now handled by Eligius pool, but further down, it seems to be hiding block content.  So, it doesn't work at all, but I bet I must be doing something wrong....

Regarding Bitcoind, yes, adding addnode=relay.eligius.st helped a lot, thank you for the tip. It now picks up new blocks on the network in less than 20 seconds!  I also opened port 8333 on the router to run it as full node and used maxconnections=22 to try to limit traffic, although I've read somewhere that this alone won't guarantee that bitcoind won't kill my upload bandwidth.

So for now I'll stick to --expiry 10 for BFGMiner and keep getting new block info from my Bitcoind.  I may try to install my own pool software, thanks for the link.  BTW, do you know what I may be doing wrong with failover pool, since it seems to be hiding block info from me?

./bfgminer --http-port 8330 -o http://127.0.0.1:8332 -u user -p password -o http://stratum.mining.eligius.st:3334 -u user -p password --coinbase-addr 1F2qbpkfApQm2gM63YvjTauyjaHxq2oekS --coinbase-sig "Cube102"

Thanks, I will install cgminer and see if the block changes as soon as I see a new one accepted in bitcoind debug log.  Another issue is that my installation of Bitcoin-Qt (on a Mac) doesn't report a new block for about 60 to 120 seconds after I see it in blockchain.info.  I run it without port 8333 open, so it has only 8 active connections.  Do you think that if I run it as a full node, with a lot more connections, that would ensure that it gets new blocks basically as soon as they appear on the blockchain?

And, as previous commenter suggested, I will add a regular pool to the failover list, because right now I don't have any.  That's probably a good idea anyway.

Hello all,

I started mining solo few days ago and I noticed a significant lag in new network block detection by both my Bitcoin Core (v0.9.0-beta 64-bit) and further by BFGMiner (3.10.0).  When I see a new block on blockchain.info, from that point it takes about 120 seconds for it to appear in my Bitcoin-Qt's debug.log and then it takes another 120 seconds for my BFGMiner to report "New block detected on network".  That's about 4 minutes of lost time, since I am pretty sure that my ASIC miners won't start mining the new block until both my Bitcoin Core and BFGMiner know about it.

I started playing with --expiry option in BFGMiner and found out that if I make it less than the default 120 seconds, then BFGMiner will recognize there's a new block on the network faster.  For example:

./bfgminer --http-port 8330 -o http://127.0.0.1:8332 -u user -p password --coinbase-addr 1F2qbpkfApQm2gM63YvjTauyjaHxq2oekS --coinbase-sig "Cube102" --expiry 20

I would like to make the --expiry value even less, let's say 10 seconds, so I start working on a new block as soon as possible.  4 minutes is not acceptable since my miners on average lose 40% of chance to find a new block.  That's 40% of lost electricity.  Additionally I see quite a few "inputs already spent" and "already have block X" in my Bitcoind debug.log, which may be related to the fact that I'm still working on the block that has been already solved.

My question therefore is, can I safely use --expiry 10 (or maybe even 5) or will that cause BFGminer to consider some shares stale, while they are still valid. I've read somewhere that when mining solo, you don't submit any shares so that shouldn't have any negative impact, but I may be wrong.  Can I use --expiry 10 with my BFGMiner and what else can be done to make both Bitcoind and BFGMiner recognize faster the fact that there's a new block on the network while mining solo?  Thanks.

Hello all,

I started mining solo few days ago and I noticed a significant lag in new network block detection by both my Bitcoin Core (v0.9.0-beta 64-bit) and further by BFGMiner (3.10.0).  When I see a new block on blockchain.info, from that point it takes about 60 seconds for it to appear in my Bitcoin-Qt's debug.log and then it further takes about 120 seconds for my BFGMiner to report "New block detected on network".  That's about 3 minutes of lost time, since I am pretty sure that my ASIC miners won't start mining the new block until both my Bitcoin Core and BFGMiner know about it.

I started playing with --expiry option in BFGMiner and found out that if I make it less than the default 120 seconds, then BFGMiner will recognize there's a new block on the network faster.  For example:

./bfgminer --http-port 8330 -o http://127.0.0.1:8332 -u user -p password --coinbase-addr 1F2qbpkfApQm2gM63YvjTauyjaHxq2oekS --coinbase-sig "Cube102" --expiry 60

I would like to make the --expiry value even less, let's say 10 seconds, so I start working on a new block as soon as possible.  Really, 3 minutes is not acceptable since my miners on average lose 30% of chance to find a new block.  That's 30% of lost electricity.  Additionally I see quite a few "inputs already spent" and "already have block X" in my Bitcoind debug.log, which may be connected to the fact that I'm still working on the block that has been already solved.

My question therefore is, can I safely use --expiry 10 (or maybe even 5) or will that cause BFGminer to consider some shares stale, while they are still valid. I've read somewhere that while mining solo, you don't submit any shares, but I may be wrong.  Can I use --expiry 10 with my BFGMiner and what else can be done to make both Bitcoind and BFGMiner recognize faster the fact that there's a new block on the network while mining solo?  Thanks.