Butterfly Labs - Bitforce Single and Mini Rig Box

[stevegee58]

Is that anything like noncense?

[1715199651]

1715199651

[1715199651]

1715199651

[1715199651]

1715199651

[WhitePhantom]

In security engineering, nonce is an arbitrary number used only once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks...

http://en.wikipedia.org/wiki/Cryptographic_nonce

[420]

In security engineering, nonce is an arbitrary number used only once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks...

http://en.wikipedia.org/wiki/Cryptographic_nonce

and the purpose?

[crazyates]

In security engineering, nonce is an arbitrary number used only once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks...

http://en.wikipedia.org/wiki/Cryptographic_nonce

and the purpose?

It's a variable. The way bitcoin hashing works, you input variables, and you output a hash. Variables -> Hash

Bitcoin mining has several variables that are constantly changing, so we constantly have new work to do. Variables can include new transactions, timestamp, and what's called a nonce range.

This wiki graph shows all (well not all, but most) of the variables, and when they are updated.

Even a single digit change can drastically change the completed hash, so the nonce range has 2^32 different possibilities. This gives us 2^32 different hashes, even before any other variable can change.

Every time you hash, your miner adds +1 to the nonce, tries it again, and gets a completely different hash. Repeat several bazillion times.

[420]

In security engineering, nonce is an arbitrary number used only once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks...

http://en.wikipedia.org/wiki/Cryptographic_nonce

and the purpose?

It's a variable. The way bitcoin hashing works, you input variables, and you output a hash. Variables -> Hash

Bitcoin mining has several variables that are constantly changing, so we constantly have new work to do. Variables can include new transactions, timestamp, and what's called a nonce range.

This wiki graph shows all (well not all, but most) of the variables, and when they are updated.

Even a single digit change can drastically change the completed hash, so the nonce range has 2^32 different possibilities. This gives us 2^32 different hashes, even before any other variable can change.

Every time you hash, your miner adds +1 to the nonce, tries it again, and gets a completely different hash. Repeat several bazillion times.

okay so it's the 'randomizer' thanks!


but now what decides what hash its looking for when it checks to see if it 'won'

[crazyates]

In security engineering, nonce is an arbitrary number used only once in a cryptographic communication. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks...

http://en.wikipedia.org/wiki/Cryptographic_nonce

and the purpose?

It's a variable. The way bitcoin hashing works, you input variables, and you output a hash. Variables -> Hash

Bitcoin mining has several variables that are constantly changing, so we constantly have new work to do. Variables can include new transactions, timestamp, and what's called a nonce range.

This wiki graph shows all (well not all, but most) of the variables, and when they are updated.

Even a single digit change can drastically change the completed hash, so the nonce range has 2^32 different possibilities. This gives us 2^32 different hashes, even before any other variable can change.

Every time you hash, your miner adds +1 to the nonce, tries it again, and gets a completely different hash. Repeat several bazillion times.

okay so it's the 'randomizer' thanks!

but now what decides what hash its looking for when it checks to see if it 'won'

That's where the difficulty comes in.

Imagine you're pulling numbers from a hat. There's 100 numbers, and if you get higher than 5, you win a prize! But you're winning too often, so I increase the number to 20. Three more people join you, so now I"m getting a winner 4x as often, so I increase the number to 80. Now I'm giving out the same number of prizes, but you're now winning 1/4 of the number of times you used to. I'm selfish and feeling evil, so I increase the number to 99. Now it's a LOT harder to get a winner, but it will happen eventually.

That's (sort of) what difficulty does.

[kano]

Just to clarify
For each hash you do you hash a bunch of bytes. They are (in order)
version (= 1) - 4 bytes
Previous block - 32 bytes
Merkle Root - 32 bytes
Time - 4 bytes
Block Difficulty - 4 bytes
Nonce - 4 bytes

Now of those 6 - 3 of them cannot be changed: version, previous block, block difficulty
Next is Merkle Root - that is not changeable in normal pool work (this is a subject of discussion at the moment of effectively moving all the work the pool does to the miner ... so the pool is simply just a share counter ... start billing them for your work!)

That leaves Time and Nonce.

So you get a work item from the pool that has all but the nonce defined, then you start a counter of the nonce from 0 to 0xffffffff and for each value you hash the combination of the 6 and check if the result is below the required difficulty.

So the Nonce is actually just a counter so you can try 4billion hashes with each item of work the pool has given you.

Changing a single bit in the 6 pieces of data (as in the normal example incrementing the nonce by one) produces a completely different hash result.

