If they are going to adjust their prices based on BTC going up or whatever, they probably want to adjust it down when it drops.
They will not do that until the units stop selling. 
Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 493. (Read 5352367 times)
February 06, 2018, 09:16:49 AM
February 06, 2018, 09:14:30 AM
If they are going to adjust their prices based on BTC going up or whatever, they probably want to adjust it down when it drops.
February 06, 2018, 08:45:33 AM
February 06, 2018, 08:26:33 AM
Anyone who noticed ... the DB restarted again just now.
This is the same cause as the other day.
No mining is affected.
I've not applied the fix yet - though the problem has existed for years, just unlucky I guess it's happened twice in a few days.
Mine on!
Edit: KanoDB reload completed at 06:16:47 UTC
This is the same cause as the other day.
No mining is affected.
I've not applied the fix yet - though the problem has existed for years, just unlucky I guess it's happened twice in a few days.
Mine on!
Edit: KanoDB reload completed at 06:16:47 UTC
Each time this happens the CKPool Status app on my phone says that we found a block.
If only I could make blocks appear like that - though it did often seem that way in the distant past that we'd all too often find blocks on restarts February 06, 2018, 08:15:47 AM
Anyone who noticed ... the DB restarted again just now.
This is the same cause as the other day.
No mining is affected.
I've not applied the fix yet - though the problem has existed for years, just unlucky I guess it's happened twice in a few days.
Mine on!
Edit: KanoDB reload completed at 06:16:47 UTC
This is the same cause as the other day.
No mining is affected.
I've not applied the fix yet - though the problem has existed for years, just unlucky I guess it's happened twice in a few days.
Mine on!
Edit: KanoDB reload completed at 06:16:47 UTC
Each time this happens the CKPool Status app on my phone says that we found a block.
February 06, 2018, 05:42:17 AM
So, I felt the urge to ramble on about Bitcoin again since this block is pissing me off probably as much as everyone else here
Rather than try to edit in and out of the various posts ... here's how mining works
Firstly, mining is exactly the same as rolling a dice ... except for the number of possible solutions!
When you roll a dice, you have a 1 in 6 chance of getting a 6.
There's no progress to getting a 6, ever. You either get a 6 or you don't.
One try = yes or no. No history involved.
With Bitcoin the dice actually has 2^256 sides - yeah that's a pretty big number ~1.579x10^77
And ... there's more than one solution that's valid.
Any "side of the dice" that has enough zeros on the front, and is less than a specified value, is a block.
Of that ~1.579x10^77 number, the current difficulty decides how many sides mean we found a block.
The current difficulty is actually "0x176c2146" which is called "bits" and is 4 bytes of the data we hash.
"0x17" = 23 decimal and 32-23 = 9 bytes of leading zeros (i.e. 9 times '00')
The rest is "0x6c2146"
So, what those 2 numbers mean is that any block hash with a hex value of
H=0x0000000000000000006c21460000000000000000000000000000000000000000 or less is a block
and if you divide 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff+1 (~1.579x10^77) by H and divide it again by 0x100000000 (2^32) you will get that network difficulty number:
Nd = 2,603,077,300,218.593
which means that every 2^32 times you roll the Bitcoin dice (i.e. hash a full nonce range) you have a 1 in 2,603,077,300,218.593 chance of finding a block.
... and the reason we divide by 0x100000000 again is that the network difficulty number of 1 represents 2^32 hashes
So ... that's how hashing works, but what are we actually hashing?
I wrote a document about it once, I'll repeat a little bit here:
The structure of a block header is an 80 byte binary data set, defined as follows:
Version 4 bytes
Previous Block Hash 32 bytes
Merkle Root 32 bytes
Block Time 4 byte Unix Timestamp
Required Hash Difficulty 4 bytes
Hash Nonce 4 bytes
So looking at that we can vary 3 things:
Merkle root, Block Time and Hash Nonce
Normal hashing is to setup everything except the Hash Nonce and then count the Hash Nonce from 0 to 2^32-1 and hash each one.
Hashing the full Nonce range from 0 to 2^32-1 is also called 1 difficulty.
With stratum we can modify the Merkle Root to generate a different block header to hash the Nonce range.
The Merkle Root is a hash tree of the transactions we include in the block, however there's one transaction that we can change with stratum, and that is the coinbase transaction - or the transaction that pays the miner.
In this transaction we only need to make sure that:
1) It's a valid transaction (which is actually pretty random for the coinbase transaction due to the "sig" being allowed to contain almost anything as long as it starts with 'height')
2) It pays out to the expected address we want to receive the generated Bitcoins
3) The amount it pays is correct
So for stratum we put a bunch of other 'nonces' in the coinbase sig, that includes a unique number for each miner, and run the others from 0 up to some specified limit to generate a different coinbase transaction each time, that will generate a unique Merkle Root, to be put in a block header, to be hashed over the full Nonce range.
Thus with the unique number for each miner, and the miner itself following the stratum rules for creating coinbase transactions, the miner can keep generating a large amount of work that isn't expected to run out before the pool sends it new work.
Lastly, every time the miner finds a hash value that is higher than the difficulty specified by the pool, the miner sends the nonce and the "sig" nonces back to the pool.
The pool hashes those nonces with the values it sent to the miner, and thus verifies it's valid, and thus rewards the miner with the difficulty of the work sent to the miner.
Now one more thing I'll add, that got mention a little while back, is that the miner can't modify the payout address to 'steal' the block.
The reason is that the pool wont get a valid hash of the nonces sent back, so the miner will get no reward. Simple
Rather than try to edit in and out of the various posts ... here's how mining works
Firstly, mining is exactly the same as rolling a dice ... except for the number of possible solutions!
When you roll a dice, you have a 1 in 6 chance of getting a 6.
There's no progress to getting a 6, ever. You either get a 6 or you don't.
One try = yes or no. No history involved.
With Bitcoin the dice actually has 2^256 sides - yeah that's a pretty big number ~1.579x10^77
And ... there's more than one solution that's valid.
Any "side of the dice" that has enough zeros on the front, and is less than a specified value, is a block.
Of that ~1.579x10^77 number, the current difficulty decides how many sides mean we found a block.
The current difficulty is actually "0x176c2146" which is called "bits" and is 4 bytes of the data we hash.
"0x17" = 23 decimal and 32-23 = 9 bytes of leading zeros (i.e. 9 times '00')
The rest is "0x6c2146"
So, what those 2 numbers mean is that any block hash with a hex value of
H=0x0000000000000000006c21460000000000000000000000000000000000000000 or less is a block
and if you divide 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff+1 (~1.579x10^77) by H and divide it again by 0x100000000 (2^32) you will get that network difficulty number:
Nd = 2,603,077,300,218.593
which means that every 2^32 times you roll the Bitcoin dice (i.e. hash a full nonce range) you have a 1 in 2,603,077,300,218.593 chance of finding a block.
... and the reason we divide by 0x100000000 again is that the network difficulty number of 1 represents 2^32 hashes
So ... that's how hashing works, but what are we actually hashing?
I wrote a document about it once, I'll repeat a little bit here:
The structure of a block header is an 80 byte binary data set, defined as follows:
Version 4 bytes
Previous Block Hash 32 bytes
Merkle Root 32 bytes
Block Time 4 byte Unix Timestamp
Required Hash Difficulty 4 bytes
Hash Nonce 4 bytes
So looking at that we can vary 3 things:
Merkle root, Block Time and Hash Nonce
Normal hashing is to setup everything except the Hash Nonce and then count the Hash Nonce from 0 to 2^32-1 and hash each one.
Hashing the full Nonce range from 0 to 2^32-1 is also called 1 difficulty.
With stratum we can modify the Merkle Root to generate a different block header to hash the Nonce range.
The Merkle Root is a hash tree of the transactions we include in the block, however there's one transaction that we can change with stratum, and that is the coinbase transaction - or the transaction that pays the miner.
In this transaction we only need to make sure that:
1) It's a valid transaction (which is actually pretty random for the coinbase transaction due to the "sig" being allowed to contain almost anything as long as it starts with 'height')
2) It pays out to the expected address we want to receive the generated Bitcoins
3) The amount it pays is correct
So for stratum we put a bunch of other 'nonces' in the coinbase sig, that includes a unique number for each miner, and run the others from 0 up to some specified limit to generate a different coinbase transaction each time, that will generate a unique Merkle Root, to be put in a block header, to be hashed over the full Nonce range.
Thus with the unique number for each miner, and the miner itself following the stratum rules for creating coinbase transactions, the miner can keep generating a large amount of work that isn't expected to run out before the pool sends it new work.
Lastly, every time the miner finds a hash value that is higher than the difficulty specified by the pool, the miner sends the nonce and the "sig" nonces back to the pool.
The pool hashes those nonces with the values it sent to the miner, and thus verifies it's valid, and thus rewards the miner with the difficulty of the work sent to the miner.
Now one more thing I'll add, that got mention a little while back, is that the miner can't modify the payout address to 'steal' the block.
The reason is that the pool wont get a valid hash of the nonces sent back, so the miner will get no reward. Simple
Thanks Kano for the explanation
"I wrote a document about it once, I'll repeat a little bit here:" <--- You wouldn't happen to have that document somewhere ?, I would be interested in reading it.
Cheers
February 06, 2018, 03:04:11 AM
Off Topic, But interesting: Telsa is going to put his Roadster on Mars. 13:30 EST TUESDAY Feb 6!!
Whole new meaning to space junk!
http://www.spacex.com/webcast
http://www.spacex.com/sites/spacex/files/falconheavypresskit_v1.pdf
Whole new meaning to space junk!
http://www.spacex.com/webcast
http://www.spacex.com/sites/spacex/files/falconheavypresskit_v1.pdf
February 06, 2018, 02:30:20 AM
Ok Who Shit on the bitcoin and no one wants it anymore?
1 Bitcoin equals
6164.99 US Dollar
1 Bitcoin equals
6164.99 US Dollar
February 06, 2018, 01:13:30 AM
Anyone who noticed ... the DB restarted again just now.
This is the same cause as the other day.
No mining is affected.
I've not applied the fix yet - though the problem has existed for years, just unlucky I guess it's happened twice in a few days.
Mine on!
Edit: KanoDB reload completed at 06:16:47 UTC
This is the same cause as the other day.
No mining is affected.
I've not applied the fix yet - though the problem has existed for years, just unlucky I guess it's happened twice in a few days.
Mine on!
Edit: KanoDB reload completed at 06:16:47 UTC
February 05, 2018, 11:27:24 PM
The Diff looks to me like it's been somehow "manipulated" to squeeze out the small.. (just a theory but plausible never the less)
The diff will always grow to suit large miners better than small miners.It's even suggesting in the inital whitepaper by 'Satoshi' that that will be the case.
However, that is a simple economics concept, known as economies of scale.
That is true kano,
Though this may be the case we have seen what many see as attack on the network. (my thought's / speculation)
Lets assume a group wanted bitcoin all for themselves, How could they "secure" there investment and take control of the network without need for 51% attacks ect..
Step 1. make a new chain..
2. We saw the creation of a 2nd chain BCH now we know from this they created with something called "emergency diff adjustment" now BCH chain is now slightly ahead of Bitcoin’s in size and block height.!
Quote
"Block chain length" is calculated from the combined difficulty of all the blocks, not just the number of blocks in the chain. The one that represents the most computation will win
2. Now you have a 2nd chain to "jump" back and forth as you please.
Now I refer to a very early set of comments on the forum regarding "difficulty adjustment attack"
https://bitcointalksearch.org/topic/difficulty-being-manipulated-318727
Quote from user Rival
Quote
Any time that you intentionally throttle back your hash rate you lose... period.
Dozens of convoluted strategies have been formulated and tried and in all cases they screw you. The only effective way to manipulate the difficulty is by somehow sabotaging your competition so that THEY are the ones who are throttling back their hash rates.
Dozens of convoluted strategies have been formulated and tried and in all cases they screw you. The only effective way to manipulate the difficulty is by somehow sabotaging your competition so that THEY are the ones who are throttling back their hash rates.
There is no need to "throttle back" when they can mine there "fork" with difficulty adjustment to suit. this keeps the money rolling in while you throw hashrate on and off the original chain.
https://imgur.com/a/1AtFu
The jump and continued "fast" growth of the diff from 1st august is something people should really be looking into and asking questions. The hashrate has been "far" from stable we see large chunks come and go from the chain in my view to "fuzz" the network into jumping + diff each time. I am not alone in thinking this theory once you push the diff higher and higher squeezing out the home miners "even with multiple s9's (which in most country's now take around 400+ days ROI give or take depending on electrical rates) and they are not losing money in the process by having the separate chain to mine on. This relinquishes the need to throttle back and lose money in the process.
this is not fact so please do not take it as such its more "speculation". But is possible..
February 05, 2018, 10:58:17 PM
Indeed, as the mighty Zep said, "ramble on!" 
And Mine On!
And Mine On!
February 05, 2018, 10:33:36 PM
So, I felt the urge to ramble on about Bitcoin again...
And, thank you for it! Pretty awesome to get an explanation like that.
That was a pretty cool ramble!
February 05, 2018, 10:30:14 PM
So, I felt the urge to ramble on about Bitcoin again...
And, thank you for it! Pretty awesome to get an explanation like that.
February 05, 2018, 10:18:28 PM
The Diff looks to me like it's been somehow "manipulated" to squeeze out the small.. (just a theory but plausible never the less)
The diff will always grow to suit large miners better than small miners.It's even suggesting in the inital whitepaper by 'Satoshi' that that will be the case.
However, that is a simple economics concept, known as economies of scale.
February 05, 2018, 10:04:34 PM
The Diff looks to me like it's been somehow "manipulated" to squeeze out the small.. (just a theory but plausible never the less)
February 05, 2018, 09:54:14 PM
Hashrate 21.00 EH/s
Difficulty 2,603,077,300,218 - 2.60 T
Next Difficulty Estimated
(+11.05%) 2.89 T
Date to Next Difficulty
0 Days 22 Hours
NOOOOOOOOOOOOOOOOOOOOOOOO Make it stop!
Difficulty 2,603,077,300,218 - 2.60 T
Next Difficulty Estimated
(+11.05%) 2.89 T
Date to Next Difficulty
0 Days 22 Hours
NOOOOOOOOOOOOOOOOOOOOOOOO Make it stop!
The hashrate actually came back up a little bit. I’m hoping with the downward trend in the BTC price that difficulty will reverse at some point.
Look like global hashrate dropped last 12 hrs. 25ex to 23ex
https://imgur.com/a/e4ed9
I was going off the hashrate on BTC.com. It had dropped under 20Eh recently and popped back over 21Eh today. I just can’t see difficulty continuing to rise at the rate it has been. If this price stays. I think it’s going to put a hurtin on the big data centers that have 6 figure power bills.
February 05, 2018, 09:51:45 PM
Thanks for the additional info on that kano.
If I could give merit for that I would!
If I could give merit for that I would!
February 05, 2018, 09:44:04 PM
RE: proxy post further above
Basically what a proxy does is act like a normal miner to the pool.
The simple version of it is:
It adds to the size of coinbase1 and subtracts from the size the miner is allowed to use between coinbase1 and coinbase2
i.e. if it used 1 byte, it could send different work to 256 miners - each one would be given coinbase1 with X appended, coinbase2, and with the size between them now 1 byte smaller.
Each miner would, of course, get a unique X.
What this also means is that you will average 18 shares per minute between your proxy and the pool - even if you have 256 miners.
(of course the proxy can break it larger to 2 bytes=65536 miners, 3 bytes=16777216 miners etc)
So network load between you and the pool is lower with a proxy - it can be the equivalent of a single miner even if you have many thousands of miners.
How this looks in stratum would be:
From Pool to Proxy
When the proxy first connects to the pool, the pool tells it your ID and the enonce size
From then on you use those 2 for all work.
So work arrives like so:
{"params":["aabbccdd00001122","a83fb5dc201c2a484569c0cbba8b5b8e2e524e38002e4c590000000000000000",
"01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff3603eebf0700042c11795a049cbb5e180c",
"0a2ef09f90882e12204b616e6f506f6f6c20283d4f2e4f3d2920ffffffff02a6507b55000000001 976a914370c9767eeb3f6add88c207733b7ff2e920622c888ac0000000000000000266a24aa21a9 ed73a4cfcddaecfbc3f77505bccccdc8ff4d13cdda8fd7d06347b61b68f48ac1d900000000",
["743b249690334d20a53686ee75981af35cbc2325e03e0114d8a3e19f98f14d37",...],
"20000000","176c2146","5a79112c",false],"id":null,"method":"mining.notify"}
From Proxy to miner XX
When the miner connects to the proxy it would get the same ID but with a shorter enonce value (1 shorter if configured for 256 miners)
Then each time the proxy gets work from the pool, it sends it to each miner with each miner's unique XX value.
{"params":["aabbccdd00001122","a83fb5dc201c2a484569c0cbba8b5b8e2e524e38002e4c590000000000000000",
"01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff3603eebf0700042c11795a049cbb5e180cXX",
"0a2ef09f90882e12204b616e6f506f6f6c20283d4f2e4f3d2920ffffffff02a6507b55000000001 976a914370c9767eeb3f6add88c207733b7ff2e920622c888ac0000000000000000266a24aa21a9 ed73a4cfcddaecfbc3f77505bccccdc8ff4d13cdda8fd7d06347b61b68f48ac1d900000000",
["743b249690334d20a53686ee75981af35cbc2325e03e0114d8a3e19f98f14d37",...],
"20000000","176c2146","5a79112c",false],"id":null,"method":"mining.notify"}
The difference in the work is only the XX that's been added (and of course the initial connection being told the enonce is 1 byte smaller)
This means each miner is mining something different, but based off the same single work item.
Basically what a proxy does is act like a normal miner to the pool.
The simple version of it is:
It adds to the size of coinbase1 and subtracts from the size the miner is allowed to use between coinbase1 and coinbase2
i.e. if it used 1 byte, it could send different work to 256 miners - each one would be given coinbase1 with X appended, coinbase2, and with the size between them now 1 byte smaller.
Each miner would, of course, get a unique X.
What this also means is that you will average 18 shares per minute between your proxy and the pool - even if you have 256 miners.
(of course the proxy can break it larger to 2 bytes=65536 miners, 3 bytes=16777216 miners etc)
So network load between you and the pool is lower with a proxy - it can be the equivalent of a single miner even if you have many thousands of miners.
How this looks in stratum would be:
From Pool to Proxy
When the proxy first connects to the pool, the pool tells it your ID and the enonce size
From then on you use those 2 for all work.
So work arrives like so:
{"params":["aabbccdd00001122","a83fb5dc201c2a484569c0cbba8b5b8e2e524e38002e4c590000000000000000",
"01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff3603eebf0700042c11795a049cbb5e180c",
"0a2ef09f90882e12204b616e6f506f6f6c20283d4f2e4f3d2920ffffffff02a6507b55000000001 976a914370c9767eeb3f6add88c207733b7ff2e920622c888ac0000000000000000266a24aa21a9 ed73a4cfcddaecfbc3f77505bccccdc8ff4d13cdda8fd7d06347b61b68f48ac1d900000000",
["743b249690334d20a53686ee75981af35cbc2325e03e0114d8a3e19f98f14d37",...],
"20000000","176c2146","5a79112c",false],"id":null,"method":"mining.notify"}
From Proxy to miner XX
When the miner connects to the proxy it would get the same ID but with a shorter enonce value (1 shorter if configured for 256 miners)
Then each time the proxy gets work from the pool, it sends it to each miner with each miner's unique XX value.
{"params":["aabbccdd00001122","a83fb5dc201c2a484569c0cbba8b5b8e2e524e38002e4c590000000000000000",
"01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff3603eebf0700042c11795a049cbb5e180cXX",
"0a2ef09f90882e12204b616e6f506f6f6c20283d4f2e4f3d2920ffffffff02a6507b55000000001 976a914370c9767eeb3f6add88c207733b7ff2e920622c888ac0000000000000000266a24aa21a9 ed73a4cfcddaecfbc3f77505bccccdc8ff4d13cdda8fd7d06347b61b68f48ac1d900000000",
["743b249690334d20a53686ee75981af35cbc2325e03e0114d8a3e19f98f14d37",...],
"20000000","176c2146","5a79112c",false],"id":null,"method":"mining.notify"}
The difference in the work is only the XX that's been added (and of course the initial connection being told the enonce is 1 byte smaller)
This means each miner is mining something different, but based off the same single work item.
February 05, 2018, 09:30:54 PM
Hashrate 21.00 EH/s
Difficulty 2,603,077,300,218 - 2.60 T
Next Difficulty Estimated
(+11.05%) 2.89 T
Date to Next Difficulty
0 Days 22 Hours
NOOOOOOOOOOOOOOOOOOOOOOOO Make it stop!
Difficulty 2,603,077,300,218 - 2.60 T
Next Difficulty Estimated
(+11.05%) 2.89 T
Date to Next Difficulty
0 Days 22 Hours
NOOOOOOOOOOOOOOOOOOOOOOOO Make it stop!
The hashrate actually came back up a little bit. I’m hoping with the downward trend in the BTC price that difficulty will reverse at some point.
Look like global hashrate dropped last 12 hrs. 25ex to 23ex
https://imgur.com/a/e4ed9
February 05, 2018, 09:28:01 PM
...
The hashrate actually came back up a little bit. I’m hoping with the downward trend in the BTC price that difficulty will reverse at some point.
The hashrate actually came back up a little bit. I’m hoping with the downward trend in the BTC price that difficulty will reverse at some point.
I don't see the hashrate being affected unless it is a prolonged (meaning 6 months + ) BTC price decline. It has to be long enough to discourage people from buying more miners or unplugging / selling existing ones.
Jump to: