Bitcoin Forum
June 30, 2024, 08:27:25 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][ICO] Ziber - Revolutionary Blockchain Platform for IP-telephony on: July 09, 2017, 08:16:39 AM
Good idea, I will wait for full review.
2  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 19, 2014, 01:33:56 PM
Congratulations Slush's Pool!



24 hours mining, zero blocks found!

Current round duration:   1 day, 0:00:51
1 day Pool luck:   0%

A great moment in mining history.

I'll be celebrating by barbecuing some roadkill - it feels appropriate.

Okay Slush, we reached 24 hours, no need for overkill, can we have a block now pleeeeeease?
3  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 19, 2014, 12:30:12 PM
ONCE again a Big fail for Slush this is becoming far to common that rounds are not consistent hash rate continues to climb while pay out drops.  I have been a loyal miner on Slush since I began bitcoin mining and it saddens me that I am at a point where I will have to make a choice what is  the best use of my equipment.
I dont know about anyone else but I cant justify running nearly 1TH 24/7 and get one round in a day. just a complete waist of my equipment and electricity because this site cant seem to manage there equipment.

Not sure can hold out on this pool much longer.   


Would any one like to offer alternative pools and give reasons why they like each of them?Huh?

It's nothing to do with Slush's management of equipment, it's a simple matter of statistics.  I don't hear anyone complain when we get a 2 minute block, but you have to expect the occasional long block. The 7-day luck is well over 100%, and even the 30-day luck is over, so statistically, Slush's Pool is delivering better than what you might expect.
4  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 19, 2014, 12:26:07 PM
Has Slush's ever run longer than this block? 

yes

Slush block # 21746 which was found on 28/02/2014 11:00 took 21:59:22... so no record broken yet...


Definitely a record now, though...
5  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 11, 2014, 06:11:48 PM
I think I finally figured it out. My hashrates mean nothing. The total pool hashrate means nothing.
The less often that I check my stats on Slush's website, the more blocks get found and the shorter the rounds. When I log in to check the rounds a lot, the time to solve the blocks go up.

So, it's my fault when we have long blocks. Sorry about that! Cheesy

Keep looking away, it's working a treat! Tongue
6  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 11, 2014, 08:30:32 AM
Hey guys

Having trouble with ASIC Block Erupter 336 Mh/s. I bought off Ebay for a few dollars so it might not be me but I just wanted to check with you guys before returning to the guy. I'm having trouble getting my computer to recognize the device. I have downloaded the drivers from http://www.silabs.com/products/mcu/Pages/USBtoUARTBridgeVCPDrivers.aspx and installed them. When i got to my devices under unspecified i have  cp2102 us to uart bridge controller. I then open up my BFG miner enter all my pool information and worker information, but i have no devices that are being recognized and am unable to add any devices. Any input would be appreciated.

Thanks Red.

What configuration options are you using with BFGminer? it doesn't recognise devices 'out of the box', you need to tell it to look for specific devices, with the -S flag, for example -S icarus:all
You can also get BFGminer to detect devices if you press 'M', then '+' to add new devices.
If you can see the bridge controller in device manager, then it is probably working okay - the device it is showing is the USB controller for the ASIC chip on the stick.
Just one final note - at current difficulty, one of these will reach the minimum payout in over four months, and that isn't taking into consideration the periodic difficulty increases (the last one was over 20% IIRC). Once you get this one working, you may want to consider adding several more if you ever want to see the minimum payout, and don't expect to make a profit, unless you can get them for pennies!
7  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 09, 2014, 01:20:12 PM
Over 900TH/s
Well, lets hope we get a few sub 1 hour blocks to disprove the conspiracy theorists (they know who they are!)
8  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 06, 2014, 10:30:48 PM
Hey guys,

New to bitcoin mining. Joined slush's pool. This is just kinda something im playing with and dont expect to make any real money off of it. Currently running m gpu and getting about 75 Mhash/s. I dont really want to continue to use my GPU to mine. I was looking into ASICMiner Block Erupter 335 mh/s for around 25 dollars used. My question is are there any compatibility issues i will have with these or should it just be a plug in and mine type of deal? Like i said, i dont expect to make money just playing around, not trying to invest a couple grand into a unit to hash for me.

Thanks. Red

You should not have any compatibility issues. It is essentially plug and hash. But it depends on the software.

This - but shop around, you can get them for closer to $10 on eBay now. Don't expect to ever make your money back though, unless BTC go up crazily in price...

Just to add to that - you might do better with an Antminer U1 which work in the same way, but hash 6 times faster for around twice the price.
9  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 06, 2014, 10:28:51 PM
Hey guys,

