I'm trying to force it to lower the share difficulty..  It's giving my BFL little single a diff of ~430 which is way too high.

BTW, currently the P2pool server lives in the USA, I will be setting up an EU p2pool for the EU pool servers as well.

Nope, anyone can still connect to 3332 anytime, it is proxied to P2Pool.

One caveat is that the p2pool currently does not check worker names.  It will happily accept hash from whomever.  So please make sure your workers are set up properly so you get paid.

p2pool is up and running and we've found our first 2 p2pool shares!  (not surprising since we should find one about every 30 minutes)

2013-11-05 23:32:47.617383  Shares: 2 (0 orphan, 0 dead) Stale rate: ~0.0% (0-66%) Efficiency: ~117.5% (40-118%) Current payout: 0.0165 BTC

We have plenty of hash for NVC and FTC, but I will consider it. 

Did you, and/or your destination update your client(s)?  There was a DGC hard fork yesterday.

We have (very basic) DB connectivity from p2pool!

mysql> select username,sum(difficulty) from shares group by username;
+----------------+-----------------+
| username       | sum(difficulty) |
+----------------+-----------------+
| flound1129.bfl |            1811 |
+----------------+-----------------+
1 row in set (0.00 sec)

Following flounder's 'no major changes before sleeping' rule, p2pool on BTC will be enabled tomorrow.  Tonight is the last night to claim the block bounty!

If this works out well, I may enable it for LTC as well.

I'll pay all the shares in the db over and over again until we reach X BTC worth of payouts.  (I'll have to figure out what X should be at some point, but it'd obviously have to be at least 25.)


Several reasons.

1. P2pool payouts show up as generate transactions in our wallet.  That means almost no modification to our current payout setup. The payouts show up exactly as if they were mined blocks.  If we go with another pool I have to add logic to find out the block # from the remote pool, then figure out how much our payout was from that particular block, etc.
2. It's decentralized, as opposed to a single pool which can be dos'd, hacked, etc.
3. Because we run our own node(s), the latency and up to 3% additional stales we'd be subject to by running stratum-proxy to another pool are not an issue.
4. Extremely easy to set up merged mining.

There are a few other reasons, but those are the main ones.

Actually if anyone here knows Ruby and wants Hero Member status, I have a small amount of work you could do.

I'll also give you the bounty I was planning to give out for the first BTC block if we can get ourselves hooked up to p2pool before we find one.

I'm fairly close to having the BTC port connected to p2pool.  All I need to do is learn Ruby real quick

Subtracting the tx fee of 0.01 makes the withdrawal 0.00702970, which is below the minimum input of 0.01 for NVC (network rules, not mine).  But yeah, I should add some logic around that.

I can cancel it, or you can leave it as requested until you generate 0.003 more NVC at which time it should be processed.

I'll just leave this here.

Something weird going on with the estimates script..  I'm looking into this.

We haven't lost any shares.

"Turned into"?  Are you new?

There are coins in the wallet, so either it's below the tx fee, or it can't create the transaction for some reason.  How many NVC are you trying to withdraw?

I'll point to a big pool that supports GBT, that's the point.  Doesn't really matter which one.

If someone can modify stratum-mining to use another pool as a getblocktemplate source, I'll point us at Eligius or Bitminter.  I looked into it but I just don't have the programming skills.

A few days ago I announced a promotion but forgot to post it in this thread.  The finder of our first BTC block will receive the pool fees (0.3125 BTC) plus the transaction fees in the block, up to a total of 1 BTC.

Bitcoin auto payout threshold set to 0.01.

BTC minimum auto threshold set to 0.01 coins.  BTC withdrawals under 0.01 will be subject to a fee of 0.001 BTC.