Bitcoin Forum
August 27, 2024, 02:48:16 AM *
News: All versions of Windows are affected by a critical security bug; make sure you update.
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 [226] 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 »
4501  Bitcoin / Pools / Re: [~350 GH/s] "Eligius" mining pool (still semi-experimental!) on: June 23, 2011, 06:06:08 PM
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.
This is not correct. MaxPPS pays out the full debt the same way. The only difference is that you never get paid more than you've done the work to get (like you do in proportional), while the pool keeps track of the operator's finances to make sure it doesn't pay you more than the operator has earned from running the pool for you. If the pool has to underpay you due to the finances, it also keeps track of how much it underpaid you so when/if the operator's finances improve, it can pay you extra. It is true that changing address resets this memory, and that is a real flaw to be considered.
4502  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 23, 2011, 04:01:03 PM
This goes under pool maintenance. Take a 0.5% fee already.
These graphs are potentially useful to other pools too, so hoping they might donate too Wink
4503  Bitcoin / Pools / Re: [~350 GH/s] "Eligius" mining pool (still semi-experimental!) on: June 23, 2011, 03:39:55 PM
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.

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 should be a non-issue: since pool hopping is ineffective, nobody will do it.
4504  Bitcoin / Mining software (miners) / Re: My improvements to poclbm on: June 23, 2011, 02:29:50 AM
What does the Efficiency value mean?
Same thing it's always meant with regard to mining. Percentage of getworks that result in a share. With roll-ntime, fast miners can easily milk lots of shares out of each getwork.
4505  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 23, 2011, 12:51:09 AM
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?
I do it in tonal: 0. / diff
4506  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 22, 2011, 11:42:03 PM
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.

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.
The past 2 weeks includes different difficulties. At the last difficulty, shares were of course worth more.

futhermore ur case refers to (nearly) everybody hopping, which destroys the gain in both prop and pplns.
If there is ever a benefit to hopping, it is inevitable that everyone will do it, thus killing the pool.
4507  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 22, 2011, 09:37:40 PM
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.
4508  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 22, 2011, 08:49:46 PM
is poolhopping still an issue? the graphs i saw on eligius, are quite constant 24/7.
Whether people are actually doing it or  not, I don't know. I don't think the hashrate graph gives enough info to tell. With proportional, pool hopping is a good idea and a miner's right. The problem is that it will kill the pools involved eventually.
if thats true, then why did u implement it in the first place?! why don't u know if they r hopping, aren't u the admin with access to lots of stats?! because if they r not, we could cut the whole thread quite short! and ur pools hashpower rises and rises.
Whether it's happening or not, it's basically stupid to not hop a prop. pool. And doing so will kill them.

maximumpps stands against the no registration needed, because every time u change, u have to get ur maximum up again.
You still don't need to register. I agree, the lack of being able to change addresses on a whim is a concern. Any suggestions to deal with it?
not with keeping maxpps. but it's sounds shitty anyway maxpps = pps or less. shouldnt pps stand for a guaranteed value, which maxpps does not?
MaxPPS isn't PPS. PPS carries an infinite risk for the pool operator. MaxPPS is PPS without that risk. ie, you get as much as PPS would pay, so long as it doesn't kill the pool.
also i chose eligius, because in the end everything gets paid out after a week, but with maxpps that would not be the case. so i would change the server, because it looks like the worst system to me.
No matter which system is used, including MaxPPS, everything you earn will still be paid out after a week.

pplns looks like the über ripoff:#
Variables: N = difficulty * 2
# Easy math: (your shares / N shares) * reward
basically it's like prop but the size is always two times time the average ( N = difficulty * 2). meaning it's averaged out prop/2.
on averge u would be ripped off 50%, on faster rounds even more, on doulbe than average rounds it would be like prop, and on longer than 2*average round u would decrease the 50%profit of the 50btc + fees margain of the operator.
Except that the last N shares are always paid. So except for blocks at least 2*diff shares long, your shares on the previous block(s) would get paid more than once.
ahh u should stress the retroactively part, where u get paid on average just half but it dates back twice as much, so it should average out(except really long round which own miners). now it makes sense.
Every system proposed averages out for ordinary miners.

