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

dog1965

sr. member

Activity: 392

Merit: 250

can someone please help I JUST STARTED MY OWN NODE its running fine except I keep getting these messages when I start up and occasionally when its running looks like I am missing a plug in or something ?

exceptions.AssertionError: tried to broadcast share without knowing all its new transactions

Error while processing Event callbacks:
2016-02-01 10:45:02.816000 > Traceback (most recent call last):
2016-02-01 10:45:02.816000 > File "p2pool\node.pyc", line 135, in download_shares
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 > File "p2pool\node.pyc", line 48, in handle_shares
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 > File "p2pool\node.pyc", line 297, in set_best_share
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.816000 > File "p2pool\util\variable.pyc", line 74, in set
2016-02-01 10:45:02.816000 >
2016-02-01 10:45:02.831000 > --- ---
2016-02-01 10:45:02.831000 > File "p2pool\util\variable.pyc", line 42, in happened
2016-02-01 10:45:02.831000 >
2016-02-01 10:45:02.831000 > File "p2pool\node.pyc", line 96, in broadcast_share
2016-02-01 10:45:02.831000 >
2016-02-01 10:45:02.831000 > File "p2pool\p2p.pyc", line 317, in sendShares
2016-02-01 10:45:02.831000 >
2016-02-01 10:45:02.831000 > exceptions.AssertionError: tried to broadcast share without knowing all its new transactions

P2Pool: 17470 shares in chain (17474 verified/17474 total) Peers: 7 (0 incoming)
2016-02-01 13:36:07.455000 Local: 5764GH/s in last 10.0 minutes Local dead on arrival: ~2.4% (1-5%) Expected time to share: 30.0 minutes
2016-02-01 13:36:07.455000 Shares: 6 (1 orphan, 0 dead) Stale rate: ~16.7% (3-57%) Efficiency: ~93.8% (49-110%) Current payout: (0.1734)=0.1734 BTC
2016-02-01 13:36:07.455000 Pool: 882TH/s Stale rate: 11.1% Expected time to block: 6.8 days
2016-02-01 13:36:10.065000 > Unhandled error in Deferred:
2016-02-01 13:36:10.065000 > Unhandled Error
2016-02-01 13:36:10.065000 > Traceback (most recent call last):
2016-02-01 13:36:10.065000 > Failure: twisted.internet.defer.TimeoutError: in ReplyMatcher

Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: peer too old
2016-02-01 14:50:07.081000 Bad peer banned: (u'188.138.106.130', 9333)
2016-02-01 14:50:07.081000 Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: first message was not version message
2016-02-01 14:50:07.097000 Bad peer banned: (u'188.138.106.130', 9333)
2016-02-01 14:50:07.097000 Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: first message was not version message
2016-02-01 14:50:07.097000 Bad peer banned: (u'188.138.106.130', 9333)
2016-02-01 14:50:07.097000 Peer 188.138.106.130:9333 misbehaving, will drop and ban. Reason: first message was not version message
2016-02-01 14:50:07.097000 Bad peer banned: (u'188.138.106.130', 9333)

Computer I am running it on is a INTEL I7 4930k overclocking to 4.6 GHZ stable.
RAM: 16GB corsair dominator 4GB sticks 4 sticks.
MOBO: MSI BIG BANG-XPOWER II LGA2011
HDD: 6TB raid configuration "two 3tb"
8tb raid configuration "four 2tb drives"
stupid verizom 100MB/s router 100 up/down

miners: antminer s5 and antminer S7 which both don't show up in the p2pool dos command windows when I run the node only combined hash rate speed shows up those are my miners which I am mining on my own pool. question I am using a different bitcoin address then my pool's BTC address do they have to be the same Huh

? also I am mining to a online wallet.

I don't want to ask a million questions I am new at running a node but if anyone can answer them its much appreciated. I just want to stay focused on what's causing the errors a pasted above and how to fix it ?

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Quote from: OgNasty on February 01, 2016, 03:52:28 PM

