[ANN] beeeeer.org - Primecoin mining pool!

[mhps]

ps. it's actually already on the btctalk alt coin forum, somebody already released a (small) announcement there (without my "permission" / knowledge)
pps. i still think, that a slow growing  userbase would be more vital

oops. I guess that was I who posted about beeeer.org pool in the main XPM annoucement thread. I didn't know you hadn't wanted to let the world know or a permission was needed. Thought I was helping.  Anyway maybe stopping accepting new addressed can help throttle the user base growth?

[theprofileth]

ps. it's actually already on the btctalk alt coin forum, somebody already released a (small) announcement there (without my "permission" / knowledge)
pps. i still think, that a slow growing  userbase would be more vital

oops. I guess that was I who posted about beeeer.org pool in the main XPM annoucement thread. I didn't know you hadn't wanted to let the world know or a permission was needed. Thought I was helping.  Anyway maybe stopping accepting new addressed can help throttle the user base growth?

Hint...
I think he was more worried about DDOS issues
Edit:
Any ways after some tinkering here is what I came up with for a primecoin proof of work DGM model, still need to run a bunch of tests to do some verfication that it isn't broken.

Code: [Select]

TheProfileth's attempts to make a primecoin compatible DGM method
I probably failed but hey whats life without failures
Original and most likely better version found here https://bitcointalk.org/index.php?topic=39497.0

The method is purely score-based, which means that all the information required to calculate payouts can be encoded with a single score value per participant. There is no fundamental need to keep a history of shares. However, because the scores grow exponentially, it is advised to use a logarithmic scale to store their values and do the calculations.

We will denote by B the block reward ie  999/Difficulty^2 and p = 1/Difficulty. In addition there are 3 parameters which can be adjusted to balance average fee, operator variance, share- and pool-based participant variance, and maturity time:
f - Fixed fee.
c - Average variable fee. The average total fee will be (c+f-cf)B per block. Increasing c reduces participants' variance but increases operator's variance.
o - Cross-round leakage. Increasing o reduces participants' share-based variance but increases maturity time. When o=0 this becomes the geometric method. When o->1 this becomes a variant of PPLNS, with exponential decay instead of 0-1 cutoff (note that "exponential" does not mean "rapid", the decay can be chosen to be slow). For o=1, c must be 0 and r (defined below) can be chosen freely instead of being given by a formula.