New to bitcoin mining. Joined slush's pool. This is just kinda something im playing with and dont expect to make any real money off of it. Currently running m gpu and getting about 75 Mhash/s. I dont really want to continue to use my GPU to mine. I was looking into ASICMiner Block Erupter 335 mh/s for around 25 dollars used. My question is are there any compatibility issues i will have with these or should it just be a plug in and mine type of deal? Like i said, i dont expect to make money just playing around, not trying to invest a couple grand into a unit to hash for me.

Thanks. Red

You should not have any compatibility issues. It is essentially plug and hash. But it depends on the software.

This - but shop around, you can get them for closer to $10 on eBay now. Don't expect to ever make your money back though, unless BTC go up crazily in price...
10  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 02, 2014, 11:45:27 PM
Thanks for the vote of confidence guys, but I'm having trouble following the question and answers. Can someone boil post a precis of the question?

In short:

I noted that we had a 35 second block and suggested that this might be some sort of record - another poster mentioned that we once had a 2 second block, but it was invalid.
This got me thinking that this situation must be extremely unlikely to happen, since the odds of a block lasting 2 seconds are quite short, and the odds of two pools finding a two second block at the same time would be even shorter. A quick estimate of the odds, if my understanding of the maths is right, is that the probability of a block being 2 seconds or less is around 0.001, so two at the same time would be around 0.000001, or 1 in 1 million (as pointed out by another poster, the odds of there being a 'race' between these two would be close to one because the block time is so short, rather than 1 in 60, which seems to be the approximate rate of orphaned blocks in the network)
This led me to wonder whether there is something about the (double) SHA256 algorithm that might lead to hash collisions being more likely for certain blocks, so that these blocks rather than being expected to last on average 10 minutes, would have much lower than expected difficulty. This might shorten the odds of there being an orphaned 2 second block. I don't know how possible this actually is, given that the block contains the address of the pool doing the hashing, so that the actual block being computed by two pools would differ.
So, I suppose what I am asking is whether my estimates seem fair, or if I have got the maths all wrong, and whether it is plausible that the hashing algorithm could lead to collisions in this way, causing the occasional block to be much easier to solve, for certain pools, or the network as a whole. I appreciate that cryptanalysis is far from a simple topic, so the second question is really more rhetorical.
11  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 02, 2014, 07:21:47 PM

By extremely short blocks, you can't account for mean orphan probability. By a two-second block, probability of orphan race is extremely high, near to 100% IMHO, as the time differences between the good and the orphaned block normally are of the same size as is the block duration by a 2-second block. So I think you must leave out your "60" multiplier.

Good point - the odds still work out at around 1 in 1000000, but as Terry Pratchett once wrote, million-to-one chances happen nine times out of ten. Smiley

I still wonder if the contents of some blocks can make the difficulty vary significantly from the assigned difficulty though. Perhaps there is a weakness in (double) SHA256 where hash collisions are more likely with certain values?
Maybe OrganOfCorti can help us out on this one? Any crypto experts around? Where's Bruce Sterling when you need him...
12  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 02, 2014, 11:24:05 AM
My understanding is that when two pools find the 'same' block, they are actually finding different hashes that meet the difficulty requirement (please correct me if I am wrong). In this case, given that the network difficulty makes this so that the expected block length is ten minutes, and invalid blocks are not that common (IIRC, we have seen two in the last month or so), I am quite surprised that there should be such a 'collision' on a two-second block - surely the odds of this happening would be vanishingly small, unless there is something intrinsic that makes the difficulty on certain blocks much lower than it should be.

Not only different hashes; each pool assembles its own block from the available transactions in the transaction pool according to its rules. So the "same" block can potentially differ between the two pools in the sense it contains different transactions.

The last idea is quite interesting. Can someone have enough will and power to check it? :-)
[edit] I'd sure not say vanishingly, but the chance is of course smaller for two pools at once than it is for one pool.

I would have thought that the probability of two people finding a sub 2-second block, at the same time would be the probability of one finding it, squared.
Assuming the block difficulty is correct, at the moment, we are on block 288579. 
I don't know how many 2 -second blocks there have been so to make the numbers easier, lets guess at around 300, which makes the odds of a given block being less than 2 seconds around 1 in 1000, or 0.001.
From the statistics on blockchain.info, it looks like there are around 2.5 orphaned blocks per day. The total number of blocks each day is tuned to be 144 (one every ten minutes), so dividing this by 2.5 gives around 60, or a 1 in 60 chance of there being such a collision on a given block.
if my maths is right, this means there is a a 1 in 1000 chance of each participant hitting a 2 second block, so multiply these together to get 1 in 1000000, and there is a 1 in 60 chance of there being a collision in this way, so the odds of this happening would be roughly 1 in sixty million. To put this in perspective, you have a 1 in 600000 chance of being struck by lightning, and this would appear to be some 100 times less likely!