interessting system. but it would just change hopping styles:
as i get it, u now join fresh rounds and leave when they take to long, and come back if a new one starts.
with pplns it's just the opposite. u join the long rounds, because they should be over soon and hopefully followed by shorter rounds, so u get paid triple and more. then leaving at the beginning of a new round in fear of a long round, where the first shares aren't worth anything. and being worth nothing should be a even stronger driving factor than being worth less.
Maybe, but this might be flawed with the gambler's fallacy: there's no reason to expect a short round after a long one. And really, there are no rounds with PPLNS at all.

all those systems have their ups and downs. but if u wanna combat hopping, pplns doesn't look to good. pps should be king, or if u wanna burden the miners with the risk it's maxpps.
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.
4509  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 22, 2011, 07:54:38 PM
MaxPPS also holds at the pool amounts generated that aren't yet matched by 'value'. These could be larger than the minimum payout.
This is not relevant, as it isn't funds due to anyone yet.
I understand that's the logic of MaxPPS. But, they are real BTC funds delivered from the blockchain. They are under the control of the pool operator. And, if someone who has already built up a pending 'earnings' amount later becomes due that BTC by having their 'value' catch up, they need those funds to be safe in order to get paid.

What if in the meantime, you had a security break-in and those BTC were stolen? Or a catastrophic data-loss situation where you lost the keys to pay that out?
Then it can pay from future generation, at the expense of the excess getting into the pool wallet. It all evens out, that's why it's even workable. Wink

If that account never shows up with more mining, to get their 'earnings' and 'value' caught up, is that amount held in reserve in case they again show up forever? Or is it eventually redeployed to pool costs or other recently-active miners?

Practically, you might want to declare an expiration time for these unvested earnings, before it becomes an issue.
Since it isn't theirs, it isn't necessarily in reserve. Of course, not keeping it as a reserve would create a liability to the pool operator should they come back later. Since pool hopping will be pointless and PPS generally a losing proposition, I expect there won't be all that much size to these abandoned NRC (non-reward credits). Specifying an expiration for such credits might be a good idea just in case-- perhaps it could help defer/reduce fees.
4510  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 22, 2011, 07:16:07 PM
MaxPPS also holds at the pool amounts generated that aren't yet matched by 'value'. These could be larger than the minimum payout.
This is not relevant, as it isn't funds due to anyone yet.

To illustrate with an extreme example, assume a MaxPPS system with 50 miners. each submits 1 share, the 50th makes a full block. They each get 1BTC in 'earnings' but only an infinitesimal amount in 'value'. So they are credited tiny amounts, but (50-epsilon) is held indefinitely by the pool operator, until some overlong-round arrives.
They get paid for the work they did. The remainder is not owed to them, and won't be until they do the work to earn it.

If some miners dabble and then leave, and thus never catch up on 'value', that reserve is held.. forever? (Or does it eventually revert to the operator or other miners?)
It's not a reserve. They have non-reward credit noted on their account, in case they decide to mine again, and at that time the pool might owe them more than it makes at that point in time.

Basically, MaxPPS is nothing more or less than PPS with safeguards for the pool operator, which allows him to charge a lower fee, or even no fee at all.
4511  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 22, 2011, 06:52:43 PM
In my mind one of the largest benefits, worthy of highlighting via a bottom-bullet, is that PPLNS minimizes the record-keeping and reserve-holding of the pool operator. Even with 100% trust in the operator, holding a reserve balance at the pool involves risks: real-life crises, security-break-ins, bitcoin economy crashes, etc. A system which allows most accounts to be 'zeroed' asap after generation fees earned means less risk.
I'm not sure this is a real benefit for practical reasons:
  • Full record-keeping is still needed for auditing
  • Reserve-holding is needed only until the minimum payout is met (and there is enough generation to make the payouts) under all systems
It does remove the requirement for maintaining non-reward credit, but that is strictly a negative of the MaxPPS system, not so much a benefit of this one IMO.
4512  Bitcoin / Pools / Re: Visual comparison of pool payout methods based on real-world data on: June 22, 2011, 06:23:10 PM
is poolhopping still an issue? the graphs i saw on eligius, are quite constant 24/7.
Whether people are actually doing it or  not, I don't know. I don't think the hashrate graph gives enough info to tell. With proportional, pool hopping is a good idea and a miner's right. The problem is that it will kill the pools involved eventually.