Quote from: p3yot33at3r on February 01, 2016, 03:49:20 PM

Well, an advantage of having a low hash rate is the nice, big, juicy block! payouts

Yes, it just sucks if it takes you a long time to submit an accepted share and then your work falls off the chain and you never receive anything.

Amen to that.

OgNasty

donator

Activity: 4760

Merit: 4323

Leading Crypto Sports Betting & Casino Platform

Quote from: p3yot33at3r on February 01, 2016, 03:49:20 PM

Well, an advantage of having a low hash rate is the nice, big, juicy block! payouts

Yes, it just sucks if it takes you a long time to submit an accepted share and then your work falls off the chain and you never receive anything.

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Well, an advantage of having a low hash rate is the nice, big, juicy block! payouts

OgNasty

donator

Activity: 4760

Merit: 4323

Leading Crypto Sports Betting & Casino Platform

Quote from: organofcorti on February 01, 2016, 03:33:15 PM

Quote from: OgNasty on February 01, 2016, 03:10:00 PM

Quote from: Richy_T on January 29, 2016, 04:12:53 PM

Any way to do fractional shares, perhaps?

We split rewards evenly based on hashes instead of shares to help smooth out variance for the little guys.
https://bitcointalksearch.org/topic/p2pool-nastypool-0-fee-prop-on-pplns-ipv6-support-bonus-credits-306611

That thread doesn't explain how the reward method works though -- what does Prop-on-PPLNS mean? Clearly, you're not going to get miners to send you every single hash they make, so how do you pay "by hash"?

This probably isn't the proper thread to discuss specifics relating to our payout method. However, it's pretty simple. Rewards earned by NastyPool (p2pool node) are split evenly among the -PoP miners based on their average reported hashrate during the week period.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: OgNasty on February 01, 2016, 03:10:00 PM

Quote from: Richy_T on January 29, 2016, 04:12:53 PM

Any way to do fractional shares, perhaps?

We split rewards evenly based on hashes instead of shares to help smooth out variance for the little guys.
https://bitcointalksearch.org/topic/p2pool-nastypool-0-fee-prop-on-pplns-ipv6-support-bonus-credits-306611

That thread doesn't explain how the reward method works though -- what does Prop-on-PPLNS mean? Clearly, you're not going to get miners to send you every single hash they make, so how do you pay "by hash"?

OgNasty

donator

Activity: 4760

Merit: 4323

Leading Crypto Sports Betting & Casino Platform

Quote from: Richy_T on January 29, 2016, 04:12:53 PM

Any way to do fractional shares, perhaps?

We split rewards evenly based on hashes instead of shares to help smooth out variance for the little guys.
https://bitcointalksearch.org/topic/p2pool-nastypool-0-fee-prop-on-pplns-ipv6-support-bonus-credits-306611

CartmanSPC

legendary

Activity: 1270

Merit: 1000

Quote from: Polyatomic on January 30, 2016, 10:30:35 PM

Wait up can someone please tell me again,
`` bitcoinaddresshere/1 `` is that always submit shares at the target and higher.
`` bitcoinaddresshere/2 `` is that always submit shares double the target and higher.

Not sure where you got this but it is wrong.

Anything after the '/' lower than the current min diff of 1570000 will give you the minimum share diff.
Anything higher up to the current max of 47100000 will give you shares less often but of higher value.

I think you people should target about 1 share every 6-12 hours to allow smaller miners a chance.

Quote from: Polyatomic on January 30, 2016, 10:30:35 PM

Code:

modulate share difficulty to prevent any node from producing more than 5% of shares

I'm curious now, what actually happens to large miners with enough hashrate to trigger that?.

This is now 1.3%. It is on a per node basis and is supposed to increase the share diff for everyone on a node that has more than 1.3% of the p2pool hashrate. It can be overrode by using 'address/number'.

