Bitcoin Forum
November 01, 2024, 02:48:37 AM *
News: Bitcoin Pumpkin Carving Contest
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: [XPM] [ANN] Primecoin Pool Software  (Read 5199 times)
smolen
Hero Member
*****
Offline Offline

Activity: 524
Merit: 500


View Profile
August 13, 2013, 10:57:03 AM
 #21

The big problem for making pool is shares check....
Example: If you mine 9-er chain and submit 6-er chains as share you'll get about 20 6-er chains in a hour.
Exactly! A miner properly optimized for short chains (to get the best possible reward from pool) would have low performance on 9+ chains. Sort of withholding attack from pool's point of view.

Of course I gave you bad advice. Good one is way out of your price range.
SlyWax
Sr. Member
****
Offline Offline

Activity: 248
Merit: 251



View Profile
August 13, 2013, 08:37:04 PM
Last edit: August 13, 2013, 09:40:24 PM by SlyWax
 #22

The big problem for making pool is shares check....
Example: If you mine 9-er chain and submit 6-er chains as share you'll get about 20 6-er chains in a hour.
Exactly! A miner properly optimized for short chains (to get the best possible reward from pool) would have low performance on 9+ chains. Sort of withholding attack from pool's point of view.

Well you can check if someone is getting a fast paced flow of 6-er chains and nothing else, then the pool put his share on old, until either the luck is coming back, or he is proved to be unfaithful.
bcp19
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500



View Profile
August 13, 2013, 09:37:36 PM
 #23

The big problem for making pool is shares check....
Example: If you mine 9-er chain and submit 6-er chains as share you'll get about 20 6-er chains in a hour.
Exactly! A miner properly optimized for short chains (to get the best possible reward from pool) would have low performance on 9+ chains. Sort of withholding attack from pool's point of view.
Optimizing a miner to search only short chains is kinda dumb.  Let's say ALL the miners adopt it... suddenly no blocks are found and no one makes anything.  Face it, why are 5-chains no longer accepted?  Flooding the pool with 6 chains will give you a short term increase in XPM followed by either a lockout of 6 chains or a loss of the big dogs finding blocks who get disgusted funding all the small timers who will never find a block stealing all the XPM.  The end result of both options is  a subsequent decrease in XPM.  Greed is always it's own reward.

I do not suffer fools gladly... "Captain!  We're surrounded!"
I embrace my inner Kool-Aid.
smolen
Hero Member
*****
Offline Offline

Activity: 524
Merit: 500


View Profile
August 13, 2013, 10:29:48 PM
Last edit: August 13, 2013, 10:42:10 PM by smolen
 #24

The big problem for making pool is shares check....
Example: If you mine 9-er chain and submit 6-er chains as share you'll get about 20 6-er chains in a hour.
Exactly! A miner properly optimized for short chains (to get the best possible reward from pool) would have low performance on 9+ chains. Sort of withholding attack from pool's point of view.
Optimizing a miner to search only short chains is kinda dumb.  Let's say ALL the miners adopt it... suddenly no blocks are found and no one makes anything.  Face it, why are 5-chains no longer accepted?  Flooding the pool with 6 chains will give you a short term increase in XPM followed by either a lockout of 6 chains or a loss of the big dogs finding blocks who get disgusted funding all the small timers who will never find a block stealing all the XPM.  The end result of both options is  a subsequent decrease in XPM.  Greed is always it's own reward.
Private short chain miner running on pool will increase mining profit at expense of other pool users.
Short chain miner released to the public will damage or kill pools, at least they will be forced to increase commission.
Right now scaring casual CPU miners off the pools will lead to more hashpower for other CPU-only coins.
Overall decrease of primecoin hashpower will lead to more profit for solominers. And the block reward for primecoin increases when difficulty decreases.
I see eldentyrell's trick of using signcrypton as the best way to run primecoin pool.

EDIT: link to tricone mining thread
https://bitcointalk.org/index.php?topic=49971.0

Of course I gave you bad advice. Good one is way out of your price range.
versificateur (OP)
Newbie
*
Offline Offline

Activity: 47
Merit: 0


View Profile
August 14, 2013, 12:36:50 AM
 #25

Hi all,
I finally went with Java and almost finished a getwork pool proxy that I'll re-use to implement getblocktemplate and a first draft of a stratum-like protocol.
The proxy currently act as a blank pool on top of primecoind daemon, so no reward scheme implemented at all. Therefore all "workers" point to the proxy server address:port and payments are madeto XPM address given at a JSON payment config file.
It will be possible to configure many addresses with percentage of reward associated. Default is equivalent reward for all addresses.
I currently polish/refactor proxy server and look into stratum code to "fork" it. Reward system will come next, but probably not released with proxy server which I intent to keep simple as stratum-server is.
 
versificateur (OP)
Newbie
*
Offline Offline

Activity: 47
Merit: 0


View Profile
August 14, 2013, 01:53:02 AM
 #26


You cant give 100% reward to someone, that would mean the others won't get anything.
Or I didn't get from what you are taking your 100% ...

What I meant by 100% reward is share value of an exactly diff matching submitted chain.

Anyway, the reward should try to match a % of the chain/day that the miner have, if this indicator is proven to be reliable.
But since chain/day cannot be used as a prof of work, you will have to finely tune the repartition of the shares.
chain/day is probably a deterministic model, the  I could look at Sunny code and implement it on pool side I think. But as it's not accurate, does it worth it ?

