p2pool - Decentralized, Absolutely DoS-Proof, Pool Hopping-Proof Pool [archival]

[Shevek]

Now we're ready to begin testing on the main Bitcoin network.

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... 

[1713467719]

1713467719

[1713467719]

1713467719

[1713467719]

1713467719

[forrestv]

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

That means new highest-scored hash, not that the actual numerical value of the hash is highest. I can see how that would be confusing to people who understand mining, I'll reword that

[jgarzik]

Is anyone yet posting Ghash/sec stats?

[Shevek]

Is anyone yet posting Ghash/sec stats?

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!

[forrestv]

It was up to 658 mhash/s a little while ago.

Shevek: It's calculated from the time the last 200 shares took to mine. You have to mine for about half an hour to affect it, and even then there's a bit of variance in the display.

[jgarzik]

It was up to 658 mhash/s a little while ago.

Can you (a) create a JSON endpoint that bitcoinwatch can query for the speed, and (b) poke tcatm to add it to bitcoinwatch?

Also, like other pools, updating the thread subject to include last 24 hours hash performance estimate would be nice.

[jgarzik]

Oh, and can you update the top post to include useful info and URLs, rather than just crossing out stuff?

Just delete inaccurate info.

[thirdlight]

Added 310Mhash/s, running through Flexible mining proxy - all fine.

Seeing a lot of "Got duplicate share, ignoring" - is this a problem?

What a lot of output - is there an option for less verbose?

[Shevek]

Added 310Mhash/s, running through Flexible mining proxy - all fine.

Seeing a lot of "Got duplicate share, ignoring" - is this a problem?

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...

What a lot of output - is there an option for less verbose?

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

Code:

$ screen -d -m -S p2pool python run_p2pool.py USER PASS

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

Code:

$ screen -r p2pool

and then you see the output again.

[Shevek]

Also, like other pools, updating the thread subject to include last 24 hours hash performance estimate would be nice.

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

[grue]

does this pool still charge a "fee"?

If a block is found in the first 599 shares, the extra is paid to me. On average, 36% of the subsidy of a block will go to me as a result of this. This is a trade-off between minimizing the payment to some central entity and having lower variance in payouts. If the proportion going to me were reduced by half, variance would double. I believe that this is an acceptable compromise.

[forrestv]

Can you (a) create a JSON endpoint that bitcoinwatch can query for the speed, and (b) poke tcatm to add it to bitcoinwatch?

I pushed a change to git that make all nodes provide rate (hash/s) information at http://127.0.0.1:9332/rate - a good central one is http://p2pool.forre.st:9332/rate .

What a lot of output - is there an option for less verbose?

Running Python with -O (optimization enabled) will increase the speed of the p2pool daemon by a lot and reduce the debug print spew by a lot too. Once you've got it working, add that option. (python -O run_p2pool.py USER PASS) The Windows py2exe build has optimization permanently enabled.

does this pool still charge a "fee"?

If a block is found in the first 599 shares, the extra is paid to me. On average, 36% of the subsidy of a block will go to me as a result of this. This is a trade-off between minimizing the payment to some central entity and having lower variance in payouts. If the proportion going to me were reduced by half, variance would double. I believe that this is an acceptable compromise.

That paragraph is no longer true with the new approach; there is still a 0.5% fee, but that is countered by the fact that fees from transactions are spread among miners.

[forrestv]

Traceback (most recent call last):
Failure: twisted.internet.defer.TimeoutError: Getting http://127.0.0.1:8332/ too
k longer than 5 seconds.

Your bitcoin client is either not running or does not have server mode enabled. To enable server mode, put server=1 in bitcoin.conf (see https://en.bitcoin.it/wiki/Data_directory).

You also could be running it on an alternate RPC port? (-rpcport=XXX) In that case, run p2pool with --bitcoind-rpcport XXX.

[BurningToad]

I am trying this out, curious to see it work!

[DiabloD3]

Traceback (most recent call last):
Failure: twisted.internet.defer.TimeoutError: Getting http://127.0.0.1:8332/ too
k longer than 5 seconds.

Myself, um, dude.

No pony sigs. kthx.

[forrestv]

i did run it like server, it requires bitcoind ?

It only requires bitcoin to be run with the server mode enabled.

Critical update!

palsecam was the first to run the node for two hours straight, exposing a bug where the timestamp from bitcoin used to judge shares wasn't being updated. This bug will affect anybody running a node for longer than two hours, causing all future shares to not be validated, essentially splitting you off from the main network.

Bug symptom: (repeated many times)

Code:

ValueError('share from too far in the future!')

Pull from git or get the updated ZIP from the first post.

Sorry!

[Shevek]

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.

[forrestv]

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.

All information is stored in the sharechain, which is held in memory by all nodes. That chain is examined by the software to display the 'Contribution: 23.92% >368 mhash/s' information. This bit of the p2pool software can be audited, as verifying that that number is correct proves that you're getting fair payouts.

There previously was a way to store shares in a sqlite database, but that was removed in the transition to the new model of a continuous sharechain. I can reintroduce this if desired, but examining it would yield essentially only the same results as able to be seen in 'listtransactions' from bitcoin - the list of payouts that you received.

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?

Yes, it is in production and will distribute payouts immediately in any solved block.

Where node reward goes? To the default address of the actual "wallet.dat" pointed by bitcoind? Or to the IP of the node?

If you provide an address on the command line with the --address option, payouts will go there.  Otherwise, if you have IP transactions enabled, it gets a new pubkey from bitcoind, and if that fails, it gets an address in the 'p2pool' account using 'getaccountaddress p2pool'.

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

I'm working on this on the wiki - http://wiki.bitcoin-otc.com/wiki/P2Pool.

[Shevek]

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.

All information is stored in the sharechain, which is held in memory by all nodes. That chain is examined by the software to display the 'Contribution: 23.92% >368 mhash/s' information. This bit of the p2pool software can be audited, as verifying that that number is correct proves that you're getting fair payouts.

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:

Code:

Pool rate: 1031 mhash/s 12652 shares Contribution: 31 (0 mhash/s) Aprox. rew.: 0,12214342

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

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

I'm working on this on the wiki - http://wiki.bitcoin-otc.com/wiki/P2Pool.

Nice... thank you!

BTW, I propose more JSON options, for example

Code:

http://127.0.0.1:9332/difficulty # see the difficulty that at actual HR keeps the rate 1 share each 5 seconds
http://127.0.0.1:9332/connected # see the actual number of nodes connected by this one
...

[Meni Rosenfeld]

I'm working on this on the wiki - http://wiki.bitcoin-otc.com/wiki/P2Pool.

Why is it on the bitcoin-otc wiki instead of the Bitcoin wiki?