Polyatomic

sr. member

Activity: 257

Merit: 250

Wait up can someone please tell me again,

`` bitcoinaddresshere/1 `` is that always submit shares at the target and higher?.
`` bitcoinaddresshere/2 `` is that always submit shares double the target and higher?.

Say the sharechain target is 4 000 000 How does one submit only, shares double
that and higher.

Lets grep the source yeah

Code:

milton@milton:~/temp/p2pool$ git grep share_target
p2pool/bitcoin/getwork.py: def __init__(self, version, previous_block, merkle_root, timestamp, bits, share_target):
p2pool/bitcoin/getwork.py: self.version, self.previous_block, self.merkle_root, self.timestamp, self.bits, self.share_target = version, previous_block, merkle_root, timestamp, bits, share_target
p2pool/bitcoin/getwork.py: return hash((self.version, self.previous_block, self.merkle_root, self.timestamp, self.bits, self.share_target))
p2pool/bitcoin/getwork.py: 'target': pack.IntType(256).pack(self.share_target).encode('hex'),
p2pool/bitcoin/getwork.py: share_target=pack.IntType(256).unpack(getwork['target'].decode('hex')),
p2pool/bitcoin/stratum.py: self.other.svc_mining.rpc_set_difficulty(bitcoin_data.target_to_difficulty(x['share_target'])).addErrback(lambda err: None)
p2pool/bitcoin/worker_interface.py: share_target=x['share_target'],
p2pool/main.py: my_shares_per_s = sum(datum['work']/dt/bitcoin_data.target_to_average_attempts(datum['share_target']) for datum in datums)
p2pool/work.py: desired_pseudoshare_target = None
p2pool/work.py: desired_share_target = None
p2pool/work.py: desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
p2pool/work.py: desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
p2pool/work.py: return user, pubkey_hash, desired_share_target, desired_pseudoshare_target
p2pool/work.py: user, pubkey_hash, desired_share_target, desired_pseudoshare_target = self.get_user_details(user)
p2pool/work.py: return pubkey_hash, desired_share_target, desired_pseudoshare_target
p2pool/work.py: def get_work(self, pubkey_hash, desired_share_target, desired_pseudoshare_target):
p2pool/work.py: if desired_share_target is None:
p2pool/work.py: desired_share_target = 2**256-1

That looks interesting lets try a bit of pickaxe

Code:

milton@milton:~/temp/p2pool$ git log -Sshare_target --pretty=raw --abbrev-commit p2pool/work.py
commit c345d54
tree 02354ed885c4c302aae09e5689d6f7f6ccd79064
parent 29493ba726ab40f78574361fdeabec075a8a685f
author Forrest Voight 1372869213 -0400
committer Forrest Voight 1372873668 -0400

   dynamically adjust share difficulty to prevent payouts below dust threshold

commit 819f0e3
tree eab5343ad18bc2fa0e0b46b8fc7d9913243259f1
parent d2941ed60b7e65683ecaa8774c0e5e9e7dad2d4b
author Forrest Voight 1372439913 -0400
committer Forrest Voight 1372443960 -0400

   modulate share difficulty to prevent any node from producing more than 5% of shares

commit 80c9591
tree 4b573ac22ff8ec5c7fc8d7a3144517da90e36075
parent 70d337b9024ff6564fcbebae114c95b91422aed3
author Forrest Voight 1340553333 -0400
committer Forrest Voight 1340555939 -0400

   moved WorkerBridge to p2pool.work