... and to add my previous comments on the subject ... yes that is just like MSDOS - Satoshi decided that a nonce size of 32bits was big enough - when in fact it is already too small - and when ASIC comes out it will be VERY noticeable. There is enough space to simply make it 128 bits and thus last 'many' years into the future. However that requires a hard fork and we all know the bitcoin devs are hopeless at forks and as a result - we get the good old MSDOS hack solutions to solve the problem - the first one was roll-n-time so miners simply change the time field - thus why the time field in a block is next to meaningless. The next solution is to have the miners do pretty much all the work the pools should be doing - so in my opinion they should also charge the pools for doing all their work if that is implemented

[crazyates]

Just to clarify
For each hash you do you hash a bunch of bytes. They are (in order)
version (= 1) - 4 bytes
Previous block - 32 bytes
Merkle Root - 32 bytes
Time - 4 bytes
Block Difficulty - 4 bytes
Nonce - 4 bytes

Now of those 6 - 3 of them cannot be changed: version, previous block, block difficulty
Next is Merkle Root - that is not changeable in normal pool work (this is a subject of discussion at the moment of effectively moving all the work the pool does to the miner ... so the pool is simply just a share counter ... start billing them for your work!)

That leaves Time and Nonce.

So you get a work item from the pool that has all but the nonce defined, then you start a counter of the nonce from 0 to 0xffffffff and for each value you hash the combination of the 6 and check if the result is below the required difficulty.

So the Nonce is actually just a counter so you can try 4billion hashes with each item of work the pool has given you.

Changing a single bit in the 6 pieces of data (as in the normal example incrementing the nonce by one) produces a completely different hash result.

... and to add my previous comments on the subject ... yes that is just like MSDOS - Satoshi decided that a nonce size of 32bits was big enough - when in fact it is already too small - and when ASIC comes out it will be VERY noticeable. There is enough space to simply make it 128 bits and thus last 'many' years into the future. However that requires a hard fork and we all know the bitcoin devs are hopeless at forks and as a result - we get the good old MSDOS hack solutions to solve the problem - the first one was roll-n-time so miners simply change the time field - thus why the time field in a block is next to meaningless. The next solution is to have the miners do pretty much all the work the pools should be doing - so in my opinion they should also charge the pools for doing all their work if that is implemented

Thanks for that. I started thinking about this earlier, and posted my thoughts here, but I'll ask you here now.

1) As of right now, how often does a new header (with a new merkle root) get pushed to a miner?

2) How far forward can rollNtime go into the future and still solve a valid block?

3) I'm assuming miners > 4GH/s (miners that process more than the entire nonce range every second) just keep rolling the time by +1 second until they receive a new header? This is basically why I'm asking questions 1 and 2.

[freshzive]

I get 0.35% on OzCoin with my BFL ... averaging 870MH/s or higher with the 880MH/s bitstream.

This is using ozcoin, so I'm guessing switching to another pool wouldn't help? Strange my rejects are higher though. I can't imagine that 1% would be due to latency? Ping times to the pool around ~50ms.

Did you take the cases off to get them all stable at 880?

[jddebug]

I get 0.35% on OzCoin with my BFL ... averaging 870MH/s or higher with the 880MH/s bitstream.

This is using ozcoin, so I'm guessing switching to another pool wouldn't help? Strange my rejects are higher though. I can't imagine that 1% would be due to latency? Ping times to the pool around ~50ms.

Did you take the cases off to get them all stable at 880?

I always got high rejects at Ozcoin too. I've been using 50btc (pps only) with rejects at less than 0.2 % or better. I don't know what the difference is but I'm not complaining.

[freshzive]

Hmmm. I was running cgminer2.4.3, upgraded to 2.7.3 to see if that helps.

Any other cgminer flags I should be using?

[crazyates]

I get 0.35% on OzCoin with my BFL ... averaging 870MH/s or higher with the 880MH/s bitstream.

This is using ozcoin, so I'm guessing switching to another pool wouldn't help? Strange my rejects are higher though. I can't imagine that 1% would be due to latency? Ping times to the pool around ~50ms.

Did you take the cases off to get them all stable at 880?

I always got high rejects at Ozcoin too. I've been using 50btc (pps only) with rejects at less than 0.2 % or better. I don't know what the difference is but I'm not complaining.

I'm on Ozcoin with CGMiner 2.7.0, and I'm getting ~0.7%.

[freshzive]

I get 0.35% on OzCoin with my BFL ... averaging 870MH/s or higher with the 880MH/s bitstream.

