Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :) - page 3. (Read 101960 times)

You probably don't understand - I cannot test pool hoping on my own pool, because it is mostly resistant against this type of attack. But as you don't believe that this attack is possible, you should be fine that I'll contribute my 2-3ghash to your pool, right? I want to be absolutely clear; I'm asking because I don't want to be accused later that I'm attackng your pool.

You have two possibilities:
a) Be fine with my test, because you are sure that pool switching attack is nonsense
b) Ban me (I'll use my public credentials, no hiding), but disclose that you're affraid of switching users

And I'm doing all this because YOU don't believe Raulo's math and YOU are asking for real-world proof. (And it will brings me few bitcoins as a bonus.)

Sounds like an opinion to me ... I thought you said these were not allowed?

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.

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.

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

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.

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.

Looks like it's down again from here .

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

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

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.

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.

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.

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.

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

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.

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.

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 https://bitcointalksearch.org/topic/geometric-method-new-cheat-proof-mining-pool-scoring-method-4787

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.

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.

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