p2pool/work.py: desired_share_target = min(desired_share_target,
p2pool/work.py: desired_share_target = min(desired_share_target,
p2pool/work.py: desired_target=desired_share_target,
p2pool/work.py: if desired_pseudoshare_target is None:
p2pool/work.py: target = desired_pseudoshare_target
p2pool/work.py: share_target=target,
p2pool/work.py: self.local_rate_monitor.add_datum(dict(work=bitcoin_data.target_to_average_attempts(target), dead=not on_time, user=user, share_target=share_info['bits'].target))

Ah k there

Code:

milton@milton:~/temp/p2pool$ git show 819f0e3
diff --git a/p2pool/work.py b/p2pool/work.py
index 40a1a30..346db56 100644
--- a/p2pool/work.py
+++ b/p2pool/work.py
@@ -142,18 +142,20 @@ class WorkerBridge(worker_interface.WorkerBridge):
   user, contents2 = contents[0], contents[1:]

   desired_pseudoshare_target = None
- desired_share_target = 2**256 - 1
+ desired_share_target = None
   for symbol, parameter in zip(contents2[::2], contents2[1::2]):
   if symbol == '+':
   try:
   desired_pseudoshare_target = bitcoin_data.difficulty_to_target(float(parameter))
   except:
- pass
+ if p2pool.DEBUG:
+ log.err()
   elif symbol == '/':
   try:
   desired_share_target = bitcoin_data.difficulty_to_target(float(parameter))
   except:
- pass
+ if p2pool.DEBUG:
+ log.err()

I can't tell what a miner is supposed to put in front of the / ?
It also says in the commit message of 819f0e3e3ab9460fe60606c3f1e9c562d40361c7

Code:

modulate share difficulty to prevent any node from producing more than 5% of shares

I'm curious now, what actually happens to large miners with enough hashrate to trigger that?.
Take it easy guys and maybe I'll see ya round. I'll delete if this post is too noisy.
=^)

Edit: Sun Jan 31 14:45:56 ACDT 2016
Cheers CartmanSPC

nicklello

member

Activity: 193

Merit: 10

Quote from: CartmanSPC on January 29, 2016, 05:49:38 PM

Quote from: CartmanSPC on January 29, 2016, 05:42:28 PM

Quote from: jonnybravo0311 on January 29, 2016, 01:45:13 PM

The number of nodes isn't a problem, and really never has been. Plenty of people put up and run publicly accessible p2pool nodes. Heck, I was one of them for 2 years.

Ideally, if you're interested in p2pool, you'd run your own node. That's the ultimate design of it - to be completely decentralized. It's a fantastic concept. As I pointed out, not everybody does so. So, if there are plenty of nodes from which people can choose, why aren't more people here? Well, that leads back to the part of my post you didn't quote.

The variance here is twofold. First, is getting shares onto the chain. Share difficulty is currently 1360000. So what does that mean for expectations?

Antminer S1 would expect to land a share every 9 hours or so
Antminer S3 would expect to land a share every 3.5 hours or so
Antminer S5 would expect to land a share every 1.4 hours or so
Antminer S7 would expect to land a share every half an hour or so

So, the price of entry is pretty steep. And, it only gets worse as more hashing power is added to the pool because the share difficulty rises in conjunction with the added hash. That's the ultimate problem to be solved: how do you keep miners from suffering more and more variance even as the pool gains hash and solves more blocks?

I keep coming back to the idea of increasing the maximum p2pool share difficulty from the current 30 time the minimum. I believe this would help decrease the minimum p2pool share difficulty and provide more shares for smaller miner in turn lowering variance. Currently the maximum share diff is 40800000 based on the min being 1360000. I believe p2pool automatically increases the share difficulty on each node based on how much hash rate it has in comparison to the rest of the pool.

[note to self: post code where this is done]

For an S7 if the miner set's his share diff to be the current max he would get a share every ~15 hours (based on the example in the quote). I don't have an S7 to see if it is automatically increasing it's difficulty and by how much. If nodes are not increasing difficulty then we need to figure out why...but I think they are.

Found an old post from roy7 that goes into more detail:
https://bitcointalk.org/index.php?topic=18313.msg5950880;topicseen#msg5950880

[note to self: post code where the 30 times the minimum share difficulty is done]

For example...this miner with 22 TH/s is currently using the minimum share diff of 1430391. ETA to share is about 5 minutes. They should be running with the max share diff not min. By running with the min they are taking away shares that smaller miners could use to get in the share chain and also increasing the min share diff for everyone. If they set themselves to use the current max share diff it would give them a share every 2.5 hours instead of 5 minutes which is more than reasonable. They will make the same amount and help out smaller miners and the entire pool as a whole... including themselves.

http://minefast.coincadence.com/miner.php?id=1Nhx4RU5bbUiHEXJLFEdQaewwHYnpSNAvD

This example shows that p2pool may not be automatically increasing the share diff at the node level...or, more likely, the miner explicitly set his diff to be low. It's been a while since I looked at the code but I think it was last set to if a node has more then 5% of the hashrate increase. The node where this miner is at is about 45 TH out of 600 TH so a little over 5%.

Edit: it's actually 1.3% now so that node should definitely be increasing their miners share diff. The miner most likely is overriding it though.

Code:

bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty

https://github.com/p2pool/p2pool/blob/482f410b0f48696901ae2a732450d02a27c0edc6/p2pool/work.py#L290

Was lowered from 5% on 11-04-2013 in this commit: https://github.com/p2pool/p2pool/commit/69d7300919e0f9b23ec81c1d01c0bf12cdb1ebc5

Maybe time to lower even more?

Are you suggesting that the ability to set your miner's difficulty to a value lower than the p2pool node would otherwise set is in fact causing this issue with shares ?

Would a way forward be to disable the miner abiility to set difficulty ?

CartmanSPC

legendary

Activity: 1270

Merit: 1000

Quote from: kano on January 29, 2016, 06:22:54 PM

So ... if p2pool was 10% of the network, the pool would be ... 86PH ... yeah consider that in your calculations ...

... and reducing share time means more lost shares.

Of course there's the other problem that happened recently when someone easily 51% p2pool ... and no one seemed to care or even notice Tongue

Well, yea...ultimately p2pool it is flawed in that it is not scalable among other things. Tongue

...and I am suggesting to increase share times (for larger miners) not decrease.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

So ... if p2pool was 10% of the network, the pool would be ... 86PH ... yeah consider that in your calculations ...

... and reducing share time means more lost shares.

Of course there's the other problem that happened recently when someone easily 51% p2pool ... and no one seemed to care or even notice Tongue

CartmanSPC

legendary

Activity: 1270

Merit: 1000

Quote from: CartmanSPC on January 29, 2016, 05:42:28 PM

Quote from: jonnybravo0311 on January 29, 2016, 01:45:13 PM

The number of nodes isn't a problem, and really never has been. Plenty of people put up and run publicly accessible p2pool nodes. Heck, I was one of them for 2 years.

Ideally, if you're interested in p2pool, you'd run your own node. That's the ultimate design of it - to be completely decentralized. It's a fantastic concept. As I pointed out, not everybody does so. So, if there are plenty of nodes from which people can choose, why aren't more people here? Well, that leads back to the part of my post you didn't quote.

The variance here is twofold. First, is getting shares onto the chain. Share difficulty is currently 1360000. So what does that mean for expectations?

Antminer S1 would expect to land a share every 9 hours or so
Antminer S3 would expect to land a share every 3.5 hours or so
Antminer S5 would expect to land a share every 1.4 hours or so
Antminer S7 would expect to land a share every half an hour or so

So, the price of entry is pretty steep. And, it only gets worse as more hashing power is added to the pool because the share difficulty rises in conjunction with the added hash. That's the ultimate problem to be solved: how do you keep miners from suffering more and more variance even as the pool gains hash and solves more blocks?

I keep coming back to the idea of increasing the maximum p2pool share difficulty from the current 30 time the minimum. I believe this would help decrease the minimum p2pool share difficulty and provide more shares for smaller miner in turn lowering variance. Currently the maximum share diff is 40800000 based on the min being 1360000. I believe p2pool automatically increases the share difficulty on each node based on how much hash rate it has in comparison to the rest of the pool.

[note to self: post code where this is done]

For an S7 if the miner set's his share diff to be the current max he would get a share every ~15 hours (based on the example in the quote). I don't have an S7 to see if it is automatically increasing it's difficulty and by how much. If nodes are not increasing difficulty then we need to figure out why...but I think they are.

Found an old post from roy7 that goes into more detail:
https://bitcointalk.org/index.php?topic=18313.msg5950880;topicseen#msg5950880

[note to self: post code where the 30 times the minimum share difficulty is done]

For example...this miner with 22 TH/s is currently using the minimum share diff of 1430391. ETA to share is about 5 minutes. They should be running with the max share diff not min. By running with the min they are taking away shares that smaller miners could use to get in the share chain and also increasing the min share diff for everyone. If they set themselves to use the current max share diff it would give them a share every 2.5 hours instead of 5 minutes which is more than reasonable. They will make the same amount and help out smaller miners and the entire pool as a whole... including themselves.

http://minefast.coincadence.com/miner.php?id=1Nhx4RU5bbUiHEXJLFEdQaewwHYnpSNAvD

This example shows that p2pool may not be automatically increasing the share diff at the node level...or, more likely, the miner explicitly set his diff to be low. It's been a while since I looked at the code but I think it was last set to if a node has more then 5% of the hashrate increase. The node where this miner is at is about 45 TH out of 600 TH so a little over 5%.

Edit: it's actually 1.3% now so that node should definitely be increasing their miners share diff. The miner most likely is overriding it though.

Code:

bitcoin_data.average_attempts_to_target(local_hash_rate * self.node.net.SHARE_PERIOD / 0.0167)) # limit to 1.67% of pool shares by modulating share difficulty