if we allocate different value for each length, we should take :
S(L) = percentage of share allocated at length L.
C(L) = number of chain of length L found by all the pool miners.
M = block value in XPM

If a miner found F chain of length L he will gain for this length :
G(L) = M*F(L)*S(L)/C(L)
Your model is nice, but it's still discrete; to be reliable, share value need to be continuous as proof of work and diff are in primecoin network. That was my previous point. I give an example

Given a difficulty d
Let's call M(d) the value of a submitted share at difficulty d
Let's also call Dc the current diff and S the share value of a Dc-lenght chain

M(Dc)=S

In my previous post I stated M(Dc)=S as my reference share for all the other chain submitted. The share that worth 100%, and then calibrate reward system (M(d)) on this 100%-share with an exponential function. Let's call c the calibrated exponential function such as c(Dc)=1.

We therefore have M(Dc)= S . 1 = S . (c(Dc))

For example saying we accept share of [Dc-3] if we found S to be worth 2,5 XPM at diff 9.75 and choose a calibration of 1% for a 6.75-chain, 10% for 7.75-chain, 50% for a 8.75-chain, we have:

M(Dc=9.75) = 2,5  
M(8.75)      = 2.5 * 50%
M(7.75)      = 2.5 * 10%
M(6.75)      = 2.5 * 1%

That was my point.

But S is also function of total chains accepted during a round. If we call R the network block reward and Ci, each of these chains therefore we have to calculate S such as sum of all Ci weighted by internal reward percentage equal R.

That was my first idea of a more realistic reward for XPM pool. But I still think that others could bring something better  Grin


SlyWax
Sr. Member
****
Offline Offline

Activity: 248
Merit: 251



View Profile
August 14, 2013, 06:38:57 AM
Last edit: August 14, 2013, 06:52:03 AM by SlyWax
 #27


You cant give 100% reward to someone, that would mean the others won't get anything.
Or I didn't get from what you are taking your 100% ...

What I meant by 100% reward is share value of an exactly diff matching submitted chain.

Still don't get it sorry, but may be it's because you are referring to your way of calculation.

Anyway, the reward should try to match a % of the chain/day that the miner have, if this indicator is proven to be reliable.
But since chain/day cannot be used as a prof of work, you will have to finely tune the repartition of the shares.
chain/day is probably a deterministic model, the  I could look at Sunny code and implement it on pool side I think. But as it's not accurate, does it worth it ?

I don't think so, but it can be used to see if the reward system is fair for small miners.

if we allocate different value for each length, we should take :
S(L) = percentage of share allocated at length L.
C(L) = number of chain of length L found by all the pool miners.
M = block value in XPM

If a miner found F chain of length L he will gain for this length :
G(L) = M*F(L)*S(L)/C(L)
Your model is nice, but it's still discrete; to be reliable, share value need to be continuous as proof of work and diff are in primecoin network. That was my previous point.

No the difficulty been continuous is because we need it to be like that so it can be increased/decreased continuously.
But it's merely an artefact that work by accepting only a % of the chains at right length.
But the effort to calculate it is the same so it should be rewarded the same.

.../
But S is also function of total chains accepted during a round. If we call R the network block reward and Ci, each of these chains therefore we have to calculate S such as sum of all Ci weighted by internal reward percentage equal R.
/...

In my formula M is the network block reward and is equal to the sum of all weighted shares, by design.

As a side note, I would like to emphasis that in a fair-play situation, you should reward more the lower chain length (globally), so that small miners are taken into account.
Big miner won't be harmed, because they also mine a proportionally high number of smaller chain too.

May be I should write it this way :

G(L) = M*S(L) * F(L)/C(L)

With M*S(L) being the allocated XPM for length L,
and F(L)/C(L) being the ratio the miner got for length L.
bcp19
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500



View Profile
August 19, 2013, 10:32:14 PM
 #28

The big problem for making pool is shares check....
Example: If you mine 9-er chain and submit 6-er chains as share you'll get about 20 6-er chains in a hour.
Exactly! A miner properly optimized for short chains (to get the best possible reward from pool) would have low performance on 9+ chains. Sort of withholding attack from pool's point of view.
Looks like someone was stupid enough to make one of these... Ypool has come out with new share rewards:

6-chains are now worth .000976
7-chains are now worth .03125
8-chains are now worth 1
9-chains are now worth 32
10-chains are now worth 1024

God you gotta love fools and their stupidity and greed.  Ya just F'd yourselves.

I do not suffer fools gladly... "Captain!  We're surrounded!"
I embrace my inner Kool-Aid.
cryptrol
Hero Member
*****
Offline Offline

Activity: 637
Merit: 500


View Profile
January 22, 2014, 10:07:25 AM
 #29

Hi all,
I finally went with Java and almost finished a getwork pool proxy that I'll re-use to implement getblocktemplate and a first draft of a stratum-like protocol.
The proxy currently act as a blank pool on top of primecoind daemon, so no reward scheme implemented at all. Therefore all "workers" point to the proxy server address:port and payments are madeto XPM address given at a JSON payment config file.
It will be possible to configure many addresses with percentage of reward associated. Default is equivalent reward for all addresses.
I currently polish/refactor proxy server and look into stratum code to "fork" it. Reward system will come next, but probably not released with proxy server which I intent to keep simple as stratum-server is.

Sorry for being a necromancer with this thread but I was looking for some open source primecoin pool software and can't find any.
Did you ever release anything ? If not does anyone know where can I find it ?
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!