In order to accomodate the effects of chain Length involved in primecoin I propose the addition of the variables
M = Minimum chain length accepted
T = Target chain length based on difficulty checked every block to be sure
L = Length Submitted
V = 10^((L+(T-M))
V represents the value of the share
So if M = 6
Then a chain of length 6 with a chain difficulty of 9 = 10^(9-9) =1
Then a chain of length 7 with a chain difficulty of 9 = 10^(10-9) =10
Then a chain of length 8 with a chain difficulty of 9 = 10^(11-9) =100
Then a chain of length 9 with a chain difficulty of 9 = 10^(12-9) =1000

The method is as follows:
1. When the pool first starts running, initialize s=1. Initialize the scores of all workers to 0.
2. Set r = 1 + p(1-c)(1-o)/c. If at any point the difficulty changes, p and then r should be recalculated.
3. When a share is found, increase by p*s*B*V the score of the participant who found it. Set s=s*r.
4. If the share found happens to be a valid block, then after doing #3, also do the following for each participant: Letting S be his score, give him a payout of (S(r-1)(1-f))/(ps). Set S=S*o. The remaining reward is given to the operator. Or, if the total is higher than the block reward (only possible if f<0), the operator pays the difference out of his own funds.

The inutition is this: Instead of keeping the score unchanged when a block is found (as in PPLNS) or setting all scores to 0 and effectively transferring them to the operator (as in the geometric method), a part of the score is transferred to the operator. When rounds are long, participants get to keep most of their score between rounds and this is similar to PPLNS. However, if several blocks are found in rapid succession, the operator will collect a large portion of the score and thus be the primary beneficiary of the good fortune. The fees collected this way allow letting f be negative, sweetening the rewards of long rounds. Overall, this decreases the dependence of participants' rewards on the pool's luck, thus reducing the variance caused by it.


The variance of the payout for a single submitted share is

(1-c)^4(1-o)(1-p)p^2(1-f)^2B^2
------------------------------ * V
   (2-c+co)c+(1-c)^2(1-o)p

Notably, the factor of (1-o) allows this to be much smaller than the variance of the geometric method, if o is chosen close to 1. This value is of relevance, though, only to small miners, and the potential advantage of this system is for large miners (which suffer from pool-based variance but not so much from share-based variance). It would be of interest to evaluate the total variance for a participant constituting a given portion of the pool, and the variance of the operator. So far I was unable to derive symbolic expressions for these, but they can be evaluated in simulation. For c = 0.5, o = 1-c = 0.5, f = (-c)/(1-c) = -1 I got that a miner constituting the entirety of the pool has about 30% of solo variance (instead of 100% as in PPLNS), and the operator's variance is about 25% of PPS variance.

The geometric method was so called because shares decay in a geometric sequence, and its analysis crucially depends on summation of geometric series and the fact that round length follows the geometric distribution. Because in this new method shares decay geometrically along two directions, both for every share found and for every block found, I call it the double geometric method.

The variables used in the calculations grow rapidly, so if the method is implemented naively, they will overflow the data types used. Thus the implementation should use one of the following:

a. Periodic rescaling: The only thing that matters is the values of the scores relative to the variable s. Thus, if the values grow to large, all that is needed is to rescale them. This means dividing the scores of all participants by s, and then setting s=1. This should be done once in a while, the exact times do not matter (it can even be done for every share).

b. Logarithmic scale: Instead of maintaining the variables themselves, their logarithms are stored and updated. The following is the method expressed in logarithmic scale, denoting by log the natural logarithm function and by exp the natural exponentiation function:
1. When the pool first starts running, initialize ls=0. For every worker define a variable lS and initialize it to negative infinity (or a negative number of very large magnitude, say -1000000), and do this also for every worker which later joins.
2. Set r = 1 + p(1-c)(1-o)/c, lr = log(r). If at any point the difficulty changes, p, r and lr should be recalculated.
3. When a share is found, let lS = ls + log(exp(lS-ls) + pB) for the participant who found it. Set ls = ls + lr.
4. If the share found happens to be a valid block, then after doing #3, also do the following for each participant: Give him a payout of (exp(lS-ls)*(r-1)*(1-f))/p. Set lS = lS + log(o).

For display purposes, the quantity that should be shown as the score of a worker is S/s (or exp(lS-ls) in logarithmic scale). This represents the expected payout the worker should receive in addition to any confirmed rewards (before fees). To display the expected payout after deducting fees, use (1-f)*(1-c)*S/s, or (1-f)*(1-c)*exp(lS-ls).
Edit: Made some fixes where I mixed up some operators.

[Grekk]

Where Хolokram?

[Hyperion]

Where Хolokram?

Apparently not servicing our every need. *cracks whip*

[xolokram]

Hi

like everyone noticed: server crashed (something in the backend failed) --- some critical parts of the backend are not set to restart-on-fail yet. Found blocks so far are save. Payouts will be executed manually (I will try to execute them as early as possible (regarding confirmations)).

The server will go up in a few minutes, but I still have to test some things, so there will be some restarts today.

stupid question maybe but how come there are more than six decimal places in the payouts?

Because they are probably using the higher decimal count internally for precision but you will be payed out the normal decimal amount.

this

@Grekk (compilation error):
how much RAM does the machines have? if it's less than 500 MByte, you'll have a problem

ps. it's actually already on the btctalk alt coin forum, somebody already released a (small) announcement there (without my "permission" / knowledge)
pps. i still think, that a slow growing  userbase would be more vital

oops. I guess that was I who posted about beeeer.org pool in the main XPM annoucement thread. I didn't know you hadn't wanted to let the world know or a permission was needed. Thought I was helping.  Anyway maybe stopping accepting new addressed can help throttle the user base growth?

no problem, it's ok.

@theprofileth:
that would be great / thank you
I will get back to your idea when the backend is fixed.

ps. it's actually already on the btctalk alt coin forum, somebody already released a (small) announcement there (without my "permission" / knowledge)
pps. i still think, that a slow growing  userbase would be more vital

oops. I guess that was I who posted about beeeer.org pool in the main XPM annoucement thread. I didn't know you hadn't wanted to let the world know or a permission was needed. Thought I was helping.  Anyway maybe stopping accepting new addressed can help throttle the user base growth?

Hint...
I think he was more worried about DDOS issues
[...]

Funny thing that you're mentioning it, but someone was trying to DDoS it on Day#1 (traffic went up from a few MByte/hr to Gigabytes/hr). I don't know if the latest crash was caused by a DDoS.

Where Хolokram?

Bahamas, enjoying my new Primecoins...

@Hyperion:
haha

- xolokram

[xeroc]

thanks for your incredible work.
you tell us what went wrong in your backend?

[Grekk]

@Grekk (compilation error):
how much RAM does the machines have? if it's less than 500 MByte, you'll have a problem

1st machine have 512 MB ram but swapfile disabled.
2nd is ok now

[patapato]

Code: [Select]

In order to accomodate the effects of chain Length involved in primecoin I propose the addition of the variables
M = Minimum chain length accepted
T = Target chain length based on difficulty checked every block to be sure
L = Length Submitted
V = 10^((L+(T-M))/T)
V represents the value of the share
So if M = 6
Then a chain of length 6 with a chain difficulty of 9 = 10^(9/9) =1
Then a chain of length 7 with a chain difficulty of 9 = 10^(10/9) =10
Then a chain of length 8 with a chain difficulty of 9 = 10^(11/9) =100
Then a chain of length 9 with a chain difficulty of 9 = 10^(12/9) =1000



There is an error here: 10^(9/9) = 10, not 1, and so on. The results that you want will be obtained changing '/' by '-', that is:
V = 10^((L+(T-M)) - T), wich is the same as
V = 10^(L-M)

Anyway, I keep thinking that a proportional relation, like the simple V = L, will be better to minimize variance, and it will be enough to incentivate searching for longer chains.

An exponential relation, like the one that you propose, will raise very much the variance of the people submitting mostly short chains, for which it will be close to solo mining, profiting only when they are lucky. A pool must try to organize and make profitable many many small participants, instead of few big participants.

Furthermore, how do you manage the case of a chain of length 16? will it be valuated 10000000?. Exponential valuations has no sense, it raise variance for the operator and for most of the participants.

[Roger3636]

Hello been mining for a couple of hours
and this are my stats
 "0": 26,
 "6": 657,
 "7": 44,
 "8": 4,
 "9": 1,
 "-6": 1,
I understand that 0 are rejetcts,  what is the -6 at the end? did I find a block?

[xolokram]

@roger:

Can you explain what i see on your website in /user/#id!?

sure, the values you see there are your shares and the corrosponding count for the current round/block

"0" -> rejected - mostly due to a pool restart (when your client doesn't ask for new work soon enough)
"6", "7", "8", "9" -> shares (6-chain, 7-chain etc.)
"<block-height>" -> you've found the block (the round ends, the block gets saved for later payout info and is visible in the "blocks" info page)
"<negative value>" -> this could've been a share, but it's stale

stale & 'rejected' values should be <1%
as I stated in the first post, there's the chance, that the (windows) client doesnt reconnect to the pool properly, when the server gets restarted --- this typically leads to 'rejected' values

- xolokram

ps. there was a restart this morning due to a crash, I'm investigating --- all shares were restored

@xeroc:
something in the load-balancer was wrong. i -hope- it's fixed now; it's hard to test such things.

- xolokram

ps. as long as nothing terrible happens, i'm trying to fix the reconnect/rejection bug next
pps. @all: monitor your rejection rate and reply if it went up tremendous
ppps. payout #7 executed

[Quirlorimbo]

Hello been mining for a couple of hours
and this are my stats
 "0": 26,
 "6": 657,
 "7": 44,
 "8": 4,
 "9": 1,
 "-6": 1,
I understand that 0 are rejetcts,  what is the -6 at the end? did I find a block?

"-6": 1 = stale

block is:

"block number": 1

e.g. : "157290": 1

[Roger3636]

Hello been mining for a couple of hours
and this are my stats
 "0": 26,
 "6": 657,
 "7": 44,
 "8": 4,
 "9": 1,
 "-6": 1,
I understand that 0 are rejetcts,  what is the -6 at the end? did I find a block?

"-6": 1 = stale

block is:

"block number": 1

e.g. : "157290": 1

Thankyou for clarifying so what are the 0 chain numbers? i thought the chains were 6,7,8,9,10 etc

[CoinBuzz]

When i want to compile it under BAMT (debian-based), i get this error:

error: DB_AUTO_COMMIT was not declared in this scope

is there any pre-compiled version of this miner?

[Quirlorimbo]

Hello been mining for a couple of hours
and this are my stats
 "0": 26,
 "6": 657,
 "7": 44,
 "8": 4,
 "9": 1,
 "-6": 1,
I understand that 0 are rejetcts,  what is the -6 at the end? did I find a block?

"-6": 1 = stale

block is:

"block number": 1

e.g. : "157290": 1

Thankyou for clarifying so what are the 0 chain numbers? i thought the chains were 6,7,8,9,10 etc

"0" = rejected
"-x" = stale

your rate should be ~1-3% on linux

[Roger3636]

Hello been mining for a couple of hours
and this are my stats
 "0": 26,
 "6": 657,
 "7": 44,
 "8": 4,
 "9": 1,
 "-6": 1,
I understand that 0 are rejetcts,  what is the -6 at the end? did I find a block?

"-6": 1 = stale

block is:

"block number": 1

e.g. : "157290": 1

Thankyou for clarifying so what are the 0 chain numbers? i thought the chains were 6,7,8,9,10 etc

"0" = rejected
"-x" = stale

your rate should be ~1-3% on linux

Thanks again stilll learning at the moment on current projections i'm on course to double my xpm from ypool