I agree. His threat was just that, a threat. If he was serious he would have put all his hashrate on BU anyway, and as it stands all he's doing is signalling BU in his coinbase; he is not actually running BU nodes. I've always suspected his BU threat was just a bargaining point after UASF was mentioned but now he's mined himself into a corner and is persisting with something he probably never intended to do. We'll see what he really does should the hashrate climb further and see if he persists with forking into a BU world just out of stubbornness now.

Agreed too, but let the bigblockers have their day for today. Let them fap to variance.

That's your judgement, and that's fine. A segwit based main chain would make the blocks up to 4MB with segwit transactions so I don't see how that's the rate limiting thing for a "minority" chain, and even with 25% of the current hashrate, a minority chain would be about 400PH. Jihan threatened to fork at 51% anyway but we'll see... He could just do it now, since only 1 of 4 of his pools are advertising BU - switching all of them would put it significantly >51%

Yep this is precisely what I mean and demonstrates what would happen on every block on the "proportional" payout mechanism and why no pool should be using it today. The only reason it's prop at the moment is because the N is building up. But there is no other fair way to build up this N which is also a nice way to build up the pool's hashrate to start out. Of course none of this is a guarantee of a windfall unless the 1st block is lucky, which I really hope it is Getting a pool started from scratch and attracting hashrate is incredibly difficult these days.

I don't know what you're talking about "cannot survive" - the chains will be completely separate and run in their own directions should it happen. Jihan said he wanted people to "attack" the minority chain (which is a fucking awful approach and speaks volumes) but that would mean he needs as much hashrate directed towards attacking it as he does mining BU blocks and no such hashrate is spare to do that. So unless BU support ends up being 90% leaving only a 10% core chain, then there won't be enough spare hashrate to throw at killing off the forked minority sized chain. There is no precedent saying which chain the economy will follow, but the majority have expressed that they will follow segwit...

Great, 1% more and then they can fork off and see where the fork's support takes them...

Nice. You've pushed this pool past 1PH for the first time since its inception. Since this pool monitors and reports worker luck, if you monitor the luck of rental miners over enough shares you can get an idea of it there's something wrong with your rental - but if they're *just* withholding blocks, it won't show up unless you mine trillions of shares. Since this is a new calculation, I don't have a good guide for how long is "enough" yet but so far I'm seeing virtually all the workers on the pool currently converging towards 1.0 which to be honest is reassuring. However note that I haven't had a bitcoin-related mathematician like organofcorti or meni rosenfeld confirm the validity of my calculations though.

Well this is 'offtopic' for this thread but since it's your thread you can take it whichever direction you want.

Bitmain's on that list? Did Jihan pull his head out of his arse and realise he was one person against the rest of the world at last? Now if only he'd do the same thing for bitcoin - but then he'll argue the only reason he agreed on the ltc roundtable was because they agreed to a block size increase when they need it which is laughable since ltc has almost completely empty blocks and may never need it. Oh well, I'll reserve further discussion for bitcoin/

Excellent, thanks and good luck.

Remember to the other miners, on the very first block of the pool, it is effectively like a proportional pool so you can "hop" on and game it to get more reward if it's a lucky block than you otherwise could get on an established running pool.

Yes that's correct so I should explicitly say: DERP is your expected reward if a block is found now.

"Horse shit"

Restarts complete. All looking okay for now.

This change should make it unnecessary to have the per worker stats pages any more so I will be removing them on the next update.

Just an update about what's planned and happening with this pool.

I'm expecting a reasonably large hasher to come online within a month or so; the presence of such an interested party contributed significantly to me being interested in starting this pool in the first place.

The stats as they are currently displayed are awkward, I acknowledge, and some of the values displayed are unnecessarily showing lots of significant digits. This will be trimmed in the future to make it easier to read.

The pool LNS and HERP values will eventually converge once the pool reaches 5xN; the only time they will change after that is temporarily after a diff change until they converge again.

The current displayed "diff" with the pool is off by a factor of 10. It shows 0.15% diff when in fact it's 1.5% diff. This will be rectified on a future restart.

User stats show only the overall user statistics at the moment. The solo pool also shows per-worker stats on the same page which would allow a full summary of all user and worker stats in one convenient place, if somewhat crowded. I plan to port that change from solo to this pool.

I am toying with the idea of a most rudimentary GUI summary of the user stats in the near future just to make life easier for miners. I don't know what form this will take but an outsider has offered to help.

