[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[TierNolan]

It seems to me that all you would be doing by increasing your difficulty would be to forfeit some potential earnings from weak shares, by throwing those shares away instead of submitting them to the sharechain, unless there's something I'm missing.

You have to decide what the target is.

For example, if you do 1 trillion hashes, you will get approx

25 difficulty 10 shares

250 difficulty 1 shares (includes the 25 difficulty 10 shares)

You have to decide in advance what your target is.  You can set it to anything you want, as long as it is higher than the minimum required.

If you set it to 10, then only the 25 difficulty 10 shares count, so you get 25 shares worth 10 each.

If you set it to 1, then the 250 difficulty 1 shares all count, so you get 250 shares worth 1 each.  The 25 difficulty 10 shares also count, but since you set them to difficulty 1, you can't claim a reward of 10.

In other words, the "value" of a share is not fixed.  It's based on the target difficulty for that share relative to the target difficulties of all the other shares that make up that block.  In other words, if you opt-in to a difficulty that is 2x as high, you get paid 2x as much for that share. 

Right, and you have to pick the target before you run the hash, so you can't change it afterwards.

[Krellan]

You have to decide what the target is.

For example, if you do 1 trillion hashes, you will get approx

25 difficulty 10 shares

250 difficulty 1 shares (includes the 25 difficulty 10 shares)

Interesting.  I thought p2pool already paid out on a prorated basis, based on how difficult your share was, regardless of what the target was?  If you just barely limp in over the minimum required difficulty, you get paid a small amount, but if you find a massively high difficulty share (such as a share that's good enough to become a real Bitcoin block) you get paid that much more.  You don't get paid the same amount per share, I have noticed.

Didn't know it took into account the ability to optionally choose a higher minimum required difficulty, and increased the payout ratio proportionally, to compensate you for your loss from all the little low shares that you've now chosen to throw away instead of submit.  What's the ratio that it uses?

Let's say I submit 6 shares, at these difficulties: 1, 1, 1, 1000, 1000, 1000.

That will pay me about 3003 difficulties worth of work.  Now, let's say I change my minimum difficulty to 500.  Instead of submitting 6 shares, I submit only 3 shares, at these difficulties: 1000, 1000, 1000.  This only pays me about 3000 difficulties worth of work, not 3003.  So I have lost a little income here.  In case there's something I'm missing.

Anybody have the exact formula?

Josh

[forrestv]

You have to decide what the target is.

For example, if you do 1 trillion hashes, you will get approx

25 difficulty 10 shares

250 difficulty 1 shares (includes the 25 difficulty 10 shares)

Interesting.  I thought p2pool already paid out on a prorated basis, based on how difficult your share was, regardless of what the target was?  If you just barely limp in over the minimum required difficulty, you get paid a small amount, but if you find a massively high difficulty share (such as a share that's good enough to become a real Bitcoin block) you get paid that much more.  You don't get paid the same amount per share, I have noticed.

Didn't know it took into account the ability to optionally choose a higher minimum required difficulty, and increased the payout ratio proportionally, to compensate you for your loss from all the little low shares that you've now chosen to throw away instead of submit.  What's the ratio that it uses?

Let's say I submit 6 shares, at these difficulties: 1, 1, 1, 1000, 1000, 1000.

That will pay me about 3003 difficulties worth of work.  Now, let's say I change my minimum difficulty to 500.  Instead of submitting 6 shares, I submit only 3 shares, at these difficulties: 1000, 1000, 1000.  This only pays me about 3000 difficulties worth of work, not 3003.  So I have lost a little income here.  In case there's something I'm missing.

Anybody have the exact formula?

Josh

How "difficult" a share is depends only on its target. Any share mined around the same time will yield the same contribution to your payout. I say "around the same time", because the minimum difficulty changes to keep it at one share every thirty seconds, and that will affect a share's reward.

[TierNolan]

Interesting.  I thought p2pool already paid out on a prorated basis, based on how difficult your share was, regardless of what the target was? 

No you set the difficulty in advance.  If you aim for a difficulty 1 share, but get a hash that is good enough for a difficulty 10 share, it still only counts as a difficulty 1 share.

When you get a share, it gets added to the share chain and when the next block is hit, you will get a share of that block's payout.

Let's say I submit 6 shares, at these difficulties: 1, 1, 1, 1000, 1000, 1000.

That will pay me about 3003 difficulties worth of work.  Now, let's say I change my minimum difficulty to 500.  Instead of submitting 6 shares, I submit only 3 shares, at these difficulties: 1000, 1000, 1000.  This only pays me about 3000 difficulties worth of work, not 3003.  So I have lost a little income here.  In case there's something I'm missing.

If you set the difficulty target at 1, you will get around 1 share for every 4 billion hashes and each one will be worth 1 share.  However, some will have a hash that is low enough to be a valid difficulty 10 share. 

If you set the difficulty target to 10, you get 1 share for every 40 billion hashes, but each one of those shares would count for 10.

What happens with hashing is that you (in effect) pick a random number between 0 and a huge number (2 to the power of 256).  You need to get an result lower than the target.  A difficulty 10 share has a target that is 10 times lower than a difficulty 1 share.  This means you are 10 times less likely to hit it.

[kano]

Statistics fail + p2pool understanding fail

p2pool understanding fail
If you submit a share - it counts for nothing at all unless it is above p2pool difficulty - currently 25500 as I type this

p2pool allows you to submit lower difficulty shares to make it's stats work to show how it thinks you are hashing

That is what the +x difficulty is all about to set it above the old default 1 difficulty

So if you submit a share below around 25000 diff, but >= x, you will never get anything for it except a counter saying you found it.

Statistics fail
The simplest explanation is to see the fail

If I submit shares at 10 difficulty, I will find on average 1/10 of the shares as if I was submitting shares at 1 difficulty.

Thus each share >= 10 difficulty is worth 10x as much as a 1 difficulty share.

The share difficulty itself is irrelevant except for that fact that is it >= 10 (... unless you mine ozcoin PoT ...)

[twmz]

p2pool allows you to submit lower difficulty shares to make it's stats work to show how it thinks you are hashing

That is what the +x difficulty is all about to set it above the old default 1 difficulty

Yes, but in the context of this discussion I think we're talking about the '/x' difficulty username option (vs '+x') which actually does allow you to change the target for the real p2pool shares and not just the pseudo shares (as long as you choose something higher than what p2pool network requires by default).

[Krellan]

No you set the difficulty in advance.  If you aim for a difficulty 1 share, but get a hash that is good enough for a difficulty 10 share, it still only counts as a difficulty 1 share.

When you get a share, it gets added to the share chain and when the next block is hit, you will get a share of that block's payout.

OK, that makes sense.  I thought that p2pool paid out each successful share based on the difficulty of that share itself (how close to zero the hash was), not based on the target difficulty.  Interesting how there's still so much variance in the payout table, then: each payout is slightly different, they don't quantize themselves into recognizable patterns.

Since there's only 8640 shares, I would think that it would be easy to see groupings in the payout table, but instead, each number is slightly different.  Does the target difficulty continuously update itself and change a little each time?  Maybe that is why.

[zvs]

No you set the difficulty in advance.  If you aim for a difficulty 1 share, but get a hash that is good enough for a difficulty 10 share, it still only counts as a difficulty 1 share.

When you get a share, it gets added to the share chain and when the next block is hit, you will get a share of that block's payout.

OK, that makes sense.  I thought that p2pool paid out each successful share based on the difficulty of that share itself (how close to zero the hash was), not based on the target difficulty.  Interesting how there's still so much variance in the payout table, then: each payout is slightly different, they don't quantize themselves into recognizable patterns.

Since there's only 8640 shares, I would think that it would be easy to see groupings in the payout table, but instead, each number is slightly different.  Does the target difficulty continuously update itself and change a little each time?  Maybe that is why.

yes, the difficulty target adjusts based on that particular pools hashrate

not sure when the source starts calling for the actual share difficulty to go up, but the pseudo shares used to measure your hash rate start to increase in difficulty somewhere around 5-10ghash?

Blah/50000+5

would make difficulty 5 share targets for showing hash rate on graph,  and 50000 difficulty target for you to get a portion of the block (assuming your hash rate wasnt high enough to push it above those #'s already)

long polling still opens just as many connections, it may reduce bandwidth usage for stratum, but stratum has never worked properly for me on p2pool.    oh, the new non-punish policy is great,  it would be slow nodes fault if something got orphaned anyway

http://www.nogleg.com:9332/static/share.html#000000000000ce061ad134ff10377613d98ae66dc1fc065311c8e039600a63c9

correct share, orphaned:  http://www.nogleg.com:9332/static/share.html#000000000000386801f1d4782ab9931c9a4c63c6eec24c6c4eaa2ba903e03b48

incorrect share, not orphaned:  http://www.nogleg.com:9332/static/share.html#00000000000166aebdbc7be75dfec1657a15706e21e2ad89bbb13cfa7b0ec5e2

but note in came over a minute earlier.   so this reduces your risk of punishing yourself

[daemondazz]

I'm pleased to announce that I've released my modified low-rate friendly P2Pool bitcoin node at cryptominer.org:9332 for general usage:

Announcement: https://bitcointalk.org/index.php?topic=280780.0
Website: http://cryptominer.org/bitcoin/

This node should allow miners with a low hash rate (eg < 1Gh/s) to receive a consistent reward for their hash rate instead of the high-variance of having an expected-time-to-share of tens of hours or days.

[FuzzyBear]

Loving the blocks found over the last 2 days on p2pool been epic!!

Also I have a 0% p2pool btc fee pool almost ready with merge mining coins Namecoin, Ixcoin, devcoin and a few others hopefully coming soon...

http://fuzzypool.mine.bz/

should be ready for beta testers real soon, but have a look and please PM me any questions / opinions / thoughts or suggestions

Many thanks

FuzzyBear

[SebastianJu]

I have some questions regarding p2pool. Sorry if already asked and i didnt find the answer.

I read the previously found shares from other miners are included in the block as transactions so that every miner gets his reward for the real found bitcoins block. But is the reward of a newly found block already splitable? And is it fair enough to let a miner mine blocks that include previous shares from others? I mean the work the others did before the actual miner found the real bitcoin block is lost then right? The block reward cant be sent to some zentralised server first that then determines how many btc every miner gets right?

I often read about problems with the time in p2pool because of the setup of p2pool. Is this a serious factor? I mean compared to mining at normal pools or solomining since all p2pool miners would have the same chance.

When mining bitcoins one has to run a bitcoin server. But what about merged mining? Thats possible with p2pool too like i read. So does one have to run a wallet server of each coin one is merge mining? That would lead to p2pool only able to run on linux when merge mining since many merge mine able coins only have linux wallets. Right?

[gyverlb]

I have some questions regarding p2pool. Sorry if already asked and i didnt find the answer.

I read the previously found shares from other miners are included in the block as transactions

To clarify (hopefully), for each destination address where at least one share is in the sharechain there's a transaction in the coinbase provided to miners by all p2pool nodes. If an address got 100 valid shares, there's only one transaction in the coinbase.

so that every miner gets his reward for the real found bitcoins block. But is the reward of a newly found block already splitable?

The reward is automatically splited as valid shares on p2pool are the results of work on a coinbase that split the block proportionally to each address effort (as detected by the number of shares computed by each address).
A p2pool block is simply a share hitting the Bitcoin network difficulty, so it has the same properties: it automatically splits the reward.

And is it fair enough to let a miner mine blocks that include previous shares from others? [...]

Yes, that's PPLNS, look it up (several pools use it, not only p2pool).

I often read about problems with the time in p2pool because of the setup of p2pool. Is this a serious factor? I mean compared to mining at normal pools or solomining since all p2pool miners would have the same chance.

I don't understand.

When mining bitcoins one has to run a bitcoin server. But what about merged mining? Thats possible with p2pool too like i read. So does one have to run a wallet server of each coin one is merge mining? That would lead to p2pool only able to run on linux when merge mining since many merge mine able coins only have linux wallets. Right?

Indeed you'll need a node for each coin you want to merge mine. It doesn't need to be a local one though, so you may run p2pool on a Windows server and access nodes running on Linux.
I don't see the point of using Windows myself (especially when revenue depends on it) so I wouldn't be of any help here sorry.

[twmz]

And is it fair enough to let a miner mine blocks that include previous shares from others? I mean the work the others did before the actual miner found the real bitcoin block is lost then right?

Yes, but that is the entire point of pooled mining.  Miners agree to split the reward for a block with those that were helping to find blocks at the same time even though those other miners failed to find anything.

The block reward cant be sent to some zentralised server first that then determines how many btc every miner gets right?

That is how a normal pool works, and is entirely viable, but it's also contrary to the entire point of p2pool which is to avoid having any centralized server that everyone depends on and has to trust.

[nibor]

Running Bitforce-SC 60Ghash for last few days and working perfectly.
Have 73 shares (4 Orphan, 4 dead) 104.6% (93-111%) efficiency. And I have had some issues with my ADSL line so a few could be due to that.


Below is all taken from https://bitcointalk.org/index.php?topic=153232.0
Post is just to say it is good advice.

Setup is:
p2pool and bitcoin client running on Win7-64bit i7 quad core with their data files on ssd disk. This is connected to internet via ADSL 7mbit down 1mbit upload (12ms ping time to www.google.com). Enabled QoS on 2 ports (no idea if this helped!).

Running p2pool (13.4) with these switches:
--max-conns 16 --outgoing-conns 8
Have 8 outgoing and 1 incoming - never seen above 4.

Running bitcoin (0.8.3) with:
blockmaxsize=1000000
mintxfee=0.0001
minrelaytxfee=0.0001
maxconnections=15
This gives me a 0.2 second getblocktemplate latency. I did have mintxfee=0.00001 but then latency was 1-2s! Again no idea if this caused issues just did not feel good. I have 10-15 connections.


Miner is a VERY old laptop (8 years?) with WinXP and cgminer (3.3). Is connected to other machine with a pair of homeplugs (due to miner being so loud it is banned from house and in garden room!). Ping latency is 4ms is stable but very low bandwidth due to distance/mcb's.
Run miner with /+100 at end of user name so only report 100 diff shares. This is to reduce load on laptop and bandwidth used. Again do not know if this is helping.


Will experiment with different settings over next few weeks.

On another note - the web front end say "Expected after mining for 24 hours:".
But this is wrong - it should say at the moment "... after 35.4 hours" as the expected block time is 11.8 hours. Does everyone agree with me on this? Just that it is confusing for new users.
Also would be good if there was an "expected income per 24 hours" that just did the multiplication of this by the number of blocks expected each day (2.0339 at the moment). If all agree I am correct might submit a patch if I find the time!

[nibor]

This transaction:
https://blockchain.info/tx/6dad36cbfca544df4b2608dd38df0e9a91061075c780cf10acdc74e6d7f00504

added 0.3seconds to  GetBlockTemplate latency. It is 87k in size with 588 inputs and fee of 0.0093.

This is included if you have mintxfee=0.0001 as fee is over 0.0001*87=0.0087.

However we are never going to earn a lot of fees if we include TX's like this as each block could only hold 11 of them for total fees of 0.1BTC! And have latency of 3.3 seconds.


Does anyone know where in the code this is? Seems odd that it takes so long. It does not have to check sigs or anything like that.

[gyverlb]

This transaction:
https://blockchain.info/tx/6dad36cbfca544df4b2608dd38df0e9a91061075c780cf10acdc74e6d7f00504

added 0.3seconds to  GetBlockTemplate latency. It is 87k in size with 588 inputs and fee of 0.0093.

This is included if you have mintxfee=0.0001 as fee is over 0.0001*87=0.0087.

This is a bit more complicated, in short in most cases this is only included if the coinbase isn't already full with more profitable transactions.

However we are never going to earn a lot of fees if we include TX's like this as each block could only hold 11 of them for total fees of 0.1BTC! And have latency of 3.3 seconds.

getblocktemplate latency isn't noticeable unless the CPU usage generated when it is called is enough to slow your p2pool node.

In short, unless your efficiency suffers (measured over hundreds of shares), it's fine to allow these transactions in.

[SebastianJu]

Thanks for the answers!

If i understand it correctly a real bitcoin block that was found by a p2pool miner cant be stolen by him because this block already includes all the reward transactions to those miners that mined on that block. So a miner has to decide upfront if he wants to mine p2pool or solo. Deciding to change this wont work after a block was found.

That means the reward 25BTC + fees is created and in the same time these newly mined bitcoins are broken apart? I didnt think this can work because the actual block only brought this coins into existence but at the same time is splitting it. But it seems to work then.

What i meant regarding the reward. The split of the reward among all miners means that the newly mined block is not having the newest data. Up to the last 10 seconds of mining of others can be lost because not already included. 10 seconds are a good choice then to minimize this i think.

I tried to install the groupcoin wallet because at the moment i mine at bitparking.com and need an address. I dont get how its done. And there is no exchange for groupcoins to get an address from there. So maybe in the p2pool community there is a way to circumvent this by someone providing an address where i could send my rewards to and later sell it at Open Transaction? So that not everyone has to create his own wallet? Is there such thing already?

I have read its possible to mine litecoins too. Would it be possible to hire a coder that creates me a script so that i could mine any other 256 Coin with p2pool too? I have read i even could merge mine this way. Is this possible in p2pool?

The amount of lost shares in p2pool are normal. And every p2pool miner has the same. So its fair among the p2pool users.
Theory: But that means that a certain amount of hashpower is lost compared to solo mining. The shares maybe were good but they are lost and so is the amount of time invested in them.
Solution?: Am i right that this is no disadvantage to solo mining because the real bitcoin block that is found in p2pool is directly put into the network via solomining? So the lost shares does not affect in the end because for the real found block those lost shares dont exist. Correct? Then p2pool would be even better than normal pools because they have to receive the found share first and from there propagate it.

Sorry for the many questions...

[zvs]

This transaction:
https://blockchain.info/tx/6dad36cbfca544df4b2608dd38df0e9a91061075c780cf10acdc74e6d7f00504

added 0.3seconds to  GetBlockTemplate latency. It is 87k in size with 588 inputs and fee of 0.0093.

This is included if you have mintxfee=0.0001 as fee is over 0.0001*87=0.0087.

However we are never going to earn a lot of fees if we include TX's like this as each block could only hold 11 of them for total fees of 0.1BTC! And have latency of 3.3 seconds.


Does anyone know where in the code this is? Seems odd that it takes so long. It does not have to check sigs or anything like that.

it is in main.cpp

int64 CTransaction::nMinTxFee = 50000;  // Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 50000;

(i think the following one just applies to your own created transactions)
int64 nTransactionFee = 50000;        

you'd also have to change the fee after the default 27000 priority transaction is full

the nMinFee = xxxx.

otherwise after 27000, it'll accept priority transactions at the .0001 rate, while using .0005 for the rest

mine has only accepted 0.0005 for a while now

[TierNolan]

If i understand it correctly a real bitcoin block that was found by a p2pool miner cant be stolen by him because this block already includes all the reward transactions to those miners that mined on that block. So a miner has to decide upfront if he wants to mine p2pool or solo. Deciding to change this wont work after a block was found.

Yes.

That means the reward 25BTC + fees is created and in the same time these newly mined bitcoins are broken apart? I didnt think this can work because the actual block only brought this coins into existence but at the same time is splitting it. But it seems to work then.

The "coinbase" transaction is just like any other transaction, except it has no inputs.  There is no problem with it have 1000 outputs, as long as the block is less than 1MB total.

What i meant regarding the reward. The split of the reward among all miners means that the newly mined block is not having the newest data. Up to the last 10 seconds of mining of others can be lost because not already included. 10 seconds are a good choice then to minimize this i think.

It is a random process.  Failed hashes aren't saved up or something.

The last 10 seconds was used to try to find the block, so it wasn't wasted.  Ofc, only 1 miner actually found one.

[TierNolan]

getblocktemplate latency isn't noticeable unless the CPU usage generated when it is called is enough to slow your p2pool node.

In short, unless your efficiency suffers (measured over hundreds of shares), it's fine to allow these transactions in.

A potential solution here would be to mine empty blocks.  When there is a new block, your miners immediately switches to a coinbase only block.  Once getblocktemplate returns a block, p2pool can switch over to that.