 Show Posts
|
|
Pages: [1] 2 3 »
|
|
rQhzjj7AdpEpevWBA7W2XHo3ZKSHmj53XV
|
|
|
|
Time to increase the reward per share? I have a proposal:
I think this is dangerous. It means a 100% guaranteed "better than average" luck to anyone who mines on eligius. If everyone was 100% rational (and not pool hopping), they'd stop mining at their current pool and jump to eligius instantly as soon as payouts are increased. Until, at some point in the future, eligius has 100BTC funds and reduces payouts. Chances are the situation won't improve and payouts are lowered even more after the next block. Now everyone should go to a score-based pool or ArsBitcoin with SMPPS. that is already disproven, because eligius pays already more than many pools for example deepbit. deepbit has 4661 Gh/s and eligius only 450Gh/s, but eligius pays 10/9 per share in comparision to deepbit. if it's all about the money they should have switched a very long time ago...
so what do i have to allow in ghostery requestpolicy noscript abp or cookies that it works?
I use noscript and abp, and all that was needed to let the charts work was to allow Javascript on eligius.st yes, that's how it was for me before the update too. but not now anymore. the graph on http://eligius.st/~artefact2/  works as it should, but not the individual ones like http://eligius.st/~artefact2/5/16ccjkuuQjQ64H9qssmXnj695DdBDR75wJ  |
|
|
|
are the graphs still not working?
if i active script content, one of the
"You must enable Javascript to see the graph.
You must enable Javascript to see the graph."
notifications disappears, but the graphs won't show up as they normally did.
They're showing up fine here. so what do i have to allow in ghostery requestpolicy noscript abp or cookies that it works? |
|
|
|
|
are the graphs still not working?
if i active script content, one of the
"You must enable Javascript to see the graph.
You must enable Javascript to see the graph."
notifications disappears, but the graphs won't show up as they normally did.
|
|
|
|
I'm still waiting my unpaid EU balance. The US one was received promptly when Luke-Jr said it would, but nothing yet for EU.
it took quite a while, but mine are all through now. |
|
|
|
that's happening quite often.  |
|
|
|
|
ah jo das bin ich, aber die adresse mit der sie erzeugt wurden sieht man dann nicht?
|
|
|
|
|
ich hab auch den eindruck das es sich als deutscher kaum/nicht lohnt zu minen, weil die strompreise im vergleich einfach viel zu hoch sind. so 0,22 vs 0,11$. somit macht es wohl sinn meine neue graka wieder umzutauschen...
wie komm ich denn an den stromverbrauch meines pc ohne so ein gerät?
|
|
|
|
|
joa das hab ich mir auch gedacht, aber warum bekomm ich bitcoins dafür?
|
|
|
|
 kann mir wer sagen was das im bitcoin client bedeutet und wie das entsteht? |