if i wanted slush, i'd go to slushs server.

if i wanted pps, i'd go to one of the many pps-servers.
Slush and PPS are only on there for comparison/reference. I'm not considering either as viable options.

maximumpps stands against the no registration needed, because every time u change, u have to get ur maximum up again.
You still don't need to register. I agree, the lack of being able to change addresses on a whim is a concern. Any suggestions to deal with it?

pplns looks like the über ripoff:#
Variables: N = difficulty * 2
# Easy math: (your shares / N shares) * reward
basically it's like prop but the size is always two times time the average ( N = difficulty * 2). meaning it's averaged out prop/2.
on averge u would be ripped off 50%, on faster rounds even more, on doulbe than average rounds it would be like prop, and on longer than 2*average round u would decrease the 50%profit of the 50btc + fees margain of the operator.
Except that the last N shares are always paid. So except for blocks at least 2*diff shares long, your shares on the previous block(s) would get paid more than once.

eligius is the best(2nd best when it comes to payouts only) of 5 servers i have tested. never change a running system, just fix the us-server.
The proportional system is self-defeating due to pool hopping. As far as actual earnings, the graphs clearly show that for the ordinary miner, all the systems pay more or less the same.
4513  Bitcoin / Pools / Re: [~350 GH/s] "Eligius" mining pool (still semi-experimental!) on: June 22, 2011, 03:04:57 PM
Please nominate and vote in the upcoming poll for the new Eligius payout method.

Nominations: https://forum.bitcoin.org/index.php?topic=20689.0

Upgrade should occur before the next difficulty (2 days away!), so we need to act quickly here...
4514  Bitcoin / Pools / Eligius: New payout method NOMINATIONS PLEASE on: June 22, 2011, 02:49:37 PM
Please nominate any new payout method concepts on this thread! Nominations will be open for probably less than 24 hours, so if you have an idea, post it ASAP, don't wait to perfect the math!

See also: Visual comparison of pool payout methods based on real-world data
4515  Bitcoin / Development & Technical Discussion / Re: Bitcoin client needs a makeover? on: June 22, 2011, 02:33:21 PM
https://en.bitcoin.it/wiki/Spesmilo
4516  Bitcoin / Development & Technical Discussion / Re: Sabatoge: "Losing" Bitcoins on: June 22, 2011, 12:05:25 AM
In other words, Bitcoin is INFINITELY divisible, therefore the loss of even 99.9% of all bitcoins is not a problem?
Bitcoins are only division down to 2.1e15 units. Changing that is no less difficult than increasing the total BTC count from 21 million to 21 billion, or making it infinite.
4517  Bitcoin / Development & Technical Discussion / Re: A proposed solution to adjust for lost Bitcoins: wallet 'heartbeats' on: June 21, 2011, 10:51:38 PM
It might be more viable if we allow refreshes without the private key. Worst case, someone malicious refreshes lost coins...
4518  Bitcoin / Development & Technical Discussion / Re: Sabatoge: "Losing" Bitcoins on: June 21, 2011, 09:10:46 PM
How will fractional transactions be expressed if such a sabatoge took place?

Seems cumbersome to ask for 10^-8.002345 coins as payment for a product or service.
Decimal people can use SI units: mBTC or μBTC

Ideally more people might adopt the Tonal system, in which case TBC is a fairly reasonable size.

See also: https://en.bitcoin.it/wiki/Units
4519  Bitcoin / Development & Technical Discussion / Re: Sabatoge: "Losing" Bitcoins on: June 21, 2011, 08:19:40 PM
You guys assume the 2.1e15 units are sufficient. Which I personally doubt.
4520  Bitcoin / Development & Technical Discussion / Re: Is the current level of computational power necessary to secure the network? on: June 21, 2011, 08:17:58 PM
It's actually not high enough since the security of the network is presently under constant threat by Deepbit, and has been for at least a month by now.
Pages: « 1 ... 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 [226] 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!