|
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...
|
|
|
|
FYI, deepbit's last block was at 10:58 UTC. So, geebus, do we have an agreement? EDIT: Murphy laws; looks like the block was not deepbit's. That's first detection failure in last 10 deepbit blocks  . |
|
|
|
Prove it.
There's no doubt that the attack will work. So I'm open to test this attack with my 3Ghash against your pool. Does your previous post mean that you agree with this real-world test? I will welcome +20-30% of my daily income . I already have tycho's pool block detector, so I can switch between your pools pretty easily. Let's make some fun . 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.
Kids usually don't believe that cooker is really hot. They need to touch it. |
|
|
|
Any progress on long polling?
It's in progress and will be ready soon. LP was ready after 10 hours of coding, but there are other related problems (multiple bitcoind instances synchronization), which I'm currently solving. Unfortunately I'm busy in my daily job, so it is taking some time... |
|
|
|
hopping pools you can somehow magically make your card yield more results
Who said that? we're protected against pool hopping
Fail. Attacker can switch between solo and pool, or better, between you and deepbit. Anything what is needed by attacker is count of round shares of at least one pool. |
|
|
|
Or if anyone has suggestions on alternatives (aside from score based, because I fucking refuse to do it) I'm happy to listen.
Why is score worse than sliding window of calculating shares? Originally I also wanted to implement sliding window, but found score much more effective and better from all points. |
|
|
|
I just calculated the average shares/block for deepbit and my pool. deepbit is 68400, which perfectly fit current difficulty, my pool is 83100 (both calculated from 27.3. 21:00, it's latest known history on deepbit stats). So you're right, current pool luck is worse than deepbit. But few days ago deepbit was above 90k . This is nothing about deepbit, just don't panic, everything around mining is about luck. EDIT: Pool luck is displayed as CFD graph on pool stats page. From this graph you can see that there is absolutely no reason for panic, the teoretic and measured curves almost perfectly fit. |
|
|
|
The problem I'm having is that lately in slush's pool a lot more shares seem to be needed per hour. It's very consistent.
Well, the pool luck in previous 3 days was pretty bad, as you can see in daily graphs (system and user's). As far as I can tell, system is working well and there is no reason for losing shares or miss blocks. I was getting a lot less than I should have working 24 hours a day with a 5870.
Even in those unlucky days, my miner is getting only 1-2 BTC less than expected _teoretic_ daily income (from 35 BTC total) in 7day moving average, so I cannot confirm that. Compared with depbit for ex., for the samples I checked, about twice as many shares per block (with similar times to solve) seem to be needed.
Probability is bitch . How long history did you checked? |
|
|
|
Especially since the existing video, unfortunately, says "bitcoins are generated all over the network, by anybody!" This is something we need to fix psychologically in the community here. Although that's the order in which bitcoins get to the network, bitcoins are not generated by a bitcoin miner. They were all created mathematically right at the beginning when the bitcoin protocol was specified and the blockchain launched. They are awarded to miners by all of us, in return for processing transactions and providing security to the network, in a highly competitive market. Everybody repeat it five times. If I could change one thing about how bitcoins get described to newcomers it would be this. This slight change makes a universe of difference.
I absolutely agree! There is huge psychology difference between saying 'bitcoins are created by miner' and 'miner accept bitcoins from the network as reward for processing transactions'. Originally I explained bitcoins to my friends with first sentence, but then found that they don't catch it correctly and it is source of misunderstanding. I tried second way later and I hit almost 100% success rate  . |
|
|
|
Cool! As soon as bitcoin will be mentioned on their site (homepage or pricing page or 'buy additional storage' page), I'll send my coins. |
|
|
|
|
Yes (Althought I already sent my money directly to the justmoon). I'm sure that with those funds, justmoon&team will produce perfect in-depth video next time.
|
|
|
|
Possible attack against a connected-mode pool: when you find a pool-grade hash, send it immediately to gain credit, but when you find a block-grade hash, hold it until the pool hashrate dips.
This introduces some risk that someone outside the pool will find a block in the meantime, so you can't hold too long, but the optimal wait time is almost certainly greater than zero.
Probably not. I didn't do exact math around it, but though about this possibility, too. You cannot take the share too long, because with new bitcoin block, your share become invalid. And this time should be proportional potential gain of delayed submit... Of course I'll welcome exact calculation about this possibility. |
|
|
|
What happened? Network down or some thing?
No, everything is OK. The hashmeter is calculated from current round (is calculated from submitted shares/round duration). This means that after refresh instantly after block is found, you'll see "Cluster performance: 0Ghash/s", because there isn't any share yet. As the round is going, the hashmeter goes up to real cluster performance. I have also implemented hashmeter with sliding 5min average (submitted shares in last 5min / 300 sec), which is currently not enabled. This hashmeter is not affected by round ends, but the hashrate variance is much bigger - 5min is not long enough window and speed is changing in +/- 20ghash/s. EDIT: I just changed hashmeter from round-based to continuous and rised statistics window from 5min to 20min avg, so number should be much more steady/exact now. |
|
|
|
CPU miners will never find a single share before the total share count is near 5k shares or so.
Why? This is not correct - everybody has the same chance to hit first share, of course proportionally to his hashrate. Just for curiosity, 7/8 shares was submitted by normal users with decent GPUs (I know some of the users so I can tell), not by users with strong rigs. Of course probability that CPU user with 1mhash/s hit one of first 8 shares is very low, but don't forget that he has 200-300x slower worker. In these cases, you could use the share ratio of the last round the did have time to actually find some shares for.
Sorry, I still don't see why. And why the limit should be 5k shares and not 3k or 10k shares. Don't confuse fairness and luck; this artifical limit is definitely less _fair_, because it favors unlucky workers. |
|
|
|
I realized something this morning: The average number of shares per block should be close to the current difficulty
You're right, average round should have the same number of shares as current difficulty is. The graph you did shows the real variance in round durations. |
|
|
|
# Block found Duration Total shares Your Reward Block # Validity
2538 2011-03-29 04:57:49 0:00:02 8 8 none 115552 93 confirmations left
Now that doesn't seem too fair. How could this be "fixed" to be more fair with the score based system? Maybe total shares < 1000, use the ratio from the last round?
Firstly, the block is invalid - the block redistribution is fairly slow and I'm being upset with it. Thinking about next bitcoin patch, we will see... Next, why anybody who didn't contributed to the round should receive any reward? |
|
|
|
I wouldn't exactly say it's been "discounted" per se, as I see no solid evidence aside from a denial has been presented to discount the claims... but thats merely arguing semantics ... it seems the discussion is essentially over though, if thats what you mean. TruthHurts's main evidence was based on bug in blocknum (on stats page) and then on tracing wrong wallets in blockexplorer. The fact that my miner didn't find a block for few days isn't any evidence at all . I think I said pretty solid reasons why I'm not stealing blocks, at least not in proposed way. Also, as many people can see, not only my pool has problem with detecting block numbers . So this discussion is definitely over for me. |
|
|
|
|
I think that site is great idea - need more propagation here around!
|
|
|
|
Are you selling trucks for bitcoins? |
|
|
|
I still think there are many errors in the list. Mainly, score based != share based. bitcoinpool, afaik, isn't score based pool, but share based. Deepbit PPS fee is 10% Also please load my hashrate from http://mining.bitcoin.cz/stats/json/ |
|
|
|
|
Show Posts