This is using ozcoin, so I'm guessing switching to another pool wouldn't help? Strange my rejects are higher though. I can't imagine that 1% would be due to latency? Ping times to the pool around ~50ms.

Did you take the cases off to get them all stable at 880?

I always got high rejects at Ozcoin too. I've been using 50btc (pps only) with rejects at less than 0.2 % or better. I don't know what the difference is but I'm not complaining.

I'm on Ozcoin with CGMiner 2.7.0, and I'm getting ~0.7%.

Yeah, it was the version. Upgraded to 2.4.5. 5,000 shares in and i'm at ~0.55%

[kano]

After: 3 days and ~10 hours

Code:

 cgminer version 2.7.5c - Started: [2012-09-05 13:13:53]
--------------------------------------------------------------------------------
 (5s):435.2 (avg):869.7 Mh/s | Q:5065  A:59763  R:170  HW:0  E:1180%  U:12.1/m
 TQ: 0  ST: 3  SS: 10  DW: 508  NB: 643  LW: 104211  GF: 3  RF: 10  WU: 12.2
 Connected to http://au.ozco.in:8331 with LP as user ....
 Block: 000003332aeda236a9bccec36dd9623f...  Started: [23:14:18]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 BFL 0:  50.8C         | 870.9/869.7Mh/s | A:59756 R:170 HW:0 U:12.14/m
--------------------------------------------------------------------------------

Now, not all shares are going to Ozcoin
Ozcoin was 59,503 Accepted and 141 Rejected
But that's ~0.24%

Also note - I'm using 8331 - i.e. no NMC, no merged mining and certainly no extra NMC LPs

(3 days and 10 hours ago I moved it down to my basement garage where the other mining hardware is - coz it was hitting as high as 60C up here and throttling almost every hour - winter ended and spring just started here)

Also note that I'm in Aus and the pool server au.ozco.in is in the USA ... and I get a ping of ~225ms from my rig
... checking my API stats, the minimum Ozcoin pool wait time is 0.399577s and of course Ozcoin is roll-n-time - so that's why I get >1000% efficiency also

Edit: oh and the cases - no, the case is on with the fan blowing out the top
The BFL version is: single fan on top, no fan underneath new heatsink on top
As far as I can tell, the throttling hardware in mine is fscked - which works well to my advantage allowing it report higher temps with the 880 bitstream before it throttles - last week, the day before I moved it downstairs, it was running at up to 57C without throttling at all

[freshzive]

Now I'm getting strange issues with 2.7.5:

Code:

[2012-09-08 14:24:57] BFL0: took 20243ms - longer than 7000ms

2 of my units are showing a high # of HW errors all of a sudden. Arrrrrgh!!

[freshzive]

And this:

Code:

[2012-09-08 14:27:17] BFL0: took 20243ms - longer than 7000ms
 [2012-09-08 14:27:17] BFL0: Error: Send work reports: NO-NONCE

 [2012-09-08 14:27:17] BFL-502994848: Garbled response probably throttling, clearing buffer
 [2012-09-08 14:27:22] BFL0: Comms error

Maybe I should downgrade? This wasn't happening at all using the old version.

This too:

Code:

BFL: Error reading/timeout (ZGX)

[kano]

Now I'm getting strange issues with 2.7.5:

Code:

[2012-09-08 14:24:57] BFL0: took 20243ms - longer than 7000ms

2 of my units are showing a high # of HW errors all of a sudden. Arrrrrgh!!

That's a throttle

[freshzive]

That's a throttle

Yeah, but it wasn't happening at all (running for weeks without stop) using cgminer 2.4.3 so that doesn't really make sense to me.

[The00Dustin]

Yeah, but it wasn't happening at all (running for weeks without stop) using cgminer 2.4.3 so that doesn't really make sense to me.

I think throttles showing as HW errors and being listed in the output was a feature added later than 2.4.3.  IOW, you didn't see it was throttling before, but that doesn't mean it wasn't.

[freshzive]

Yeah, but it wasn't happening at all (running for weeks without stop) using cgminer 2.4.3 so that doesn't really make sense to me.

I think throttles showing as HW errors and being listed in the output was a feature added later than 2.4.3.  IOW, you didn't see it was throttling before, but that doesn't mean it wasn't.

If you look at my earlier post, the units were all running within ~20Mhash of the firmware speed. With this throttling, they are now running 1-200MH below firmware speed (one is averaging 600). This level of throttling couldn't have been happening before