https://github.com/p2pool/p2pool/blob/482f410b0f48696901ae2a732450d02a27c0edc6/p2pool/work.py#L290

Was lowered from 5% on 11-04-2013 in this commit: https://github.com/p2pool/p2pool/commit/69d7300919e0f9b23ec81c1d01c0bf12cdb1ebc5

Maybe time to lower even more?

CartmanSPC

legendary

Activity: 1270

Merit: 1000

Quote from: jonnybravo0311 on January 29, 2016, 01:45:13 PM

The number of nodes isn't a problem, and really never has been. Plenty of people put up and run publicly accessible p2pool nodes. Heck, I was one of them for 2 years.

Ideally, if you're interested in p2pool, you'd run your own node. That's the ultimate design of it - to be completely decentralized. It's a fantastic concept. As I pointed out, not everybody does so. So, if there are plenty of nodes from which people can choose, why aren't more people here? Well, that leads back to the part of my post you didn't quote.

The variance here is twofold. First, is getting shares onto the chain. Share difficulty is currently 1360000. So what does that mean for expectations?

Antminer S1 would expect to land a share every 9 hours or so
Antminer S3 would expect to land a share every 3.5 hours or so
Antminer S5 would expect to land a share every 1.4 hours or so
Antminer S7 would expect to land a share every half an hour or so

