 Show Posts
|
|
Pages: « 1 2 [3] 4 »
|
Of course every share is checked by pool. Why do you think that it doesn't ? Ah, BitLex nailed it. I mistook your original comment about not validating blocks to refer to shares - My mistake.  |
|
|
|
what could contributors lie about?
the only way of "cheating" is the same you mentioned above, legitimately contribute work to the pool and "pool-hopping" as discussed in other threads. About completing a share... Without verification, what stops someone from just making up answers? "Yup, found a hash. Yup, found a hash. Yup, found a hash". I can appreciate that checking those from hundreds of clients puts a bit of a load on the server, but it seems just plain necessary to keep the scum out of the pool. |
|
|
|
Slush has shown the statistical charts proving that the score based reward system distributes just as equally as a shares based reward system./quote]
...Over time. "Fair" has more than one meaning in this context.
For people running GPU miners with hundreds of mh/s, the expected payout over time converges with reality in just a few blocks. For those of us running under 10mh/s, the payout per block varies radically - I've had a few lucky blocks where I get a whole BitDime as my share, and I've had full days where I only managed to solve a share every fifth block and even then only pulled down on the order of 1E-4BTC per block.
So Slush's pool, while "fair", trades slow-miner convergence rate for discouraging a particular type of cheating. A purely proportional pool converges faster, but allows a style of participation that some people might consider "cheating" (though if you legitimately contribute work to the pool, I don't know that I'd throw too many stones just because someone found the best way to split their contributions across multiple pools to maximize payouts - You could just as well call the entire concept of "pools" cheating, because it deviates from the Satoshi-intended winner-take-all style of BTC generation).
That said, Tycho, how do you plan to avoid massive cheating without block verification? Accepting all shares as equal, no problem; but what stops contibutors from simply lying? |
|
|
|
Since you have an Intel CPU, you should be using the SSE2 CPU Miner, not jgarzik's. It appears the average performance (on Intel chips) is on the order of ~450% of jgarzik's. I have a similar setup (same CPU family, don't know the speed offhand) - It gets about twice the performance using the straight CPU miner (PuddinPop's) that it does using the SSE version... And 2100 kh/s sounds about right. Also, muflix, if you actually hope to mine any Bitcoins, you'll want to join a pool ASAP. At 2100kh/s, you have basically zero chance of ever getting a block of 50. For comparison, I have a total of about 5000kh/s contributing to Slush's pool, and I earned my first whole BTC just last night, after almost two weeks of mining. |
|
|
|
I'm paying them about double their electricity costs, and they think it's a great deal. Being a greedy b*st*rd, I don't want them to discover bitcoins and start mining for themselves. LOL... Dude, I don't think you really need to worry about it. They'd almost certainly rather have the cash, no need to sneak around. Hell, even as someone already interested in BTC, I would take 1 ... (crunches the numbers) ... USD$800/year/5870 to run a miner or ten for anyone interested. In fact, make it twenty, and I'll give you a discount for effectively paying for my home heating.  As for the ethics here - I really don't see a problem. You offered to more than fairly compensate people to run a program for you. If they don't insist on knowing what it does before agreeing, not your problem. Not like it does anything illegal, like act as a CP FTP site without them knowing or a spam bot or anything like that. 1) Serious offer, if you want it - Minimum six month commitment, payable in advance (since I currently own zero 5870 cards) |
|
|
|
|
Hey Slush, I don't know if you consider this a bug or not, but I thought I'd report it.
The clock on one of my machines somehow got screwed up and it considered today the 21st. The "My Account" page dutifully reported my last share as submitted (an hour ago now) on the 21st.
It doesn't look like this has had any real impact on my shares, but I don't know where else you might have coded timestamps such that trusting what the client says really does matter.
|
|
|
|
|
Love it! This makes it ever so much easier to keep my machines chugging away at mining.
Question (or feature request, perhaps) - Any way to make them just blank the screen, rather than showing stats and the coins dancing around?
|
|
|
|
Because it's a database, and thus easy to use, compared to building your own file format. That explains why we don't use a roll-your-own binary format. It doesn't explain why we don't use something a bit more common, such as XML. You could also turn that argument around - By using a relatively uncommon DB, we've still "rolled our own" with the negative of having an external build dependency. Even if we want insist on FOSS, why not connect to a "real" DB like MySQL? |
|
|
|
You obviously don't understand how this works. This is like playing the lottery. The actions beforehand have ABSOLUTELY NO BEARING on the outcome of the next play. Umm, actually, in this case - It kinda does. By playing in a pool, we don't compete against one another. Slush has kindly broken the problem space up for us so we can cooperate on solving the same target, rather than each going our own way and possibly duplicating effort. Otherwise, the gripers who point out that "they" solved X blocks but only got such-and-such a share in it would have a valid complaint. That said - We have a pretty damned big problem space, so the difference between truly random and cooperative amounts to something on the order of one part in 2^128 (256 -80 bits for the fixed-per-block state vector, -32 bits for the share difficulty, -16 bits for the current difficulty). But still, it gives us just the teensiest edge vs each of us hashing on our own. |
|
|
|
The format should be a CSV file (unix line endings) that looks like this: Out of curiosity, why does the wallet use an external dependency (Berkeley DB, now "owned" by known-open-source-killer Oracle) in the first place, rather than something ubiquitous like XML (or if purely flat, even CSV as you mention)? |
|
|
|
From blockexplorer what values would I need to pickle into the file? Did you ever find a solution to this? I tried the following: #include<stdio.h>
#include<stdlib.h>
unsigned char Forward[80]=
{
0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x48, 0xc0, 0x4e, 0x58, 0xdc, 0xa8, 0xe1, 0xa2, 0xdf, 0x25, 0x13, 0x39, 0xc8, 0x1e, 0x2d, 0xfe, 0x1f, 0xf0, 0xe9, 0xd6, 0x55, 0xb7, 0xb4, 0xca, 0x42, 0x8d,
0x72, 0xfe, 0xbc, 0x10, 0x74, 0x70, 0xc4, 0xf8, 0x3e, 0x22, 0x4f, 0x96, 0x83, 0xa5, 0xc7, 0xfb, 0x24, 0xc4, 0xde, 0xce, 0x84, 0x12, 0xb9, 0xd9, 0x5d, 0xb2, 0x77, 0xc8, 0xdd, 0x75, 0x45, 0x1d,
0x4D, 0x57, 0x4A, 0x61,
0x1B, 0x02, 0x85, 0x52,
0x13, 0xAA, 0xD2, 0x0D
};
unsigned char Reversed[80]=
{
0x01, 0x00, 0x00, 0x00,
0x8d, 0x42, 0xca, 0xb4, 0xb7, 0x55, 0xd6, 0xe9, 0xf0, 0x1f, 0xfe, 0x2d, 0x1e, 0xc8, 0x39, 0x13, 0x25, 0xdf, 0xa2, 0xe1, 0xa8, 0xdc, 0x58, 0x4e, 0xc0, 0x48, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00,
0x1d, 0x45, 0x75, 0xdd, 0xc8, 0x77, 0xb2, 0x5d, 0xd9, 0xb9, 0x12, 0x84, 0xce, 0xde, 0xc4, 0x24, 0xfb, 0xc7, 0xa5, 0x83, 0x96, 0x4f, 0x22, 0x3e, 0xf8, 0xc4, 0x70, 0x74, 0x10, 0xbc, 0xfe, 0x72,
0x61, 0x4A, 0x57, 0x4D,
0x52, 0x85, 0x02, 0x1B,
0x0D, 0xD2, 0xAA, 0x13
};
int main(void)
{
FILE *fout;
fout=fopen("manual.txt", "wb");
fwrite(Reversed, 1, 80, fout);
fflush(fout);
fclose(fout);
return(0);
}
(Dat1 has the values as they appear from blockexplorer, Dat2 has them bytewise-reversed - And spare me the comments about error handling  ). Neither produces the "right" hash via sha256sum. Perhaps relevant, I notice that the "data" field from running "bitcoind getwork" has another 12 dwords worth of crap after the nonce, all zeros except for the 1st and 12th. That pads it to 128 bytes (not coincidentally, the value of that first dword after the nonce), but I see no particular reason why it contains anything after the nonce. |
|
|
|
it's been this way since slush changed his payout per share was fair even with the possible cheating Yes, the new scoring somewhat favors faster contributors (who will have a lower ratio of stale shares and a better chance of generating shares closer in time to the pool hitting) - But then, the entire BTC infrastructure favors horsepower over participation, so either take your few pennies a day, or go solo and pray that you ever hit a block within the next few years. OR, start your own purely-proportional shared pool. Simple as that.  Personally, even as a somewhat-penalized low-h/s contributor, I greatly appreciate what Slush has done for us by making it possible to generate any BTC at all without a high-powered GPU to throw at the task. |
|
|
|
first you need to subtract 168W that rest of the system uses (if you don't run your pc 24/7 then adjust it properly) and remember to subtract another 50W that 5970 uses in idle anyway then you need to guess how much is actually used when mining with full speed - that could be another 50W less than when gaming ... For the times you would have had your PC on anyway. For the other 16+ hours a day, you have to consider the full power consumption as something you wouldn't have used if not for mining. However, purely for measuring MH/W, it surprises me that no one has actually measured the change in draw directly, for the most common cards at least. Just hook your PC to a Kill-A-Watt, get a baseline reading, then start the CUDA/CL miner and see how it changes. It seems like a fairly critical deciding factor in actual mining efficiency, since as TEOTWAWKI pointed out, the upper limit can run you over a grand a year in electricity. If anyone wants to donate a 5970 to me (or any other high-end cards), I'll gladly measure it and update the wiki. |
|
|
|
Cheating will be much more effective with new scoring - you just need to start some ~20 minutes after new block. Yes. Yes, it will. The new scoring method will encourage people to mine solo (or in a flat-shared pool) until a block has gone unsolved for a certain amount of time, then switch to an exponentially weighted pool like Slush's. On the bright side, that might increase the number of blocks the pool solves (because contributions to it will increase as a block takes longer and longer). On the down side, this punishes the "honest" participants by devaluing their contributions by 86.5% per ten minutes (if Slush still uses a compression factor of 300). is it possible for cheater to found winning hash, report it to stand-alone client to make a block and report "sorry, nothing found" to the pool? No, because you would need the private key used by Slush's bitcoin instance on his server to submit the block. If I stop or crash for whatever reason and start again, does that reset the time I have devoted or is it equivalent to just picking up where I left off?been working at and start all over or do I just pick up off from the 3 days? As I understand it, yes - But it doesn't matter for the reason I mention above - Your past participation decays 86.5% every 10 minutes - So after an hour and a half (actually 1:32:06.2), your "share" of the current block has less value than the resolution of a bitcoin (1E-8, aka "zero" in the BTC). |
|
|
|
Why not simply count the number of hashes checked in a block instead of the number of correct hashes found? If you'll forgive me for answering a question not addressed to me... "For the same reason BitCoins take work to generate". Hashing counts as a one-way trap-door function, which means you can't reverse it (get the input from a given output), and that only a tiny fraction of inputs lead to the desired output. You can prove success very easily; Proving failure requires exhaustively searching the input space. So while your idea would make it hard to cheat by gaming a specific pool distribution algorithm, it would make it trivial to cheat by just always saying "nope, no hashes here" (You can actually get around that by distributing known-good blocks on occasion, but then you wasting CPU time and increase the number of non-share shares). |
|
|
|
i guess that everyone is getting a lot of invalids, so in the end it doesn't affect your total score/payout, only a lot of bogus calculations for your cpu/gpu and useless network traffic Slower clients will submit more cross-block results than faster ones, both in the absolute sense (because they take longer per share), and in the relative sense (because faster clients process more shares in the "good" window). That said, moving to score-based vs share-based doesn't really have much effect on that, so basically it just sucks all around not to have a $600 GPU.  |
|
|
|
For example, over this night the number of requests rise from 300 getwork/s to more than 500 getwork/s. Any way we can tell our RPC clients to hit your servers less often (personally, I've set the "update period" to ten seconds from the default of four, but I think that only affects what I see, not network traffic)? Or do you get that many actual shares returned each second? Or, you could just double the difficulty of each share and thereby halve your load, rinse-wash-repeat as necessary (while that would make it tougher for the low h/s miners like me, I would say the pool integrity comes first)... |
|
|
|
Might I humbly suggest increasing the compression by, oh say, a factor of 10? Alternatively, if you really mean to use such a high rate of share decay, why not let shares carry over to the next block? That would avoid worst-case situations such as the two badly skewed payouts in a row on 1206 and 1207, but would have little effect on even a typical 10-minute block. Just a thought. |
|
|
|
All following calculations are using C=300, but it may be changed in the future to provide the best cheatproof/usability ratio. Might I humbly suggest increasing the compression by, oh say, a factor of 10? For the shortest round as of the time I write this, you currently penalize the 1 second share by 6% vs the winning share. For a by-design "typical" round of 10 minutes, you penalize the earliest share by a whopping 86%. And for the longest share as of this writing, 1h52m, the earliest share might as well have gone solo, as you penalize the earliest share by "9 nines" percent, ie, more than the resolution of a bitcoin. Did you really mean to penalize the first vs the last share in a typical block by almost 90%? |
|
|
|
|