Now, further up there, I made an assumption - that the block difficulty is 'correct'. As I understand it, the block difficulty essentially defines how many leading zeroes must be in a block's hash for it to be considered 'solved'. For example, the last block (found by us!) had a hash of 0000000000000000d69d39dbe4e025909fc30b4be52abfaccfec9315c497ac6c, the digits after the leading zeroes are irrelevant (which is what leads to block collisions in the first place, as two hashes can be found with the same number of leading zeroes).
The block itself is composed of the newly found hash, the hash from the previous block, the block number, difficulty and time, the pool's address, and all the transactions in that block (this is a simplified description), so my question is this - since the odds of two pools finding a 2 second block at the same time is so low (and I stick by 'vanishingly small' as a good description), is it possible that some blocks have more 'solutions' than are statistically expected - in other words, for some blocks, are there more solutions than expected with that number of leading zeroes?
For example, the hash above has 16 leading zeroes, in binary this is 128 leading zeroes, so if my understanding is correct, the odds of getting this out of any random hash would be 2^128.
Any thoughts?
13  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 02, 2014, 12:16:50 AM
Holy crap - a 35 second block - that has to be some kind of record!

naw, i saw a 20 second block once.

I remember a 14 second one. And it's not been too long ago.
And a 4 second one last year.

Shortest I ever seen was block 239570 found by slush on 2013-06-03 in just 2 seconds. Unfortunately it was invalid for us...



I guess there must be some minimum amount of time for a block to be seen by the network before the next block can be found?

I'm not sure about a minimum time, it was just that another pool found the same 2 second block and reported it to the network before we did.

My understanding is that when two pools find the 'same' block, they are actually finding different hashes that meet the difficulty requirement (please correct me if I am wrong). In this case, given that the network difficulty makes this so that the expected block length is ten minutes, and invalid blocks are not that common (IIRC, we have seen two in the last month or so), I am quite surprised that there should be such a 'collision' on a two-second block - surely the odds of this happening would be vanishingly small, unless there is something intrinsic that makes the difficulty on certain blocks much lower than it should be.
14  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: March 01, 2014, 11:33:28 PM
Holy crap - a 35 second block - that has to be some kind of record!

naw, i saw a 20 second block once.

I remember a 14 second one. And it's not been too long ago.
And a 4 second one last year.

Shortest I ever seen was block 239570 found by slush on 2013-06-03 in just 2 seconds. Unfortunately it was invalid for us...



I guess there must be some minimum amount of time for a block to be seen by the network before the next block can be found?
15  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: February 28, 2014, 11:53:05 PM
Holy crap - a 35 second block - that has to be some kind of record!
16  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: February 28, 2014, 10:23:19 PM
It seems some people start to get it - our hashrate increases after some bad luck instead of when we got a good luck ... I hope this will help crossing the 900TH line and show that, it's not a limit in any way, so here is a prediction:
 This round (currently 1h 8min) will last between 1h 30min and 2h 15min
 There will be at least 2 rounds below 3h in the next ~14h (by 13:00 UTC)


And........ Nope Sad

Yet..... Grin

Well, there's one very sub-3 hour block  Smiley
17  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: February 25, 2014, 07:24:33 PM
An insider has scammed us from our blocks of work.  The website dose not display the blocks from the last 22 hours and so someone has disabled it and stole our mining contribution to benefit himself i dont trust slush i will jump to another pool.

thats impossible not with 850TH/s

Yes I agree its not impossible i will jump too.

You could, of course, just check on blockchain.info to confirm that this is not the case.
https://blockchain.info/blocks

 Roll Eyes
18  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: February 25, 2014, 12:54:23 PM
Are we finally going to reach the mythical 24h block?


20hrs and counting...


1 block a day...

btc under $500...


we're all doomed...Wink

21 hours - RUN FOR THE HILLS! Grin
19  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: February 25, 2014, 11:04:22 AM
Are we finally going to reach the mythical 24h block?
20  Bitcoin / Pools / Re: [850 TH] Slush's Pool (mining.bitcoin.cz); TX FEES + VarDiff on: February 20, 2014, 01:09:59 PM
Man, 2 12 hour blocks in a row is depressing.

So is a current Bitcoin price of under $600

The flip-side of that though, is that people buying hardware with BTC will wait until the value bounces back, so our existing GH/s will be less diluted until it does.  And only a few days ago, we had six blocks in 2 hours, so don't despair!
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!