So, the price of entry is pretty steep. And, it only gets worse as more hashing power is added to the pool because the share difficulty rises in conjunction with the added hash. That's the ultimate problem to be solved: how do you keep miners from suffering more and more variance even as the pool gains hash and solves more blocks?

I keep coming back to the idea of increasing the maximum p2pool share difficulty from the current 30 time the minimum. I believe this would help decrease the minimum p2pool share difficulty and provide more shares for smaller miner in turn lowering variance. Currently the maximum share diff is 40800000 based on the min being 1360000. I believe p2pool automatically increases the share difficulty on each node based on how much hash rate it has in comparison to the rest of the pool.

[note to self: post code where this is done]

For an S7 if the miner set's his share diff to be the current max he would get a share every ~15 hours (based on the example in the quote). I don't have an S7 to see if it is automatically increasing it's difficulty and by how much. If nodes are not increasing difficulty then we need to figure out why...but I think they are.

Found an old post from roy7 that goes into more detail:
https://bitcointalk.org/index.php?topic=18313.msg5950880;topicseen#msg5950880

[note to self: post code where the 30 times the minimum share difficulty is done]

Tibi

newbie

Activity: 56

Merit: 0

what do we define as per of today the term small miner, are we talking about running outdated asic miners or a persone whit one S7 ?