|
|
|
With regards to the work queue empty problem: Try adding -q 3 before the -k switch in phoenix to have more than only one queue. You probably have to figure out which value is perfect for you  . how high does it has to be? -q 7 isn't working, try even higher? |
|
|
|
warning: job finished, miner is idle <-----anyone know how to fix this? Is it a problem with the pool or something on my end?
me too. im getting "work queue empty miner is idle" a lot, even with short disconnects. using phoenix 1.5 with phatk win7 32bit  |
|
|
|
@shamathana
Of course you can contrive scenarios where certain entry/exit-patterns get more; payments do have a random component and so some patterns will result in more or less in the short run. (Sometimes betting on red at the roulette wheel results in gains over the next few spins.)
But there are an equal prevalence of scenarios where those same entry/exit-patterns, using information available at the moment of participate/don't-participate decisionmaking, get less.
really? please show me i do not see that! i should have processed all cases: shorter, average and longer rounds. and they look like hopping prop too me. shorter rounds: u get all of the extra rewards, average rounds: you even out with the normals, longer rounds u get less from the deficit(which is not the excatly right word since u still get paid, but not so much as u should have on average. yes i speak english as a foreign laguange :-P). The 'proof' you request is trivial: PPLNS payments are completely determined by a formula whose only inputs are future unknowable events uncorrelated with the recent past. There is thus no way to look at the history of a pool and decide, 'now if I enter(leave) I will get more(less)'. At every moment, the prospective value of participating is equal. Hence, no hopping by any rational miner.
@ future unknowable events uncorrelated with the recent past yes, and true for prop too. the deciding factor is in hopping prop/pplns, that if the round is better than average u get the reward, but if it's below average u still make more than the normalo. i can go into more details if u wish, but first i will eat. @At every moment, the prospective value of participating is equal equally random, because it is infuenced by the N = difficulty * 2 shares still wanting to be generated after urs. Even a miner who is able to predict with certainty an upcoming inrush of new participants, or outrush, doesn't gain any net gain in expected-return. More co-miners mean a block will be hit quicker (by wall-clock time), but also old shares will expire quicker (by wall-clock time). Knowing an influx or outflux is imminent just means variance over time will fall or rise respectively, as is the case with any pool expanding or contracting. Not that expected return will rise or fall.
yes true, but still not the point. nobody knows the future and hoppers don't know it either. they KNOW if they hop they get most of the sharevalue increases(shorter rounds) and less of the shavevalue decreases(longer rounds) from the pool. |
|
|
|
I know this won't go anywhere as those with huge mining rigs would argue against it however I see some relationship to Bitcoin mining and that of real mining and I thought I might try to broaden the discussion.
First off you guys that got in early have staked your claims as it were to the best mining, much like the early gold rushers you got the easy pickings early on, established your claims and used your early finds to fund further mining. Again much like the gold rush there are some miners with deeper pockets than others and those miners have brought in heavier equipment and are tolling through far more ground than those with limited resources. The problem is, again much like early gold rush, coal mining, etc those big outfits tore through the land and with no regulation they destroyed the land, streams and rivers even to the point of causing deaths such as the Buffalo Creek Flood. You early miners as well as the deep pockets ones are much like these early days of real mining in that you have your massive mining rigs which are unregulated and cause environmental damage with the high energy consumption and heat output.
In an effort to reduce the environmental destruction regulations were put in place to stop mountain top removal, uncontrolled run off of mine waste, land reclamation and the fees, fines and cost associated with these rules somewhat leveled the playing field between large outfits and smaller ones. Granted sometimes this worked in reverse and of course there is the huge mining lobby funded by the big outfits which get away with things the smaller guys can't but let's act like all things are done over the table and on the up and up in terms of this discussion.
So how can we move Bitcoin mining into the same Eco friendly state as modern day mining? One way of course is by taxing the heavy polluters but I'm not sure how the Bitcoin environment can set that up. Maybe by Pools taking a larger fee from the larger miners, less from the smaller but it would seem that would be easy enough to get around by just setting up multiple accounts. of course if the pools took a larger fee from the larger outfits you need to push those Bitcoins back into the system without generating the same social disorder system we have in the US where the rich fund the poor by way of subsides.
so the gh/s have to share with the just some mh/s one, since i'M one of them i say signed, but u have to tell that the guys with the big rigs in a way that they don't leave.... Just saying.
You're absolutely right. A possible solution is to publish block information only after payments for that time period have been made. That won't really fix the problem though, as there are probably other ways to achieve the same. Especially with eligius, where it's rather easy to identify if a block was found by eligius (search for non-fee transactions in the block. if there are none, it was most likely an eligius block. Not sure if this always works out. Maybe it also helps to see which pool returns a long poll result first.. Well, probably not.) I like PPLNS, although I'm not into mathematics enough to tell if it has any flaws. delay stats?! then why not use prop. |
|
|
|
Globally, SI/metric prevailed, mainly because it was illegal to use anything but SI/metric.
perhaps he should have done that *G still remains: and where do u get the 0.ffff from, which should be 65535/16^4 right? and the "diff" is the difficulty( http://blockexplorer.com/q/getdifficulty) in ton/hex? and the difficulty is the average number of shares needed to solve a block? Any other suggestions for payout methods to consider? We're running out of time fast, so I need to get the poll options finished soon...
don't look at me i'm fairly new, but u need time to vote too, or just 3 people will vote ;-P should be about 40h before the next change?! |
|
|
|
and why didn't it prevail? and where do u get the 0.ffff from, which should be 65535/16^4 right? and the "diff" is the difficulty( http://blockexplorer.com/q/getdifficulty) in ton/hex? Your analysis seems to assume there's some benefit under PPLNS from hopping in and out, so a lot of people will do it. There's no benefit, so it will only be a small group of superstitious people.
There's no benefit? what makes u believe that? just a statement, but no verification isn't enough. lets examine a few examples. expanation:
y-axis(up): reward paid per quarter round in halfs each digit
x-axis(right): relative time(not time! that depends on the pools h/s) in average quarter round shares(877226/4) each digit
after a block is solved the numbers start counting up again: 23Solved123456Solved1234Solved1....
average round lenght: 1234
fast round: 12 (half the shares needed)
long round: 123456 (1,5 times the shares needed)
even longer: 12345678 (double the shares needed)
normal miner/hopper getting paid a half: #
hopper getting paid a half, but not normal miner: W
the hopper hops from the end of the pplns round to a normal pps-server, and when the round is on average halfway through the hopper joins the pplns again:
12hopper joins34hopper leaves12hopperjoins34hopper leaves12hopperjoins34...
#
#
2 for this segment(~220k submited shares) the miner/hopper got paid two halfs(average) normal pps payout
#
3 for this segment(~220k submited shares) the miner/hopper got paid 1 half(50% of average)
#
#
#
4 for this segment the miner/hopper got paid 3 halfs(150% of average)
W
#
1 for this segment the miner got paid 1 half(#) and the hopper got paid 2 halfs(#+W)
i hope u get what i mean, lets look at the corresponding graphs: just average rounds: normals and hoppers get paid the same, except the miner gets all his money from the pplns-server, where as the hopper gets 50% from the pplns (34), and the other(12) paid from the pps-server. hopping gives neither an advantage nor a disadvantage: ########
########
########
########
12341234123412341234 now a longer round appears(123456), and the hopper gets more(all W's) than the normals. so it averages out for the hopper, but the normals have a net loss: ########
WW########
WW########
########
####
1234123412345612341234 now an even longer round occurs(12345678). the normals get two average rounds(12341234) just halfs, where as the hopper just gets 1 normal round of halfs(3434), so he gets less of the deficit from hopping:
########
WW ########
WW ########
########
####
123412341234567812341234 now an even longer round occurs(123456789abc, triple size of average). even the hopper gets hit by lots of "just halfs" and even a part nothing, which can be minimized by joining even later. but despite that, his balance is again better than of the normals: ########
########
WW #########
####WW
1234123456789abc12341234 a shorter than average round(12).hopper gets paid the averages on 12 from the pps, and is there to gain the triplepay from the (34) parts from the pplns. hopping gives again neither an advantes nor a disadvantage: ########
########
########
########
####
123412341212341234 as u can see hopping on prop as on pplns has some advantages and not as much disadvantages of joining said pool. If irrational superstitious hoppers make a PPLNS pool larger when there has been a long period without a generated block, that just makes the pool more attractive to rational variance-minimizers and fuss-minimizers, seeking a fair pool requiring minimum attention.
the pool gets more attractive? again just a statement, proof is needed too! can only be, because of the faster but smaller payouts(increased h/s). but with lots of hoppers there also much risk for the normal miners mining very long for nearly nothing(relative time as pointed out above). the 12 parts take more time because only the normals mine and the hoppers are gone, additionally those parts have a good chance of being paid just once or even nothing at all(wich should be clear looking at the graphs above). it's the oppotise from prop! on prop u dont want to mine the last shares of a block and on pplns u dont want to mine the first shares. So lets say the hoppers leave after a generation in a futile search for higher returns elsewhere. Note that they are then increasing the variance of their still-alive PPLNS shares so this hop is even worse than neutral for one possible goal.
Some of the variance-minimizers and fuss-minimizers who joined during the hopper inrush are likely to stay. Each seasonal cycle of irrational hoppers should leave the pool with a larger base. And slowly train the hoppers to stop wasting their effort.
variance? i'm not quite sure what u want to point out. but i guess: the worth of their already mined shares is not affected if the keep mining or not. |
|
|
|
I do it in tonal: 0. / diff
what's tonal? and what are those symbols behind the "0." and before the "/ diff"? |
|
|
|
if you didn't hold in your pockets those "scammed" btc taken from those vicious pool-hoppers, but instead distributed them between "fair" users rectroactively after some period of time, say 10 days, probably more people would accept that MaxPPS thing...
I have to agree with this. This is something I never quite wrapped my head around. I like the MaxPPS model except for that one thing. that wasn't a trollpost?! Example:
I pool hopper starts mining. Then leaves.
A block is found. He joins back... another block is found. This will fill his "value."
If the pool hopper leaves the pool at this point or changes Bitcoin addresses, he will never be able to collect this "value."
So where does this value go? Who eventually gets this built up value if it is never collected?
I agree with jkminkov that after a period of time (10 - 20 days) the unclaimed value should be redistributed to the rest of other miners that are active.
this applies to all, not pool hoppers alone. the correct term should be addresshopper not pool hopper. the problem is that maxpps creates staying dept. with prop u work for eligius, this creates dept too, but that is paid every 1btc and fully after one week of inactivity. with maxpps the dept stays because it's not fully paid out because of the limiting value, and accumulates with every new address. so there needs to be a way that this dept is paid. u can then implement rules like 1month of inactivity of the address voids the dept(poolowner gets it), but that counteracts the no registration needed, because every time u change ur address u lose a portion of the money still owed to u. so it will be liek the other pools, if u wanna change ur address, u have to time it quite well that not much btc are left behind. |
|
|
|
anyway if i understand bc correctly the average sharevalue should be 50 / (877 226 + (2 / 3)) = 5.69978113 × 10^-5 as u said. That's if each share is difficulty 1. Pool shares are actually slightly lower difficulty, so you get the number I posted. so how do you calculate it then? |
|
|
|
PPS is king for miners obviously, but that means I'd be left paying them out of pocket at a loss. I could only afford that at probably 15% fee, which is IMO ridiculous. MaxPPS is the only viable way to do anything even close to feeless PPS.
make ur offer :-P bitcoins.lc sharevalue is atm @ 9,9972462987887*10^-5 ur's is atm @ 6,93413218269838*10^-5 deepbit.net with pps is @ 5,129803015564*10^-5 In human-readable decimal: bitcoins.lc and (current) Eligius are proportional. So there is no "share value" to speak of. Actual value of a share at the current difficulty is 0.000056996941566467068322407 deepbit.net is (in normal decimal number format) 0.00005129803015564 Eligius would be, if MaxPPS is used, about 0.000056996884569525500216354 and whats with the 15% with pps, don't "just" need a financial cussion to start with and after that just some % to keep it filled? Yes, that % is 15. u call it humanreadable when it starts with lots of zeros? for me 5,..*10^-5 as an average sharevalue is easierer to remember, just two fives. since nobody uses m(illi)btc (10^-3) or µ(icro)btc (10^-6), i stick to the scientific method, which the google calculator and libreofficecalc conveniently use. anyway if i understand bc correctly the average sharevalue should be 50 / (877 226 + (2 / 3)) = 5.69978113 × 10^-5 as u said. but why then are urs and the one from bitcoins.lc so much higher? both are overall (2weeks) values, since i began mining. so they should be quite evened out, or does that need even more time? but they are way to high and prop from deepbit is to low @ 3,8*10^-5. however those values came to be, since one mines for profit, one should join the server with the highest sharevalue. To the extent people believe the 'something's-due' fallacy, it could be self-limiting. Superstitious people may pile into a pool that seems to have gone a long wall-clock-time without a block. Now larger, the pool will tend to hit a block in less wall-clock-time. Of course it takes just as long in share-tick-time, and gets divided over more separate contributors in the last-N window, so the acceleration is exactly offset by reduction in payout. Neither hopper nor veteran gains or loses expectation from the piling in. it's not about "wall-clock-time". maybe i misused some words. to carify "long" "fast" "lucky" "unlucky" and other don't always refer to the wall-clock-time, but mostly refer to the amount of shares, which were needed to complete a block and if the sum was below oder above average(877226.66). futhermore ur case refers to (nearly) everybody hopping, which destroys the gain in both prop and pplns. But, they all gain from the lower variance, as more trials in the same wall-clock-time means better convergence to PPS-like payouts. So to the extent subscribers to the gambler's fallacy do jump in after unlucky periods, they reduce variance just at those times when it becomes embarrassing to the pool. A simple graph that obscured hashrate changes over time might make such a pool look unnaturally lucky.
with pplns there will be timely long rounds too, because of a lot of hoppers. the abandonment problem just shifts from the end to the beginning. in prop every hopper leaves to the end so the speed gets slower with time. with pplns the speed is directly slow at the beginning because everybody leaves after the round is completed. and as no shares get completed no hopper rejoins. and as the speed is crippled, normal ppl propably won't join too, because they won't get paid in a long time. crippling the pool even further. There is no such thing as 'this pool is due'. There is no way to tell, based on history, that a pool is going to hit more than average blocks soon. So there's no way to determine now is a better or worse time than average for participation in PPLNS.
there is also no such thing as the next round WILL be a fast one in prop, that's not how it works. if it's short u made a hefty profit, if it's long u switch pools to minimize loses, or even hit a short round there. thing is on average ur on top, because short rounds make a good profit and long round aren't as bad and can trigger a good profit from the other pool evening out the loses made on the first pool. -> ur lucky = big profits, unlucky = not real loses => overall gain. same thing with pplns. if the next round is fast: triple pay. if it's long u started quite late so it's still twice the reward, meaning nothing lost just average. -> ur lucky = big profits, unlucky = not real loses => overall gain. in both cases u have an overall gain, because the third case (below average) does not/much less likely exists. |
|
|
|
|
