Bitcoind gives that error if it's downloading blocks or if it doesn't have any connections. Try bitcoind -rpcport=18332 getwork to see the error. So, I suppose your diagnostic is ok. |
|
|
|
You can start a bitcoind in parallel with the mainnet one with: bitcoind -testnet -rpcport=18332 Success! It was a problem with the number of dashes  Then you can do: python run_p2pool.py USER PASS --testnet --bitcoind-rpc-port=18332 If this doesn't work, pastebin the error .. because it works for me. EDIT: Perhaps you used --bitcoind-p2p-port instead of --bitcoind-p2p-port? That would explain your problem. rpc-port is ok. After handsake OK ("Testing bitcoind RPC connection to ' http://127.0.0.1:18832/' with authorization....", then this error is shown repeatedly: Error getting work from bitcoind:
Unhandled Error
Traceback (most recent call last):
Failure: twisted.web.error.Error: 500 Internal Server Error
|
|
|
|
I'm running last bitcoind executable in Linux. But when I want to stop it Try running bitcoind stop (without the dash)  |
|
|
|
atendu mian venantan elasadon dum sekvaj pluraj tagoj  Nu, "ellasi" havas kromnuancon "furzo" Mi tamen esperas ke viaj kontribuoj estos multe pli ĝuinda! |
|
|
|
I have some problems... First, is not possible to run testnet and real net at the same time. So, I must sacrifice the "real" bitcoind to test p2pool When I do it, I must say p2pool not only --testnet, but rpcport also. Once the starting occurs without problem, it can't get work from bitcoind (using bitcoind 0.3.24 for Linux). |
|
|
|
I'm running last bitcoind executable in Linux. But when I want to stop it I get error message: Bitcoin: Cannot obtain a lock on data directory /home/shevek/.bitcoin. Bitcoin is probably already running.Of course, it is running! |
|
|
|
Read through this thread, all the clues are in here. I mean, the clue(s) are even in the guide itself. Come on, man.
I've finally found a clue, but not in this thread neither in these forums. |
|
|
|
I'm gpu-mining ok with these advices in Debian testing.
But I have a problem: when I switch to other tty (CTRL-ALT-Fn), mining stops. The process still stands but miner lost connection with gpu.
In this forum I read about starting the miner even with ssh-terminal! But I don't see how... every recipe fails (i.e putting "DISPLAY :0" at the beginning).
Any clues? TIA
Read through this thread, all the clues are in here. I mean, the clue(s) are even in the guide itself. Come on, man. I've tried everything: there's no way to activate gpu's from terminals out of the current X-display. Order, gives only CPU as mining device when launched in, say, tty0. No matter if I launch a "screen" instance, or if I insist about "DISPLAY=:0" at the beginning. I suspect, a fundamental difference between Debian and Ubuntu is the key. But I have no expertize on this.  |
|
|
|
|
In the last 2 days the server funds reached a steady state over 300 BTC.
Time to increase the reward per share? I have a proposal:
* If after a solved block funds are over 250 BTC, reward increases 5% for the next block
* If after a solved block funds are below 100 BTC, reward decreases 5% for the next block
It's a way to smoothly impact the luck of the pool onto the miners.
|
|
|
|
|
I'm gpu-mining ok with these advices in Debian testing.
But I have a problem: when I switch to other tty (CTRL-ALT-Fn), mining stops. The process still stands but miner lost connection with gpu.
In this forum I read about starting the miner even with ssh-terminal! But I don't see how... every recipe fails (i.e putting "DISPLAY :0" at the beginning).
Any clues? TIA
|
|
|
|
(...)
The miner just changes the ntime header (+1 every second),
(...)
That's the point! Thanks! |
|
|
|
As far as i know, per each getwork you have to try 2^32 nonces, if you dont find any hashes that match the diff, you request new work, and the process repeats itself.
Then you don't know. You can do up to 2^32 nonces per second (with X-Roll-Ntime), which is 4 GH/s. You only need to get new work when longpoll returns it, or the pool sets a time limit on the work it gives you (2 minutes with pushpool). Luke... why do you fix the time to blown up the full nonce in ONE second? 400 MH/s miner does the work in about 10 seconds, which is not bad... isn't it? So, It seems to me, that your goal is to tune the nonce length to be submitted, accordingly to miner power, in such way that miner finish its part of the nonce in only 1 second, then ask for new one piece... perhaps too much traffic overload. Well, you are entangled in pools, so perhaps you can clarify the question. |
|
|
|
Block #19 solved... or not? It appears in the list with no date, but with 8 confirmations (at the moment). Blockexplorer says it is ok. eclipsemc.com shows frontpage as if the block was not solved... no expected reward What happens!? |
|
|
|
|
Thanks you (everybody) for your 2 cents!
|
|
|
|
Playing around generation of vanity addresses, I've discovered that private keys are stored as base58 numbers, with the character "5" at the beginning. But... why? The reason why public keys are distributed in base58, I can understand: base58 is a kind of base64 without some conflicting characters that could be confused and taken as phising target. But, private keys never should be cast out. So, base64 seems to be perfect for the goal, because it is the easiest way to "textify" binaries, the most compact and most universal. For example, the private key: 5JEiDZ747ZRjB22ie48Gq1ADUZuU2Fjw2xJE5D4LCXcK8E81zAh In base64 (excluding the starting "5"): I3fcciKvYeoG/mTtUnTbX1XAW4WGqrWz1Z2g7/IC1Mz/B4++G Any clues for this strange election? |
|
|
|
... I think I need a little break now
Sure! Thanks for your effort. But still it produces a lot of rejections...  |
|
|
|
But it does not work with long-term used wallet.dat file. Even if the server is stopped.
When wallet.dat is freshly created, there is no problem.
I've fixed this issue (removed tx reader), added max_version and got rid of pycrypto. https://github.com/joric/pywalletWOW!! Thanks! |
|
|
|
|
I success compile it and run it.
But... I have a lot of rejections: 8 rej. for 1 acc. Mining on us.eclipsemc.com. "poclbm" gives a normal rate of ~2% rejections.
|
|
|
|
Will this work on windows bitcoin client or is this just for linux. I believe the patch is just for linux isn't it for the actual client?
It doesn't matter, pywallet.py works directly with the database. You have to shut down the bitcoin client to import a key. Thanks for your app Joric. But it does not work with long-term used wallet.dat file. Even if the server is stopped. When wallet.dat is freshly created, there is no problem. |
|
|
|
|
It looks awesome!
I'll give a try quickly.
|
|
|
|
|
Show Posts
