Dogecoin PPLNS window only 12 hours - suggest changing it to 24

[penneydude]

Is it possible for us to change the share chain length on the Dogecoin network to 24 hours instead of 12? The current setting is a little disadvantageous to smaller miners, and I'm seeing a lot of people getting frustrated over frequent dry spells.

I've talked to blixnood and he is onboard to change the setting in his repo as well, we would just have to coordinate it and urge nodes to update.

[Rav3nPL]

It need to erase share chain from start. There is no way to change this "in
the fly"
31 sty 2014 04:39 "penneydude" notifications@github.com napisa³(a):

Is it possible for us to change the share chain length on the Dogecoin
network to 24 hours instead of 12? The current setting is a little
disadvantageous to smaller miners, and I'm seeing a lot of people getting
upset about frequent dry spells.

I've talked to blixnood and he is onboard to change the setting in his
repo as well, we would just have to coordinate it and urge nodes to update.

Reply to this email directly or view it on GitHubhttps://github.com//issues/26
.

[penneydude]

I realize that it's not a trivial change as it would require a hard fork of the share chain, but I think it's one that would be beneficial to the Dogecoin P2Pool network on the whole, especially to miners who are just starting with P2Pool and are confused why their payouts stop and start so often.

We have a number of larger pool operators, as well as blixnood, who agree with the idea of switching to a 24 hour share chain - it's definitely something that we would have to plan for a specific time and date in the near future, not something that we could roll out without any warning.

[CartmanSPC]

I think what you may be wanting to change is SPREAD not PPLNS. Chain length (PPLNS) is used to determine the number of shares back to compute payout amount or in other words how long it takes before they reach their full payout.

SPREAD determines for how many blocks they will get paid. I would propose SPREAD be changed to 30 (from 10) due to the 60 second block time.

[Rav3nPL]

@CartmanSPC looks like you not fully understand how share chain works.
SHARE_PERIOD means how pool share diff is regulated to hit one share every x seconds. This should be 10x less than block time in network to avoid share punishing. Lower number also means that share diff will be lower, but in same time chare chain will be longer so pool will eat more memory, also short share time lead to more orphans
CHAIN_LENGTH tells how long share is valid. Longer chain on low block rate means more chance to get paid for work. It also tells how long (max) you need mine to get "full" payout
TARGET_LOOKBEHIND tells how many chain shares are counted for share diff regulation. Low (10-20) values give faster diff regulation - faster response for "big" miners come and go.
SPREAD means how many (max) blocks found by pool are pay for every share. Large numbers allow pay for more blocks when pool is finding many blocks (ie when coin has really low diff).
So if we want make longer PPLNS window we need change CHAIN_LENGHT and SPREAD if we are finding many blocks or only CHAIN_LENGHT when we finding small number (1-2) blocks in CHAIN_LENGHT time.

[penneydude]

It looks like the network is currently finding a block every ~1.1 hours, so I think it would be worth tweaking both CHAIN_LENGTH and SPREAD.

Here are the proposed changes:

SHARE_PERIOD=15, # seconds target spacing
CHAIN_LENGTH=24_60_60//15, # shares
REAL_CHAIN_LENGTH=24_60_60//15, # shares
TARGET_LOOKBEHIND=20, # shares coinbase maturity
SPREAD=30, # blocks

I think the other parameters are fine where they are currently, and I've increased SPREAD a bit extra to allow for network growth.

Would you be ok with these changes? If so, we can all agree on a specific time and date to push them, and get the word out to node operators in advance to notify them of the coming update.

[EA5]

Don't you think the SHARE_PERIOD should be lower?

Also some words about the mechanism of change, will it be a new pool created and nodes could switch to it by changing networks.py? Should we provide any compensation to miners of old pool?

Do much of P2Pool operators aware of this change and support it with this parameters?

[penneydude]

Are you proposing lowering share period to reduce the share difficulty? Or do you have a different reason? We could go down to 12, but as you reduce share period you also increase the DOA rate...

That is what we would have to do, yeah - It's a hard fork of the network. What kind of compensation are you talking about? If we coordinate the switch well we should see pretty minimal downtime.

I've asked some of the larger node operators for feedback, and the ones I've heard from support the changes. Nothing is set in stone yet though, I think this should be an open discussion.

[EA5]

"Are you proposing lowering share period to reduce the share difficulty? Or do you have a different reason? We could go down to 12, but as you reduce share period you also increase the DOA rate..."
Yes, for this reason and with that consequences. As you start this initiative for smaller miners, SHARE_PERIOD has much effect for their case, but too low one is bad for the pool. Should we do this (mb even lower) or no?

"That is what we would have to do, yeah - It's a hard fork of the network. What kind of compensation are you talking about? If we coordinate the switch well we should see pretty minimal downtime."
Could we use old share chain for the new settings? If yes - it's ok.
But anyway nodes will switch to new settings in different time - so they will have different parts of old share chain, and then only the first node that switch could keep it, others should totally delete it and join this first node. But miners that continue to mine on nodes with old settings will be underpaid, as their work for this period will not go to new share chain.

And also a question - will there be new IDENTIFIER/PREFIX in /p2pool/networks.py for the new settings so nodes with new/old settings could not connect, or we do not need that and they could work together for some time?

If we decide to change SHARE_PERIOD, it also may affect the answers of the previous questions.

