 Show Posts
|
|
Pages: « 1 2 3 [4]
|
THIS WAS FROM THE DEEPBIT THREAD, NOT THIS ONEIf you use miner with long polling support and have several miner instances (several rigs or multiple gpu cards), you must use different miner login/password for each miner instance.
You may create additional miner logins in your profile.
Do we need to do this as well?
|
|
|
|
|
What power supply do you have? This sounds like a power problem.
|
|
|
|
What I meant was that in pools that accept invalid blocks, everyone's invalid blocks are accepted, so its just like rejecting everyone's invalid blocks; since everyone gets the bonus, its equivalent to no one getting the bonus. You are talking about shares, not blocks. Shares don't need 120 confirmations to mature. Ahh, you're right. Apologies to you my good sir. |
|
|
|
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. |
|
|
|
What is this?
Over the long run, you will be paid the same amount (actually 1% more on slush's because of less fees) by both pools. Any differences this weekend will be just based on "luck".
Actually current stats show that it may be less on slush's because of invalid blocks. (this can depend on luck too) Everyone gets awarded for invalid blocks so they don't count. Only in deepbit and bitpenny. Other pools don't give you reward for invalid blocks (the ones that don't pass confirmation). That's one of the reasons why you have to wait for 120 blocks in those pools. What I meant was that in pools that accept invalid blocks, everyone's invalid blocks are accepted, so its just like rejecting everyone's invalid blocks; since everyone gets the bonus, its equivalent to no one getting the bonus. |
|
|
|
What is this?
Over the long run, you will be paid the same amount (actually 1% more on slush's because of less fees) by both pools. Any differences this weekend will be just based on "luck".
Actually current stats show that it may be less on slush's because of invalid blocks. (this can depend on luck too) Everyone gets awarded for invalid blocks so they don't count. |
|
|
|
|
What is this?
Over the long run, you will be paid the same amount (actually 1% more on slush's because of less fees) by both pools. Any differences this weekend will be just based on "luck".
|
|
|
|
|
Are you guys all using -f 1 or some absurdly low -f?
Set -f to something higher and your cpu util will go down (though hashrate will as well)
|
|
|
|
This is absolutely false when applying this attack. That is why it is an attack. Earnings from jumping ship and going solo can net you ~120-130% (on average) of what your true average daily payout should have theoretically been given your hash rate.
Prove it. Show it being done. Not theories on paper. Give me a reasonably sized data set proving it, in comparison to daily payouts when not pool hopping, with a comparable set of control data. Likewise, include your daily average from gribble, and gather the sets during a period of identical difficulty. Get the daily earnings both before and after. If you make more money per day, consistently for a period of time as long as the average block solve time that gribble reports, I'll believe you. If you can show it is ACTUALLY feasible, and not a theory on paper, I will believe you. Otherwise, I think it's completely bullshit and I will ask you not to speak of it in this thread again. My explanation shows that by pool hopping to a pay per share pool after the inflection point, you will be guaranteed to be making more bitcoins than if you stayed in your original pay per share pool. |
|
|
|
I do understand it, it just isn't feasible.
Say we have 99 people, each of whom has submitted 2 shares.
Now lets say person 100 is the "attacker". They join the pool and submit 2 shares. Thus earning them an equal percentage. Then they leave, as they've hit the point in which they now have their equal share, and are simply maintaining a percentage from there on out, as opposed to gaining from nothing.
The round continues on for a few hours. Those 200 shares then turn into 20000 shares over time. Of which, 19998 belong to the first 99 people, and the last 2 belonging to the attacker who jumped ship.
The attacker has reduced their payout from 2% of the total, to 0.02% of the total.
The only way they could effectively attack the pool is to determine the total number of shares that 100% CFD would be, for the pool, and submit 2x that number of shares by themselves, then jump ship to another pool... and even then, that isn't stealing money from others, it's simply guaranteeing that they maintain their original percentage of the payout over time.
It's not extra earnings, it's just earnings. You cannot make more money than your average daily payout. If anyone claims to have done this, they got lucky once or twice, and the few times that they are dramatically unlucky will balance that out, thus maintaining the average.
Not true. Let me explain. Lets say I contribute to 5% of the pool (which generates 100 shares an hr), thus I generate 5 shares/hr. I will make 2.5 bitcoins when a round finishes. This is true as long as I keep mining. However, lets say this round is really long, and past some point (say 10 hrs - 1000 shares) I jump ship. When I jump ship, I still will make 2.5 bitcoins from my mining time from this pool if it hits immediately. If the pool hits 1 hour after I jump ship (hits the 11th hr), I will make 50*(50/(1000+95))=2.28310502 bitcoins. If another pool (lets say per-share) pays me more than (2.5-2.2831)/5 bitcoins per work verification, I will be making more bitcoins than just the 2.5 I would have made if I stayed in your pool. Also, for each additional hour after the time I jump ship, the amount extra that I make by jumping ship increases. So I think my way is better. Just keep a sliding window (n hr) of the number of shares submitted by a user. And when we hit, split payout based on faction of work done in the past n hrs. Don't clear the window when we hit. This discourages people hopping and encourages people to stay in the pool. (unless there is a flaw here that I don't see. |
|
|
|
In your FAQ it says: Q: How do YOU prevent fraud/cheating?
We only accept shares from the current block, and the previous block. With the network solving a block every 600 seconds on average, that would only allow a window of 20 minutes maximum to attempt any cheating against the pool. Likewise, with all statistics being available for the public to view, identifying cheaters would not be difficult.
Originally I thought that your FAQ said something along the lines of "If we hit, we only count solved shares that you sent for the 2 previous blocks that the network has solved before the block we hit and use that to calculate the share of bitcoins you get. (eg: a sliding window of the past 2 blocks the network solved)" - This would make some sense, as that would stop cheaters from being paid if they left the pool after N hours to mine on their own. Or is there another method of cheating that I'm not aware of? But now that I look at the statistics, you take the proportion of shares solved since the last hit to determine how much is paid. So if someone does cheat, they still get paid for it. Thus, what does that entry in the faq actually mean? Wouldn't, say a 1 hour sliding window solve the cheating problem and encourage people to continuously mine? (when we hit, sum up the total number of shares everyone solved in the past hour and have the 50*(proportion solved by a specific user) be their payout) |
|
|
|
|
What PSU do you have? IIRC, you shouldn't need the crossfire cable either. Also check your bios for a dual-pcie setting?
|
|
|
|
We dont have 11ghash so thats wrong anyways. currently were at about 8.5 so redo the math. Look ive been mining for about a month. went through everything did my due diligence before i got into this business. Luckily i run a computer repair business so i had the parts on hand to get up to about 2ghash on my own and was gonna mine solo but i did the math and realized it didnt matter if i mined solo or not its still the same pay out outside of the luck that plays a small part in this. when the pool was running 4ghs i got 50% of every blcok found. yeah it took 3 days but if i was mining solo i woulda got 100% and took 6 days the same payout when we got to 8ghs i got 25% but we found a block twice as fast u see my point? still the same payout. when the difficultly dropped and we hit like 8 in one day we got ahead on the curve. now were behind. That makes us average and still exact same payout. So it really doesnt make since to talk about how long the round is look at the numbers your hasrate and your payout it all adds up. Period. No were not hitting as fast as other pools but were not splitting 1000 ways either. Actually the negitivity stops this pool from growing larger and sends people else where. When i look at the last 10 or so blocks found those memebers arent in this round so the members dropping out and adding in makes it hard to estimate when were likely to hit. So lets jus do the math and be grateful its as easy to add things up as it is in this pool from what ive seen things can be alot more complicated..cheers  *Goes back to mining* Oh my computers are still mining. I understand each block being a hit is an independent event/etc. We were at 14 gh/s around this time last night for a bit, and most of the time this round has been > 11 gh/s so I've just gave it an average and called it 11 gh/s. Only recently this round did the global hash rate drop under 10. Also, no negativity, just stating my observation with the unlikelihood of this happening. My miners are still going full-on for this pool |
|
|
|
|
Try booting with just 1 5970 and your lcd plugged into that card. What does poclbcm do then?
|
|
|
|
|
open up a command line prompt (windows key + "cmd.exe") and run poclbcm. What processing cores does it list? Also, did you install ATI stream?
|
|
|
|
Current Round: 01d 07h 55m 27s
This round is taking FOREVER lol
We're at the 99th percentile for having a hash rate of 11 Gh/s.  1 day, 10 hours, 27 minutes = 99th percentile at 11 Gh/s |
|
|
|
Hey, I like the new json user stats thing but there are a few errors. First there should be a comma before "Pool" and there is an extra comma at the end.
Fixed. Thanks! Also I think there may be an output bug when currentRound is at minute 0. But it may be a bug in my code; I didn't log any json that I got from you. Let me know if you track it down. I'll see if I can fix it on my side if the bug doesn't reside in your code. Yeah, when minute is 0: "Pool":{"currentRound":"09h 25s","currentSpeed":"12.21 Ghash/s"} Minutes doesn't appear. |
|
|
|
Hey, I like the new json user stats thing but there are a few errors. First there should be a comma before "Pool" and there is an extra comma at the end.
Fixed. Thanks! Also I think there may be an output bug when currentRound is at minute 0. But it may be a bug in my code; I didn't log any json that I got from you. |
|
|
|
|
Hey, I like the new json user stats thing but there are a few errors. First there should be a comma before "Pool" and there is an extra comma at the end.
|
|
|
|
|