Further nodes: At this stage it would be hard to justify setting up an EU based node to mine to with the pool and it would be a less satisfactory mode of communication since the coinbase would need to be shared to another pool meaning delays there anyway. This means there would not be much advantage to miners local to that area since there would be the delays of communicating with the main pool anyway. At most I could provide a DE passthrough which would slightly decrease latency for miners who have a very slow communication with the main pool but overall it may not actually be a real world advantage counting the latency between the node and the main pool so I'm against it for now. Passthrough nodes tend not to have perfect 24/7 connectivity in the real world either which is why solo has them as two virtually separate pools that simply collate their statistics - that cannot be done with this pool.

Because of coinbase generation of payouts, there are potential issues with the coinbase getting very large if the number of users on this pool ends up growing dramatically. This could start slowing down communication to miners and worse, make the pool incompatible with some mining hardware that has limits on coinbase size. If we reach this size, I will rework the payout mechanism to limit the number of users paid with each block found and interleave users' payouts between blocks found. This would mean miners would not necessarily get a payout with every block found (but they'd be rewarded the same overall), but this change would only come about if the pool ends up getting large enough and blocks would be coming more frequently by then. The smallest miners would be the ones whose payouts would end up getting interleaved as this would then give them a better reward/transaction fee ratio. If it gets to this, the pending payouts would become part of the user statistics.

No more disadvantage than rentals have overall. Their cost is always more than their expected return. However given the pool is still very small, if it's lucky then you could be lucky and earn a much better return.

Just means your miner has switched to a new diff too early on the instructions from the pool. In 30 seconds it would go away.

Hi OOC. Got an addition for you, and some fee pay scheme for your interest

https://bitcointalk.org/index.php?topic=1876330.0

Pool:                      ckpool.org
Website:                 http://ckpool.org
Proxy:                    No
Generation address:  14BMjogz69qe8hk9thyzbmR5pg34mVKB1e
Coinbase signature: ckpool.org
Payout method:        SPLNS (Score per last N shares, see pool thread above for full details)
Fee:                        0.5%
Pay Tx Reward:        Yes
Vardiff:                   18 SPM
Local Work:             Stratum
Pay Orphans:           No
Min Withdrawal:       0.0000546 BTC
Merge Mining:          No

SPLNS HERP DERP is related to the now defunct ozcoin's interpretation of my original payscheme idea they called pay on target, resuscitated now but extrapolated to PPLNS instead of PPS.

No restrictions. As the front page says; all ASICs are welcome. If your stats are showing your luck converging to 1, I wouldn't worry, but I haven't had mathematical proof that the luck estimate is spot on yet.


No, there's a disadvantage. I highly recommend multiple workers use different worker names but the same username. The reason is each payout will end up being a transaction in its own right, and spending rewards will end up requiring more transaction fees. Additionally if you have multiple small miners (eg. usb stick), you may never get over the dust threshold if you split them up. I should add this to the faq... but there haven't been hardly any questions yet so there aren't any frequently asked questions  

Added the first FAQs to the top post in anticipation of them being frequently asked.

New pool public beta official thread started for ckpool.org, please direct all further discussion regarding it here:

https://bitcointalk.org/index.php?topic=1876330.0

http://ckpool.org


No frills, no fuss ZERO FEE anonymous SPLNS bitcoin mining for everyone

No registration required, coinbase generation, no pool op wallets

Configuration:
Just point your miner to one of:
If in Europe use one of:
If in mainland China use:

Set your username to your btcaddress with any or even no worker extension, and any password.
eg:
If you enter an invalid address you will be rejected

SPLNS

SPLNS stands for Score Per Last N Shares. Score refers to the fact that share value is weighted by the difficulty of the share found.
Last N Shares refers to the fact that the score is a rolling score based on N shares where N means 5 x the current difficulty.
The rolling average is weighted according to when the shares were found - the more recent shares are the more they are worth.

Features of SPLNS:

Hop proof - the system cannot be gamed to earn more by hopping on and off during lucky blocks.
Short "ramp up time" compared to PPLNS - rewards more rapidly rise to stable levels when you first start hashing.
Long "ramp down time" - you are still entitled to rewards for a very long period which is pool hashrate dependant rather than time dependent so you don't quickly "fall off" and earn nothing when you stop mining. Additionally this helps minimise variance for intermittent miners.
Lucky rewards - since shares are weighted by the difficulty of the share found, if you are a small miner that has a handful of lucky high diff shares, you can earn significantly more, capped at current network difficulty.
Block finder rewards - as per lucky rewards, a large share weight is attached to block finds (but is applied to the next block reward since user rewards are included in the existing unsolved block reward.) The sooner the next block is found, the higher the block finder reward is.
Malicious & faulty miner disincentives - since shares are rewarded according to the difficulty of the share found, malicious miners that withhold block solves, or faulty hardware that doesn't produce high diff shares will have substantially less reward than on any other pay scheme or pool.

SPLNS calculation is done on the fly and updated every minute based as a product of HERP DERP.
Herp stands for Hash Extracted Rate Product - where each share is worth sqrt(MIN(share diff, network_diff) / work_diff) * work_diff / 2
Derp stands for Difficulty Extrapolated Reward Payment - where the reward equals the user's herp divided by the pool's herp i.e. it is the expected reward should a block be found now.
The pool's Herp is simply added until it reaches 5 * network difficulty. After that it is biased every minute by scaling existing herp down to add the latest minute's herp and all users' herp is adjusted by the same scale the pool's was.

Additional and/or unique ckpool.org features:

Accurate statistics by the minute - while the statistics displayed at ckpool.org are rudimentary, they are updated by the minute and include accurate estimates of hash rate, herp and derp - which translates into an accurate estimate of payout should a block be solved.
Luck estimates - as the difficulty of each share is calculated into the user's herp, it is compared to an equivalent 'last N share' calculation to determine the miner's overall luck. This is done on a per worker and per user basis and displayed in the stats.The larger the miner and the longer they mine, the closer to 1 their luck will be while small miners may have much more variation.
Coinbase generation - Block solve reward is distributed directly from the block to each user, meaning each user gets a 'mined' transaction directly into their wallet as soon as the block is solved so there is no wait to get paid and no pool wallet storing user's rewards. Rewards will be considered 'immature' by bitcoin rules so will be unspendable until 100 network confirmations have passed.
Interleaved rewards - Each time a block is solved, the top 100 miners will receive a payout while 50 of the remaining smaller miners will receive a payout. Rewards will alternate between the smaller miners according to who has waited the longest for a payout. Rewards accumulate from blocks worked on even if miners are not scheduled for a payout with that block. This is done to minimise the size of the coinbase transaction to minimise latency, maximise mining hardware compatibility, and to make sure miners don't receive many small payouts which would lead to much larger fees when spending their reward.
Micropayments - payments below the dust threshold at block solve time will add to the user's herp for the next block. Once a miner's reward on successive blocks is greater than the dust threshold they will join other users with interleaved payouts.
Blocks are always as full as network congestion demands - ckpool never mines empty or light blocks and yet is still extremely fast at getting new work out to miners on block changes to minimise wasted work and decrease orphan risk.
Rapid propagation of blocks thanks to high speed low latency connections across a network of bitcoin nodes to further decrease orphan risk.
Shares all transaction fees with miners - transaction fees account for a significant portion of mining reward now and as ckpool.org always mines blocks full of transactions the extra rewards can be substantial.
Massively scalable - ckpool can handle extremely large amounts of miners without detriment to performance.

FAQ

Q: Should I use different usernames for each of my miners?
A: You are much better off consolidating all your workers to use the same username and different workernames. The reason is each different user will get a separate reward transaction at block find and each transaction will attract its own fee to spend at a later date, so you'll end up spending less fees if you just use the one username. Additionally if you have multiple small miners (eg. USB sticks), you may never get over the dust threshold if each miners to a separate address.

Q: What is the dust threshold?
A: 5460 satoshi or 0.0000546 BTC. Once enough herp has been amassed to create this much derp, miners will enter the payout queue.

Q: Are there any restrictions on hardware?
A: Only ASIC miners are allowed. Only mining hardware/software that is faulty or malicious and cannot mine high diff shares or has some/all blocks withheld that you are conscious of is not allowed - using such hardware will lead to substantially decreased rewards.

All pool code source freely available here: https://bitbucket.org/ckolivas/ckpool-splns

Support and live discussion on IRC: irc.freenode.net #ckpool

Pool code and pool operated and created by Con Kolivas, creator of cgminer and ckpool.

Maybe they're using a covert asicboost of their own and these are the random transactions they're generating to do it with...

Meh, not remotely surprised. I also happen to know that some pool owners are being coerced into mining BU under fear of not getting hardware from bitmain, along with financial incentives being offered to otherwise neutral poools.
How does one actually do that? We don't happen to be sitting on a truckload of money and asic manufacturing plants to overwhelm them; they are the producers of the bulk of the bitcoin and litecoin hashrate. This is why people are talking about a proof of work change, which I think would be terrible for bitcoin at this stage myself. The destabilisation of the network to move from being dependent on hundreds of millions of dollars of ASIC hardware investment to amateur hardware in the home would be a huge hit to the security and stability of the blockchain. There is no real thing as an "asic proof" algorithm; with enough financial incentive anything can be made into an asic - and bitcoin has the incentive there. A proof of work change will just make us go through the process of switching from cpu to gpu to fpga to asic all over again.