Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 1873. (Read 5352140 times)
January 08, 2016, 04:10:34 AM
Woohoo!! I'm ready for a quick one!
January 08, 2016, 03:53:03 AM
Block!! 
You mean party time!!!!
Not spectacular ~101.591%, but it's a block!!!!
January 08, 2016, 03:49:22 AM
Block!!
January 08, 2016, 03:10:32 AM
I'm understood, thank you.
January 08, 2016, 03:08:49 AM
Payout 392186 sent
21676d73d5beffcf34762839074d47ae935bcd8066d4f618356ed737529d48f1
and confirmed
--
Edit: I guess the most important point to note about that is that blockchain.xyz doesn't do anything but make transactions.
Pools/Miners confirmed transactions.
So if some web site is silly enough to make up their own rules about bitcoin, it doesn't matter, just ignore them.
Once a transaction is in a valid block, what they say means nothing.
21676d73d5beffcf34762839074d47ae935bcd8066d4f618356ed737529d48f1
and confirmed
--
Edit: I guess the most important point to note about that is that blockchain.xyz doesn't do anything but make transactions.
Pools/Miners confirmed transactions.
So if some web site is silly enough to make up their own rules about bitcoin, it doesn't matter, just ignore them.
Once a transaction is in a valid block, what they say means nothing.
January 08, 2016, 02:59:54 AM
Last payout 21676d73d5beffcf34762839074d47ae935bcd8066d4f618356ed737529d48f1
blockchain report:
Transaction rejected by our node. Reason: The Maximum number of outputs in a single transaction is 250
Don't use blockchain.blockchain report:
Transaction rejected by our node. Reason: The Maximum number of outputs in a single transaction is 250
Once it's confirmed they will show it properly.
January 08, 2016, 02:58:58 AM
Last payout 21676d73d5beffcf34762839074d47ae935bcd8066d4f618356ed737529d48f1
blockchain report:
Transaction rejected by our node. Reason: The Maximum number of outputs in a single transaction is 250
blockchain report:
Transaction rejected by our node. Reason: The Maximum number of outputs in a single transaction is 250
January 08, 2016, 02:07:30 AM
...
Am I submitting shares in the future? -1s
...
Yep now that the main server is a little more busy that it used to be ... used to be pretty bored, now it's twice pretty bored Am I submitting shares in the future? -1s
...
...The time when the request hits ckdb (now), then until it gets the data, it can be delayed enough nanoseconds for the 'second' value to go forward awaiting the results, if it was a few nanoseconds before the next second, then a share to arrive, then the result of the workers request to be supplied.
Thus ends up: -1
i.e. the share arrived (just) after the request started.
January 08, 2016, 01:09:18 AM
How many blocks per day on average are we supposed find on kano pool?
One block each 15 hours w/ current hashrate at 100% luck January 08, 2016, 01:02:00 AM
How many blocks per day on average are we supposed find on kano pool?
January 08, 2016, 12:15:22 AM
Am I submitting shares in the future? -1s
One of my S3's died, need to troubleshoot....
January 08, 2016, 12:03:34 AM
SG and DE node users.
I've tracked down the bug in the node code that caused people to hash into thin air without failing over and have implemented a workaround for it to prevent the cause from happening. In addition I've implemented a change to make it more robust in ckpool itself at disconnecting clients connected to the node but that would warrant a ckpool restart at the main pool which isn't justified at this stage.
Apologies for the lost time when hashing on the SG node. Please give it another go and watch carefully for any issues. Thanks for your patience!
I've tracked down the bug in the node code that caused people to hash into thin air without failing over and have implemented a workaround for it to prevent the cause from happening. In addition I've implemented a change to make it more robust in ckpool itself at disconnecting clients connected to the node but that would warrant a ckpool restart at the main pool which isn't justified at this stage.
Apologies for the lost time when hashing on the SG node. Please give it another go and watch carefully for any issues. Thanks for your patience!
Ok just reconnected to SG node. Let's see if it runs smoothly.
January 07, 2016, 11:56:55 PM
Sorry, my fault, didn't finish my teriyaki chicken from lunch today. Just did now, a block is sure to crack any minute now...
Ought! I believe this is exactly the reason. Please control yourself next time! January 07, 2016, 11:44:58 PM
Sorry, my fault, didn't finish my teriyaki chicken from lunch today. Just did now, a block is sure to crack any minute now...
January 07, 2016, 11:24:02 PM
Time to hit a block before the last one matures, eating grilled chicken tacos!
January 07, 2016, 10:49:05 PM
SG and DE node users.
I've tracked down the bug in the node code that caused people to hash into thin air without failing over and have implemented a workaround for it to prevent the cause from happening. In addition I've implemented a change to make it more robust in ckpool itself at disconnecting clients connected to the node but that would warrant a ckpool restart at the main pool which isn't justified at this stage.
Apologies for the lost time when hashing on the SG node. Please give it another go and watch carefully for any issues. Thanks for your patience!
I've tracked down the bug in the node code that caused people to hash into thin air without failing over and have implemented a workaround for it to prevent the cause from happening. In addition I've implemented a change to make it more robust in ckpool itself at disconnecting clients connected to the node but that would warrant a ckpool restart at the main pool which isn't justified at this stage.
Apologies for the lost time when hashing on the SG node. Please give it another go and watch carefully for any issues. Thanks for your patience!
Awesome ck thanks for the update!
January 07, 2016, 09:55:56 PM
malform json handled, empty json values handled. gtg for future repeats.
January 07, 2016, 09:49:22 PM
Should be within the next 5/10 minutes - just gotta wait for that random shift summary event 
Restart complete in record time this time Code:
[2016-01-08 13:38:30.433+11] Listener received terminate message, terminating ckdb
...
[2016-01-08 13:45:04.037+11] reload queue completed 0m 8.808s
6.5 minutes ...
[2016-01-08 13:45:04.037+11] reload queue completed 0m 8.808s
January 07, 2016, 09:48:21 PM
...
Kano, Changed my payout address about 12 hours ago, got email about the change but this payout was sent to old address. Is that because use use the address at time of block hit or at time of payment made?
Payout is sent to the address at the exact time the block is found.Kano, Changed my payout address about 12 hours ago, got email about the change but this payout was sent to old address. Is that because use use the address at time of block hit or at time of payment made?
Ok, great thanks. So next block we find will use the new address. Thanks for the quick reply!
January 07, 2016, 09:47:11 PM
...
Kano, Changed my payout address about 12 hours ago, got email about the change but this payout was sent to old address. Is that because use use the address at time of block hit or at time of payment made?
Payout is sent to the address at the exact time the block is found. Kano, Changed my payout address about 12 hours ago, got email about the change but this payout was sent to old address. Is that because use use the address at time of block hit or at time of payment made?
Jump to: