I've had a bit of an issue the last couple of days and I'm hoping to nip it in the bud...

On Wednesday, I switched to p2pool on a local node and switched it into my #1 position. Hashing seemed to be going OK but on Thursday in the day, I noticed my miner was no longer reachable (no ping, my router showed that port as not connected). Checking the p2pool graph showed that the miner had stopped hashing at 6am. I had someone at home restart it and hashing continued. However, p2pool was adversely affecting my internet connection so I shut it down, allowing the miner to fall back to antpool. I checked it was hashing on the pool and thought no more of it.

This morning, I was woken by a beeping sound at 6am. Could this be a recurring problem? Has anyone heard of this before? It just seems odd that the times are the same.

A few more relevant details:

• Other than this, the miner has been hashing for over a week with no issues.
• p2pool was not running this morning so it should have just been failing to connect and falling back to antpool
• Miner did not seem especially hot this morning
• • I moved the miner yesterday evening to a different room so it should not be location dependent. The new area should actually be cooler (currently running at 52 and 45).
  • Not sure of the firmware version but kernel is 3.8.13 and cgminer is 4.8.0, Hardware is 3.4.3.0
  
  So just a coincidence or something else?

OK, looks like I need to do some bandwidth limiting to keep the family happy (p2pool is very bursty and saturates my bandwidth). I've modified the tc.sh script to add in port 9333 (as a separate class). What are minimum settings to still be a happy and contributing member to p2pool?


Edit: Even with severely restricted bandwidth settings, to the degree that I could hardly tell the difference on my router's bandwidth viewer, it was still affecting my daughter's ping quite badly. And I'm sure I had things set low enough to where I was probably damaging my participation in the pool.

I would use the router's QOS but I've had issue with that in the past with that killing my payouts with quite generous settings. It also knobbles my work videophone (again with generous settings) so I'm not sure what that's about.

I'll do some experimenting over the weekend.

If one attempts to make calls to the bitcoin API while it is still syncing, often (sometimes not), I will get a 500 error timeout. This will happen with commands such as getblockcount. Other times, I might get an error 28 (which I can deal with easily enough). getblocktemplate seems to always return (even with an error).

So my question is, what is the best way to avoid the 500 errors. Do I just need a longer timeout or is bitcoind pretty much "too busy" for the duration? Is there a strategy to use such as calling getblocktemplate first and if that doesn't return an error, I can proceed?

That's really not how random events happen. If you flip a dime 29 times and it comes up heads, the next time is still 50/50, the same as if you switch to a nickel.


Unrelated but I am switching to p2pool anyway. It's not about the payout but about the principle for me. I was disappointed that the Antpool p2pool wasn't working, especially after they trumpet about their contributions on the website but I'm happy running my own anyway (nothing like freshly minted coins).

This may not be the right place for this but I had this site open...

http://p2pool.info/

And received several cha-ching sounds. I have no problem with that but it took me a while to track down as we haven't actually found a block in quitea while. It also doesn't seem to correlate with anyone else finding a block either (but I'm checking blockchain.info so who knows )

Also, the "recent block" list is about 4 months old.

(Just did it again)

Reindexing was taking forever. It's now about 12 hours later and I was still only caught up to Feb.

I guess the lesson is to backup your blocks and chainstate directories (which fortunately, I did or rather had a copy for a different instance of bitcoind). That represents work which is hard and slow to recover.

Just had this happen to me. Latest version of bitcoin on Linux. Halted the bitcoind with "bitcoin-cli stop" so it should have been clean. Currently trying the reindex.


Grrr. It started downloading the blockchain all over again :/
(Edit: It wasn't downloading the blockchain, just regenerating the rev*.dat files)


If it makes any difference, the blocks and chainstate directories are symlinked from elsewhere. Is there something in that that could be causing it? I mention it because the person is having trouble with the SD card. Could we get more info on what triggers this error?

Never mind. Disk space issue...

I hate when people post problems so I always like to come back when I figure things out.

Just for information, I can confirm that copying the complete blocks directory and the chainstate, the blockchain was not redownloaded and only the blocks between last shutdown to the latest were downloaded.

People who do not understand something should not invest in it. But they should also STFU.

Don't trouble yourself citizen, your overlords have people who take care of that kind of thing.

Well, I'll admit that security is not too likely to be an issue. It was more illustrative of the point about tying to old software. Or really, any particular piece of software at all. Internal data structures as documents were not OK when Word was doing it with the doc format. We should aim to do better than that.

Actually, it shouldn't make any difference unless there is some delay before you start getting paid.

Good to know.


True. But the major reason put forward for sticking with 4.8 is portable wallets which they really are not, any more than HTML best viewed with IE3.0 is.

I can understand the objection to 6.x based on the licensing (I am not that well versed on the changes but I did notice a few complaints while searching). I just think being wedded to an old version of software is not ideal and I suggest that a move away from it be started. The dumpwallet and importwallet may well (haven't looked into it yet) provide what should, going forward, be considered a portable wallet and wallet.dat should become to be regarded as an internal instance of a wallet only.

Is it not used also for indexing the blockchain and other things? I also see a peers.dat and fee_estimates.dat (granted that the latter is probably fairly recent)

I think it would be better to get away from requiring BDB4.8. The dumpwallet/importwallet appear to be the correct way forward. The database used should not be important (beyond minimum requirements).

I'd also note that in attempting to find information to feed into this argument, I went digging for information about 4.8 and end of life/support information and was unable to find anything much. Given that we're two versions on now (6.something), is it reasonable to be expecting much in the way of attention to 4.8? What if there are security bugs lurking?

I think it would be healthy do decouple core from any particular database in any case but surely this tying to a particular version is "not good".

It's my computer and I don't want to install outdated software without good reason.

"Best viewed with Internet Explorer 3.0"

Since then, I have opened a new id for the trading. I have accepted no trades (people don't seem to understand what "cash & local" means) but my rating is down to two stars (which seems to be something of a default).

At this stage, this signal-to-noise is so bad I think that any potential reward doesn't justify the risk so I'll probably turn it off.

For now, I'm compiling it ignoring the incompatibility but since this is a solution I'm hoping to sell to others (maybe) I probably have to get the 4.8 working.

Having thought about it more, I've come to the conclusion that bitcoind should use whatever database internally when running (which is to say it shouldn't be locked into BDB 4. but that the "wallet" should be a file exported from the client, probably in the same format at the JSON exported by Pywallet.

They were creating new addresses per donor.

Finally came through 11pm central time. That's noon Beijing time. I don't demand absolute reliability but you should attempt to live up to your published schedule.