For a valid ticket mask, think of network mask and CIDR notation.   
When visualizing a CIDR in bit form, a mask with 0's scattered between 1's is not valid.

Starting at 4GHs, every time the hash rate double(s) its worth tacking a bit onto the mask.
If the 2Pac ever push past 1TH(s), then I'll add a todo to check if the other bytes do what they are suppose to.

--

The chip iterates 2^32 nonces instead of 0 to max nonce. 
To experiment with SNO you probably need to pair it with HCN.

Recall all the advice that's been given to you already.

Yes, it includes all the latest updates from ck's repository.
Including some related to system libusb that has sent my windows build example back to the drawing board. 
   
The entry page to my repository should say "This branch is N commits ahead of ckolivas:master. ".
If it's ever "commits behind" just let me know.

_data[36] = (byte)((difficulty >> 24) & 0xff);
_data[37] = (byte)((difficulty >> 16) & 0xff);
_data[38] = (byte)((difficulty >> 8) & 0xff);
_data[39] = (byte)(difficulty & 0xff);

It is not big endian.

I do not think that this is exactly what your miner received from the pool. I think what you are seeing is based on an internal representation of the data which makes it appear to be different than what it actually is.

That is what is being displayed, but that is not what it actually has to be in the block header.

Because your miner is displaying that information incorrectly.

The correct block hash is f90f78da7e91f335617b9ad9bb8eb96cfab30431cd7a0b000000000000000000. You will notice that if you byteswap this so that it is actually in big endian, the block hash becomes 0000000000000000000b7acd3104b3fa6cb98ebbd99a7b6135f3917eda780ff9 which is an actual block that you look up on a block explorer or node. Looking up what your miner is displaying in both its original form and byteswapped form results in not being able to find such a block.

No, everything in Bitcoin is serialized as little endian. Actually, this is serialized as big endian, but in kind of a strange way. It seems like it is being printed out with each 4 byte chunk (32 bit integer length) in big endian, which also means that the merkle root and previous block hash fields are messed up. But this is not the actual block header it is hashing.

This is the correct block header. Everything is in little endian as it should be. This is what the block header should look like.

The second one.

I highly suggest that you read Bitcoin.org's documentation on the raw transaction format as that is basically what you are being given by the stratum protocol. All it is giving you is the entire coinbase transaction with some parts missing that the miner needs to fill out. Those are the nonce and extra nonce which are part of the coinbase.

This is not a header. This consists of 4 different fields. The first 4 bytes are the transaction version number, the next byte is the number of inputs. The next 32 bytes are the transaction id of the transaction the input spends from. The 4 bytes after that are the index of the output that is being spent. In a coinbase transaction, the previous txid must be all 0's, and the output index must be 0xffffffff.

Yes, that is the length. It is the length of the scriptSig, which in a coinbase transaction, is known as the coinbase.

The first byte is a length specifier. The next 3 bytes are the block height. This is pursuant to BIP 34

No, this is not a separator. It is the sequence number. Every input has a 4 byte sequence number.

That's the transaction lock time, not "end".

These aren't actually length specifiers but rather just straight unicode text. The coinbase part of a coinbase transaction can contain basically anything it wants (except that it must begin with the block height and be less than 100 bytes) that does not have to conform to any particular serialization rules. So What this really represents is a newline (0a is newline) followed by ckpool and then another unicode separator and then /solo.ckpool.org/

No, this is incorrect. This contains more data than should be in a transaction output. What you have is some combination of the input data and the output data. This is actually the second half of the coinbase transaction which includes all of the outputs and part of the input data.

The only things in a transaction output are the value and scriptPubKey. So you should only have cCoinbaseValue and cScriptPubKey.

This is actually two values.

The 03 specifies the number of outputs. There are 3 outputs. The rest of that is part of the value.

This is part of the value. It should be combined with the last 4 bytes of the previous value as the full structure is a 64 bit integer. The full thing is 37a3954a00000000. This is the little endian encoding of the value (which is what Bitcoin uses). The value in decimal is 1251320631 satoshis.

Only part of this is the output script. That is 17a9144ab4b2aa35879fe47e6a16ea783494f9dcf615b787. The 72ddc0 is part of the next thing.

This is the part of the last 3 bytes of the previous thing which is the value of the next output. The value of this is 72ddc00000000000 which is 12639602 satoshis.

Only the 1976a914f4cbe6c6bb3a8535c963169c22963d3a20e7686988ac part is the scriptPubKey. This output is for the fee. The last 0 is part of the next thing.

This (with the previous trailing 0) is the value of the last output, which is 0 satoshis (yes that is allowed). You are also missing a 0 which you have included as part of the next thing, but that is actually part of this one.

Excluding the first 0 and the last 4 zero bytes, this is the scriptPubKey of the last output. It is an OP_RETURN output that commits the witness hashes of the block.

The last 4 bytes are the lock time.

This helped me when I played around with the stratum protocol a few years ago, might help you a bit (see "Building Local Work"): http://archive.is/CH9a0

This helped me when I played around with the stratum protocol a few years ago, might help you a bit (see "Building Local Work"): http://archive.is/CH9a0

2. Accepted shares can be a lower difficulty than the network diff, and just show you (and the mining software) that it's working

5. You can change the time, or the extra nonce. You can also get fancy with adjusting the merkle root. Mining space is practically unlimited.

No, not at all.

The coinbase transaction's txid is included as part of the merkle root. The construction of the merkle root is described here: https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L9. Basically you concatenate the txids of pairs of transactions and hash them, then concatenate pairs of hashes, and so on until there is only one hash remaining.

The fields Coinbase1, ExtraNonce, ExtraNonce2, and Coinbase2 are used to construct the coinbase transaction which pays the miner. The transaction id of that coinbase transaction is then used to construct the merkle root.

Those parameters are part of the transaction ids. All of those parameters except for transaction Ids[] are for constructing the coinbase transaction. It's txid is then used in the merkle root.

The merkle root is computed from the transaction ids.

j.extranonce2 = self.increment_nonce(j.extranonce2)
		coinbase = j.coinbase1 + self.extranonce + j.extranonce2 + j.coinbase2
		merkle_root = sha256(sha256(unhexlify(coinbase)).digest()).digest()

		for hash_ in j.merkle_branch:
			merkle_root = sha256(sha256(merkle_root + unhexlify(hash_)).digest()).digest()
		merkle_root_reversed = ''
		for word in chunks(merkle_root, 4):
			merkle_root_reversed += word[::-1]
		merkle_root = hexlify(merkle_root_reversed)

The answer is shares aren't worth anything but they don't consume much bandwidth and are used for feedback to the miner only to know they're mining successfully.