Author

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

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
The BU vote only requires 75% so it's even less relevant that the pool votes on it due to our current size.

Meanwhile, in the last 2 days we've had a zero fee pool block payout confirmed by another pool and I've personally sent out 3 transactions with fees around 3c and each has been confirmed in what I considered a reasonable amount of time considering the low fee: 33mins for the 1st one and 3.5hrs for 2nd and 3rd

So what I'm saying is yep something needs to be done soon, but nope neither of the options seem like a good long term solution at the moment.

Meanwhile, on the subject of voting, our top miners are clearly bringing in more hash rate and more soon, we'll see when it happens Smiley
When we get to a few % of the network I'll then be discussing with them (and anyone else who points multiple PHs of hardware at the pool long term) about that voting.
full member
Activity: 315
Merit: 120
As an FYI ... I pointed my miners to a PPLNS signaling BU.  These transaction times and unc-tx. I've been waiting 20+ hours, again, with 0.0005+ tx/kb.  I don't know the answer, but I know it's not long queues and high tx fees as the Core team wants - too many altcoins.

Anyways ... we've discussed this and I thought I'd share. It didn't sound like you had any considerations of pointing BU, beyond small pool size?  I hope you take no offense to this, as that is not my intention, only to inform.  Great pool and great work! Happy to point back, but wanted to vote ...
sr. member
Activity: 508
Merit: 250
Hey Kano, I received the payment for the last block without us finding a new one about an hour ago.  Perfectly fine with me I just was wondering why, I believe that it's a first time I see this happen.  Thanks!  Smiley
Yep:
https://bitcointalksearch.org/topic/m.18436008

I see, ok thanks!
legendary
Activity: 1736
Merit: 1032
Carl, aka Sonny :)
Block! by 585rich Smiley with 7.5THs Smiley
Guessing it was an S5?

Yea 585rich!  Welcome to the Acclaim Board with your 1st Kano block! Cheesy
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Block! by 585rich Smiley with 7.5THs Smiley
Guessing it was an S5?
Another high txn fee block (1.6BTC) so maybe there was just a lull yesterday in transactions.
legendary
Activity: 952
Merit: 1003
Ditto...that did the old...



on me...

Nice way to start the French press, however...  Kiss
legendary
Activity: 1736
Merit: 1032
Carl, aka Sonny :)
Hey Kano, I received the payment for the last block without us finding a new one about an hour ago.  Perfectly fine with me I just was wondering why, I believe that it's a first time I see this happen.  Thanks!  Smiley
Yep:
https://bitcointalksearch.org/topic/m.18436008

That is funny...I sure had a puzzled look on my face Smiley

But hey, it's all good!  Time for more blocks! Cheesy
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Hey Kano, I received the payment for the last block without us finding a new one about an hour ago.  Perfectly fine with me I just was wondering why, I believe that it's a first time I see this happen.  Thanks!  Smiley
Yep:
https://bitcointalksearch.org/topic/m.18436008
sr. member
Activity: 448
Merit: 250
Hey Kano, I received the payment for the last block without us finding a new one about an hour ago.  Perfectly fine with me I just was wondering why, I believe that it's a first time I see this happen.  Thanks!  Smiley

Look back on the previous page, another pool confirmed the payout transaction.
sr. member
Activity: 508
Merit: 250
Hey Kano, I received the payment for the last block without us finding a new one about an hour ago.  Perfectly fine with me I just was wondering why, I believe that it's a first time I see this happen.  Thanks!  Smiley
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
You can't.

A share is associated with a work item - and it can't pretend to be associated with a different one.
That work item has a difficulty that the pool assigns.
The work item is of course also unique per 'worker'.

Ah, I see. That's what I was wondering before, if there was something in the work items that was unique per connection/difficulty. Thanks.
Well it's effectively unique, but by reference rather than being part of the work.

Yeah that is actually a 'bug' in stratum that I argued with Slush about in the stratum thread (and others mentioned but didn't care too much about it)
Slush's answer was it was too hard for him to code it ...
... crappy programmers everywhere you look ...

A workaround was put into effect rather than actually fixing it properly.
The fix was of course to make the difficulty part of the actual work, the problem was the pool sends out the difficulty as a separate message to the work and it doesn't specify which work it is associated with either, it's simply a "difficulty change" message.
The workaround is in the stratum spec about how a difficulty change is associated with what work.

... but no you can't game it.
newbie
Activity: 49
Merit: 0
You can't.

A share is associated with a work item - and it can't pretend to be associated with a different one.
That work item has a difficulty that the pool assigns.
The work item is of course also unique per 'worker'.

Ah, I see. That's what I was wondering before, if there was something in the work items that was unique per connection/difficulty. Thanks.
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
The stolen shares are, in most cases, far above.. NOT below the current difficulty. Think about it. If you found a share that was hundreds of times the current difficulty, wouldn't you want to save it ?
...
Lulz no idea what you been smoking to confuse you, but a share is only worth the value of the work it was generated for, and a valid block share is only worth a block no matter what difficulty it is (as long as it's a block).
... and if a block is not submitted immediately, it's worth nothing if someone else finds a block while you procrastinate, so no you wouldn't save it - that's stupid.

If a share is worse than the requested work difficulty, it's worth nothing.
If a share is better than or equal to the requested work difficulty, it's only worth the requested work difficulty.

I didn't see his full post, but what is to stop someone from opening multiple connections and submitting shares just above the work diff? Say you have a miner that avgs 10k diff, open two more connections to submit all work from 5k-9999 and four more connections for all work from 2.5k-4,999, etc. This miner would be making the same as an honest miner, in addition to all the proceeds from submitting his lower shares on the other connections.

Seems even easier to take advantage of on pools that allow you to set your own difficulty. Open up a bunch of ranges and get paid huge amounts for rarer high hashes, while still getting paid on as low hashes as your connection speed allows.

I asked about this before, but I think I confused the issue previously by asking about connection 'cookies' or individual connection nonces to try to prevent this.

It would be obvious from statistics of course, but it still seems ripe for exploit on pools that don't pay much attention.
You can't.

A share is associated with a work item - and it can't pretend to be associated with a different one.
That work item has a difficulty that the pool assigns.
The work item is of course also unique per 'worker'.
Edit: and by 'worker' I mean a connection to the pool (which may be a miner or a proxy)
newbie
Activity: 49
Merit: 0
...
The stolen shares are, in most cases, far above.. NOT below the current difficulty. Think about it. If you found a share that was hundreds of times the current difficulty, wouldn't you want to save it ?
...
Lulz no idea what you been smoking to confuse you, but a share is only worth the value of the work it was generated for, and a valid block share is only worth a block no matter what difficulty it is (as long as it's a block).
... and if a block is not submitted immediately, it's worth nothing if someone else finds a block while you procrastinate, so no you wouldn't save it - that's stupid.

If a share is worse than the requested work difficulty, it's worth nothing.
If a share is better than or equal to the requested work difficulty, it's only worth the requested work difficulty.

I didn't see his full post, but what is to stop someone from opening multiple connections and submitting shares just above the work diff? Say you have a miner that avgs 10k diff, open two more connections to submit all work from 5k-9999 and four more connections for all work from 2.5k-4,999, etc. This miner would be making the same as an honest miner, in addition to all the proceeds from submitting his lower shares on the other connections.

Seems even easier to take advantage of on pools that allow you to set your own difficulty. Open up a bunch of ranges and get paid huge amounts for rarer high hashes, while still getting paid on as low hashes as your connection speed allows.

I asked about this before, but I think I confused the issue previously by asking about connection 'cookies' or individual connection nonces to try to prevent this.

It would be obvious from statistics of course, but it still seems ripe for exploit on pools that don't pay much attention.
hero member
Activity: 723
Merit: 519
Any reason for the last payout without a new block?
That's funny Smiley

As I've always said, I do actually (almost always) send out the payout 1 minute after it matures.
That of course actually means that the payout transaction is out there on the net for anyone to accept and confirm.

The problem is that it's a zero fee transaction so I'd never expect anyone else to actually confirm it.
I force it to be in our work by prioritising it with a ridiculously high value.

In this case it was confirmed in another pool's block: 460168

I guess the reason is that the transaction count has gone down a lot, and some pools are actually confirming free transactions when they can't fill the block.

"....but bitcoin doesn't work anymore because blocks are full"  Wink
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Any reason for the last payout without a new block?
That's funny Smiley

As I've always said, I do actually (almost always) send out the payout 1 minute after it matures.
That of course actually means that the payout transaction is out there on the net for anyone to accept and confirm.

The problem is that it's a zero fee transaction so I'd never expect anyone else to actually confirm it.
I force it to be in our work by prioritising it with a ridiculously high value.

In this case it was confirmed in another pool's block: 460168

I guess the reason is that the transaction count has gone down a lot, and some pools are actually confirming free transactions when they can't fill the block.
full member
Activity: 120
Merit: 100
Any reason for the last payout without a new block?
legendary
Activity: 1736
Merit: 1032
Carl, aka Sonny :)
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
Block! by cobramining Smiley
A7v2
and 2 payouts Smiley

Looks like the txn fees are finally falling - that was a 2 minute block, but still not a lot of fees, unlike usual.

Edit: actually it was only 239,216 bytes due to there only being that many chosen by bitcoind.
I don't affect the "segwit" 13.1 code's decision to choose transactions except for the smaller (88,888) size on the block change and the reorg of transactions to fit in a 'few extra' bytes when it's close to full.
legendary
Activity: 3586
Merit: 1099
Think for yourself
I'm not too concerned though because I think recent SegWit discussions on LiteCoin may help ease pressure on BTC for a while.  I guess I just don't fully understand SegWit ...

Segregated Witness is to correct a screw up they made when implementing the P2SH changes.

Did LiteCoin make the same mistakes the Bitcoin devs did?
Jump to: