[NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)

[dayfall]

I am not saying everyone should jump.  Suppose half of the miners didn't jump.  Everyone that stayed would still get their fair share, right?

[1714265980]

1714265980

[1714265980]

1714265980

[1714265980]

1714265980

[1714265980]

1714265980

[grndzero]

I am not saying everyone should jump.  Suppose half of the miners didn't jump.  Everyone that stayed would still get their fair share, right?

Actually if half jumped out then you would get more than what you had before they jumped. My experience with bitcoinpool so far is that you make your stake in the pool in the first few minutes then maintain it until the block is found. If more people come in while the round is in progress they will dilute your shares with their power. If a bunch of people stop mining and you keep going you will increase your shares.

My experience. I jump into a new round with 600 Mh/s and my estimated earnings are between 2.80-3.00 once the pool settles at about 11 Mh/s. However during the round the pool went up to 15 Mh/s and my estimated earnings were diluted down to more like 1.80-2.00. If everyone jumped in the pool at a new round and the pool was 15Mh/s then got out halfway through my estimated earnings would go up if I continued until the end.

Kind of a reverse hack. Come to think of it, I hope a lot of people try this "exploit" while I'm in a round.

[FRanz33]

I am not saying everyone should jump.  Suppose half of the miners didn't jump.  Everyone that stayed would still get their fair share, right?

Actually if half jumped out then you would get more than what you had before they jumped. My experience with bitcoinpool so far is that you make your stake in the pool in the first few minutes then maintain it until the block is found. If more people come in while the round is in progress they will dilute your shares with their power. If a bunch of people stop mining and you keep going you will increase your shares.

My experience. I jump into a new round with 600 Mh/s and my estimated earnings are between 2.80-3.00 once the pool settles at about 11 Mh/s. However during the round the pool went up to 15 Mh/s and my estimated earnings were diluted down to more like 1.80-2.00. If everyone jumped in the pool at a new round and the pool was 15Mh/s then got out halfway through my estimated earnings would go up if I continued until the end.

Kind of a reverse hack. Come to think of it, I hope a lot of people try this "exploit" while I'm in a round.

Although that is very true. We dont get paid until we find a block. Every person in the pool is capable of finding the block but as people leave trying to stake a claim somewhere else it just makes the round go longer people get restless and more people leave. No one can really tell when we will hit our not just make assumptions based on our hash rate but honestly when was the last time we hit exactly when we were supposed to? 10hs 1 hrs the very nature of the word Average means you take more than one round and put them together to estimate when we should hit..all of the jumping around is counter productive and time consuming. Jus sitting and collecting coins while doing nothing is pretty sweet..throw in all that extra nonsense to make 30% off of (for most of you) 1 to 2 coins and it doesnt seem as attractive. But now i do see why some big players steer clear of pools

[xenon481]

and how long do u think a round will last if it goes from 15 to 5ghash after the the 43% mark?

The entire reason that I brought all of this up is exactly because exactly the type of situation that you just mentioned is what was reported by concerned users of the pool.

You reported on March 30th that you've seen the pool's total hashing power fluctuating between 14GHash/sec and 8GHash/sec.

That means that ~43% of all of the pool's hashing power is jumping ship from time to time. This may or may not be a purposeful implementation of the pool-hopping attack, but it is exactly the type of indicator that you would expect if a relatively large number of people were already doing it.

[audaibnjad]

Looking over Raulo's proof, and the other comments on this thread, a problem is that each solved block is considered in isolation. That is, the only thing that effects your payout is the amount of work you've done on the current block.


There was a suggestion a while ago about having a sliding window which crosses solved block boundaries. For example, you could have a window of 24 hours -- when it's time for payout, rather than summing up all of the submitted/accepted work in the current block, you sum up all accepted work from the previous 24 hours (regardless of block). I'm not convinced this solves any problems, but it's a fun thing to think about.