(All this are based on my understanding of how P2Pool works. Maybe I'am wrong in something. But I think this is important things we should consider before we start.)

"I've asked some of the larger node operators for feedback, and the ones I've heard from support the changes. Nothing is set in stone yet though, I think this should be an open discussion."
That's nice. We need more responses to make coordinated decision and not to brake pool into two parts.

[penneydude]

I would be ok with reducing SHARE_PERIOD to 12, but I don't think I'd personally feel comfortable going any lower. It doesn't seem like a good idea to change too many variables all at the same time, otherwise we risk messing up the system in a way we didn't predict.

As far as compensating miners on nodes that fail to switch, I think that would be pretty difficult. I know that I don't have the capital required to do something like that... To me, it seems like it is the responsibility of each node operator to keep their software up to date. We will make our honest best effort to get the word out about the coming update - Obviously it is in everyone's best interest to keep as much of our hashing power as we can on the same network.

Regarding identifier and prefix, yes, I believe we will have to change both of those parameters, as well as the port. As far as I know there is no way to make a new network with a different share chain length work together with the current one, but I will get in touch with forrestv on IRC later today and verify that.

If you know any node operators, or have a means of contacting any (forums, etc) then please feel free to do so, and tell them to weigh in with their thoughts. We have an open discussion currently going on Reddit as well, here:

http://www.reddit.com/r/dogemining/comments/1wm315/i_think_i_found_the_reason_for_frequent_p2pool/

That would likely be a better place for feedback. I'd like to keep this specific thread as uncluttered as possible.

[penneydude]

@Rav3nPL We are looking to make these changes in the next week or two - Would that be ok?

[zaw9c1]

Yes, anything to help the share droughts!! I got one share all day and
it expired before i find another :( 12more hours and not found one yet.
somebody else came on my node with 2MegaHash and he found share in 10min!

On 2/3/2014 7:14 PM, penneydude wrote:

@Rav3nPL https://github.com/Rav3nPL We are looking to make these
changes in the next week or two - Would that be ok?

—
Reply to this email directly or view it on GitHub
#26 (comment).

[CartmanSPC]

A lower SHARE_PERIOD would give miners a greater chance to get a share (since there would be more of them to go around) but with the size/hashrate of the doge p2pool I am not sure if that is a good thing.

Increasing the PPLNS to 24 hours would give miners twice as long to get a share. Both options combined would benefit smaller miners BUT it may be (like Warren (LTC dev) has said for the LTC p2pool) that it has grown to a level where smaller miners just don't do well.

The (smaller by hashrate) LTC p2pool currently has a minimum recommended hash rate of 1.5 Mh/s over the last 24 hours and a minimum of 1.8 Mh/s over 30 days. http://ltc.noshit.pl/p2pool

[zaw9c1]

even some of the mega hasher are having trouble find shares some days. not just lower hash rate users. some days you find a lot, other day you don't find one for 2 days, when you find one you don't find another. :(

• you can gauge by comment on reddit. on good days ppl be raving about how great p2pool is, on the dry days, people who do p2p looking for another place to mine.. seems like it is effecting a lot of people at once.

[CartmanSPC]

Yes, true. I have 4.5 Mh/s and left the LTC p2pool because of their changes from a SHARE_PERIOD of 10 to 15 and a SPREAD of 12 to 3(!). The reasons for the change were to reduce "dust" but we do not have that problem with doge.

My belief is that we should consider a 24 hour PPLNS, SPREAD of 30 and SHARE_PERIOD of either 10 or 15 (undecided but leaning towards 10).

Also, the network hash is large enough where we should consider increasing the target lookbehind to 200. 20 is way to low at these levels.

[Rav3nPL]

If we want to decrease share diff we need to make shorter share and we can NOT make longer PPLNS window.
If we change window to 2x longer and in same time change share period 2x share diff will be exactly same.
Share period is 15s now and PPLNS window is 12hrs.
I think, the bes solution would be change share period to 5s. BUT this will rise pool-wide orphan ratio (faster shares always do this) and make pool more memory and CPU demanding because of 3x longer chain (more shares to handle).

[zaw9c1]

Share Diff piss me off.. :)
When when mega hasher come in an play little guys get screw out of p2pool.
I'm facing same problem in Vertcoin ATM. Before @ diff 77 share time was 10min, diff goes up to 140 share time goes to 20-35min but not too many p2pooler.
Than Pools getting attack and ppl moved ot p2pool share diff went up from 9K - 21K even at diff 122. @ 144 diff I didn't see any share diff that high.

I might not know what i'm talking about but i'm not getting shares. Because Share diff is too damn high!!!

Wattage is work!

I know share diff can be adjust for worker using addr/diff but you can't push it down below what p2pool is giving out. you can only raise it for your self.

[Rav3nPL]

There is new pull request on forrestv main repo p2pool#174
If it will work correctly share diff for bigger miners will be adapted better.

[gururise]

Agreed. Setting share diff based on hash rate looks like a better solution than mucking around with the PPLNS time period.

[penneydude]

Will this change require us to fork the share chain as well?

[zaw9c1]

If you just change the Share Diff Based on Hash Rate than I don't see why would it effect the share chain at all. I'll be on node to node basic.

[penneydude]

Would this be any different than manually setting difficulty through cgminer (setting +0.0011 as a 1Mh/s miner, for example, after your payout address on the command line), other than it being automated?

If not, I'm not sure that this will solve the problems we have been seeing -- If I'm understanding correctly, it won't make it any more likely for a miner to find a payable share, so it won't help with inconsistent payouts for smaller miners.

[Rav3nPL]

DOGE is now MM, closing.