Search content
Sort by
Showing 20 of 48 results by Lanidarc
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
21 is fixed for me.
For me as well. ##309 is still screwed up
309 is already confirmed, to late to fix anything
Hardly, slush has several times fixed bad blocks after-the-fact by adding revenues to other blocks in the confirmation chain.
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
I hope Namecoin gets implemented into the stratum. It's still profitable to merge-mine NMC, and brings an incentive to gain more users(as well as keep some of the more seasoned miners who can help us nab more blocks.)
It looks like they are finally starting to develop NMC too. PLEASE add it to stratum!
Oh do link us up, laugingbear! Who is "they"?
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
Just reading through the last few pages, all I can say is...
http://oi41.tinypic.com/2u71z03.jpg
Thank the mining gawds for ignore button!
Methinks I have seen the next victim of the ignore button - a certain self-righteous, ranting, noob with some sort of superiority complex....
http://oi41.tinypic.com/2u71z03.jpg
Thank the mining gawds for ignore button!
Methinks I have seen the next victim of the ignore button - a certain self-righteous, ranting, noob with some sort of superiority complex....
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
How do you know those are transfer fees and not just change addresses?
Well how do you explain 34 BTC blocks? This was my completely noob rudimentary attempt...
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
I noticed every once in a while (like the last block) there will be almost 10BTC worth of transfer fees! I think it's awesome but does anyone know why that happens? a typo when someone did a transfer? or are people just being very nice to miners
Hey, I noticed this a few times, and wondered myself. So I went on blockchain.info and looked at some of the transactions. You can see some Tx look like they have been run through a poor mixing job like this:
http://i43.tinypic.com/dgqhxw.jpg
So here we see Wallet 15r1c move 590 BTC to a couple other wallets, incurring 1.014 BTC Tx fee, which then manage to get the coin to Wallet 1KNCQ who gives it back to 15r1c all in the same second, which means they all get rolled up in the same block, incurring a total of 1.39454 BTC worth of Tx Fees. And so on and so forth.... This is but an example of why some blocks have HUGE Tx Fees.
You go around looking at some of these wallets, and you can see some pretty amazing amounts of coin doing neat tricks!
There's lot's of Tx mixers out there, but these blokes prolly used a horse like this one
http://i1276.photobucket.com/albums/y462/staffpicks/Animated_GIFs/horsears_zpsc0a8b98c.gif
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
Lucko is a moronic douchenozzle - I've reported it for double posting and for being an anus in general... 
There's a wee linky under it's name 'ignore' - use it! I do!
There's a wee linky under it's name 'ignore' - use it! I do!
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
Rate of invalid blocks is getting ridiculous,
18120 2013-05-20 15:38:18 0:04:08 Processing... 237069 25.16931001 99 confirmations left
Is not even found in blockchain.info
18120 2013-05-20 15:38:18 0:04:08 Processing... 237069 25.16931001 99 confirmations left
Is not even found in blockchain.info
Hmm, Bitminter have had 2 invalids in last 12 days - we have had 9... I think there is something wrong now...
Make that 10 - two in a row today now - 18120 and 18121
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
haha damn i wish i had that mining all for myself 
boy with the recent luck the pool has been having i'm glad i jumped ship
yer right doesn't need...then why are they on btcguild?
Saw him over 13TH/s yesterday
boy with the recent luck the pool has been having i'm glad i jumped shipAsicminer doesn't need a pool he hashes more than slush pool on his own lol
yer right doesn't need...then why are they on btcguild?
Saw him over 13TH/s yesterday
We're pretty happy you jumped ship too!
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
you have to accept the odd 6 or 8 hour drudge too
Especially when the difficulty has increased -which went up approximately 11% from 10076292 to 11187257 about 4 days ago...
[EDIT] and now we had a six hour round, the shares will take some time to calculate - queue the large quantity of posts from some people about round calculations showing 'none', then a few posts later 'it seems to have corrected', then a few posts later 'yeah but there must be something wrong', then a few posts later 'where is slush', etc, etc, etc...
And who is be saying any such thing about - besides you?
I has not be saying the bad things about the slushy - I like them
It's posts like these that keep me coming back for more!! *LoooL!!!*
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
Man, all the Fear/Uncertainty/Doubt you can dish up.
All the blocks I've seen with incorrect payouts were eventually corrected. I see some people freak out just after "Processing..." is completed. It's clear there are multiple calculations on different boxes to get the final number. I suspect on some of the blocks with "short" payouts, one of the boxes is missing from that calc. You can refresh and watch it grow in 3rds...
I think the pool is better than ever. He moved to a more stable host (and faster IMHO).... I think he's tired of having 5000 employees and having a handful of those who work the least complain the most.
He's recalculating "short" blocks... it seems correct... but I tell you what. Log your next block session, don't lose the logs, and come back and complain with some REAL evidence you're being shorted. Coming on here and bitching about what you suspect doesn't do anyone any favors.'
There are logging options in cgminer. Use them, do the math, and then come back with real evidence and make some real accusations. The pool has never been stronger.... He reacted to a theft, and a DDoS attack, and it's still going strong. All the while, maintaining a good attitude and helping people. Give the guy a break... and we'll see you back next block with some real evidence, right?
You relay don't get it. I had log and this is first time in 10 days someone asked for it. I have explained how I know what I know in forum and also why I can't post them directly. Read back and you will figure it out why none asked to have them. And I'm not the only one who had this problem so realy. I'm not moving back just to give you a log. I'm not stupid. Since I moved I didn't have to make a single complaint about payouts and look at a single log since all is as it should be. Last days at Slush were:"Hell what was wrong with this one, this one and this one...", connecting to miners to see why they are not submitting shares seeing everything is OK and hoping it will fix out. Hell no I don't need this drama. I like that I only need to refresh a page once a day and see all is well. It is relaxing.All the blocks I've seen with incorrect payouts were eventually corrected. I see some people freak out just after "Processing..." is completed. It's clear there are multiple calculations on different boxes to get the final number. I suspect on some of the blocks with "short" payouts, one of the boxes is missing from that calc. You can refresh and watch it grow in 3rds...
I think the pool is better than ever. He moved to a more stable host (and faster IMHO).... I think he's tired of having 5000 employees and having a handful of those who work the least complain the most.
He's recalculating "short" blocks... it seems correct... but I tell you what. Log your next block session, don't lose the logs, and come back and complain with some REAL evidence you're being shorted. Coming on here and bitching about what you suspect doesn't do anyone any favors.'
There are logging options in cgminer. Use them, do the math, and then come back with real evidence and make some real accusations. The pool has never been stronger.... He reacted to a theft, and a DDoS attack, and it's still going strong. All the while, maintaining a good attitude and helping people. Give the guy a break... and we'll see you back next block with some real evidence, right?
Now if only we didn't have to read you go on and on and on and on about it.... yeesh - you're glad you're gone, and so are we - have fun blathering on at your new pool thread....
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
Anyone had read this???
http://www.electronista.com/articles/13/05/14/reasoning.for.court.ordered.shutdown.unclear/
http://www.electronista.com/articles/13/05/14/reasoning.for.court.ordered.shutdown.unclear/
That's it! Party's over! Everyone, out of the pool!
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
I just moved to bitminter, because i feel like i am missing out on profit from nmc, if slush adds nmc, ill be back.
Lol - good riddance to you and any others. You wouldn't know a good pool if you drowned in it! I defy any miner on slush pool to post a graph showing a daily decrease in their earnings.
Yea sure a couple blocks had funky payouts - I don't give a crap if it's variance or even a bug, because there is no detectable decrease in my earnings.
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
I will ask again, am I the only one seeing this:
Date: 30.5.2013: Reward 425.26716892714285 BTC
Date: 30.5.2013: Reward 506.74909089 BTC
at mining.bitcoin.cz graphs
Date: 30.5.2013: Reward 425.26716892714285 BTC
Date: 30.5.2013: Reward 506.74909089 BTC
at mining.bitcoin.cz graphs
I assume you are wondering why there are two values for a given day - even though you don't make that clear at all...
You are looking at two functions plotted on same graph - a 7 day moving average and the actual data point for the day...
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
I keep seeing a lot of people that I think are confused how pooled mining works.
We aren't all doing part of a big problem, and a round is not just one block. Every time the network finds a block the problem changes cause they are all a chain. A share isn't a piece of a puzzle it's a lottery ticket. And we are all pooling our lottery tickets in hope one of us wins with the agreement we all split the proceeds. So this %CDF isn't coverage of a problem space it's just a probability that a winning lottery ticket will be made for the latest link of the chain.
The real trick is that we are all working on low difficulty attempts so we can make lots of them in the hopes that by chance we'll hit one that is above the required difficulty.
Or at least this is what I'm pretty sure is the case usual disclaimer applies I'm not an expert.
We aren't all doing part of a big problem, and a round is not just one block. Every time the network finds a block the problem changes cause they are all a chain. A share isn't a piece of a puzzle it's a lottery ticket. And we are all pooling our lottery tickets in hope one of us wins with the agreement we all split the proceeds. So this %CDF isn't coverage of a problem space it's just a probability that a winning lottery ticket will be made for the latest link of the chain.
The real trick is that we are all working on low difficulty attempts so we can make lots of them in the hopes that by chance we'll hit one that is above the required difficulty.
Or at least this is what I'm pretty sure is the case usual disclaimer applies I'm not an expert.
I'm not an expert on the btc protocol per se, but I do understand the mathematics involved, and this is a very good and succinct description for lay people. However, the %CDF is not really a probability, but a measure of how many blocks of this difficulty one would "normally" expect to have been found after this many lottery tickets (shares) have been cast.
EDIT - odd as it may seem, the actually probability that share N finds the block is exactly the same as the probability that share 1 will find it.
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
No - there is definitely something wrong here. I'm not being paid for any blocks anymore
17774 2013-04-30 20:25:35 2:03:23 14233698 132 0.00000000
17775 2013-04-30 23:59:52 3:34:17 24772020 145 0.00000000
17776 2013-05-01 02:25:35 2:25:43 16453036 13 0.00000000
I have moved over to another pool, and I'm not having problems there with zero returns per block, even if my share counts are low.
17774 2013-04-30 20:25:35 2:03:23 14233698 132 0.00000000
17775 2013-04-30 23:59:52 3:34:17 24772020 145 0.00000000
17776 2013-05-01 02:25:35 2:25:43 16453036 13 0.00000000
I have moved over to another pool, and I'm not having problems there with zero returns per block, even if my share counts are low.
The problem here is that these are fairly long blocks, and the scoring system works in such a way that shares done towards the end count more than at the beginning, but the flip to this is that with slow share submission at the end it could look like you were not sending anything and your score would be decaying faster than you were adding shares. Even if this was done with the simple calc of (your shares / total shares) * 25 * 0.98, you only be looking at 0.0002. And and average submission rate of a bit more than 1 share per minute. While slush's pool is pretty nice for most people, I don't think it is a great solution for such a low hash rate. You're just getting unlucky with score decay and too steep of a curve at the end.
Hmmm, if this is indeed the case, I would expect it to be fairly straightforward to have the decay rate depend on the average hash rate...? Actually expected this would be the case.
If this isn't easy to do though, I don't think Slush would put a huge effort in for tiny miners.
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
17719 seems to be suspiciously light in rewards. Thanks
Slush, I find the same. Something odd with 17719...
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
On a total side note.....
http://www.cbc.ca/news/business/story/2013/04/26/business-bitcoin-tax.html
Which means i've got to start generating reports for the end of this year (this is my first year bitcoin mining and barely have over 0.01 BTC so far, not counting the pool)
May have to get Slush to send me a T4-BTCI form at the end of the year ( revenue canada income tax form lol )
http://www.cbc.ca/news/business/story/2013/04/26/business-bitcoin-tax.html
Which means i've got to start generating reports for the end of this year (this is my first year bitcoin mining and barely have over 0.01 BTC so far, not counting the pool)
May have to get Slush to send me a T4-BTCI form at the end of the year ( revenue canada income tax form lol )
OMG too freekin' funny! I was looking in the comments on this article and LMFAO'd on this:
http://i43.tinypic.com/4meix.jpg
Re: [8500 GH/s] Slush's Pool (mining.bitcoin.cz); TX FEES + UserDiff; ASIC tested
At what time UTC did the pool become compromised?
From my logs, the first rejected share was at 23/04/2013 15:30:40 which is UTC-6, so 23/04/2013 21:30:40 UTC I make it.