Windows are sort of like the "weighted average" used by other pools -- more recent work is worth more. In the "window" case, work in the window is worth 100%, work outside of the window is worth 0%.

Another solution which may be good is to use the weighted average approach, but again apply it across all blocks rather than just the current one.



It'll be a fun project (for me, anyway -- you should decide you're own definition of fun) to figure out the proper weights and how long windows should be, and how folks can game this system as well.

[xenon481]

Looking over Raulo's proof, and the other comments on this thread, a problem is that each solved block is considered in isolation. That is, the only thing that effects your payout is the amount of work you've done on the current block.


There was a suggestion a while ago about having a sliding window which crosses solved block boundaries. For example, you could have a window of 24 hours -- when it's time for payout, rather than summing up all of the submitted/accepted work in the current block, you sum up all accepted work from the previous 24 hours (regardless of block). I'm not convinced this solves any problems, but it's a fun thing to think about.

Windows are sort of like the "weighted average" used by other pools -- more recent work is worth more. In the "window" case, work in the window is worth 100%, work outside of the window is worth 0%.

Another solution which may be good is to use the weighted average approach, but again apply it across all blocks rather than just the current one.



It'll be a fun project (for me, anyway -- you should decide you're own definition of fun) to figure out the proper weights and how long windows should be, and how folks can game this system as well.

There are lots of potential ways to help mitigate the cheating (the proof talks about some), but so far, the best that I've seen is the one that Holy-Fire came up with in http://bitcointalk.org/index.php?topic=4787.0

[audaibnjad]

There are lots of potential ways to help mitigate the cheating (the proof talks about some), but so far, the best that I've seen is the one that Holy-Fire came up with in http://bitcointalk.org/index.php?topic=4787.0

Interesting. From Holy-Fire: "It was designed to resist a form of cheating where a miner only participates at the beginning of a round."


The window method also does this -- by potentially making all work at the beginning of (long) rounds worthless. If the window is applied across multiple blocks, then this payout method may even encourage people to AVOID the beginning of the block (hoping that someone solves it in much less than the window period) while they solo mine/whatever.

[geebus]

I don't want to cheat anyone, but I feel that I am justified if the operator says that a specific action is ok.  

The BitcoinMiningPool just took 15h to find a block.  If I assume 7.5h is average time to find a block, I should have left before the 7h mark.  Here is my reasoning: If the block was found at 7.5h, then jumping obviously has no effect.  But if the block was found at 15h and if I had jumped, then my shares on BitcoinMiningPool would have devalued to half of what it would have been had I stayed the whole 15h.  (I worked only 7.5h of the 15.  I would have averaged 150Mh/s rather than 300Mh/s over the 15h period.)  but I also would have worked at another pool for 7.5h at 300Mh/s.  so payoff is 150/7.5 + 300/7.5.

Jumping, I get either 1+1 or 1/2+1
Staying, I get either 1+1 or 1     (Edit: 1 = the amount of payment expected for 300Mh/s work over 7.5h.)

So it seems to me that the longer I stay after 7.5h the less I can expect to make based on the work I am doing.  Even though I would have only gotten 0.7BTC (1/2 of my expected 1.5BTC) if I had jumped, I would have rather had spent my computing power elsewhere.

