I've search for this problem a bit, but I had bad luck  despite of this, I'm sure it stands somewhere. So, sorry if I repeat the topic.

Yesterday I accidentally wipe off the file 'wallet.dat'. No problem: I took my backup and restored it. My backup was a bit old, so when I restarted bitcoin, the addresses stay but the balance, with all operations made after backup, blew up. The reason is, because bitcoin uses the same file, 'wallet.dat' to keep private keys, public keys and transactions.

The only solution I've found for restoring the balance was restart bitcoin in a new folder (conserving 'wallet.dat' and 'bitcoin.conf') and wait several hours for the block-data rebuild up.

So the question is: is there any more clever way to restore the balance!? The information about transactions is in the block chain, available to the program; I think the client program should have an option "rescan the blockchain" or similar for such occasions. And, even better, keep the transaction file away from priv. keys!

I agree: p2pool eats too much memory:


So 17,6% of mem is a bit too much.

I think it's a problem of the design. As forrestv said, the whole sharechain is kept in memory, instead of a file or a db.

Perhaps it's time to reconsider this policy and think about files. Moreover, with files in mind, it is possible reconsider also the limit of 24,000 shares of payout, too low for home miners of ~100 MH/s power.

Sorry for the trivial advice but... did you set server=1 in your bitcoin.conf?

Sometimes I've got strange errors when I launched p2pool quick after bitcoind. If this is your case, simply wait a couple of minutes.

poclbm had a bug past night dealing with new difficulty. Try again with fresh poclbm and fresh p2pool. BTW, forrestv said that launching the program with python -O saves a lot of output.

Yes, but this information is very poor... not much digits. I've contributed with aprox. 50 shares and now there are ~12,600 shares on the pool. So, 50/12,600 ~ 0.3%. But I see 0,00%... may be a round error? may be not all my shares where accepted, even if the miner tells Ok?

This is a bit confusing. Perhaps other way to implement this could be:


So, I can see quickly if a share is counted up or silently rejected.


Nice... thank you!

BTW, I propose more JSON options, for example

Ok, I'm running a node and have some few questions.

• Where the node stores the information it harvest? The list of accepted shares and node-IPs, for example.
• Particularly... where it stores the information about *own* accepted shares? This is crucial to audit future rewards.
• Is the pool actually in production? So... it is ready to reward for eventual solved block? Or is it only testing whether the pool-net can hand the traffic?
• Where node reward goes? To the default address of the actual "wallet.dat" pointed by bitcoind? Or to the IP of the node?

So, perhaps it's time to collect and write down a more detailed documentation.

I think forrest don't consider it "in production" yet.

I guess not. When a share is found the information echoes through the net. Once your node receive the first notice, the following are rejected as duplicated.

I suppose...


In *nix flavors you can launch the node this way:


and the output is silent. If you want to peek type:


and then you see the output again.

HR was slowly increasing from ~300 MH/s up to a bit more than 400 MH/s in this moment, as reported by p2pool output.

I don't know how this is calculated. I've just plugged ~60 MH/s into the system and HR didn't change.... even when shares started being accepted.

BTW remote mining works! I have bitcoind and p2pool in one machine and the miner in other... all works fine!

Running now the daemon, but not the miner which is located in other computer. BTW, so I'll test remote connection to the pool-net.

I don't understand the messages about "new highest hash". It is supposed that the lower the hash the better... 

Mi same ĉagreniĝas.... brr.....

Olvídate de "deepbit"; minando ahí sólo contribuyes a aumentar la centralidad de la red cuando se supone que ésta tiene que ser p2p. Además, se queda con un 3% y sólo devuelve un mínimo de 0,01 (el resto, hasta 8 decimales, queda "durmiendo" en tu cuenta hasta que vuelvas a minar).

Hasta que la solución de minado p2p esté en marcha, te recomiendo cualquier otro "pool". Particularmente, "eligius" es muy fácil de usar porque no necesitas ni siquiera inscribirte.

I'll test it as soon as possible, to see if stales are really drop down.


I think the right way to implement failover and multiserver is the one adopted by poclbm and hashkill: several servers are placed in compact format user:pass@server:port (or user:pass:server:port) without flags; the first one is meant to be the favourite and the program will test it from time to time after its shutdown.

Moreover, hashkill allows input a text file with one server per line.

P.S. Edited for cosmetic changes

About 5 second rate...

If a block is solved in an average of 10 minutes, at the rate of 5 second per share, it yields 120 shares per block. Counting 3*n -> 360 shares to be rewarded on average.

Too low for those who are pooling to avoid uncertainty 

Nope!

Real long term solution DDoS reluctant and p2p-friendly:

http://forum.bitcoin.org/index.php?topic=18313.0

I didn't really plunged onto it.

I only know that this recipe allowed me to open an xterm from text terminal and ./poclbm.py reported correctly the GPU in the same text terminal.

So, I must further investigate...

It was a problem of permissions with X server. It seems, that Ubuntu default policy is opener than Debian's. I was not possible for me to stablish a connection to X server out of the main screen.

In the linked method, what is really interesting to me is:

For miners with really low hashrate (compared to the global pool one), yes. Let's say, CPU-miners.

On the other side, this fixes also the minimum worth money to pay. For N=100,000 it is 50,000 satoshi. Perhaps 10,000 is a fairer limit (N=500,000).

Only a proposal...

Somewhere has been discussed the possibility of having a long-fixed (say, 100,000 items) list of valid shares to divide reward with. At the beginning all shares are accepted. But when the list reaches its limits, new share is accepted only if its value is better than the worst one in the list, and this last is pissed off. Actually, this means fixing acceptance target (and so, assorted difficulty) to the worst share in the list.

If some hopper leaves the pool after scoring, say, 10,000 shares, It will be possible that resting miners will continue generating shares with better values than many of these 10,000. When the block is solved and the hopper come back to get the reward, then she would be surprised if only 3,000 shares count toward her income...