Bitcoin Forum
December 03, 2016, 11:56:07 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 »
  Print  
Author Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)  (Read 95985 times)
dayfall
Sr. Member
****
Offline Offline

Activity: 312



View Profile
March 31, 2011, 07:44:09 PM
 #701

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? Wink
1480809367
Hero Member
*
Offline Offline

Posts: 1480809367

View Profile Personal Message (Offline)

Ignore
1480809367
Reply with quote  #2

1480809367
Report to moderator
1480809367
Hero Member
*
Offline Offline

Posts: 1480809367

View Profile Personal Message (Offline)

Ignore
1480809367
Reply with quote  #2

1480809367
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480809367
Hero Member
*
Offline Offline

Posts: 1480809367

View Profile Personal Message (Offline)

Ignore
1480809367
Reply with quote  #2

1480809367
Report to moderator
grndzero
Sr. Member
****
Offline Offline

Activity: 392


View Profile
March 31, 2011, 08:30:16 PM
 #702

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? Wink

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.

Ubuntu Desktop x64 -  HD5850 Reference - 400Mh/s w/ cgminer  @ 975C/325M/1.175V - 11.6/2.1 SDK
Donate if you find this helpful: 1NimouHg2acbXNfMt5waJ7ohKs2TtYHePy
FRanz33
Jr. Member
*
Offline Offline

Activity: 56


View Profile
March 31, 2011, 08:48:41 PM
 #703

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? Wink

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
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 31, 2011, 08:52:41 PM
 #704

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.

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
audaibnjad
Newbie
*
Offline Offline

Activity: 3


View Profile
March 31, 2011, 09:22:14 PM
 #705

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 Wink -- 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.

Sharecoin: SYQh1Bh6drRocFT6YJWgeM43ZeTHyiY1a4
xenon481
Sr. Member
****
Offline Offline

Activity: 406



View Profile
March 31, 2011, 09:36:12 PM
 #706

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 Wink -- 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

Tips Appreciated: 171TQ2wJg7bxj2q68VNibU75YZB22b7ZDr
audaibnjad
Newbie
*
Offline Offline

Activity: 3


View Profile
March 31, 2011, 09:58:52 PM
 #707

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.

Sharecoin: SYQh1Bh6drRocFT6YJWgeM43ZeTHyiY1a4
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
March 31, 2011, 11:27:44 PM
 #708

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
nphard
Member
**
Offline Offline

Activity: 67


View Profile
April 01, 2011, 02:33:11 AM
 #709

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
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
April 01, 2011, 07:51:41 AM
 #710

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.


1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
yrral
Member
**
Offline Offline

Activity: 79


View Profile
April 01, 2011, 08:12:54 AM
 #711

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
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
April 01, 2011, 08:49:58 AM
 #712

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
April 01, 2011, 09:00:08 AM
 #713

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
Full Member
***
Offline Offline

Activity: 126



View Profile
April 01, 2011, 09:08:15 AM
 #714

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

167q1CHgVjzLCwQwQvJ3tRMUCrjfqvSznd Donations are welcome Smiley Please be kind if I helped
burtyb
Jr. Member
*
Offline Offline

Activity: 45



View Profile WWW
April 01, 2011, 09:13:03 AM
 #715

Looks like it's down again from here Sad.

Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 1890



View Profile WWW
April 01, 2011, 09:26:54 AM
 #716

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.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
April 01, 2011, 10:44:29 AM
 #717

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
geebus
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
April 01, 2011, 10:46:23 AM
 #718

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
April 01, 2011, 10:59:54 AM
 #719

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
Sr. Member
****
Offline Offline

Activity: 258



View Profile WWW
April 01, 2011, 11:06:57 AM
 #720

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.

Feel like donating to me? BTC Address: 14eUVSgBSzLpHXGAfbN9BojXTWvTb91SHJ
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!