Any hard feelings if I do this?  (By the way, I don't want anyone else jumping until we agree it is somehow not cheating.)

Unless you're leaving the pool at the start of the round for the 2nd pool, your shares will be a worth a diminished percentage in the other pool.

If 10000 shares have already been submitted in the other pool, your new share is worth 1/10000 of the value of a share that was submitted when 0 shares had been submitted to the round, and you're playing catch up. The only situation where this would feasibly work is if you left for the beginning of another round.

Either way, FairUser and I are working on a reasonable way to remove the incentive to leave.

[nphard]

FairUser and I are working on a reasonable way to remove the incentive to leave.

What about providing bonus shares to the miner who successfully solves the block?

[Meni Rosenfeld]

There are lots of potential ways to help mitigate the cheating (the proof talks about some), but so far, the best that I've seen is the one that Holy-Fire came up with in http://bitcointalk.org/index.php?topic=4787.0

Interesting. From Holy-Fire: "It was designed to resist a form of cheating where a miner only participates at the beginning of a round."

The window method also does this -- by potentially making all work at the beginning of (long) rounds worthless. If the window is applied across multiple blocks, then this payout method may even encourage people to AVOID the beginning of the block (hoping that someone solves it in much less than the window period) while they solo mine/whatever.

Window methods are harder to analyze, and I'm sure once an analysis is done they will be shown to be inferior.

I don't think a window method will incentivize avoiding the beginning of a round, but in general, allowing cheating by joining only long rounds is also something we wish to avoid. In my method, the operator's score is precisely balanced to make the joining time irrelevant. If it is decreased or increased, it will incentivize miners to join early or late, respectively.

What about providing bonus shares to the miner who successfully solves the block?

It increases variance, makes the payout scheme more complicated, and isn't really necessary if a sensible foundation is used in the first place.

That said, it might be useful for mitigating other kinds of attack, so it's worth keeping in our sleeves.

[yrral]

Window methods are harder to analyze, and I'm sure once an analysis is done they will be shown to be inferior.

I don't think a window method will incentivize avoiding the beginning of a round, but in general, allowing cheating by joining only long rounds is also something we wish to avoid. In my method, the operator's score is precisely balanced to make the joining time irrelevant. If it is decreased or increased, it will incentivize miners to join early or late, respectively.

From a quick preliminary analysis of the sliding windowing method, I don't see any disadvantages of the method. No matter what happens, I don't see any advantage of either joining or leaving right after a pool solves a block or long into a round. Since solving blocks are independent events, your payout for participating at a given point can only be calculated based on the pool hashrate for the past n hours and your hashrate for the next n hours.

I think a window size of 2 or 3 times the average time to solve a block would be good.

[geebus]

Window methods are harder to analyze, and I'm sure once an analysis is done they will be shown to be inferior.

I don't think a window method will incentivize avoiding the beginning of a round, but in general, allowing cheating by joining only long rounds is also something we wish to avoid. In my method, the operator's score is precisely balanced to make the joining time irrelevant. If it is decreased or increased, it will incentivize miners to join early or late, respectively.

From a quick preliminary analysis of the sliding windowing method, I don't see any disadvantages of the method. No matter what happens, I don't see any advantage of either joining or leaving right after a pool solves a block or long into a round. Since solving blocks are independent events, your payout for participating at a given point can only be calculated based on the pool hashrate for the past n hours and your hashrate for the next n hours.

I think a window size of 2 or 3 times the average time to solve a block would be good.

I've also considered random windowing, where a window of time x-seconds large, based on length of round, proportionally larger as rounds grow in length, is used. The randomness of the window could mean that at times, only shares during the first part of the round, middle, end, or somewhere in between may be used.

This gives incentive to stay during the entire round to insure you get paid (if you joined only during the start, or only at the end, you may be excluded based on the random start position of the window) and as it would be a proportional count of shares during that period, payout would be fairly maintained to your current per-block average, while eliminating any reasonable way to predict whether it would be good or bad to leave a round. Unfortunately, this does also leave open the possibility of having some honest and hard-working miners being excluded due to downtime, network outages, etc...

...FairUser and I have been having some lengthly discussions about this, and we're also taking into consideration many things we would like to find remedies for; the poor efficiencies of some users, fair payment systems, incentives to participate full-round, added incentives for block solvers, etc...

Hopefully we'll have something drafted up and can begin implementing our solution soon.

[slush]

geebus, fairuser - any response to my cheating offer? As you don't believe that pool hoping can damage pool users, there should not be a problem with that...

[nster]

Window methods are harder to analyze, and I'm sure once an analysis is done they will be shown to be inferior.

I don't think a window method will incentivize avoiding the beginning of a round, but in general, allowing cheating by joining only long rounds is also something we wish to avoid. In my method, the operator's score is precisely balanced to make the joining time irrelevant. If it is decreased or increased, it will incentivize miners to join early or late, respectively.

From a quick preliminary analysis of the sliding windowing method, I don't see any disadvantages of the method. No matter what happens, I don't see any advantage of either joining or leaving right after a pool solves a block or long into a round. Since solving blocks are independent events, your payout for participating at a given point can only be calculated based on the pool hashrate for the past n hours and your hashrate for the next n hours.

I think a window size of 2 or 3 times the average time to solve a block would be good.

I've also considered random windowing, where a window of time x-seconds large, based on length of round, proportionally larger as rounds grow in length, is used. The randomness of the window could mean that at times, only shares during the first part of the round, middle, end, or somewhere in between may be used.

This gives incentive to stay during the entire round to insure you get paid (if you joined only during the start, or only at the end, you may be excluded based on the random start position of the window) and as it would be a proportional count of shares during that period, payout would be fairly maintained to your current per-block average, while eliminating any reasonable way to predict whether it would be good or bad to leave a round. Unfortunately, this does also leave open the possibility of having some honest and hard-working miners being excluded due to downtime, network outages, etc...

...FairUser and I have been having some lengthly discussions about this, and we're also taking into consideration many things we would like to find remedies for; the poor efficiencies of some users, fair payment systems, incentives to participate full-round, added incentives for block solvers, etc...

Hopefully we'll have something drafted up and can begin implementing our solution soon.

IMO, if it ain't broke, don't fix it (and mess it up)

TBH, if someone thinks that the measures you take may affect their payout badly, they will just leave. I personally find deepbit's system right now great

[burtyb]

Looks like it's down again from here .

[Meni Rosenfeld]

IMO, if it ain't broke, don't fix it (and mess it up)

TBH, if someone thinks that the measures you take may affect their payout badly, they will just leave. I personally find deepbit's system right now great

Not everyone has the knowledge to understand why fixed-weight share-based is flawed. It's dishonest of pool operators to offer a service known to be fundamentally defective.

I don't want to sound too self-promoting, but I really wish people would have a look at my method instead of trying to reinvent the square wheel.

[geebus]

IMO, if it ain't broke, don't fix it (and mess it up)

TBH, if someone thinks that the measures you take may affect their payout badly, they will just leave. I personally find deepbit's system right now great

Not everyone has the knowledge to understand why fixed-weight share-based is flawed. It's dishonest of pool operators to offer a service known to be fundamentally defective.

I don't want to sound too self-promoting, but I really wish people would have a look at my method instead of trying to reinvent the square wheel.

There are plenty of alternative methods that can be introduced aside from score based methods. As I've stated very clearly that I refuse to switch to a score based system with this pool, and this is a discussion about this pool, which will never use a score based system, I will kindly ask you not to use a thread discussing this pool to promote yourself.

[geebus]

geebus, fairuser - any response to my cheating offer? As you don't believe that pool hoping can damage pool users, there should not be a problem with that...

You have your own pool. Go run it instead of trying to run ours.

[FairUser]

We has a server outage again tonight, but for a totally different reason.  We were attacked with a SYN flood.  The offending IPs has been blocked.  Yes, I said IP's.  This time is was a DDoS.  Looks like someone doesn't like us much.   I know it's April 1st and all, but this is not funny.

Please restart your miners.

[geebus]

We has a server outage again tonight, but for a totally different reason.  We were attacked with a SYN flood.  The offending IPs has been blocked.  Yes, I said IP's.  This time is was a DDoS.  Looks like someone doesn't like us much.   I know it's April 1st and all, but this is not funny.

Please restart your miners.

OR...

We were also attacked by a horde of ninjas, and the fiber line was cut in a wicked flurry of throwing stars.

One of these two explanations is real, and one is the April Fools joke. I'll leave it up to you to decide.

Either way, server is back on.