Topic: KanoPool kano.is lowest 0.9% fee 🐈 since 2014 - Worldwide - 2432 blocks - page 885. (Read 5352420 times)

Well you'd have to look for rejected blocks in your bitcoin debug.log
Give it a while
Also the network hash rate will probably drop a bit - but that won't be obvious for a while either.
The pools list at btc.com may or may not show the split correctly ... who knows how they come up with the numbers there
I sent them the details for KanoPool a while ago and they've still done nothing to fix that ...

Edit: blockchair.com was supposed to have a browser at fork time ... but that clearly didn't happen

Okay is it now August 1? and if so has anything started?

first new block

https://blockchain.info/blocks


https://blockchain.info/block-height/478479

Last payout (478295) confirmed - in time
The power of 42,000 satoshis

Edit: also there were a few failovers from 16:18 to 16:28 UTC from one of the US stratum nodes.
You'll see a drop on the shift graph for that shift.
I'm guessing there was network trouble but got no notifications (to wake me up) since in each case they were immediate failovers and failbacks.
My monitoring needs to lose the connection (which it didn't, so it wasn't a full failover of everyone) or it needs to fail another network test, which didn't happen either.
So must have been very short each time.

Well that all simply depends on how much hash rate goes to the fork, and that's anyone's guess.

It will of course mean average slower blocks until the next diff change, but once the next diff change gets here, that will mean a diff drop also.

I doubt we'll see 20% of the network switch to the fork, but doing the calculations with 20%:

e.g. if it was 20% then that would mean 1/0.8 or 25% longer blocks i.e. expected avg 12.5 mins per block.
we are at the moment 666 blocks in this diff change i.e. 1350 to go so ~1/3 done, ~2/3 to go
2/3 would expect to be 9.375 days, but with the extra 25% that would be 11.7 days so about 2.3 extra days - so even 20% is not that big a change.
The diff drop for 20% would be about 13.3% - i.e. about 2/3 of the 20%

The next diff change, after this up coming one, will also be a little slower, since the first 1/3 of this diff change was at the higher hash rate, so that should be the other 1/3 of the 20% for the whole next diff change, but since it would already have dropped 13.3% ... that 1/3 would mean roughly about another 6.2% diff drop next diff change.

... all that also presuming no hash rate rise

With the fork going happen and if a good size of the speed drops off the network to mine BCC with about 8 days till difficulty adjustment.

How do you see it playing out?
Longer wait times and tell blocks are found and slow down transactions and confirmations.

hope so.

Oh my avalon 741 comes on tues  just in time for the new era.

I'm all clear on payments as well. Reminds me of the brouhaha around the last two halvings... 

Kano,

I appreciate you keeping us informed as to the plan for B-Day, hopefully it's a non-event and it should be at least for us.

I've seen that happen with a few zero fee transactions in the past.  It just sits at 0 until we hit our next block or until someone else confirms it which did happen from time to time.  This one has fees so it has a better chance of getting confirmed

Of course, our BLOCK MONDAY party will take care of it if no one else does...let's get it started!

Just means the last payout (that's not confirmed yet) actually got out past the pool bitcoind.
When it's a zero fee transaction, few others will accept it or pass it on.
It's not zero fee (42,000 sat) so it gets out further on the net.

My core wallet has a incoming transaction from Kano.is at 7/31/17 @ 04:04 and it shows a light grey and says:

Status: 0/unconfirmed, not in memory pool
Date: 7/31/2017 04:04
From: unknown
To: 1Q14j1KRDRcpUUb2rQYUh5WMLaynPfyP7S (own address, label: KANO.IS)
Credit: 0.00599468 BTC
Net amount: +0.00599468 BTC
Transaction ID: 5f6688c178cd5cba2c98056f9091da43e0b6b7ac3ecda023ab7f21b4b0773d4f
Transaction total size: 28234 bytes
Output index: 496


Never seen that, new normal?

It is 9:01AM EST time.

It looks to me that all blocks are mature and that they have been paid.


All go here for me and all have confirms

https://blockchain.info/address/16yLHLoeyuCLPMXkVpC3gyrRYvwRGwjKJr

Thanks Kano!

Full quote since it's about what I said, and I'm changing it a bit:

I'll also send out 478295 in a few hours (when it matures) with the same $1 (42,000 sat) fee since it should get confirmed reasonably quickly.
Of course, best if we confirm it ... i.e. find a block ... but either way, it 'should' be confirmed well before B-Day.

feels funny to get payout alerts without a corresponding block alert 

when the first one came in i had to double-check to make sure the script was running properly.

Well that worked
478,360 BTCC confirmed the payout for 478254

478261 payout will be sent out (the same) after the next network block (when it matures)

Edit: and again

478,363 BTC.TOP confirmed the payout for 478261

... those $1 fees work well ... at the moment ...

Having some intermittent communication issues between the main server and the web server.
If you get a web error, just retry it and it should be ok.

Sounds like a plan!  I agree with you, I think it will not amount to anything when it's all over.

Payout Information

So the payout handling for B-Day (yeah I think that name is an appropriate play on D-Day) will be as follows:

I'm queueing up 478254 and 478261 right now to go out as soon as they Mature - as per normal.

The 'expected' Maturity times at the moment are: ~3:50am (478254) and ~5:00am UTC (478261)
That gives a bit over 19 hours to confirm them before 1-Aug 0:20 UTC

Currently we expect to average ~13hrs per block so there's a reasonably high probability they will both be confirmed before B-Day
If not, well I don't REALLY think it matters, but we'll see anyway

478295, on the other hand is expected to Mature at ~10:40am UTC, and with the ~13hrs before it's average 'expected to be confirmed', that lands it close to B-Day arrival time.

So, I'll hold back sending out the payment for 478295 (and any blocks found after 478295) until tomorrow.

--

Again, I don't see why there should be any problems at all with Bitcoin on B-Day, but considering the melodrama going around, it's not really that big a deal to add a short delay to just a few payouts.

... and anyone who is really concerned can also have me hold their 'unqueued' payouts until they are no longer concerned as per the web site says.

--

Edit: I also set 42,000 sat in each one as a txn fee - about $1 - to see if that makes others confirm them also.
The Bitcoin transaction rate really has dropped recently - often block aren't full - so there's probably a higher chance of it getting into another pool's block if there's some tiny fee in it.
Anyway - we'll see if that makes any difference for those 2 payouts.

Excellent, thanks!