windpath

legendary

Activity: 1258

Merit: 1027

The solution may very well lie with technologies that are imminently on the horizon.

Both Rootstock and Lightning could offer a means of decentralized trust-less block reward accumulation for small miners.

Richy_T

legendary

Activity: 2576

Merit: 2267

1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k

Quote from: jonnybravo0311 on January 29, 2016, 01:45:13 PM

The number of nodes isn't a problem, and really never has been. Plenty of people put up and run publicly accessible p2pool nodes. Heck, I was one of them for 2 years.

Ideally, if you're interested in p2pool, you'd run your own node. That's the ultimate design of it - to be completely decentralized. It's a fantastic concept. As I pointed out, not everybody does so. So, if there are plenty of nodes from which people can choose, why aren't more people here? Well, that leads back to the part of my post you didn't quote.

The variance here is twofold. First, is getting shares onto the chain. Share difficulty is currently 1360000. So what does that mean for expectations?

Antminer S1 would expect to land a share every 9 hours or so
Antminer S3 would expect to land a share every 3.5 hours or so
Antminer S5 would expect to land a share every 1.4 hours or so
Antminer S7 would expect to land a share every half an hour or so

So, the price of entry is pretty steep. And, it only gets worse as more hashing power is added to the pool because the share difficulty rises in conjunction with the added hash. That's the ultimate problem to be solved: how do you keep miners from suffering more and more variance even as the pool gains hash and solves more blocks?

Any way to do fractional shares, perhaps?

Tibi

newbie

Activity: 56

Merit: 0

all in all p2pool is a not so good thing for most of the miners . :/ to bad.

jonnybravo0311

legendary

Activity: 1344

Merit: 1024

Mine at Jonny's Pool

The number of nodes isn't a problem, and really never has been. Plenty of people put up and run publicly accessible p2pool nodes. Heck, I was one of them for 2 years.

Ideally, if you're interested in p2pool, you'd run your own node. That's the ultimate design of it - to be completely decentralized. It's a fantastic concept. As I pointed out, not everybody does so. So, if there are plenty of nodes from which people can choose, why aren't more people here? Well, that leads back to the part of my post you didn't quote.

The variance here is twofold. First, is getting shares onto the chain. Share difficulty is currently 1360000. So what does that mean for expectations?

Antminer S1 would expect to land a share every 9 hours or so
Antminer S3 would expect to land a share every 3.5 hours or so
Antminer S5 would expect to land a share every 1.4 hours or so
Antminer S7 would expect to land a share every half an hour or so

So, the price of entry is pretty steep. And, it only gets worse as more hashing power is added to the pool because the share difficulty rises in conjunction with the added hash. That's the ultimate problem to be solved: how do you keep miners from suffering more and more variance even as the pool gains hash and solves more blocks?

wariner

legendary

Activity: 1257

Merit: 1004

pool.sexy

Quote from: jonnybravo0311 on January 29, 2016, 10:57:31 AM

Finally, let's face it: people are not really that interested in running a pool (or node in this case). Maybe they don't have a computer that is on 24 hours a day. Maybe they have limited bandwidth. Maybe they just don't have the technical knowledge and have no desire to learn it.

I have 7 nodes...you are welcome Cheesy

Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 102. (Read 2591920 times)