PeerCoinTalk - PeerCoin (PPC) & PrimeCoin (XPM)
Primecoin (XPM) => Mining Primecoin => Topic started by: xolokram on September 04, 2013, 09:38:04 am
-
Hi,
this is the official announcement for our Primecoin mining pool www.beeeeer.org (http://www.beeeeer.org)
As of writing this, ypool is not the only Primecoin pool any longer. ;)
for technical issues/questions: please use this thread (http://ppcointalk.org/index.php?topic=501.0)
this thread here is proposed for general discussion
Some stats/features:
- adjustable pool fee (per miner, default: 3%)
- no registration needed, username is your primecoin-payout-address
- beta testing phase (we'll work on every little bug/problem ASAP)
- custom protocol & miner (based on mikaelh's high-performance client)
- your payouts are executed, when you reach at least 3.01 XPMs
- CPPSRB-based payout system, you're paid per share, current share values are shown on the main page
- high end visual stunning plain-text web interface
ToDo:
- [MINER] config file support
- [POOL] better web interface
- [POOL] stats ... lots of stats!!
- [POOL] web-interface: link to the miner binaries (when everything is ready/stable)
- [M&P] 'xpt' protocol
Link:
www.beeeeer.org (http://www.beeeeer.org)
Client / Miner:
linux / bitbucket: source (https://bitbucket.org/thbaumbach/primecoin-hp)
linux / github: source (https://github.com/thbaumbach/primecoin)
windows binary: 'xolominer' v0.8 (32&64bit) (http://www.mediafire.com/download/473rshiav08074t/primeminer_v08_rc1.zip) (we do not recommend any other source for binaries, be careful!!)
mac user: see this post (http://ppcointalk.org/index.php?topic=501.msg4037#msg4037)
pool 'mining' addresses:
EU: 176.34.128.129 (port: 1337)
US: 54.200.248.75 (port: 1337)
ASIA: 54.251.179.44 (port: 1337)
(payout is independent from the used pool, choose the one near your location)
usage:
primeminer -pooluser=[xpm-payout-address] -poolip=[choose-from-above] -poolport=1337 -genproclimit=[threads-to-use] -poolpassword=[some-random-password-for-protection*]
optional: -minerid=[0 - 65000] -poolfee=[1 - 100 (in %), default: 3%]
* = it should be the same on all your miners
jhPrimeminer & original primecoin client are not supported currently!
compilation:
linux: make -f makefile.unix primeminer
mingw: make -f makefile.mingw primeminer.exe
mingw64: make -f makefile.mingw64 primeminer.exe
osx: make -f makefile.osx primeminer (no support from my side as i don't have a suitable test environment)
solaris: pls edit makefile on your own, I dont have a suitable test environment
you'll need the following libraries/tools installed: g++ libboost-all-dev libdb++-dev build-essential libgmp-dev libssl-dev
(please be aware that the names of these libraries can differ depending on your linux distribution)
FAQ:
We are not responsible for any damage to your computer system or data with our provided
service and software and in no event will we be responsible for any consequential, incidental,
or indirect damages arising out of the use or inability to use our service or software.
Any known issues?
High workload during night times cause communication delay on the server side (this leads to a higher amount of rejects), we're working on this.
Why 'beeeeer.org'?
Everybody loves beer, that's why. (Ok, almost everybody)
Has the server crashed again?
If the status page isn't available: yup - something really bad happened. We're still in beta/testing phase, don't panic, everything will be ok!!
- xolokram, glhf
ps. yes, i shamelessly copied parts of the ypool announcement ;)
pps. props to mikaelh, sunnyking & fuzzybear for their work
ppps. did i miss something?
- [RESERVED]
- Nice i'll have to give this a try tonight, I'll make the thread sticky for you :)
- I'm in!
- Wow, that was fast, thank you.
btw. the jhPrimeminer should work too (!!!!!!!!!)
but mumus version of jhPrimeminer has to be fixed first, there's a bug in his 'getwork' protocol code (I will add the .diff file later, for his code)
- xolokram
ps. quirlorimbo is my "partner-in-crime"
pps. added the windows binary & 'getwork' fix for mumus' jhPrimeminer (v7.1) to the first post
- thanks..
btw .. you cannot use -u and -p:
-------------------
terminate called after throwing an instance of 'std::runtime_error'
what(): Add the parameter -pooluser=<user> and -poolpassword=<password>
-------------------
use -pooluser= and -poolpassword= instead.
Is there a chance you publish the sources for the server?
- yeah, you're right --- stupid copy&paste mistake --- I will correct that.
atm I don't plan to publish the source code for the server, sorry.
- xolokram
- Can you explain what i see on your website in /user/#id!?
-
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
- Um for those of us who don't regularly patch things with .diff files, how the hell do we fix the jhprimeminer with the .diff file?
Also nice to see a new pool try to challenge ypool's reign. Though I am kinda upset over the 3 xpm min, it should be 2 in my opinion.
But really I am really sad that I can't use any of these (https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM) to mine due to the getwork issue, as they are vastly superior to the previous versions IE v7.1 and below
-
Um for those of us who don't regularly patch things with .diff files, how the hell do we fix the jhprimeminer with the .diff file?
Also nice to see a new pool try to challenge ypool's reign. Though I am kinda upset over the 3 xpm min, it should be 2 in my opinion.
But really I am really sad that I can't use any of these (https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM) to mine due to the getwork issue, as they are vastly superior to the previous versions IE v7.1 and below
Ask someone nicely who has a working compilation-environment for jhPrimeminer or do a patch/pull request? Or maybe configure your own environment? Or use the other client?
I'm mostly working in Linux, that's why I concentrate on the *nix/mingw software. jhPrimeminer support and the quick look into mumus' client source code was not my main focus, I just wanted to fix the 'getwork' protocol issue ASAP.
The xpm-payout-barrier is something we can discuss here
Since payouts will be automatically executed I think this barrier shouldnt be too low to keep the xpm-network-transaction-fee on an acceptable level.
Yeah, challenging ypool is quite tough. Does someone know what shares yPool is counting on their block stats page (http://ypool.net/stats.php) ?? (5,6,7,8,9... chains or 6,7,8,9... chains?)
- xolokram
ps. I made a pull request for mumus jhPrimeminer for the 'getwork' protocol issue, let's see what he thinks about it...
- Sorry I did not mean to be rude, just I REALLY want to mine at your pool but if I can't use the latest jhprimeminer I am really just losing out on about half of my hashing power (yes the newer versions are that much better)
So in summary, I want to mine really bad at your pool even if it is less profitable, I just don't want to mine there if it can't do any good.
- no problem.
I just don't wanted to offer my compilation of jhPrimeminer here because I configured my Visual Studio environment (which is needed for jhPrimeminer) very dirty --- this means it's not really optimized (regarding: used libs / compile options / AVX suppot etc. pp.). I just wanted to check if the miner gets work from the pool and is doing something useful. I hope "hg5fm" will offer a fixed version of the "mumus" miner ASAP, or maybe the creator of the "RdB" version (never heard of that before) will fix it (my pull request is already on github).
I may look into the configuration for jhPrimeminer and release a fixed version on my own, when I got time for this. Atm the pool & my miner are the first priority.
- xolokram
ps. pool restarted due to smaller code changes
- Nice. Just had this on my screen
xxxx147693d1c235cca3b!!
Target: 09.dbfc73
Chain: TWN06.aa17xx
[WORKER] share submitted -> SHARE
So was it a 6-chain share? Does it mean I get the same payout for finding a 6-chain and a 9-chain?
-
Nice. Just had this on my screen
xxxx147693d1c235cca3b!!
Target: 09.dbfc73
Chain: TWN06.aa17xx
[WORKER] share submitted -> SHARE
So was it a 6-chain share? Does it mean I get the same payout for finding a 6-chain and a 9-chain?
yup, you've found a 6-chain share
the console output tells you:
- the difficulty aka target length - needed to 'identify' a block (this value will change if a new block has been found on the network and your client is informed about that (every ~60 seconds))
- what you've found: Chain: TWN06.aa17xx
which decodes into <kind><length>.<fractional length>
where <kind> can be: 1CC, 2CC or TWN (describes what kind of primechain you've found)
length is most important as it will tell you if it's a 6,7,8 or 9-chain share (atm they have the same value regarding the payout, but maybe we will change that later for future blocks)
- xolokram
- The probablity of finding an n+1 chain is about 10 times smaller than finding an n chain. So giving all chains the same weight you are inviting shorter chains -- people will mod the miner to find and submit tons of shorter chains. That is why ypool changed its policy at http://community.ypool.net/index.php?page=Thread&threadID=63 to give more weight to the longer chains. Then payout is calculated according to weighted chains (share) counts.
But I think ypool is over doing it. Now it's really the 9 chains that really count. It feels a little like soloing.
- Would be cool if your pool calculated the weight of the shares based on the actual difficulty of each one precisely. You could wait until after a block to do the calculations if you don't want to have to worry about demanding processing, plus you got like 2999 blocks before it needs to be calculated anyways lol
- i'm aware of that. i think - like mhps - ypool's ratio is too aggressive. after we'll find the first block we'll have ~53 hours before confirmations are through and the first payout (which i guess will be quite uninteresting since it will be hard for someone to reach the 3 XPMs) will be executed. we can figure out a ratio until then.
atm i dont recommend to use the jhPrimeminer, there's a problem with the share submission code too, i will check the code. please use my miner instead.
- xolokram
- how about 64 bit client version ... seems it will be more fast or i am wrong?
- This seems really great. If this turns out alright I could help with the website stuff.
- i cannot mine using your miner unfortunately :'(
i'm trying your miner on my core i5-2450M sandybridge , i've compiled it exactly like hp10 with only difference that i made it using make -f make.unix primeminer , it built successfully , but doesn't work , here's how i execute it :
primeminer -pooluser=XXXXXXXXXXXXXXXXXXX -poolpassword=0 -poolip=beeeeer.org -genproclimit=4
here's what i get :
http://pastebin.com/QybCxJ99
what should i do ?
PS : i did the same on my fedora machine and it's working just fine !!
PPS : i forgot to tell you that my computer is running ubuntu 13.10 beta AMD 64
- is there a way to get performance metrics ?
-
is there a way to get performance metrics ?
http://www.beeeeer.org/user/<your address> will tell how many chains you have found. You can time it can get chains/hour.
- Hello
@ig0tik3d:
yup, good idea. i will look into that as i have to configure/install mingw for 64bit and build all the libs again.
i'm currently not on a windows machine, please be patient.
@super3:
ok. atm i think the minimal website is sufficient (form-follows-function ;) )
thx anyway, we'll come back to the offer, when everything works.
@manawenuz:
looks like an uncommon error, let's debug, can you change the following line of makefile.unix:
DEBUGFLAGS=
into
DEBUGFLAGS=-g
and (install gdb (`sudo apt-get install gdb`) and) run
gdb --args primeminer -pooluser=XXXXXXXXXXXXXXXXXXX -poolpassword=0 -poolip=beeeeer.org -genproclimit=1
there will be a prompt, type in "run", wait for it to crash, then type in "bt", and PM me the console output of gdb
+
the miner should give you an output like this every minute:
2001-01-01 05:11:16 primemeter 6275420 prime/h 149684368 test/h 720 5-chains/h 1.643551 chain/d
5-chains/hour and chains/day and the old prime/hour (calculate primes/s) should give you a hint about your performance
@all:
gentlemen, we've found a block: http://www.beeeeer.org/block/151881 with ~33k shares
payout will be executed in ~50 hours. i think i will execute it manually to monitor the whole process
everything has to start small, right? :) gj
- xolokram
ps. pool restart incoming (minor code changes/bugfixes)
-
jhPrimeminer should work too, but mumus version has a bug in the 'getwork'-protocol (refering v7.1, see attachment for fix)
what port i need set to connect to pool with jhPrimeminer?
-
PORT 9912
now with 100% support for the blind (and deaf)
BUT i have to fix something with the share submission code @pool first to work with jhprimeminer properly
otherwise your shares will end in nirvana, sorry *fixed*
- hey there .. your miner is great .. expecting 0.7XPM from first block ..
I have a short feature request:
could you make the miner read the config stuff from a file instead of prameters?
Thanks
- hi
thank you. I will write down the feature request in the todo-list on OP.
FYI there's still the payout barrier of 3 XPMs you'll have to reach.
good news:
I fixed the share submission part of the pool to accept work from the jhPrimeminer. Don't get confused, when jhPrimeminer tells you, that the server rejected the share (just check you personal stats on the pool info page and you'll see details about your submitted shares). Be aware, that mumus edition (why is it called mumus?) of jhPrimeminer v7.x still has a bug in the 'getwork' protocol, you'll need to fix the bug in the source code first (see OP for more information or wait until somebody will fix this for you). All other versions not based on mumus v7.x ---should--- work properly.
reminder: i'm not your personal tech support for jhPrimeminer (Quirlorimbo is your tech support - lol, he'll hate me for this!)
- xolokram
- have an other question
Can I mine on the same address using different machines? or will there be a collision?
- you can mine with different machines on the same address! no problem, i do it as well.
- anybody can compile binary with fix mumus version jhPrimeminer for win64?
-
why is it called mumus
Because mumus on bitcointalk.org forked the official jhPrimeminer and greatly improved it. Mumus was subsequently improved by rdebourbon to make the "rdb" version, which at some point was improved by cabin. I think I got it right. It's interesting that you don't seem to know much about all these and developed the your miner based on mikaelh's miner.
By the way, as a minor interface improvement request -- I don't think anyone is interested in seeing the long block string for every get_work. The miner only needs to show that the threads are alive, what the performence is, and shares are found.
- A GUI miner for this would only take a few hours. Do you think you can implement multiple workers for the same address?
-
Just found this on http://www.beeeeer.org/block/151881 :
"AeUD8XG5Hb2QWghuHAQ94JPEJhSvatDnEM": {
"0": 19,
"6": 1109,
"7": 91,
"8": 9,
"9": 1,
"151881": 1,
"-6": 1
},
whats the 151881 telling us? a chain of length 151881????????
-
Just found this on http://www.beeeeer.org/block/151881 :
"AeUD8XG5Hb2QWghuHAQ94JPEJhSvatDnEM": {
"0": 19,
"6": 1109,
"7": 91,
"8": 9,
"9": 1,
"151881": 1,
"-6": 1
},
whats the 151881 telling us? a chain of length 151881????????
That is block number in the block chain. Looking at the shares you made basically you hit a block by the first 9-chain you submitted. That is a 1 in 7 chance at current difficulty. Very good luck! :D
btw you can also see that n length chains are ~10 times rarer than n-1 length. If anyone has a lot of shares and the shares have significantly different ratios s/he is probably gaming the system.
- the blockheight number (>100000) in the shares indicates that "AeUD8XG5H[...]JhSvatDnEM" has found the block (aka his/her share was responsible for hitting the target length)
@mhps:
I didn't really used ypool alot (just tested it once). That's why jhPrimeminer was never really an option for me (along the fact that it's not multi-platform). I solomined alot (with mikaelh's client) and then started someday working on my own pool software. Quirlorimbo was the guy who convinced me of trying to add support for jhPrimeminer for the pool (kindof).
+
thanks for the clarification on their versions. less verbose output? yeah, let's see :)
@super3:
you can let multiple miner mine for the same address!!
-
the blockheight number (>100000) in the shares indicates that "AeUD8XG5H[...]JhSvatDnEM" has found the block (aka his/her share was responsible for hitting the target length)
@mhps:
I didn't really used ypool alot (just tested it once). That's why jhPrimeminer was never really an option for me (along the fact that it's not multi-platform). I solomined alot (with mikaelh's client) and then started someday working on my own pool software. Quirlorimbo was the guy who convinced me of trying to add support for jhPrimeminer for the pool (kindof).
+
thanks for the clarification on their versions. less verbose output? yeah, let's see :)
@super3:
you can let multiple miner mine for the same address!!
Yes, I know. But how do I tell how each miner is doing? For example if one was just producing stales or was down I couldn't really tell that because all the miner stats would be grouped.
- Ah ok, I see what you mean. Mh, unless you dont want to use multiple addresses, which isn't really a good idea, you just can't.
I will think about it, maybe I will use the password field for this. I will work up something.
there need to be way more statistics on the web front anyway --- because everybody loves statistics, right?
- xolokram
ps. arrrgh, i hate the github web interface :)
pps. block #2 (http://www.beeeeer.org/block/152782) with 27630 shares
- another block just dropped in
http://www.beeeeer.org/block/152782
around 40 addresses with shares ..
hopefully gonna be alot more soon ...
- but not -too- fast; i have to get a feeling about the stability of every component of the pool to find bottlenecks early on. ;D
- xolokram
ps. updated OP, minor changes
- @xolokram , the same happened on my paravirtualized Cent6 VM on Cent5
http://pastebin.com/PrKYf5NB
and there's the log you've requested .
my ovz vm running Fedora is doing alright though ,
any thoughts?
- after it crashs, type "bt" into the gdb console, and send me the output
and you compiled it with the "-g" parameter, right?
(use Private Messages to answer, we don't want to pollute the thread with stuff like this)
- xolokram
ps. i have to go now, i'll be back in a few hours, stay frosty
- i've recompiled it with -g parameter , i've figured out what the problem is !!!
it's because of my internet , they have deep packet inspection in place , and they drop your packets !!!
i've made a vpn and it started to mine !!!
- Decided to give this a try today to see how it compares to yPool.
Looks like the first XPM being credited towards my address are from the 3rd block that the pool has discovered to date.
http://www.beeeeer.org/block/153134 (http://www.beeeeer.org/block/153134)
The Primeminer v01 is looking fairly stable for a Beta. I'll leave it running through the night and see if it survives to the morning. I've been having to run the yPool miner in a batch file that restarts it every hour or so I'll see if this one looks like it will need the same treatment or not.
May I suggest a link to the Miner download on the main page of the Beeeeer.org website.
- block #4
i compiled the 64bit version of the miner for windows (what a pain, i should clean up the code and remove the old lib dependencies!). it's faster now (on 64bit machines). see OP.
- xolokram >:(
-
Ah ok, I see what you mean. Mh, unless you dont want to use multiple addresses, which isn't really a good idea, you just can't.
I will think about it, maybe I will use the password field for this. I will work up something.
there need to be way more statistics on the web front anyway --- because everybody loves statistics, right?
- xolokram
ps. arrrgh, i hate the github web interface :)
pps. block #2 (http://www.beeeeer.org/block/152782) with 27630 shares
Yeah the passworld field will work just fine. Just each password is a unique miner, or they can just use numbers or something.
- Great Job!!
I just connected my first miner to the pool, I´m looking forward to compile a Linux binary today if I can.
Good luck!
- Started mining last night. Win 7 64 sp1, experienced the reconnection bug.
Gonna have to make auto restart script.
Major props, ypool sucks.
- I can`t understand how to mine on Ubuntu 12\13? Can somebody make a detailed instruction for noob? :)
- I guess I´m missing something.
Pulled form both sources but my compilation fails with the following errors:
In file included from main.cpp:16:
prime.h:10:17: warning: gmp.h: No existe el fichero o el directorio -> (this means file not found in spanish)
prime.h:11:19: warning: gmpxx.h: No existe el fichero o el directorio
In file included from main.cpp:16:
prime.h:51: error: ´mpz_class´ does not name a type
prime.h:52: error: ´mpz_class´ does not name a type
prime.h:53: error: ´mpz_class´ does not name a type
prime.h:54: error: ´mpz_class´ does not name a type
prime.h:70: error: ´mpz_class´ has not been declared
prime.h:75: error: variable or field ´PrimorialAt´ declared void
prime.h:75: error: ´mpz_class´ was not declared in this scope
prime.h:75: error: ´bn´was not declared in this scope
prime.h:75: error: ´mpz_class´ was not declared in this scope
prime.h:75: error: ´mpzPrimorial´was not declared in this scope
In file included from main.cpp:16:
prime.h:129: error: ´mpz_class´ has not been declared
prime.h:129: error: ´mpz_class´ has not been declared
In file included from main.cpp:16:
prime.h:163: error: ´mpz_class´ does not name a type
prime.h:164: error: ´mpz_class´ does not name a type
prime.h:206: error: ´mpz_class´ has not been declared
prime.h:206: error: ´mpz_class´ has not been declared
prime.h: In constructor ´CSieveOfEratosthenes::CSieveOfEratosthenes(unsigned int, unsigned int, unsigned int, unsigned int, int&, int&, CBlockIndex*)´:
prime.h:212: error: ´class CSieveOfEratosthenes´ has no member named ´mpzHash´
prime.h:213: error: ´class CSieveOfEratosthenes´ has no member named ´mpzFixedMultiplier´
prime.h: At global scope:
prime.h:412: error: variable or field ´mpz_set_uint256´ declared void
prime.h:412: error: ´mpz_t´ was not declared in this scope
prime.h:412: error: expected primary-expression before ´&´ token
prime.h:412: error: ´u´ was not declared in this scope
main.cpp: In function ´void BitcoinMiner(CWallet*, CBlockProvider*, unsigned int)´:
main.cpp:4646: error: ´mpz_class´ was not declared in this scope
main.cpp:4646: error: expected ´;´ before ´mpzHash´
main.cpp:4660: error: ´mpzHash´ was not declared in this scope
main.cpp:4660: error: ´mpz_set_uint256´ was not declared in this scope
main.cpp:4661: error: ´mpz_divisible_ui_p´ was not declared in this scope
main.cpp:4674: error: expected ´;´ before ´mpzPrimorial´
main.cpp:4678: error: ´mpzPrimorial´ was not declared in this scope
main.cpp:4687: error: expected ´;´ before ´mpzMultiplierMin´
main.cpp:4688: error: ´mpzMultiplierMin´ was not declared in this scope
main.cpp:4694: error: expected ´;´ before ´mpzFixedMultiplier´
main.cpp:4696: error: ´mpzFixedMultiplier´ was not declared in this scope
main.cpp:4698: error: ´mpzFixedMultiplier´ was not declared in this scope
main.cpp:4703: error: ´mpzFixedMultiplier´ was not declared in this scope
main.cpp:4703: error: ´mpzHash´ was not declared in this scope
main.cpp:4852: error: ´mpzHash´ was not declared in this scope
main.cpp:4852: error: ´mpz_set_uint256´ was not declared in this scope
main.cpp:4853: error: ´mpz_divisible_ui_p´ was not declared in this scope
prime.h: At global scope:
prime.h:19: warning: ´thread_num_max´ defined but not used
make: *** [obj/main.o] Error 1
I used a Debian Squeeze 64bit for this compilation (where I have successfully used hp10).
cheers!
UPDATE: used Ubuntu 13 and the compilation worked. I´ll check back on debian what I´m doing wrong.
- hi
block #12 atm :D gj
tomorrow will be the (not too interesting) payout for block #1 (aka 151881). as i said before, i will execute the first payouts manually. if everything works fine, i will setup a script for automatic payouts. we should discuss the share value ratios for future blocks here.
@Grekk:
[from a (VERY) old howto i wrote someday] try:
> sudo apt-get update && sudo apt-get update && sudo apt-get upgrade
> sudo apt-get install git g++ libboost-all-dev libdb++-dev build-essential libgmp-dev libssl-dev
> git clone https://bitbucket.org/thbaumbach/primecoin-hp.git
> cd primecoin-hp/src
> make -j 3 -f makefile.unix primeminer
@pt0x:
you have to install the GMP library first. in debian64 that should be (as root): apt-get install lib64gmp3 lib64gmp3-dev lib64gmpxx4
check compile instructions for mikaelh's client of primecoin (here? and on bitcointalk?) if you want to know more
- xolokram
-
@Grekk:
[from a (VERY) old howto i wrote someday] try:
> sudo apt-get update && sudo apt-get update && sudo apt-get upgrade
> sudo apt-get install git g++ libboost-all-dev libdb++-dev build-essential libgmp-dev libssl-dev
> git clone https://bitbucket.org/thbaumbach/primecoin-hp.git
> cd primecoin-hp/src
> make -j 3 -f makefile.unix primeminer
Thanks, I joined)
Is this normal? Appears in almost every request to new data.
no response from server
[REQUEST] reply empty / long-poll timeout (re-polling!)
And the question... how to change the settings?
GeneratePrimeTable() : setting nSieveExtensions = 6, nSievePercentage = 10, nSieveSize = 1000000
GeneratePrimeTable() : prime table [1, 1000000] generated with 78498 primes
long polling header found
- the "no response from server" / "empty reply" message is part of the long polling feature, it's just a verbose output
this message should appear only every minute (maximum)
if it happens more often, something's wrong with the connecten (on server or client side)
-sieveextensions
-sievepercentage
-sievesize
are the parameters for mining
-
the "no response from server" / "empty reply" message is part of the long polling feature, it's just a verbose output
this message should appear only every minute (maximum)
if it happens more often, something's wrong with the connecten (on server or client side)
-sieveextensions
-sievepercentage
-sievesize
are the parameters for mining
Xolokram thanks for the help! you are a hero!.
I was able to compile on debian successfully (my bad), on the other hand I started to have a lot of rejected shares an then I discovered that besides port 9912, TCP port 9999 (outgoing) It´s also needed for the long polling feature to work right and avoid so many rejected shares.
Like you I was disappointed that I couldn't find a native pool miner for Linux and other OSs. Your implementation look very solid.
If you need help to translate the site to Spanish or an extra hand with anything, I'm willing to help.
Good luck!!
-
the "no response from server" / "empty reply" message is part of the long polling feature, it's just a verbose output
this message should appear only every minute (maximum)
if it happens more often, something's wrong with the connecten (on server or client side)
may be pool is too busy?
-
the "no response from server" / "empty reply" message is part of the long polling feature, it's just a verbose output
this message should appear only every minute (maximum)
if it happens more often, something's wrong with the connecten (on server or client side)
may be pool is too busy?
I'm starting to see the same output on my miners
- any chances on releasing the source code for your back end? I'd be interested in doing some developing on this project, especially if it became open source. This would greatly reduce the ypool monopoly.
-
we should discuss the share value ratios for future blocks here.
From the looks of the stats, each step up in chain length comes with a tenfold decrease in the number found.
So if you find 5000 6-chains shares, it's likely that you will find 500 7-chains, 50 8-chains, and only 5 9-chains.
Taking that into consideration share value should look something like this:
0.01 per 6-chain
0.1 per 7-chain
1 per 8 chain
10 per 9-chain
etc.
What I can't see from looking at the stats is who the block finder is, and what their chain counts are. Perhaps you should take the chain counts from the block finders and use those to determine more accurate ratios.
I would like to see some sort of bonus for the block finder, maybe 5% of the total block reward. After all regardless of the amount of work any of us do, we only get a payout when someone gets lucky and finds a block. I like the idea of getting paid for getting lucky ;)
- hi,
first payout is through: http://www.beeeeer.org/payouts
explanation about what you see:
- info about the current block reward and previous rewards and xpm-transaction-fees
- "prev" will contain a list of waiting payouts from previous blocks (this is empty for the first block)
- "add" contains payouts for the current block
- "payout" is the actual payout for this block which will be executed (remember the current 3 XPM payout barrier!)
- "next" contains the payout information for the next block
@pt0x:
port 9999 is the port for the long polling. It needs to be reachable for your client, otherwise alot of rejects will appear.
@Grekk:
Server isn't to busy right now, there are still recources left and 500+ connections should be such a big problem.
If it would've been a problem on the server side, the rejects for everyone would go up. But atm it looks like that this is a client side problem as there are some people in the block-share-details who have <1% rejects/stales.
@pt0x & Grekk:
do the "no response from server" / "empty reply" happen more often that once every minute?? windows? linux?
restart the client and does it happen again? if so, then it's a serious problem. if not, then you lost the connection to the server and the -stupid- reconnection bug appeared on your client side (i mentioned it on the OP, i thought it's only happening on the windows client).
@zeta:
at the moment i'm not planning to release the source code. maybe in the future, i will think about it.
@AlexMc:
yeah, that's a pretty straight-forward ratio for the share values. block finder is the one where the share details contain a value equal to the block height (>100000, check "...vatDnEM" on block 151881). i will think about the rewards. :)
- xolokram
ps. i'm in a hurry right now, if i'm missing something tell me ;) i will be back later today
pps. block 155355 (http://www.beeeeer.org/block/155355) found after ~250 shares :o
- You need to add the time found each block.
How to view the total number of coins produced by me?
-
- "next" contains the payout information for the next block
Only on the 3rd place??? >:( I have to add 2 additional miners ;)
- BTW I was wondering is the pool currently proportional? IE I mean are the shares/values on a per block basis or are they carrier through like PPLNS? In my opinion PPLNS is more fair to everyone especially with short rounds for example just because you didnt generate a crappy 6 share in a 250 share block doesnt mean you havent been helping a lot in previous rounds. Essentially it helps to even out the randomness and make it more fair for everyone contributing and not just those who happen to get lucky. I prefer a 24 hour based PPLNS where the number of time between rounds is 24 hours. Though personally my favourite payout system is Double Geometric AKA DGM (https://bitcointalk.org/index.php?topic=39497.0). It would be cool to see you implement something like that for your pool, would help it stand out not just from Ypool but also for the future if any other pools come about.
- Hi,
Thx for this great pool, with no mail and no account ;)
Just a quick question.
I can mine from 2 different servers, should I use the same -pooluser=[xpm-payout-address] or 2 differents?
usage:
primeminer -pooluser=[xpm-payout-address] -poolpassword=0 -poolip=beeeeer.org -poolport=9912 -genproclimit=[threads-to-use]
-
BTW I was wondering is the pool currently proportional? IE I mean are the shares/values on a per block basis or are they carrier through like PPLNS? In my opinion PPLNS is more fair to everyone especially with short rounds for example just because you didnt generate a crappy 6 share in a 250 share block doesnt mean you havent been helping a lot in previous rounds. Essentially it helps to even out the randomness and make it more fair for everyone contributing and not just those who happen to get lucky. I prefer a 24 hour based PPLNS where the number of time between rounds is 24 hours. Though personally my favourite payout system is Double Geometric AKA DGM (https://bitcointalk.org/index.php?topic=39497.0). It would be cool to see you implement something like that for your pool, would help it stand out not just from Ypool but also for the future if any other pools come about.
Now everything is working well and the payment too.
Except connecting to the server, the server rejects the connection constantly. You need a different server.
-
Hi,
Thx for this great pool, with no mail and no account ;)
Just a quick question.
I can mine from 2 different servers, should I use the same -pooluser=[xpm-payout-address] or 2 differents?
usage:
primeminer -pooluser=[xpm-payout-address] -poolpassword=0 -poolip=beeeeer.org -poolport=9912 -genproclimit=[threads-to-use]
You may use same wallet.
-
...
[...]
Except connecting to the server, the server rejects the connection constantly. You need a different server.
like i said earlier, it seems to be a problem of the miner / mining machine, not the server. some of the the clients produce <1% rejects, while other ~10% (check the share details for the blocks). first i thought this is a windows problem, but it looks like some linux system suffer from this too. i will look into the client code the next days and hopefully fix this / find a workaround. stability & payouts are the main focus at the moment.
i checked some of my debug logs and it looks like 2 clients (2 out of ~30) connect to port 9912 properly, but are not connecting to port 9999 (long poll feature), thus they will have problems with rejected shares (aka "no response from server" aka "empty reply").
@linkou:
you can use the same xpm address for seperate miners.
@theprofileth:
atm it's on a per-block-basis. i will add this to the todo list.
@grekk:
you can check your current payout-balance in every payout (the "next" field gives you a cumulative value for all your shares (from the last payout to the current payout)).
- xolokram
-
atm it's on a per-block-basis. i will add this to the todo list.
- xolokram
;D
Does that mean you are considering doing DGM!
Also when do you plan to release this to the masses IE put it on the bitcointalk alt coin forum?
- i have to go through the dirty details first, before i decide on that issue. but it sounds good.
this (https://bitcointalk.org/index.php?topic=104664.msg1146110#msg1146110) can be helpful <- reminder to myself
i dont really like the bitcointalk alt coin forum, too much "wine", trolls & unthankful bashing --- but i'm aware of the promotional potential of btctalk
- xolokram
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
-
I would like to see some sort of bonus for the block finder, maybe 5% of the total block reward. After all regardless of the amount of work any of us do, we only get a payout when someone gets lucky and finds a block. I like the idea of getting paid for getting lucky ;)
I don't agree with prizes of any kind from the pool. Satoshi Dice is about prizes for lucky boys, pools should be just the opposite: to minimize lucky as much as possible, to distribute earnings uniformly on a work contribution basis. The more is luck rewarded by a pool, the more it will be close to solo mining. If someone wants to be rewarded for being lucky he should do solo mining (or S. Dice).
- +1
I think a profitability calculator would be great. I'm mining src right now since I know exactly how much it'll net me per day.
I'd rather mine xpm on gpu at your pool but it isn't possible atm. Anyone got numbers for a single i7 Sandy?
-
With the same basis of thought, perhaps it is so not bad to give the same share value for chains of any length, in order to promote many small processors instead to promoting the big ones. I mean, the people who have huge computing power does not need a pool, so, the smaller the CPU the better should be going to a pool. But if the pool rewards more to the more lucky (again) it will be the same as rewarding more the big systems against the small systems.
Taking that into consideration share value should look something like this:
0.01 per 6-chain
0.1 per 7-chain
1 per 8 chain
10 per 9-chain
etc.
That is not good for the pool, the target of the pool must be to minimize variance for everybody, but a distribution of reward proportional to the inverse of probability of lenght will minimize variance of the bigger ones, letting more variance to the smaller ones.
I understand that a uniform distribution has the problem of promoting miners and tunning parameters to search just for small chains, and not searching for chains bigger than the difficulty (the only ones which are valid for block creation). So I propose to value shares proportional to its lenght. That is:
4 per 4-chain
5 per 5-chain
6 per 6-chain
7 per 7-chain
8 per 8 chain
9 per 9-chain
etc.
That will be enough for the miner and the developer to try to improve sieving and prime testing to find bigger chains. It is the opposite approach to yPool, who has disappointed most of the smaller contributors with its new sharing scheme. Now yPool is only worth for the more powerful computing systems, is it what you want?
-
Having problems with rejects, ~20% on most blocks. Tried restarting miner but I can't watch 7 machine screens 24/7. Is there anything else we can try to lower them?
For example, in the current block:
{
"0": 119,
"6": 541,
"7": 51,
"8": 6,
"-6": 2
}
even though none of miners are 'disconnected' (I watched them to see that they are all occasionally submitting shares).
(Unrelated: what is with some of the anti-robot questions when trying to post? "Who wrote the book 1984 (first and last name required)" what kind of question is that? Should I google it? :o)
- Pool is down?
- Pool is down!
something in the backend crashed,
/edit1: ok, back online, i have to find the cause now...
- feature request:
total number of blocks found on the frontpage, and maybe add the number of blocks found in the last 24 hrs next to it
- I got like 100% rejects for like the last couple blocks because of something (I think a disconnect)
Restarting obviously fixed the issue, but can someone please fix the reconnect issue with the miner as I don't like wasting time sending in worthless data and wasting pool resources.
- stupid question maybe but how come there are more than six decimal places in the payouts?
-
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.
-
I have a problem with the compilation miner in two machines
1st
rm -f libmemenv.a
ar -rs libmemenv.a helpers/memenv/memenv.o
ar: creating libmemenv.a
make[1]: Leaving directory `/root/primecoin-hp/src/leveldb'
[email protected]:~/primecoin-hp/src# top
when i try to start compiling the second time ..... get
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
make: *** [obj/main.o] Error 4
make: *** Waiting for unfinished jobs....
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
make: *** [obj/net.o] Error 4
2nd
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
make: *** [obj/main.o] Error 4
make: *** Waiting for unfinished jobs....
how to fix?
Thanks
- I like this, there's been a couple good suggestion on the last page, big +1 to the ones mentioning share value equal to chain lenght and the one that mentioned last blocks found in a 24hs period.
That should be enough to determine profitability easily.
Now we need more miners here.
- 12 threads here just joined :)
- server down again
- Damn just my luck only been mining here 30 minutes and servers down!
-
maybe that is why he mentioned "slow" :P
pps. i still think, that a slow growing userbase would be more vital
-
Damn just my luck only been mining here 30 minutes and servers down!
This is all your fault ;D
- In regards to boosting userbase, I think a thread like this one (an ANN thread) should be made at
https://bitcointalk.org/index.php?board=67.0
This pool has of course come up in comments in this thread (https://bitcointalk.org/index.php?topic=264115.0), but its not going to get as much attention as a new ANN thread.
- i guess server will be up again in 6 hours ...
pls respect the rl of xolokram :)
this why its called "beta" ;)
- Too bad it went down :( horever we had a nice progress so far.
- Well while it is down I guess I will put together a share value and try to implement the variable income based version of the DGM formula.
Shouldn't be too hard 8)
-
Well while it is down I guess I will put together a share value and try to implement the variable income based version of the DGM formula.
Shouldn't be too hard 8)
Sounds good man, I'm excited about this pool. Now if someone makes the gpu miner better (at least equal or slightly better than an i7) and integrate it to it after it's open sourced...
-
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?
-
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.
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.
- Where Хolokram?
-
Where Хolokram?
Apparently not servicing our every need. *cracks whip*
-
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 :-X
- xolokram
- thanks for your incredible work.
you tell us what went wrong in your backend?
-
@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
-
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.
- 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?
-
@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
-
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
-
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
- 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?
-
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
-
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 :)
-
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
These are my stats from the latest block:
"0": 296,
"6": 1538,
"7": 157,
"8": 13,
"9": 1,
"-6": 6,
"-7": 1
I'm only using Linux, as you can see I'm getting a lot of rejects. I doubled checked that I have port 9999 open and connections are being established but I still get the high count.
I guess the speed of my connection has something to do with this but maybe you could know another reason why this is happening.
I see that payments are being processed but I guess mine got held. The 3xpm threshold applies for the total amount of work done right? I thought it was calculated per block , however I have no problem waiting .
cheers!
-
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
These are my stats from the latest block:
"0": 296,
"6": 1538,
"7": 157,
"8": 13,
"9": 1,
"-6": 6,
"-7": 1
I'm only using Linux, as you can see I'm getting a lot of rejects. I doubled checked that I have port 9999 open and connections are being established but I still get the high count.
I guess the speed of my connection has something to do with this but maybe you could know another reason why this is happening.
I see that payments are being processed but I guess mine got held. The 3xpm threshold applies for the total amount of work done right? I thought it was calculated per block , however I have no problem waiting .
cheers!
Gosh how many cpu's you have there or are you using the new gpu miner?
- @pt0x:
do you see
"[MASTER] got_work"
in the console output (once every minute (roughly))
if not, something's wrong with the longpoll connection on your side.
@CoinBuzz:
looks like you have a problem with the Berkeley DB library. install it properly (via package manager) or compile it on your own.
- xolokram
- Thank you for the pool. It looks like you added a time(stamp) field to the block information, thank you :) makes mining my personal information easier (blocks/day, xpm per day etc).
Any chance of having that added to blocks prior to 157290? Not a big deal either way...
-
@pt0x:
do you see
"[MASTER] got_work"
in the console output (once every minute (roughly))
if not, something's wrong with the longpoll connection on your side.
:-[ I do see the message. I guess it’s my connection.
Looks like Stratum proxy will need a serious rewrite to work with your pool.
Thanks!
-
Gosh how many cpu's you have there or are you using the new gpu miner?
Connected to the pool: around 25. It's a mix of Xeons, i7, i5, Core 2 quad and Duos. I have GPU rigs but right now they are mining LTC.
-
Getwork() failed with error code 0
PushWorkResult failed :(
can someone call 911
it works again! :)
-
Getwork() failed with error code 0
PushWorkResult failed :(
can someone call 911
Pool it's down, just sit tight for a little bit.
- i'm already trying to check what happened. it's the same error like last night. looks like some nasty bug. don't panic.
- xolokram
ps. pool restarted, i'm digging through the log files...
pps. ok, i have a clue why it happens, but i have no smart/easy solution yet
-
i'm already trying to check what happened. it's the same error like last night. looks like some nasty bug. don't panic.
- xolokram
ps. pool restarted, i'm digging through the log files...
+1
- I cannot connect to the pool
-
I cannot connect to the pool
whats your problem?
-
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)
Oh lol my bad on the / instead of - yeah that is what I meant. I will fix that thanks.
V was supposed to be V = 10^(L-M) But I have to
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 you are missing a key idea behind this system, people can tune their software to submit a LOT more 6 chains than 7 or 8 and thus beat the system if they are not weighted proportionally as each chain up is in fact actually 10 times harder to find hence why this post was made before
we should discuss the share value ratios for future blocks here.
From the looks of the stats, each step up in chain length comes with a tenfold decrease in the number found.
So if you find 5000 6-chains shares, it's likely that you will find 500 7-chains, 50 8-chains, and only 5 9-chains.
Taking that into consideration share value should look something like this:
0.01 per 6-chain
0.1 per 7-chain
1 per 8 chain
10 per 9-chain
etc.
Also
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.
Hence the need for an M which allows you have a min chain required, I mean nobody is gonna allow you to submit stupid 6 chains when we need 16 chains to find a block that would just be a waste of resources ESPECIALLY if you couple it with your broken idea of how to value shares because a length 16 is = 10^16 but you want it to be worth 16... also known as two 8 chains
Also here is the further revised version.
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-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).One thing to note is that I have not however made any changes to the recommended methods of implementation (which I should probably do) simply due to the fact that I did have time to decode how the logs and exponents would be affected by the value V, so some reworking may be necessary.
Edit: Ok so my attempt at the important implementation recommendation looks like this
b. Logarithmic scale: Instead of maintaining the variables themselves, their logarithms are stored and updated. The following is the method expressed in l
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 = V*(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).
lol it is probably wrong as all I did was multiply the old value of r by V but ??? that might be all that is needed
- The miner output goes crazy when the pool it´s down ;)
-
The miner output goes crazy when the pool it´s down ;)
Probably ends up DDOSing the pool with requests which makes it even worse. Probably want to add a 30 second time delay(plus few extra random seconds) between requests when it looses connection in the miner..
- hgrrllmpf , i guess it's time for v0.2 of the miner (& pool) >:( stay tuned
- xolokram
-
I cannot connect to the pool
whats your problem?
I'm using windows x64, but got this error:
server returned HTTP error 403
-
@theprofileth, the problem of equal share value was first exposed in the yPool forum in this thread (http://community.ypool.net/index.php?page=Thread&threadID=58), in which someone wrote:
v6 has stayed pretty close in xpm income to v4 but with a lot more solved blocks. based on the total xpm income for the past 36 hours, i have to say v4 makes the miner more primecoins and v6 solves a LOT more blocks for the pool.
there is an equal amount of processing power allocated to each version. both versions of the miner are running with default settings.
to compare numbers:
v4 has 41 blocks found and 409 primecoins credited to the account.
--basically even with solo mining if i add the donation to the total
v6 has 51 blocks found and 370 credited to the account
--obviously this version is MUCH better at finding blocks and better for the pool over all. unfortunately, the share handling is killing this miner's profit potential.
You can see that the advantage of v4 versus v6 (versions of jhPrimeminer, by Mumus) was just 409/370 = 10.5 %. Also, it was counting several lengths of chains, say 6,7,8 and 9. So, the difference in primecoins if we count just consecutive lengths could be about 1.105^(1/3) = 3.4%.
In any case, it is less than 9/8 = 12.5%, and less than 8/7, 7/6 or 6/5. So, with just a share value proportional to the chain length the problem will be solved.
And a proportional value is a better measure of the computing work contributed by each participant, whilst an exponential valuation will depend on the luck each time, mainly for the small workers. Also, exponential valuation will give huge variance to the pool (yPool cuts its exponential valuation for lengths greater than 9 to avoid an unaffordable variance for the pool operator).
- down again :(
-
hgrrllmpf , i guess it's time for v0.2 of the miner (& pool) >:( stay tuned
- xolokram
Looking forward to that!
PD: Yesterday I tweaked my IPTables, changed the lines from session new,established to just leave the traffic completely open to ports 9912 and 9999 on the routing firewall. I still get a lot rejects and this message on the log:
[REQUEST] reply empty / long-poll timeout (re-polling!)
Maybe NAT it's causing this?
Good luck with the upgrade!
- @patapato
You do realize that 51/41 is 24% more blocks while receiving 370/409 which is %10 less. This is a HUGE disparity that existed even when there were weighting on shares that was proportional at a factor of about 1/8 iirc either way an exponential system can be more easily rescaled easily when compared to the rounding that occurs with fractions I mean how can one reduce 683 * 6/5 + 87* 7/6 + 7* 8/7
You can't is the answer. Rounding is far more harmful for small miners as they are losing out on a larger percentage of their shares over time than larger miners, further more the operational variance is lowered due to the fact that you aren't paying out losers in high amounts. You reward those that succeed not those that want to game the system. Furthermore this system actually works with higher tier chains where as I said before a 16 length chain would only be worth 16/15 which is actually less than 6/5 as your system has the most crucial flaw of not understanding that a a fraction n+1/n will forever shrink down infinitely. Furthermore you seem to misunderstand that a PPLNS has no operational risk which is why ypool uses it not, proportional share values has nothing to do with his. Please do some homework before continuing this line of thought.
Edit: Speaking in terms of optimization, furthermore as mentioned in the system the score accumulated between blocks can be rescaled equally each time a block is found in order to prevent overflow plus it would help to provide a more accurate payout estimate using this system.
Also a note on "fairness"
Let us assume that every single miner were to use the exact same rig and the exact same settings and mine for the exact same amount of time and that the only element of chance was generated through the prime generation. If we used a 1:1 share value in this situation, each person puts in the same amount of effort for finding a block and thus the variance is split between each one and their payouts would be approximately the same regardless of who found the block or who put in what, as long as the number of shares was about the same. Now imagine this community attempting to tackle a length 16 chain. They might spend literally months attempting to get the block and again this would then have everyone payed out equally. Now lets imagine a that in this community someone found out how to submit lots of lower chains so that when that 16 chain block was found they got more than half of the block. Obviously the community now has to weigh their shares to avoid such exploitation, however they only change the weights by a proportional value so each chain down from the target is worth 25% of the previous such that four 6 chains equal one 7 chain. Now this time around that one person does their method of mass chain submitting and while they don't get half of the reward, they still get a larger portion than they should simply due to the fact that it is much easier to submit four smaller chains than 1 larger chain especially over the course of a long period of time.
Now lets look at a more realistic example, if everyone can target their chain lengths and each chain length increase is essentially a ten fold increase in difficulty why would the payout be anything less than a ten fold increase for a higher chain compared to a lower chain? Furthermore this method in fact motivates people to aim for higher chains and further the pool as a whole which mind you, does benefit small miners as they get payed out every block found and thus more blocks means more payouts not just for the giants but also for the common folk. The goal of primecoin pools shouldn't be to allow leaches to steal from those who actually are contributing, if you allow chain spamming then you are essentially enabling pool hopping without even having to leave the pool as it is more profitable to spam low values than to actually aim for higher ones. Furthermore even if xolokram wanted to be nice and later allows a very low minimum chain length for submitting, this system would allow it not to negatively impact anyone and instead would simply allow for a more precise payout/hashrate.
On the topic of min chain length essentially the lower the min chain length the lower the payout variance (if an exponential value system is used) due to the fact that people's work is being accurately estimated however it does raise the operating cost by having to handle an exponential amount of increased submitted shares (regardless of value weighting the amount of 5 chain's found per hour is 10 fold the amount of 6 chains) so with the proper infrastructure in place the min could be set up to 4 levels lower than the target (ie one level lower than it is currently) IF AND ONLY IF the amount that the servers can take before crashing is at least another ten fold of the current. And given the current status of the servers dying pretty much daily I would say that ten times would have to be a minimum.
- hi
just a quick note: i'm coding a new protocol for the miner<->pool communication. one that actually scales :)
at the moment, we have to stick to the (unbearable) state of the server. i hope i will release the new version tomorrow.
failing reconnects & (99%) rejects should be history then.
- xolokram
ps. i shouldn't raise too much hope :D
pps. everything will crash (as it's not doing it already!?) & it'll suck ;D
ppps. some good thoughts are going on here
-
hi
just a quick note: i'm coding a new protocol for the miner<->pool communication. one that actually scales :)
at the moment, we have to stick to the (unbearable) state of the server. i hope i will release the new version tomorrow.
failing reconnects & (99%) rejects should be history then.
- xolokram
ps. i shouldn't raise too much hope :D
pps. everything will crash (as it's not doing it already!?) & it'll suck ;D
ppps. some good thoughts are going on here
Now it's clear why you wanted to keep this pool low profile.
It has worked good so far, given the beta condition. We are finding an average of 2 blocks per every 1000 increase.
cheers!
-
Help me please)
GeneratePrimeTable() : setting nSieveExtensions = 6, nSievePercentage = 10, nSieveSize = 1000000
GeneratePrimeTable() : prime table [1, 1000000] generated with 78498 primes
establishing TCP connection to 5.45.100.191:9912
operation_aborted @ tcp_handle_read_header
closing TCP connection:
done.
spawning 4 worker thread(s)
[WORKER0] Hello, World!
[WORKER1] Hello, World!
connection not available
[WORKER0] GoGoGo!
[WORKER1] GoGoGo!
PrimecoinMiner started
[WORKER3] Hello, World!
[WORKERPrimecoinMiner started
[WORKER3] GoGoGo!
2] Hello, World!
[WORKER2] GoGoGo!
PrimecoinMiner started
PrimecoinMiner started
-
Help me please)
GeneratePrimeTable() : setting nSieveExtensions = 6, nSievePercentage = 10, nSieveSize = 1000000
GeneratePrimeTable() : prime table [1, 1000000] generated with 78498 primes
establishing TCP connection to 5.45.100.191:9912
operation_aborted @ tcp_handle_read_header
closing TCP connection:
done.
spawning 4 worker thread(s)
[WORKER0] Hello, World!
[WORKER1] Hello, World!
connection not available
[WORKER0] GoGoGo!
[WORKER1] GoGoGo!
PrimecoinMiner started
[WORKER3] Hello, World!
[WORKERPrimecoinMiner started
[WORKER3] GoGoGo!
2] Hello, World!
[WORKER2] GoGoGo!
PrimecoinMiner started
PrimecoinMiner started
Looks like something it's blocking your comunications.
- do not use the current source code (from bitbucket) on beeeeer.org
i will tell you when the server is ready :)
- xolokram
-
I'm getting the following compiler error on ubuntu 13.04.
obj/main.o: In function `BitcoinMiner(CWallet*, CBlockProvider*, unsigned int)':
main.cpp:(.text+0x1de69): undefined reference to `CBlockProvider::submitBlock(CBlock*)'
collect2: error: ld returned 1 exit status
make: *** [primecoind] Error 1
Any ideas?
-
I'm getting the following compiler error on ubuntu 13.04.
obj/main.o: In function `BitcoinMiner(CWallet*, CBlockProvider*, unsigned int)':
main.cpp:(.text+0x1de69): undefined reference to `CBlockProvider::submitBlock(CBlock*)'
collect2: error: ld returned 1 exit status
make: *** [primecoind] Error 1
Any ideas?
are you compiling it as:
make -f makefile.unix primeminer
forgetting primeminer on the end was giving me issues.
-
do not use the current source code (from bitbucket) on beeeeer.org
i will tell you when the server is ready :)
- xolokram
xe-xe) Ok i understand.
- Down again
- <maintenance>
-
<maintenance>
Ok no worries :)
-
+++ FYI +++ FYI +++ FYI +++ FYI +++
hi,
ok. almost done (aka ready for stress tests). pool is running currently on the old protocol AND the new protocol. everyone on linux should checkout the newest source and connect using port 1337. windows user should stick to the old miner atm and check if everything is ok with their current mining machines, probably a reconnect is needed. i will build a windows version later today.
jhPrimeminer is not usable at the moment!!
i hope everything will work, i've tested alot on primecoin's "testnet".
there are still some areas i'm not happy with --- code-wise.
- xolokram
ps. did somebody recognize, that i executed the latest (confirmed) payouts? :)
pps. i'll be back later
OK, IGNORE THIS MESSAGE UNTIL I FIX THE POOL
aka stick to the old miner atm
-
hi,
ok. almost done (aka ready for stress tests). pool is running currently on the old protocol AND the new protocol. everyone on linux should checkout the newest source and connect using port 1337. windows user should stick to the old miner atm and check if everything is ok with their current mining machines, probably a reconnect is needed. i will build a windows version later today.
i hope everything will work, i've tested alot on primecoin's "testnet".
there are still some areas i'm not happy with --- code-wise.
- xolokram
ps. did somebody recognize, that i executed the latest (confirmed) payouts? :)
pps. i'll be back later
OK, IGNORE THIS MESSAGE UNTIL I FIX THE POOL
aka stick to the old miner atm
xolokram your doing a great job under difficult circumstances!
keep up the good work!! :)
-
I'm getting the following compiler error on ubuntu 13.04.
obj/main.o: In function `BitcoinMiner(CWallet*, CBlockProvider*, unsigned int)':
main.cpp:(.text+0x1de69): undefined reference to `CBlockProvider::submitBlock(CBlock*)'
collect2: error: ld returned 1 exit status
make: *** [primecoind] Error 1
Any ideas?
are you compiling it as:
make -f makefile.unix primeminer
forgetting primeminer on the end was giving me issues.
That got it to compile, thanks!
It seemed to start up and it printed 'PrimecoinMiner started' for the number of threads that I am using, but it's not mining. I assume that is due to xolokram's most recent message. I'll let you know if it comes back up later.
Edit: mining now.
-
the new mining protocol uses port 1337, but atm it's unstable (regarding receiving work from the server)
jhPrimeminer is not usable at the moment!!
- xolokram
ps. looks like everything works, i'll monitor it a little longer --- let's see what happens...
pps. there's some weird 'drop connection' bug on the pool-side, fix incoming...
- testing :)
- Hi, I'm seeing unusually high amount of rejected shares. I'm mining on 0.1 on Windows and 0.2 (latest git sources) compiled on Linux.
Hopefully this gets fixed soon :)
-
Hi, I'm seeing unusually high amount of rejected shares. I'm mining on 0.1 on Windows and 0.2 (latest git sources) compiled on Linux.
Hopefully this gets fixed soon :)
can you check if this still happens with v0.2 now? i've fixed a (very weird) bug.
jhPrimeminer should work again, but support will be dropped soon (until i have implemented their jh00's protocol).
linux users: please switch to v0.2 now!!
windows users have to wait for a binary later today.
- xolokram
ps. we've found a block, altough the pool is not in a healthy condition ;)
pps. looks like v0.1 is still suffering from some protocol problems?! i think it's the pool. fix/restart incoming...
ppps. now i'm tech support for v0.1, v0.2, windows, linux, jhPrimeminer & the pool
pppps. can someone confirm that jhPrimeminer (with 'getwork'-fix) is working again?!
- "0": 321,
"6": 623,
"7": 63,
"8": 7,
"-6":
Very much rejects on Old protocol.
PS: Miners have not reinstalled yet
- i'm trying to fix that right now.
- xolokram
-
Hi, I'm seeing unusually high amount of rejected shares. I'm mining on 0.1 on Windows and 0.2 (latest git sources) compiled on Linux.
Hopefully this gets fixed soon :)
can you check if this still happens with v0.2 now? i've fixed a (very weird) bug.
0.2 on Linux is still throwing more rejects, but 0.1 on Windows seems to produce more valid shares
PS. Now receiving "system:111" messages on 0.2, what's that?
- I started mining on the pool some hours ago. Not long ago the miner started telling "system:111"
And the webseite seems to be down. Is there some kind of mainteneance going on?
p.s. thumbs up for programming an xpm pool!
- ok, it's up & running again. that was really tough.
reminder: never bugfix/beta-test in a productive environment ;)
v0.1 , v0.2 & jhPrimeminer -SHOULD- work now. if you're encountering many rejects --> restart your miner first, if it still happens --> PM me or write here.
port for v0.1 & jhPrimeminer: 9912
port for v0.2: 1337
linux user: please switch to v0.2
windows user: wait for binary
i will drop the support for the old 'getwork' protocol soon. thus v0.1 & jhPrimeminer will not work for then on. to support jhPrimeminer in the future i'll have to implement jh00's xpt protocol.
- xolokram
ps. thanks for all the support & patience today......
pps. the 'worker' count on the pool stats page are just the workers using the new v0.2 protocol
ppps. i'll have to take a break ;D
pppps. if you (want to) use v0.2: please check, that you've built with the latest source (atm commit 97d918d)
-
Compile from
bitbucket.org/thbaumbach/primecoin-hp.git
start....
primeminer -pooluser=USER -poolpassword=0 -poolip=beeeeer.org -poolport=1337 -genproclimit=1
result :o
********************************************
*** Primeminer - Primecoin Pool Miner v0.2
*** by xolokram/TB - www.beeeeer.org
***
*** thx to Sunny King & mikaelh
********************************************
GeneratePrimeTable() : setting nSieveExtensions = 6, nSievePercentage = 10, nSieveSize = 1000000
GeneratePrimeTable() : prime table [1, 1000000] generated with 78498 primes
spawning 1 worker thread(s)
[WORKER0] Hello, World!
[WORKER0] GoGoGo!
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
what(): set_option: Bad file descriptor
Aborted (core dumped)
- @Grekk:
on commit 97d918d?
> git log
small information gathering:
please tell me on reply...
what software are you using?
which system do you use?
what is the rejection rate? (roughly)
how 'stable' is your connection generally? (roughly)
- xolokram
ps. please use the latest commit 97d918d if you want to use v0.2
- everything works fine for me (2xubuntu) v0.02
- Hi xolokram.
Thanks for this software and the pool. I've only been mining XPM a short time but your pool has the higest return rate for me.
I'm currently running your v0.2 software on three hosts. One is an AMD Phenom Quad Core running Linux Mint 14. The second is an Intel Dual core also running Linux Mint 14. The third is a Digital Ocean single core VPS running Ubuntu 13.04.
The compile worked first time on each (I used the code from GitHub). At first I was getting nearly 100% rejects but since you said to restart clients I've been getting approximately 9% Rejects.
Thanks again. If I can be of any assistance with more information, please let me know.
-
...
thank you for the reply; did you built with commit 97d918d?
-
~/primecoin-hp/src$ git log
commit d3673649c80390861df47137c1f9440e8a5b38ca
Author: Thomas Baumbach <[email protected]>
Date: Wed Sep 11 17:33:38 2013 +0200
tcp no_delay added (yeah, that should've been pretty handy earlier...)
commit 1a26d554107adbb4b2c7bb591d702acea4d62f6e
Author: Thomas Baumbach <[email protected]>
Date: Wed Sep 11 13:18:32 2013 +0200
proper read handling
commit 0ac835f4fdf35b479d4a81637631ddc82f740fde
Author: Thomas Baumbach <[email protected]>
Date: Wed Sep 11 10:34:34 2013 +0200
remove some verbose info -fix- (i need some sleep)
what software are you using?
which system do you use?
Clear Ubuntu 13.04 (GNU/Linux 3.8.0-29-generic x86_64)
-
Hi.
This is what git log gives me.
git log
commit 1a26d554107adbb4b2c7bb591d702acea4d62f6e
Author: Thomas Baumbach <[email protected]>
Date: Wed Sep 11 13:18:32 2013 +0200
proper read handling
commit 0ac835f4fdf35b479d4a81637631ddc82f740fde
Author: Thomas Baumbach <[email protected]>
Date: Wed Sep 11 10:34:34 2013 +0200
remove some verbose info -fix- (i need some sleep)
commit 710c8626058bc6b1a4b61ebcbe0a69e69ab8fd6d
Author: Thomas Baumbach <[email protected]>
Date: Wed Sep 11 10:24:06 2013 +0200
remove some verbose info
commit 6a4f89d4d8353ddb13f7d8af73f582b4a83b6fe1
Author: Thomas Baumbach <[email protected]>
Date: Wed Sep 11 10:17:54 2013 +0200
fixed the reconnection
:
- @MJ2P & Grekk:
that's not the newest commit:
check the latest/top commit hash (> git log) & compare with the latest here (https://bitbucket.org/thbaumbach/primecoin-hp/commits/all)
use
> git pull
to get the latest commit
- xolokram
- Will do. I'll have a run and check how many rejects I get and report back
- Cheers xolokram! 0.2 now seems to be working much better :)
0.1 win build still throws a few reject every now and then.
Also, thanks for your effort on developing this pool. Expect to receive some XPM tips ;)
-
@MJ2P & Grekk:
that's not the newest commit:
check the latest/top commit hash (> git log) & compare with the latest here (https://bitbucket.org/thbaumbach/primecoin-hp/commits/all)
use
> git pull
to get the latest commit
- xolokram
Have you considered integrating the commit ID to the banner that is shown when starting the primeminer? I think that could help juggling different versions/commits during the beta phase without losing track ;)
- OMG, I Just finished recovering from a power outage ouch. On my way!!
BTW: xolokram: Payments are working like a charm!!!
- So it looks like the website was down for a few minutes, which I get happens.
However, my stats, as far as shares submitted reset even though we haven't gotten a block in a while.
What gives?
- Damn the last block must have been an orphan :(
-
Damn the last block must have been an orphan :(
...at least my share counter for my user has been reset and no new block was listed...
- backend crashed. the v0.1 'getwork' protocol is quite unstable for that many connections.
we should migrate to v0.2 as fast as possible, i want to get rid of that sh*%#y protocol.
- xolokram
ps. windows build will be ready soon, i'm trying to implement some statistics to the miner
-
@MJ2P & Grekk:
that's not the newest commit:
check the latest/top commit hash (> git log) & compare with the latest here (https://bitbucket.org/thbaumbach/primecoin-hp/commits/all)
use
> git pull
to get the latest commit
- xolokram
Thank you,
I fully migrated to V .2)
{
"0": 11,
"6": 238,
"7": 23,
"8": 3,
"9": 1
}
PS: I think rejects from WIN-miner
- Why would you drop getwork support? The new jhprimeminer is great I am getting tons of shares right now ;D
https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
plus it just means you don't have to work on optimizing a miner on your own
mumus was even nice enough to fix getwork for you even though ypool has it disabled :)
-
Why would you drop getwork support? The new jhprimeminer is great I am getting tons of shares right now ;D
https://www.dropbox.com/sh/sq24hzo993afy9c/l7icP0KiuM
plus it just means you don't have to work on optimizing a miner on your own
mumus was even nice enough to fix getwork for you even though ypool has it disabled :)
maybe xolokram can just update the pool to support jh00's xpt protocol
-
Thank you,
I fully migrated to V .2)
{
"0": 11,
"6": 238,
"7": 23,
"8": 3,
"9": 1
}
PS: I think rejects from WIN-miner
I'm on 0.2 (commit 97d918dddf77f1942c2281c5d04faa37e7a32c88) and I have some rejects on Ubuntu 12.04 LTS 64 Bit:
{
"0": 5,
"6": 33,
"7": 6,
"8": 1
}
...but no big deal at all and considering that this is a beta, I'd like to say: great job so far!
[edit]
plus: it seems that the rejects are associated to downtimes of the backend (at least that is what I assume for the last bunch of my rejected shares (22:12 UTC+2))
[/edit]
-
mumus was even nice enough to fix getwork for you even though ypool has it disabled :)
you mean he accepted the code i pushed to his github to fix his miner, right?
[...] jhprimeminer [...]
[...] xpt protocol [...]
because the raw 'getwork' protocol is not suitable for hundreds (thousands?) of connections - it makes the whole backend unstable.
i will add xpt support in the future.
- xolokram
-
[...] jhprimeminer [...]
[...] xpt protocol [...]
because the raw 'getwork' protocol is not suitable for hundreds (thousands?) of connections - it makes the hole backend unstable.
i will add xpt support in the future.
- xolokram
Sounds good to me as long as I can use the best programs around I will support your pool to the bitter end :)
Now if only I could get the GPU miner to work on your pool, seems like I can only get it to solo mine ;D
-
backend crashed. the v0.1 'getwork' protocol is quite unstable for that many connections.
we should migrate to v0.2 as fast as possible, i want to get rid of that sh*%#y protocol.
- xolokram
ps. windows build will be ready soon, i'm trying to implement some statistics to the miner
To clarify, we lost our shares due to the backend crash or due to the fact that the block that was found was an orphan?
If it's the latter, shares should remain until the next paying block.
- it crashed hard ... right into nirvana, there was no block at the time of the crash.
<stupid example removed>
as long as there's not much variation in the # of current miners during the round in which the pool crashes nothing is 'lost'
@orphans:
check this (http://www.beeeeer.org/payout/155339)
shares from a orphaned block are not transfered to a other round atm
maybe i will at something like this in the future
---
primeminer v0.2 for Windows
windows binary: primeminer v0.2 (http://www.mediafire.com/download/lw5v9ck4bho1dts/primeminer_v02_x86_and_x64.zip.zip) *BETA*
(contains 32 and 64 bit version)
usage:
primeminer -pooluser=[xpm-payout-address] -poolpassword=0 -poolip=beeeeer.org -poolport=1337 -genproclimit=[threads-to-use]
use port 9912 if you want to use the -old- getwork protocol (jhPrimeminer) - support will be abandoned soon!!
- xolokram
ps. pool restart incoming! DONT PANIC!!
- Just finished upgrading all my Linux instances to v0.2, I'm getting a considerably less amounts of rejects.
The new miner seems to be working just fine. Great Job!
- Has anyone been able to get the miner to compile on OSX? I've been fiddling with the makefile, but I don't really know what I'm doing. I thought that I had gotten it working, but the program that it actually compiled was just the wallet.
Posting your working makefile for osx would be greatly appreciated.
-
I LOVE APPLE(S)
I'll try: @makefile.osx
REMOVE:
obj/init.o \
CHANGE:
all: primecoindTO
all: primeminer
&
primecoind: $(OBJS:obj/%=obj/%)TO
primeminer: $(OBJS:obj/%=obj/%) obj/main_poolminer.o
> make -f makefile.osx
thanks for the tons of prime- & bitcoins i will receive ... there will be some coins, right? ... right?
- xolokram
ps. not tested, i don't have any OSX device
pps. BLOCK!!
-
I LOVE APPLE(S)
I'll try: @makefile.osx
REMOVE:
obj/init.o \
CHANGE:
all: primecoindTO
all: primeminer
&
primecoind: $(OBJS:obj/%=obj/%)TO
primeminer: $(OBJS:obj/%=obj/%) obj/main_poolminer.o
> make -f makefile.osx
thanks for the tons of prime- & bitcoins i will receive ... there will be some coins, right? ... right?
- xolokram
ps. not tested, i don't have any OSX device
pps. BLOCK!!
I'm now getting another error, any idea on this one?
main_poolminer.cpp:441: error: ‘sighandler_t’ does not name a type
main_poolminer.cpp: In function ‘int main(int, char**)’:
main_poolminer.cpp:476: error: ‘set_signal_handler’ was not declared in this scope
/opt/local/include/boost/asio/error.hpp: At global scope:
/opt/local/include/boost/asio/error.hpp:244: warning: ‘boost::asio::error::system_category’ defined but not used
/opt/local/include/boost/asio/error.hpp:246: warning: ‘boost::asio::error::netdb_category’ defined but not used
/opt/local/include/boost/asio/error.hpp:248: warning: ‘boost::asio::error::addrinfo_category’ defined but not used
/opt/local/include/boost/asio/error.hpp:250: warning: ‘boost::asio::error::misc_category’ defined but not used
/opt/local/include/boost/system/error_code.hpp:222: warning: ‘boost::system::posix_category’ defined but not used
/opt/local/include/boost/system/error_code.hpp:223: warning: ‘boost::system::errno_ecat’ defined but not used
/opt/local/include/boost/system/error_code.hpp:224: warning: ‘boost::system::native_ecat’ defined but not used
make: *** [obj/main_poolminer.o] Error 1
- Good on ya xolokram, this new miner is much better in my hour or so of mining i found it to be comparable to the new 3.3 jhprimeminer
I should have some extra time this weekend so that I run a series of tests to verify my claims about the version of DGM that I am working on.
Actually xolokram if you wanted to do me a solid you could collect some data off of the blocks we have found pm me with some of the user data that I could use for the testing for example the number of users, chain lengths submitted, you know that sort of stuff. Either way if you are too busy I guess I could dig through your website and collect it on my own.
- @refer_2_me:
> git pull
> make -f makefile.osx
i've commited a update that could help osx users / you
@theprofileth:
i'll try to get more data asap
- kroloxam
-
@refer_2_me:
> git pull
> make -f makefile.osx
i've commited a update that could help osx users / you
@theprofileth:
i'll try to get more data asap
- kroloxam
It compiled!
Edit: It compiles and runs albeit quite slowly compared to my linux box.
BTW, you should change the port number on the homepage, it says 9912, but that doesn't retrieve any work.
-
np
ps. pool restarts incoming! DONT PANIC!!
this
- xolokram
ps. btw i'm now at <1% rejects (http://www.beeeeer.org/user/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE)
ps. btw i'm now at 1% - 10% rejects (http://www.beeeeer.org/user/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE)
-
I have got the following error while running v0.2 on W7 (after more than one hour):
2013-09-12 03:42:50 primemeter 44881 prime/h 1041910 test/h 12 5-chains/h 0.011859 chain/d
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >'
what(): resolve: Host desconocido
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
2013-09-12 03:44:07 primemeter 37917 prime/h 891910 test/h 0 5-chains/h 0.009504 chain/d
- Good Morning xolokram
I've let my miners run over night and am happy to report that I'm also getting ~1% rejected.
Great work on the pool and thanks for all your hard work.
-
thank you
what(): resolve: Host desconocido
looks like you've completely lost your internet connection; the app crashed or is it throwing these messages while mining?
uhm, i'm confused... the pool is still running... :) ... nothing crashed ... what an unusual feeling...
i'm aware of the high rejection rates atm (for some miners), i'll look into this problem, when i have the time
- xolokram
ps. dont expect too much changes today as i've to take care of other things (pool restart(s) incoming; minor changes, check your miners & reconnect)
- {
"0": 374,
"6": 419,
"7": 33,
"8": 3,
"-6": 1
}
Last 20-30 min.
What happened?
-
{
"0": 374,
"6": 419,
"7": 33,
"8": 3,
"-6": 1
}
Last 20-30 min.
What happened?
Looks like something's wrong with the backend...
I encounter the same dramatic inrease in rejects:
{
"0": 23,
"6": 18,
"7": 1
}
-
i'm working on it, dont panic
everything should be ok now
(altough it's a workaround i'm using, i'll have to investigate)
- xolokram
ps. miners on the 'getwork' probably need a reconnect
- just changed to V0.2 from jhprimeminer 3.3
80% of my share are now rejected :(
- v0.1 and jhPrimeminer use the old 'getwork' protocol, which i try to get rid of.
use v0.2 or wait until i implement xpt-protocol , if you don't want to have the reject/reconnection problems
- xolokram
ps. the last ~45 minutes there was a bug in the backend, rejects during this period were common
pps. pool-backend/v0.2 still needs some tweaking, there are still too many rejects
- All working fine now!
interesting to see if V0.2 is better than jhprimeminer 3.3 :)
- Xolokram, I humbly request that the total owed and earned showed be listed on each miner's address page along with the current shares in the round, would be lovely to know how much I am making without having to wait for payout blocks ;D
Also I find it funny how patapato hasn't made a rebuttal to my arguments, I guess I will assume he is conceding victory to me.
- The last 5 minutes all rejects!
-
The last 5 minutes all rejects!
restart your miner, it happens sometimes :o
-
The last 5 minutes all rejects!
restart your miner, it happens sometimes :o
Thanks all working fine, funny things these miners ..lol
- Are there any news on the auto-payout?
BTW: I got my first 10XPM 8)
-
MOAR STAAAAAAAAAAAAAATS!!
...will be part part of the bright future! ;)
aka i will rework the "web interface" as soon as i have found the reason for the high reject rate (~10-20%). i think the problem is part of the pools connection backend.
i've commited a patch with a workaround that will help the current rejection issue (it's just a quick'n'dirty "fix"). linux user should built the new miner now.
auto-payout is not running at the moment
it's all executed manually (via script)
- xolokram
ps. i think it's more vital if we split the thread into a "technical issues & problems" thread and a "general ideas and thoughts about the pool" thread
pps. i should have thought about a better domain for the pool; altough it's funny to read the threads @btctalk, when they're talking about "trying beeeeer" ;)
- Need re-build miners?
- if you want to use the dirty workaround
otherwise wait until i have a proper solution
- {
"0": 130,
"6": 722,
"7": 63,
"8": 8,
"9": 1,
"-7": 1
}
Tonight was only 1-2% rejects
- commit 7b239dde112e40eafed35312cd8281c9736bfe0f
is compiled and running (on Ubuntu 12.04 64 Bit). Let's see how it works.
Current situation (last solved block 161238):
{
"0": 3,
"6": 30,
"7": 1
}
[edit]
Looking good so far:
{
"0": 3,
"6": 45,
"7": 1
}
[/edit]
-
Tonight was only 1-2% rejects
can you refer a block to this argument?
as far as i see, the average was ~10-15% rejects
some had luck on a block with only 1% rejects, some had bad luck producing 20% rejects
on the next block it was totally different for the user
i think i know why this happens, there might be a race condition on a critical part of the backend
@masterOfDisaster:
the 'fix' will not erase rejects completely, but it may reduce the amount
- xolokram
ps. hooray, post #200 ::)
-
can you refer a block to this argument?
as far as i see, the average was ~10-15% rejects
Yes, you are right, Sorry
-
[...]
@masterOfDisaster:
the 'fix' will not erase rejects completely, but it may reduce the amount
- xolokram
ps. hooray, post #200 ::)
I don't expect things to proceed that fast. If that 'fix' mitigates the problem a bit, it's good ;)
My overall experience of the pool is very well so far.
I second your idea of splitting the topics into a "technical issues & problems" thread and a "general ideas and thoughts about the pool" thread. Maybe we can add a "feature request" thread as well. I have some ideas, but don't wanna spam this thread, that currently is quite focused on technical aspects, with my silly ideas :)
-
aka i will rework the "web interface" as soon as i have found the reason for the high reject rate (~10-20%). i think the problem is part of the pools connection backend.
I don't mind if the web interface stays as it is. It's fancy enough for me :)
More stats is what I crave the most.
-
aka i will rework the "web interface" as soon as i have found the reason for the high reject rate (~10-20%). i think the problem is part of the pools connection backend.
I don't mind if the web interface stays as it is. It's fancy enough for me :)
More stats is what I crave the most.
Yes we need a stable pool the last block i got 11 shares 11 rejected 0xpm :(
- Having to close and restart my miners every 30 minutes to stop all the rejects never had this on jhprimeminer 3.3
-
[MASTER] submitted share -> REJECTED
too many rejects, forcing reconnect.
This is new function - reconnect?
I have not seen this before
-
Having to close and restart my miners every 30 minutes to stop all the rejects never had this on jhprimeminer 3.3
How do you installed it on Linux?
{
"0": 88,
"6": 318,
"7": 30,
"8": 4
}
:-[
-
i really don't want to repeat myself all the time.
if you don't want the mass rejections/reconnect problem atm, use my miner v0.2 OR wait until i have fixed that issue / implemented xpt for jhPrimeminer.
from now on:
PLEASE USE THIS THEAD (http://ppcointalk.org/index.php?topic=501.0) FOR PROBLEMS WITH THE POOL/MINER
this thread is now for general discussion: e.g.
- which share values to use for future block reward calculation?
- making a third thread only for suggestions/ideas?
- payout barrier of 3 XPM too low? too high?
@zaba:
yup, it's the dirty workaround
@anonymous:
thank you for your donation! :)
- xolokram
ps. maintenance incoming, pool will be down for a few minutes, let's all hope i've found the bug
pps. reminder: global rejection rate GWK=48,1% GWX=~17,8% (before 'fix')
-
if you don't want the mass rejections/reconnect problem atm, use my miner v0.2 OR wait until i have fixed that issue / implemented xpt for jhPrimeminer.
I'm using the V02, but also have a lot of rejections.
to xolokram
How can I compile a miner v02 on a machine with 512 MB of RAM with disabled swap file? The compilation process is aborted due to lack of memory.
-
XOLOKRAM'S OFFICIAL IGNORE LIST:
(this will be a reminder for me - updated constantly)
- Grekk - 24 Stunden (13. September 21:00 Uhr) Post #209 --> Post #208
- xolokram
ps. looks like this is necessary for some users
pps. please read post #208 (http://ppcointalk.org/index.php?topic=485.msg3634#msg3634) , post #1 (http://ppcointalk.org/index.php?topic=485.msg3304#msg3304) & support thread (http://ppcointalk.org/index.php?topic=501.msg3632#msg3632)
- Use it
http://ppcointalk.org/index.php?action=profile;area=lists;sa=ignore;u=11498
- gentlemen (and -women),
i think i've fixed the rejection issue (for gwx protocol, this is the protocol for my v0.2 miner)
global stats so far: for gwx protocol (aka v0.2 miner protocol)
valid: 10124
rejects: 346 (~3,4% was ~18% before)
i'm already aware of a smaller bug (also producing some rejects that can be avoided), but i've not fixed it yet.
just fyi: for gwk protocol (aka v0.1 and jhPrimeminer ATM)
valid: 498
rejects: 138 (~27% was ~48% before)
- xolokram
ps. to those who really have to use jhPrimeminer, please wait until i've implemented jh00's xpt protocol (or use my miner v0.2)
pps. reminder for the new tech support thread --> HERE (http://ppcointalk.org/index.php?topic=501.0)
-
gentlemen (and -women),
i think i've fixed the rejection issue (for gwx protocol, this is the protocol for my v0.2 miner)
global stats so far: for gwx protocol (aka v0.2 miner protocol)
valid: 10124
rejects: 346 (~3,4% was ~18% before)
i'm already aware of a smaller bug (also producing some rejects that can be avoided), but i've not fixed it yet.
just fyi: for gwk protocol (aka v0.1 and jhPrimeminer ATM)
valid: 498
rejects: 138 (~27% was ~48% before)
- xolokram
ps. to those who really have to use jhPrimeminer, please wait until i've implemented jh00's xpt protocol (or use my miner v0.2)
pps. reminder for the new tech support thread --> HERE (http://ppcointalk.org/index.php?topic=501.0)
Thanks xolokram
I'll give your miner another go :-)
- Xolokram, so I was thinking before about alternative methods for payouts along with DGM, and I realized that you could also do CPPSRB which stands for Capped Pay Per Share with Recent Backpay (http://eligius.st/~gateway/faq/capped-pps-recent-backpay) the method has zero operational risk due to its method of limiting payout to only what has been earned and it provides a low variance method of payout for miners. This and DGM are by far the two best payout methods around
A quick summary of the pros and cons of each would look like
Double Geometric (DGM)
Hoppability None
Share-variance Adjustable
Pool-variance Adjustable
Maturity time Adjustable
Operator risk Adjustable
Variance+risk Adjustable
Variance+risk+maturity Medium
Complexity High
Instability Low
Capped Pay Per Share with Recent Backpay (CPPSRB)
Hoppability None
Share-variance Very Low
Pool-variance None
Maturity time Adjustable
Operator risk None
Variance+risk Low
Variance+risk+maturity Low
Complexity Medium
Instability Low
Essentially CPPSRB just allows you to run a PPS payout system without the risk of PPS as you only payout when you have enough and you pay people back when you break even and builds up a cache when you do well in rounds to help pay back people when you get longer rounds, DGM handles this in the reverse sort of way. In DGM when you are doing well IE fast blocks you build of a sort of emergency fund, this fund gets used on long rounds to pay people out more in order to incentivize staying on long rounds, where as CPPSRB you never feel any difference between long and short rounds in terms of payout, the main idea is that you just have to wait longer to get payed back. Both are good systems and can be able to and have been able to run with 0% fee pretty much indefinitely.
Also if you are considering a new name because the current one is kind hilarious and not exactly one I would expect from such a cool opportunity, I suggest Xolomine ;) I hope you see what I did there 8)
-
CPPSRB which stands for Capped Pay Per Share with Recent Backpay (http://eligius.st/~gateway/faq/capped-pps-recent-backpay)
Also if you are considering a new name because the current one is kind hilarious and not exactly one I would expect from such a cool opportunity, I suggest Xolomine ;) I hope you see what I did there 8)
CPPSRB sounds pretty good actually. I have to get my head around the details, but i've a good feeling about this.
0% fee is not really a option unfortunately. Eligius takes the transaction fees, which are rougly ~0.1 BTC per block. this is equal to ~30 XPM if i'm correct. The current transaction fees on the XPM network are (roughly) 0 to 0.03 XPM per block. that means that a block at eligius is 'worth' 1000 blocks for xpm pools (for eligius). ok, then there are 10x more primecoin blocks than bitcoin blocks; which still is a factor of 100 at the end, am i right? i hope the calculations are correct and you see my point --- it would be great when at least the server would pay for itself. like i wrote in post #1, a fee somewhere between 1 and 3% should be acceptable.
btw i really like eligius' pool, it was one of the first pools i used --- back in the days :)
- xolokram
ps. i see what u did there ;)
pps. i think i will stick to the domain atm, but i will use 'xolomine' for my miner (which is -regarding the important mining part- mostly mikaelh's miner, but i won't tell anybody if you won't!! *shhhh*)
- Oh I wasn't suggesting that you go with a 0% fee I was just saying that it has the ability to run on 0% fee as it has zero operational risk in theory. I was thinking that you could let people choose how much they want to pay by having an additional parameter in the miner or even just your password if it is 1<x<100 then that can be the fee they pay but yeah. I like pools that allow you to choose how much you want to give.
- ok, then this will be my argument post for future posts suggesting a 0% fee pool :)
i like the 'pay'-what-you-want idea
- xolokram
ps. 41478 valid vs 1192 rejects (2,8%) shares @getworx-protocol (aka v0.2 protocol)
-
gentlemen (and -women),
i think i've fixed the rejection issue (for gwx protocol, this is the protocol for my v0.2 miner)
[...]
Is this a change that requires new compilation of the miner? I guess no, because the last commit at github seems some time ago...
- nope, it was a bug in the backend. no new compilation is needed, but it doesn't hurt to do it anyway (atm). ;)
- xolokram
- Oh and essentially the only difference between a normal CPPSRB and one for primecoin would be that all shares submitted would have the V variable that I came up with before except you would be changing
Number of Primecoins
---------------------------- = primecoins per share
Difficulty of Network
to
Number of Primecoins
---------------------------- * V = primecoins per share
Difficulty of Network
However in this case it might be worth changing the values from 1 to 1000 to a lower but equivalent factor of 10
hmm, essentially my idea is this, you can go 1 to 1000 to incentivize growth or you can go 0.01 to 10 to lower chance of falling behind.
Maybe start off with 0.01 to 10 then slowly easy up to 0.1 to 100 and then finally 1 to 1000 so that you can have a cache built up.
Essentially with primecoins you need a value multiplier.
Hmm, I wish I knew the actual value of the difficulty but for now I can just assume that the difficulty of 9 means 10^9 so therefor a block with 9.85959399 for diff and 10.27 reward would look like
10.27
---------------------------- * V = primecoins per min share
e^9.85959399
ends up being 0.000536541*V primecoins per min share
so you should be able to take about 18,637.9 value 6 shares or 1,863.79 7 chains or 186.379 8 chains or 18.6379 9 chains
And looking at some of the blocks in the past this seems about right for what we need
-
I wish I knew the actual value of the difficulty
there's a website for this: www.beeeeer.org (http://www.beeeeer.org/) ;D
-
I wish I knew the actual value of the difficulty
there's a website for this: http://www.beeeeer.org/ ;D
I mean how they calculate it to such a nice number :P ::) I am assuming we don't simply take 10 primecoins and divide by 9.8 difficulty and pay out just under 1 primecoin per share :P or I suppose you could go with that strategy and use it to cap like this
primecoins
-------------- = value of block length
difficulty
so
10.17
------------ = 1.0314401622718052738336713995943 per 9 chain and then just go down in factors of 10 so
9.86
0.10314401622718052738336713995943 per 8 chain
0.010314401622718052738336713995943 per 7 chain
0.0010314401622718052738336713995943 per 6 chain
however that would easily bankrupt your pool as you would never hit blocks fast enough for it to work
- theprofileth
Why does not suit the current system? You want a second Ypool?
IMHO Сurrent system is working very well
-
theprofileth
Why does not suit the current system? You want a second Ypool?
IMHO Сurrent system is working very well
Hello, yet another uniformed soul ::)
ypool uses a proportional weighted pplns system that has rounds of 80 blocks.
We are suggesting the usage of a CPPSWB with an exponential weighted share values.
Currently the system is a per block proportional pool with equal share values.
If all of this means nothing please go read some of the previous pages were we/I discuss more on this topic.
- I'm going to give this pool a go for a couple days and compare the share values against ypool and solo mining. I've got a friend that for some reason or another, has had great luck with finding blocks, such that I've recommended he join beeeeer as well.
-
Also I find it funny how patapato hasn't made a rebuttal to my arguments, I guess I will assume he is conceding victory to me.
Here I am :) , I'm glad to know that you miss me ;)
this thread is now for general discussion: e.g.
- which share values to use for future block reward calculation?
I was waiting to see if somebody else wrote his opinion, or was interested on reading ours.
Here is one rebuttal (if you don't like it I have more). Let's go again to the share value problem as appeared in yPool (http://community.ypool.net/index.php?page=Thread&threadID=58):
to compare numbers:
v4 has 41 blocks found and 409 primecoins credited to the account.
--basically even with solo mining if i add the donation to the total
v6 has 51 blocks found and 370 credited to the account
--obviously this version is MUCH better at finding blocks and better for the pool over all. unfortunately, the share handling is killing this miner's profit potential.
At that time (August 10) yPool was already applying an exponential share value, namely:
Share value = pow(8, round(submitted share difficulty,0) -7) (http://tuckfheman.tumblr.com/post/56712167724/ypool-worlds-first-primecoin-mining-pool)
This is quite similar to the proposals made by theprofileth (http://ppcointalk.org/index.php?topic=485.msg3446#msg3446) and AlexMc (http://ppcointalk.org/index.php?topic=485.msg3399#msg3399), except that here it was an 8-fold value for each consecutive length of chain, instead of 10-fold.
Now, let's analyze more deeply this problem. At first sight it looks that miners using v4 were profitting extra primecoins against miners using v6. But that is not true, people who used v4 was also loosing primecoins!: difficulty was about 9.66, so the primecoins per block was about 999/9.66^2 = 10.7 (http://xpm.muuttuja.org/charts/). Instead, v4 miners got 409/41 = 9.8 coins per block, that is 8.4 % less than the correct. v6 miners was loosing quite more, about 32 %.
So, who was taking extra primecoins?. It was the v4 big miners who found chains longer than the difficulty!. Why?, because the value of a 12-length chain (for example) was 262144 times that of a 6-length chain. An exponential valuation works as a lottery in wich the ones who are lucky to find a long chain are rewarded with the contribution of the rest.
So, the problem was the opposite to the one exposed, yPool was incorrectly rewarding in excess to the bigger chains, not to the small chains!.
The reason why v6 lost a bigger percentage was just the different base of the (quasi)exponential probability distribution. in v4 the base of the exponential distribution was (I think) about 12 or 13 (that is 12 or 13 times more 6-chains than 7-chains, and so on). In v6 it was close to 10, and that has the secondary effect that the total chains of any length found with v6 was less than with v4.
Now let's go with the possible solution, with the help of the numbers in the avobe example. If the distribution of lengths are so different in v4 than v6 it means that they have different mean length. Suppose that mean length is 7 in v4 and 8 in v6 (put another reasonable numbers if you want), and suppose that total number of chains is proportinal to the credited primecoins (I have not more data, I have to make reasonable assumptions). Then we can estimate proportional share valuation as total chains multiplied by mean length:
proportional share value for v4: 409*7 = 2863 < proportional share value for v6: 370*8 = 2960
So, in this case a proportional share value would correct the problem. And it is enough to incentivate submitting longer chains. I think that it is not true that a miner could be developed or tuned to take advantage of a proportional share valuation without findinding more blocks (if you found 6 primes in chain it will be worth to test the seven, and if your sieve is bad for big chains you will find few more total chains).
The effect of the new share value applied by yPool has been devastating for small miners, don't fall on the same error. [/list]
- Does beeeeer.org still accept getwork connections? I am asking because the reaper gpu prime miner uses getwork to connect to the primecoind daemon so I would think I should be able to connect to beeeer.org with it as well but when I try to connect it states that curl throws an error 52 which means it got an empty or bad response... this might not be possible to do but I dont see any reason as of right now why it wont work unless getwork has been turned off.
-
theprofileth
Why does not suit the current system? You want a second Ypool?
IMHO Сurrent system is working very well
Hello, yet another uniformed soul ::)
ypool uses a proportional weighted pplns system that has rounds of 80 blocks.
We are suggesting the usage of a CPPSWB with an exponential weighted share values.
Currently the system is a per block proportional pool with equal share values.
If all of this means nothing please go read some of the previous pages were we/I discuss more on this topic.
Why complicate things? The current system is clear and transparent, brought more shares... received more XPM.
-
Is it possible to "proxy" this pool via iptables?
I tried
iptables -t nat -A PREROUTING -p tcp --dport 1337 -j DNAT --to-destination 5.45.100.191:1337
but thats not working, i think its connecting but it keeps spamming a system #random number# message.
-
Why complicate things? The current system is clear and transparent, brought more shares... received more XPM.
Because the current system that equally rewards shares without taking into regard the propability of getting such a share. Some sleazebag could manipulate the miner to create only chains of length 6, save the additional cpmputing time for finding out about a consecutive prime to make it a chain of length 7 (or even 8 or longer).
This sleazebag did take profit from generating more shares than honest miners without being able to contribute to solving a block. That is why I highly recommend giving the shares a weight. A tenfold increase in value for a share each step upward in chain length seems to be close to the distribution of the found chains. I don't have enough math skills to say that this tenfold is an intrinsic value. But at least currently it turns out to be the value...
...talking about a payout system is a slightly different topic.
- hi,
just fyi - what will be done next:
i think it is the best to rework the web interface a little bit (read: add more global/personal stats) before i make my final decision about the share value & payout system. so we'll still have enough time to go through all the aspects of every option and maybe until then we can have some proper stats from the pool itself. btw faster payouts can be another advantage
despite this, i see that few mining machines still have some problems with rejects (talking about v0.2 miners in particular), i will have to look into that issue.
PLEASE USE THIS THEAD (http://ppcointalk.org/index.php?topic=501.0) FOR TECHNICAL ISSUES/PROBLEMS/QUESTIONS WITH THE POOL or MINER(S)
thank you
i think i have to spam this on every new page on this thread ... kinda sad
- xolokram
-
hi,
just fyi - what will be done next:
i think it is the best to rework the web interface a little bit (read: add more global/personal stats) before i make my final decision about the share value & payout system. so we'll still have enough time to go through all the aspects of every option and maybe until then we can have some proper stats from the pool itself. btw faster payouts can be another advantage
despite this, i see that few mining machines still have some problems with rejects (talking about v0.2 miners in particular), i will have to look into that issue.
PLEASE USE THIS THEAD (http://ppcointalk.org/index.php?topic=501.0) FOR TECHNICAL ISSUES/PROBLEMS/QUESTIONS WITH THE POOL or MINER(S)
thank you
i think i have to spam this on every new page on this thread ... kinda sad
- xolokram
Stats are nice, i was bored so i build this xD
http://xpm.syware.de/?address=AbB7cgdEXr3hJ254qFW1QqAecLGfW9XyGU
Oh and please rename your time variable to something else, php just ignores that value, can't access it, guess it's a protected word...once i can access time i can calculate daily avg - i want to add which blocks have already been paid too ^^
-
Is it possible to "proxy" this pool via iptables?
I tried
iptables -t nat -A PREROUTING -p tcp --dport 1337 -j DNAT --to-destination 5.45.100.191:1337
but thats not working, i think its connecting but it keeps spamming a system #random number# message.
This post might belong to tech support: http://ppcointalk.org/index.php?topic=501
I give an answer there ;)
For convenience: http://ppcointalk.org/index.php?topic=501.msg3677#msg3677
-
Stats are nice, i was bored so i build this xD
http://xpm.syware.de/?address=AbB7cgdEXr3hJ254qFW1QqAecLGfW9XyGU
[...]
Nice job! Thanks for sharing!
-
hi,
just fyi - what will be done next:
i think it is the best to rework the web interface a little bit (read: add more global/personal stats) before i make my final decision about the share value & payout system. so we'll still have enough time to go through all the aspects of every option and maybe until then we can have some proper stats from the pool itself. btw faster payouts can be another advantage
despite this, i see that few mining machines still have some problems with rejects (talking about v0.2 miners in particular), i will have to look into that issue.
PLEASE USE THIS THEAD (http://ppcointalk.org/index.php?topic=501.0) FOR TECHNICAL ISSUES/PROBLEMS/QUESTIONS WITH THE POOL or MINER(S)
thank you
i think i have to spam this on every new page on this thread ... kinda sad
- xolokram
Stats are nice, i was bored so i build this xD
http://xpm.syware.de/?address=AbB7cgdEXr3hJ254qFW1QqAecLGfW9XyGU
Oh and please rename your time variable to something else, php just ignores that value, can't access it, guess it's a protected word...once i can access time i can calculate daily avg - i want to add which blocks have already been paid too ^^
Dude, this is so awesome! Thanks :D
Question: why are some diff's green and some red? :)
-
Dude, this is so awesome! Thanks :D
Question: why are some diff's green and some red? :)
Green is lower diff than before (good) red is higher (bad) - it's just a gimmick :D
-
Dude, this is so awesome! Thanks :D
Question: why are some diff's green and some red? :)
Looks like rising diffs are red and falling diffs are green...
-
Dude, this is so awesome! Thanks :D
Question: why are some diff's green and some red? :)
Green is lower diff than before (good) red is higher (bad) - it's just a gimmick :D
Awesome. Thanks again!
When you do get the time value sorted, could you make the paid blocks disappear (so only unpaid blocks are on the page), and have a separate link to 'History' or something like that?
Just an idea :)
-
Dude, this is so awesome! Thanks :D
Question: why are some diff's green and some red? :)
Green is lower diff than before (good) red is higher (bad) - it's just a gimmick :D
Awesome. Thanks again!
When you do get the time value sorted, could you make the paid blocks disappear (so only unpaid blocks are on the page), and have a separate link to 'History' or something like that?
Just an idea :)
I wanted to scan the paid blocks page, then match that with your mined blocks to mark the ones that are paid - then sum up your xpm until it goes above 3 where a payout happens - i could of course then hide those blocks, guess my list isnt long enough yet xD
-
I wanted to scan the paid blocks page, then match that with your mined blocks to mark the ones that are paid - then sum up your xpm until it goes above 3 where a payout happens - i could of course then hide those blocks, guess my list isnt long enough yet xD
Sounds good, can't wait to see the upgrades! :)
-
I wanted to scan the paid blocks page, then match that with your mined blocks to mark the ones that are paid - then sum up your xpm until it goes above 3 where a payout happens - i could of course then hide those blocks, guess my list isnt long enough yet xD
Sounds good, can't wait to see the upgrades! :)
Mostly done, just too lazy to add the hide option - have to rewrite everything object orientated to easily do that xD
-
Mostly done, just too lazy to add the hide option - have to rewrite everything object orientated to easily do that xD
Does the script automatically determine the blocks that have been found by the pool? I'm asking because the pool has 162537 as last found block, but your overview ends at 162486 (the second last block).
-
Mostly done, just too lazy to add the hide option - have to rewrite everything object orientated to easily do that xD
Does the script automatically determine the blocks that have been found by the pool? I'm asking because the pool has 162537 as last found block, but your overview ends at 162486 (the second last block).
Yes but i set the "check for block data" timer to 1 hour, i've reduced it to 10 minutes.
- Sy, what exactly is the Payout column? The values in Payout are higher than the values in 'XPM'. Thanks in advance.
-
Sy, what exactly is the Payout column? The values in Payout are higher than the values in 'XPM'. Thanks in advance.
Payout is your accumulated XPM up to 3 XPM where a payout to your account happens, it then resets back to 0.
-
Sy, what exactly is the Payout column? The values in Payout are higher than the values in 'XPM'. Thanks in advance.
Payout is your accumulated XPM up to 3 XPM where a payout to your account happens, it then resets back to 0.
Ah, of course. I need to go to bed, lol. Thanks for clarifying.
-
Sy, what exactly is the Payout column? The values in Payout are higher than the values in 'XPM'. Thanks in advance.
Payout is your accumulated XPM up to 3 XPM where a payout to your account happens, it then resets back to 0.
Ah, of course. I need to go to bed, lol. Thanks for clarifying.
I've renamed it to Stash, couldn't come up with a better name :D
Also rounded the xpm to 4 digits, no one cares for the others anyway ^^
-
Sy, what exactly is the Payout column? The values in Payout are higher than the values in 'XPM'. Thanks in advance.
Payout is your accumulated XPM up to 3 XPM where a payout to your account happens, it then resets back to 0.
Ah, of course. I need to go to bed, lol. Thanks for clarifying.
I've renamed it to Stash, couldn't come up with a better name :D
Also rounded the xpm to 4 digits, no one cares for the others anyway ^^
Awesome! Now, once we get to the point where we have been mining for 500 or 1000 blocks, does that mean we will have to scroll all the way down? :p
-
Sy, what exactly is the Payout column? The values in Payout are higher than the values in 'XPM'. Thanks in advance.
Payout is your accumulated XPM up to 3 XPM where a payout to your account happens, it then resets back to 0.
Ah, of course. I need to go to bed, lol. Thanks for clarifying.
I've renamed it to Stash, couldn't come up with a better name :D
Also rounded the xpm to 4 digits, no one cares for the others anyway ^^
Awesome! Now, once we get to the point where we have been mining for 500 or 1000 blocks, does that mean we will have to scroll all the way down? :p
Haha i'll tweak it some more if the pool doesn't create it's own stats - this might just be temporary after all :)
But there is the posibility of summaries at the top 8)
- Could take a while for the pool to have it's own stats, though. Haha. Anyway, so far so good. Job well done, will definitely be using this!
-
Could take a while for the pool to have it's own stats, though. Haha. Anyway, so far so good. Job well done, will definitely be using this!
Thanks, im still waiting for my next solo block to be found so i can finally switch to this pool for good ;D
- @Sy:
wow, that's awesome. thank you for your work, maybe i'll just add a few more pages for raw data and leave the dirty details of creating a proper overview to projects like yours --- at least this gives me some time to concentrate on the 'important' issues like connections/rejection problems & the payout system. I see you fixed the 'time' field issue already.
just fyi, payouts with a reward of 0 are orphans, don't know if you already recognized this. as far as i know, this happened twice by now.
good job!
oh, we're on a new page?
PLEASE USE THIS THEAD (http://ppcointalk.org/index.php?topic=501.0) FOR TECHNICAL ISSUES/PROBLEMS/QUESTIONS WITH THE POOL or MINER(S)
thank you
- xolokram
-
Thanks, im still waiting for my next solo block to be found so i can finally switch to this pool for good ;D
Also, if you're feeling REALLY excited to work, you could add something that calculates how many XPM per 24 hours we're making. You'd just look at how many XPM you make per hour, do that times 24 and print it. Of course it wouldn't be exactly correct, but it should give you an idea.
I'm not telling you what to do though! Just bringing up ideas. You can do with it whatever you want, lol :)
@Sy:
wow, that's awesome. thank you for your work, maybe i'll just add a few more pages for raw data and leave the dirty details of creating a proper overview to projects like yours --- at least this gives me some time to concentrate on the 'important' issues like connections/rejection problems & the payout system.
just fyi, payouts with a reward of 0 are orphans, don't know if you already recognized this. as far as i know, this happened twice by now.
good job!
oh, we're on a new page?
PLEASE USE THIS THEAD (http://ppcointalk.org/index.php?topic=501.0) FOR TECHNICAL ISSUES/PROBLEMS/QUESTIONS WITH THE POOL or MINER(S)
thank you
- xolokram
Xolokram, I know currently each share (6+) has the same value, but what value is this exactly? Thanks in advance.
-
Stats are nice, i was bored so i build this xD
http://xpm.syware.de/?address=AbB7cgdEXr3hJ254qFW1QqAecLGfW9XyGU
Oh and please rename your time variable to something else, php just ignores that value, can't access it, guess it's a protected word...once i can access time i can calculate daily avg - i want to add which blocks have already been paid too ^^
Oh nice! A lot of cheers to you, sir! 8)
-
@Sy:
wow, that's awesome. thank you for your work, maybe i'll just add a few more pages for raw data and leave the dirty details of creating a proper overview to projects like yours --- at least this gives me some time to concentrate on the 'important' issues like connections/rejection problems & the payout system. I see you fixed the 'time' field issue already.
just fyi, payouts with a reward of 0 are orphans, don't know if you already recognized this. as far as i know, this happened twice by now.
good job!
oh, we're on a new page?
PLEASE USE THIS THEAD (http://ppcointalk.org/index.php?topic=501.0) FOR TECHNICAL ISSUES/PROBLEMS/QUESTIONS WITH THE POOL or MINER(S)
thank you
- xolokram
More raw data is fine with me and yeah, there was just no time for the first blocks (guess you added it later) and when i checked why i couldn't access it i always took a random block, saw time and thought WTF! xD
I'll have to add database support though and write everything in there if i want to create extensive stats - currently just saving all the block and payout data to file and parsing it ;D
-
Also, if you're feeling REALLY excited to work, you could add something that calculates how many XPM per 24 hours we're making. You'd just look at how many XPM you make per hour, do that times 24 and print it. Of course it wouldn't be exactly correct, but it should give you an idea.
I'll go for real 24h i think but yeah, that's always interesting :)
-
Xolokram, I know currently each share (6+) has the same value, but what value is this exactly? Thanks in advance.
the value of a share is calculated block-wise. the value of your shares is your stake (is that the correct word?) of the shares of all users for the block --> converted to XPMs, depending on the reward the block gave to the pool. 6-, 7-, 8-, 9- ... -chain-shares are valued equal at the moment, this will probably change in the future.
i hope i understood and answered your question correct :D
@Sy:
you can calculate a "virtual time" for the block as the average time per block should be 1 minute (just use the height number to calculate the time). or maybe i will add the time manually to the first blocks as the primecoin network records the creation time for every block.
- xolokram
ps. @all: please don't double post (use modify instead, as long as nobody answered) and don't quote the full post for small independent questions; it will keep the thread a little more clean than those huge repeating posts
-
you can calculate a "virtual time" for the block as the average time per block should be 1 minute (just use the height number to calculate the time). or maybe i will add the time manually to the first blocks as the primecoin network records the creation time for every block.
Pretty neat, didn't think of that :D diff retargets every block right? So it should actually be pretty accurate 8)
- yup, difficulty & reward is calculated for every block
/edit:
you should be aware of possible orphan blocks: http://www.beeeeer.org/payout/155339
no reward for this one
- xolokram
-
Stats are nice, i was bored so i build this xD
http://xpm.syware.de/?address=AbB7cgdEXr3hJ254qFW1QqAecLGfW9XyGU
Oh and please rename your time variable to something else, php just ignores that value, can't access it, guess it's a protected word...once i can access time i can calculate daily avg - i want to add which blocks have already been paid too ^^
Oh nice! A lot of cheers to you, sir! 8)
Sy, Great job thankyou so much... now i have an idea when i'm getting paid :)
-
yup, difficulty & reward is calculated for every block
/edit:
you should be aware of possible orphan blocks: http://www.beeeeer.org/payout/155339
no reward for this one
- xolokram
I pulled all times out by hand using getblockhash(id) and getblock(hash), there is no guessing in statistics! ;D
Ah only way to see if its orphan is by parsing the whole payout? Okay...
- I just recieved my first 3xpm !!! not bad for my FX8350 8 core cpu ! :)
-
I just recieved my first 3xpm !!! not bad for my FX8350 8 core cpu ! :)
Depends on the timeframe ;D
-
Ah only way to see if its orphan is by parsing the whole payout? Okay...
correct, as the block information contains only the information about the block at creating time, the "reward" field there should be taken as "expected reward". The payout script is responsible for checking on confirmations & orphans.
- Very interesting. Thanks for answering my questions, xolokram. You're doing a nice job here :)
-
I just recieved my first 3xpm !!! not bad for my FX8350 8 core cpu ! :)
Depends on the timeframe ;D
Well heres the block info http://xpm.syware.de/?address=AQAdmZHMFdRhviD76zuaF7Aq3bDAr5ycEL
Any good??
-
linux user can test the first release candidate (not final) for v0.3, pull the latest source from bitbucket or github & compile
- minor changes/bugfixes
- merge with latest commits by mikaelh (thanks)
- experimental reconnect-fix on share submission
- rename to "xolominer" (in startup info)
- xolokram
-
linux user can test the first release candidate (not final) for v0.3, pull the latest source from bitbucket or github & compile
[...]
- xolokram
Do you plan creating Linux binaries as well in the future? The thing is, I have some low budget root servers with low RAM and restrictions that prohibit using swap. So I would be glad to use them for testing, too ;)
My 2 main machines are already running the 0.3 RC0. Looks good so far.
I'm totally amazed how fast you bring this pool forward. Thank you for that!
p.s. and I'd highly appreciate a Windows binary of 0.3 once it's released :) Want to bring more machines to the pool!
-
linux user can test the first release candidate (not final) for v0.3, pull the latest source from bitbucket or github & compile
- minor changes/bugfixes
- merge with latest commits by mikaelh (thanks)
- experimental reconnect-fix on share submission
- rename to "xolominer" (in startup info)
- xolokram
Thanks, I'm giving it a go at the moment. No problems so far :)
- unfortunately, i'm not on a windows machine right now. i'll do that tomorrow for windows. linux binaries are pretty bogus in my opinion, but you're right, the current makefile (aka build script) needs to much RAM. as i'm not using all the original primecoind source any longer with my new protocol this can be changed. i will update the makefile to use less RAM soon.
- xolokram
ps. actually i wanted to add some more significant features to the miner, but mikaelh released his commits today, so i just gave it a shot as a minor release candidate
pps. the current block is really annoying ... 40k+ shares
-
[...]
pps. the current block is really annoying ... 40k+ shares
Either the pool is very unlucky or something is wrong considering that it is roughly 90 minutes ago since we found the last block. But I bet it's only bad luck :D
[edit]
I knew I had to name it.
*SOLVED*
:D
[/edit]
- haha, gj --- thank you "...ohY8WccpK", our savior ;)
ps. next block!! that's how it should work...
-
haha, gj --- thank you "...ohY8WccpK", our savior ;)
ps. next block!! that's how it should work...
This time i was only _thinking_ about it ;)
- Another one of those crazy blocks.. what's going on :(
-
@xolokram and @jh00, mainly.
I think that I found the solution for the proper share value in a Primecoin pool. It is strongly based on the assumption that the probability distribution of lengths of chains is always an exponential (different for each miner), or at least the tail of the distribution (for lengths greater than a minimum). If the assumption was not valid, the method would not be valid too.
I am pretty convinced that the assumption is valid, as it depends basically on the probability of finding primes. Tweaking the software to change the natural distribution would not be worthwhile, if you are able to find many short chains, it will be worth to test the next length, and that will be enough to get an exponential distribution of lengths.
The share value will be the estimation of the statistically expected blocks for each worker and each round from his submited chains. The sum of the estimated blocks for all the workers in a round should be close to 1.
Let:
N(x): number of chains of length greater or equal (GE) than x
m: minimum accepted lenght (note that N(m) = total number of accepted shares)
d: floor of difficulty, required length of chain for a block
then: share value = <blocks> = <N(d)>
and: <N(d)> = N(m+1) * ( N(m+1) / N(m) )^(d-m-1)
Let me explain the criteria and how to obtain this result. Suppose that 6 is the minimum accepted length of chains. If probability distribution is exponential on the chain length, the base, B, of the exponential function can be measured as the ratio of chains of length 7 to chains of length 6. But it can be more accurately measured as the ratio of chains greater than (GT) 6 to chains greater or equal (GE) than 6. In this way, every chain is counted for the measurement. The expected number of chains greater than x (GE x+1) is then estimated as:
<N(x+1)> = N(x)*B
which is the same as <N(x+1)> = N(x) * N(x+1) / N(x) , does everybody agree ;-) ?
The base of the exponential distribution should be constant on x. So, to estimate number of chains greater than any length we compute:
<N(x+a)> = N(x) * B^a
= N(x) * ( N(x+1) / N(x) )^a
= N(x+1) * ( N(x+1) / N(x) )^(a-1) , to simplify computation
Note that only N(x) and N(x+1) are needed. Now, if we want to compute the estimated chains greater or equal than the floor of difficulty, and the minimum accepted length is m, we get the formula at the begining of the post. For example, in the present time with difficulty floor = 9, and for minimum accepted lenght = 6:
share value: N(7) * ( N(7) / N(6) )^2
Let's analyze some features of this scheme of valuation:
- it is fair, because it tries to estimate the mean of blocks per round that each worker would find
- it is a natural way of estimating the contribution of each one
- it measures as accurately as possible the computing work of each worker, balanced by his estimated efectiveness
- it is proportional to the total number of submitted chains, N(m), but it is weighted by a factor, B^(d-m), that characterize the "quality" of each worker depending on the software used, the tunning of its parameters, etc
- it minimize variance for the worker, because N(m) and N(m+1) are quite stable for equal periods of time
- it promotes the searching of longer chains for both, workers and developers, because it is worth trying to maximize B (as it exponentiated) instead of just N(m)
- it is easy to implement for the pool developers
- the pool must try to accept the shorter lenghts that he could manage, as the method needs chains of at least two lengths (very small contributions will be valued as 0, or will have big variance)
- also the greater the number of chains the better the accuracy (it would be good for it to accept length 5)
- @patapato & theprofileth:
check out THIS (http://ppcointalk.org/index.php?topic=501.msg3762#msg3762)
it may help
- xolokram
- After using jhprimeminer V3.3beta for 3 days and then xolominer V0.2 for 2 days i can confirm the xolominer even with the rejects finds 10-20% more shares!
- to be fair:
the jhPrimeminer has to use the (less efficient) 'getwork' protocol on my server. so, a comparison based on the absolute amount of shares is not really a good idea. however, the 'quality' of shares should be comparable. (for a share amount comparison jhprimeminer has to implement my custom protocol or vice versa)
- xolokram
-
hi,
i can tell you that the current overall rate is:
valid = ~260000
rejected = ~12000
stale = ~2000
total = ~274000
-> 4,4% rejected & 0,7% stale
this is only regarding the new protocol 'getworx' (my miner v0.2 or higher); for the old 'getwork' protocol (v0.1 & jhPrimeminer) it's worse (but the total shares are only ~20k)
concerning the chain length, the current rates are:
'getwork' (old, v0.1 & jhPrimeminer)
6 = ~14470 (94,22%)
7 = ~810 (5,27%)
8 = 73 (0,469%)
9 = 4 (0,026%)
total = 15357
'getworx' (new, v0.2 or higher)
6 = ~236070 (90,75%)
7 = ~21900 (8,42%)
8 = ~2080 (0,799%)
9 = 90 (0,034%)
9,85 or higher = 21 (0,0080726%) (hitting the current target length, aka block found) /corrected: there was a mistake in the calculation
total = 260140
from the raw values (although the 'getwork' values are not as reliable as the 'getworx' values) i would prefer v0.2 or higher
maybe this will help you (regarding rejection rates) and others (regarding chain length)
i'm surprised by the values for 8- to 9-chains (instead of 9% it's a <5% factor)
- xolokram
ps. this probably will be a cross-post to the general discussion, as the values can be very interesting for the share-value / payout discussion
Here are some statistics after running version f8cf45 (mikaelh's change added) for 12.7hr
6ch 337 91%
7ch 30 8%
8ch 3 0.8%
valid 370 88%
rejects 46 11%
stale 3 0.7%
Compare with a 9.5 hours run on previous version ( http://ppcointalk.org/index.php?topic=501.msg3759#msg3759 ) the new version has less chains found per hour. But this might be caused by daily periodical changes. It often seems more shares are found when it is day time in the US/Western Europe.
Rejection rate is comparable to the previous test.
-
to be fair:
the jhPrimeminer has to use the (less efficient) 'getwork' protocol on my server. so, a comparison based on the absolute amount of shares is not really a good idea. however, the 'quality' of shares should be comparable. (for a share amount comparison jhprimeminer has to implement my custom protocol or vice versa)
- xolokram
Would you be able to put the 0.3 Windows version up today? :)
- hi
sorry for the late reply
windows binary: primeminer v0.3 RC0 (http://www.mediafire.com/download/1j6p5v1q349q8bb/primeminer_v03_x86_and_x64.zip) *experimental*
(contains 32 and 64 bit version, it's based on mikaelh's hp11)
- xolokram
ps. v0.4 will take a little bit longer as i plan to add some more features to the protocol (and maybe will add xpt support to the pool)
-
hi
sorry for the late reply
windows binary: primeminer v0.3 RC0 (http://www.mediafire.com/download/1j6p5v1q349q8bb/primeminer_v03_x86_and_x64.zip) *experimental*
(contains 32 and 64 bit version, it's based on mikaelh's hp11)
- xolokram
ps. v0.4 will take a little bit longer as i plan to add some more features to the protocol (and maybe will add xpt support to the pool)
Hello Xolokram
Just tried your V0.3 and its affected my performance chain/d was 2.2 now 1.6 on V0.3 gone back to 0.2
I know its experimental i'll wait until V0.4 :)
-
hi
i experienced the same, it's because of the last commits by mikaelh. he changed one of the default mining settings to suit the current difficulty. this should result in less shares, but longer chains (on average). we should change the value of the shares asap to make tweaking the miner for higher rates on longer chains (what the intention of mikaelh's commit was & the intention of every pool should be) more profitable. i'll have to test this more
- xolokram
-
hi
i experienced the same, it's because of the last commits by mikaelh. he changed one of the default mining settings to suit the current difficulty. this should result in less shares, but longer chains (on average). we should change the value of the shares asap to make tweaking the miner for higher rates on longer chains (what the intention of mikaelh's commit was & the intention of every pool should be) more profitable.
- xolokram
ps. by tweaking the miner for more shorter chains you increase your personal share ratio in return of less blocks overall
how would one tweak the miner to begin with?
- @xTachibana: the miner is based on primecoind/mikaelh
you can use:
-sieveextensions
-sievepercentage
&
-sievesize
be sure that the share value (by chain length) will be changed next
- xolokram
-
@xTachibana: the miner is based on primecoind/mikaelh
you can use:
-sieveextensions
-sievepercentage
&
-sievesize
be sure that the share value (by chain length) will be changed next
- xolokram
what do you recommend for duo cores :O? i was using 500 sieve size while on ypool, not sure if thats good here as well, also im not sure what sieve extensions and sievepercentage do
- i can tell you to use the default settings as i've not tested the settings enough to give you a proper answer. because i had to concentrate on other stuff than testing parameters (mainly due to unexpected coding sessions ::) )
but maybe other users can tell you something about their experience?!
- xolokram
ps. it would be cool to see whether the average of "shares needed per block" were going up or down after release of v0.3 ... Sy??? :)
pps. with the information about mining parameters i guess the shares per block will go up... yup, i'm pessimistic...
- I have a feeling my income will drastically decrease once you implement the share value rewards. Stick with the current plan! :D
-
I have a feeling my income will drastically decrease once you implement the share value rewards. Stick with the current plan! :D
Yes i have the same feeling too!.... we dont want another ypool clone .. I came here because ypool was shit for small miners like me as soon as I started here my xpm tripled please please leave it as it is!!!!
-
I have a feeling my income will drastically decrease once you implement the share value rewards. Stick with the current plan! :D
Yes i have the same feeling too!.... we dont want another ypool clone .. I came here because ypool was shit for small miners like me as soon as I started here my xpm tripled please please leave it as it is!!!!
My thoughts exactly. If you're going to have share values (like ypool does), we may as well go back to ypool since their hashrate is so much higher. Your pool is interesting BECAUSE of the way it deals with shares. It makes it very interesting for both us smaller miners, and the big guys!
- How much you get payed and how much you put in should be proportional, not simply higher cause you want it to be.
I mean how many blocks are you finding? If the answer is none be happy you get payed at all.
-
Here are some statistics after running version f8cf45 (mikaelh's change added) for 12.7hr
6ch 337 91%
7ch 30 8%
8ch 3 0.8%
valid 370 88%
rejects 46 11%
stale 3 0.7%
Compare with a 9.5 hours run on previous version ( http://ppcointalk.org/index.php?topic=501.msg3759#msg3759 ) the new version has less chains found per hour. But this might be caused by daily periodical changes. It often seems more shares are found when it is day time in the US/Western Europe.
Rejection rate is comparable to the previous test.
9.5 hours test (including a period of maintenance of the pool). The miner xterm somehow died not long before I checked so I didn't get to see the statistics. But from Sy's record page (Thanks Sy! :) Would be nice to add share statistics ) the XPM earning rate is within 3% compared the test before hp11 change was implemented yesterday ( http://ppcointalk.org/index.php?topic=501.msg3759#msg3759 )
-
hi
it would've been useful if one of the measurements we're scaled down/up to the other (especially on a logarithmic scale). absolute values are pretty useless in the way you used them; and i'm not talking about factors/improvements of 2x or higher.
i was surprised by the fall of the ratio from the 9-chains to 8-chains; compare it to 8-to-7 and 7-to-6.
- xolokram
I did the scaled comparison, as you suggest. Here is the cumulated number of chains from your data (http://ppcointalk.org/index.php?topic=501.msg3762#msg3762), that is, the chains longer or equal than each size. Columns 2 and 3 are your data, column 4 is the ratio of v0.2 to v0.1 for each size, and column 3 is the scaled v0.2 that best fit to v0.1.
| Chain length |
getworx', v0.2 |
getwork', v0.1 |
v0.2 / 28 |
v0.2 / v0.1 |
| 6 |
260161 |
15357 |
9291.46 |
16.94 |
| 7 |
24091 |
887 |
860.39 |
27.16 |
| 8 |
2191 |
77 |
78.25 |
28.45 |
| 9 |
111 |
4 |
3.96 |
27.75 |
| 9.85 |
21 |
|
0.75 |
You can see that lengths 7, 8 and 9 are "exactly" the same with a factor 28, I put the scaled v0.2 close to v0.1 in order that you see how much it fits. The data which is more different between both distributions is the 6-length chains. Here is the graph to see it better:
(http://i.imgur.com/MKxWGAF.png)
What is clear for me is that the best method for share values will be the one which better estimate the expected blocks. It is quite the same as better extrapolating the distribution from the submitted data.
The method that I proposed (http://ppcointalk.org/index.php?topic=485.msg3761#msg3761) consists basically in extrapolate it from the two first points. But it is not the best possible way, now I see. I see clearly that only the tail of the distribution is exponential, not the whole distribution. The effect of a better sieving is to curve down the begining of the distribution, getting a scaled up tail. In the case of the present data, you can see that the number of chains greater or equal than 7 gives a very accurate measure for the chains greater or equal than 9 (and it would be also for >= 9.85).
- An important observation here is that the last point corresponding to the exact difficulty, 9.85, will always be higher than the extrapolated distribution of integer lengths. It is because the distribution of the fractional part is not exponential, but uniform.
In linear scale it is the same as straight lines between each length, with angles on the integer points. In log scale it will be like lobes in the up side of the straight line from one integer length to the next. You can see clearly that effect on the difficulty graphs (http://xpm.muuttuja.org/charts/). That is why the difficulty grows quickly after reaching each integer, and slowly later. (sorry my english, I'm not able to describe it better).
That is why the point for length 9.85 in the graph is too high for the distribution. But that effect will be equal for everybody.
- i agree with bram on the share value point, there is no real benefit to being in beeeeer if you're going to do the same thing as ypool, the main reason people are coming over here is because they like the way you pay out, that and beer :B, we all love beer.
- sometimes i see
"6": 5,
"165390": 1,
"-6": 1
},
i guess a small bug in the stats?
- i can't compile this client on my linux machines.
Any package needed to compile on ubuntu/debian?
-
i can't compile this client on my linux machines.
Any package needed to compile on ubuntu/debian?
Ok, my problem solved, I just need to install libdb4.8++-dev before compile.
- @CoinBuzz:
please use the technical support thread next time.
@irritant:
the 'high' number in the stats indicate the blockheight, that means this miner found the block.
@patapato:
problem(?): can you tell me, that finding 4 9-chains took the same time for v0.1 & v0.2 (your chosen pivot element)?? i can tell you that v0.2 needed ~25% less shares in total for the 4 9-chains. if you chose 6-chains as pivot element it will result in "more" 9-chains for v0.2 at comparable number of shares in total.
<i will come back later to your suggestions / ideas / posts & we still have to find a good share value distribution, theprofileth: some ideas? :) sorry, i'm in a hurry right now, will be back later>
@brampoer & roger:
but you don't want to have an advantage for people tweaking for low-length-chains (which is bad for the pool & ALL users), don't you?
(referencing theprofileth's post) i'll not force or beg you to use my pool, but in the end we have to find smart solutions for problems like the disparity in (tweakable) quantity of 6-chain shares versus 9-chain shares.
- xolokram
- Of course you don't want people tweaking for lower shares. However, you have to keep in mind that not all of us have computers that pull 50 9-chains per hour out. I like this pool because it's an excellent pool for us smaller miners. There has to be something else we can do to prevent tweaking for lower vals. I hope you rethink it :)
-
Of course you don't want people tweaking for lower shares. However, you have to keep in mind that not all of us have computers that pull 50 9-chains per hour out. I like this pool because it's an excellent pool for us smaller miners. There has to be something else we can do to prevent tweaking for lower vals. I hope you rethink it :)
+1
- Sorry been away the past couple days will have more time to respond on Monday or maybe tomorrow. :'(
However it seems like a lot of "poor me I don't actually contribute to anything but I wanna get payed more than other people" from my point of view ::)
-
Of course you don't want people tweaking for lower shares. However, you have to keep in mind that not all of us have computers that pull 50 9-chains per hour out. I like this pool because it's an excellent pool for us smaller miners. There has to be something else we can do to prevent tweaking for lower vals. I hope you rethink it :)
Since it's open source we have to find a solution together and weighting the shares seem the obious and fair choice. You get paid for the amount of computer power you put to find the block and its clear that longer shares require more cpu cycles.
Another solution could be a cheating detection system based based on statistics, but how do u ban someone and prevent him from changing his ip or xpm address?
-
Sorry been away the past couple days will have more time to respond on Monday or maybe tomorrow. :'(
However it seems like a lot of "poor me I don't actually contribute to anything but I wanna get payed more than other people" from my point of view ::)
+1
-
[...]
Since it's open source we have to find a solution together and weighting the shares seem the obious and fair choice. You get paid for the amount of computer power you put to find the block and its clear that longer shares require more cpu cycles.
[...]
+1
I understand that weighted shares seem frustrating for those who don't get high numbers of long chains. But it is no fair share model if all shares are equally rewarded.
- there's the danger of sleazebags tuning their mining software to produce only short chains but higher amounts of them to get an unfair share of the rewards
- short chains don't directly contribute to solving blocks, only if you count them as byproduct on the way to find sufficiently long chains they are worth of something
If you could completely make sure that manipulating the mining software was impossible, then it wouldn't be a big difference whether you gave the longer chains more weight or not as the higher computing power produces not only higher amounts of long chains but lots more short chains as well.
But as I see no real effective way for locking manipulated clients out, I highly recommend giving the shares a weight.
I might argue in a different way if there was a way known to produce efficiently more long chains but only those long enough to gain more outcome but not long enough to produse more blocks.
I only might argue differently, because the last way could be a kind of evolutionary step of the algorithm and could - at least for me - be appreciated. Especially if you could develop that idea far enough to effectively produce more chains that are long enough for solving blocks (no matter how long the chains had to be) ;) .
But thats a little bit subjunctive, so currently I stick to this demand:
As long as there's no way known to lock out short chain producing mining clients, I stick to the call for fairly weighted shares.
- ok so on my tiny amount of cpu power i've managed to find 2 blocks in 6 days amounting to 20xpm mining here has made me 17xpm uncluding unconfirmed does that make me a leech.. all me and bram are saying is that we dont want another ypool clone. make it fair to everyone small miners and big alike or otherwise i'll just buy more gpu's and use mobo's to mine LTC simple as that .... end of story no ones a winner...
- Oh yes or just wait another month or two for the gpu miner then you are all fucked.....
- I never said it was not fair, it's funny how some of you get ridiculously offended by what I'm saying. All I am saying is that we don't need another ypool. If you like share values and all that so much, move your miners to ypool and you can just sit there and have fun over there.
We don't need 80 pools that do the exact same thing, now do we? This pool is great because we actually have the chance to do something different here. As said before, this is open source and we should set something up that everyone is comfortable with (in my opinion). If you can't deal with it, so be it. If that offends you, I have bad news for you.
- While I understand the "We don't want another yPool" comments, sadly there's a reason why they had to put a weighting to their shares. I agree they were a bit aggressive about it, which is probably why they recently adjusted their share values again.
However, the fact remains that no one gets paid until blocks are found, and blocks aren't found with 6-chains...
I do have a possible solution to this, although I don't know how much work it would take to implement.
Have 2 options using different workers or URLs or ports for mining at beeeeer.org
One option would have weighted shares, the other the same value for all shares. I would imagine that the miners with more powerful CPUs would want to use the weighted option, but at least you would have the choice.
I'm sure that right now Xolokram has to focus on the mining software development and stability of the pool, but if this sounds like a feature people would like then maybe it can go on a to do list.
-
While I understand the "We don't want another yPool" comments, sadly there's a reason why they had to put a weighting to their shares. I agree they were a bit aggressive about it, which is probably why they recently adjusted their share values again.
However, the fact remains that no one gets paid until blocks are found, and blocks aren't found with 6-chains...
I do have a possible solution to this, although I don't know how much work it would take to implement.
Have 2 options using different workers or URLs or ports for mining at beeeeer.org
One option would have weighted shares, the other the same value for all shares. I would imagine that the miners with more powerful CPUs would want to use the weighted option, but at least you would have the choice.
I'm sure that right now Xolokram has to focus on the mining software development and stability of the pool, but if this sounds like a feature people would like then maybe it can go on a to do list.
This idea is actually not bad. We should have a testrun with this.
-
While I understand the "We don't want another yPool" comments, sadly there's a reason why they had to put a weighting to their shares. I agree they were a bit aggressive about it, which is probably why they recently adjusted their share values again.
However, the fact remains that no one gets paid until blocks are found, and blocks aren't found with 6-chains...
I do have a possible solution to this, although I don't know how much work it would take to implement.
Have 2 options using different workers or URLs or ports for mining at beeeeer.org
One option would have weighted shares, the other the same value for all shares. I would imagine that the miners with more powerful CPUs would want to use the weighted option, but at least you would have the choice.
I'm sure that right now Xolokram has to focus on the mining software development and stability of the pool, but if this sounds like a feature people would like then maybe it can go on a to do list.
This idea is actually not bad. We should have a testrun with this.
You know that this would mean you would need to basically be running 2 pools which would split the hashrate and increase orphans for both sides. Furthermore if you have the option to do unweighted or weighted you will just pick whatever benefits you more and if it is benefiting you more then odds are it is benefiting the pool less. God this thread became full of either very naive or very malicious people since I stopped posting for a few days.
- hi, i'm back. it's good to see some discussion on the latest topics.
i'm reading patapato's & profileth's (older) posts to recollect the most mature ideas for the payout/share value discussion. i will also try to phrase an idea i had.
@alex,bram:
a second pool for comparison? it's splitting the community and the additional work/monitoring. i don't know. i will keep it in mind.
btw these 2 pools should be total independent.
@pt0x,masterofdesaster,profileth,patapato&co.:
i agree, thank you
@roger:
no one ever said beeeeer should be a new ypool, but equal value to all shares on primecoin isn't vital at all as it's fairly easy to f*** with the distribution of shares. and i would really love to see a solution that fits for "big players" and "hobby miners" as well. we should work out a good solution all together, simple rambling on how bad everything probably can be isn't really helpful.
- xolokram
ps. the status quo isn't a solution
-
and i would really love to see a solution that fits for "big players" and "hobby miners" as well
This is ironic. Having the set share values will only help the "big players" and kill the "hobby miners". Irony at it's best.
-
will only help the "big players" and kill the "hobby miners"
You are refering to ypool's solution, right? This is not ypool! please refer a post by me or a post in this thread to clarify your assumption (or describe why it's impossible in general?). Or -what would be most useful- give us a idea how to handle the problem with tweakable share distribution. thank you.
- xolokram
-
will only help the "big players"
You are refering to ypool's solution, right? This is not ypool! please refer a post by me or a post in this thread to clarify your assumption. Or -what would be most useful- give us a idea how to handle the problem with tweakable share distribution. thank you.
- xolokram
I am, which is why I (and other people) keep saying that we hope this is not going to turn into a second ypool. It is your pool, you can do with it what you want. I'm definitely enjoying it for now, I hope it stays that way :)
It is hard to come up with a good solution. I get that it is unfair right now, but I am just saying that, IF you were to go into ypool's direction, you're going to kill the small miners. Me and my friends are on this pool right now because it's beneficial for smaller miners, and you don't see that that often.
- since we're gonna be doing it anyways how about something like this
Diif Share Value
6ch .005
7ch .045
8ch .405
9ch 3.645
10ch 10
11ch 20
12ch 45
with this it makes it better for smaller miners (because the difference in share value is only 9x rather than 14.x like ypool), it also is better for bigger miners because 10ch are worth 3x~ more as opposed to merely 50% as on ypool
and to keep it fair, i think it would be best to not have share value carry over to different blocks (pplns)
-
since we're gonna be doing it anyways how about something like this
Diif Share Value
6ch .005
7ch .045
8ch .405
9ch 3.645
10ch 10
11ch 20
12ch 45
with this it makes it better for smaller miners (because the difference in share value is only 9x rather than 14.x like ypool), it also is better for bigger miners because 10ch are worth 3x~ more as opposed to merely 50% as on ypool
This might work. Good idea!
-
@patapato:
i can tell you that v0.2 needed ~25% less shares in total for the 4 9-chains. if you chose 6-chains as pivot element it will result in "more" 9-chains for v0.2 at comparable number of shares in total.
That is why I told that counting chains greater than 7, instead of 6, produce an accurate prediction for 9-chains in this case. I don't mean that it is the general solution. It keeps being a work in progress:
... In the case of the present data, you can see that the number of chains greater or equal than 7 gives a very accurate measure for the chains greater or equal than 9 (and it would be also for >= 9.85).
And that is why I told that the method that I proposed (http://ppcointalk.org/index.php?topic=485.msg3761#msg3761) was not the best.
- this is basically ypool (@xTachibana's post)... i think i'm not getting your point, brampower ;)
- xolokram
xolokram's collection of ideas about share distribution/values: (work-in-progress)
#overview https://bitcointalk.org/index.php?topic=104664.msg1146110#msg1146110
#00 http://ppcointalk.org/index.php?topic=485.msg3399#msg3399
#01 http://ppcointalk.org/index.php?topic=485.msg3407#msg3407
#02 http://ppcointalk.org/index.php?topic=485.msg3761#msg3761
#03 http://ppcointalk.org/index.php?topic=485.msg3417#msg3417
#04 http://ppcointalk.org/index.php?topic=485.msg3433#msg3433
#05 http://ppcointalk.org/index.php?topic=485.msg3446#msg3446 (!)
#06 http://ppcointalk.org/index.php?topic=485.msg3453#msg3453 ^
#07 http://ppcointalk.org/index.php?topic=485.msg3483#msg3483 ^
#08 http://ppcointalk.org/index.php?topic=485.msg3494#msg3494 ^
#09 http://ppcointalk.org/index.php?topic=485.msg3502#msg3502
#10 http://ppcointalk.org/index.php?topic=485.msg3642#msg3642
#11 http://ppcointalk.org/index.php?topic=485.msg3649#msg3649
#12 http://ppcointalk.org/index.php?topic=485.msg3651#msg3651
#13 http://ppcointalk.org/index.php?topic=485.msg3658#msg3658
#14 http://ppcointalk.org/index.php?topic=485.msg3674#msg3674
#15 http://ppcointalk.org/index.php?topic=485.msg3761#msg3761 (!)
#16 http://ppcointalk.org/index.php?topic=485.msg3792#msg3792
-
its better for both small miners and big miners than ypool. not the same aside from the share value idea, also share value wouldnt last for 80 blocks
this is basically ypool (@xTachibana's post)... i think i'm not getting your point, brampower ;)
- xolokram
xolokram's collection of ideas about share distribution/values: (work-in-progress)
#overview https://bitcointalk.org/index.php?topic=104664.msg1146110#msg1146110
#00 http://ppcointalk.org/index.php?topic=485.msg3399#msg3399
#01 http://ppcointalk.org/index.php?topic=485.msg3407#msg3407
#02 http://ppcointalk.org/index.php?topic=485.msg3761#msg3761
#03 http://ppcointalk.org/index.php?topic=485.msg3417#msg3417
#04 http://ppcointalk.org/index.php?topic=485.msg3433#msg3433
#05 http://ppcointalk.org/index.php?topic=485.msg3446#msg3446 (!)
#06 http://ppcointalk.org/index.php?topic=485.msg3453#msg3453 ^
#07 http://ppcointalk.org/index.php?topic=485.msg3483#msg3483 ^
#08 http://ppcointalk.org/index.php?topic=485.msg3494#msg3494 ^
#09 http://ppcointalk.org/index.php?topic=485.msg3502#msg3502
#10 http://ppcointalk.org/index.php?topic=485.msg3642#msg3642
#11 http://ppcointalk.org/index.php?topic=485.msg3649#msg3649
#12 http://ppcointalk.org/index.php?topic=485.msg3651#msg3651
#13 http://ppcointalk.org/index.php?topic=485.msg3658#msg3658
#14 http://ppcointalk.org/index.php?topic=485.msg3674#msg3674
#15 http://ppcointalk.org/index.php?topic=485.msg3761#msg3761 (!)
#16 http://ppcointalk.org/index.php?topic=485.msg3792#msg3792
-
this is basically ypool (@xTachibana's post)... i think i'm not getting your point, brampower ;)
- xolokram
Ypool's share values are much lower, which is not profitable for small miners. With the values xTachibana suggested, both small and big miners will be making what they deserve.
-
and i would really love to see a solution that fits for "big players" and "hobby miners" as well
This is ironic. Having the set share values will only help the "big players" and kill the "hobby miners". Irony at it's best.
???
Irony (http://lmgtfy.com/?q=irony)
Big players find blocks, blocks pay miners, payed miners are happy
Therefor big players make miners happy and payed
Unless you don't like being payed, don't dislike big players
I mean I am a small ass miner I only get like 3 primecoin a day or so mining on ypool no idea how much here
However that isn't the point of a pool.
Pools are suppose to pay out in regular intervals not payout more than solomining, infact you should know that solomining is more profitable if you can stomach the randomness, hence if you want profit you want an exponential payout system that allows even small miners to get payed a lot every once in a while.
Furthermore patapato talked about chains longer than the target ruining it on ypool due to an exponential weight.
What ruined it for people is the fact that the weight wasn't capped at the target height. Furthermore a CPPSRB doesn't store the results of one round over to another which balances randomness with your fair rewards. So really everyone get over yourselves, and wait your turn in line at the soup kitchen already :P
-
and i would really love to see a solution that fits for "big players" and "hobby miners" as well
This is ironic. Having the set share values will only help the "big players" and kill the "hobby miners". Irony at it's best.
Please elaborate.
How will you prevent the pool and the honest members from being fooled by manipulated miners only producing 6-chains (but more than they would, if they were looking for longer chains, too)?
How does granting longer chains a bigger reward kill "hobby miners"? Slow miners produce less XPM per timeframe. Like it or not - statistically this it what happens: slower miners, fewer XPM (per given time frame).
Why should the pool grant slow miners an advantage over faster miners (like it does currently and will do until a fair share reward model has been introduced)?
It might be a better idea to develop a fair model instead of trying to stick to the current one. The pool will die if it gets more attraction and will be joined by dishonest people who try to achieve a an advantage over the others by using "adjusted" miners (I hope that this is not yet the case...)
Just to name my opinion in terms of the weighted shares (math is based on pool info by xolokram (http://ppcointalk.org/index.php?topic=501.msg3762#msg3762)):
A step-up in chain legth should roughly elevenfold the worth of the share - at least based on xolokram's numbers. I made an exception for the 9-chains. Either there's something wrong with the amount of them (or only those that solved blocks are counted?), but based on the numbers the step-up from 8 to 9 would roughly be a factor 23.5...
And maybe we should cut-off the gain in worth at the length that is currently used to solve a block. A 10-chain is nice but not necessary to solve a block (currently), so it is debatable whether to give a 10-chain a higher value than a 9-chain (one reason for doing this could be the fact, that each 10-chain is suffient for solving a block, but only 14% of the currently found 9-chains are...)
-
since we're gonna be doing it anyways how about something like this
Diif Share Value
6ch .005
7ch .045
8ch .405
9ch 3.645
10ch 10
11ch 20
12ch 45
with this it makes it better for smaller miners (because the difference in share value is only 9x rather than 14.x like ypool), it also is better for bigger miners because 10ch are worth 3x~ more as opposed to merely 50% as on ypool
and to keep it fair, i think it would be best to not have share value carry over to different blocks (pplns)
That is quite similar to the yPool (flawed) share value scheme (http://community.ypool.net/index.php?page=Thread&threadID=63):
The new values for each share are as follows:
Diff
Share value
10ch 6
9ch 4
8ch 1
7ch 0.067
6ch 0.0045
To compensate for the higher randomness caused by this change we increased the duration of a share from 40 to 80 blocks.
(http://i.imgur.com/wwIuFl5.png)
-
and i would really love to see a solution that fits for "big players" and "hobby miners" as well
This is ironic. Having the set share values will only help the "big players" and kill the "hobby miners". Irony at it's best.
Please elaborate.
How will you prevent the pool and the honest members from being fooled by manipulated miners only producing 6-chains (but more than they would, if they were looking for longer chains, too)?
How does granting longer chains a bigger reward kill "hobby miners"? Slow miners produce less XPM per timeframe. Like it or not - statistically this it what happens: slower miners, fewer XPM (per given time frame).
Why should the pool grant slow miners an advantage over faster miners (like it does currently and will do until a fair share reward model has been introduced)?
It might be a better idea to develop a fair model instead of trying to stick to the current one. The pool will die if it gets more attraction and will be joined by dishonest people who try to achieve a an advantage over the others by using "adjusted" miners (I hope that this is not yet the case...)
Just to name my opinion in terms of the weighted shares (math is based on pool info by xolokram (http://ppcointalk.org/index.php?topic=501.msg3762#msg3762)):
A step-up in chain legth should roughly elevenfold the worth of the share - at least based on xolokram's numbers. I made an exception for the 9-chains. Either there's something wrong with the amount of them (or only those that solved blocks are counted?), but based on the numbers the step-up from 8 to 9 would roughly be a factor 23.5...
And maybe we should cut-off the gain in worth at the length that is currently used to solve a block. A 10-chain is nice but not necessary to solve a block (currently), so it is debatable whether to give a 10-chain a higher value than a 9-chain (one reason for doing this could be the fact, that each 10-chain is suffient for solving a block, but only 14% of the currently found 9-chains are...)
Oh no, we definitely need to change the system. I definitely don't want the pool to go under because of people trying to cheat the system.
All I'm saying is that it would be great if it wouldn't turn into a 2nd yPool (since ypool is not profitable for small miners).
The share values that xTachibana posted seem pretty reasonable for both small and big miners. That way, people that tune to only find 6ch's will not make as much because a 9ch is much more profitable.
-
if by similar you mean they share the same idea of share value then yes, i suppose they are similar, however your graph doesnt explain anything, it just looks like my idea is worse, the reason i made it so that higher chains are only worth 9x more instead of 14 times more is so that smaller miners dont get complete fucked by 1 person finding 10 9ch per hour (like on ypool, the vast majority of the xpm is being given to the huge miners, and <3xpm is split between 200~ small miners)
since we're gonna be doing it anyways how about something like this
Diif Share Value
6ch .005
7ch .045
8ch .405
9ch 3.645
10ch 10
11ch 20
12ch 45
with this it makes it better for smaller miners (because the difference in share value is only 9x rather than 14.x like ypool), it also is better for bigger miners because 10ch are worth 3x~ more as opposed to merely 50% as on ypool
and to keep it fair, i think it would be best to not have share value carry over to different blocks (pplns)
That is quite similar to the yPool (flawed) share value scheme (http://community.ypool.net/index.php?page=Thread&threadID=63):
The new values for each share are as follows:
Diff
Share value
10ch 6
9ch 4
8ch 1
7ch 0.067
6ch 0.0045
To compensate for the higher randomness caused by this change we increased the duration of a share from 40 to 80 blocks.
(http://i.imgur.com/wwIuFl5.png)
- No seriously guys, you don't seem to understand the issue with your idea of fairness.
Your idea is essentially because someone makes more money than you, you deserve to make more and they deserve to make less.
The reason you don't make any is because you aren't as good as them. If you wanna be as good as them, devote some resources, IE pay for a vpn or a bunch of hardware. Linode (https://www.linode.com/)is really pretty cheap and pretty easy to get set up. If you don't want unfair payout then you want a PPS system and if you want a PPS system you want Capped Pay Per Share with Recent Backpay. I think the issue is that you guys are too focused on keeping things the way they are currently instead of actually using your brains and the resources available to you to actually think of anything of worth other than "Hey guys, I don't like making less money... I should make more... We should make more... Here is a chart about why I should make more money... Can I have more money... ect"
Also if you want evidence of manipulating a miner to spam low chain hashes, compare v0.2 with v0.3 of xolo's miners.
v0.3 is the productive one
v0.2 is the chain spam one
I know this because I am testing it. And will continue to do so until the payout system is changed.
Xolo I applaud you for putting up with people like this. Just remember these are not the majority of your miners, they are just some naive miners who think they know everything about running a pool.
-
No seriously guys, you don't seem to understand the issue with your idea of fairness.
Your idea is essentially because someone makes more money than you, you deserve to make more and they deserve to make less.
The reason you don't make any is because you aren't as good as them. If you wanna be as good as them, devote some resources, IE pay for a vpn or a bunch of hardware. Linode (https://www.linode.com/)is really pretty cheap and pretty easy to get set up. If you don't want unfair payout then you want a PPS system and if you want a PPS system you want Capped Pay Per Share with Recent Backpay. I think the issue is that you guys are too focused on keeping things the way they are currently instead of actually using your brains and the resources available to you to actually think of anything of worth other than "Hey guys, I don't like making less money... I should make more... We should make more... Here is a chart about why I should make more money... Can I have more money... ect"
Also if you want evidence of manipulating a miner to spam low chain hashes, compare v0.2 with v0.3 of xolo's miners.
v0.3 is the productive one
v0.2 is the chain spam one
I know this because I am testing it. And will continue to do so until the payout system is changed.
xTachibana actually just posted a solution that seems to work for both small and big miners. So no, just no.
-
No seriously guys, you don't seem to understand the issue with your idea of fairness.
Your idea is essentially because someone makes more money than you, you deserve to make more and they deserve to make less.
The reason you don't make any is because you aren't as good as them. If you wanna be as good as them, devote some resources, IE pay for a vpn or a bunch of hardware. Linode (https://www.linode.com/)is really pretty cheap and pretty easy to get set up. If you don't want unfair payout then you want a PPS system and if you want a PPS system you want Capped Pay Per Share with Recent Backpay. I think the issue is that you guys are too focused on keeping things the way they are currently instead of actually using your brains and the resources available to you to actually think of anything of worth other than "Hey guys, I don't like making less money... I should make more... We should make more... Here is a chart about why I should make more money... Can I have more money... ect"
Also if you want evidence of manipulating a miner to spam low chain hashes, compare v0.2 with v0.3 of xolo's miners.
v0.3 is the productive one
v0.2 is the chain spam one
I know this because I am testing it. And will continue to do so until the payout system is changed.
xTachibana actually just posted a solution that seems to work for both small and big miners. So no, just no.
Oy vey, ok so his first 4 values IE 6-9 are simply a 0.045 times a multiple of 9 making it an exponential of 9... which is very similar to an exponent of 10. Seriously you are saying if I had said
Dif Share Value
6ch 5
7ch 50
8ch 500
9ch 5,000
10ch 13,717
11ch 27,434
12ch 41,152You would have agreed with me? or do you just like small numbers?
Note those are the EXACT same proportions except the first 4 are a power of 10 * 5
You DO know I believe that the max value should be capped at the target right? IE 9
- ok, here are my current ideas --- yup, multiple ones as we're actually talking about several problems --- (please tear it apart!! ;) ):
1) 'cheat' protection: will give you some factor for your resulting share value
first check the share distribution for
a) all user's in total (aka the average)
b) every single miner/user
compare the resulting histograms ('a' to every 'b')
if the user's distribution is "bad" (many short chains) --> penalty; if it is "good" (many long chains) --> reward
of course, there should be some threshold, and 'reward' & 'penalty' should be a floating value
and the point of time is important (block-wise? daily? per-payout? i don't know by now what's good for this)
reminder: i've not mentioned any values for the penalty/reward
2) share value:
i don't know if it's really needed with the above mentioned cheat protection idea
(less diverse than tachibana's version, capped at current difficulty if it's really necessary)
3) the payout system
CPPSRB? -> HERE (http://eligius.st/~gateway/faq-page)
theprofileth is right; a fixed distribution is not really useful imho
-
[...]
What ruined it for people is the fact that the weight wasn't capped at the target height. [...]
So really everyone get over yourselves, and wait your turn in line at the soup kitchen already :P
I think the fist cited sentence is quite important (and i want to second the following ;) ).
Capping is needed and I suggest capping the weight at a level of +1 (and beyond) of the needed chain-length, because a 10-chain (and an even longer chain) is much better (for the pool in terms of solving a block) than a 9-chain if the difficulty is very close to 10. Or maybe do something like this:
say the difficulty is 9.x [edit] where x is a 2-digit number[/edit]
Then a 10-chain might be worth "x/100" times the standard step-up of a 9-chain while a longer chain is worth the same as a 10-chain.
Or to be more general:
say the difficulty is "a.x". Up to a chain length of "a" you might have an elevenfold of weight (or whatever step-up seems appropriate). Beginning with a chain lenth of "a+1" the weight is capped to 11*x/100.
[edit] And to be even more general here (and considering values of x with variable length):
weight is 11*x/10^(number of digits of x)
[/edit]
This would reduce the reward for people with extraordinary long chains. And that would be beneficial for all shorter chains.
Nevertheless it's not totally unfair, because with "x" getting bigger, a chain that exceeds the length of "a" is getting more and more useful what should make the weight of a chain above the needed minimum length higher - but an a+2 chain is not better for solving a block than an a+1 chain... (although it is more rare)
examples for x=0, 25, 50, 75, 86, 90, 95, 99:
weight for a 10-chain (and longer) in comarison to a 9-chain (elevenfold for step-up assumed):
x=0 translates into 11*0/100 = 0 times the weight for a 10-chain (with a difficulty of 9.0 10-chains are simply not necessary) [edit2] ...maybe this should be 1 instead of 0 as 10-chains are simply as useful as 9-chains ; I'm adding an adjusted formula at the end of this post...[/edit2]
x=25 translates into 11*25/100 = 2.75 times the weight for a 10-chain (and longer)
x=50 translates into 11*50/100 = 5.5 times the weight for a 10-chain (and longer)
x=75 translates into 11*75/100 = 8.25 times the weight for a 10-chain (and longer)
x=86 translates into 11*86/100 = 9.46 times the weight for a 10-chain (and longer)
x=90 translates into 11*90/100 = 9.9 times the weight for a 10-chain (and longer)
x=95 translates into 11*95/100 = 10.45 times the weight for a 10-chain (and longer)
[edit2]Say the current chain length is "a" and the probability for finding a chain of length "a+1" is (1/11)th of that for finding a chain of length "a". Then should the weight for a chain of length a+1 be "1" as long as the difficuly stays below "a.(1/11)". The aforementioned formula should kick in after having passed that difficulty.
In our example with a=9:
weight = 1 for any 10-chain (or longer) as long as the difficulty stays below 9.09090909 (and so forth; to be precise: 100/11...)
weight as aforementioned for each block with a difficulty above that value
[/edit2]
-
ok, here are my current ideas --- yup, multiple ones as we're actually talking about several problems --- (please tear it apart!! ;) ):
1) 'cheat' protection: will give you some factor for your resulting share value
first check the share distribution for
a) all user's in total (aka the average)
b) every single miner/user
compare the resulting histograms ('a' to every 'b')
if the user's distribution is "bad" (many short chains) --> penalty; if it is "good" (many long chains) --> reward
of course, there should be some threshold, and 'reward' & 'penalty' should be a floating value
and the point of time is important (block-wise? daily? i don't know by now what's good for this)
reminder: i've not mentioned any values for the penalty/reward
This is not a bad idea at all! I find some 8 and 9 ch's, but most of my shares are 6/7 ch because I mine with a lot of my VPS'. I really like your idea but because of this it may seem like I am cheating even though I'm not (because I find a high amount of small chains) and I don't want to be punished because of that. You know what I mean?
-
No seriously guys, you don't seem to understand the issue with your idea of fairness.
Your idea is essentially because someone makes more money than you, you deserve to make more and they deserve to make less.
The reason you don't make any is because you aren't as good as them. If you wanna be as good as them, devote some resources, IE pay for a vpn or a bunch of hardware. Linode (https://www.linode.com/)is really pretty cheap and pretty easy to get set up. If you don't want unfair payout then you want a PPS system and if you want a PPS system you want Capped Pay Per Share with Recent Backpay. I think the issue is that you guys are too focused on keeping things the way they are currently instead of actually using your brains and the resources available to you to actually think of anything of worth other than "Hey guys, I don't like making less money... I should make more... We should make more... Here is a chart about why I should make more money... Can I have more money... ect"
Also if you want evidence of manipulating a miner to spam low chain hashes, compare v0.2 with v0.3 of xolo's miners.
v0.3 is the productive one
v0.2 is the chain spam one
I know this because I am testing it. And will continue to do so until the payout system is changed.
Xolo I applaud you for putting up with people like this. Just remember these are not the majority of your miners, they are just some naive miners who think they know everything about running a pool.
ok lets think about this for a second, if i use v.03, i make much less xpm per block, but we find more blocks per day, so im losing out on 1-2 xpm, but we find maybe 1 more block a day, is that worth it for me? think about that for a second
or i could use v.02, we find the same amount of blocks (ive found 1 or 2 thus far) but i get paid 10-20% more than with v.03, which do you think a sane person would do? make more money, or lose money and contribute negligible amounts of blocks? im sorry to say this, but i think the majority of the miners on this pool are small time miners, so theyre getting paid for doing nothing, as you said, at best they find 1 or two blocks a day, which isnt much, what you're trying to say is that only the strong (rich) should make xpm because the small (middle class or poor) dont have or dont want to use their brains (what does this have to do with getting more processing power?) or their money
and @xolokram, it could work, but i think your cheat protection would have a hard time telling if someone is cheating, or theyre using a bunch of shitty 1 core vps (my 1 core vps finds like 1-2 6chs an hour Q>Q)
-
ok, here are my current ideas --- yup, multiple ones as we're actually talking about several problems --- (please tear it apart!! ;) ):
1) 'cheat' protection: will give you some factor for your resulting share value
first check the share distribution for
a) all user's in total (aka the average)
b) every single miner/user
compare the resulting histograms ('a' to every 'b')
if the user's distribution is "bad" (many short chains) --> penalty; if it is "good" (many long chains) --> reward
of course, there should be some threshold, and 'reward' & 'penalty' should be a floating value
and the point of time is important (block-wise? daily? i don't know by now what's good for this)
reminder: i've not mentioned any values for the penalty/reward
2) share value:
i don't know if it's really needed with the above mentioned cheat protection idea
(less diverse than tachibana's version, capped at current difficulty if it's really necessary)
3) the payout
CPPSRB? -> HERE (http://eligius.st/~gateway/faq-page)
theprofileth is right
Well at least you have CPPSRB, but really the cheat system isn't needed with it if you just do 2 things
1. Cap the total value multiplier to the target value (or if you really want, 1 level higher than target) IE if you score a 12 and the target is 9 it will count as a 9 but if you score a 10 and the value is 10 it will be a 10, though I assume we are dropping 6 shares once we hit value 10 to save time.
2. Set up the the payout to be
Coins IE (999/Difficulty^2*)*0.99
---------------------------- * V = primecoins per min share
e^Difficulty
This method should allow for long blocks to not bankrupt the pool but also payout people in a much more fair manner.
* that is the formula to calculate number of coins per block with the subtraction of the fee ie 1%
ok lets think about this for a second, if i use v.03, i make much less xpm per block, but we find more blocks per day, so im losing out on 1-2 xpm, but we find maybe 1 more block a day, is that worth it for me? think about that for a second
or i could use v.02, we find the same amount of blocks (ive found 1 or 2 thus far) but i get paid 10-20% more than with v.03, which do you think a sane person would do? make more money, or lose money and contribute negligible amounts of blocks? im sorry to say this, but i think the majority of the miners on this pool are small time miners, so theyre getting paid for doing nothing, as you said, at best they find 1 or two blocks a day, which isnt much, what you're trying to say is that only the strong (rich) should make xpm because the small (middle class or poor) dont have or dont want to use their brains (what does this have to do with getting more processing power?) or their money
Hence why we need an EXPONENTIAL WEIGHT TO STOP PEOPLE LIKE YOU AND EVERY OTHER "SMART MINER" cause fuck you, I find blocks several times a week on an i5, I contribute, I do my part. If 1000 miners found 1 block a day, you fucking dip shit, we would find 1000 blocks a day >:(
You are a leech, you think only of yourself, you do not deserve to pretend to care
-
No seriously guys, you don't seem to understand the issue with your idea of fairness.
Your idea is essentially because someone makes more money than you, you deserve to make more and they deserve to make less.
The reason you don't make any is because you aren't as good as them. If you wanna be as good as them, devote some resources, IE pay for a vpn or a bunch of hardware. Linode (https://www.linode.com/)is really pretty cheap and pretty easy to get set up. If you don't want unfair payout then you want a PPS system and if you want a PPS system you want Capped Pay Per Share with Recent Backpay. I think the issue is that you guys are too focused on keeping things the way they are currently instead of actually using your brains and the resources available to you to actually think of anything of worth other than "Hey guys, I don't like making less money... I should make more... We should make more... Here is a chart about why I should make more money... Can I have more money... ect"
Also if you want evidence of manipulating a miner to spam low chain hashes, compare v0.2 with v0.3 of xolo's miners.
v0.3 is the productive one
v0.2 is the chain spam one
I know this because I am testing it. And will continue to do so until the payout system is changed.
xTachibana actually just posted a solution that seems to work for both small and big miners. So no, just no.
Oy vey, ok so his first 4 values IE 6-9 are simply a 0.045 times a multiple of 9 making it an exponential of 9... which is very similar to an exponent of 10. Seriously you are saying if I had said
Dif Share Value
6ch 5
7ch 50
8ch 500
9ch 5,000
10ch 13,717
11ch 27,434
12ch 41,152You would have agreed with me? or do you just like small numbers?
Note those are the EXACT same proportions except the first 4 are a power of 10 * 5
You DO know I believe that the max value should be capped at the target right? IE 9
i only added in 11 and 10ch just in case :( i didnt think about a cap, would you like my idea more of it was capped at 10ch? (as in chains above 10 offer the same share value as 10, at least until difficulty is 10)
-
ok, here are my current ideas --- yup, multiple ones as we're actually talking about several problems --- (please tear it apart!! ;) ):
1) 'cheat' protection: will give you some factor for your resulting share value
first check the share distribution for
a) all user's in total (aka the average)
b) every single miner/user
compare the resulting histograms ('a' to every 'b')
if the user's distribution is "bad" (many short chains) --> penalty; if it is "good" (many long chains) --> reward
of course, there should be some threshold, and 'reward' & 'penalty' should be a floating value
and the point of time is important (block-wise? daily? i don't know by now what's good for this)
reminder: i've not mentioned any values for the penalty/reward
This more or less the same (at least it has the same effect) as giving the shares a weight. I'd prefer a transparent and fair weight system over a "good guy" / "bad guy" evaluation.
Maybe I'm a bit paranoid but my experience tought me that one can't be paranoid enough... ;)
How do you plan to treat "address hoppers" with manipulated miners. I mean, what about miners that just change the address once being exposed a cheater?
2) share value:
i don't know if it's really needed with the above mentioned cheat protection idea
(less diverse than tachibana's version, capped at current difficulty if it's really necessary)
Maybe more data is needed, but I bet there can be a factor derived (either from a sheer number of shares or from a systematical analysis of the underlying math) that describes the probability of an n-chain in relation to an m-chain - trying to say that in a mathematical way ;)
3) the payout system
CPPSRB? -> HERE (http://eligius.st/~gateway/faq-page)
theprofileth is right; a fixed distribution is not really useful imho
I have made good experience with eligius and CPPSRB - at least I think the pool was running on CPPSRB in 2011 ;)
-
i only added in 11 and 10ch just in case :( i didnt think about a cap, would you like my idea more of it was capped at 10ch? (as in chains above 10 offer the same share value as 10, at least until difficulty is 10)
lol don't worry xTachibana you are actually pretty intelligent but I have really been saying the same ideas for too long but nobody reads the entire thread so I need to say them on every page it seems like or else people go fucking crazy and think that squares are now circles ;)
- @theprofileth:
i remember your post (http://ppcointalk.org/index.php?topic=485.msg3649#msg3649)
wait, i have to re-read/think the details... :)
@xtachibana:
yeah, i really don't have a good answer about when to execute such a calculation
block-wise is stupid, as lucky blocks will be unfair etc. pp.
@masterOfDisaster:
it's not exactly the same. i have to think about some good examples ;)
the bad guy will be the bad guy if he uses the same config/miner again (despite his address / ip / whatever)
- xolokram
-
Hence why we need an EXPONENTIAL WEIGHT TO STOP PEOPLE LIKE YOU AND EVERY OTHER "SMART MINER" cause fuck you, I find blocks several times a week on an i5, I contribute, I do my part. If 1000 miners found 1 block a day, you fucking dip shit, we would find 1000 blocks a day >:(
You are a leech, you think only of yourself, you do not deserve to pretend to care
Aaaaand you lost credibility. If you don't have the decency to engage in a NORMAL, RESPECTFUL discussion, then either just stay away or don't talk to us. It's sad, really.
-
ok, here are my current ideas --- yup, multiple ones as we're actually talking about several problems --- (please tear it apart!! ;) ):
1) 'cheat' protection: will give you some factor for your resulting share value
first check the share distribution for
a) all user's in total (aka the average)
b) every single miner/user
compare the resulting histograms ('a' to every 'b')
if the user's distribution is "bad" (many short chains) --> penalty; if it is "good" (many long chains) --> reward
of course, there should be some threshold, and 'reward' & 'penalty' should be a floating value
and the point of time is important (block-wise? daily? i don't know by now what's good for this)
reminder: i've not mentioned any values for the penalty/reward
2) share value:
i don't know if it's really needed with the above mentioned cheat protection idea
(less diverse than tachibana's version, capped at current difficulty if it's really necessary)
3) the payout
CPPSRB? -> HERE (http://eligius.st/~gateway/faq-page)
theprofileth is right
Well at least you have CPPSRB, but really the cheat system isn't needed with it if you just do 2 things
1. Cap the total value multiplier to the target value (or if you really want, 1 level higher than target) IE if you score a 12 and the target is 9 it will count as a 9 but if you score a 10 and the value is 10 it will be a 10, though I assume we are dropping 6 shares once we hit value 10 to save time.
2. Set up the the payout to be
Coins IE (999/Difficulty^2*)*0.99
---------------------------- * V = primecoins per min share
e^Difficulty
This method should allow for long blocks to not bankrupt the pool but also payout people in a much more fair manner.
* that is the formula to calculate number of coins per block with the subtraction of the fee ie 1%
ok lets think about this for a second, if i use v.03, i make much less xpm per block, but we find more blocks per day, so im losing out on 1-2 xpm, but we find maybe 1 more block a day, is that worth it for me? think about that for a second
or i could use v.02, we find the same amount of blocks (ive found 1 or 2 thus far) but i get paid 10-20% more than with v.03, which do you think a sane person would do? make more money, or lose money and contribute negligible amounts of blocks? im sorry to say this, but i think the majority of the miners on this pool are small time miners, so theyre getting paid for doing nothing, as you said, at best they find 1 or two blocks a day, which isnt much, what you're trying to say is that only the strong (rich) should make xpm because the small (middle class or poor) dont have or dont want to use their brains (what does this have to do with getting more processing power?) or their money
Hence why we need an EXPONENTIAL WEIGHT TO STOP PEOPLE LIKE YOU AND EVERY OTHER "SMART MINER" cause fuck you, I find blocks several times a week on an i5, I contribute, I do my part. If 1000 miners found 1 block a day, you fucking dip shit, we would find 1000 blocks a day >:(
You are a leech, you think only of yourself, you do not deserve to pretend to care
well, first of all, we dont have 1000 miners, second of all, not everyone can find 1 block a day, i find 1 on a good day on my 3570k, which is probably the same if not better than the i5 you have, but anyhow, the vast majority of the 389 workers beeeeer has dont even have a cpu as powerful as ours, if you didnt notice, with nearly 400 workers we're only finding 30-70 blocks a day, and most of those are probably found by 1-5 people.
also, can you keep your schizophrenia in check, first you insult me and now you compliment me, im very confused on how i should feel right now.
-
Hence why we need an EXPONENTIAL WEIGHT TO STOP PEOPLE LIKE YOU AND EVERY OTHER "SMART MINER" cause fuck you, I find blocks several times a week on an i5, I contribute, I do my part. If 1000 miners found 1 block a day, you fucking dip shit, we would find 1000 blocks a day >:(
You are a leech, you think only of yourself, you do not deserve to pretend to care
Aaaaand you lost credibility. If you don't have the decency to engage in a NORMAL, RESPECTFUL discussion, then either just stay away or don't talk to us. It's sad, really.
I wasn't actually mad at xTachibana I just really don't like that kind of "I can't help so why even try" attitude about anything.
That sort of attitude belongs over at ypool
I apologize to xTachibana, I just can't stand the idea that everyone at this pool can't do anything, because you know if that is true our larger miners will leave and then we will only have each other.
Also I meant to say "If you do this, you are a leech, you think only of yourself, you do not deserve to pretend to care"
Also we do actually have around 400 miners and generate about 23000~ shares per hour
- calm down @everyone
i should've not chosen red :)
-
calm down @everyone
i should've not chosen red :)
O U xolo :)
Also xTachibana post your primecoin address
- Maybe we should slow posting down and start reading at least this page again. There has been some simultaneous posting and I think some good ideas are on this page. Let's don't waste them by going forward headlessly.
-
Hence why we need an EXPONENTIAL WEIGHT TO STOP PEOPLE LIKE YOU AND EVERY OTHER "SMART MINER" cause fuck you, I find blocks several times a week on an i5, I contribute, I do my part. If 1000 miners found 1 block a day, you fucking dip shit, we would find 1000 blocks a day >:(
You are a leech, you think only of yourself, you do not deserve to pretend to care
Aaaaand you lost credibility. If you don't have the decency to engage in a NORMAL, RESPECTFUL discussion, then either just stay away or don't talk to us. It's sad, really.
I wasn't actually mad at xTachibana I just really don't like that kind of "I can't help so why even try" attitude about anything.
That sort of attitude belongs over at ypool
I apologize to xTachibana, I just can't stand the idea that everyone at this pool can't do anything, because you know if that is true our larger miners will leave and then we will only have each other.
while i agree that the attitude itself is not good, based on common sense and data from ypool, the vast majority of miners (at least those mining xpm) are small time miners, with maybe 1 cpu or 2 cpu's, but not 1-2 3770k's, more like 2 old pentium duo cores, even with just my 3570k, i was among the top 100 in payouts after 80 blocks, which is very sad, it means that over 200-300 people are mining with really shitty cpu's.
oh and i accept your apology :)
-
Hence why we need an EXPONENTIAL WEIGHT TO STOP PEOPLE LIKE YOU AND EVERY OTHER "SMART MINER" cause fuck you, I find blocks several times a week on an i5, I contribute, I do my part. If 1000 miners found 1 block a day, you fucking dip shit, we would find 1000 blocks a day >:(
You are a leech, you think only of yourself, you do not deserve to pretend to care
Aaaaand you lost credibility. If you don't have the decency to engage in a NORMAL, RESPECTFUL discussion, then either just stay away or don't talk to us. It's sad, really.
I wasn't actually mad at xTachibana I just really don't like that kind of "I can't help so why even try" attitude about anything.
That sort of attitude belongs over at ypool
I apologize to xTachibana, I just can't stand the idea that everyone at this pool can't do anything, because you know if that is true our larger miners will leave and then we will only have each other.
Also I meant to say "If you do this, you are a leech, you think only of yourself, you do not deserve to pretend to care"
Also we do actually have around 400 miners and generate about 23000~ shares per hour
Sure. But am I a leech just because I don't have 1000's of dollars to spend on mining equipment? Yes, I am a small miner and because of that I don't help the pool out as much as other people do. And yes, most of the shares I find are 6ch and 7ch. But that does not mean I don't want to help the pool. As a matter of fact I am doing everything I can and even though I have shitty machines I am still running 0.3 on them (while it would be more profitable to run 0.2 right now).
All I'm saying is that people have to accept that there are smaller miners too. If I could be one of the big guys I would, but I don't have that money so I am mining with what I can. Ypool is a no-go for me since that pool is tweaked to the bigger miners and I like this pool so much because I can actually make some XPM here. That is all.
I'm not a leecher, I just don't have the equipment that others do.
-
oh and i accept your apology :)
Thank you also could you post your primecoin address
-
calm down @everyone
i should've not chosen red :)
O U xolo :)
Also xTachibana post your primecoin address
AXqtznv3daELfDqdNu6FESApCpqHK3LfRr
no matter what i try i cant seem to get more 7ch and 8ch :(
-
calm down @everyone
i should've not chosen red :)
O U xolo :)
Also xTachibana post your primecoin address
AXqtznv3daELfDqdNu6FESApCpqHK3LfRr
no matter what i try i cant seem to get more 7ch and 8ch :(
Ok I feel better now
You should check your primecoin client ;D
Edit:
ps. please remove the 6-chain cheat config ::)
Because you said please I did ;)
-
calm down @everyone
i should've not chosen red :)
O U xolo :)
Also xTachibana post your primecoin address
AXqtznv3daELfDqdNu6FESApCpqHK3LfRr
no matter what i try i cant seem to get more 7ch and 8ch :(
Ok I feel better now
You should check your primecoin client ;D
already did :) thank you, on another note, anyone know how to configure my miner to find more 8+ch?
-
on another note, anyone know how to configure my miner to find more 8+ch?
Well it would look something like this
-sieveextensions=9 -bits=8 -TargetInitialLength=8that might work
-
on another note, anyone know how to configure my miner to find more 8+ch?
Well it would look something like this
-sieveextensions=9 -bits=8 -TargetInitialLength=8that might work
ill try it now on my 3570k
- @theprofileth:
in your post: http://ppcointalk.org/index.php?topic=485.msg3649#msg3649
you're assuming a exponential distribution of the shares, right? /edit: you're already mentioning the exponential distribution on the same page, sorry, so yes
anyway, i don't see how this should help punishing cheating clients
sorry if i'm not correct or too 'slow' (it's late over here and i'm almost falling asleep)
- xolokram
ps. i had totally different plans for tonight, now i'm here... :o
-
@theprofileth:
in your post: http://ppcointalk.org/index.php?topic=485.msg3649#msg3649
you're assuming a exponential distribution of the shares, right?
anyway, i don't see how this should help punishing cheating clients
sorry if i'm not correct or too 'slow' (it's late here and i'm almost falling asleep)
- xolokram
ps. please remove the 6-chain cheat config ::)
pps. i had totally different plans for tonight, now i'm here... :o
A cheating client will submit 10 times as many 6 shares over 7 shares over a long period of time and given that PPS has no rounds we are talking about the entirety of their mining career, so, if 7's are 10 times the value then they are not making any more than they are supposed to for example lets say they submit 6000 6 chains and 200 7 chains, they are being payed for essentially 8000 6 chains however if a normal person submits 4000 6 chains and 400 7 chains they are going to pay out the same as the guy cheating and thus he wont have and advantage as even though he is submitting more than 40% more is making the same plus he will rarely if ever hit an 8 chain but the normal miner will hit much more of those an those are worth 1000 each which VERY quickly evens out the variance between the cheater and the normal miner, as if a normal miner finds 1 8 chain than the cheater he will be beating him in pay and that is very likely to happen with a properly set up miner.
Also it is worth noting that if a cheating system is set up you would need a registration system to actually make it work and that requires a lot more infrastructure and management than just the simple payout we have now.
-
@theprofileth:
in your post: http://ppcointalk.org/index.php?topic=485.msg3649#msg3649
you're assuming a exponential distribution of the shares, right?
anyway, i don't see how this should help punishing cheating clients
sorry if i'm not correct or too 'slow' (it's late here and i'm almost falling asleep)
- xolokram
ps. please remove the 6-chain cheat config ::)
pps. i had totally different plans for tonight, now i'm here... :o
A cheating client will submit 10 times as many 6 shares over 7 shares over a long period of time and given that PPS has no rounds we are talking about the entirety of their mining career, so, if 7's are 10 times the value then they are not making any more than they are supposed to for example lets say they submit 6000 6 chains and 200 7 chains, they are being payed for essentially 8000 6 chains however if a normal person submits 4000 6 chains and 400 7 chains they are going to pay out the same as the guy cheating and thus he wont have and advantage as even though he is submitting more than 40% more is making the same plus he will rarely if ever hit an 8 chain but the normal miner will hit much more of those an those are worth 1000 each which VERY quickly evens out the variance between the cheater and the normal miner, as if a normal miner finds 1 8 chain than the cheater he will be beating him in pay and that is very likely to happen with a properly set up miner.
Also it is worth noting that if a cheating system is set up you would need a registration system to actually make it work and that requires a lot more infrastructure and management than just the simple payout we have now.
so far im at
"6": 28,
"7": 3
}
i dont think its working :(
-
@theprofileth:
in your post: http://ppcointalk.org/index.php?topic=485.msg3649#msg3649
you're assuming a exponential distribution of the shares, right?
anyway, i don't see how this should help punishing cheating clients
sorry if i'm not correct or too 'slow' (it's late here and i'm almost falling asleep)
- xolokram
ps. please remove the 6-chain cheat config ::)
pps. i had totally different plans for tonight, now i'm here... :o
A cheating client will submit 10 times as many 6 shares over 7 shares over a long period of time and given that PPS has no rounds we are talking about the entirety of their mining career, so, if 7's are 10 times the value then they are not making any more than they are supposed to for example lets say they submit 6000 6 chains and 200 7 chains, they are being payed for essentially 8000 6 chains however if a normal person submits 4000 6 chains and 400 7 chains they are going to pay out the same as the guy cheating and thus he wont have and advantage as even though he is submitting more than 40% more is making the same plus he will rarely if ever hit an 8 chain but the normal miner will hit much more of those an those are worth 1000 each which VERY quickly evens out the variance between the cheater and the normal miner, as if a normal miner finds 1 8 chain than the cheater he will be beating him in pay and that is very likely to happen with a properly set up miner.
Also it is worth noting that if a cheating system is set up you would need a registration system to actually make it work and that requires a lot more infrastructure and management than just the simple payout we have now.
ironically, the "cheat" one you posted is getting me more 7 and 8ch than default, im not sure if you were being sarcastic when you posted it, or the settings are wrong
-
ironically, the "cheat" one you posted is getting me more 7 and 8ch than default, im not sure if you were being sarcastic when you posted it, or the settings are wrong
Shh if you tell them that then they won't use those settings ;)
-
ironically, the "cheat" one you posted is getting me more 7 and 8ch than default, im not sure if you were being sarcastic when you posted it, or the settings are wrong
Shh if you tell them that then they won't use those settings ;)
trying out my own settings now, finding 1 7ch every 8-10 6ch, that sounds about right i think?
-
A cheating client will submit 10 times as many 6 shares over 7 shares over a long period of time and given that PPS has no rounds we are talking about the entirety of their mining career, so, if 7's are 10 times the value then they are not making any more than they are supposed to for example lets say they submit 6000 6 chains and 200 7 chains, they are being payed for essentially 8000 6 chains however if a normal person submits 4000 6 chains and 400 7 chains they are going to pay out the same as the guy cheating and thus he wont have and advantage as even though he is submitting more than 40% more is making the same plus he will rarely if ever hit an 8 chain but the normal miner will hit much more of those an those are worth 1000 each which VERY quickly evens out the variance between the cheater and the normal miner, as if a normal miner finds 1 8 chain than the cheater he will be beating him in pay and that is very likely to happen with a properly set up miner.
Also it is worth noting that if a cheating system is set up you would need a registration system to actually make it work and that requires a lot more infrastructure and management than just the simple payout we have now.
please beat me up if i'm wrong, this is my last attempt of the day to get this right: i'm so tired right now
6-chain share value=1
7-chain share value=10
8-chain share value=1000 (? this looks wrong ?)
9-chain share value=what would that be?
(this actually looks like another ypool share value distribution)
the xpm share value needs a very good starting point (as it be wrong easily)
and this highly depends on the correct guess of the distribution
and correct guesses of possible 'cheated' distributions
CPPSRB seems to be ok, but a immediate payout is actually not a good idea on the primecoin network as there is a fixed transaction fee.
and the cheating system wouldn't need any registration as it's working on your not-yet-for-payout-evaluated submitted shares. if you cheat again, you'll caught immediately.
i'm not trying to hit on your idea(s).
i'm just trying to think about every possible disadvantage before a final decision is made.
- lokraxom
ps. i will go to sleep now, see you guys
-
A cheating client will submit 10 times as many 6 shares over 7 shares over a long period of time and given that PPS has no rounds we are talking about the entirety of their mining career, so, if 7's are 10 times the value then they are not making any more than they are supposed to for example lets say they submit 6000 6 chains and 200 7 chains, they are being payed for essentially 8000 6 chains however if a normal person submits 4000 6 chains and 400 7 chains they are going to pay out the same as the guy cheating and thus he wont have and advantage as even though he is submitting more than 40% more is making the same plus he will rarely if ever hit an 8 chain but the normal miner will hit much more of those an those are worth 1000 each which VERY quickly evens out the variance between the cheater and the normal miner, as if a normal miner finds 1 8 chain than the cheater he will be beating him in pay and that is very likely to happen with a properly set up miner.
Also it is worth noting that if a cheating system is set up you would need a registration system to actually make it work and that requires a lot more infrastructure and management than just the simple payout we have now.
please beat me up if i'm wrong, this is my last attempt of the day to get this right: i'm so tired right now
6-chain share value=1
7-chain share value=10
8-chain share value=1000 (? this looks wrong ?)
9-chain share value=what would that be?
(this actually looks like another ypool share value distribution)
the xpm share value needs a very good starting point (as it be wrong easily)
and this highly depends on the correct guess of the distribution
and correct guesses of possible 'cheated' distributions
CPPSRB seems to be ok, but a immediate payout is actually not a good idea on the primecoin network as there is a fixed transaction fee.
and the cheating system wouldn't need any registration as it's working on your not-yet-for-payout-evaluated submitted shares. if you cheat again, you'll caught immediately.
i'm not trying to hit on your idea(s).
i'm just trying to think about every possible disadvantage before a final decision is made.
- lokraxom
well for one, why is 8ch 100 times more share value than a 7ch, when you find 1 8ch every 10~ 7ch? at most i would say
6ch 1
7ch 10
8ch 150
9ch 2000
10ch 20000
- My friend is a top ypool user and his setting on jhprimeminer are -s 1500000 -primes 2000000 -d 8 these settings will give you chains up 12 ch so you may need to adjust them accordingly
apologies for my rantings earlier
Karma everbody :)
-
A cheating client will submit 10 times as many 6 shares over 7 shares over a long period of time and given that PPS has no rounds we are talking about the entirety of their mining career, so, if 7's are 10 times the value then they are not making any more than they are supposed to for example lets say they submit 6000 6 chains and 200 7 chains, they are being payed for essentially 8000 6 chains however if a normal person submits 4000 6 chains and 400 7 chains they are going to pay out the same as the guy cheating and thus he wont have and advantage as even though he is submitting more than 40% more is making the same plus he will rarely if ever hit an 8 chain but the normal miner will hit much more of those an those are worth 1000 each which VERY quickly evens out the variance between the cheater and the normal miner, as if a normal miner finds 1 8 chain than the cheater he will be beating him in pay and that is very likely to happen with a properly set up miner.
Also it is worth noting that if a cheating system is set up you would need a registration system to actually make it work and that requires a lot more infrastructure and management than just the simple payout we have now.
please beat me up if i'm wrong, this is my last attempt of the day to get this right: i'm so tired right now
6-chain share value=1
7-chain share value=10
8-chain share value=1000 (? this looks wrong ?)
9-chain share value=what would that be?
(this actually looks like another ypool share value distribution)
the xpm share value needs a very good starting point (as it be wrong easily)
and this highly depends on the correct guess of the distribution
and correct guesses of possible 'cheated' distributions
CPPSRB seems to be ok, but a immediate payout is actually not a good idea on the primecoin network as there is a fixed transaction fee.
and the cheating system wouldn't need any registration as it's working on your not-yet-for-payout-evaluated submitted shares. if you cheat again, you'll caught immediately.
i'm not trying to hit on your idea(s).
i'm just trying to think about every possible disadvantage before a final decision is made.
- lokraxom
ps. i will go to sleep now, see you guys
Sorry I made a mistake as I skipped a step of logic, I meant that it is easy for people to find multiple 8 chains over a while and having 10 which is pretty easy gives them 1000 as they are 100 each, my bad about not fully explaining that. The idea is that the spammer won't get that many 8 chains let alone enough to actually stay up with most normal/smart miners. BTW CPPSRB doesn't use immediate payout it waits for the blocks to mature and pays out over a threshold IE the way you are doing it currently is how Eligius does it as well. The only thing that would be immediate is that we would just be able to know how much we have earned before we get payed out due to the flat rate of pay. Also it would be very easy to simply create a new address and just mine from that to just avoid penalties unless all penalties were levied at everyone at the start and then you would end up hurting small miners who look like low volume spammers.
Obviously 9 chains would be worth 1000 and 10 chains (if you allowed 1 higher than the target as we are getting closer to 10 chains than 9) would be worth 10000. However I want to suggest against this due to the fact that paying out 10000 of the allocated ~18000 shares per block would very easily render you effectively having to pay out double the amount the block produces.
-
ok, here are my current ideas --- yup, multiple ones as we're actually talking about several problems --- (please tear it apart!! ;) ):
1) 'cheat' protection: will give you some factor for your resulting share value
first check the share distribution for
a) all user's in total (aka the average)
b) every single miner/user
compare the resulting histograms ('a' to every 'b')
if the user's distribution is "bad" (many short chains) --> penalty; if it is "good" (many long chains) --> reward
of course, there should be some threshold, and 'reward' & 'penalty' should be a floating value
and the point of time is important (block-wise? daily? i don't know by now what's good for this)
reminder: i've not mentioned any values for the penalty/reward
This more or less the same (at least it has the same effect) as giving the shares a weight. I'd prefer a transparent and fair weight system over a "good guy" / "bad guy" evaluation.
Maybe I'm a bit paranoid but my experience tought me that one can't be paranoid enough... ;)
How do you plan to treat "address hoppers" with manipulated miners. I mean, what about miners that just change the address once being exposed a cheater?
I agree. I have analyzed my shares a lot and I often see my miners producing no 8ch or 9ch for an exceptionally long period of time. It could be just luck or it could be a bug in the miner triggered by some condition. You would need to wait until the miner should have produced several, say 3, 9chs but haven't prduced any to be reasonablly sure that the miner is having a problem. By that time 3000 6chs would have been made usually. So 3000 6chs are the detection noise limit. An address hopper using tor could operate under the radar.
-
Btw Xolo I forgot to ask if you are going to implement one of the more popular features of CPPSRB, that being paid orphans. The idea is that because you are paying on work not completion you still count everyone's shares and just pay them back when you can and as we don't hit too many orphans it is just a nice way to one up ypool plus it doesn't detriment the total pool by much as you make up lost payments in short blocks to help pay out long blocks and orphans. While this might sound risky the reason CPPSRB works is because you only pay what you can and shelve the rest of the valid shares and treat them as if they were submitted the next block and pay out that way so that the total work done is carried over until it is payed off or there is a surplus. This is why I suggested this type to you as it fits the best of both worlds as PPS pays out everyone the most especially small miners as there is a lot less variance compared to other payout types (though we are trying to ameliorate that with the value weighting which in theory only helps you earn more not less ;) well if you are an optimist that is how you can view it)
Also I request that you change min chain length to 7 once we hit chain length 10 which will help keep the pool from assuming too much leecher debt.
Edit: Also some nice mining settings I have been using getting lots of 8's is
-sievesize=1500000 -primes=2000000 -sieveextensions=7 -bits=10 -TargetInitialLength=7 -sievepercentage=5 -chainlength=10I don't think that everything in here actually does anything but I set them anyways
- I'm trying to make another short (but hopefully educated) guess regarding the weight of shares:
starting with the weight of a 6-chain, each step-up in chain length elevenfolds the weight
Maybe this is totally misdirected, but as I saw no comment regarding this
http://ppcointalk.org/index.php?topic=485.msg3826#msg3826
and that
http://ppcointalk.org/index.php?topic=485.msg3834#msg3834
either I fell into the TL;DR trap or my ideas are that hilarious that no one wanted to show me up ;)
-
Btw Xolo I forgot to ask if you are going to implement one of the more popular features of CPPSRB, that being paid orphans.
[...]
Considering that CPPSRB is a nice distribution method that is fair (for current and past miners) and with no risk for the pool operator (if implemented correctly ;) ) this distribution method would be even more attractive if there was the option for getting paid for orphans.
This should make pool hopping less attractive (which is anyway not very attractive for CPPSRB) and it definitely negates the risk of not getting paid for having worked on an orphaned block.
I second both CPPSRB and "getting paid for orphans".
-
I'm trying to make another short (but hopefully educated) guess regarding the weight of shares:
starting with the weight of a 6-chain, each step-up in chain length elevenfolds the weight
Maybe this is totally misdirected, but as I saw no comment regarding this
http://ppcointalk.org/index.php?topic=485.msg3826#msg3826
and that
http://ppcointalk.org/index.php?topic=485.msg3834#msg3834
either I fell into the TL;DR trap or my ideas are that hilarious that no one wanted to show me up ;)
I ageed with you on most of what you said in both posts. It's just that there are too many opinions to follow up.. ;) I have no experience with CPPSRB however.
It's too early to ask for perhaps, but I wish the pool gives a note when a record-breaking Cunningham chain is found by the pool members. Just to show something different from pools of all other coins.
-
well for one, why is 8ch 100 times more share value than a 7ch, when you find 1 8ch every 10~ 7ch? at most i would say
6ch 1
7ch 10
8ch 150
9ch 2000
10ch 20000
Maybe we need a mathematician with more knowlegde in number fields (or whatever is the correct expression), but I'm almost certain that there can be a probability derived that is nearly constant for each step-up in chain length. And the inverse of that probabilty should be the weight factor of the chain length. That is, I admit it, less numbers than before (when I was talking about an elevenfold of the weight for each step-up), but maybe closer to a sound solution ;)
- I've created a topic for my simple pool stats
http://ppcointalk.org/index.php?topic=507
- ah, good timing... /irony
i changed the blocks overview a little bit: see http://www.beeeeer.org/blocks
i added some stats (data (gmt), duration, shares per block, and average duration/shares of the last 20 / 50 / 100 blocks)
sorry Sy, can you try to change your parser?!
and the personal details are not part of the block info any longer, they can be accessed like this...
e.g. http://www.beeeeer.org/block/166915/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
- xolokram
ps. sorry, i'm busy today, i'll be back later and try to answer / comment everyone on the latest discussion
pps. Sy, you're site looks nice ;)
-
I'm trying to make another short (but hopefully educated) guess regarding the weight of shares:
starting with the weight of a 6-chain, each step-up in chain length elevenfolds the weight
Maybe this is totally misdirected, but as I saw no comment regarding this
http://ppcointalk.org/index.php?topic=485.msg3826#msg3826
and that
http://ppcointalk.org/index.php?topic=485.msg3834#msg3834
either I fell into the TL;DR trap or my ideas are that hilarious that no one wanted to show me up ;)
You know that is just another step from 10 fold and is less easily resampled down as factors of 10 can be divisible by 10 all the way down to a nice easy 1, factors of 11 can not and only max out at 11 which is prime so maybe if we want to be ironic we can use a prime factor for the exponent. Also I don't know I read your posts and they seem a bit convoluted in their explanations or atleast this one did (http://ppcointalk.org/index.php?topic=485.msg3834#msg3834) either way I think we have said enough about the exponential weighting system for now. Also again the cap should be on the level of the target as if you don't do that the costs of maintaining the payout system will be unbearable.
-
ah, good timing... /irony
i changed the blocks overview a little bit: see http://www.beeeeer.org/blocks
i added some stats (duration, shares per block, and average duration/shares of the last 20 / 50 / 100 blocks)
sorry Sy, can you try to change your parser?!
and the personal details are not part of the block info any longer, they can be accessed like this...
e.g. http://www.beeeeer.org/block/166915/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
- xolokram
ps. sorry, i'm busy today, i'll be back later and try to answer / comment everyone on the latest discussion
pps. you're site looks nice ;)
Noooo, how could you?! ;D ;D
But payout and shares_payout is still there, changing at the next block? It looks like you only changed your overview a bit, doesnt matter since i take the block id from the link to the block details via regexp, that one is still intact and then look into the block file itself - so i think it's still all good :)
-
...
Noooo, how could you?! ;D ;D
But payout and shares_payout is still there, changing at the next block? It looks like you only changed your overview a bit, doesnt matter since i take the block id from the link to the block details via regexp, that one is still intact and then look into the block file itself - so i think it's still all good :)
"payout" and "shares_payout" are still part of the general block info, again sorry --- that was really bad timing
btw. i'm thinking about shutting down the old 'getwork' protocol (port 9912/9999). it's producing <6% of all shares. soon :)
and here are some new stats (only 'getworx' protocol (xolominer v0.2 & v0.3)):
6-chains: 925796
7-chains: 85145
8-chains: 8055
9-chains or higher: 479
rejected: 78947 (7,19%)
- xolokram
ps. like i said, i'll be back later...
pps. post #100 *woohoo* :o
-
...
Noooo, how could you?! ;D ;D
But payout and shares_payout is still there, changing at the next block? It looks like you only changed your overview a bit, doesnt matter since i take the block id from the link to the block details via regexp, that one is still intact and then look into the block file itself - so i think it's still all good :)
"payout" and "shares_payout" are still part of the general block info, again sorry --- that was really bad timing
btw. i'm thinking about shutting down the old 'getwork' protocol (port 9912/9999). it's producing <6% of all shares.
- xolokram
Np, everything is still working as intended on my end :)
-
Xolokram, I suggest that the exponential weights be applied as such,
0.1 6 chains
1 7 chains
10 8 chains
100 9 chains
Reason being is that by the set up at starting at 1 we could of only payed out 18k 6 chains however 18k~ is approximately the average TOTAL amount of chairs per block and thus we would be at nearly a constant loss if they were payed out as before, this allows for you to pay out 180k 6 chains or 18k 7 chains before the block accrues debt. Obviously that should be enough and no longer be an issue of concern.
And thus I submit my final proposal here.
Beeeeer.org's primecoin CPPSRB with weighted value or if like acronyms CPPSRBWV
F=Fee %, default 0.01
D=Difficulty of current block
M = Minimum chain length accepted, default should be 6
T = Target chain length based on difficulty checked every block to be sure, default should be truncated D IE if 9.8 then T=9
L = Length Submitted, no default
O = Offset of the weight, lower means less payout but less chance of pool debt, default should be 1
V = Value IE weight, calculated as 10^(L-M-O)
V should = 0.1*10^(L-M)) which is the same as the above if O=1
(999/D^2)*(1-F)
---------------------------- * V = primecoins per share
e^D
This system allows for approximately 180k min value chains (or equivalent) to be submitted without generating debt.
-
[...]
And thus I submit my final proposal here.
Beeeeer.org's primecoin CPPSRB with weighted value or if like acronyms CPPSRBWV
F=Fee %, default 0.01
D=Difficulty of current block
M = Minimum chain length accepted, default should be 6
T = Target chain length based on difficulty checked every block to be sure, default should be truncated D IE if 9.8 then T=9
L = Length Submitted, no default
O = Offset of the weight, lower means less payout but less chance of pool debt, default should be 1
V = Value IE weight, calculated as 10^(L-M-O)
V should = 0.1*10^(L-M)) which is the same as the above if O=1
(999/D^2)*(1-F)
---------------------------- * V = primecoins per share
e^D
This system allows for approximately 180k min value chains (or equivalent) to be submitted without generating debt.
Sorry for producing convoluted posts. I try to give them better structure next time.
I agree we have said enough about the exponential weight system (although I don't understand the drawback of chosing 11 instead of 10 and creating the power with that).
I think we should peer at the cap. I don't see how it is implemented in your formula. T is not used, although it is necessary for capping. I try to add a fix, although it's not pretty to do this by distinction of cases.
I don't agree to the way you introduced the cap in your recent post (http://ppcointalk.org/index.php?topic=485.msg3882#msg3882). The fractional part of the difficulty makes chains of length T+n (n>=1) the more important the bigger the fractional part gets. So I'd recommend capping the weight for all lengths T+n for n>1 to the weight of T+1 chains in due consideration of the fractional part of the difficulty. Capping the weight at T seems to be too early. Either we extend the weight algorithm to chains of length T+1 or we try this:
introducing another variable and another factor could help getting T+1 chains a fair weight:
P = fractional part of the difficulty D (as floating point number)
W as factor for giving chains of length T+n, n>1 proper value (pseudo code):
if L <= T
then W = 1
else
W = 10 * P
I think this is important because each valid chain of length T+n solves a block whereas only (1-P)*100 percent of chains of length T do.
which leads to (including comments regarding cap):
F=Fee %, default 0.01
D=Difficulty of current block
M = Minimum chain length accepted, default should be 6
T = Target chain length based on difficulty checked every block to be sure, default should be truncated D IE if 9.8 then T=9
L = Length Submitted, no default
O = Offset of the weight, lower means less payout but less chance of pool debt, default should be 1
if L<=T then V = Value IE weight, calculated as 10^(L-M-O); else V = 10^(T-M-O)
V should = 0.1*10^(L-M)) which is the same as the above if O=1
P = fractional part of the difficulty D (as floating point number)
if L<=T then W = 1; else W = 10 * P
(999/D^2)*(1-F)
---------------------------- * V * W = primecoins per share
e^D
-
Xolokram, I suggest that the exponential weights be applied as such,
0.1 6 chains
1 7 chains
10 8 chains
100 9 chains
Reason being is that by the set up at starting at 1 we could of only payed out 18k 6 chains however 18k~ is approximately the average TOTAL amount of chairs per block and thus we would be at nearly a constant loss if they were payed out as before, this allows for you to pay out 180k 6 chains or 18k 7 chains before the block accrues debt. Obviously that should be enough and no longer be an issue of concern.
And thus I submit my final proposal here.
Beeeeer.org's primecoin CPPSRB with weighted value or if like acronyms CPPSRBWV
F=Fee %, default 0.01
D=Difficulty of current block
M = Minimum chain length accepted, default should be 6
T = Target chain length based on difficulty checked every block to be sure, default should be truncated D IE if 9.8 then T=9
L = Length Submitted, no default
O = Offset of the weight, lower means less payout but less chance of pool debt, default should be 1
V = Value IE weight, calculated as 10^(L-M-O)
V should = 0.1*10^(L-M)) which is the same as the above if O=1
(999/D^2)*(1-F)
---------------------------- * V = primecoins per share
e^D
This system allows for approximately 180k min value chains (or equivalent) to be submitted without generating debt.
LOL the same system ypool used up until around the 14th august
-
Beeeeer.org's primecoin CPPSRB with weighted value or if like acronyms CPPSRBWV
F=Fee %, default 0.01
D=Difficulty of current block
M = Minimum chain length accepted, default should be 6
T = Target chain length based on difficulty checked every block to be sure, default should be truncated D IE if 9.8 then T=9
L = Length Submitted, no default
O = Offset of the weight, lower means less payout but less chance of pool debt, default should be 1
V = Value IE weight, calculated as 10^(L-M-O)
V should = 0.1*10^(L-M)) which is the same as the above if O=1
(999/D^2)*(1-F)
---------------------------- * V = primecoins per share
e^D
This system allows for approximately 180k min value chains (or equivalent) to be submitted without generating debt.
Oh my god! You agent of Ypool?
- ^ except that you're getting paid per share, not per proportion of a block
which is a considerable difference
@theprofileth:
i like the idea of CPPSRB. i'm not 100% sure about the share values (everybody's invited to help here, but please first: try to understand what CPPSRB is (see eligius) and how it works). i will add some statistics and i will try to add a system for a "dry run" to see if there are some problems with it.
[still reading the posts right now / edits probably incoming]
- xolokram
- Can we stay at the current system where people get paid by there contribution in the current block?
We should do something about the share rating though. The blockfinder should get 3 XPM the next 2 XPM should be divided over the 9 chains, the next 2 over the 8 chains also 2 XPM for the 7 chains. The pool operator should take his share and the rest should be divided over the 6 chains
I think that is fair.
-
Can we stay at the current system where people get paid by there contribution in the current block?
nope, because it gives an advantage for 'cheating' miners (and a slight(?) advantage for 'big players').
We should do something about the share rating though. The blockfinder should get 3 XPM the next 2 XPM should be divided over the 9 chains, the next 2 over the 8 chains also 2 XPM for the 7 chains. The pool operator should take his share and the rest should be divided over the 6 chains
I think that is fair.
i guess this is not really fair, it will prefer users with alot of cpu power (aka 'big players') <-- first impression
- xolokram
-
Can we stay at the current system where people get paid by there contribution in the current block?
nope, because it gives an advantage for 'cheating' miners (and a slight(?) advantage for 'big players').
Don't bring in the Big Players, that's a different problem than the cheaters.
We should do something about the share rating though. The blockfinder should get 3 XPM the next 2 XPM should be divided over the 9 chains, the next 2 over the 8 chains also 2 XPM for the 7 chains. The pool operator should take his share and the rest should be divided over the 6 chains
I think that is fair.
this is not really fair, it will prefer users with alot of cpu power (aka 'big players')
- xolokram
But it will stop the cheaters... , CPPSRB is something nice for you to implement though ;)
Maybe you could find something that counts in the chain statistics over the last 100 blocks.
-
Maybe you could find something that counts in the chain statistics over the last 100 blocks.
working-in-progress currently done
- xolokram
ps. PPS is pretty much as fair as it can get, but [email protected] needs additional adjustment for share value as one easily could tweak for 6-chains
-
Maybe you could find something that counts in the chain statistics over the last 100 blocks.
working-in-progress currently done
- xolokram
ps. PPS is pretty much as fair as it can get, but [email protected] needs additional adjustment for share value as one easily could tweak for 6-chains
Cool 8)
EDIT: ... I believe I have the same percentages mining solo
- I like how that pps system sounds, never heard about it before...I'm sure xolokram will figure out a fair share valuation method. I'm in for the ride :D
-
which leads to (including comments regarding cap):
F=Fee %, default 0.01
D=Difficulty of current block
M = Minimum chain length accepted, default should be 6
T = Target chain length based on difficulty checked every block to be sure, default should be truncated D IE if 9.8 then T=9
L = Length Submitted, no default
O = Offset of the weight, lower means less payout but less chance of pool debt, default should be 1
if L<=T then V = Value IE weight, calculated as 10^(L-M-O); else V = 10^(T-M-O)
V should = 0.1*10^(L-M)) which is the same as the above if O=1
P = fractional part of the difficulty D (as floating point number)
if L<=T then W = 1; else W = 10 * P
(999/D^2)*(1-F)
---------------------------- * V * W = primecoins per share
e^DYou know that means the payout is higher when difficulty is fractionally higher which is supposed to be the opposite of PPS. In fact that defeats the entire purpose, i think the point you are missing is that the cap at T prevents overpaying and running into debt as you are payed for every share based off of the difficulty of the block, lower difficulty = more pay so having w ruins this system and makes it likely to collapse, please can everyone go and read about PPS before we have any further discussions on the matter.
https://en.bitcoin.it/wiki/Comparison_of_mining_pools
Edit:I should note that CPPSRB puts all the risk on you guys, by that I mean, if you want to overpay everyone at the pool it means nobody will ever get payed out except for maybe xolo lol who collects his 1% each block. Which is why we want to allow for longer blocks to occur and not suck up all the reserve money. Also because it is a first in last out system means faster people get payed out first, that is their only real advantage. Essentially what you want to have is called a "block finder reward" which is stupid and only benefits giants in the long run. What I want is scaled rewards which benefits everyone and incentives success but doesn't punish people who are slow. That is the point of this whole thing, I mean really we could just drop 6 chains then go with a straight 10^(L-M) but since we want to help slow people we have the 10^(L-M-O) as this offset allows us to pay some to the slow miners but still a lot to the major players without unnecessarily overpaying either.
- I'm trying to add the getworx protocol to my linux build of rde's miner.
is there any technical information on how this new protocol works anywhere?
-
You know that means the payout is higher when difficulty is fractionally higher which is supposed to be the opposite of PPS. In fact that defeats the entire purpose, i think the point you are missing is that the cap at T prevents overpaying and running into debt as you are payed for every share based off of the difficulty of the block, lower difficulty = more pay so having w ruins this system and makes it likely to collapse, please can everyone go and read about PPS before we have any further discussions on the matter.
https://en.bitcoin.it/wiki/Comparison_of_mining_pools
Edit:I should note that CPPSRB puts all the risk on you guys, by that I mean, if you want to overpay everyone at the pool it means nobody will ever get payed out except for maybe xolo lol who collects his 1% each block. Which is why we want to allow for longer blocks to occur and not suck up all the reserve money.
If this risk is really that high we should consider a simple CWPPS (capped weighted pay per share) model that simply splits up the rewards between the miners according to the aggregated amount of weight their shares have.
[edit]Maybe this is rather a weighted proportional pay model "WP" (close to the current one, but with weight for the shares).[/edit]
Also because it is a first in last out system means faster people get payed out first, that is their only real advantage. Essentially what you want to have is called a "block finder reward" which is stupid and only benefits giants in the long run. What I want is scaled rewards which benefits everyone and incentives success but doesn't punish people who are slow.
There is most likely exactly one share where this mechanism (of giving W a value > 1) kicks in: the one share that solved the block. Although you can call it a block finder reward, I'm trying to explain why this reward is benefecial for the pool. I'm trying to prevent people from tuning their miners not to produce T+1 chains. T+1 are the ones that solve the block definitely (it might be time to refer to http://ppcoin.org/static/primecoin-paper.pdf). So we should neither reward people for not producing long chains which is a point of attack in non-weighted share models (as is currently the case) nor should we reward people for not producing block solving long chains (in a future weighted payment model).
This would in fact punish slower miners even more, because the big players produce roughly 10 times the T chains they produce T+1 chains (unless proven otherwise; and this is the case for all miners, but big players produce them more frequently). If T+1 chains don't have a higher value than the T chains, it would be beneficial for them to gather more shares in T chains than to try to solve the block with a T+1 chain. So it's in my opinion necessary to give a T+1 chain a higher weight than a T chain.
This might sound a bit theoretical and I admit that sounds a bit paranoid as well. But by all means I want to avoid people trying to get an advantage over others by playing unfair - what is the main reason why we think about a replacement of the current payment model ;)
We could simply ignore it and treat that situation in case it occured. But i prefer a system that is as sound as possible.
[TL;DR version]
Having the weight capped at T+1 chains is good. Introducing a cap at T chains plays in the hands of the guys who want to make that their advantage.
In hash based crypto coin pools a block reward is ridiculuous, because solving blocks happens "incidental". For a primecoin pool it makes sense to reward T+1 chains differently, because not generating block solving shares can be of advantage for a special kind of sleazebags.
[/TL;DR version]
That is the point of this whole thing, I mean really we could just drop 6 chains then go with a straight 10^(L-M) but since we want to help slow people we have the 10^(L-M-O) as this offset allows us to pay some to the slow miners but still a lot to the major players without unnecessarily overpaying either.
Paying for 6 chains does not really "help" slow people. The don't get higher rewards in total, but they receive a more continuous payout. Slower miners get constant low rewards (with 6 chains being paid), whereas they did get less regular but higher rewards, if 6 chains were not paid. Taking short chains out of the reward model simply pushes pool mining into the direction of solo mining. That is an option if you want to calculate lesser numbers of shares. Long-term rewards shouldn't differ between those models whereas the reward for a single round gets more fluctuating.
-
If this risk is really that high we should consider a simple CWPPS (capped weighted pay per share) model that simply splits up the rewards between the miners according to the aggregated amount of weight their shares have.
[edit]Maybe this is rather a weighted proportional pay model "WP" (close to the current one, but with weight for the shares).[/edit]
No. Just no. Please, please try to understand there is a LOT going on that your "CWPPS" doesn't seem to understand. First off Pay Per Share means you are PAYED PER each SHARE you submit, regardless of round or last block, you get payed. You are simply proposing as your edit states, a proportional version with weighted shares. The largest benefit of CPPSRB is that there is MUCH less variance in payout compared to Proportional, in fact there is NO variance. You are payed the highest amount possible that is why over the long run people like PPS, as it pays out the most. The reason why straight PPS is bad is because the risk is on the operator of the pool as they need to continually pay the miners regardless of blocks being found which can easily cause a pool to go bust. However CPPSRB fixes this issue by only paying out what it can and creating a queue to payout people once 4 simple things have occurred. 1: They have gone over a specified minimum payout for the processing to occur, 2: The shares of the blocks they were mining on have matured and are now accessible to the pool for payouts, 3: The pool has payed off all prior shares to where it has caught up with the shares of said miner where thus finally 4: A block is found and all transactions are put into it and thus the payout is complete.
The only "risk" of not using my offset for the payout is that it will take MUCH longer to recieve payouts and the queue will become too long due to the fact that not only are 6 chains becoming a drag but also because larger chains are eating all the block rewards. I feel like I need to break down this into math because you just aren't getting it.
lets assume the difficulty for this example is 9.86, which gives us ~10.275 coins
the value of each share without weights would equal
10.275 coins 10.275
---------------- = --------------- = 5.3658464391151582921566197985352e-4 or 0.00053658464391151582921566197985352
e^9.86 19148.8894
so each share is worth about 0.00053658 primecoins, we can calculate the number of shares needed to fufill this by doing the inverse
10.275
---------------=19,148.889400000000000000000000125 or 19,148.8894 which is EXACTLY the value of e^difficulty
0.00053658...
So, we have ~19 thousand of these 0.00053658 primecoin shares that we can dish out, but if you look at a normal round such as any of them here (http://www.beeeeer.org/blocks) you can see on their own that is about how many 6 chains are produced, hence why we need to offset for this and thus allow for longer rounds without wasting as much money on 6 chains while still rewarding 7 chains and above. Infact with my offset the 7 chains become the new standard payout with a weight of 1 which will allow us to successfully phase out 6 chains once the 10 chain blocks occur or whenever Xolo wishes to be honest.
There is most likely exactly one share where this mechanism (of giving W a value > 1) kicks in: the one share that solved the block. Although you can call it a block finder reward, I'm trying to explain why this reward is benefecial for the pool. I'm trying to prevent people from tuning their miners not to produce T+1 chains. T+1 are the ones that solve the block definitely (it might be time to refer to http://ppcoin.org/static/primecoin-paper.pdf). So we should neither reward people for not producing long chains which is a point of attack in non-weighted share models (as is currently the case) nor should we reward people for not producing block solving long chains (in a future weighted payment model).
This would in fact punish slower miners even more, because the big players produce roughly 10 times the T chains they produce T+1 chains (unless proven otherwise; and this is the case for all miners, but big players produce them more frequently). If T+1 chains don't have a higher value than the T chains, it would be beneficial for them to gather more shares in T chains than to try to solve the block with a T+1 chain. So it's in my opinion necessary to give a T+1 chain a higher weight than a T chain.
This might sound a bit theoretical and I admit that sounds a bit paranoid as well. But by all means I want to avoid people trying to get an advantage over others by playing unfair - what is the main reason why we think about a replacement of the current payment model ;)
We could simply ignore it and treat that situation in case it occured. But i prefer a system that is as sound as possible.
We are pretty set on a CPPSRB system so your idea of allowing up to T+1 is still ridiculous as it would literally be equivalent to giving a 10 chain finder 0.00053658*10^(10-6) or 0.00053658*10000=5.3658 primecoins THAT IS HALF OF THE BLOCK, this would effectively eliminate ANY possibility of ever producing a surplus of coins for the pool and overpay the largest miners the most. If however you wanted to include my offset then we would be giving them =0.00053658*10^(10-6-1) or 0.00053658*1000=0.53658 primecoins. If you cap it to a length of the target you pay a 10 chain or higher =0.00053658*10^(9-6-1) or 0.00053658*100=0.053658 primecoins. I would be fine with paying out 5% of the block to the finder, however that basically means that everyone else is only earning 95% of the block in a sense even though that is not technically true, I just don't like the idea of block finder rewards but I would be willing to accept it in this situation. So yes I am accepting the idea of capping the max payout weight at T+1. Xolo your move ;)
However I do have a part with this bit, even though I know where it is coming from
I'm trying to prevent people from tuning their miners not to produce T+1 chains. T+1 are the ones that solve the block definitely
Ummm you don't understand anything about math or primecoin mining or mining in general if that is a concern for you. If people could tune their miners to find Difficulty + 1 they would be solomining and finding ALL THE BLOCKS. My friend, we want people to have the best settings and find higher shares, which is why we weight them and pay them more when they find better shares and find blocks, they do this by tuning their software. All we can do is incentivize them. There will NEVER be a situation where people will avoid finding blocks WHEN FINDING BLOCKS PAYS YOU MORE due to the exponentially weighted values. Please don't spread fear and misinformation because if people are at the level that they can tune to produce the target IE 9 chains regularly instead of 10 chains regularly they are probably over at ypool.
[TL;DR version]
Having the weight capped at T+1 chains is good. Introducing a cap at T chains plays in the hands of the guys who want to make that their advantage.
In hash based crypto coin pools a block reward is ridiculuous, because solving blocks happens "incidental". For a primecoin pool it makes sense to reward T+1 chains differently, because not generating block solving shares can be of advantage for a special kind of sleazebags.
[/TL;DR version]
Again see previous statements, btw the term you are looking for is normally called "block withholding" but here it is more like they would be wasting time as they could be getting payed more by actually producing blocks on their own with solo mining.
Paying for 6 chains does not really "help" slow people. The don't get higher rewards in total, but they receive a more continuous payout. Slower miners get constant low rewards (with 6 chains being paid), whereas they did get less regular but higher rewards, if 6 chains were not paid. Taking short chains out of the reward model simply pushes pool mining into the direction of solo mining. That is an option if you want to calculate lesser numbers of shares. Long-term rewards shouldn't differ between those models whereas the reward for a single round gets more fluctuating.
This is one point where you are dead wrong. Regular payouts help slower miners WAY more than just about anything else, simply due to the fact that variance plays a HUGE part in every other payout system which usually works against the small miner plus they can't get a stable source of coins due to their low mining abilities. The same can be said about 6 chains, variance affects payout so lower variance IE lower min chain length = higher payout for smaller miners due to their lower likelyhood of producing larger chains and bad luck. I mean to be honest if we cut out the 6 chains, mining would look a lot more similar to bitcoin mining where you only produce a couple shares every couple of minutes even on ok hardware. Either way solomining is more profitable than ypool and yes I have/had the primecoins to prove this, however pool mining is more constant.
Also just a note earlier you mentioned using powers of 11 instead of 10, while this does look similar to the stats I suppose using 11 as the exponent could work however it is more of an annoying number than anything which is why I preferred 10, plus logic says that it should be a factor of 10, so for now I am gonna stick with 10 though if Xolo wants to use 11 I would not be against it.
Also Xolo, your dry run is looking great, only problem is that your values are half what I said they should be lol
0.000276 instead of 0.000537 and so on
I guess we have some bad luck ;) or O should be 2 which would then mean we don't need to use your 5.2 offset.
-
you're calculating the 7-chains.
atm it's calculated this way:
adjustment * (0.1 * 10^(length_submitted - 6)) * (block_reward / e^block_difficulty)
6 -> 0.0000525
7 -> 0.000525
8 -> 0.00525
9 -> 0.0525
currently the adjustment is ~5, which leads to the values you see on the block page
adjustment is used to max out payment for the miners (pool balance ~ 0)
- xolokram
profileth's prototype for Beeeeer.org's primecoin CPPSRB with weighted values or PPfBP_CPPSRBWV
F=Fee %, default 0.01
D=Difficulty of current block
M = Minimum chain length accepted, default should be 6
T = Target chain length based on difficulty checked every block to be sure, default should be truncated D IE if 9.8 then T=9
L = Length Submitted, no default
O = Offset of the weight, lower means less payout but less chance of pool debt, default should be 1
V = Value IE weight, calculated as 10^(L-M-O)
V should = 0.1*10^(L-M)) which is the same as the above if O=1
(999/D^2)*(1-F)
---------------------------- * V = primecoins per share
e^Dwith this 18k 6-chains are possible or 1800 7-chains or 180 8-chains or 18 9-chains (if i calculated correct)
the adjustment reduces the amount
@everybody:
you can check your theoretical (aka not yet implemented) payout for PPS here and compare it to the current payout system: e.g.
http://www.beeeeer.org/block/168481/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
http://www.beeeeer.org/block/168452/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
http://www.beeeeer.org/block/168451/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
http://www.beeeeer.org/block/168446/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
http://www.beeeeer.org/block/168384/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
looks pretty fair getting paid-per-share
-
with this 18k 6-chains are possible or 1800 7-chains or 180 8-chains or 18 9-chains (if i calculated correct)
Only mistake is that you forgot to factor in the 0.1*10^(L-M) as the 0.1 is the offset that raises the amount of allowed 6 shares to about 180k or precisely 10.14/0.0000525=193,142 so more like 193k ;)
This is the reason that the numbers actually work and aren't all just negative for pool reserves ;)
I was smart and caught myself and I turned out I was right and did need the 0.1 starting point
BTW on the user pages (not the per block user pages) for everyone you should add some global stats to see how much we have earned so far, our number of x chains and average stuff and blah and blah you know ;)
-
BTW on the user pages (not the per block user pages) for everyone you should add some global stats to see how much we have earned so far, our number of x chains and average stuff and blah and blah you know ;)
will be next as i'm curious about the numbers too, but this will take some time as i'm busy for today
maybe Sy can add some dirty'n'quick solution for this?!? ;D
- xolokram
-
If this risk is really that high we should consider a simple CWPPS (capped weighted pay per share) model that simply splits up the rewards between the miners according to the aggregated amount of weight their shares have.
[edit]Maybe this is rather a weighted proportional pay model "WP" (close to the current one, but with weight for the shares).[/edit]
No. Just no. Please, please try to understand there is a LOT going on that your "CWPPS" doesn't seem to understand. First off Pay Per Share means you are PAYED PER each SHARE you submit, regardless of round or last block, you get payed. You are simply proposing as your edit states, a proportional version with weighted shares.
[...]
We are pretty set on a CPPSRB system
Is that so? In a proportional version with weighted shares you are paid for each share you submit as well. Just not with a fixed value but a proportional value.
[...]
Ummm you don't understand anything about math or primecoin mining or mining in general if that is a concern for you.
Sorry if my implied ignorance offends you, but I might have some understanding about math, the probability that a number is prime in general and primecoin mining. Can you explain what's wrong with the statement "a T+1 chain solves the block"?
If people could tune their miners to find Difficulty + 1 they would be solomining and finding ALL THE BLOCKS. My friend, we want people to have the best settings and find higher shares, which is why we weight them and pay them more when they find better shares and find blocks, they do this by tuning their software. All we can do is incentivize them. There will NEVER be a situation where people will avoid finding blocks WHEN FINDING BLOCKS PAYS YOU MORE due to the exponentially weighted values. Please don't spread fear and misinformation because if people are at the level that they can tune to produce the target IE 9 chains regularly instead of 10 chains regularly they are probably over at ypool.
I wasn't not talking about people tuning their miners to only produce T+1 chains. I was talking about people to tune their miners NOT TO PRODUCE T+1 chains. That is something completely different.
But it seems I didn't take into consideration the relatively little amount of time it takes to do the euler-lagrange-lifchitz test for the next number in the chain to test its primality. That was the base for the misinterpretation. In fact solving a block rather than holding back possible solutions would be beneficial for malicious miners, too. They could most likely not aggregate enough shares (by saving the time for testing the next element in the chain) to compensate the longer cycle.
I was not trying to spread fear nor misinformation. I was just trying to "harden" the payment system for being safe against that kind of potental attack, which is, as I now assume, no smart attack and will most likely not happen.
Paying for 6 chains does not really "help" slow people. The don't get higher rewards in total, but they receive a more continuous payout. Slower miners get constant low rewards (with 6 chains being paid), whereas they did get less regular but higher rewards, if 6 chains were not paid. Taking short chains out of the reward model simply pushes pool mining into the direction of solo mining. That is an option if you want to calculate lesser numbers of shares. Long-term rewards shouldn't differ between those models whereas the reward for a single round gets more fluctuating.
This is one point where you are dead wrong. Regular payouts help slower miners WAY more than just about anything else, simply due to the fact that variance plays a HUGE part in every other payout system which usually works against the small miner plus they can't get a stable source of coins due to their low mining abilities. The same can be said about 6 chains, variance affects payout so lower variance IE lower min chain length = higher payout for smaller miners due to their lower likelyhood of producing larger chains and bad luck. I mean to be honest if we cut out the 6 chains, mining would look a lot more similar to bitcoin mining where you only produce a couple shares every couple of minutes even on ok hardware. Either way solomining is more profitable than ypool and yes I have/had the primecoins to prove this, however pool mining is more constant.
Variance by cutting out 6 chains is in long-term run not against small miners. It doesn't limit the average income, it makes it just more fluctuating. This should be true for both WP and CWPPS.
Also just a note earlier you mentioned using powers of 11 instead of 10, while this does look similar to the stats I suppose using 11 as the exponent could work however it is more of an annoying number than anything which is why I preferred 10, plus logic says that it should be a factor of 10, so for now I am gonna stick with 10 though if Xolo wants to use 11 I would not be against it.
This is just a number I tried to derive from the ditribution of the shares. I try to find a mathematical rather than a statistical approach.
[edit description]
reworked parts of the post to explain the misunderstanding that lead to the assumption, holding back blocks could be beneficial for big players
[/edit description]
-
BTW on the user pages (not the per block user pages) for everyone you should add some global stats to see how much we have earned so far, our number of x chains and average stuff and blah and blah you know ;)
will be next as i'm curious about the numbers too, but this will take some time as i'm busy for today
maybe Sy can add some dirty'n'quick solution for this?!? ;D
- xolokram
Hmm that's not really possible since the user data is overwritten on each block, if there is a record, sure - np :D at least i can't find any infos in neither blocks nor payout. There are some general stats at the bottom of the entry page though, not sure if that helps... http://xpm.syware.de/
I've put some work into it today, im rather satisfied i must say 8)
-
[...]
There are some general stats at the bottom of the entry page though, not sure if that helps... http://xpm.syware.de/
I've put some work into it today, im rather satisfied i must say 8)
It's awesome! Thank you!
-
[...]
There are some general stats at the bottom of the entry page though, not sure if that helps... http://xpm.syware.de/
I've put some work into it today, im rather satisfied i must say 8)
It's awesome! Thank you!
Yeah, thanks! Keep up the good work.
-
[...]
There are some general stats at the bottom of the entry page though, not sure if that helps... http://xpm.syware.de/
I've put some work into it today, im rather satisfied i must say 8)
It's awesome! Thank you!
Yeah, thanks! Keep up the good work.
One request though, for small miners like myself, the XPM/min isn't that informative as it is rounded off to low numbers. The XPM/day figure you had before was nice. Also, an XPM/hr might be a good compromise.
-
BTW on the user pages (not the per block user pages) for everyone you should add some global stats to see how much we have earned so far, our number of x chains and average stuff and blah and blah you know ;)
will be next as i'm curious about the numbers too, but this will take some time as i'm busy for today
maybe Sy can add some dirty'n'quick solution for this?!? ;D
- xolokram
Superb work Sy !!!! :D
Hmm that's not really possible since the user data is overwritten on each block, if there is a record, sure - np :D at least i can't find any infos in neither blocks nor payout. There are some general stats at the bottom of the entry page though, not sure if that helps... http://xpm.syware.de/
I've put some work into it today, im rather satisfied i must say 8)
- Zolokram is it possible to have the xpt protocol when the new pps system becomes active, some of us would like to use jhprimeminer?
Cheers n beeeeers
Roger
- Hey Xolo, is there currently a cap on payouts of T+1 because I just saw this in the most recent block
http://www.beeeeer.org/block/169217/ANxERLYcT6jsKdzybBjuFBCco7v7fC1vqc
"your_payout": 0.6349354336018664,
"details": {
"0": 67,
"6": 3098,
"7": 307,
"8": 24,
"9": 3,
"169217": 1,
"-6": 1
},
"your_payout_PPS": 3.190821151559353
}
I am wondering if the "169217": 1, is the cause of the massive spike.
Also I was thinking it may be necessary to set O to 2 that means change 0.1*10^(L-M) to 0.01*10^(L-M)
I say this because it looks like just about everyone is gonna want a piece of beeeeer seeing as our hashrate and number of miners has doubled in the last couple of days. Also you may want to use an adjustment of * 5 if you use 0=2 to offset the 10 fold decrease to instead by 2 times less. Also you still need to implement the shelved part of CPPSRB meaning that as soon as the amount of shares payed out goes over the block's generated amount of coins the rest of the shelves are shelved and payed back later IE put onto the next block. I noticed that it doesn't show this in the stats yet for individuals. Either way you should probably use a starting point that you a
-
Zolokram is it possible to have the xpt protocol when the new pps system becomes active, some of us would like to use jhprimeminer?
Cheers n beeeeers
Roger
Maybe... i prefer to concentrate on the important stuff first, Loger.
Hey Xolo, is there currently a cap on payouts of T+1 because I just saw this in the most recent block
http://www.beeeeer.org/block/169217/ANxERLYcT6jsKdzybBjuFBCco7v7fC1vqc
"your_payout": 0.6349354336018664,
"details": {
"0": 67,
"6": 3098,
"7": 307,
"8": 24,
"9": 3,
"169217": 1,
"-6": 1
},
"your_payout_PPS": 3.190821151559353
}
I am wondering if the "169217": 1, is the cause of the massive spike.
there is no cap on a T+1 chain (? what i actually mean: the PPS system currently only calculates the payout for 6,7,8,9 shares ?) and the CPPSRB payout system is not active yet (but it will be soon).
the high-chain-share indicates that this miner found the block. so this is actually a 9,8x chain or higher
you really didnt knew this (it was mentioned ~4 times in this thread already :D) ?
anyway, you are 'right', there's a mistake in the pps payout calculation as it ignores block found shares, what a reward, eh? :) thanks for figuring out before it goes online
I say this because it looks like just about everyone is gonna want a piece of beeeeer seeing as our hashrate and number of miners has doubled in the last couple of days. Also you may want to use an adjustment of * 5 if you use 0=2 to offset the 10 fold decrease to instead by 2 times less. Also you still need to implement the shelved part of CPPSRB meaning that as soon as the amount of shares payed out goes over the block's generated amount of coins the rest of the shelves are shelved and payed back later IE put onto the next block. I noticed that it doesn't show this in the stats yet for individuals. Either way you should probably use a starting point that you a
the pps system is not ready/online. i will add proper stats for everyone when it's done. your last sentence looks crippled ;)
- Zolomark
-
lol I apparently just hit enter then got busy looking at something else.
Either way you should probably use a starting point that you are able to soak long rounds while not underpaying on short rounds.
Is what I meant to say.
- Zolomark
also Zolomark? ??? who is this mysterious fellow
but yeah I am definitely feeling like right now it is currently paying out too much, given that even a relatively short round is using up all 10
I say go with halving the payout and try that.
- yeah, i have to change the value, 5.25 (with 0=1) is just a first starting point
i'm pretty sure i have to adjust the value anyway after the PPS System goes online
and when it works like intented it will be monitored every day/week (i have now real estimation for now)
Zolomark is my alter ego; he's the cynical guy of us 4. :D
- xolokram
ps. i'll check what happens with halving the pps payout
pps. halving gave the pool a current balance of +2017, i'll try something else
- You shouldn't look at the ENTIRE history of the pool, maybe only the last day or so as there has been a gigantic increase in miners and hashrate which shows a more realistic projection of what is to come.
- i'm currently looking only at the recent blocks and i'm aware of the fact that more&more people entered the pool in the last days/hours
more people using the pool shouldn't change too much as long as the shares/block doesn't change too much (this is a relative statement ;) )
it would be just more block for everyone (imho)
- Hmm, actually I just remembered something. The Pool is almost supposed to be in debt every so often, that just means it is working fine, which is why there is the shelving system. I mean if you look at Eligius http://eligius.st/~wizkid057/newstats/ Luck below 100% means they payed out more than they earned by the percentage, so 50% luck means they payed out double, where as 500% luck means hey payed out 5 times less. The only difference is that we don't have anything to compare with stats wise to show what percentage would be shelved, as you can see from their graphs at the beginning they had a very large amount shelved that eventually evened out to about 2% normally.
- from a psychological point of view it would be better to start with a lower factor and increase it slowly to adjust the payout.
just like you said, there are not enough stats to compare with.
i'm off for today, good night.
- xolokram
-
... I suppose using 11 as the exponent could work however it is more of an annoying number than anything which is why I preferred 10, plus logic says that it should be a factor of 10, ...
Your mathematical skills are in evidence now.
-
... I suppose using 11 as the exponent could work however it is more of an annoying number than anything which is why I preferred 10, plus logic says that it should be a factor of 10, ...
Your mathematical skills are in evidence now.
When I say it is more annoying I mean, it is not only a prime number which makes it much harder to rescale it's exponents which are also annoying numbers such as 121,1331,14641. Plus you would have to manually offset it rather than using a simple reduction of the exponent to achieve similar effects.
Also Xolo why not try a simple 10% ie 0.09*10^(L-M) instead of 0.1*10^(L-M), that should be enough leeway to not constantly be negative.
-
... I suppose using 11 as the exponent could work however it is more of an annoying number than anything which is why I preferred 10, plus logic says that it should be a factor of 10, ...
Your mathematical skills are in evidence now.
When I say it is more annoying I mean, it is not only a prime number which makes it much harder to rescale it's exponents which are also annoying numbers such as 121,1331,14641. Plus you would have to manually offset it rather than using a simple reduction of the exponent to achieve similar effects.
Also Xolo why not try a simple 10% ie 0.09*10^(L-M) instead of 0.1*10^(L-M), that should be enough leeway to not constantly be negative.
Maybe I shouldn't write this in a hurry, but doesn't produce 0.1^(M+2-L)*10 the same results as 0.1*10(L-M)? So the formula could easily be adjusted to whatever factor that seems appropriate for a chain length step-up. Say it were a probability of 1/11 to find a chain L+1 in comarison to find a chain L, you could calculate that part of the weight formula as (1/11)^(M+2-L)*10.
That would replace a linear behaviour...
I don't see why we need to rescale the exponents and if ever necesary this could be done with logarithms, or not?
-
One request though, for small miners like myself, the XPM/min isn't that informative as it is rounded off to low numbers. The XPM/day figure you had before was nice. Also, an XPM/hr might be a good compromise.
Both XPM/Min and XPM/Hour in details aren't really reliable, the xpm/d on a reached payout treshold should be way more accurate since it's calculating over more blocks than one, thus averaging much better - i'm thinking about removing it in the details view since it's pretty dependant on block time and varies highly even though you're still using the same ressources.
- regarding the latest value calculation discussion:
http://jsfiddle.net/thbaumbach/UKww8/ - play with it
this is the pool's point of view (with most recent 300 blocks).
- xolokram
<small suggestion was crappy>
-
regarding the latest value calculation discussion:
http://jsfiddle.net/thbaumbach/UKww8/ - play with it
this is the pool's point of view (with most recent 300 blocks).
- xolokram
<small suggestion was crappy>
Are those totals (per block or overall) accessable by url somehow?
- what do you mean by totals ?
-
what do you mean by totals ?
http://xpm.syware.de/stats.php
pChart is kinda nice, gotta find the % coloring though ;D
Something like http://beeeeer.org/block/169979/$address but not for that address but for the whole block so i can auto generate it.
- the share details per block are visible at the main block page:
http://www.beeeeer.org/blocks
see "shares by length (6|7|8|9)"
the user details per block (regarding shares) are also available in the user-block details:
e.g. http://www.beeeeer.org/block/169952/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
see "details"
- xolokram
-
the share details per block are visible at the main block page:
http://www.beeeeer.org/blocks
see "shares by length (6|7|8|9)"
the user details per block (regarding shares) are also available in the user-block details:
e.g. http://www.beeeeer.org/block/169952/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
see "details"
- xolokram
Okay but not inside the /block/$id file - parsing is more work than a nice json array ;D would be awesome if you could write all your http://beeeeer.org/blocks data into the blockfile itself too 8)
Just checked the chains distribution values, they are kinda boring since the basicly don't change at all...no point in visualizing them.
- small maintenance, server will be back in ~10-15 minutes ::) :o
- Is there any way to set payment threshold above 3 (for example 10 XPM) and without that annoying fee! Because I don't want to see sums like 2.99196 in my wallet.
-
Is there any way to set payment threshold above 3 (for example 10 XPM)
yes, by discussing it here and changing the threshold for everyone if it's acceptable for the majority. otherwise i would need a registration system, at that's not going to happen.
and without that annoying fee! Because I don't want to see sums like 2.99196 in my wallet.
nope, it's part of the primecoin network, i'm not able to change that.
- xolokram
- Hi all,
When was the last payment from pool?
- hi xolokram i wanted to know if your miner has the disconnect bug s i am tired of all other miners and having to check all my vps every day . Dose it reconnect also once pool is back online do they reconnect as i was having problems with my one core vps amd they disconnect from miner 3.3 and others can you please let me know
- @elvisrene:
they should reconnect (v0.3) on their own, when the server's back online.
@Boo-Boo:
block 166928
(we're right now at block 17160, so it was the most recent a few minutes ago)
- xolokram
-
yes, by discussing it here and changing the threshold for everyone if it's acceptable for the majority. otherwise i would need a registration system, at that's not going to happen.
It's pity! I think the majority will not agree to increase threshold.
Can you set it to 3.01 at least? ;)
-
@elvisrene:
they should reconnect (v0.3) on their own, when the server's back online.
@Boo-Boo:
block 166928
(we're right now at block 17160, so it was the most recent a few minutes ago)
- xolokram
so i should use version experimental v0.3 i hop so it works well as i have heard your pool is more just then ypool if so you will have a lot of cpu power form me i have more then 400 cores that would really help out your pool
- O and sorry about disconnect bug i mean this
(http://i.imgur.com/EudYsEs.png)
it looks like its looking for a chain but it just stays there in the limbo dose your miner have this issue .If i can make a restart script so it will restart every so often i just want to know before i set it up .Thanks in advance for any advice.
-
Can you set it to 3.01 at least? ;)
done. any further increase should be discussed here :)
so i should use version experimental v0.3
yup, use that one, jhprimeminer and my miner v0.1 use the old 'getwork' protocol, which i'm trying to abandon.
i have heard your pool is more just then ypool
i don't really know what that means, but probably yes, you're right. :)
the server was down for maintenance a few minutes ago and jhprimeminer & v0.1 suffer from a reconnection problem. restart your miner if you want to use one of those two.
- xolokram
ps. v0.4 & CPPSRB payout system coming soon
-
done. any further increase should be discussed here :)
Ok! Thank you! :)
-
@elvisrene:
they should reconnect (v0.3) on their own, when the server's back online.
@Boo-Boo:
block 166928
(we're right now at block 17160, so it was the most recent a few minutes ago)
- xolokram
so i should use version experimental v0.3 i hop so it works well as i have heard your pool is more just then ypool if so you will have a lot of cpu power form me i have more then 400 cores that would really help out your pool
I've been using v0.3RC0 for a couple of days now and it works just fine on Linux.
-
Can you set it to 3.01 at least? ;)
done. any further increase should be discussed here :)
so i should use version experimental v0.3
yup, use that one, jhprimeminer and my miner v0.1 use the old 'getwork' protocol, which i'm trying to abandon.
i have heard your pool is more just then ypool
i don't really know what that means, but probably yes, you're right. :)
the server was down for maintenance a few minutes ago and jhprimeminer & v0.1 suffer from a reconnection problem. restart your miner if you want to use one of those two.
- xolokram
ps. v0.4 & CPPSRB payout system coming soon
is v0.3 still experimental?
-
@elvisrene:
they should reconnect (v0.3) on their own, when the server's back online.
@Boo-Boo:
block 166928
(we're right now at block 17160, so it was the most recent a few minutes ago)
- xolokram
so i should use version experimental v0.3 i hop so it works well as i have heard your pool is more just then ypool if so you will have a lot of cpu power form me i have more then 400 cores that would really help out your pool
I've been using v0.3RC0 for a couple of days now and it works just fine on Linux.
Same here
-
some f***ups going on in the backend, investigating...
server will do some restarts, no panic
ps. ok, i think i know what happened, final restart incoming, everything should be ok in a few minutes
pps. i know what happened, i have to find a smart solution, takes a few minutes --- expect some pool restarts!
ppps. ok, it should be fixed now 8)
- Thanks for the great support...
-
atm it's calculated this way:
adjustment * (0.1 * 10^(length_submitted - 6)) * (block_reward / e^block_difficulty)
6 -> 0.0000525
7 -> 0.000525
8 -> 0.00525
9 -> 0.0525
currently the adjustment is ~5, which leads to the values you see on the block page
adjustment is used to max out payment for the miners (pool balance ~ 0)
I surrender :( (by now). But if you are going to implement any weighting you must "normalize" dividing between the number of terms that you are summing. I mean, if somebody only has 6-chains you should divide by 1, if he has 6-chains and 7-chains you should divide by 2, if he has 6, 7 and 8 length chains you should divide by 3,and if he has also 9-chains you should divide by 4.
See it with an example, four workers, each of them is 1/10 times the other (1/10th of the mining time), and the values used in the formula are "reward": 10.1673, "diff": 9.86121416, "adjust": 5.3:
Value of {"shares": {"6": 3140, "7": 282, "8": 27, "9": 2}} * 1 = 2.996
Value of {"shares": {"6": 314, "7": 28, "8": 3}} * 10 = 2.513
Value of {"shares": {"6": 31, "7": 3}} * 100 = 1.715
Value of {"shares": {"6": 3}} * 1000 = 0.8432
Normalizing, that is correcting for the number of summands, would give proper values:
4/4*2.996 = 2.996
4/3*2.513 = 3.350
4/2*1.715 = 3.430
4/1*0.8432 = 3.373
-
atm it's calculated this way:
adjustment * (0.1 * 10^(length_submitted - 6)) * (block_reward / e^block_difficulty)
6 -> 0.0000525
7 -> 0.000525
8 -> 0.00525
9 -> 0.0525
currently the adjustment is ~5, which leads to the values you see on the block page
adjustment is used to max out payment for the miners (pool balance ~ 0)
I surrender :( (by now). But if you are going to implement any weighting you must "normalize" dividing between the number of terms that you are summing. I mean, if somebody only has 6-chains you should divide by 1, if he has 6-chains and 7-chains you should divide by 2, if he has 6, 7 and 8 length chains you should divide by 3,and if he has also 9-chains you should divide by 4.
See it with an example, four workers, each of them is 1/10 times the other (1/10th of the mining time), and the values used in the formula are "reward": 10.1673, "diff": 9.86121416, "adjust": 5.3:
Value of {"shares": {"6": 3140, "7": 282, "8": 27, "9": 2}} * 1 = 2.996
Value of {"shares": {"6": 314, "7": 28, "8": 3}} * 10 = 2.513
Value of {"shares": {"6": 31, "7": 3}} * 100 = 1.715
Value of {"shares": {"6": 3}} * 1000 = 0.8432
Normalizing, that is correcting for the number of summands, would give proper values:
4/4*2.996 = 2.996
4/3*2.513 = 3.350
4/2*1.715 = 3.430
4/1*0.8432 = 3.373
Why would we do this? I dont really understand how it does anything than pay everyone the act same amount regardless of work put in except for the guy who finds the block he gets payed less... :-\
-
some f***ups going on in the backend, investigating...
server will do some restarts, no panic
v0.2 went through all that and just keeps mining, good work!
- I noticed that the chains/d rate dropped for my v0.3 linux build by 30%, what's different?
-
@Sy:
thank you. wait until v0.4 or CPPSRB --> everything that can go wrong will go wrong!! ;)
(i'm trying to keep expectations as low as possible)
@Lytse:
the original author of the miner my pool-miner is based on (mikaelh) changed the sieve extension default setting to a higher number (higher chance of hitting the target; less shorter chains)
@patapato:
PPS ... pay per share ...
worker #1 gets the most XPMs because he submitted most of the shares ... he's paid per share
worker #2 gets less XPMs because he submitted less shares ... he's paid per share, just like worker #1
...
please tell me, that i'm incorrect, because i don't really get what you want and you're one of the guys here who really brought in some good posts/ideas/discussions.
[going through your post again (and again (and again)) --- i'm trying to figure out what you want --- pls stand by]
i think, what you're missing is, that on the long run your normalization is not needed at all!!
worker #1 is the base
worker #2 will have similar stats to worker #1 in '10 times of time needed by worker #1', thus he'll get the same amount of XPMs for the same work
worker #3 will have similar stats to worker #1 in '100 times of time needed by worker #1', thus he'll get the same amount of XPMs for the same work
worker #4 will have similar stats to worker #1 in '1000 times of time needed by worker #1', thus he'll get the same amount of XPMs for the same work
normalization is not needed. of course worker #1 gets most of the reward at a specific point of time, but he's also contributing most of the shares until then.
but there's not one point of time where everybody's getting their payout calculated. it's continuous.
- xolokram
ps. CPPSRB & v0.4 is scheduled for tomorrow evening; if everything works as intended and nobody's bringing up some serious flaw of the idea
-
thank you. wait until v0.4 or CPPSRB --> everything that can go wrong will go wrong!! ;)
(i'm trying to keep expectations as low as possible)
Bring it on ;D 8)
- hahaha looks like we'er on fire added 400 cores will add 400 cores more
- xolo one question how long dose it take until i start seeing the xpm going in to my wallet
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
-
@patapato:
PPS ... pay per share ...
worker #1 gets the most XPMs because he submitted most of the shares ... he's paid per share
worker #2 gets less XPMs because he submitted less shares ... he's paid per share, just like worker #1
...
please tell me, that i'm incorrect, because i don't really get what you want and you're one of the guys here who really brought in some good posts/ideas/discussions.
Thank you! ;)
...
worker #4 will have similar stats to worker #1 in '1000 times of time needed by worker #1', thus he'll get the same amount of XPMs for the same work
It is not true, that is the problem. I will try to put it without the confusing factors 1, 10, 100, 1000 (I wrote it to clarify but I think it had the opposite effect).
- worker #1 gets 2.996
- worker #2 gets 0.2513
- worker #3 gets 0.01715
- worker #4 gets 0.0008432
It is NOT a factor 10 between the share value of each worker,
worker #3 shoud get 10 times #4, but he gets 2*10
worker #2 should get 100 times #4, but he gets 3*100
worker #1 should get 1000 times #4, but he gets close to 4*1000 (3.55 in fact, but the difference is due to less 9-chains than expected by the model)
This effect is due to the fact that when you do weighting you are trying to give comparable value to chains of each length, so the correct way is not summing the weighted values, but averaging the weighted values. Otherwise you are disfavoring to the people with only 6-chains, or only 6- and 7-chains, who are the mayority.
Averaging after weighting gives a proportion close to 10 between workers in the example:
4/4*2.996 = 2.996
4/3*0.2513 = 0.3350
4/2*0.01715 = 0.03430
4/1*0.0008432 = 0.003373
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i have already but still have not one coin in my wallet http://xpm.syware.de/?address=ARTJCDz1XEKvT5kSZouPLWnxQooJ6Hi1d9&details=2 and i am using your site i was looking around and im number 2 in pool but i still dont see coins
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i have already but still have not one coin in my wallet http://xpm.syware.de/?address=ARTJCDz1XEKvT5kSZouPLWnxQooJ6Hi1d9&details=2 and i am using your site i was looking around and im number 2 in pool but i still dont see coins
Your xpm has not matured yet!
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i have already but still have not one coin in my wallet http://xpm.syware.de/?address=ARTJCDz1XEKvT5kSZouPLWnxQooJ6Hi1d9&details=2 and i am using your site i was looking around and im number 2 in pool but i still dont see coins
Your xpm has not matured yet!
ok thank you buddy
-
@patapato:
PPS ... pay per share ...
worker #1 gets the most XPMs because he submitted most of the shares ... he's paid per share
worker #2 gets less XPMs because he submitted less shares ... he's paid per share, just like worker #1
...
please tell me, that i'm incorrect, because i don't really get what you want and you're one of the guys here who really brought in some good posts/ideas/discussions.
Thank you! ;)
...
worker #4 will have similar stats to worker #1 in '1000 times of time needed by worker #1', thus he'll get the same amount of XPMs for the same work
It is not true, that is the problem. I will try to put it without the confusing factors 1, 10, 100, 1000 (I wrote it to clarify but I think it had the opposite effect).
- worker #1 gets 2.996
- worker #2 gets 0.2513
- worker #3 gets 0.01715
- worker #4 gets 0.0008432
It is NOT a factor 10 between the share value of each worker,
worker #3 shoud get 10 times #4, but he gets 2*10
worker #2 should get 100 times #4, but he gets 3*100
worker #1 should get 1000 times #4, but he gets close to 4*1000 (3.55 in fact, but the difference is due to less 9-chains than expected by the model)
This effect is due to the fact that when you do weighting you are trying to give comparable value to chains of each length, so the correct way is not summing the weighted values, but averaging the weighted values. Otherwise you are disfavoring to the people with only 6-chains, or only 6- and 7-chains, who are the mayority.
Averaging after weighting gives a proportion close to 10 between workers in the example:
4/4*2.996 = 2.996
4/3*0.2513 = 0.3350
4/2*0.01715 = 0.03430
4/1*0.0008432 = 0.003373
I think you misunderstand the point of PPS, you are being payed on your ability to produce blocks. In effect an unweighted PPS uses the likelyhood of block generation IE difficulty and pays you for every share based upon how long it should take to generate a block. We know better than to do that with primecoins so we are shooting for something more similar to POT which stands for Pay On Target. (https://bitcointalk.org/index.php?topic=131376.0) the only difference is that our method pays out more but you have to wait longer for your shares to become unshelved. If all else fails we can switch to POT and simply use the chains as values, though that would require a fair bit more calculation on the backend. FYI Xolo sorry I forgot to mention this payout method before I just assumed it couldn't be done as you didn't want to read the exact values of every share.
- More properly explained (I think), let there be four workers, each of them is 1/10 times the other:
worker #1 submitted chains: {"6": 3140, "7": 282, "8": 27, "9": 2}
worker #2 submitted chains: {"6": 314, "7": 28, "8": 3}
worker #3 submitted chains: {"6": 31, "7": 3}
worker #4 submitted chains: {"6": 3}
Let use "block_reward": 10.1673, "block_difficulty": 9.86121416 and "adjustment": 4*5.3 = 21.2 (to keep results close to the original). Then we should compute for each worker the average of the values obtained for each length with the weighting formula (http://ppcointalk.org/index.php?topic=485.msg3935#msg3935) (not just the sum, but dividing the sum by the number of summands), in order that the payment for each worker be about 1/10 times the previous, as it should be:
worker #1 XPM: (3.5302 + 3.1704 + 3.0355 + 2.2485) / 4 = 2.996
worker #2 XPM: (0.35302 + 0.31479 + 0.33728) / 3 = 0.3350
worker #3 XPM: (0.034852 + 0.033728) / 2 = 0.03430
worker #4 XPM: (0.003373) / 1 = 0.003373
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i have already but still have not one coin in my wallet http://xpm.syware.de/?address=ARTJCDz1XEKvT5kSZouPLWnxQooJ6Hi1d9&details=2 and i am using your site i was looking around and im number 2 in pool but i still dont see coins
Damn thats some serious CPU power :D
And yes, Blocks have to mature, that takes around 2.5 day for the first mined xpm to be credited.
-
More properly explained (I think), let there be four workers, each of them is 1/10 times the other:
worker #1 submitted chains: {"6": 3140, "7": 282, "8": 27, "9": 2}
worker #2 submitted chains: {"6": 314, "7": 28, "8": 3}
worker #3 submitted chains: {"6": 31, "7": 3}
worker #4 submitted chains: {"6": 3}
Let use "block_reward": 10.1673, "block_difficulty": 9.86121416 and "adjustment": 4*5.3 = 21.2 (to keep results close to the original). Then we should compute for each worker the average of the values obtained for each length with the weighting formula (http://ppcointalk.org/index.php?topic=485.msg3935#msg3935) (not just the sum, but dividing the sum by the number of summands), in order that the payment for each worker be about 1/10 times the previous, as it should be:
worker #1 XPM: (3.5302 + 3.1704 + 3.0355 + 2.2485) / 4 = 2.996
worker #2 XPM: (0.35302 + 0.31479 + 0.33728) / 3 = 0.3350
worker #3 XPM: (0.034852 + 0.033728) / 2 = 0.03430
worker #4 XPM: (0.003373) / 1 = 0.003373
worker #1 & worker #4 will get the same payout for the same work <-- aka fair payout
the only difference is, worker #4 will need more time for this (but he's the miner with less computing power)
the addition of a normalization is not necessary
actually the normalization would then prefer shares that are producable above the 1/10th-assumption (or whatever assumption would be the base)
and this is bad because the real distrubution of shares per length isn't the ideal assumption of 1/10th to 1/10th to 1/10th and what's even worse it's adjustable via mining parameter
that's why we don't want to have equal values for all 6-chains, 7-chains, 8-chains & 9-chains via normalization
(e.g. worker #1 in your example should discard all 9-chains)
question:
what are the shares (# of shares per length) for worker #4 submitted until block #1000 in your example??
i will add your suggestions to the dry-run-setup --- guess the cppsrb will be delayed ;)
but i (currently) think that normalization of the chain length has no real advantage.
in you example, worker #1 is not submitting 1000 x the work of worker #4 (in terms of value of the submitted work)
he's doing 4000 x the work of #4, because you assume that all 6-chains should be equally valued to all 7-chains (and 7-to-8 and 8-to-9) at a specific point of time, right? :-X
or another example: some worker is submitting
{"6":1, "9":1}
i would be really pissed if the normalization is in the calculation
- xolokram
ps. enough of the edits for now... :D
-
More properly explained (I think), let there be four workers, each of them is 1/10 times the other:
worker #1 submitted chains: {"6": 3140, "7": 282, "8": 27, "9": 2}
worker #2 submitted chains: {"6": 314, "7": 28, "8": 3}
worker #3 submitted chains: {"6": 31, "7": 3}
worker #4 submitted chains: {"6": 3}
Let use "block_reward": 10.1673, "block_difficulty": 9.86121416 and "adjustment": 4*5.3 = 21.2 (to keep results close to the original). Then we should compute for each worker the average of the values obtained for each length with the weighting formula (http://ppcointalk.org/index.php?topic=485.msg3935#msg3935) (not just the sum, but dividing the sum by the number of summands), in order that the payment for each worker be about 1/10 times the previous, as it should be:
worker #1 XPM: (3.5302 + 3.1704 + 3.0355 + 2.2485) / 4 = 2.996
worker #2 XPM: (0.35302 + 0.31479 + 0.33728) / 3 = 0.3350
worker #3 XPM: (0.034852 + 0.033728) / 2 = 0.03430
worker #4 XPM: (0.003373) / 1 = 0.003373
worker #1 & worker #4 will get the same payout for the same work <-- aka fair payout
the only difference is, worker #4 will need more time for this (but he's the miner with less computing power)
the addition of a normalization is not necessary
actually the normalization would then prefer shares that are producable above the 1/10th-assumption (or whatever assumption would be the base)
and this is bad because the real distrubution of shares per length isn't the ideal assumption of 1/10th to 1/10th to 1/10th and what's even worse it's adjustable via mining parameter
that's why we don't want to have equal values for all 6-chains, 7-chains, 8-chains & 9-chains via normalization
(e.g. worker #1 in your example should discard all 9-chains)
question:
what are the shares (# of shares per length) for worker #4 submitted until block #1000 in your example??
i will add your suggestions to the dry-run-setup --- guess the cppsrb will be delayed ;)
but i (currently) think that normalization of the chain length has no real advantage.
in you example, worker #1 is not submitting 1000 x the work of worker #4 (in terms of value of the submitted work)
he's doing 4000 x the work of #4, because you assume that all 6-chains should be equally valued to all 7-chains (and 7-to-8 and 8-to-9) at a specific point of time, right? :-X
or another example: some worker is submitting
{"6":1, "9":1}
i would be really pissed if the normalization is in the calculation
- xolokram
ps. enough of the edits for now... :D
In my example, worker #1 is doing 1000x the work of #4. You can think that he is the same worker in 1000x time, or the same worker with 1000x computing power. Thus, I don't assume anything about what the value of each length should be. Assumptions are only on the weighting model, and that model is not mine ;) .
I just say that the same worker in a 1000x time should be payed 1000x. The only way to get it with any proper weighting model is to average the weighted values, not to sum them. (*)
I think that your "another example" has probability < 1/1000 of being real; if there was many like this one, your model for the weights would not be valid. But yes, even that example should be treated averaging weighted values for the 6 chain and 9 chain.
(*) Clue: if we divide 314 by 1000, round the result to integer, and then apply any weight, for example a 1000x weight, the result would be 0, despite it should be 314 without rounding. If this clue don't clarify you, please don't take it into account.
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i have already but still have not one coin in my wallet http://xpm.syware.de/?address=ARTJCDz1XEKvT5kSZouPLWnxQooJ6Hi1d9&details=2 and i am using your site i was looking around and im number 2 in pool but i still dont see coins
Damn thats some serious CPU power :D
And yes, Blocks have to mature, that takes around 2.5 day for the first mined xpm to be credited.
yea it is a lot of power and i still have to add 400 cores more
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i have already but still have not one coin in my wallet http://xpm.syware.de/?address=ARTJCDz1XEKvT5kSZouPLWnxQooJ6Hi1d9&details=2 and i am using your site i was looking around and im number 2 in pool but i still dont see coins
Damn thats some serious CPU power :D
And yes, Blocks have to mature, that takes around 2.5 day for the first mined xpm to be credited.
yea it is a lot of power and i still have to add 400 cores more
Make it rain! More power in the pool means faster blocks!
-
...
ok, here's my (last?) attempt to convince you: ;)
let's say you have 2 miners:
a) one mining 1000 chains per payout-interval (whatever that means (1hour, 1block...))
b) one mining 1 chain per payout-interval
you'll agree, that both will have the same distribution of 'shares per chain-length' (in a ideal world): let's say
{ 6 = 900, 7 = 90, 8 = 9, 9 = 1 }
the only difference:
a needs 1 payout-interval, b needs 1000 payout-intervals!
with your normalization:
b will get 4x the payout of a for the same work !
(because b sumbits only 1 share per payout-calculation, thus his divisor will be always 1, while a will submit everything and gets a divisor of 4)
we dont need your normalization
because we already normalized the payout by giving every chain-length a specific value loosely based on the relative frequency of this chain-length
(e.g. 6 = 0.01 XPM, 7 = 0.1 XPM, 8 = 1 XPM , 9 = 10 XPM <-- that doesn't mean that the values are perfect)
- xolokram :o
ps. you can scale that example arbitrarily: let's say c is a miner mining 50 chains per payout-interval... you'll have the same (maybe less extreme) issue here... your normalization breaks the PPS scheme
pps. cheating would be easy: modify the miner-code to submit every share for a specific user(-address), 6-chains get their own account, 7-chains get their own account, etc. pp. <-- this will get you a divisor of 1 for every submitted chain-length :-\
-
...
ok, here's my (last?) attempt to convince you: ;)
let's say you have 2 miners:
a) one mining 1000 chains per payout-interval (whatever that means (1hour, 1block...))
b) one mining 1 chain per payout-interval
you'll agree, that both will have the same distribution of 'shares per chain-length' (in a ideal world): let's say
{ 6 = 900, 7 = 90, 8 = 9, 9 = 1 }
the only difference:
a needs 1 payout-interval, b needs 1000 payout-intervals!
with your normalization:
b will get 4x the payout of a for the same work !
(because b sumbits only 1 share per payout-calculation, thus his divisor will be always 1, while a will submit everything and gets a divisor of 4)
Nop. While b submitts any 9-chain with that distribution, both miners submitts chains of the four types: "6", "7", "8" and "9". So both will have 4 weighted values summed and divided by 4.
The maximum unit of time for which b submits only chains of type "6" is when his expected "7" chains are less than 0.5, thus rounded to 0, as well as the "8" and "9" chains. In that case the submitted chains would be:
- submitted by a: { "6" = 5000, "7" = 500, "8" = 50, "9" = 5 }
- submitted by b: { "6" = 5 } , chains longer than 6 are rounded to 0, as chain count must be integer
Simplifying the weighting model with the following weights: 6 = 0.01 XPM, 7 = 0.1 XPM, 8 = 1 XPM , 9 = 10 XPM, your straigth application of values will be:
- payout for a: (0.01*5000) + (0.1*500) + (1*50) + (10*5) = 50 + 50 + 50 + 50 = 200
- payout for b: (0.01*5) = 0.05
So, your computed payouts will result in a = 4000 * b.
Instead, averaging will result in a = 200/4 = 50, as he submitted the 4 types of chains, and b = 0.05/1. So a = 1000 * b, as it shoud be.
- read my post again!
/edit:
i will simplify my example:
expected distribution (in a perferct world):
{ 6 = 9, 7 = 1 }
values:
{ 6 = 0.1 XPM, 7 = 1.0 XPM }
miner 1: 10 submissions (# 6-chains, # 7-chains)
(9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) = (90,10) = 19 XPM / 2 = 8 XPM (0.8 XPM per payout-calculation on average @ 10x computing power)
miner 2: 10 submissions
(1,0) (1,0) (1,0) (1,0) (0,1) (1,0) (1,0) (1,0) (1,0) (1,0) = (9,1) = 1.9 / 1 = 1.9 XPM (0.19 XPM per payout-calculation on average)
(of course, the normalization takes place at every submission (which should simulate the payout calculation here); i simplified that by calculating the normalization only at the sum of all submissions)
(and yes: miner 1 will not always submit (9,1)s, there could be some (10,0)s and some (8,2)s, but that's not the issue here!!)
(and yes: miner 2 will not always submit (1,0)s & one (0,1), there could be some (2,0)s, some (0,0) and probably a (1,1)s, but that's not the issue here either!!!)
miner 2 is doing 1/10th of the work of miner 1, right?
his submissions are worth ~2x of the submission of miner 1!
your normalization is faulty!
THIS IS AN (EXTREME (read: unlikely)) EXAMPLE, BUT IT WILL SHOW YOU THE FLAW/MISTAKE OF YOUR NORMALIZATION!!
- xolokram
ps. thank you for ignoring my cheat instruction
-
read my post again!
/edit:
i will simplify my example:
expected distribution (in a perferct world):
{ 6 = 9, 7 = 1 }
values:
{ 6 = 0.1 XPM, 7 = 1.0 XPM }
miner 1: 10 submissions (# 6-chains, # 7-chains)
(9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) = (90,10) = 19 XPM / 2 = 8 XPM (0.8 XPM per payout-calculation on average @ 10x computing power)
miner 2: 10 submissions
(1,0) (1,0) (1,0) (1,0) (0,1) (1,0) (1,0) (1,0) (1,0) (1,0) = (9,1) = 1.9 / 1 = 1.9 XPM (0.19 XPM per payout-calculation on average)
(of course, the normalization takes place at every submission (which should simulate the payout calculation here); i simplified that by calculating the normalization only at the sum of all submissions)
(and yes: miner 1 will not always submit (9,1)s, there could be some (10,0)s and some (8,2)s, but that's not the issue here!!)
(and yes: miner 2 will not always submit (1,0)s & one (0,1), there could be some (2,0)s, some (0,0) and probably a (1,1)s, but that's not the issue here either!!!)
miner 2 is doing 1/10th of the work of miner 1, right?
his submissions are worth ~2x of the submission of miner 1!
your normalization is faulty!
THIS IS AN (EXTREME (read: unlikely)) EXAMPLE, BUT IT WILL SHOW YOU THE FLAW/MISTAKE OF YOUR NORMALIZATION!!
- xolokram
ps. thank you for ignoring my cheat instruction
dont know why you bother hes not in 1 or 2 or 3 so why is he bashing your pool so far i have been getting more then waht i got at ypool and the miner dose not disconnect from pool so in all +10
- As I see it xolokram is right. If a small miner is mining long enough he will get his proportional share of #8 and #9 chains and he will get a fair pay. The problem is that the small miner will get more irregular payments, because he will receive less than he deserves while he is finding only #6 chains and will compensate when he finds the big ones. So we are increasing variance for small miners and they will depend more on good luck, wich is just the opposite of what pools are cretaed for.
-
expected distribution (in a perferct world):
{ 6 = 9, 7 = 1 }
values:
{ 6 = 0.1 XPM, 7 = 1.0 XPM }
miner 1: 10 submissions (# 6-chains, # 7-chains)
(9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) (9,1) = (90,10) = 19 XPM / 2 = 8 XPM (0.8 XPM per payout-calculation on average @ 10x computing power)
miner 2: 10 submissions
(1,0) (1,0) (1,0) (1,0) (0,1) (1,0) (1,0) (1,0) (1,0) (1,0) = (9,1) = 1.9 / 1 = 1.9 XPM (0.19 XPM per payout-calculation on average)
...
miner 2 is doing 1/10th of the work of miner 1, right?
Not right, (0,1) in miner 2 is more or less as much probable as (1,9) in miner 1, which is not there.
his submissions are worth ~2x of the submission of miner 1!
No, 9 submissions are worth about 1x of the submission of miner 1, and one very unlikely submission is worth about 10x them.
your normalization is faulty!
THIS IS AN (EXTREME (read: unlikely)) EXAMPLE, BUT IT WILL SHOW YOU THE FLAW/MISTAKE OF YOUR NORMALIZATION!!
If you justify a system of valuation on EXTREME unlikely EXAMPLES, you can justify any thing you want. But you are the owner of the pool, you don't need to justify anything :D
As I see it xolokram is right. If a small miner is mining long enough he will get his proportional share of #8 and #9 chains and he will get a fair pay. The problem is that the small miner will get more irregular payments, because he will receive less than he deserves while he is finding only #6 chains and will compensate when he finds the big ones. So we are increasing variance for small miners and they will depend more on good luck, wich is just the opposite of what pools are cretaed for.
That could be solved counting #5 chains also. A minimum accepted length of 6 is too high to have enough good statistics for most of the workers, so the problem of high variance for small miners will be the same with any valuation system. But worst when summing #8 and #9 than when averaging, the opposite that you say.
- you obviously don't read carefully enough. i give up. i'm not implementing your "normalization", because of it's wrong behaviour.
- xolokram
-
you obviously don't read carefully enough. i give up. i'm not implementing your "normalization", because of it's wrong behaviour.
- xolokram
I told you he was hopeless the dumbass doesn't know math or how to read.
Looking forward to our new awesome payout system and client.
-
I told you he was hopeless the dumbass doesn't know math or how to read.
Looking forward to our new awesome payout system and client.
... awesome ...
+10
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i think it was changed to 3.1, however, could it be changed one more time, this time to 3.14159265359 ?
-
xolo one question how long dose it take until i start seeing the xpm going in to my wallet
You have to reach the payout of 3 XPM first (or 3.1?) check my sig for stats...
i think it was changed to 3.1, however, could it be changed one more time, this time to 3.14159265359 ?
LOL
- is the pool down i can access put my miners still connect
- the web frontend crashed, i'll investigate that asap, but i'm currently busy --- i'll report back.
actual mining pool, blocks & payouts are save. no panic.
- xolokram
ps. i restarted the web frontend, but as i've not checked what happened i guess it'll crash again
pps. i changed some minor stats & info parts in the frontend yesterday night, i guess i should've tested it more ;)
ppps. Sy's stats depend on the web frontend, that's why his stats where not updated too
pppps. ~55 blocks in the last ~12 hours
- cool thanks im adding 250 more cores more today i was too lazy yerterday
- ok, i fixed the web interface bug. i'm currently not really in the mood to code; i'll implement the CPPSRB payout system tomorrow or maybe on monday --- we'll see...
- xolokram
ps. thanks to MJ2P for the donation!
-
hey xolo could I get a breakdown of what I see here
{
"payout_pps": 0.0009044449633379715,
"payout_pps_pato": 0.000342874577516,
"shares": 30030,
"blocknum": 733,
"details": {
"6": 0.9094905094905095,
"7": 0.08171828171828172,
"8": 0.008191808191808193,
"9": 0.0005994005994005994
}
}
{
"6": 13,
"7": 1
}
I am kinda confused on the value of things why are 6 worth the most???
Or is that a percentile breakdown?
-
hey xolo could I get a breakdown of what I see here
{
"payout_pps": 0.0009044449633379715,
"payout_pps_pato": 0.000342874577516,
"shares": 30030,
"blocknum": 733,
"details": {
"6": 0.9094905094905095,
"7": 0.08171828171828172,
"8": 0.008191808191808193,
"9": 0.0005994005994005994
}
}
{
"6": 13,
"7": 1
}
I am kinda confused on the value of things why are 6 worth the most???
Or is that a percentile breakdown?
Yes my stats are very simular, confused too :D
- The sum of those four numbers is 1, so I guess it's the proportion of each one you have submitted. I would like to know what "payout_pps" and "payout_pps_pato" mean.
- hi
these are stats over all blocks found so far.
"payout_pps": average payout PER SHARE (CPPSRB)
"payout_pps_pato": average payout PER SHARE (CPPSRB + patapato's 'normalization')
"shares": how many shares you've submitted
"blocks": how many blocks you've submitted shares (former "blocknum")
"details": what Urakhga said (chain length distribution)
@payout_pps(_pato):
not the actual values are important, it's the comparison to other users!!
a) patapato's version has a higher deviation overall
b) patapato's version prefers slower miners (= the average of payout per share is higher for slow miners)
both issues are bad. i added this information because patapato had problems with my abstract example to see what's wrong with his method. these are the real values and they show exactly what i was talking about in my previous posts. but i guess, he's still not convincible.
@xeroc:
don't expect too much too happen. it will still be a mining pool for primecoin and users will get paid for their work (generally speaking). v0.4 of the miner software will mostly add features for the communication protocol, so it will not be 1000% faster or whatever you might think of :).
@irritant:
it's currently at 3.01
Why not 9.80665?
- xolokram
ps. the current (average of all users') distribution of chain-lengths is: 6=90.87% , 7=8.36% , 8=0.69% , 9=0.045% --- just fyi
- How goes implementing the new payout system? I can't imagine that it is super easy given that you either need to choose between tracking the times that each share is submitted or figuring out some way of shelving shares fairly, I guess you could go with an equal percentage that gets shelved for everyone but then again the point is that if you submitted early in a round you are supposed to be payed out first which helps to encourage larger miners without harming smaller ones. Also I suggest that at some point when you end up with a large amount of matured primecoins due to good luck you use this to start allowing earlier withdraw times IE you give us matured coins in exchange for our immature coins obviously you would want to charge some sort of fee for people being hasty but still would be nice to have that as a feature.
-
calculating the payout for submitted shares is done (as you can already see in your user live stats; these are just dry-run values)
the part that's missing right now is "shelving" shares.
[...]if you submitted early in a round you are supposed to be payed out first[...]
maybe i'm misinterpreting your sentence, but CPPSRB works like a stack using last-in-first-out. most recent (shelved) shares are paid first (not early shares). see CPPSRB (http://eligius.st/wiki/index.php/Capped_PPS_with_Recent_Backpay)
anyway. i have to save these shares somehow on long rounds, including information about the payout-per-share (XPM per 6-chain, 7-chains, etc.), because i expect that to change within the first days.
also: there are 2-5 users who clearly optimized their miners to submit mostly 6-chains. i'm thinking about punishing them...
(there are actually more users optimizing towards smaller chains; but these few guys are the most greedy)
- xolokram
ps. there will be a short down time, i will shut down the 'getwork' protocol, thus jhPrimeminer is NOT usable any longer (soon)
pps. time to say goodbye, 'getwork' protocol shut down, jhPrimeminer users: please switch to my miner v0.3 (or higher in near future)
reminder for myself:
T4=0.9627728539038969 0.03531891410296474 0.0018683386413654165 0.000039893351772927044
y4=0.9389742360253029 0.059015546908138615 0.00197333234974088 0.00003688471681758663
1R=0.9380210134070915 0.05914102416349737 0.0027371211248127234 0.00010084130459836349
-
also: there are 2-5 users who clearly optimized their miners to submit mostly 6-chains. i'm thinking about punishing them...
(there are actually more users optimizing towards smaller chains; but these few guys are the most greedy)
It's better to device a system so that the cheaters are automatically punished according to how much they stray away from a standard distribution by having too many small chains, and automatically rewarded by having "too many" short chains. To reduce variance, statistics should be calculated based on all shares from the same address since last payment. Suppose we increasing minimum payment to N times the current block size to reduce variance. if N=1, everyone who should get paid should on average have a certain number of long chains. For example if the diff=9.5, then in order to get 11 XPM (999/9,5^2) everyone should have on average at least 5 9chains, ~50 8chains, ~500 7chains, ~5000 6chains (let's call this the share-length data set). To reduce statistical fluctuation, larger N can be used. With enough data points, do a linear fit in log-normal space of the share-length data set, weighted by Poisson uncertainty of each length. The user's pay is adjusted according to how much the fitted slope deviates from the standard. It important to reward users who send in "too many" short chains so that in the long term, fluctuations even out. You can fine tune the "standard slope" and the punish factor with exsiting data.
This may sound complicated. Hope the idea is useful food for thought.
- thank you for the pool xolokram. i started to get my first payments and it feels great not to check every day for disconnected miners have more free time to add cores i have around 900 right now and will keep adding hop that more people see that this is a great pool and start joining
-
also: there are 2-5 users who clearly optimized their miners to submit mostly 6-chains. i'm thinking about punishing them...
(there are actually more users optimizing towards smaller chains; but these few guys are the most greedy)
Now it is clear why we have so many new connections and the avg time to find a block increased at some point >:(
- some small announcements:
1) GETWORK PROTOCOL'S DEAD
i shut down the getwork protocol ports (namely port 9912 and 9999)
because most of the jhPrimeminer users optimized their miners for 6-chains, the chain length distribution was terrible
thus jhPrimeminer is not usable any longer now
(maybe there will be a comeback using xpt protocol, but currently we don't really need that)
2) TO THE FOLLOWING THREE ADDRESSES:
AK9QEdHVF8Axs5ZDcBdWrcPhVN9R4MiQT4
AaJZ5zHk2TaSeCLZP12xSbA7KDvQRxrxy4
ALMFFej6CExPMuTxuLensw2jwV53cKiC1R
you have 5 days to change your mining settings and improve your chain-length-ratio!!
otherwise i will add all your personal pending payouts to the community
NO negotiations.
3) MINER CLIENT v0.4 IS HERE:
i added some protocol features and two more parameters
a) use: -minerid=<value between 0 - 65000>
with this you can identify specific miners in your personal stats (SOON - WAIT FOR THE SERVER-SIDE UPDATE)
b) use: -poolfee=<value between 1 - 100>
with this you can specify your fee (%) you want to give to the pool (SOON - WAIT FOR THE SERVER-SIDE UPDATE)
adjustable per miner (default: 2), if you use an older client (v0.2 & v0.3) the fee is set to 5%, update!!
CLARIFICATION: THIS IS NOT FULLY IMPLEMENTED ON SERVER-SIDE YET, THE CURRENT FEE IS STILL 1% :)
you can configure your clients now/asap with v0.4; i will announce when the new fee system is online (NOW + X DAYS | X >= 2))
linux: source @ bitbucket (https://bitbucket.org/thbaumbach/primecoin-hp) / source @ github (https://github.com/thbaumbach/primecoin) (see OP for more information)
windows binary: primeminer v0.4 RC1 (http://www.mediafire.com/download/ho8qwpm8xtmb53t/primeminer_v04_x86_and_x64.zip) (contains 32 and 64 bit version)
mac user: see this post (http://ppcointalk.org/index.php?topic=501.msg4037#msg4037) for more information
usage:
primeminer -pooluser=[xpm-payout-address] -poolip=beeeeer.org -poolport=1337 -genproclimit=[threads-to-use]
optional: -minerid=[0 - 65000] -poolfee=[1 - 100 (in %)]
4) CPPSRB PAYOUT SYSTEM WILL COME TOMORROW WEDNESDAY
expect some downtime
expect some bugs
expect the worst, hope the best, we'll meet in the middle
i should add this again... :)
for technical issues/questions: please use this thread (http://ppcointalk.org/index.php?topic=501.0)
this thread here is proposed for general discussion
that's all --- glhf
- xolokram
ps. block 1000+ and <600 seconds per block *woohoo*
pps. time to open a beer
- Thanks for the continued hard work xolokram,
v0.4 is now updated on my miners and is working well. looking forward to seeing the stats changes too.
- These are the moments when I love "git pull" and "puppet"!!!
pd: Xolo, you'r the boss here, but I REALLY, REALLY would like to thank Sy's for his stats webpage, +1
- Amazing stuff!
Compiling 0.4 now...love this pool man. 8)
-
windows binary: primeminer v0.4 RC1 (http://www.mediafire.com/download/ho8qwpm8xtmb53t/primeminer_v04_x86_and_x64.zip) (contains 32 and 64 bit version)
Seems to be down. Isn't it?
- yeah, looks like mediafire is down completely. wow. i will add a mirror later today, i'm currently not on a PC where i have the binaries stored.
@pt0x:
you can thank him via donation if you like. ::)
- xolokram
-
yeah, looks like mediafire is down completely. wow. i will add a mirror later today, i'm currently not on a PC where i have the binaries stored.
It's online again
- Did someone say Mirror?
http://xpm.mj2p.co.uk/primeminer_v04_x86_and_x64.zip (http://xpm.mj2p.co.uk/primeminer_v04_x86_and_x64.zip)
- There's a problem starting with block 178396. Reward appears as 100*block value. I don't think the pool can afford to pay all of us 100 times what the pool gets.
- yeah, thank you. i'm currently working on the payout system, the factor of 100 was a mistake. no payouts were harmed; i guess you all would've loved the 1000 xpms per block ;) i'm fixing this asap
i don't know how Sy handles this, but i guess his stats are now screwed :) he has to fix this too.
@MUTO:
thanks for the info
- xolokram
-
yeah, thank you. i'm currently working on the payout system, the factor of 100 was a mistake. no payouts were harmed; i guess you all would've loved the 1000 xpms per block ;) i'm fixing this asap
i don't know how Sy handles this, but i guess his stats are now screwed :) he has to fix this too.
@MUTO:
thanks for the info
- xolokram
That's why my USD suddenly jumped xD
Block 178415, 178398 and 178396 are still incorrect, reward is okay but every user payout is wrong...divide by 100?
-
Did someone say Mirror?
http://xpm.mj2p.co.uk/primeminer_v04_x86_and_x64.zip (http://xpm.mj2p.co.uk/primeminer_v04_x86_and_x64.zip)
Seems to be legit, thanks :)
https://www.virustotal.com/de/file/f4bfa8e076161d71da198cf42b43fd89382fcb07bb82b18797bc783db8d4555c/analysis/
-
Seems to be legit, thanks :)
https://www.virustotal.com/de/file/f4bfa8e076161d71da198cf42b43fd89382fcb07bb82b18797bc783db8d4555c/analysis/
;D. Always worth checking.
It has been touched once when I unzipped it last night. Apart from that it is as pure as they come.
-
Block 178415, 178398 and 178396 are still incorrect, reward is okay but every user payout is wrong...divide by 100?
fixed
-
Block 178415, 178398 and 178396 are still incorrect, reward is okay but every user payout is wrong...divide by 100?
fixed
Same, all good again :)
- Now comission charged from found blocks.
How will it work with the new parameters miner v04? It is not clear how it will work even on a separate account.
One account, for example:
5 miners give a pool of 5%
2 miner is given a pool of 3%
10 miners give 1% of the pool
How all this will be calculated and reflected in the statistics?
- stupid bug crashed the web frontend >:(
since you will be paid per share (read: every share has a specific value in XPM)
i can charge a fee on every submitted share.
or for simplification: i can charge a fee for every submitted work of every miner seperately.
it's currently not part of the statistics
/edit:
Ok, so implementing the core features of CPPSRB is pretty easy.
the 'problem' is, to give you an easy interface to see what happens (how many shares you've submitted, worth of those shares, shares in the queue (pending) and paid shares)
and i'm sure, that i'll break Sy's stats (sorry in advance)
because the current system (e.g. payouts calculated block-wise) is not suited for cppsrb
so CPPSRB? wednesday! :-\
- xolokram
ps. yup, currently there's no fee at all, because of the ongoing maintenance
- Hello,
I had tested primemeter V2 vs primemeter V4 and V2 is much faster
on version V4 I'm getting on intel xeon E5606 @ 2.13 on 2 cores
1466671 prime/h 22017883 test/h 0 5-chains/h 0.252724 chain/d
on version V2 I'm getting on intel xeon E5606 @ 2.13 on 2 cores
1943713 prime/h 46615941 test/h 180 5-chainsh 0.524171 chain/d
Is the slowness done with purpose on new version where user can determinate pool share? Can this been improve?
Regards
- hi
v4 (& v3) is based on mikaelh's hp11 client, thus it uses the new default mining settings which 'prefer' longer prime-chains instead of short ones. that's why it produces less chains overall on the same hardware as v2. the pool is transitioning (hopefully everything will be running by tomorrow evening) to the cppsrb payout system and will reward longer chains.
mining parameter: (and default values)
-sieveextensions=9
-sievepercentage=10
-sievesize=1000000
- xolokram
reminder from this post (http://ppcointalk.org/index.php?topic=485.msg4148#msg4148) for everyone:
ok, so implementing the core features of cppsrb is pretty easy.
the 'problem' is, to give you an easy interface to see what happens (how many shares you've submitted, worth of those shares, shares in the queue (pending) and paid shares)
and i'm sure, that i'll break Sy's stats (sorry in advance) because the current system (e.g. payouts calculated block-wise) is not suited for cppsrb
so cppsrb? wednesday! :-\ i'm too busy to get other s*** done today
ps. good job (http://www.beeeeer.org/block/179152)
-
reminder from this post (http://ppcointalk.org/index.php?topic=485.msg4148#msg4148) for everyone:
ok, so implementing the core features of cppsrb is pretty easy.
the 'problem' is, to give you an easy interface to see what happens (how many shares you've submitted, worth of those shares, shares in the queue (pending) and paid shares)
and i'm sure, that i'll break Sy's stats (sorry in advance) because the current system (e.g. payouts calculated block-wise) is not suited for cppsrb
so cppsrb? wednesday! :-\ i'm too busy to get other s*** done today
ps. good job (http://www.beeeeer.org/block/179152)
Haha okay, i'll see what i can make out of your new data once it's there (little heads up via pm maybe? 8) )
PS too bad i didnt submit a lucky share for that block ;D
- ok, i'll PM you
/edit1:
POOL MAINTENANCE - DONT PANIC
let's all hope i don't f*** s*** up :o
/edit2:
SOON :D
/edit3:
done.
- Gosh nearly 5000 workers Ypools dominence will end soon!
-
Gosh nearly 5000 workers Ypools dominence will end soon!
OMG update nearly 6000 now!!!
-
...and i'm pretty surprised that the server seems to run smooth - no big performance issues right now.
btw. an update takes ~500 ms to send to all ~5500 workers
(i have some ideas to optimize that further, but that's rather low priority right now)
i will try to launch the CPPSRB payout system tomorrow (yeah i know... how many times did i say that now?)
i had too much to do the last days, i hope i'll have some time then
Gosh nearly 5000 workers Ypools dominence will end soon!
i wouldn't say that; ypool's overall stats seem to be not effected by beeeeeeeeeer
- xolokram
- Fug ypool...xD
- At 00.14 GMT beeeeer took ypools crown as the top primecoin site!!!
- Never liked ypool anyways. Now that the multiminer argument is going to be added I might throw together a GUI tool for this over a weekend. Just plug in your address and hit go. Any idea what I should call it?
-
Never liked ypool anyways. Now that the multiminer argument is going to be added I might throw together a GUI tool for this over a weekend. Just plug in your address and hit go. Any idea what I should call it?
Multiminer??
-
Never liked ypool anyways. Now that the multiminer argument is going to be added I might throw together a GUI tool for this over a weekend. Just plug in your address and hit go. Any idea what I should call it?
Multiminer??
I think he means having multiple workers under one address.
Also a GUI would be lovely.
-
POOL MAINTENANCE #1 - DONT PANIC ... DONE
POOL MAINTENANCE #2 - DONT PANIC ... SOON
@theprofileth:
maybe i'm misinterpreting your sentence, but CPPSRB works like a stack using last-in-first-out. most recent (shelved) shares are paid first (not early shares). see CPPSRB (http://eligius.st/wiki/index.php/Capped_PPS_with_Recent_Backpay)
of course the payout queue is paid first-in-first-out (the oldest submitting users get paid first)
it's just the most recent block reward that will payout the shares in last-in-first-out order
-
@theprofileth:
maybe i'm misinterpreting your sentence, but CPPSRB works like a stack using last-in-first-out. most recent (shelved) shares are paid first (not early shares). see CPPSRB (http://eligius.st/wiki/index.php/Capped_PPS_with_Recent_Backpay)
of course the payout queue is paid first-in-first-out (the oldest submitting users get paid first)
it's just the most recent block reward that will payout the shares in last-in-first-out order
Yes this is correct :D
- Hello :) is the reward system for primeminer v.4 longer chains active, ?
-
Hello :) is the reward system for primeminer v.4 longer chains active, ?
No not yet Xolokram will implement it soon!
-
No not yet Xolokram will implement it soon!
yup
please indulge me: this week is exhausting. i didn't had the time for the progress i hoped for (...and promised) on the project. some parts are still missing / are untested (regarding cppsrb).
and it looks like the weekend won't get any better. anyway; i plan to finish, test & release cppsrb for the beginning of next week.
- xolokram
-
No not yet Xolokram will implement it soon!
yup
please indulge me: this week is exhausting. i didn't had the time for the progress i hoped for (...and promised) on the project. some parts are still missing / are untested (regarding cppsrb).
and it looks like the weekend won't get any better. anyway; i plan to finish, test & release cppsrb for the beginning of next week.
- xolokram
Don`t worry about it :)
- After mining for over an hour still my stats are empty:
Still the mining gives no errors:
Probable prime chain found for block=54d118a22b589115e7d705571de94ac8b2ebd98ebbb9acd97a30d6b0f314a61a!!
Target: 09.dbd70c
Chain: TWN07.309e0d
[MASTER] submitted share -> SHARE
Probable prime chain found for block=893eab26bb660b2cd204a51fc566ee41cca634387e231a180f0fe001f5a0ac2d!!
Target: 09.dbd70c
Chain: TWN06.cf3645
[MASTER] submitted share -> SHARE
How can I see that I am actually submitting shares ???
EDIT: stats are updated. I was too impatience :-)
:-) :-)
- Second question: Can I use my old X6500 FPGA for mining :-) This one I have used in the past for bitcoin mining?
-
Second question: Can I use my old X6500 FPGA for mining :-) This one I have used in the past for bitcoin mining?
Sorry no FPGA's are onlt for SHA256 coins consider using it for peercoin mining!
- did the new payout system working now my winnings went all the way down >:(
-
did the new payout system working now my winnings went all the way down >:(
Since you have a lot of computation power you might consider soloing. For a public pool, using a rewarding policy good for big miners automatically means the informed small miners (and there are thousands of them) are unhappy.
-
@elvisrene:
2) TO THE FOLLOWING THREE ADDRESSES:
AK9QEdHVF8Axs5ZDcBdWrcPhVN9R4MiQT4
AaJZ5zHk2TaSeCLZP12xSbA7KDvQRxrxy4
ALMFFej6CExPMuTxuLensw2jwV53cKiC1R
you have 5 days to change your mining settings and improve your chain-length-ratio!!
otherwise i will add all your personal pending payouts to the community
NO negotiations.
if you're one of those 3 guys: wait a few hours, i will check the stats later today and will payout if there's a improvement. their current payouts are on halt right now, check the payout info.
if you're not one of those 3 guys: nothing has changed yet (regarding the payout system), everything is working on the pool's side. maybe some more details about your problem and i can help you?!
/edit:
ok, so it looks like
AK9QEdHVF8Axs5ZDcBdWrcPhVN9R4MiQT4 and ALMFFej6CExPMuTxuLensw2jwV53cKiC1R
were able to improve their submitted shares. good job and thank you. their payout is no longer on halt and will be part of the next payout batches.
while AaJZ5zHk2TaSeCLZP12xSbA7KDvQRxrxy4 abandoned the pool (?), his payout will be donated to the whole community within the next payouts soon --- his (her?) chain-length stats are still messed up.
@anonymous:
PN3XPC37HFqnGd8Xggb3pUnK4ZNWSkQdNY is not a valid primecoin address!! :)
please change that ASAP
@mykel:
like roger said, no FPGAs (yet?)
+
the stats update on web interface has a delay of ~60 seconds and if the pool finds a block and you've a bad timing your stats will be reset :) just check the block information page
- xolokram
- I can't wait for the Monday update ;)
Also a precaution, if you want to use a modifier for the payout be warned against making it scale with pool reserves as it seems nice to give back to the everyone when we are doing well but if we are doing poorly it means we are getting payed less even though it should essentially even out it encourages people to mine when the payout is higher ie when the pool is getting lucky and switch when the pool is doing poorly.
- pool maintenance
(this will take a little bit longer)
- xolokram
ps. PN3XPC37HFqnGd8Xggb3pUnK4ZNWSkQdNY (& other invalid primecoind addresses) will be blocked/ignored now
-
I can't wait for the Monday update ;)
Also a precaution, if you want to use a modifier for the payout be warned against making it scale with pool reserves as it seems nice to give back to the everyone when we are doing well but if we are doing poorly it means we are getting payed less even though it should essentially even out it encourages people to mine when the payout is higher ie when the pool is getting lucky and switch when the pool is doing poorly.
I wouldn't switch, switch to what btw? qrk?
Looking forward to the update as well :D
- switch to cppsrb (http://eligius.st/~gateway/faq/capped-pps-recent-backpay) payout system.
-
switch to cppsrb (http://eligius.st/~gateway/faq/capped-pps-recent-backpay) payout system.
Is there a page where we can see some stats on how the payout system is working? Maybe like how the pool is doing (ahead or behind), by how much and/or how many shelved shares a given address has, etc.
Thanks in advance.
- yup there is, but since cppsrb is not fully active right now the stats are only 'simulated' on some arbitrary test settings (regarding value per share etc.pp.). check PM.
- xolokram
- Ok now the /user page is just confusing.
- actually it's just the old page + additional information
try to :) ignore the last part while cppsrb is under construction
-
Since you have a lot of computation power you might consider soloing. For a public pool, using a rewarding policy good for big miners automatically means the informed small miners (and there are thousands of them) are unhappy.
What is considered a "big miner" or a "small miner" (I have 14 4 core PCs), and why is soloing better for "big miners", other than avoiding the pool fees? As far as I can see the math works out the same, the pool simply evens out the variance. am I missing something?
I started solo mining Primecoin on a single PC a week ago, and in the first few hours I found a block, and got 10.26; I have found nothing since. I am sure sooner or later I would, but with the pool I would get 3 or so payouts of 3+ in about the same time, for about the same amount total. If I threw in another 10 PCs like the first I would find blocks on average 10 times faster, but would I not find shares 10 times faster as well, in both cases generating 10 times the Primecoin?
I started pool mining here this morning, to see how it goes. Reading the posts it seems there is a lot going on so this might not be the best time to test it out, but such is life. I admit I can't make much sense out of the user stats page, but I gather it is changing anyway. It is showing me 220 shares and "payout_current": 0.0010818713074041875 since this morning so I assume that means I am mining and banking a bit of dust...
-
Since you have a lot of computation power you might consider soloing. For a public pool, using a rewarding policy good for big miners automatically means the informed small miners (and there are thousands of them) are unhappy.
What is considered a "big miner" or a "small miner" (I have 14 4 core PCs), and why is soloing better for "big miners", other than avoiding the pool fees? As far as I can see the math works out the same, the pool simply evens out the variance. am I missing something?
I started solo mining Primecoin on a single PC a week ago, and in the first few hours I found a block, and got 10.26; I have found nothing since. I am sure sooner or later I would, but with the pool I would get 3 or so payouts of 3+ in about the same time, for about the same amount total. If I threw in another 10 PCs like the first I would find blocks on average 10 times faster, but would I not find shares 10 times faster as well, in both cases generating 10 times the Primecoin?
I started pool mining here this morning, to see how it goes. Reading the posts it seems there is a lot going on so this might not be the best time to test it out, but such is life. I admit I can't make much sense out of the user stats page, but I gather it is changing anyway. It is showing me 220 shares and "payout_current": 0.0010818713074041875 since this morning so I assume that means I am mining and banking a bit of dust...
Icedaddy if you want to see how well your mining on beeeeer is go here http://xpm.syware.de/?address=*your XPM address*
lots of info!
- BTW beeeeers overtaken ypool again not sure for how long though this time
- Nice to hear you are making progress Xolo, also I really hope we get a global stats page for each user from all this as it looks like you have the capabilities to do it from all the excess info on the current user pages. By global stats I mean like total x chain length submitted average chain length, value per 24 hour cycle, estimated primecoins per day ect.
-
Since you have a lot of computation power you might consider soloing. For a public pool, using a rewarding policy good for big miners automatically means the informed small miners (and there are thousands of them) are unhappy.
What is considered a "big miner" or a "small miner" (I have 14 4 core PCs), and why is soloing better for "big miners", other than avoiding the pool fees? As far as I can see the math works out the same, the pool simply evens out the variance. am I missing something?
The difference is mainly in variance. If you have only a few computers it can take weeks before a block shows up. Once I ran with wrong parameters for a week before I found out accidentally. With a solo miner that we currently have, there are not many statistics (e.g. 6ch/h, 7ch/h ...) to show the health of the miner. So with a solo miner silently running days after days without producing anything, you might wonder if everything is OK. With a pool you can see your progress of evert miner all the time.
Also a pool can have bugs or may or may not have a reward policy to your advantage. It's another uncertainty.
-
Icedaddy if you want to see how well your mining on beeeeer is go here http://xpm.syware.de/?address=*your XPM address*
lots of info!
I saw that utility in another thread and tried it, and as you say lots of good info. I am just going to let it run for a few days and see what comes of it...
-
The difference is mainly in variance. If you have only a few computers it can take weeks before a block shows up. Once I ran with wrong parameters for a week before I found out accidentally. With a solo miner that we currently have, there are not many statistics (e.g. 6ch/h, 7ch/h ...) to show the health of the miner. So with a solo miner silently running days after days without producing anything, you might wonder if everything is OK. With a pool you can see your progress of evert miner all the time.
Also a pool can have bugs or may or may not have a reward policy to your advantage. It's another uncertainty.
Very true and very important. Since I am mining for fun and not to make a fortune seeing things happening is part of the fun.
I have been looking into the new reward policy but have not come to any conclusions about it being an advantage or disadvantage to me. I gather it is nearly done so I will stick around and see how well it works for me. If I don't like it I will move on to another coin...
-
I have been looking into the new reward policy but have not come to any conclusions about it being an advantage or disadvantage to me. I gather it is nearly done so I will stick around and see how well it works for me. If I don't like it I will move on to another coin...
If you're a honest miner, there's no big difference for you personally with cppsrb. it's not that your payout will double or whatever.
with the coming cppsrb payout system, the main advantage is, that cheating clients (tweaking the software to produce mainly 6-chains) will not be "rewarded" any longer.
thus it will help the community & pool to stay healthy.
plus you can predict what your reward will be due to PPS.
"payout_current", "payout_pps" & "payout_pps_pato" are your (calculated) reward per share you've submitted (current system, cppsrb system, cppsrb+pato system).
- xolokram
-
actually it's just the old page + additional information
try to :) ignore the last part while cppsrb is under construction
OMG so much infos! *nom nom nom* ;D
By the way is the payout treshold still 3.0 or did it chane to 3.1? I think i've read something somewhere in this thread...
-
If you're a honest miner, there's no big difference for you personally with cppsrb. it's not that your payout will double or whatever.
with the coming cppsrb payout system, the main advantage is, that cheating clients (tweaking the software to produce mainly 6-chains) will not be "rewarded" any longer.
thus it will help the community & pool to stay healthy.
plus you can predict what your reward will be due to PPS.
"payout_current", "payout_pps" & "payout_pps_pato" are your (calculated) reward per share you've submitted (current system, cppsrb system, cppsrb+pato system).
- xolokram
I guess I must be an "honest miner" as I don't have the skill set to tweak anything; I just use the stock V4 miner as advised, out of the box.
I admit a bit of skepticism. I was once told that I would not see any difference between PPS and PPLNS, but reality painted a very different picture. From what I can tell researching cppsrb (I had not encountered it before) it appears to be nothing more than a way to mitigate the risk of the pool operator by deferring payments in lean times until better times roll around, and I can certainly support that. However based on my research I cannot see how cppsrb by itself would have anything to do with chain length so I must assume that more than just implementing cppsrb is going on; some sort of change to the pool methodology. I hope it achieves the goal as indicated. Of the dozen or so coins I have tried or researched Primecoin appears to be the best for me, but pool options are rather limited; if I had the skill set I would run my own proportional pool, but alas I don't.
- @Sy:
it's set to 3.01 (3.0 + 0.01 primecoin transaction fee)
the new info on the user page is the sharelog as used by the cppsrb
i don't know if that helps, i'll let you know when everything is setup and will explain to you what everything means; so you can build the eye candy for the cancer i call web-frontend ;)
@icedaddy:
yeah, cppsrb is just a modification to pps-based payout systems.
just compare "payout_current" (the current (kind-of-proportional) reward system) to "payout_pps" (simulated cppsrb) and check if there is a significant difference.
i dont know if you want this to know: chain-lengths are only a part of the concept of primecoins, you'll not see this in other cryptocoins (atm). these are the shares the miners submit to the pool to get their reward. unfortunately you can tweak your software to generate more shorter (actually useless) chains. currently the pool doesn't care about chain lengths, but this will change to prevent people from tweaking their miners for shorter chains.
ypool uses different rewards per chain-length too, but they have a proportional payout scheme. rpool... uhm yeah... i actually dont have a clue how rpool's payout works, too much asian symbols on their website, but their reward system is also based on the chain length and proportional per block i think, looks like they make some similiar mistakes like i did ... they'll learn! :o :D
- xolokram :-X
-
@icedaddy:
yeah, cppsrb is just a modification to pps-based payout systems.
just compare "payout_current" (the current (kind-of-proportional) reward system) to "payout_pps" (simulated cppsrb) and check if there is a significant difference.
i dont know if you want this to know: chain-lengths are only a part of the concept of primecoins, you'll not see this in other cryptocoins (atm). these are the shares the miners submit to the pool to get their reward. unfortunately you can tweak your software to generate more shorter (actually useless) chains. currently the pool doesn't care about chain lengths, but this will change to prevent people from tweaking their miners for shorter chains.
ypool uses different rewards per chain-length too, but they have a proportional payout scheme. rpool... uhm yeah... i actually dont have a clue how rpool's payout works, too much asian symbols on their website, but their reward system is also based on the chain length and proportional per block i think, looks like they make some similiar mistakes like i did ... they'll learn! :o :D
- xolokram :-X
"payout_current": 0.0010839806188654383,
"payout_pps": 0.0011091239283266246,
"payout_pps_pato": 0.0006092909501900293,
It would seem that PPS is about 3% higher and PPS_PATO is 50% lower. I would not consider 3% significant, but I would 50%; pps_pato would be a disaster for me.
I am still coming up to speed on primecoins but understood up front they are very different from SHA/SCRYPT based coins. I understand the basic concept of chain length, but not exactly how it fits in. If I am reading the /user page correctly and the details represent percentages I am finding better that 90% 6's (Shorter? Useless?) with a few 7's and not much above that. Watching the miner display seems to confirm that.
"details": {
"6": 0.9103448275862069,
"7": 0.08045977011494253,
"8": 0.00842911877394636,
"9": 0.0007662835249042146
}
Is this typical, or am I doing something wrong?
Out of curiosity what would happen if I found a chain longer than 9? I see no mathematical reason that could not happen. Does your algorithm simply stop looking at 9?
As far as I can tell ypool is NOT a straight proportional payout but is gimmicked up with rewards and bonuses and all sorts of junk; since they were the first, and arguably largest, I considered them first.
- According to my very limited calculations beeeeer's shares per second are very simular to ypools now, maybe only a couple of shares in it!
- Xolo I don't get the point of having pato's dumb idea shown to everyone, it really can only freak them out. I mean really, he stopped posting here for a reason because nobody wants to hear his crackpot theories anymore and he can't sway anyone with his broken math.
Just remove the pato_pps as it really is just a remnant of what really should be considered a bad joke ;)
-
Xolo I don't get the point of having pato's dumb idea shown to everyone, it really can only freak them out. I mean really, he stopped posting here for a reason because nobody wants to hear his crackpot theories anymore and he can't sway anyone with his broken math.
Just remove the pato_pps as it really is just a remnant of what really should be considered a bad joke ;)
I can't say I was "freaked out", but it did give me pause. I have no idea who Pato was, or what his idea was. Can I assume that the pps_pato has no bearing on the new logic being implemented?
- @roger:
there's a good reason why ypool, rpool and soon beeeeer have different rewards for different chain lengths. it was discussed alot in this thread.
@icedaddy:
with SHA/Scrypt the only thing that really matters for a miner is "produce as many shares as you can"; primecoin has to adjust this to keep (pool-)miners from only producing useless short chain-length-ish shares. why not abandon shares with short chain-lengths at all? good question: what should be rewarded then, if not the shares below the current difficulty would be the counter-question. in other words: primecoin shares are not worth equally and since you can tweak the software to produce more short chains you have to reward the miners that produce long shares (aka help the community aka help the pool).
shares with chain length above the current difficulty (atm that value is 9.8x) means: jackpot, you've found a block!
ypool's payout is (or it was when i checked the last time) proportional per block + bonus for the last 80 (?) blocks
@theprofileth:
you could've just said: remove pato's stupid idea from the stats, xolo!!
my answer would've been: yes, you're right! let's remove that sh**
btw. tomorrow!! :)
proper answers to pato's stats:
1) it's not properly scaled, it was implemented to show someone that his assumptions were stupid ... on the internet ... man, this actually sounds more stupid ;)
2) it will -NOT- be part of cppsrb on beeeeer, just use the "payout_pps" stats and compare them to "payout_current"
- xolokram
-
ypool's payout is (or it was when i checked the last time) proportional per block + bonus for the last 80 (?) blocks
It's proportional spreaded out in the next 80 blocks. If there are orphaned blocks in the 80, well, too bad (http://ppcointalk.org/index.php?topic=408.msg3926#msg3926).
-
@Sy:
it's set to 3.01 (3.0 + 0.01 primecoin transaction fee)
the new info on the user page is the sharelog as used by the cppsrb
i don't know if that helps, i'll let you know when everything is setup and will explain to you what everything means; so you can build the eye candy for the cancer i call web-frontend ;)
Bwahaha well said xD
And thanks, ill switch to database backed stats once thats finalized and most likely "restart" from that block onward, i don't think old and new will really work together but we'll see.
- @roger:
there's a good reason why ypool, rpool and soon beeeeer have different rewards for different chain lengths. it was discussed alot in this thread.
Hi Xolokram
I totally understand what your saying and what the system will be like, I am resigned to the fact that the system has to change for the betterment of the pool and all the miners, all i'm doing is venting some fury over my pet hate ypool.
Long live Beeeeer!! :D
- Is there the posibility to listen on more than one port? Like 8080, 443 or 21? Ports that by default aren't blocked ;D
-
that sounds like a network (configuration) problem on your side
please use the tech support thread for more details / help
Sy asked for additional (typical web) ports to run the pool on, maybe this will help you too --- i'll let you know here, when this is activated on the pool side
@Sy & icedaddy:
try using one of the following ports (instead of 1337): 21, 443, 8080, 133337
btw. i've switched to a (nosql) database driven sharelog regarding cppsrb, i'm not sure how to implement a good overview for users/overall stats, i'm working on it. (cppsrb is still running simulated)
- xolokram
-
that sounds like a network (configuration) problem on your side
please use the tech support thread for more details / help
I was not aware there was such a thing, even though it is displayed in large block letters in the first post of this thread. :-[ I apologize. My post has been removed from here and placed there.
-
minor maintenance on the web frontend done - see main page, don't press f5, use a modern browser, allow javascript, watch the magic happen :)
- Has multi-miner support been added yet? Doubled the size of my cluster today. Have i7, i5x2, i3x2/ Currently have half of my cluster mining at rPool till I can see multi-miner stats on beeeeer.
-
minor maintenance on the web frontend done - see main page, don't press f5, use a modern browser, allow javascript, watch the magic happen :)
Hi xolo,
the xxx.59999999999 and xxx.90000000000001 I am getting look like floating point rounding errors, don't they?
nice designs by the way, I love TUIs :D
- Sorry so much time without posting, I needed my time and mind for other purposes.
First of all, I admire the work of xolokram and I like this pool. My thoughts are neither against the person nor against the pool, on the contrary, I try to to help. If it is not help I am sorry.
That said, I find some obstacles for neutral thinking. A pool administrator wants as much mining power on his pool as it could be, so he tries to attract big miners, which is in contradiction with the main reason for pools to exist, which is to join many small forces to make a big force. On the other side, small miners have few options, they cannot do solo mining because the time to get a block would be extremely large, and there are only 3 pools for primecoins. So, either they accept the pool rules or they don't mine.
Then, the way is to get that big miners earn more in the pool than doing solo mining, which is only possible taking part of the contribution of small miners, which have no means to measure how much they would earn with solo mining compared with pool mining, and they have no possibility to prove if they are receiving less than they contributed.
I am not saying that xolokram has the intention of fooling small miners in that way, on the contrary, he is convinced that small miners would tweak the miner software to improve their poor earnings fooling the "good" big miners. Also he tries (of course) to get as much mining power as he can for the pool. Both motivations go against small miners.
I would like a pool that would really join thousands of small miners to effectively get the equivalent of a big miner with thousands of CPU cores. I think that systems who can get an average of more than one block per day would make a better job with solo mining for their selves and for the Primecoin network.
This post is about motivation and philosophy, I am writing another practical one (again ;) ).
- I don't see your point about bad miners being good or bad.
A "bad" small miner will tweak his application to get unfair advantage, albeit small, over the other "good" miners, small and big alike.
A "bad" big miner will tweak his application to get unfair advantage, over the other "good" miners, small and big alike.
The unfair advantage is proportional to how big the miner is, so the bigger the miner the more incentive there is for him to cheat, contrary to your logic.
So the goal is to protect honest people from cheating people, regardless of "size".
PS. I mine with 1 i7 processor, I get a block every 4 days avg when soloing, so I guess I am on the small side of the scale, and my miner is the stock one. Still my "payout_pps" is 20% higher than "payout_current"
- Hello again. When I tried to explain things with examples I only got that people with low math level think that I have low math level. So I will try to explain theory.
Any valuation method for the contribution of each worker in a pool must try to estimate how much blocks (fraction of block) would get each worker. I hope that most of you agree with this premise.
As that estimation is a prediction, it should be based on probability. The only data that we have for it is the number of chains of each length greater or equal than a minimum (6), and smaller than the difficulty (9). (The only chain greater than difficulty on each round should be considered 9-length also, as its "luck" is what is "shared").
To get a probability estimation of finding a block from the number of chains of each length, we need either to measure or to model the discrete probability distribution of lengths. We can assume that the distribution is the same for every worker, which is not true, or try to measure the distribution from each worker data. But we can not measure any distribution if we have only few chains of length 6 for many workers, so we have no option, we must assume the same distribution for everybody (that is one reason why my previous model (http://ppcointalk.org/index.php?topic=485.msg3761#msg3761) is not good, the other being a wrong assumption that the distribution was perfectly exponential).
Lets define our distribution as the probability P of each length and the one of length greater than difficulty, P(d):
distribution = {P(6), P(7), P(8), P(9), P(d)}
Then we can estimate the fraction of block, V, from the number of chains of each length, N(x), in the following way:
V(6) = P(d) * N(6) / P(6)
...
V(9) = P(d) * N(9) / P(9)
So that instead of modeling the probability we can model V(x) directly. We could indeed estimate V from all the chains, as the join probability is the sum of probabilities:
V(6, 7, 8, 9) = P(d) * (N(6)+N(7)+N(8)+N(9)) / (P(6)+P(7)+P(8)+P(9))
but it must be noted that in this case we need chains of all the lengths, otherwise we can not apply the same model for V.
So, lets say that we have a modeled or measured V(x), or estimation of blocks from each length measurement. But we want only one estimation, not four different estimations. In that case, the straightforward way is to do the average of the four estimations:
V = (V(6)+V(7)+V(8)+V(9)) / 4
or, if we have only 6-chains and 7-chains:
V = (V(6)+V(7)) / 2
We could think that V(6) is a worst estimation than V(8), for example. Then, what we want is to do a weighted average. Lets call W(x) to the weight for each length. Then the proper way to do it is:
V = sum(W(x)*V(x)) / sum(W(x))
In the case that a worker have chains of every length it will be:
V= (W(6)*V(6) + W(7)*V(7) + W(8)*V(8) + W(9)*V(9)) / (W(6) + W(7) + W(8) + W(9))
but in the case of a worker with just 6-chains it will be:
V= W(6)*V(6) / W(6) = V(6)
(logically, it has not sense weighting with only one datum; applying weight without dividing by the sum of weights is mathematically wrong and very unfair for the less weighted)
Now, the formula proposed by Xolokram (http://ppcointalk.org/index.php?topic=485.msg3935#msg3935) could be considered as V(x), with diferent "adjustment":
V(x) = adjustment * (0.1 * 10^(x - 6)) * (block_reward / e^block_difficulty)
but what he do with it is to sum estimations: V(6) + V(7) + V(8) + V(9), which is not correct and not justified on any basis. Besides that I also think that the modeled distribution is a desired distribution, far from real because it is not based on real data or primes theory, so it is worst than a measured distribution from the data of each round, which is easy to get and quite fair, as it reflects the distribution of mayority of mining force in the pool.
- That's pretty complicated :)
I have a question, about the sum of probabilities.
V(6,7) = Pd * (N6 + N7) / (P6 + P7)
Is that right?
-
I am not saying that xolokram has the intention of fooling small miners in that way, on the contrary, he is convinced that small miners would tweak the miner software to improve their poor earnings fooling the "good" big miners. Also he tries (of course) to get as much mining power as he can for the pool. Both motivations go against small miners.
I would like a pool that would really join thousands of small miners to effectively get the equivalent of a big miner with thousands of CPU cores. I think that systems who can get an average of more than one block per day would make a better job with solo mining for their selves and for the Primecoin network.
neither i said that nor is this my intention. otherwise a very nice and fancy post...
So the goal is to protect honest people from cheating people, regardless of "size".
this.
[...]
i will go through your large post later, but don't expect me to waste time on bogus ideas again.
btw.
V(x) = adjustment * (0.1 * 10^(x - 6)) * (block_reward / e^block_difficulty)
the post you're quoting is really old, the calculation (especially this part "(0.1 * 10^(x - 6))") is not how it's going to be implemented, check out the RPS (reward per share) values on the beeeeer main page, it's based on the actual distribution of chain lengths, not on assumptions. have a nice day.
- xolokram
- Did something on http://beeeeer.org/blocks change?
My script is finding thousands of old blocks previously unlisted, was the list truncated?
- nope, the list has not changed.
i changed some smaller parts (html header & main page) yesterday --- i think the blocks & payout list was empty for a short time during maintenance, maybe because of this your script thinks that the blocks are "new" ?
please tell me if there's something wrong with the web frontend.
- xolokram
ps. i will be back later today
-
nope, the list has not changed.
i changed some smaller parts (html header & main page) yesterday --- i think the blocks & payout list was empty for a short time during maintenance, maybe because of this your script thinks that the blocks are "new" ?
please tell me if there's something wrong with the web frontend.
- xolokram
ps. i will be back later today
Some blocks (and i guess payout aswell) got </pre></body></html> at the end, i think that is incorrect - it at least broke my json_decode ^^
Oh and there is a HTML header aswell xD
<html><head><meta http-equiv="Content-type" content="text/html;charset=UTF-8"><meta charset="UTF-8"><script src="http://code.jquery.com/jquery-1.10.2.min.js"></script><script src="/socket.io/socket.io.js"></script><script>var socket = io.connect('/');socket.on('news', function (data) { $('#'+data.type).text(data.value); });</script></head><body><pre>{
plus in block 182494 it says
</pre>kLU": 0.005705555555555556,
"ARoBTbDmMZhRe4tA9uqHfwWLTiEMnHjvU4": 0.005705555555555556,
"AerFbyt7sE2Fwxbj5nYbpEuPJenstPeVk5": 0.005705555555555556,
"AK8r3AMvG2rw6gSA2GyHYYiqKEdoR4nJPo": 0.005705555555555556,
"AeBk6YnLM9zpqpLTWVMz5hofKWJRXHDtz8": 0.005705555555555556,
"ARskhKebzwhUsQms8dTj78qtmaUgDvvX9P": 0.005705555555555556
}
;D
-
...
Your reasoning is wrong because you apply it always to just one block found. In the long run, the small miner will find a #9 chain, and this is the moment when he gets the reward you think he is missing. If you have been rewarding him with your system, when he finds the #9 chains he will get more than he deserves.
The only problem is variance, not total reward. Any reward system that tries to prevent people from cheating finding only #6 chains will increase variance for small miners.
- @Sy:
i'll provide a clean json interface without any html garbage asap - give me a few minutes
@patapato:
you're doing the same thing wrong again.
let's say W(x) = 1 (for every possible x (6,7,8,9)) <-- you can actually ignore the example weighting
then every payout calculation should look like this:
V= (W(6)*V(6) + W(7)*V(7) + W(8)*V(8) + W(9)*V(9)) / (W(6) + W(7) + W(8) + W(9)) <-- this is the important part
with the little difference (that's the part you don't get) that V(whatever) can be 0 (zero)
aka
you always divide by (W(6) + W(7) + W(8) + W(9)) = 4
just because someone didn't found a (let's just say) 9-chain, doesn't mean his payout should only consider weigting of 6, 7 & 8s since you want to compare his payout to other miners (that actually did find 9-chains!)
it's the same idea again you tried to establish the last time, or am i missing something
/edit: to everyone who's able to help...
can someone with machines with more than 10 threads test my latest commit?
i changed something in the communication/thread management to reduce the bandwidth/workload for the pool (thus reducing the communication interval & rejection rate for everyone).
github/bitbucket commit sha: 4030fa77edb655b19c94e3928f134a62720e6908
provide some info about (please test with a reasonable time interval):
- workload of your miner
- performance of your miner
- rejection rate of your miner
(compare v0.4 with v0.5 RC)
i currently do not have a machine with more than 8 threads to test everything practically. thank you.
- xolokram
-
/edit: to everyone who's able to help...
can someone with machines with more than 10 threads test my latest commit?
i changed something in the communication/thread management to reduce the bandwidth/workload for the pool (thus reducing the communication interval & rejection rate for everyone).
github/bitbucket commit sha: 4030fa77edb655b19c94e3928f134a62720e6908
provide some info about (please test with a reasonable time interval):
- workload of your miner
- performance of your miner
- rejection rate of your miner
(compare v0.4 with v0.5 RC)
i currently do not have a machine with more than 8 threads to test everything practically. thank you.
- xolokram
I'm compiling on my smallest thread count of 24. I'll edit this post when I have some numbers for you.
edit:
This is on a 2P Xeon X5650 overclocked to 4GHz. Basic config, no extra switches aside from minerid.
0.4
2013-10-04 14:30:17 primemeter 28993844 prime/h 448080940 test/h 2040 5-chains/h 4.291916 chain/d
********************************************
*** running time: 13.654hrs
***
*** 6-chains: 2951 (90.411% | 216.125/hr)
*** 7-chains: 275 (8.425% | 20.140/hr)
*** 8-chains: 32 (0.980% | 2.344/hr)
*** 9-chains: 6 (0.184% | 0.439/hr)
***
*** valid: 3264 (92.125%)
*** rejects: 276 (7.790%)
*** stale: 3 (0.085%)
********************************************
0.5RC1
2013-10-04 22:15:45 primemeter 28621863 prime/h 442147571 test/h 2940 5-chains/h 4.244472 chain/d
********************************************
*** running time: 4.728hrs
***
*** 6-chains: 979 (91.410% | 207.086/hr)
*** 7-chains: 86 (8.030% | 18.191/hr)
*** 8-chains: 6 (0.560% | 1.269/hr)
***
*** valid: 1071 (85.612%)
*** rejects: 178 (14.229%)
*** stale: 2 (0.160%)
********************************************
-
@mardoc:
thank you. i look forward to your results.
@everyone: +++ important message +++
my server provider notified me, that they scheduled an important maintenance for this night
sometime (they say it shouldn't take longer than 30 minutes...) within the next 6 hours the pool will not be available!!
i checked my restart scripts and everything. the pool should restart on its own.
unfortunately i'm not able to monitor everything during this time live. if something goes wrong i'll restart/check the pool manually asap.
however, i made a backup of all pool wallet files, payouts & found blocks (so far) --- better safe than sorry, right? :)
ok, it's not tonight. ::) sorry, my bad!
- xolokram
-
/edit: to everyone who's able to help...
can someone with machines with more than 10 threads test my latest commit?
i changed something in the communication/thread management to reduce the bandwidth/workload for the pool (thus reducing the communication interval & rejection rate for everyone).
github/bitbucket commit sha: 4030fa77edb655b19c94e3928f134a62720e6908
provide some info about (please test with a reasonable time interval):
- workload of your miner
- performance of your miner
- rejection rate of your miner
(compare v0.4 with v0.5 RC)
i currently do not have a machine with more than 8 threads to test everything practically. thank you.
- xolokram
Hi all, new here , been mining for a few days now, just to be able say "I was there" :). Big "thanks to @xolokram and all the contributors here - it's a really interesting project
@xolokram I've just kicked off a 12 thread miner using the new v5rc1, and I have a log file from ~40hrs mining to inspect. Sadly I don't see the final stats in the log (after sending a kill signal to the nohup'ed pid) so I'll need to reconstruct stats from the log. I will post again after I've done this.
-
Stats gathered so far:
https://docs.google.com/spreadsheet/ccc?key=0AqyT2lTX1fRPdDdIRGpnaU94WldzU (https://docs.google.com/spreadsheet/ccc?key=0AqyT2lTX1fRPdDdIRGpnaU94WldzU)
https://docs.google.com/spreadsheet/ccc?key=0AqyT2lTX1fRPdDdIRGpnaU94WldzUVV1eHFqM2VaOGc&usp=sharing
After 1 hr I see reject ratio is much higher now. 1.5% 6% => 15% 18%.
But letting it run and will advise when stats are updated after 2hrs.
@xolokram
has there been anything server-side that might impact rejects in the time-frame??
edit: hrs 2 and 3 added to stats spreadsheet. Corrected some numbers that were off. Rejects have come back to similar levels to v4 stats @ around 6.5%
Will update again after another 12-15 hrs if things seem stable.
edit updated stats after another 16 hrs Rejects avg'd 10.7% for this period.
@xolokram
- fixed link (sorry should have checked it)
- editing here as suggested
- will build the new version asap :)
- @churchmouse:
please use "edit" instead of double posting if no one else has posted yet; it keeps the thread a little bit cleaner.
/edit: your spreadsheet url seems to be broken?!?
anyway: of course - thank you for the information @churchmouse+mardoc
the problem with the rejection rate is, that the pool is causing this during the night time due to (very) heavy workload (6000+ workers connected). i'm trying to counter this with v0.5, but as long as almost all miners use v0.4 or v0.3 this will not change too soon. but since this patch changes the thread management / work-control of the miner it's good to see that there's no performance decrease (all cores are running, and no decrease in chains/hr).
@churchmouse+mardoc:
i've commited a (dirty) patch for RC1, can you test this patch too, please?
- xolokram
-
@churchmouse+mardoc:
i've commited a (dirty) patch for RC1, can you test this patch too, please?
- xolokram
@xolokram
new (dirty) patch to 0.5RC1 has run fine for last two hours with what looks to be normal mining performance. Have added new stats to spreadsheet (https://docs.google.com/spreadsheet/ccc?key=0AqyT2lTX1fRPdDdIRGpnaU94WldzUVV1eHFqM2VaOGc&usp=sharing). I see more rejects (13.5%) but we're hitting >7000 workers now.
- very much rejects tonigth :(
"0": 100,
"6": 433,
"7": 47,
"8": 2,
"9": 1,
"-6": 7,
"-7": 1
workers: 6282
-
@churchmouse+mardoc:
i've commited a (dirty) patch for RC1, can you test this patch too, please?
0.5RC1 (dirty)
2013-10-05 23:36:49 primemeter 29272716 prime/h 453736133 test/h 2100 5-chains/h 4.336879 chain/d
********************************************
*** running time: 11.330hrs
***
*** 6-chains: 2332 (91.487% | 205.825/hr)
*** 7-chains: 196 (7.689% | 17.299/hr)
*** 8-chains: 21 (0.824% | 1.853/hr)
***
*** valid: 2549 (84.995%)
*** rejects: 440 (14.672%)
*** stale: 10 (0.333%)
********************************************
- xolo how can i add the settings and user all to exe so all i have to do is run the exe on my vps
-
xolo how can i add the settings and user all to exe so all i have to do is run the exe on my vps
You should use the technical support thread for questions like this.
If you're running Windows you just create a batch file with all the information in it and run that batch file. If you're in Linux you can create a bash script with the same information and then run that script.
- Hello!
Can I connect the Ripper?
What are the parameters of authorization?
- next time use the tech support thread.
@JIM:
by Ripper you mean Reaper mining software, right?
it's not possible yet, i think reaper uses the GBT protocol which is not supported currently by beeeeer.
@elvisrene:
i dont really understand your question, but mardoc's right: it sounds like a tech support problem. ;)
@mardoc+churchmouse+grekk:
thank you. the work submission delay is really painful. with 4-5k connected users the delay is ~500 - 900 ms.
at 6k+ workers we reach ~1500 ms.
at 7k+ workers i've seen peaks of ~4 seconds.
the delays (time intervals) are responsible for most of the rejects.
so the ch/hr performance seems to be alright with v0.5, i guess i can package a new release then :)
/edit:
i've made final adjustments to the v0.5 release candidate (called it v0.5 RC2)
can you test the latest commit: aa32fbc4a428450cf6d0c0a34e15a5e9d66c7d77
if everything works like intended (mining performance / rejections etc.pp.) then i will release v0.5
- xolokram
- Can anybody tell me if pps has been implemented yet?
-
/edit:
i've made final adjustments to the v0.5 release candidate (called it v0.5 RC2)
can you test the latest commit: aa32fbc4a428450cf6d0c0a34e15a5e9d66c7d77
if everything works like intended (mining performance / rejections etc.pp.) then i will release v0.5
0.5RC2
2013-10-06 21:38:06 primemeter 29498988 prime/h 455556267 test/h 3240 5-chains/h 4.358676 chain/d
********************************************
*** running time: 10.045hrs
***
*** 6-chains: 2106 (90.893% | 209.657/hr)
*** 7-chains: 185 (7.984% | 18.417/hr)
*** 8-chains: 25 (1.079% | 2.489/hr)
*** 9-chains: 1 (0.043% | 0.100/hr)
***
*** valid: 2317 (86.552%)
*** rejects: 360 (13.448%)
*** stale: 0 (0.000%)
********************************************
-
@mardoc:
first: thank you.
looks like the ch/hr performance is alright.
i think i can wrap up a release within the next hours.
your rejection rate is quite high, i'm currently getting a rate below 8% 5%, mhhhhh
@roger:
not yet, i've some time this week, expect it to happen. :)
- xolokram
-
i've made final adjustments to the v0.5 release candidate (called it v0.5 RC2)
can you test the latest commit: aa32fbc4a428450cf6d0c0a34e15a5e9d66c7d77
if everything works like intended (mining performance / rejections etc.pp.) then i will release v0.5
- xolokram
@xolokram
I have updated my stats spreadsheet (https://docs.google.com/spreadsheet/ccc?key=0AqyT2lTX1fRPdDdIRGpnaU94WldzUVV1eHFqM2VaOGc&usp=sharing) after 31 hrs on 0.5rc1 (dirty) . This looks to be performing same as v0.4.
I kicked off a v0.5rc2 miner an hour ago. Will update in another 10hrs or so.
Just one minor niggle that I've noticed:
With 0.4 and 0.5rc1 (dirty) the timestamps for the "primemeter" log lines were stable - reporting at 60s intervals.
In 0.5rc1 (dirty) they're drifting by about 1s every 3hrs.
edit: in 0.5rc2 they're drifting by 1s every 1 or two minutes. No they're not, sorry!
For anyone wanting to analyse performance using these log lines (as I've been doing) it means extra work to compensate. But I'd say it's a small concern, relative to the other stuff you've got on your hands.
Once again, thanks for all your hard work!
- thanks churchmouse. i will wait for your stats then.
the timestamps for the primemeter are part of the original mining code of the primecoin-hp project. it's not really a problem if the value fluctuates, the actual codes "says": after 60 seconds or more update the stats, show the primemeter to the user and reset the timer for the next primemeter-update. if your threads are busy enough the time interval fluctuates a little.
- xolokram
ps. btw & fyi: pool restarted
- V0.5RC2 Stats (12hrs) added in my stats spreadsheet (https://docs.google.com/spreadsheet/ccc?key=0AqyT2lTX1fRPdDdIRGpnaU94WldzUVV1eHFqM2VaOGc&usp=sharing) . Performance looks fine.
@xolo
Yes, from beginning of these tests, I notice that primemeter log lines were sometimes delayed - by up to several minutes. But they reported metrics for a stable 60s interval, until the (dirty) change. Just an observation, not a request to fix :)
- Just wondering, is it possible to mine XPM with fpgas (with any miner at all?) would be nice... ^^
Nevermind, was asked somewhere in this thread before but it should basicly be possible i guess since its not ram dependant, just cpu power.
- Morning Everyone.
I was bored on the train this morning so I built a simple UI for running xolominer.
It's downloadable from here (source code too): https://bitbucket.org/mj2p/xolominer-parameters (https://bitbucket.org/mj2p/xolominer-parameters)
It's built using AutoHotkey (http://autohotkey.com) and the executable is compiled using the ahk2exe utility that comes with AutoHotkey.
To use it, drop the xolominer-parameters.exe file into the folder where your primeminer_*.exe file is and run it.
On the first run you will be shown the UI to enter your parameters.
On subsequent runs, the miner will be started automatically using the saved parameters.
If you want to edit your parameters, press 'WindowsKey+Ctrl+W' to kill the miner and show the UI.
I've added the parameters that I use frequently but may have missed others. If there's a parameter that you would like to see, let me know and I'll add it.
Hope it's of use to someone :)
- @churchmouse:
thanks for you contributions. v0.5 will be out soon for everyone (aka windows).
@Sy:
i'm not to much into FPGA programming, but the massive use of double precision (or 'custom' precision) for primecoin mining could be a problem for FPGAs. But you're right, memory is not an issue.
@MJ2P:
thnak you.
- xolokram
ps. working on the final steps towards cppsrb
- Are there any benefits in updating to 0.5 if you aren't running 10+ threads per machine? ;D
- yes. the new thread management helps the pool to reduce overhead/workload and thus reduces the delay of work-data-distrubution for all users (less rejects). at least that's the theory, we have to see how it works when most of the users switch to v0.5.
i also added some features to detect disconnects and connection problems, which could help users with bad connections.
- xolokram
- How long does it take XPM transfer to my account.
From two days waiting for the XPM.
- currently it takes 3200 network confirmations
that's ~53 hours + some delay because i'm executing the payout script manually for monitoring purpose
i'm currently working on another payout system, which will decrease the payout time interval
but it's not ready yet
- xolokram
- Never understood why they've choosen 3200 confirms -.-
- Why so many rejects today? :o
"0": 83,
"6": 448,
"7": 49,
"8": 4,
"9": 1
- Hi
Can you help me? Can I mine on beeeeer.org If I use this script on Ubuntu 13.04 server?
if [[ ! -f /swapfile ]]; then
echo "Building swapfile..."
sudo dd if=/dev/zero of=/swapfile bs=64M count=16
sudo mkswap /swapfile
sudo swapon /swapfile
if [[ -z "$(cat /etc/fstab | grep swapfile)" ]]; then
echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab > /dev/null 2>&1
fi
fi
if [[ -z "$(cat /etc/sysctl.conf | grep '^kernel.panic')" ]]; then
echo "kernel.panic=3" | sudo tee /etc/sysctl.conf >/dev/null 2>&1
fi
sudo apt-get update
sudo apt-get install build-essential bc cpulimit curl dos2unix fail2ban git haveged libboost-all-dev libdb++-dev libminiupnpc-dev libssl-dev m4 nano -y
git clone https://github.com/thbaumbach/primecoin.git && make -f makefile.unix primeminer &&
cd ./primecoin/ && ./autogen.sh && ./configure && make && sudo make install &&
./primeminer -pooluser=AMuPGPXEZUjyGPqRG8vzPDr1cGeMMNvd8v -poolip=beeeeer.org -poolport=1337
Thank you
- As i am reading this, you should hardcode poolip and port into your program, use them if not set - making the cmd shorter ^^
-
Hi
I had a lot of important things to do today. Unfortunately they had nothing to do with the pool. :-\
Anyway I wanted to release CPPSRB & v0.5 simultaneously - which is scheduled for tomorrow at 11 AM (https://developer.valvesoftware.com/wiki/Valve_Time) *whoaaa*. currently the web interface for cppsrb's user stats is giving me a headache.
(I could release v0.5 seperately though, right? :P )
@Grekk:
I don't know, maybe heavy workload (on the server side) during the 'night' ('night' on a global basis :) ) time. once v0.5 is out and widely used this should be history.
@soulmann:
please use the technical thread for questions like this.
although the script looks ok i think there are some unnecessary (wrong?) things in there. e.g.
[...] make -f makefile.unix primeminer &&
cd ./primecoin/ && ./autogen.sh && ./configure && make && sudo make install &&should be just
cd ./primecoin/src && make -f makefile.unix primeminer &&i guess. and i don't know if you need the whole 'swap' stuff at the beginning, depends on your system.
and the kernel.panic thing auto-reboots your system on kernel failures, right?! where do you have this script from?
- xolokram
-
Can someone tell me if those are normal?
"6": 0.9075663805150729,
"7": 0.08504691555200639,
"8": 0.007187063286085047,
"9": 0.00019964064683569574
Thanks
- I accidently open primeminer_x64.exe and primeminer_x32.exe in my computer, he opened a cmd prompt. what happened? he is gonna start mining to someone? I put in virustotal and it has a trojan lol pls help me.
- @hawas:
depending on the total amount of shares the percentage of 9-chains is a little low. but this could just be caused by randomness.
@usbtutorials:
at least you should show us the virustotal log url, right?
the only thing i know is symantec's stupid detection via "Reputation" which is rating every Whatevercoin-miner "bad" (this includes my miner). Thank you for your helpful (double) post.
- xolokram
- https://www.virustotal.com/pt/file/77784aa03b7bbccc1679379eeff9d777566038e9f49d30f2deb6b8ecd6a5d591/analysis/1381436322/
I opened the file, now what? I dont want to mine with my computer -.-
- ok, thanks for the info.
if you don't provide any IP info to the parameters of the exe nothing is mining at all.
http://virusscan.jotti.org/
is giving another generic problem warning on one of their scans.
this is really annoying. i can't really do something against this, but encourage to build the software on your own (which is of course a problem for windows users).
- xolokram
-
https://www.virustotal.com/pt/file/77784aa03b7bbccc1679379eeff9d777566038e9f49d30f2deb6b8ecd6a5d591/analysis/1381436322/
I opened the file, now what? I dont want to mine with my computer -.-
Hi,
seems to be a false positiv through Heuristic Pattern.
If you wan´t to be sure, delivere the sample to Symantec
https://submit.symantec.com/websubmit/retail.cgi or http://www.symantec.com/security_response/submitsamples.jsp
it is free of charge.
ALso for Trend:
http://esupport.trendmicro.com/solution/en-us/1056444.aspx
This is if you wan´t to be sure.
Adittional, if you click primeminer.....exe it will ever start a promt containing the error the parameter are missing.
-
Never understood why they've choosen 3200 confirms -.-
Actually I think this was done to make 51% attacks harder to complete as you would need to maintain the majority of the network speed for over 2 days straight or you would probably lose all your blocks or at least a lot of them. Plus it helps prevent pump and dump ;) then again why else would you mine ;D
- Ok, CPPSRB (the PPS-based payout system) is pretty much complete regarding the backend. The only problem is, i'm not able to monitor the pool for the next ~24 hrs, which is not good if something bad happens (obviously). I will stick to the plan to release v0.5 (for windows) and CPPSRB simultaneously, which should be done by tomorrow afternoon. There will be some drawbacks for the first days regarding the web frontend, because it's not 100% ready yet, which will lead to some confusion i guess ("Where's my payout in the block information?"-esque). With CPPSRB your payout will be directly connected to the shares you submit and no longer with some block.
I hope this post is more informative than confusing :D
- xolokram
- Great news xolokram.
I'm looking forward to seeing what changes have been made.
Thanks again for your hard work on the pool.
- wait until i f**k up the pool software ;D
CPPSRB will be a huge step, i dont expect it to run flawlessly from the get go. :(
we'll see.
- so, ola ... first i'like to thank's for the job. about this pool beeeer.org ... i'm german ... i'love beer ... ;-) i'm start mining at your pool several week's are ago. and aschly never i'pay pool fee ... but here i'do ... today i'was compile the v.05.rc2 on ubuntu 13.04 .... it's work very fine.
have fun,
xhabit
-
btw.
V(x) = adjustment * (0.1 * 10^(x - 6)) * (block_reward / e^block_difficulty)
the post you're quoting is really old, the calculation (especially this part "(0.1 * 10^(x - 6))") is not how it's going to be implemented, check out the RPS (reward per share) values on the beeeeer main page, it's based on the actual distribution of chain lengths, not on assumptions. have a nice day.
- xolokram
Ok, sorry. I'm glad of it.
- Xolokram
rejects
"0": 254,
"6": 536,
"7": 40,
"8": 3,
"-6": 1
and
"payout_current": 0.0005331275753053904, went down twice as in the last two days... Who is cheating pool?
-
@patapato:
you're doing the same thing wrong again.
let's say W(x) = 1 (for every possible x (6,7,8,9)) <-- you can actually ignore the example weighting
then every payout calculation should look like this:
V= (W(6)*V(6) + W(7)*V(7) + W(8)*V(8) + W(9)*V(9)) / (W(6) + W(7) + W(8) + W(9)) <-- this is the important part
with the little difference (that's the part you don't get) that V(whatever) can be 0 (zero)
aka
you always divide by (W(6) + W(7) + W(8) + W(9)) = 4
But V(x) would never be really zero, it would be a real number between 0 and 0.5, and we are trying to measure that number with integer counting, so that it is rounded to zero (that's the part you don't get). Because of it we must use the corresponding W(x) as zero also (so I don't divide by 4 always).
- @Grekk:
due to the release of Grom's version of my (or another custom?) miner for windows, which is optimized for shorter chains the payout is fu**ed up for the current payout system. Some of the users (6-8 addresses) with lots of computing power are spamming 6- and 7-chains, which decreases the overall payout for everyone (due to less blocks) but give them a higher stake. time for cppsrb.
the number of rejects also increases because of the heavy workload produced by the increased number of share submissions (and 7000+ workers).
- xolokram
POOL MAINTENANCE INCOMING
-
That's pretty complicated :)
I have a question, about the sum of probabilities.
V(6,7) = Pd * (N6 + N7) / (P6 + P7)
Is that right?
Yes. You can think of it in other way: the number of (expected) blocks divided by the probabllity of a block is equal to the number of chains (of determined length) divided by the probability of a chain: V(6,7) / Pd = (N6 + N7) / (P6 + P7)
-
xolokram's miner v0.6 RC1 released
linux: source @ bitbucket (https://bitbucket.org/thbaumbach/primecoin-hp) or source @ github (https://github.com/thbaumbach/primecoin) (update to latest source & compile)
windows: xolokram's miner v0.6 RC1 (http://www.mediafire.com/?y1fk4y8paspmax9) (contains 32 and 64 bit version)
this will be part of the CPPSRB update.
some preview information:
- 6-chains are no longer part of the payout system (from now on only 7,8,9...-chains are used)
- CPPSRB is a PPS-based payout system, you are getting paid per share (not your stake of a block (old system))
- payout will differ for shares of different chain lengths (9-chains will be more valuable than 7-chains etc.pp.)
- web frontend is not 100% ready yet, i'll add more and more features/information (please be patient and give me some time for the updates)
- the default pool fee is now 3% (like before: this is adjustable via parameter, see OP)
- expect some bugs, nobody's flawless
- xolokram
ps. more information coming soon, let me just roll in the first batch of updates on the server side
- does that address the Grom 0.5 spam issue? is the payout / share the same? if shares / h is lower than 0.5 and payout between various length chains are the same, there's no incentive for people to move away from the Grom 0.5 miner.
- grom's (currently leaked!) miner will decrease your overall payout with the upcoming cppsrb update (i hope this will be incentive enough :) )
the spam/server-workload issue will (hopefully) be history when the majority switches to v0.6
i hope grom will update his miner soon enough so people can choose which miner software they want to use; but he should at least update his codebase to v0.6 asap
- xolokram
- system:111
connecting to 5.45.100.191:1337
system:111
connecting to 5.45.100.191:1337
system:111
What does it mean?
-
@fenix79:
i'll just quote myself here...
POOL MAINTENANCE INCOMING
aka pool is down
- what's the weighting factor for 7 / 8 / 9 ch shares?
- current experimental weightings depending on the current network difficulty (aka values in XPM) are:
7-chain -> 0.0040532 XPM
8-chain -> 0.042116 XPM
9-chain -> 0.52249 XPM
'block found' -> 0.56999 XPM
i'm not sure if the 'block found' bonus is a good idea, we'll see how everything will work out, when i execute the first CPPSRB payouts (in approx. 2.5 days * )
i'm expecting (and you should too) that these value will change to maximize payout / minimize possible pool debt.
- xolokram
ps. * = until then, i will of course execute the payouts from the 'old' payout system, when the corresponding blocks are confirmed from the network
- With the new payout system coming online, do we have to move to the 0.6 version or are we ok on the older versions?
- you will have to move to v0.6 (or at least: you should move to v0.6)
currently there is no penalty or difference in performance to v0.5 (except for Grom's leaked experimental miner), but i will add a penalty later, because v0.6 has some features to reduce the workload on the server side, which is actually helpful for everyone, because this reduces the number of rejects. i don't really think that it is useful to have all these old versions (there are still single miners with v0.3) floating around.
- xolokram
- hm ... one day befor i'was move my miner to v.5.rc2 ... other question what is with the coins what was mine and was not pay out?
-
hm ... one day befor i'was move my miner to v.5.rc2
i'm sorry about that, but i guess it's just bad luck for you. there's no perfect timing for such a huge update. :)
you'll have a few days to update your miners.
other question what is with the coins what was mine and was not pay out?
like i said before:
the blocks from the old payout system will be executed once they are confirmed by the primecoin network
just like they were paid before the cppsrb update (this will take ~2.5 days for all remaining/needed confirmations)
the new payout system will kick in once the confirmations are through from now on
expect the first payout for the new cppsrb system in ~2.6 days (+ some delay due to monitoring setup)
- xolokram
- Updated my miners (all Windows, some x86, some x64) to 0.6RC1 and can report that they are able to submit shares. And as expected there are only chains of length 7+ submitted. Good work!
- so, v.6. is up and running at the first miner ...
yes, bring the first share:
[MASTER] work received
Probable prime chain found for block=3d1adf447009cc8df7c762fa0b86b4ca190d89721833a3f33e5e7b628affeb43!!
Target: 09.e6bdcb
Chain: 1CC07.5115c8
[MASTER] submitted share -> SHARE
- Confirmed. One of my systems has been upgraded and is successfully submitting 7's (hopefully 8's and 9's soon too!). I will upgrade rest of systems tonight.
Thanks for all your work Xolokram.
Gilligan~
EDIT1: Back to back 8's reported.
- ok, thanks for all the information you're adding here. i'm done with the first initial updates.
expect some more updates (especially on the web frontend) tomorrow / on monday.
i'm aware of the fact, that you can't see stats about your submitted shares by now; i'll add this asap.
let's hope everything will be ok. good night.
- xolokram
ps. i should replace the "shares / second" counter by something useful ;D
- can user stats also be divided into pre CPPSRB vs post CPPSRB. having all those old 6 shares showing up in your stats make keeping track of the ratio of different length shares submitted difficult.
Thanks.
-
miner 0.6 up and running here, all well, a couple of 7 shares submitted.
Congrats for switching to the new payout system, been waiting for it :)
Edit
Holy, workers already down to 3000? Ok, it was temporary.
- Are 6-chains/old miners currently ignored or do we have to switch now? I have to recompile my Linux miners so it would be nice to make sure that bug are figured out on the few system so I only have to recompile once.
- Are shares being counted properly or user stats updated properly? I see some of my miners are showing time 0:56 while some are 20:56 (I a in Eastern Timezone). I'm pretty sure I submitted some shares in the past 30 minutes base on the reports from the miner. But I don't see the stats page updated, addr AcpjiZSC7fGigXGQzXYbfXDy3bTNRJHCGa
- @gog1
I'm missing a bunch too. Must be an update issue because Sy isn't showing any of the v0.6 finds. I am logging my own to ensure they get credited.
Gilligan~
- smal question: why the blocks stay fix on 500? if i look ... SyStats der are mutch more. what is the diff?
{
"address": "AdKXNNnue9jyHUJFmY1sF4vZn5V3cH1Mau",
"payout_current": 0.0005714811783784708,
"payout_pps": 0.0007441797970874334,
"shares": 2331,
"blocks": 500,
"shares_per_block": 4.662,
"details": {
"6": 0.9159159159159159,
"7": 0.07893607893607893,
"8": 0.004719004719004719,
"9": 0.000429000429000429
}
}
{}
- 6-chains are confirmed by the pool, but they will not have any value. please switch to v0.6 to get rid of the 6-chains after all asap. i was thinking about rejecting them, but that would've been way more confusing to people i guess, because what i've learned form the past: they're not properly reading what i'm writing here (ending in a lot of "why do i have so much rejects?" posts).
currently there are no known issues with v0.6, everything should be fine, you can compile & run the newest version.
as far as i know: Sy's stats is using the old payout system, thus his informations will end with block #206442 currently
the user stats on beeeeer.org are currently bound to your last 500 blocks (of the old payout system!!) you've submitted shares to (except for the payouts, which are still rolling in for the next ~2 days)
like i said before: the web frontend is not ready, wait for updates to see information about your current stats
- xolokram
/edit:
i added the stats about your latest submitted shares
they are bundled via time intervals of 20 seconds
see e.g. http://www.beeeeer.org/user/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE
- If you wish :
Updated Grom's mod http://www.mediafire.com/?o3dm789ezs1wy38 (http://www.mediafire.com/?o3dm789ezs1wy38) for beer/rpool
(Based on 0.6RC1)
it's still very dirty Beta so no warranty.
This Version should be ultimate blockfinder, but the rate on low shares 7ch, 6ch is drasticaly decreased to get benefit in speed.
(Beer version doesn't send 6er chains)
- Is there source for compilation in Linux? Also, how about a Windows 32bit version?
Thanks.
-
I'm a bit 'confused'.
I just started mining primecoin and this are my stats:
http://www.beeeeer.org/user/AdhVCjynjkmE3QPmi3ukuWFjXJrkmsVY9E# (http://www.beeeeer.org/user/AdhVCjynjkmE3QPmi3ukuWFjXJrkmsVY9E#)
Notice all is set to zero
"payout_current": 0,
"payout_pps": 0,
"shares": 0,
"blocks": 0,
"shares_per_block": 0
While another address (of xolokram) states quite some numbers:
http://www.beeeeer.org/user/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE# (http://www.beeeeer.org/user/ANKZ8GNu2tpMV8u99dQwWdWky3xk4HrFYE#)
Is this because of the fact I didn't mine for 500 blocks yet or....?
Also, after what x amount of time or x amount of coins mined do I get a payout in my primecoin wallet?
Thanks
Just to add, I do find some shares, last 3mins I got 3x 7-chain shares.
Probable prime chain found for block=10d4d0724c703814ec90d1d9a5252cde0cf52b91979
4c68a23fcfec6a9144b3b!!
Target: 09.e7c35a
Chain: 1CC07.471a94
Probable prime chain found for block=c0c1f75ce4e10bd9144d2eedb2fbef03100cb9148b0
e73339b3ec7c073290cdf!!
Target: 09.e7c4c5
Chain: 2CC07.55b230
Probable prime chain found for block=881fed23bebc768b2936bb8d62a828ae00a8662080b
26914cb8a93797dc6fd73!!
Target: 09.e7caed
Chain: TWN07.c11e25
- I have the same situation, EnJoyThis.
I started mining today and have quite a few shares, yet also have the following:
"payout_current": 0,
"payout_pps": 0,
"shares": 0,
"blocks": 0,
"shares_per_block": 0
I imagine this will update at some point soon.
I'm guessing you know you found 7 chain shares by this part: Chain: 2CC07.55b230?
-
I have the same situation, EnJoyThis.
I started mining today and have quite a few shares, yet also have the following:
"payout_current": 0,
"payout_pps": 0,
"shares": 0,
"blocks": 0,
"shares_per_block": 0
I imagine this will update at some point soon.
I'm guessing you know you found 7 chain shares by this part: Chain: 2CC07.55b230?
Yes that's correct.
Once in a while I find a 8-chain share, they are worth 10x the amount of 7-chain shares. So hopefully I will get some 9-chain shares too :-)
-
Something changes, getting error on all machines that ran and compiled the older version just fine...
/net.o: In function `ThreadMapPort()':
net.cpp:(.text+0x4f7e): undefined reference to `upnpDiscover'
net.cpp:(.text+0x4fb8): undefined reference to `UPNP_GetValidIGD'
net.cpp:(.text+0x4feb): undefined reference to `UPNP_GetExternalIPAddress'
net.cpp:(.text+0x50bc): undefined reference to `strupnperror'
net.cpp:(.text+0x513c): undefined reference to `UPNP_AddPortMapping'
net.cpp:(.text+0x516e): undefined reference to `freeUPNPDevlist'
net.cpp:(.text+0x5180): undefined reference to `FreeUPNPUrls'
net.cpp:(.text+0x520d): undefined reference to `UPNP_DeletePortMapping'
net.cpp:(.text+0x522b): undefined reference to `freeUPNPDevlist'
net.cpp:(.text+0x5239): undefined reference to `FreeUPNPUrls'
collect2: ld returned 1 exit status
make: *** [primeminer] Error 1
- How often - or at what amount of XPM - does the pool payout?
-
@EnJoyThis
* You need to show/monitor one more line, it's either "SHARE" or "REJECTED"
* Those particular stats you are looking at are history after new payout system, you should see under them your shares, if they are accepted.
@Sy
These error are due to upnp support being enabled, seems you don't have the library for it.
Either install upnp on the system, or disable upnp on build
make -f makefile.unix USE_UPNP=- primeminer
-
Also, after what x amount of time or x amount of coins mined do I get a payout in my primecoin wallet?
I think all payments are on hold for about another day...
other question what is with the coins what was mine and was not pay out?
like i said before:
the blocks from the old payout system will be executed once they are confirmed by the primecoin network
just like they were paid before the cppsrb update (this will take ~2.5 days for all remaining/needed confirmations)
the new payout system will kick in once the confirmations are through from now on
expect the first payout for the new cppsrb system in ~2.6 days (+ some delay due to monitoring setup)
- xolokram
-
How often - or at what amount of XPM - does the pool payout?
You get paid after you reach 3 xpm. Then it takes 3200 confirmations to actually receive payout.
- my first 2 minutes using v6 RC1.
(http://img842.imageshack.us/img842/8302/ru85.jpg)
-
@Sy
These error are due to upnp support being enabled, seems you don't have the library for it.
Either install upnp on the system, or disable upnp on build
make -f makefile.unix USE_UPNP=- primeminer
You were correct, added the flags and it compiled just fine - now i have to figure out why my numbers are so low...yield has halfed -.-
"payout_current": 0.000559482990581672,
"payout_pps": 0.0012050479973220861,
-
now i have to figure out why my numbers are so low...yield has halfed -.-
"payout_current": 0.000559482990581672,
"payout_pps": 0.0012050479973220861,
Halfed or Doubled?
I thought we were now using the pps system. That's how I read it anyway.
- I have mined with 0.6RC1 for more than a day on several machines and got
264 7chains
16 8chains
1 9chain (a block found 15min after I started miners)
The ratios don't look quite right.
-
now i have to figure out why my numbers are so low...yield has halfed -.-
"payout_current": 0.000559482990581672,
"payout_pps": 0.0012050479973220861,
Halfed or Doubled?
I thought we were now using the pps system. That's how I read it anyway.
My XYPM/d went down significantly so i guess halfed ^^ i updated all machines (5) to 0.6 today (from 0.4 / 0.5), let's see if that changes anything.
Something with the fee seems to be off too
2013-10-14 08:13:13 reward: 0.00394 fee: 0.00008 details
> 2013-10-14 08:11:53 reward: 0.00390 fee: 0.00012 detailsI get a fraction more and pay less fee? ^^
- @Sy
You don't read the forum :D
Some tweaked miners were out there the last couple days before new payout was implemented, they submitted a lot of short chains, decreasing block rate (so decreasing share payout) and also hitting hard on the server increasing reject rates so decreasing payouts even more, the last day I was getting like 50-60% rejects.
Now 6 chains aren't counted at all, v0.6 doesn't even send them, and you should get more payout than before.
-
@Sy
You don't read the forum :D
Some tweaked miners were out there the last couple days before new payout was implemented, they submitted a lot of short chains, decreasing block rate (so decreasing share payout) and also hitting hard on the server increasing reject rates so decreasing payouts even more, the last day I was getting like 50-60% rejects.
Now 6 chains aren't counted at all, v0.6 doesn't even send them, and you should get more payout than before.
True i just skimmed over it, i read that 6th dont get submitted anymore - payouts are still strange
http://beeeeer.org/user/AbB7cgdEXr3hJ254qFW1QqAecLGfW9XyGU
it's either 0.0039 or 0.04 - shouldnt they all be pretty equal since it's counting over the last blocks?
> 2013-10-14 10:42:00 reward: 0.04047 fee: 0.00125 details
> 2013-10-14 10:33:39 reward: 0.00389 fee: 0.00012 details
- 0.003 account for a 7-chain.
0.04 account for an 8-chain.
and 0.5 account for a 9-chain.
Here are your current stats
Run Time: 38:24:37
Total Shares: 508
Shares/Hour: 13.2256
7: 457 (89.9606%) __ [90.0901%]
8: 42 (8.26772%) __ [9.00901%]
9: 9 (1.77165%) ^^ [0.9009%]
Total Reward: 7.9276, Fees: 0.16591
XPM/day: 4.95342
XPM/share: 0.0156055
-
0.003 account for a 7-chain.
0.04 account for an 8-chain.
and 0.5 account for a 9-chain.
Here are your current stats
Run Time: 38:24:37
Total Shares: 508
Shares/Hour: 13.2256
7: 457 (89.9606%) __ [90.0901%]
8: 42 (8.26772%) __ [9.00901%]
9: 9 (1.77165%) ^^ [0.9009%]
Total Reward: 7.9276, Fees: 0.16591
XPM/day: 4.95342
XPM/share: 0.0156055
Neat, guess it's time to get my stats going again ^^ damn doctrine orm is messing with me -.-
- Maybe someone is interested.
The preparation of statistics in cacti run more or less the little script
"echo-n" xpm: `curl-s http://www.beeeeer.org/user/YOUR_ADRES | html2text | awk '{print $ 5}' | sed '/ ^ $ / d' | awk '{sum + = $ 1 } END {printf (sum)} '`"
Cati draws a nice graph on which you can clearly see the value received.
-
"echo-n" xpm: `curl-s http://www.beeeeer.org/user/YOUR_ADRES | html2text | awk '{print $ 5}' | sed '/ ^ $ / d' | awk '{sum + = $ 1 } END {printf (sum)} '`"
Nice one! thks
-
Hi,
the web frontend is not 100% ready yet and since the old payout system is not 100% done with all confirmations yet (if i calculated correctly), we have 2 statistics shown on the web frontend (in the user stats). the upper part is from the old payout system (which is not active any longer, except for the pending payouts). the lower part are the stats / upcoming payouts for the new payout system (if you're new mining on beeeeer, look here!).
once the first confirmations are through and i have the time (which is a problem for the next days, i'll try my best) to monitor everything i will start to execute the payout script for the new payout system and you should see your payouts via the PPS payout system.
Some tweaked miners were out there the last couple days before new payout was implemented, they submitted a lot of short chains, decreasing block rate (so decreasing share payout) and also hitting hard on the server increasing reject rates so decreasing payouts even more, the last day I was getting like 50-60% rejects.
Now 6 chains aren't counted at all, v0.6 doesn't even send them, and you should get more payout than before.
this! thanks hawas
As far as i know: Sy's stats page is not ready for the new payout system too!!!
I have to give him special access to some of the stats (aka a proper API)
Also, for the new PPS system the reward value fluctuates due to difficulty fluctuation of the primecoin network.
And for simplification the new payout system groups all your submitted shares by time intervals (currently ~20 seconds). if you submit e.g. one 6-chain share within interval X and two 6-chain shares in interval Y you will recieve approximately 2 times the reward for interval Y than for X.
all i can say right now is: please be patient
- xolokram
ps. i should start writing my posts in 20 pt font size so that everyone reads it and doesnt panic :D
pps. thanks fenix79 for the command
ppps. we hit 10k workers last night and everything is still running, i'm kinda proud :)
pppps. it's good to see, that we're back at <300 seconds per block
- Addresses are case sensitiv right? Because if they are, someone out there configured one miner wrong ;D
I had an import error all the time because i set addresses to be unique, looks like mysql doesnt check cases though so this always returned a mysql error but went straight through my PHP check - anyway - whoever is mining with either of these addresses, you better check which one is correct and change the batch - i would say the chance that both are valid is PRETTY slim :)
AXqtznv3daELfDqdNu6FESApCpqHK3LfRr
AXqtznv3daElfDqdNu6FESApCpqHK3lfRr
- So just to clarify....
my account that was active only after the new payout system will say:
""payout_current": 0,
"payout_pps": 0,
"shares": 0,
"blocks": 0,
"shares_per_block": 0"
with only the all the submitted shares below that read like
"2013-10-14 14:51:15 reward: 0.00397 fee: 0.00012"
until the new payout system goes into effect of which I will paid for all my shares found in the meantime?
If so you should probably take a second and add a little post to the beeeeer.org homepage saying so
-
...
exactly
-
Maybe someone is interested.
The preparation of statistics in cacti run more or less the little script
"echo-n" xpm: `curl-s http://www.beeeeer.org/user/YOUR_ADRES | html2text | awk '{print $ 5}' | sed '/ ^ $ / d' | awk '{sum + = $ 1 } END {printf (sum)} '`"
Cati draws a nice graph on which you can clearly see the value received.
If you want to graph your FEE also change $5 to $7
- thanks for this info. about cacti. i'was install it and it is up and runing. but i'dont know this cacti befor. maybe you can little bit explain how to use it. and create this graph? for, example with a small video? maybe you can export a template for use? i'think this is the most easy.
- If do you want to reward and fee on a single chart
you can do so
echo -n `curl -s http://ww.beeeeer.org/user/YOUR_ADDRES | html2text | awk '{print$5" "$7}' | sed '/^$/d' | awk '{sum+=$1; sum2+=$2}END{print "reward:" sum" fee:" sum2}'`
Reward only
(http://img4.imageshack.us/img4/927/u2j6.png)
If you are interested I can do a tutorial tomorrow.
- yes look nice ... i'have interess ... maybe, i'f i know later little bit more about this cacti ... i can do more with this ... in my network.
thx ... i'wait ... you howto ... for beeeer.org
- Hi all,
i just wanted to let you all know:
I'll bundle all remaining payouts from the old payout system to one large last payout!
- xolokram
-
Maybe someone is interested.
The preparation of statistics in cacti run more or less the little script
"echo-n" xpm: `curl-s http://www.beeeeer.org/user/YOUR_ADRES | html2text | awk '{print $ 5}' | sed '/ ^ $ / d' | awk '{sum + = $ 1 } END {printf (sum)} '`"
Cati draws a nice graph on which you can clearly see the value received.
Damn, we really are a geek community. Very nice command fenix79 (thumbs up).
- i fu**ed up (read: "added" a bug in...) the web frontend, it's currently not restarting properly >:(
i'll try to fix this asap
i'm sorry about this
your payouts are safe - no panic
- No need to apologise Xolokram.
You've said right from the outset that this is a beta pool and to expect some rough edges.
-
Was Bored so i wrote some ugly code to parts stats:
cat stats.sh
TODAY=`date +"%Y-%m-%d"`
YD=`date +"%Y-%m-%d" --date="-1 day"`
DB=`date +"%Y-%m-%d" --date="-2 day"`
curl -s http://www.beeeeer.org/user/YOURID | html2text >/tmp/statsfile
head -30 /tmp/statsfile
echo ""
echo -n "TOTAL XPM: `cat /tmp/statsfile | awk '{print $5}' | sed '/ ^ $ / d' | awk '{sum +=$1} END {printf (sum)} '`"
echo ""
echo -n "TOTAL FEE: `cat /tmp/statsfile | awk '{print $7}' | sed '/ ^ $ / d' | awk '{sum +=$1} END {printf (sum)} '`"
#
echo ""
echo ""
echo "XPM/D Totals"
echo -n "$TODAY XPM/D: `grep "$TODAY" /tmp/statsfile | awk '{print $5}' | sed '/ ^ $ / d' | awk '{sum +=$1} END {printf (sum)} '`"
echo ""
echo -n "$TODAY SHARES/D: `grep "$TODAY" /tmp/statsfile | wc -L`"
echo ""
echo ""
#
echo -n "$YD XPM/D: `grep "$YD" /tmp/statsfile | awk '{print $5}' | sed '/ ^ $ / d' | awk '{sum +=$1} END {printf (sum)} '`"
echo ""
echo -n "$YD SHARES/D: `grep "$YD" /tmp/statsfile | wc -L`"
echo ""
echo ""
#
echo -n "$DB XPM/D: `grep "$DB" /tmp/statsfile | awk '{print $5}' | sed '/ ^ $ / d' | awk '{sum +=$1} END {printf (sum)} '`"
echo ""
echo -n "$DB SHARES/D: `grep "$DB" /tmp/statsfile | wc -L`"
echo ""
Results, building on the other examples:
./stats.sh
{
"address": "YOURID",
"payout_current": 0.0004952090651828521,
"payout_pps": 0.0010210082970160742,
"shares": 27092,
"blocks": 500,
"shares_per_block": 54.184,
"details": {
"6": 0.906208474826517,
"7": 0.08493282149712092,
"8": 0.008231212165953048,
"9": 0.0006274915104089768
}
}
> 2013-10-14 20:23:06 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:22:06 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:20:46 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:15:46 reward: 0.00776 fee: 0.00024 details
> 2013-10-14 20:13:46 reward: 0.50008 fee: 0.01547 details
> 2013-10-14 20:12:05 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:09:25 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:09:05 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:08:05 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:06:05 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 20:02:05 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 19:59:45 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 19:58:05 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 19:57:25 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 19:56:05 reward: 0.00388 fee: 0.00012 details
> 2013-10-14 19:55:45 reward: 0.00776 fee: 0.00024 details
TOTAL XPM: 31.8281
TOTAL FEE: 0.98195
XPM/D Totals
2013-10-14 XPM/D: 13.4827
2013-10-14 SHARES/D: 70
2013-10-13 XPM/D: 15.5362
2013-10-13 SHARES/D: 100
2013-10-12 XPM/D: 2.80919
2013-10-12 SHARES/D: 10
- watch out for block #209974 (http://xpm.cryptocoinexplorer.com/block/209974)
(it's the block with the last payout from the old payout system)
- "POOL MAINTENANCE - DONT PANIC"
too late! D:
-
"POOL MAINTENANCE - DONT PANIC"
too late! D:
;D
I'm not panicking, but have really caught the mining bug these last couple of days, so can't wait for it to be back up.
-
watch out for block #209974 (http://xpm.cryptocoinexplorer.com/block/209974)
(it's the block with the last payout from the old payout system)
Good stuff.
Any ETA on when payments will first go out from the new system?
Thanks for all your hard work :)
-
0.003 account for a 7-chain.
0.04 account for an 8-chain.
and 0.5 account for a 9-chain.
For the non-technical users like me let's see if I can make sense of this. Please be patient...
> 2013-10-14 16:47:36 reward: 0.00393 fee: 0.00008 details
> 2013-10-14 16:47:16 reward: 0.04080 fee: 0.00083 details
> 2013-10-14 16:46:36 reward: 0.01178 fee: 0.00024 details
> 2013-10-14 16:46:16 reward: 1.02028 fee: 0.02082 details
In line 1 I found a 7-chain.
In line 2 I found an 8-chain
In line 3 I found 3 7-chains?
In line 4 I found 2 9-chains?
It seems clear each line is not a share. It doesn't look like a block either. It does however look like a time interval of 20 seconds, with the gaps indicating intervals I found nothing; am I even close?
Oh an BTW I did read all the posts, although I freely admit I did not understand quite a few of them...
"The truly ignorant man is the one who refuses to admit his ignorance and learn"
-
i figured out, that the web frontend has problems restarting, because there are accesses on pages who need information which are not loaded fast enough.
it's currently restarting, but it seems to be quite slow ... give it some time.
and it crashed again ... sh**
@icedaddy:
It seems clear each line is not a share. It doesn't look like a block either. It does however look like a time interval of 20 seconds, with the gaps indicating intervals I found nothing; am I even close?
that's pretty much it. you're right.
@Scott J:
the first confirmed block using the new payout system should roll in right now (or is already confirmed), i would love to run the payout script asap, but the problem is, it's almost midnight here and i have to get up early tomorrow. if there is a problem i would stay up all night just to fix it (even if it takes hours) --- but this will propably ruin my day tomorrow, which isn't really an option :D i will delay the first payout for tomorrow evening, when i have the time to monitor everything. if everything works as intented i'll run the script periodically without monitoring and everything should be fine from then on. future: the next step would be an API to allow Sy (or whoever wants to do something similiar) to build a new and eye-candy-esque stats page.
- xolokram
-
Ive been testing this new 0.6 beta, but my rejects are still almsot 10%. CPU is a i7 2600k and im on US West Coast (might be related to lag?)
Heres the output of almost 29 hours of running this on a Win8 64bit box
********************************************
*** running time: 28.899hrs
***
*** 7-chains: 214 (91.064% | 7.405/hr)
*** 8-chains: 20 (8.511% | 0.692/hr)
***
*** valid: 235 (91.440%)
*** rejects: 22 (8.560%)
*** stale: 0 (0.000%)
********************************************
Everyone stats are similar on the % of rejects, or its more likely something bad on my end??
- ok, i fixed it (the web frontend). i hope it won't crash again!!
don't be confused: within the first X minutes it needs some time to catch up with the most recent shares in the share-log.
it crashed before, because it tried to load the whole data at once. sorry, my mistake.
ok, now it's really late, i will go to bed now...
@Jabroni:
your location could be a problem, but during the night hours (location: germany), there's a lot of workload and some people are still using the v0.5 miners which causes extra workload for the server. i will try to reduce the rejects problem once the payout script for the new payout system is running.
- xolokram
-
Hi all,
i just wanted to let you all know:
I'll bundle all remaining payouts from the old payout system to one large last payout!
- xolokram
I'm missing ~8.5% of earnings from the old payout system (received the big last one).
Is this due to orphan blocks which were/are credited wrongly with Sy's stats?
Can you confirm an "orphan block rate" of ~8.5% (2013-10-12 till 2013-10-14)?
Thank you.
- Just a little trick if you have multiple miners ...
Because the current user stats page lists fee, and the fee for every round is about the same and can be set on the miner command line (-poolfee=x), you can set your fees to different percentage for different miner, so that by looking at the fees you know which share was produced by which miner.
You can also use it to monitor the health and productivity of each miner.
-
...
From the 5861 found blocks 121 are orphans (around 2%).
I don't know if Sy's stats counted everything correctly, he said in his thread it's just an estimation, because his payout barrier calculation differs from the original one & maybe he's missing some fees or orphans. I can't really judge that. If somethings missing, please refer to blocks/payouts on beeeeer.org, i'm not responsible for Sy's stats. Is someone in a similiar situation?
I'll be back later today.
the miner id stats are coming soon. :)
- xolokram
-
...
From the 5861 found blocks 121 are orphans (around 2%).
I don't know if Sy's stats counted everything correctly, he said in his thread it's just an estimation, because his payout barrier calculation differs from the original one & maybe he's missing some fees or orphans. I can't really judge that. If somethings missing, please refer to blocks/payouts on beeeeer.org, i'm not responsible for Sy's stats. Is someone in a similiar situation?
I'll be back later today.
the miner id stats are coming soon. :)
- xolokram
Orphans are all correct but i didn't factor in fees.
I've put the site offline for now, waiting for the new data - the old one got paid anyway so it's obsolete.
-
the miner id stats are coming soon. :)
- xolokram
Great news! Keep it up :)
-
Ive been testing this new 0.6 beta, but my rejects are still almsot 10%. CPU is a i7 2600k and im on US West Coast (might be related to lag?)
Heres the output of almost 29 hours of running this on a Win8 64bit box
********************************************
*** running time: 28.899hrs
***
*** 7-chains: 214 (91.064% | 7.405/hr)
*** 8-chains: 20 (8.511% | 0.692/hr)
***
*** valid: 235 (91.440%)
*** rejects: 22 (8.560%)
*** stale: 0 (0.000%)
********************************************
Everyone stats are similar on the % of rejects, or its more likely something bad on my end??
Hi,
how to see this stats?
-
how to see this stats?
Hit Ctrl+C to shutdown your miner. These stats will show up then.
-
Thanks,
it works
********************************************
*** running time: 19.091hrs
***
*** 7-chains: 63 (86.301% | 3.300/hr)
*** 8-chains: 9 (12.329% | 0.471/hr)
*** 9-chains: 1 (1.370% | 0.052/hr)
***
*** valid: 73 (86.905%)
*** rejects: 11 (13.095%)
*** stale: 0 (0.000%)
********************************************
- hi,
i just wanted to let you all know that i added some pages (e.g. CPPSRB payouts (it's empty currently, but this will change)) and changed some parts in the user stats. i think this will break some of the commands posted earlier, sorry.
anyway, please be aware that the sharelog information is not loaded all at once at a restart, the web frontend needs some time to catch up with the most recent data. :o
- xolokram
ps. uhm yes ... how's the weather?
pps. i'm know the rejection rate is annoying, i'll try to fix/workaround this asap --- payouts & stats API first...
ppps. please report every bug / mistake / mysterious behavior :)
- xolo, you're doing a wonderful job bro...major props.
What's the default fee set at? I can modify it with the fee value in the miner config right?
Can I direct your attention to the support thread? Was having some trouble updating...sorry if it's too noob of a mistake.
- default is 3%
the parameter is: -poolfee=<value>
<value> in percent
e.g. -poolfee=50
would be 50% of your share reward to the pool (RECOMMENDED!) ;D
i'll check the tech support later today, i've to get some other stuff done right now, sorry.
- xolokram
-
default is 3%
the parameter is: -poolfee=<value>
<value> in percent
e.g. -poolfee=50
would be 50% of your share reward to the pool (RECOMMENDED!) ;D
i'll check the tech support later today, i've to get some other stuff done right now, sorry.
- xolokram
Thanks again...my issue is probably a beginner's mistake when compiling. Can't get it to produce the latest version binaries and instead I get 0.4.
-
I have mined with 0.6RC1 for more than a day on several machines and got
264 7chains
16 8chains
1 9chain (a block found 15min after I started miners)
The ratios don't look quite right.
Now it has been 2 days and 9 hours on my two win7 i5 and one win8 Xeon machines. In total I get
445 7chains
32 8chains
1 9chain
I am getting far less long chains compared with 7-chains. At this rate the per-day reward isn't better than that on ypool at all. If there had been 44 8-chains and 4 9-chains, as suggested by the number of 7-chains, the reward rate would improve by 50%. That is before correcting for ~10% rejection rate.
I see others can get 9s just fine. I am going to restart all my miners to see what comes out of it. If it doesn't help, I will have to wait for a new version of miner to mine at beeeeer.
By the way I am using port 13337 because 1337 doesn't work here.
-
I have mined with 0.6RC1 for more than a day on several machines and got
264 7chains
16 8chains
1 9chain (a block found 15min after I started miners)
The ratios don't look quite right.
Now it has been 2 days and 9 hours on my two win7 i5 and one win8 Xeon machines. In total I get
445 7chains
32 8chains
1 9chain
I am getting far less long chains compared with 7-chains. At this rate the per-day reward isn't better than that on ypool at all. If there had been 44 8-chains and 4 9-chains, as suggested by the number of 7-chains, the reward rate would improve by 50%. That is before correcting for ~10% rejection rate.
I see others can get 9s just fine. I am going to restart all my miners to see what comes out of it. If it doesn't help, I will have to wait for a new version of miner to mine at beeeeer.
By the way I am using port 13337 because 1337 doesn't work here.
try my build, link posted above :)
on 24 core opteron (which is 2.5 3 times of my i7) :
Found Chain statistics:
5er chains 42791 4194.0539 ch/h
6er chains 4439 435.0776 ch/h
7er chains 454 44.4977 ch/h
8er chains 42 4.1165 ch/h
9er chains 2 0.1960 ch/h
10er chains 1 0.0980 ch/h
runtime 16 hours
After restart :
--------------------------------------------------------------------------------
2013-10-15 14:51:51 primemeter 2717.6852*10^9 number tests/h
Found Chain statistics:
5er chains 10320 4151.5253 ch/h
6er chains 1082 435.2665 ch/h
7er chains 113 45.4576 ch/h
8er chains 16 6.4365 ch/h
9er chains 1 0.4023 ch/h
--------------------------------------------------------------------------------
********************************************
*** running time: 2.475hrs
***
*** 7-chains: 94 (88.679% | 37.984/hr)
*** 8-chains: 11 (10.377% | 4.445/hr)
*** 9-chains: 1 (0.943% | 0.404/hr)
***
*** valid: 106 (82.171%)
*** rejects: 23 (17.829%)
*** stale: 0 (0.000%)
********************************************
a lot of rejects welll
-
I have mined with 0.6RC1 for more than a day on several machines and got
264 7chains
16 8chains
1 9chain (a block found 15min after I started miners)
The ratios don't look quite right.
Now it has been 2 days and 9 hours on my two win7 i5 and one win8 Xeon machines. In total I get
445 7chains
32 8chains
1 9chain
I am getting far less long chains compared with 7-chains. At this rate the per-day reward isn't better than that on ypool at all. If there had been 44 8-chains and 4 9-chains, as suggested by the number of 7-chains, the reward rate would improve by 50%. That is before correcting for ~10% rejection rate.
I see others can get 9s just fine. I am going to restart all my miners to see what comes out of it. If it doesn't help, I will have to wait for a new version of miner to mine at beeeeer.
By the way I am using port 13337 because 1337 doesn't work here.
try my build, link posted above :)
on 24 core opteron (which is 2.5 3 times of my i7) :
Found Chain statistics:
5er chains 42791 4194.0539 ch/h
6er chains 4439 435.0776 ch/h
7er chains 454 44.4977 ch/h
8er chains 42 4.1165 ch/h
9er chains 2 0.1960 ch/h
10er chains 1 0.0980 ch/h
runtime 16 hours
After restart :
--------------------------------------------------------------------------------
2013-10-15 14:51:51 primemeter 2717.6852*10^9 number tests/h
Found Chain statistics:
5er chains 10320 4151.5253 ch/h
6er chains 1082 435.2665 ch/h
7er chains 113 45.4576 ch/h
8er chains 16 6.4365 ch/h
9er chains 1 0.4023 ch/h
--------------------------------------------------------------------------------
********************************************
*** running time: 2.475hrs
***
*** 7-chains: 94 (88.679% | 37.984/hr)
*** 8-chains: 11 (10.377% | 4.445/hr)
*** 9-chains: 1 (0.943% | 0.404/hr)
***
*** valid: 106 (82.171%)
*** rejects: 23 (17.829%)
*** stale: 0 (0.000%)
********************************************
a lot of rejects welll
P.P.S. i'm using larger sieve here (8192000) not default in my build 4096000 and primorial 37
- grom, can you do me a favor and start your own thread for your miner?
btw. is you project/miner open source? any source code available somewhere?
@mhps:
the chain distribution is not always 10% of the previous shorter chain-length shares, there's a drop from 8 to 9 (and probably from 9 to 10 and from 10 to 11 etc. pp.)
don't expect four (which is a wrong assumption anyway) 9-chains just because you have 400 7-chains
and like i said before: i'm aware of the rejection problems, please let me repair/add one feature at a time.
- xolokram
-
Stats information, i5-3570K stock, 4 Threads
********************************************
*** running time: 34.807hrs
***
*** 7-chains: 279 (90.584% | 8.016/hr)
*** 8-chains: 27 (8.766% | 0.776/hr)
*** 9-chains: 2 (0.649% | 0.057/hr)
***
*** valid: 308 (93.617%)
*** rejects: 21 (6.383%)
*** stale: 0 (0.000%)
********************************************
6.3% rejects with v0.6 from Germany - Xolo are those numbers interesting or do you check all that stuff serverside anyway?
-
hi,
i just wanted to let you all know that i added some pages (e.g. CPPSRB payouts (it's empty currently, but this will change)) and changed some parts in the user stats. i think this will break some of the commands posted earlier, sorry.
anyway, please be aware that the sharelog information is not loaded all at once at a restart, the web frontend needs some time to catch up with the most recent data. :o
- xolokram
It would be really helpful if you could have a current reward total displayed for pending shares.
-
i think this will break some of the commands posted earlier, sorry.
no problem
echo -n "xpm:`curl -s http://www.beeeeer.org/user/APiBoeLUpDSdyZNZ1SrttbVHRPrGLGeyMn | html2text | egrep "[0-9]{4}-[0-9]{2}-[0-9]{2}\s[0-9]{2}:[0-9]{2}:[0-9]{2}\sreward" | awk '{print$5}' | sed '/^$/d' | awk '{sum+=$1}END{printf (sum)}'`"
-
It would be really helpful if you could have a current reward total displayed for pending shares.
I agree. Getting kinda antsy waiting on some stats other than zeros
- @Boyers Remorse + Scott J:
this could help (http://www.amazon.com/Patience-Art-Peaceful-Living-ebook/dp/B005ERIKI8).
@fenix79:
thank you.
@Sy:
thank you, i have the stats from the time of the old payout system regarding the chain-length distribution.
for the new payout system most of the stats are still not coded yet.
- xolokram
-
@Boyers Remorse + Scott J:
this could help (http://www.amazon.com/Patience-Art-Peaceful-Living-ebook/dp/B005ERIKI8).
I tried to buy that but Amazon cancelled the order as I kept sending threatening e-mails to customer support asking when it would be dispatched.
-
...
;)
-
Hi all,
i just wanted to let you all know:
I'll bundle all remaining payouts from the old payout system to one large last payout!
- xolokram
Is this still the plan?
I have received nothing since I upgraded my miners; they say they are submitting shares and on the user stats page under "NEW PAYOUT SYSTEM" I see shares accumulating so I assume my miners are working properly?
- read properly
- Trying Groms miner for the last 2 hours 17% rejects xolos miner only 6-7% strange!
However I submitted a 9 share that was accepted but not shown up in my stats page!!
********************************************
*** running time: 2.211hrs
***
*** 7-chains: 21 (87.500% | 9.499/hr)
*** 8-chains: 2 (8.333% | 0.905/hr)
*** 9-chains: 1 (4.167% | 0.452/hr)
***
*** valid: 24 (82.759%)
*** rejects: 5 (17.241%)
*** stale: 0 (0.000%)
********************************************
> 2013-10-15 18:09:28 reward: 0.00386 fee: 0.00012 details> 2013-10-15 18:06:08 reward: 0.04007 fee: 0.00124 details> 2013-10-15 18:01:48 reward: 0.04007 fee: 0.00124 details> 2013-10-15 18:00:28 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:59:28 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:56:48 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:53:48 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:51:28 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:50:28 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:29:47 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:21:27 reward: 0.04008 fee: 0.00124 details> 2013-10-15 17:18:47 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:15:46 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:12:46 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:11:26 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:08:26 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:03:46 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:03:06 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:01:46 reward: 0.00386 fee: 0.00012 details> 2013-10-15 17:01:06 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:59:46 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:59:26 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:57:06 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:50:46 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:45:26 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:40:45 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:28:25 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:27:45 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:26:25 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:24:25 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:16:04 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:15:44 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:04:24 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:04:04 reward: 0.00386 fee: 0.00012 details> 2013-10-15 16:01:03 reward: 0.00386 fee: 0.00012 details> 2013-10-15 15:56:23 reward: 0.00386 fee: 0.00012
Very strange!!
-
if it's true what you're saying than we may have a real problem here. I PM'd you.
Is someone else noticing similiar behavior? With my miner? With Grom's miner?
I don't know what grom has changed in the source code, since it doesn't seem to be open source.
/edit:
maybe his chain stats don't care about valid or rejected, thus he says you've found a 9-chain, but it got rejected!?
sure, that's really bad luck, but it's not impossible.
ok, sorry, that was just bogus.
do you have the complete log file of your miner's output?
- xolokram
- > 2013-10-15 18:44:10 reward: 0.00386 fee: 0.00012 details
> 2013-10-15 18:41:30 reward: 0.00386 fee: 0.00012 details
> 2013-10-15 18:33:09 reward: 0.00386 fee: 0.00012 details
> 2013-10-15 18:23:49 reward: 0.00386 fee: 0.00012 details
> 2013-10-15 18:13:29 reward: 0.00771 fee: 0.00024 details
2013-10-15 18:50:14 primemeter 1918.2240*10^9 number tests/h
Found Chain statistics:
5er chains 2961 1032.1069 ch/h
6er chains 284 98.9930 ch/h
7er chains 29 10.1084 ch/h
8er chains 2 0.6971 ch/h
Only one 8er chains in stat. i use Grom's miner.
I have now 3-8er :
********************************************
*** running time: 2.908hrs
***
*** 7-chains: 27 (93.103% | 9.285/hr)
*** 8-chains: 2 (6.897% | 0.688/hr)
***
*** valid: 29 (93.548%)
*** rejects: 2 (6.452%)
*** stale: 0 (0.000%)
********************************************
Probable prime chain found for block=1628dba0aaf5a412d0891e6d3cc252ac3b24ce6ca6
4dc0228297e5499277743!!
Target: 09.eaa862
Chain: 2CC08.9a4fcd
[MASTER] submitted share -> SHARE
*** running time: 2.977hrs
***
*** 7-chains: 28 (90.323% | 9.406/hr)
*** 8-chains: 3 (9.677% | 1.008/hr)
***
*** valid: 31 (93.939%)
*** rejects: 2 (6.061%)
*** stale: 0 (0.000%)
********************************************
Where my two 8er chains in pool stats.Maybe this truble after maintance?
@Last my stat in miner:
Probable prime chain found for block=63fffc4744d21fdbc1d3f362650d4d082340b087b28
4f4809c1b0f1d5cf67253!!
Target: 09.eab4f5
Chain: TWN08.8a7947
[MASTER] submitted share -> SHARE
[MASTER] work received
********************************************
*** running time: 3.452hrs
***
*** 7-chains: 30 (85.714% | 8.691/hr)
*** 8-chains: 5 (14.286% | 1.449/hr)
***
*** valid: 35 (92.105%)
*** rejects: 3 (7.895%)
*** stale: 0 (0.000%)
- Why would people use Grom's miner?
- I don't know, he was promoting it as the superior miner (performance-wise).
can somebody confirm the same issues with my miner??? this is important!
@voffka05+everybody else with problems with grom's miner:
can you PM me your payout address???
/edit1:
mphfgrrlllll it's getting really late again and i actually wanted to finish/run the payout script ...............
/edit2:
"grom" is online here, but he's seems to be a quiet kind of guy.
- xolokram
-
I don't know, he was promoting it as the superior miner (performance-wise).
can somebody confirm the same issues with my miner??? this is important!
@voffka05+everybody else with problems with grom's miner:
can you PM me your payout address???
/edit:
mphfgrrlllll it's getting really late again and i actually wanted to finish/run the payout script ...............
- xolokram
I don't think it's problem with your miner/pool script, my miner donating some CPU time to support me, this could be some shares didn't showed
-
my miner donating some CPU time to support me, this could be some shares didn't showed
and you wanted to tell this when exactly???
-
my miner donating some CPU time to support me, this could be some shares didn't showed
Wow... Time to switch all my Windows rigs back to Xolo's. I was testing yours out, and now I'm done.
-
my miner donating some CPU time to support me, this could be some shares didn't showed
Wow... Time to switch all my Windows rigs back to Xolo's. I was testing yours out, and now I'm done.
yeah, seriously, not cool bro.
Open source or GTFO.
- To Grom :
how much is your miner takes you our resources?
- i'll add an announcement to the web interface (frontend restart incoming)
@grom:
you should've said that from the get go or make it open source for donations
instead of this crap!
btw. where's the guy who was talking about grom's great reputation and "talent"? >:(
-
my miner donating some CPU time to support me, this could be some shares didn't showed
and you wanted to tell this when exactly???
Now ? i'm sorry should i make this as option ?
i think cause it's 75% faster as normal hp11 code you are using in your miner i diserve some support ?
-
To Grom :
how much is your miner takes you our resources?
i think 15-20% of time it sends shares to my acc.
-
i'll add an announcement to the web interface (frontend restart incoming)
@grom:
you should've said that from the get go or make it open source for donations
instead of this crap!
btw. where's the guy who was talking about grom's great reputation and "talent"? >:(
No idea how to do this can you help ?
-
use the "edit" button, please
i think 15-20% of time it sends shares to my acc.
is 15 or 20? or maybe 30 or just 5?
Now ? i'm sorry should i make this as option ?
i think cause it's 75% faster as normal hp11 code you are using in your miner i diserve some support ?
By "Now" you mean "3 days later" aka "1000 blocks later", right?
In my opinion: you deserve nothing at all! But that's just my 2 cents.
-
use the "edit" button, please
i think 15-20% of time it sends shares to my acc.
is 15 or 20? or maybe 30 or just 5?
Now ? i'm sorry should i make this as option ?
i think cause it's 75% faster as normal hp11 code you are using in your miner i diserve some support ?
By "Now" you mean "3 days later" aka "1000 blocks later", right?
In my opinion: you deserve nothing at all! But that's just my 2 cents.
<= 20% as i said
- Thanks for the info xolo!
Looks like Grom stole my 9 share, which in book makes him a thief!
- Grom=Гром(Russian). Холо,говорит что исходники майнеров у всех в открытом доступе!Заплатить сумму донаты это одно,а вот предупредить о том что используются наши ресурсы стоило бы.
-
Thanks for the info xolo!
Looks like Grom stole my 9 share, which in book makes him a thief!
it bruoght you +75% and just removed 9 what does that mean.
-
Grom=Гром(Russian). Холо,говорит что исходники майнеров у всех в открытом доступе!Заплатить сумму донаты это одно,а вот предупредить о том что используются наши ресурсы стоило бы.
I'm sory i didn't mentioned that ... i'll make it's as an option and notice in readme
aswell i'll change default settings of miner to comparable defaults on Xolominer... So everyone can notice how it performs.
-
my miner donating some CPU time to support me, this could be some shares didn't showed
Wow... Time to switch all my Windows rigs back to Xolo's. I was testing yours out, and now I'm done.
I thought that was pretty obvious. Why would you trust a binary-only miner?
And it could have been worse...
And regardless of source being available, your binary could very well do that; you'd have to compile it yourself.
-
my miner donating some CPU time to support me, this could be some shares didn't showed
Wow... Time to switch all my Windows rigs back to Xolo's. I was testing yours out, and now I'm done.
I thought that was pretty obvious. Why would you trust a binary-only miner?
And it could have been worse...
And regardless of source being available, your binary could very well do that; you'd have to compile it yourself.
Well i'll make things i said if you don't like don't use.
P.S. i'll share source soon but not at this moment, it's not completly ready
-
it bruoght you +75%
can somebody actually confirm this?
i really don't like how you're still promoting you miner with this statement.
/EDIT:
yeah ... great
how should we solve this big clusterf*** now?
we have a lot of payouts now from users who were not aware of your miner's behavior (I'm trying to not use the word scam)
and you're still crying about "donations"
- xolokram
-
Thanks for the info xolo!
Looks like Grom stole my 9 share, which in book makes him a thief!
it bruoght you +75% and just removed 9 what does that mean.
75% more!! do me a favour you take the 9 share out and leave me the rest! I made a mistake but I noticed straight away something was wrong.
I have a reasonabe understanding of how the tune xolos miner for 10 shares so your piece of shit is no great loss!
-
it bruoght you +75% and just removed 9 what does that mean.
It means you stole 0.52249 XPM from him. Do that hundreds of more times (which you did) and you generate quite the profitable scheme.
I thought that was pretty obvious. Why would you trust a binary-only miner?
And it could have been worse...
And regardless of source being available, your binary could very well do that; you'd have to compile it yourself.
I thought it was a bit shady myself. The majority of my rigs are running Linux so I only ran it on a couple workstations just to see how it did.
-
it bruoght you +75%
can somebody actually confirm this?
i really don't like how you're still promoting you miner with this statement.
/EDIT:
yeah ... great
how should we solve this big clusterf*** now?
we have a lot of payouts now from users who were not aware of your miner's behavior (I'm trying to not use the word scam)
and you're still crying about "donations"
- xolokram
for Fast test :
xolominer defaults -sievesize=1000000 -sieveextensions=9 -sievepercentage=15
equealents to my mod : -sievesize=512000 -sieveextensions=10 -primes=1000000 .sievepercentage=15.
As for Algorithmus :
in first sieve miner uses only odd numbers no single even number
the extensions give all even numbers except X*2^Y, where Y is > sieveextensions
That's why Sieveextensions are same as sievesize aswell
result -> more candidates, there are some more performance in caching aswell.
-
read properly
I do, or at least try. Any thoughts on what I read improperly? Or perhaps you meant to say 'understand properly', to which I freely plead guilty to the possibility I did not. Since I can't find the "beeeeer for dummies" thread I am left with trying to wade through many things I do not understand, or misunderstand. I can remain in ignorance or ask questions, sometimes questions you more knowledgeable folk simply roll your eyes at, hoping for answers that enlarge my understanding. Please be patient with us newbies; once upon a time you were a newbie too! :D
-
Thanks for the info xolo!
Looks like Grom stole my 9 share, which in book makes him a thief!
it bruoght you +75% and just removed 9 what does that mean.
75% more!! do me a favour you take the 9 share out and leave me the rest! I made a mistake but I noticed straight away something was wrong.
I have a reasonabe understanding of how the tune xolos miner for 10 shares so your piece of shit is no great loss!
Well if it's problem
give me your xpm address, and time you used myner i'll check it on beer and give you your xpm
- To Xolo :
Grom's miner really faster x2 or x3 .Here's what to do with statistics on the pool ,"thanks" to a super grom's
ingenuity ...
- @grom:
make it open source, provide your information/code to mikaelh's project
take real donations
@icedaddy:
the last payout of the OLD PAYOUT SYSTEM is already through. it was executed yesterday. there are some posts in this thread about it. just check the last payout #206442 on the beeeeer page
the stats on the user's page which state NEW PAYOUT SYSTEM is for the NEW PAYOUT SYSTEM (obviously), it has nothing to do with the last bundled payout of the OLD PAYOUT SYSTEM.
the first payout for the NEW PAYOUT SYSTEM was scheduled for today, but thankfully it is ... delayed ... again ... because we have a very small issue right now (you can read about this in the most recent ~30 posts, or in my signature, or on the beeeeer front page).
i hope i could help you.
- xolokram
ps. i'm tired, this really sucks
- I literally started coin mining this week. Its stuff like this that turns people off of these opportunities. The first night of the new clients release I noticed I finally got a 9 chain,I was stoked, but then it never showed up, I thought well maybe bigger chains take longer..... it never showed up, I even went back and found each of the shares before and after matching it with timestamps.... NOW I KNOW.
Not Cool.
-
Well if it's problem
give me your xpm address, and time you used myner i'll check it on beer and give you your xpm
Гром ты реально не прав, сделал все по скотски, до опубликования исходников никто(в здравом уме) не станет пользоваться твоим майнером. Хоть он в 10 раз быстрее будет.
- @xolokram:
Thank you. The transition from the "old payout system" to the "new payout system" did not happen the way I had expected from reading (but perhaps not understanding) the posts here, and in the places you mentioned (I gather it did not happen quite in the manner you had expected, or at least hoped, either). I was chugging along getting 3.xxx payouts and then suddenly bam! they stopped (Mon Oct 14 07:17:36 PDT 2013); there was no sign of a "bundled payout". Now I know that for a while you indicated you were doing the payouts manually and they were irregular, but never quite like this. Perhaps coincidently the payouts ceased immediately after I upgraded my miners; in reading the posts here I understood that the new miner was working under the "new payout system", but did switching before I got the "bundled payment" mess it up? Do they really have nothing to do with each other? Did I do something wrong when I installed the new miner? Did I miss something somewhere? While there are discussions about the new algorithm, muddled by pato's comments I don't understand and arguments about grom's miner and all sorts of stuff way over my head (no wonder you are tired, and I agree is sucks) are perhaps germane to somebody as a newbie they only confuse me, and consume the bulk of the ~30 posts you indicate.
Thanks to your information I now have the answers to many of my probably simplistic questions. Is the old payout system dead and buried? Yes. Will I see any more payouts from it? No. Does not receiving any payouts on the new payout system mean my miners are broken? Not necessarily. Are my miners working? It would seem so. When will I get payouts again? Not for a while, maybe a few days.
@slash2rustee:
You could not have picked a worse time to get your feet wet; at least I got in a few weeks ago and was in on this roller coaster ride from the beginning. Things were not so chaotic back then, and hopefully will be peaceful again soon. I don't know enough about the old vs the new payout system yet to have an opinion as to its merits, but I can say the last week is not indicative of how this pool has run in the past.
By the "new client" do you mean xolokram's v6 or grom's? I have upgraded to xlokram's v6 (from v4) and to the best of my limited knowledge in interpreting the miner output and the statistics on the website I believe all the 9's I found are accounted for; I can't speak about grom's miner as I have never used it and am not familiar with it. There have been reports in this thread about anomalies in both miners, but I have net seen them.
The old payout system allowed for the extraction of JSON data allowing for monitoring and analysis of data from the pool, hopefully once the dust settles the new payout system will too, and using that I was just getting to the point where I was reasonably comfortable with how things worked, but now it is a whole new ball game.
@grom:
I second what xolokram said about making a new thread for your miner project.
@(Moderators: Excelsior, craslovell):
Move all the ancillary posts to their own threads?
- First off grom is wrong, his program may LOOK faster but it isn't. I just did some tests and not only does it get around a 20% rejection rate (tested on multiple computers and different locations) but it also produces very few candidates further more I literally just found out that he is stealing 20% (supposedly could be more or less we can't be certain)
So in essence grom's miner is slow, over inflates results, steals and shouldn't be used by anyone.
Xolo I think you might wanna include a whitelist for mining programs, I mean someone could easily make a program that DDOsed your site and they could spread it around as a miner or they could just do what grom did and never reveal the whole siphoning part.
Furthermore,
I am led to believe that xolominer is on github (or some equivalent site) thus I suggest that grom submit his changes to their as a contributor. You can keep whatever you earned as long as you open source it and make amends.
-
First off grom is wrong, his program may LOOK faster but it isn't. I just did some tests and not only does it get around a 20% rejection rate (tested on multiple computers and different locations) but it also produces very few candidates further more I literally just found out that he is stealing 20% (supposedly could be more or less we can't be certain)
So in essence grom's miner is slow, over inflates results, steals and shouldn't be used by anyone.
Xolo I think you might wanna include a whitelist for mining programs, I mean someone could easily make a program that DDOsed your site and they could spread it around as a miner or they could just do what grom did and never reveal the whole siphoning part.
Furthermore,
I am led to believe that xolominer is on github (or some equivalent site) thus I suggest that grom submit his changes to their as a contributor. You can keep whatever you earned as long as you open source it and make amends.
It's sadly but it's true it really produces more rejects, it has some bug making submiting sometimes share twice and this is rejected (should be so aswell)
as to it's slow .. well you didn't tested it right ... as always mining primes is really depends on settings ... if someone make mining with primorial "271" it will be finding chains very slow cause of complexity of tests.
-
First off grom is wrong, his program may LOOK faster but it isn't. I just did some tests and not only does it get around a 20% rejection rate (tested on multiple computers and different locations) but it also produces very few candidates further more I literally just found out that he is stealing 20% (supposedly could be more or less we can't be certain)
So in essence grom's miner is slow, over inflates results, steals and shouldn't be used by anyone.
Xolo I think you might wanna include a whitelist for mining programs, I mean someone could easily make a program that DDOsed your site and they could spread it around as a miner or they could just do what grom did and never reveal the whole siphoning part.
Furthermore,
I am led to believe that xolominer is on github (or some equivalent site) thus I suggest that grom submit his changes to their as a contributor. You can keep whatever you earned as long as you open source it and make amends.
It's sadly but it's true it really produces more rejects, it has some bug making submiting sometimes share twice and this is rejected (should be so aswell)
as to it's slow .. well you didn't tested it right ... as always mining primes is really depends on settings ... if someone make mining with primorial "271" it will be finding chains very slow cause of complexity of tests.
I'm testing your settings myself, using the standard xolominer .6...I'll report back in 6 hours to compare to the stock settings.
-
Thanks for the info xolo!
Looks like Grom stole my 9 share, which in book makes him a thief!
it bruoght you +75% and just removed 9 what does that mean.
75% more!! do me a favour you take the 9 share out and leave me the rest! I made a mistake but I noticed straight away something was wrong.
I have a reasonabe understanding of how the tune xolos miner for 10 shares so your piece of shit is no great loss!
Well if it's problem
give me your xpm address, and time you used myner i'll check it on beer and give you your xpm
Look dont even bother! I have no time for you and your scam miner, If you really wanted to take a 15-50% cut let people know beforehand before you release it to the public! if your miner really is 75% better than the current offering then why did you not just take a 3% cut simular to a pool then people could made there own judgement, you poor demented soul!!
- OMG the site is really slow ddos attack??
Anyway my post again------
Look dont even bother! I have no time for you and your scam miner, If you really wanted to take a 15-50% cut let people know beforehand before you release it to the public! if your miner really is 75% better than the current offering then why did you not just take a 3% cut simular to a pool then people could made there own judgement, you poor demented soul!!
-
@xolokram:
Thank you. The transition from the "old payout system" to the "new payout system" did not happen the way I had expected from reading (but perhaps not understanding) the posts here, and in the places you mentioned (I gather it did not happen quite in the manner you had expected, or at least hoped, either). I was chugging along getting 3.xxx payouts and then suddenly bam! they stopped (Mon Oct 14 07:17:36 PDT 2013); there was no sign of a "bundled payout". Now I know that for a while you indicated you were doing the payouts manually and they were irregular, but never quite like this. Perhaps coincidently the payouts ceased immediately after I upgraded my miners; in reading the posts here I understood that the new miner was working under the "new payout system", but did switching before I got the "bundled payment" mess it up? Do they really have nothing to do with each other? Did I do something wrong when I installed the new miner? Did I miss something somewhere? While there are discussions about the new algorithm, muddled by pato's comments I don't understand and arguments about grom's miner and all sorts of stuff way over my head (no wonder you are tired, and I agree is sucks) are perhaps germane to somebody as a newbie they only confuse me, and consume the bulk of the ~30 posts you indicate.
Thanks to your information I now have the answers to many of my probably simplistic questions. Is the old payout system dead and buried? Yes. Will I see any more payouts from it? No. Does not receiving any payouts on the new payout system mean my miners are broken? Not necessarily. Are my miners working? It would seem so. When will I get payouts again? Not for a while, maybe a few days.
@slash2rustee:
You could not have picked a worse time to get your feet wet; at least I got in a few weeks ago and was in on this roller coaster ride from the beginning. Things were not so chaotic back then, and hopefully will be peaceful again soon. I don't know enough about the old vs the new payout system yet to have an opinion as to its merits, but I can say the last week is not indicative of how this pool has run in the past.
By the "new client" do you mean xolokram's v6 or grom's? I have upgraded to xlokram's v6 (from v4) and to the best of my limited knowledge in interpreting the miner output and the statistics on the website I believe all the 9's I found are accounted for; I can't speak about grom's miner as I have never used it and am not familiar with it. There have been reports in this thread about anomalies in both miners, but I have net seen them.
The old payout system allowed for the extraction of JSON data allowing for monitoring and analysis of data from the pool, hopefully once the dust settles the new payout system will too, and using that I was just getting to the point where I was reasonably comfortable with how things worked, but now it is a whole new ball game.
@grom:
I second what xolokram said about making a new thread for your miner project.
@(Moderators: Excelsior, craslovell):
Move all the ancillary posts to their own threads?
Icedaddy you made the right choise of using xolos miner... for gods sake dont use groms miner for reasons already stated in posts beforehand!
xolo will ..we all hope, resolve the payout issue in the near future, because of all this s**t I would assume that its all screwed up!
I have had my differences with xolo and a few guys on here over the past few weeks but I can say I would trust them with my life!
Anyway i'm a bit pissed of after being duped by a scam miner... should have known better than to trust someone with a miner that spammed 6 shares. and scewed up the pool for everyone before the current pay per share system >:(
- I'm so glad I didn't use Grom's miner.
To not say he was taking a cut upfront is a scam and I'm sure he would be labeled as such on Bitcointalk...
Here are my stats since starting on this pool (i5 2400 3.1ghz, using 4 cores)
********************************************
*** running time: 56.880hrs
***
*** 7-chains: 348 (91.339% | 6.118/hr)
*** 8-chains: 29 (7.612% | 0.510/hr)
*** 9-chains: 4 (1.050% | 0.070/hr)
***
*** valid: 381 (91.587%)
*** rejects: 34 (8.173%)
*** stale: 1 (0.240%)
********************************************
That's approx 4.7 XPM I'm due... one of the rejects was a 9-chain >:(
- @xolokram
I can imagine you're exhausted! All this grom_bs + growing_server_loads + payout_mods + support = one_massive_headache. I hope you've got some able help?
If needed I could help out with some web test automation (maybe for coming api?) amongst other things. pm me if interested.
I'm working on a new stats service, something like @sy's but different too :). Like @sy I'm sort of waiting for web site to settle down and would be interested in the API discussion. I know this is not top priority right now.
Meanwhile, I'm producing some functional tests against existing site, that will break when something changes. At the very least I can alert when this happens .
- churchmouse
-
BTW I started using essentially the defaults for grom's miner for xolominer
-sievesize=4096000 -primes=289511 -sievepercentage=6 -sieveextensions=9plus i have my weird extra addons leaving me with
-sievesize=4096000 -primes=289511 -sieveextensions=9 -bits=10 -TargetInitialLength=7 -sievepercentage=6 -chainlength=10this gave me more accepted shares (especially 8 shares) over the past 4-6 hours
I suggest you just use the grom defaults over grom's actual miner btw while your Primes per hour may be lower the actual amount of usable shares increases significantly. Which is why I said grom's miner is slower, it might look through more primes per second however it doesn't find usable shares faster.
-
BTW I started using essentially the defaults for grom's miner for xolominer
-sievesize=4096000 -primes=289511 -sievepercentage=6 -sieveextensions=9plus i have my weird extra addons leaving me with
-sievesize=4096000 -primes=289511 -sieveextensions=9 -bits=10 -TargetInitialLength=7 -sievepercentage=6 -chainlength=10this gave me more accepted shares (especially 8 shares) over the past 4-6 hours
I suggest you just use the grom defaults over grom's actual miner btw while your Primes per hour may be lower the actual amount of usable shares increases significantly. Which is why I said grom's miner is slower, it might look through more primes per second however it doesn't find usable shares faster.
I'll give that a shot and compare xolo, grom's latest post and your "defaults".
Thanks.
EDIT:
I guess you can compare these...to give us a rough idea.
Grom's settings from his last post: (http://i.imgur.com/ms18rwm.jpg)
Xolo's default v0.6: (http://i.imgur.com/jizwpBj.jpg)
Now in process of testing your values theprofileth
-
BTW I started using essentially the defaults for grom's miner for xolominer
-sievesize=4096000 -primes=289511 -sievepercentage=6 -sieveextensions=9plus i have my weird extra addons leaving me with
-sievesize=4096000 -primes=289511 -sieveextensions=9 -bits=10 -TargetInitialLength=7 -sievepercentage=6 -chainlength=10this gave me more accepted shares (especially 8 shares) over the past 4-6 hours
I suggest you just use the grom defaults over grom's actual miner btw while your Primes per hour may be lower the actual amount of usable shares increases significantly. Which is why I said grom's miner is slower, it might look through more primes per second however it doesn't find usable shares faster.
I'll give that a shot and compare xolo, grom's latest post and your "defaults".
Thanks.
EDIT:
I guess you can compare these...to give us a rough idea.
Grom's settings from his last post: (http://i.imgur.com/ms18rwm.jpg)
Xolo's default v0.6: (http://i.imgur.com/jizwpBj.jpg)
Now in process of testing your values theprofileth
It's not my miner you are running, my miner has completly different output.
-
I have mined with 0.6RC1 for more than a day on several machines and got
264 7chains
16 8chains
1 9chain (a block found 15min after I started miners)
The ratios don't look quite right.
Now it has been 2 days and 9 hours on my two win7 i5 and one win8 Xeon machines. In total I get
445 7chains
32 8chains
1 9chain
I am getting far less long chains compared with 7-chains. At this rate the per-day reward isn't better than that on ypool at all. If there had been 44 8-chains and 4 9-chains, as suggested by the number of 7-chains, the reward rate would improve by 50%. That is before correcting for ~10% rejection rate.
I see others can get 9s just fine. I am going to restart all my miners to see what comes out of it. If it doesn't help, I will have to wait for a new version of miner to mine at beeeeer.
12 hours after restarting the miners:
7-chain 126 93.3%
8-chain 7 5.2%
9-chain 2 1.5%
Very good! This reenforces my suspicion that not all miner instances runs equally. The same miner can get stuck in a condition that it cannot produce long chains. One has to restart the miner to fix the problem.
I have observed the problem with hp and ypool miners. That is why I don't solo anymore -- you can' t monitor how fast it produces long (>5) chains with hp miners.
edit:
it was 12 hours above. 14 hour result is
7-chain 159 93.5%
8-chain 9 5.3%
9-chain 2 1.2%
Will report back after running for longer period.
- hm, i'dont know what i'should say. today in the morning. where i'was read all here. i'fell relay a little bit bad myself. i'm mining with 40 cores here in this pool. and i'was use with the old miner < v6 the option poolfee=
i'hope the correct stats come out very fast. and the payoutsystem work automatic ...
- HI Guys,
I just started mining prime coin over 2 days now on http://www.beeeeer.org/user/ALBUF8JX8jjmKXDSACkwkpth6CaWReCmEN . I have over 33 XPM but its not reflected in the summary.
Can someone explain what is being displayed , it currently does not make any sense. I had to sum the rewards separately to see what i was owed
- At 2013-10-14 23:04 I have receipt +1.43267511 XPM, did level payout 3 XPM was changed?
Details
TO: AJ7tb4kBpMjoxT7TC2eTDFGY5xAmVKKdKu
Quantity: +1.43267511 XPM
ID: 0ebca1be57392fe767496699a49f8c34f22fddfd87d06aa9a1ff2c2280bdf472
- It was the final payment of the old payout system.
-
BTW I started using essentially the defaults for grom's miner for xolominer
-sievesize=4096000 -primes=289511 -sievepercentage=6 -sieveextensions=9plus i have my weird extra addons leaving me with
-sievesize=4096000 -primes=289511 -sieveextensions=9 -bits=10 -TargetInitialLength=7 -sievepercentage=6 -chainlength=10this gave me more accepted shares (especially 8 shares) over the past 4-6 hours
I suggest you just use the grom defaults over grom's actual miner btw while your Primes per hour may be lower the actual amount of usable shares increases significantly. Which is why I said grom's miner is slower, it might look through more primes per second however it doesn't find usable shares faster.
I'll give that a shot and compare xolo, grom's latest post and your "defaults".
Thanks.
EDIT:
I guess you can compare these...to give us a rough idea.
Grom's settings from his last post: (http://i.imgur.com/ms18rwm.jpg)
Xolo's default v0.6: (http://i.imgur.com/jizwpBj.jpg)
Now in process of testing your values theprofileth
It's not my miner you are running, my miner has completly different output.
I know, I stated it's the default miner with the values you posted in the bat file...
- Wow! What a night of revelation!
I decide not to look at this forum for an evening and look at what happens ::)
@xolokram. My personal feeling is that xpm which was diverted by groms miner should stay that way. Even if you can tell which shares came from groms miner, I can't imagine you can easily determine which ones were diverted. Might be a bit harsh to those who lost xpm but you did give continuous warnings about using a different miner.
Offering a redirect of diverted shares is its own massive problem and you're a busy guy!
I'm going to try and help out by fielding some of the questions here so you can concentrate on updating the pool software.
So here goes:
@KTM that payment was most likely the bundled payment to end the 'old system'. At that deadline all xpm amounts which were mined using the old share system and still owing (no matter the size) were paid off. The next payment will come through when xolokram fires off the payment script for the new payment system. Assuming that everything goes well with that, future payments should be automatic.
@icedaddy (most of what I wrote above will apply for you too). I think k your last payment on Monday was your bundled payment. If memory serves, you have quite a bit of mining power so we're getting payments of ~3xpm frequently. As that's the case, I would have thought that the amount owed to you for the bundled payment would not have been a great deal more than 3xpm.
All xpm earned under the new system is accruing in the pool and payouts will start once xolokram has decide that the payout script is safe and ready. In the meantime you can see how much you've accrued on your beeeeer.org user page. Under the 'New payout System' heading is a list of all the shares you've submitted under the new system. You can get the amount you've made by adding together all the rewards and then subtracting all the fees.
(xolokram is working on a way of allowing access to more stats but for now, a bit of maths is needed)
A brief description of the new and old systems:
Old system - Each share submitted counts as one share of the next block found. Once a block is found it is divided up by the number of shares submitted by everyone for the block and each share is paid.
New system - shares of different lengths are given a weighted reward based on the difficulty of finding them. Shares with a chain length of 7 are worth the least and longer chains are worth more. Each share submitted is rewarded based on the length so it no longer matters when a block is found. The value of each share is updated using maths.
Hopefully that's all correct and helpful.
- Hi,
uhm ... first:
i'm sorry, i'll have to go all your posts later, i'm in a hurry right now.
second:
can we please make a new thread about grom's miner to seperate this issue completely from this thread?! and maybe someone can post something on the bitcointalk forums? i'm not really active there and i don't really want to maintain two (or more) threads
third:
i don't really know what i should do with the payouts. some suggest to start the payout anyway. i have some logfiles, but they are not really 100% accurate for repairing this issue, so if i should be able to filter out some of grom's payout addresses there could be some false positives, so it's maybe not the best idea?!
i have some important (non-pool-related) stuff to do today. i'll be back later today.
- xolokram
ps. what a night ...
pps. yes, the pending payouts for the cppsrb payout system are delayed again, i hope we'll have a solution this evening
- Don't revert anything, just continue as planned, everyone has paid for his lessons - that's how it works and tbh this lesson was rather cheap, i had way more expensive ones in my crypto journey so far -.-
-
Hi,
uhm ... first:
i'm sorry, i'll have to go all your posts later, i'm in a hurry right now.
second:
can we please make a new thread about grom's miner to seperate this issue completely from this thread?! and maybe someone can post something on the bitcointalk forums? i'm not really active there and i don't really want to maintain two (or more) threads
third:
i don't really know what i should do with the payouts. some suggest to start the payout anyway. i have some logfiles, but they are not really 100% accurate for repairing this issue, so if i should be able to filter out some of grom's payout addresses there could be some false positives, so it's maybe not the best idea?!
i have some important (non-pool-related) stuff to do today. i'll be back later today.
- xolokram
ps. what a night ...
pps. yes, the pending payouts for the cppsrb payout system are delayed again, i hope we'll have a solution this evening
If you could filter out grom's payout address, then it's best to distribute those rewards to other miners according their contributions for the last few days.
Anyway, we wish the payouts processed asap, since it's been too long since the 3600 confirmations of the first cppsrb blocks.
- Hi Xolo. New here and only been mining on beeeer for 2 days so I wasn't part of the old payout method. My first coins should be maturing as I type. Like Sy said, don't worry about those that were silly enough to try Grom's scam miner. I'm one of those that tried it for a couple of hours and quickly noticed that things didn't add up, at the time I assumed it wasn't properly reporting stales/rejects plus it didn't seem any quicker so I flicked it and went back to your miner.
Who would have thought someone would pull a low act like stealing peoples shares.. >:( I was mining on ypool and was earning ~2 xpm a day up until recently when it dived down to less than 1 xpm per day. After 2 days here, my rough calculations is that I'm earning 3 to 4 xpm per day so I'm very happy. Finding 8 x 9ch in 2 days helps!! :)
PS: The only thing I liked about Grom's miner was that it showed progress stats every minute or so. With your miner the only way I know how to see that is to hit control-C and do a screen capture before it closes. Is there a keyboard command to see how your miner is going without using CTRL-C ?
-
Anyone else tried those settings?
-sievesize=4096000 -primes=289511 -sievepercentage=6 -sieveextensions=9
I'm going to run them now, defaults are: (posting that here so i can't loose it ;D)
********************************************
*** running time: 50.653hrs
***
*** 7-chains: 264 (88.294% | 5.212/hr)
*** 8-chains: 30 (10.033% | 0.592/hr)
*** 9-chains: 5 (1.672% | 0.099/hr)
***
*** valid: 299 (95.527%)
*** rejects: 13 (4.153%)
*** stale: 1 (0.319%)
********************************************
-
The only thing I liked about Grom's miner was that it showed progress stats every minute or so.
I've just added this feature to xolo's miner and created a pull request in git. https://github.com/thbaumbach/primecoin/pull/1/commits
2013-10-16 10:16:36 primemeter 18131618 prime/h 280870368 test/h 2220 5-chains/h 2.655912 chain/d
[MASTER] work received
Probable prime chain found for block=b0456cf1ceff35ef47688b17f5f21df48fcd57800378389c815cbc29fe7401a3!!
Target: 09.eb4f8f
Chain: 2CC07.2d830c
[MASTER] submitted share -> SHARE
7-CH: 1 (100% | 12/hr), VL: 1 (100%), RJ: 0 (0%), ST: 0 (0%)
2013-10-16 10:17:36 primemeter 18253783 prime/h 282741591 test/h 2640 5-chains/h 2.682340 chain/d
Please review my code and add it to the primeminer :)
I also fixed the linux makefile some days ago.
- While you are at it, patch out that useless 5ch/d number and replace it with 7ch ^^
-
Anyone else tried those settings?
-sievesize=4096000 -primes=289511 -sievepercentage=6 -sieveextensions=9
I'm going to run them now, defaults are: (posting that here so i can't loose it ;D)
********************************************
*** running time: 50.653hrs
***
*** 7-chains: 264 (88.294% | 5.212/hr)
*** 8-chains: 30 (10.033% | 0.592/hr)
*** 9-chains: 5 (1.672% | 0.099/hr)
***
*** valid: 299 (95.527%)
*** rejects: 13 (4.153%)
*** stale: 1 (0.319%)
********************************************
how does that compare against the default parameters on your hardware?
-
Anyone else tried those settings?
-sievesize=4096000 -primes=289511 -sievepercentage=6 -sieveextensions=9
I'm going to run them now, defaults are: (posting that here so i can't loose it ;D)
********************************************
*** running time: 50.653hrs
***
*** 7-chains: 264 (88.294% | 5.212/hr)
*** 8-chains: 30 (10.033% | 0.592/hr)
*** 9-chains: 5 (1.672% | 0.099/hr)
***
*** valid: 299 (95.527%)
*** rejects: 13 (4.153%)
*** stale: 1 (0.319%)
********************************************
how does that compare against the default parameters on your hardware?
That was with default, ill post 24h tomorrow :)
- Simple statistics for the console
It may be useful to someone
http://pastebin.com/aUDL5Bzy# (http://pastebin.com/aUDL5Bzy#)
PS The last line is the correct value share not share/day
-
Simple statistics for the console
It may be useful to someone
http://pastebin.com/aUDL5Bzy# (http://pastebin.com/aUDL5Bzy#)
PS The last line is the correct value share not share/day
Thanks :)
7.5 xpm yesterday, 2.5 today (~4 total with 9h of the day left) - strange.
-
Simple statistics for the console
It may be useful to someone
http://pastebin.com/aUDL5Bzy# (http://pastebin.com/aUDL5Bzy#)
PS The last line is the correct value share not share/day
Thanks :)
7.5 xpm yesterday, 2.5 today (~4 total with 9h of the day left) - strange.
More people used yesterday my miner and we had Block avg lower by 79-100 s
-
More people used yesterday my miner and we had Block avg lower by 79-100 s
That would not affect his earnings.
And Primecoin's difficulty adjustment also makes your claim stupid.
Go away, scammer.
- @icedaddy- I was completely referring to the Gromgate scandal. I love hearing all the things Xolo is dong in the background and have nothing but respect and patience for his work. The reason I chose this route and beeeeer to start was his approach was very open and seemed to have the miners interest at heart. His passion made it easy for me to trust his system!
- I tested grom's settings and compared to the original stock miner's ones and the ones provided by theprofileth...I think theprofileth's might be faster at finding blocks, sacrificing 7 and 8 chain speeds, reject rate is similar at 9% for both.
Grom's was better at finding 7 chains lol
This was tested in 6 hours though, I'll try to expand but I'll stick to stock xolo and theprofileth's settings on my i7 3820.
-
Hi,
I should be able to run the payout script in a few hours (I had/have some appointments today).
I will just payout everything, i'm sorry for everyone who feels cheated by grom, but like i said before, i can't filter his payout addresses without possibly damaging other users.
I'm aware of the horrible rejection rate: this and the API for stats will be the next issue i will work on, once the payout script is running.
@grom:
PLEASE, create a new thread for your promotion / discussion / whatever.
@icedaddy:
I re-worked (read: cleaned) most of the code and I started with a complete new "pool wallet" when I activated the CPPSRB share system. That's why there were 2.5 (now >3 ) days of delay for network confirmations, but i thought this wouldn't be a real problem, because during this period there would be the confirmations/payouts for the old payout system. the first (!) payouts for the new payout system are scheduled for this evening! I hope everything will work as intended. Your workers are mining when you see "pending shares" on your personal user stats page on beeeeer.org
@profileth:
unfortunately a 'whitelist' would include very tricky (read: time consuming in terms of coding) mechanics to identify mining software, it's not that simple (impossible?) with an opensource project like my primeminer.
@churchmouse:
API's coming, Sy's waiting too :)
@KTM:
the whole payout system has changed and the old payout system has been abandoned with one large payout for all users with >0.01 XPMs of total earnings. Ah ok, i just saw pankkake & MJ2P answered this.
@fenix:
thanks for the script.
@qh:
I merged your pull request; could be interesting for some users. link to the fresh compiled binaries will be HERE IN THIS POST in a few minutes. CLICK ME (http://www.mediafire.com/download/myy4cahuly2g44d/primeminer_v06_rc2_x86_and_x64.zip) <-- v0.6 RC2 it's RC1 with live stats
(maybe i should add some advertisements to my miner, that would be soooo cool!)
@rpool:
I'm confused they don't seem to bother at all about Gromgate.
this project is a emotional rollercoaster ride right through Craplachistan. ;)
My daughter's coming home (yup, you're reading correct: I have a life :D), I will be back later!
- xolokram
-
@icedaddy (most of what I wrote above will apply for you too). I think k your last payment on Monday was your bundled payment. If memory serves, you have quite a bit of mining power so we're getting payments of ~3xpm frequently. As that's the case, I would have thought that the amount owed to you for the bundled payment would not have been a great deal more than 3xpm.
All xpm earned under the new system is accruing in the pool and payouts will start once xolokram has decide that the payout script is safe and ready. In the meantime you can see how much you've accrued on your beeeeer.org user page. Under the 'New payout System' heading is a list of all the shares you've submitted under the new system. You can get the amount you've made by adding together all the rewards and then subtracting all the fees.
(xolokram is working on a way of allowing access to more stats but for now, a bit of maths is needed)
I am not sure. If I look at the statistics on the last "old" block on beeeeer.org (206442) I see a large number of payouts, presumably the "bundled payments. Under "payout I see:
"AdSKb2ueBiZvhQJSptn8YforuLgskipCSD": 8.31729662974099,
that would (improperly?) lead me to believe I would see a payout of that amount as the "bundled payment", but I have received no such payment, only the usual 3.xxx payouts. It isn't a big deal to me per se, I mean xolokram deserves a lot more than that for all the grief he puts up with, but I hate not understanding. I guess it really doesn't matter as I don't see beeeeer changing payout algorithms again any time soon! ;D
I agree in theory about adding the rewards together and all, but at the moment I see 11388 record, a bit more math than I care to take on. ;) If I get industrious I may write some javascript to read the page do the math for me (oh for a JSON API). If I understand the new reward system, and if my miners are performing with v6 as they were under v4, I should be at about 250 XPM give or take. If I am not I know something is wrong, either with my understanding or my miners.
@Slash2Rustee:
Since neither rpool or ypool work for me because of my ISDN connection I am pretty much stuck here, but I have no real complaints. Assuming the v6 miner is working, and without payouts to judge I have to have faith and assume it is, it is a huge benefit to me as the bandwidth requirement is much lower.
@xolokram:
On the new payouts, if a job is worth doing it is worth doing right, so take your time and don't rush things. The last thing I would like to see is you feeling pushed to release something before it is ready and having to go through all this again! :o
-
Simple statistics for the console
It may be useful to someone
http://pastebin.com/aUDL5Bzy# (http://pastebin.com/aUDL5Bzy#)
PS The last line is the correct value share not share/day
Thanks :)
7.5 xpm yesterday, 2.5 today (~4 total with 9h of the day left) - strange.
To answer that question myself, it seemed i got pretty lucky with 9 chains yesterday, since i found 6 and only 1 today - that explains the higher reward - damn i would have found 6 blocks solo yesterday xD
-
Simple statistics for the console
It may be useful to someone
http://pastebin.com/aUDL5Bzy# (http://pastebin.com/aUDL5Bzy#)
PS The last line is the correct value share not share/day
Nice to see some of my code reused :)
-
To answer that question myself, it seemed i got pretty lucky with 9 chains yesterday, since i found 6 and only 1 today - that explains the higher reward - damn i would have found 6 blocks solo yesterday xD
Keep in mind the pool uses UTC time on the logs and the script is probably using your local time. so you have to account for your UTC offset of your location.
-
[...]
To answer that question myself, it seemed i got pretty lucky with 9 chains yesterday, since i found 6 and only 1 today - that explains the higher reward - damn i would have found 6 blocks solo yesterday xD
Just to tell you that you don't need to be very sorry about this: with a diff of approximately 9.91 only 9% of all 9 chains solve a block. So you chance of having solved 6 blocks with these 6 chains is 0.000000531441 ;)
...no big loss, but hey, you earned roughly 3 XPM with these chains! :D
-
[...]
To answer that question myself, it seemed i got pretty lucky with 9 chains yesterday, since i found 6 and only 1 today - that explains the higher reward - damn i would have found 6 blocks solo yesterday xD
Just to tell you that you don't need to be very sorry about this: with a diff of approximately 9.91 only 9% of all 9 chains solve a block. So you chance of having solved 6 blocks with these 6 chains is 0.000000531441 ;)
...no big loss, but hey, you earned roughly 3 XPM with these chains! :D
Thanks for this - could I ask how did you get the percentage?
Is it as simple as a difficulty of 9.xx = a 9.xx% chance?
- just a quick note
@icedaddy:
this is the last bundled payout: http://xpm.cryptocoinexplorer.com/block/209974 (from the old payout system)
your address is in there with the correct amount, check your wallet! maybe use a rescan?!?
/edit:
some "fun" facts
- sending work data to 9500 miners takes over 1 seconds (that's the delay for just computing the work data (i have an idea to reduce this, but the payout is more important right now)) + the (connection) delay for every individual miner
- the CPPSRB wallet has currently ~14000 XPMs (~6500 confirmed & ~7500 unconfirmed) right now ... pray for a flawless payout script :)
- there are currently more than 16.700 entries in the share log
- Wow, I went on vacation and lots of things happened.
@Xolo I’m sorry I didn’t help to test your miner with a +8 cores machine, promise I’ll help the next time.
@grom SHAME ON YOU!!! Scammer.
This pool has helped me on my crypto journey like anything before; congrats to Xolo for his hard work I’m sure that, in time the pool will just get better and better.
- Is anyone getting payouts after the new payout system was implemented?
I'm still seeing:
"NEW PAYOUT SYSTEM (post 12.10.2012):
current balance: 0.0"
- I
am
working
on
this
right
now
- Xolo, you're the man! ;D
-
Is anyone getting payouts after the new payout system was implemented?
I'm still seeing:
"NEW PAYOUT SYSTEM (post 12.10.2012):
current balance: 0.0"
Maybe read the past 5 pages on this tread and see before you ask ??
- @xolokram:
The address is correct. I do not use a wallet, I have an account on mcxNOW and I send everything there; perhaps that isn't a good idea, this being the reason why? Never had any problem before. I like being able to check the balances on all my coin types in one place and from anywhere with a browser.
-
@xolokram:
The address is correct. I do not use a wallet, I have an account on mcxNOW and I send everything there; perhaps that isn't a good idea, this being the reason why? Never had any problem before. I like being able to check the balances on all my coin types in one place and from anywhere with a browser.
I was thinking about that too, i usually pool mine temp coins straight to exchanges, usually works fine as long as you dont p2pool mine ^^
-
@xolokram:
The address is correct. I do not use a wallet, I have an account on mcxNOW and I send everything there; perhaps that isn't a good idea, this being the reason why? Never had any problem before. I like being able to check the balances on all my coin types in one place and from anywhere with a browser.
I'm doing this with Cryptsy and haven't had any issues. I received my XPM when he did the payout.
-
@xolokram:
The address is correct. I do not use a wallet, I have an account on mcxNOW and I send everything there; perhaps that isn't a good idea, this being the reason why? Never had any problem before. I like being able to check the balances on all my coin types in one place and from anywhere with a browser.
I'm doing this with Cryptsy and haven't had any issues. I received my XPM when he did the payout.
I'd use mcxnow for that, crypsty is not 100% reliable...also, you get interest for holding coins there.
- someone PM'd me weeks ago about having troubles with payouts on his mcxNOW address, i don't have any experience with their address system personally. The payout to your address was definitely executed, you should talk to mcxNOW about this issue.
-
I'd use mcxnow for that, crypsty is not 100% reliable...also, you get interest for holding coins there.
I've had 0 issues with Cryptsy. Where's the source on them charging interest? I'm not finding anything about that anywhere...
- He meant that mcxNOW gives you interest on your deposits.
- Oh hey Xolo I forgot to say nice decision removing the 6 chains I said a while ago that this would be the best course of action though I wasn't directly talking about rejection rate I did sort of mention it ;D either way having no 6 chains definitely gives a lot more breathing room with regards to the shelving as you should have a lot more XMP left over hopefully.
-
I'm doing this with Cryptsy and haven't had any issues. I received my XPM when he did the payout.
Come on.. He payed. Transaction is in blockchain. Just show it to http://xpm.cryptocoinexplorer.com/address/-1 , enter XPM address, find any differences with deposits on your exchange account and open support ticket there.
(just may be, did you changed deposit address on exchange?)
- @ivanlabrie:
It appears mcxnow isn't 100% reliable either. Sigh.
@xolokram:
I will pursue the matter with mcxnow.
@marduc:
mcxnow pays interest, they do not charge it.
@romaniz:
Yes he paid, I just haven't got it, which isn't his fault. No address changes were done. Technology isn't perfect. I had never thought about lost payments, but I will double check things in the future...
Out of curiosity is anybody else out there using mcxnow, and did you get the payout?
-
He meant that mcxNOW gives you interest on your deposits.
@marduc:
mcxnow pays interest, they do not charge it.
I see. When he was listing reasons not to use Cryptsy I assumed he was saying Crypsty charged you to hold coins there. That would have blown my mind. That's why I wanted a source. ;)
-
@ivanlabrie:
It appears mcxnow isn't 100% reliable either. Sigh.
@xolokram:
I will pursue the matter with mcxnow.
@marduc:
mcxnow pays interest, they do not charge it.
@romaniz:
Yes he paid, I just haven't got it, which isn't his fault. No address changes were done. Technology isn't perfect. I had never thought about lost payments, but I will double check things in the future...
Out of curiosity is anybody else out there using mcxnow, and did you get the payout?
I use mcxnow on a daily basis, but prefer to get my payouts in my local xpm address...You have to avoid sending too small of a transaction, otherwise you won't get the deposits at mcxnow. Read the account page, there's a minimum deposit amount allowed.
- It was me that PM'd xolokram about issues getting paid direct to my mcxNow address. I contacted RealSolid over at mcxNow who told me that the addresses there aren't set up to receive the bulk payouts in the format that beeeeer was sending. He recommended that I use a local wallet to receive payment and then forward xpm to mcxNow from there. I've done that since with no issue.
- Personally I would never trust an exchange to be my payout address - it's another point of failure.
-
[...]
Thanks for this - could I ask how did you get the percentage?
Is it as simple as a difficulty of 9.xx = a 9.xx% chance?
Not really...
You can read the details here: http://ppcoin.org/static/primecoin-paper.pdf
In short words: the difficulty consists of an iteger part and a fractional part.
Say you have a diff of "x.y".
Then the integer part "x" requires a length of chains (cunningham of 1st and 2nd kind and bi-twin chains) of x and above whereas the fractional part "y" renders only "y" percent of all possible chains successful in solving a block. As far as I remember the fractional part is not considered, if the length of the chain is y+1...
- @ivanlabrie:
I experimented with rpool and encountered the problem of minimum payment size of 0.1 XPM. The 3.xxx XPM beeeeer payouts have never been a problem, at least not that I am aware of; I am going to be checking much closer from now on. I can't see how an an 8.xxx payout should be a problem. I emailed them about it. If they are not reliable I may look elsewhere.
@MJ2P:
I guess a transaction isn't just a transaction? How does a "bulk payout" transaction differ from any other transaction? This makes no sense to me...
@ScottJ:
In my experience the wallet is a single point of failure. When I first started mining BTC I had a wallet, and it got corrupted and I lost it all. Sure I should have had a backup, but that is just another thing to worry about. From what I was able to glean on-line wallets were less trouble and less prone to corruption, as well as being accessible from multiple locations. But if on-line wallets are not reliable, either as an instance here or as a class, that puts an entirely different aspect to it.
@masterOfDisaster:
Does this mean that when the difficulty exceeds 10 the minimum chain length required jumps from 9 to 10?
EDIT:
Now things are really strange. I just got a transaction of 3.xxx on mcxnow. It does not show up on Primecoin Explorer. I am not smart enough to figure out whom it came from, but is it the first of the new payouts?
-
@MJ2P:
I guess a transaction isn't just a transaction? How does a "bulk payout" transaction differ from any other transaction? This makes no sense to me...
I'm afraid I don't know enough about how a transaction is structured to be able to tell you why, I'm just passing on information given to me by the owner and creator of mcxNow.
- hey all, quick question about the pay out system
so until a few minutes ago i only had pending shares listed, that list has dissappeared and now the paid share list starts to show just wondering what @10, @9, @8 etc mean and also @null
-
hey all, quick question about the pay out system
so until a few minutes ago i only had pending shares listed, that list has dissappeared and now the paid share list starts to show just wondering what @10, @9, @8 etc mean and also @null
I imagine xolokram will be along when he can to explain it all.
-
hey all, quick question about the pay out system
so until a few minutes ago i only had pending shares listed, that list has dissappeared and now the paid share list starts to show just wondering what @10, @9, @8 etc mean and also @null
I imagine xolokram will be along when he can to explain it all.
ofc, just first time round...i guess keen would be the word :)
-
hey all, quick question about the pay out system
so until a few minutes ago i only had pending shares listed, that list has dissappeared and now the paid share list starts to show just wondering what @10, @9, @8 etc mean and also @null
I imagine xolokram will be along when he can to explain it all.
ofc, just first time round...i guess keen would be the word :)
I know the feeling :)
I've tried to work it out but I'm at a loss.
- Hi,
I just executed the first payouts. And --- of course --- I fu***d up the first 2 (or 3?) payouts. I actually added a maximum total payout (at first 10 XPMs, now 30 XPMs) per execution too. But I fu***d up that too for the very first payout is (which is now worth > 50 XPM) (which was not my intention). The latter ones are ok regarding the maximum payout limit.
please don't bother to much about the first 3 payouts & all related entries of the sharelog, i'll have to fix them manually!! Just ignore them at the moment!!
Ok, i will automate the script now to be executed every 3-5 minutes (I'm not sure yet, but it's enough to catch up with the most recent shares within the next hours/days) paying out up to 30 XPMs.
the last value at the sharehistory column (the part behind the "@" is the payout# for that share entry, it's sometimes 'null' because i forgot to save that for the very first payouts)
i will add more stats and an API asap!!
Just to clarify the process:
(1) the payout script checks the balance of the pool
(2) if there are XPMs to spend (which should be the case currently :) ), do {
go through the sharelog from newest to oldest and add every reward for every user to his current balance until enough users can be paid (payout barrier = 3.01 XPMs) to maximize the payout, limited by the balance of the pool check at (1) and the current maximum payout of 30 XPMs per payout
}
(3) wait X seconds/minutes, then go back to (1)
- xolokram
ps. i will go to bed very soon, keep calm & peaceful
- I just started mining on your pool from the 14th. Based on calculations i was pending over 30 XPM but that number has no changed but i still have not received any XPM's
http://www.beeeeer.org/user/ALBUF8JX8jjmKXDSACkwkpth6CaWReCmEN
I see a new column called paid shares from the 16th. But what about the 14th and the 15th ?
- dude, really? read the last pages!
you can do that... trust me!
/edit:
i found a bug in the web frontend hiding some of the shares
i'll try to fix this before i'll go offline
- I read the last few pages, it is not clear. As I said I just started a few days ago mining PrimeCoin.
Very interesting response. Thanks a lot for your help.
-
I read the last few pages, it is not clear. As I said I just started a few days ago mining PrimeCoin.
Very interesting response. Thanks a lot for your help.
Ok, i will automate the script now to be executed every 3-5 minutes (I'm not sure yet, but it's enough to catch up with the most recent shares within the next hours/days) paying out up to 30 XPMs.
If I understand correctly, payments should be going out now, with all pending payments completed within about a day or so.
- thanks scott
even the front page of beeeeer.org states that payouts are going to be executed after/around 16.10.2013
remember: the server needs some time to load the whole share data
- appreciate the update!
-
I read the last few pages, it is not clear. As I said I just started a few days ago mining PrimeCoin.
Very interesting response. Thanks a lot for your help.
Ok, i will automate the script now to be executed every 3-5 minutes (I'm not sure yet, but it's enough to catch up with the most recent shares within the next hours/days) paying out up to 30 XPMs.
If I understand correctly, payments should be going out now, with all pending payments completed within about a day or so.
Thank you.. I have some other questions with regards to the pool, but will wait a few until payments get sorted out over the next couple of days by then xolokram should not be so stressed
- hmpf
the paid shares in the sharehistory are not correctly removed from the sharelog on the web frontend, thus they appear on both sides sharelog & sharehistory.
and older share entries in the sharehistory are not listed correctly / at all. i'm sorry, this is confusing.
i guess the most reliable source about payouts are currently the recent cppsrb payout pages.
i will fix this tomorrow. good night.
- @optimusprime:
Give xolokram a break. He is not a tech writer. Read what he posts, check his website and the first post in this thread, ponder it for a while and eventually (hopefully) it becomes clearer. His writing sometimes assumes a level of knowledge and understanding that us newbies still lack, so we struggle.
@xolokram:
Give us newbies a break. We don't speak your language. You speak of "until enough users can be paid" and "maximize payout" and such that are greek to the newbie. We can read until the cows come home (steak anyone?) and still don't