Pages:
Author

Topic: Laurentia Pool - BAD risk for miners - page 5. (Read 2316 times)

legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
July 22, 2020, 03:08:33 AM
#45
No, I’m saying you simply reap the rewards from the effort you put in. Obviously you don’t care about your pool to focus your efforts there.

My wife never touches her desktop yet it’s been on 24/7/365 for years as well.

We can go back an forth forever. There's nothing in your criticisms that is note worthy.
Again saying how you think it takes no effort to run a pool.

The people who do mine on my pool do know how much effort I put into it.

The last person, who we both well know was putting no effort into a pool, was -ck who didn't give a shit about the solo pool, ignored it, and lost someone around $50,000
Then he decided that although he has thousands of BTC, he wouldn't cover the losses his negligence caused.
The same person you are saying:
...
This is grass roots startup with no VC funding rounds, no grants, and is the product of considerable thought and analysis, and we specifically reached out to -ck because of his skill and bitcoin centric motivations. Also his care for performance, professionalism, and the synergy for us works 110%.
...
Where any sane person easily sees that there's been considerable thought into our design and we're more than proud to work along side -ck.
...

Again and quite obvious:
"Laruentia Pool - BAD risk for miners"
Using software developed by someone who has so far lost 4 blocks due to buggy code and negligence.
... and has a white paper full of design flaws.
full member
Activity: 1022
Merit: 221
We are not retail.
July 22, 2020, 12:27:34 AM
#44
No, I’m saying you simply reap the rewards from the effort you put in. Obviously you don’t care about your pool to focus your efforts there.

My wife never touches her desktop yet it’s been on 24/7/365 for years as well.

We can go back an forth forever. There's nothing in your criticisms that is note worthy.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
July 21, 2020, 11:49:42 PM
#43
...
You could be so much more productive than continue to write replies that will be tl;dr'd once people realize the immense time sink this is to no result. Which you seem to have in ample supply, showing it's doesn't take much to run a pool now does it.  
...
And here we have it.
The basis of why you've made so many mistakes in your white paper and either made a lot of it up or were lead astray by someone else.

You believe it doesn't take much effort ... and your white paper states you are doing exactly that ... to run a reliable good pool.

Time sink for me? Not much.
Running a pool? Yes I do it 24/7/365.25 for almost 6 years now.
full member
Activity: 1022
Merit: 221
We are not retail.
July 21, 2020, 11:40:04 PM
#42
We can go back an forth forever. There's nothing in your criticisms that is note worthy as every pool has it's features and benefits. You're biased as are we, we can just admit it. Also our code isn't public so please stop assuming you know anything about anything regarding LP. It's a protected mining environment and although -ck would like to make it public we've asked him not to at this point. Which you can flame as non transparent as well but other ops don't have public code either.

0.3% fee covers the cost of operating the pool and more at our minimum cadence, to drive more development specifically to the pool. I've already addressed block loss due to operational error. The fee also scales for us as operators like any other pool, so the more hashrate the sooner we can have reserves and leave fiat based insurance and the more we an do for our users. This is grass roots startup with no VC funding rounds, no grants, and is the product of considerable thought and analysis, and we specifically reached out to -ck because of his skill and bitcoin centric motivations. Also his care for performance, professionalism, and the synergy for us works 110%. We're also showing how operators needlessly rent seek miners with high fees, though we're not greedy but still want our payday. As well we're very transparent in our fee as large pool already have back door deals with farms for considerably low fees. As every hash has the same probability it doesn't make sense to tax one user over another. We don't have a login requirement just pw, and no op wallet to manage for users. So overhead is even less. So who is putting reward and personal data at more risk? I wouldn't trust you hold a door a for someone let alone hold coin.

It's fine if you think you operate a pool "better", I would believe all operators would make the same case. You just seem to be fixated on LP for reasons already mentioned prior. Again, I'm flattered for the attention you give us, as it's just more exposure. Where any sane person easily sees that there's been considerable thought into our design and we're more than proud to work along side -ck. It's also ok if you disagree with anything and everything, we can't please everyone.

If you want to take my distain for pools with a considerable fee that in my opinion doesn't really innovate for it's pool base but funds projects and also excepts grant monies for projects, it fits the narrative you'd like to tell, though completely out of context. And as once a long time Slush Pool user I'm allowed as a consumer to have an opinion on their service. I also don't have a flaming thread attempting to discredit all their work, nor have I cared to flame your work excessively like you do. It also shows that anyone can pick anything apart if they choose to. We don't have a great relationship with Slush Pool but still these are people we happily engage with and always look to have productive, provoking discourse and they take my critiques seriously in our private and public conversations.

Even after all your blatant attempts to incite us to come down to your "karen'ing" of the mining section here, just tells me you're more focused on what others are doing than your own work. Likely scrambling for a FIBRE fix thinking your some sort of god while we already made their loss a non event for us, like many other points in our design.

If you'd like to continue to compare LP to a free and feely open community pool that's ok as well but still has nothing to do with LP besides any arbitrary association you stretch to make. And again, you're still using this thread to promote YOUR work, YOUR preferences, and lack of relationship skills under the guise of some sjw assumptive, conjecture that you then reflect onto us.

You could be so much more productive than continue to write replies that will be tl;dr'd once people realize the immense time sink this is to no result. Which you seem to have in ample supply, showing it's doesn't take much to run a pool now does it. 

We cut zero corners with our services, which are provided at a high level or would not occur. We have limited risk considerably in multiple ways for our users. Our whitepaper isn't perfect but considering the competition is well ahead of the curve and we're not going anywhere.

"So get used to it".

#mineon
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
July 21, 2020, 08:17:03 PM
#41
We are insured, plan to use funds from fee generation as proof of reserves in case of any errors in or out of our control to safety net our users work in lieu of insurance in the future.
At a pool fee of 0.3% it will take you 333 blocks to just cover the cost of a single lost block, with no income to pay for servers or anything else.

I did this on KanoPool due to the problems of -ck's poorly coded and tested code, and that was just before what lead up to him kicking me out of the ckpool and cgminer git. He wasn't happy about it Tongue
My pool already has a few (current) blocks worth of pool fees that I've not paid to my wallet, to cover anything that might go drastically wrong.
But I have also removed specific problems from the ckpool code I use that are still there in the public git.
Aside: there is more code in the ckpool git by me than by -ck.

FIBRE is non essential for LP or solo ckpool, it's loss will be missed by the network but ck pools are unaffected. So beyond that our server is extremely well connected and block switching is extremely fast for both the pool -ck hosts and LP which he co-operates specifically the server side.
You can't just make a statement that is clearly wrong, without some proof of why you think the logical need of distributing your blocks quickly and getting blocks from the majority of pools quickly isn't necessary.
That makes no sense at all for anyone who has even the slightest understanding of how bitcoin works.

No matter what you say, it takes some number of milliseconds to process a block find.
But then that block needs to get to all the other pools, to stop them trying to find a competing block with the one you found, and move on to finding the next height block built off your block.
On top of that, there is the requirement to see the blocks of other pools as quickly as possible, so you aren't working on stale work, like what happened on the solo pool in the extreme when they recently lost a block.

Without the fibre network, your block will only get to other pools by relay from your bitcoind to those you are connected to.
Thus it will be a number of (slow) steps from wherever your bitcoind is to the pools in china ...

...
Don't get me started on how shitty slushpool is. This "beta" shit is the same UI with features they should have built in years ago.

Quote
If anything we, including -ck are very open and transparent. Likely this is well known by anyone who has engaged with us before.
... and yet on the multiple occasions that his pools have lost blocks, no one knew except the miner who found the block, that then prompted him to explain why.
That's not transparent - that's hiding important information.

Quote
Everything you state in this thread is extremely assumptive
I've run a reliable pool for 6 years, and had to deal with the problem known as -ck for many of those years.
There's no assumptions in anything I've said.
I'll make it quite clear that I am an expert in bitcoin, networks, software development and server management.

Quote
As for the technical aspects you'd have to consult -ck but I know that relationship is tarnished, so good luck getting answers. I'll just say there is a reason we chose new high end equipment to host our server on, to not just benefit us as operators but to benefit our users and future optimizations and efficiencies without restraint.  
If your definition of "high end" is that tiny server -ck uses for the solo pool, then you clearly have no idea what is required to run a pool.
Remember, he ran a pool on a piece of junk for years that only by luck didn't lose more blocks than it did (or did it and no one knew?)

As a lot of the people on my pool know, I use two types of servers just for the nodes, one equivalent of your so called "high end" and one with half the ram - duplicated in the major areas on two different providers.
The main server is MUCH more powerful.

Basically you are saying you are cutting corners, spending only $120 a month on a server to support millions of dollars of mining hardware,
instead of setting up a proper pool with distributed nodes to get the blocks out to the rest of the network.
One lost block due to poor network distribution is (currently) about $50,000 yet you're only willing to spend $120 a month to deal with network distribution Tongue

"Laruentia Pool - BAD risk for miners"
Using software developed by someone who has so far lost 4 blocks due to buggy code and negligence.
... and has a white paper full of design flaws.
full member
Activity: 1022
Merit: 221
We are not retail.
July 21, 2020, 07:04:27 PM
#40
FIBRE is non essential for LP or solo ckpool, it's loss will be missed by the network but ck pools are unaffected. So beyond that our server is extremely well connected and block switching is extremely fast for both the pool -ck hosts and LP which he co-operates specifically the server side.

Of course like you state any pool which submits a "winning" share from two miners at the same will have conflict. Our whitepaper outlines well our take on networking, and reasoning for our single node setup. I'm not sure what you're trying to argue as larger pools are starting to either adopt something similar or develop more on stratum like V2 which is mostly to support better the inefficiencies of satellite/proxy nodes within the same pool. Also we don't expect higher orphan chance, we expect less than competitors.

Our UI now although very basic displays best share so I'm not sure how we're not transparent as you claim when other pools provide less insight in these metrics, but still have the need to attack our service. Our goal as well is to use our fee to build out the UI to our users needs which could include more metrics requested by consensus. If anything we, including -ck are very open and transparent. Likely this is well known by anyone who has engaged with us before.

Everything you state in this thread is extremely assumptive, we've had great response to our whitepaper and service even from competitors. Which most are welcoming and excited to have new challengers in the sector. So it's more odd you give us soo much negative attention, then I've addressed my speculation on that in previous replies.

As for the technical aspects you'd have to consult -ck but I know that relationship is tarnished, so good luck getting answers. I'll just say there is a reason we chose new high end equipment to host our server on, to not just benefit us as operators but to benefit our users and future optimizations and efficiencies without restraint. 

The quote, those are my words and if wrong I'm happy to fall on that sword. It just shows our confidence in our product and displays without a doubt we're here to compete and drive results. I'm ok with being arrogant or perceived as in this regard, I do find it amusing though that this argument comes from you of all people here.

Please continue to feel free to slander our product and pump your own at the same time which is the theme of this thread. I just don't think you'll be able to piggyback our momentum this way.

70.1 PH in commitments so far, 230 PH needed pending network, likely less now honestly if trend continues.

"Laruentia Pool - BAD risk for miners. .. to not mine with us".

#mineon
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
July 15, 2020, 09:22:10 PM
#39
... and a minor update to this regarding the white paper.

The Fibre block relay was shut down yesterday.
So getting your blocks to other pools fast, now depends entirely on your own block distribution and worldwide node network connectivity.

Thus Laurentia would expect a higher orphan rate (LOST blocks) than any pool that does have a good worldwide distribution of nodes ... like my pool does.

... and related to that, whoever wrote in the white paper about the irrelevant issue of multiple nodes finding more than one block at the same time, clearly has no understanding of that.
It doesn't matter if 2 miners find 2 blocks at the same time. Of course you will only get one, no matter what you do about that.
However, it is ALWAYS possible for 2 miners to find blocks at the same time no matter where they mine, even on the same node.

The biggest issue with ckpool about this, is that it hides this information.
Like the last block that pool lost, no one knew about it except the miner, until the pool OP was prompted to look into it.
Aside: if that happened with a rental service, no one would ever know if you can't check with the rental service best shares or blocks found.

My KDB displays ALL blocks found by all miners on the pool, immediately on the web site, then reports which blocks are valid/orphan/rejected/stale etc.

--

Our server is highly optimized and more efficient than any other pool on market. Full stop.
...
This is a claim you are making with zero proof - nothing to back it up.
ck has never tested his pool code performance against the other pool's code performance.
It is simply just his arrogant opinion that his pool code is "more efficient than any other pool on market"

A simple comparison I CAN make, my KDB software running on my pool, that does all the same work as the ckpool front end running on my pool except it doesn't do work generation once every 30 seconds and network IO to miners, but it does also do a lot more work processing, web site processing and accounting, uses approximately only 1/3 of the CPU of ckpool running on the same hardware with it.
This is simple for me to see, looking at the CPU usage of the two processing running on the pool, as anyone else can also verify the performance of the current git of both pieces of software - though my current KDB now has even better performance than the public git version.
legendary
Activity: 3234
Merit: 1220
May 28, 2020, 02:13:57 AM
#38
Well i know that i was talking about SPV mining, but don't nearly all pools conduct spv mining? If kano does not then he must state things as they are, in his reply to my topic he makes it seem like he is magically beating the odds, which is not the case.

Not only does kano.is not conduct SPV mining, neither does ckpool nor does your pool. Empty blocks was not what this topic was concerning.

Also fully validating blocks the way he does it "taking your words for it because I don't know if he does" lowers the pool chances of finding blocks, those who mine to his pool waste a portion of their hash power "doing nothing" until the previous block's transactions are validated and thus risking a potential empty block (The exact reasons why most large pools do the opposite)

I am not implying that one thing is better than the other to bitcoin as a whole, simply stating the potential risk and loss in the way he conducts his pool, as you may already know most miners would prefer not to risk losing a block by wasting a few seconds of mining for the sake of block rewards ( the majority probably don't care about anything but fiat profit), if Kano does that he should make it clear and then miners can chose if they want to use his pool or not, but he doesn't do that, he simply uses that fact to advertise his pool, the same thing he is doing now in this thread and his thread by attacking Ckpool, Laurentia pool and nearly all pools, every pool except for his is a terrible pool according to him.

Just to be clear, no-one is attacking ckpool or Laurentia pool for mining empty blocks. I'm not sure why you brought empty blocks into the discussion, the first mention of it in this thread is in post 18
legendary
Activity: 2394
Merit: 6581
be constructive or S.T.F.U
May 28, 2020, 12:04:16 AM
#37

Well i know that i was talking about SPV mining, but don't nearly all pools conduct spv mining? If kano does not then he must state things as they are, in his reply to my topic he makes it seem like he is magically beating the odds, which is not the case.

Also fully validating blocks the way he does it "taking your words for it because I don't know if he does" lowers the pool chances of finding blocks, those who mine to his pool waste a portion of their hash power "doing nothing" until the previous block's transactions are validated and thus risking a potential empty block (The exact reasons why most large pools do the opposite)

I am not implying that one thing is better than the other to bitcoin as a whole, simply stating the potential risk and loss in the way he conducts his pool, as you may already know most miners would prefer not to risk losing a block by wasting a few seconds of mining for the sake of block rewards ( the majority probably don't care about anything but fiat profit), if Kano does that he should make it clear and then miners can chose if they want to use his pool or not, but he doesn't do that, he simply uses that fact to advertise his pool, the same thing he is doing now in this thread and his thread by attacking Ckpool, Laurentia pool and nearly all pools, every pool except for his is a terrible pool according to him.

Anyway, i am out of here, @NotFuzzyWarm thanks for the civilized conversation and friendly attitude, if people won't learn anything new from this discussion they could at least learn to be polite.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
May 27, 2020, 08:30:03 PM
#36
I moved the reply to kano.is where it belongs.
No idea why Phil is posting 'questions' about kano.is here Tongue
https://bitcointalksearch.org/topic/m.54514542
legendary
Activity: 3752
Merit: 2667
Evil beware: We have waffles!
May 27, 2020, 07:42:32 PM
#35
This is a misconception spread by Kano to advertise his pool.

Empty blocks MUST happen regardless of everything else, I can go with the technical explanation of why must they happen, but since I have already explained that I'll refer you to aantonop.



And I refer you to what you talking about - SPV mining which is a subject wholly off-topic here.That said, one last bit about it from Core developer Gregory Maxwell that he posted long ago on Reddit Very salient point he says at the end:

Quote
SPV makes a very strong security assumption that the hashrate of the network is verifying transactions. At least under some conditions this assumption has proven invalid.

The fact remains that it is up to the pool operator to decide to use it or not. Kano does not and only references fully validated blocks - not just the headers. Ergo - no empty blocks.

re: 'Hypocrisy over cgminer usage by manufacturers and hacks thereof, I refer you to the more appropriate thread were I answered that.
legendary
Activity: 4256
Merit: 8551
'The right to privacy matters'
May 27, 2020, 02:12:27 PM
#34
I know kano has had a very small next to nothing tx fee block.

I don't recall if it was under 30 seconds for sure.  I think the clock times were 9 or 17 seconds.  He was close to a fee less block.

Part of the empty blocks are due to manipulation and skipping the last transaction from the previous block.  Thus a very fast "empty" block.  But a block none the less.

So would you rather hit 5 blanks a month.  Or all the blanks have a small amount of tx fees but you don't get the 5 you lose one to a guy that went shortcut method.

I wonder which is better.  It would be really hard to determine how many small fee fast blocks happen for a pool using kano's method vs 1 extra block empty via the shortcut method.

If both are legal it is a pool operators choice to do one or the other.

As block reward 1/2 's more pools may not choose the faster method as tx rewards are greater.

But as I said I truly do know how stupid I am and will continue to be. So I just like friendly people to run my pools.  I am not going to get rich here. so why argue.
legendary
Activity: 2394
Merit: 6581
be constructive or S.T.F.U
May 27, 2020, 01:51:52 PM
#33
The only time an empty block MUST happen is the very very rare times mempool is empty. Aside from that, generating empty blocks is a conscious decision made by the operators of certain large pools. They are not a random event that any pool might do in the course of normal operations.

This is a misconception spread by Kano to advertise his pool.

Empty blocks MUST happen regardless of everything else, I can go with the technical explanation of why must they happen, but since I have already explained that I'll refer you to aantonop.

Now let's take simple practical examples.

Today viabtc mined an empty block 631926 , the next block had 0.46 in fees, yesterday 1THash&58COIN mined an empty block 631806 and block 631807 had 0.75BTC in fees.

Are you implying that these pools are sacrificing thousands of dollars for nothing? does a pool that owns 10% or 20% or 30% of the network hashrate run an inadequate code or slow servers?? of course NOT.

Empty blocks will ALWAYS come by because the time it takes to download and verify the transactions of the previous blocks is >0 and
1- Wait until they verify the transactions of the last block.
2- Risk putting transactions which were included in the previous block.

Number 1 is risky because another pool might beat you to it, Number 2 is risky because if you include a transaction from the previous block your block will be invalid and nobody in their mind will take that risk.

If the above is still hard to digest, take a look at the number of empty blocks mined this year, exactly 14 empty blocks for each month

Jan 14 empty blocks.
Feb 14 empty blocks.
March 14 empty blocks.
April 14 empty blocks.

Those empty blocks are found by various different pools, what does that mean?

A- Pool operators sit together in a closed room and decided how much money they want to lose.
B- Statistics, maths, and probability.

if you believe in A, stop reading, if not please continue.

What does finding 14 blocks mean?

every day we find 14/30 = 0.46 empty blocks = 1.63% of all blocks WILL be empty

For T = 0.46 a nd % = 1.63

exp(−TimefromSeconds/AverageBlocktime)−exp(−TimetoSeconds/Averageblocktime) = 0.016 > 1.63%

exp(−1/60)−exp(−2/60) = 0.016 > 1.63%

This means the average time for mining pools to download and verify transactions of the previous blocks is greater than 2 seconds, anything that falls between >0 and <200ms WILL HAVE to be empty, Kano can't do shit about, Pools can't avoid it, Satoshi can't fix it, Albert Einstein won't bother with trying to change it.

In my book he rightly refuses to support folks who do not care about copyright and usage licenses. He cannot reasonably block equipment from Bitmain, MicroBT and a few others that started the chain of violation but he can keep the far smaller number of folks from using 3rd party mods of it on his pool.  -ck not caring anymore on that point is up to him.

or he doesn't give a shit about Cgminer license, but he is an attention seeker, and since

1- Bitmain, Microbt won't be wasting their time replying to him > no attention
2- Most of the custom firmware devs are active on this forum and they will reply to him > attention received

Add to that the fact that the majority of mining gears probably run stock firmware (which violate the GPL license a million times more than these custom firmware ran on a relatively small number of miners) the loss in profit that comes with blocking stock firmware that violate that exact same license is way too huge for his pool to handle, but the small quantity of miners running custom firmware is not a big loss.

So Bitmain and MicroBT violate Cgminer license > No problem, you can mine to my pool. Two or three custom firmware violate Cgminer license> You can't mine to my pool because I argued with you on the forum and I told you that you were wrong, my ego doesn't let me.

If kano REALLY cares about the Cgminer license as he pretends, he MUST block all Bitmain and Microbt firmware from mining to his pool/s, if he doesn't do that, I can only call this "hypocrisy", and I won't be surprised if after 1-2 years custom firmware dominates the mining gears, he will allow them to use his pool.
legendary
Activity: 3752
Merit: 2667
Evil beware: We have waffles!
May 27, 2020, 01:13:46 PM
#32
Getting OT here but,
Quote
Unless I am missing something if it's solo then 3rd party firmware should not matter.
It matters because as one of the major developers of cgminer who worked with -ck, Kano takes great umbrage towards folks that violate the GPL license.  -ck not caring anymore about that point is up to him.

In my book he rightly refuses to support folks who do not care about copyright and usage licenses. He cannot reasonably block equipment from Bitmain, MicroBT and a few others that started the chain of violation but he can keep the far smaller number of folks from using 3rd party mods of it on his pool.
legendary
Activity: 3500
Merit: 6320
Crypto Swap Exchange
May 27, 2020, 12:49:28 PM
#31
Somewhere, sometime in the past I actually posted something similar to what mikeywith said about preferring to mine in a friendlier environment with a more pleasant operator.

As the saying goes time is money, and if I have to spend *time* dealing with an issue because the person running the pool does not want to, or has the mentality that "it's never my fault, I do a better job then everyone else" then I don't mine there. Because, with the equipment I have after electric & everything else I am only netting about $500 a month. It's not worth it for a few extra bucks to get grief and waste a 1/2 day dealing with something.

Case in point. I spend a lot of time dealing with network routing. I was having issues connecting to a certain pool years ago. Sent the operator detailed logs, showed him where the issue was in his network / data provider and then got back a reply that it had to be my fault everyone else was connecting fine. Guess what, they were not, they just did not notice that what should have been a 10ms to 40ms response depending on where they were was actually closer to 125ms. I showed again what the issue was and posted in the thread where it was. And the post got deleted. So I left.

Since you brought it up this is not marketing: a Kano solo pool is in the works. While he will understandably still not welcome miners using 3rd-party firmware hacks, the solo WILL accept rentals.

Unless I am missing something if it's solo then 3rd party firmware should not matter.

Stay safe.

-Dave
legendary
Activity: 3752
Merit: 2667
Evil beware: We have waffles!
May 27, 2020, 12:13:39 PM
#30
...
But as i said I am a stupid moron.  Please correct my math if I made any errors.
Personally if possible I would mine in a:

 kano.is solo pool
 solo.ckpool

 pps+ pool
A moron? Hardly.
Yes kanopool's luck has not been great after the pool had a prolonged run of bad luck forcing some very large players to go elsewhere last year. Thing is, registered users have access to a very clear stats page regarding blocks found and pool Luck. Its users have summarized full data, warts and all, going back to the start of the pool to base their decisions on. Few if any other pools do that.

Since you brought it up this is not marketing: a Kano solo pool is in the works. While he will understandably still not welcome miners using 3rd-party firmware hacks, the solo WILL accept rentals.

Along those lines btw, in late 2017 (?) there was an issue with both MR and NH rental services that really skewed work received through them for well over a month - that is why they were banned from the main pool. Similar to the Slush/Genesis kerfuffle some very large (and since was a 5ND PPLNS pool, very long term) rentals were getting an unwarranted share of miner rewards from blocks found by others. It was only because full logs of miner performance and pool-state are kept in KDB that the issue and root cause was discovered which led to the rentals ban. With a solo pool that becomes a moot point.
legendary
Activity: 4256
Merit: 8551
'The right to privacy matters'
May 27, 2020, 11:29:21 AM
#29
I would like to point out that lifetimes stats for luck on kano.is

are 101.17%   for 2429 blocks

but that for the last 1000 blocks

the luck is 96.02%

and for the last 500 blocks

the luck is 92.41 %

This last 500 blocks took 153.8 weeks

153.8 weeks is very close to 3 years ago.

May 27 2017 is  3 years ago.

June 15 or June June 16 2017 is 153.8 weeks ago

My point is once BTC became valuable or more valuable

Kano.is has had really bad luck.

Coinbase price on:

 June 11 2017   about  3000
 July  13  2017  about  2300
 Aug  14  2017  about  4300
 Sept 15  2017  about  3700
 Oct   17 2017   about  5500

May 27   2020   about  9200

I could go on and since I am a stupid moron I will go on.

500/.92 = 543.47

so kano.is is off 43.47 blocks since his last 500 blocks made.

So As a stupid moron I ask why has kano.is had brutal luck over the last 500 blocks made by the pool.

Why did kano.is have great luck  when they made the first 1929 blocks

the luck was so good when blocks were worth very little
the luck is brutal when blocks became valuable.

Does it mean anything?  I don't know I am a stupid moron.

but 105% for 1929 blocks.   coins under 3000

and 92%  for 500 blocks.     coins over 3000

So  even if solo.ckpool sucks and lost 3 to 4 blocks out of 255 blocks

kano.is has had a 500 block 153.8 week unlucky streak.

But as i said I am a stupid moron.  Please correct my math if I made any errors.

Personally if possible I would mine in a:

 kano.is solo pool
 solo.ckpool

 pps+ pool
legendary
Activity: 3752
Merit: 2667
Evil beware: We have waffles!
May 27, 2020, 10:21:26 AM
#28
Quote
Kano is using this thread to promote his own product
And just where has he said anything in this thread that can be construed as Marketing of his pool? Nowhere. It started as a way to bring to light valid concerns regarding the pool software used and its known problems in the past. I agree the title is a bit over the top but at least it got the conversations going Wink

When specific points have been brought up he states what he has done regarding those points. Ja he tends to also point out what others have not done - so what? As a counter point one can always explain why they think his solutions are unnecessary. This is a technical discussion after all and that is how discussions are supposed to work...

Quote
empty blocks MUST happen unless the time it takes to download a block, verify transactions, deal with the mempool, build a block =< zero ms, which is not true even if you claim so, even if all pools run on the same LAN with block size being 1byte time will never be =< 0, there will always be empty blocks and there will always be orphan blocks,
The only time an empty block MUST happen is the very very rare times mempool is empty. Aside from that, generating empty blocks is a conscious decision made by the operators of certain large pools. They are not a random event that any pool might do in the course of normal operations.

Orphans are another story and mainly related just to how fast a pool connects with the rest of the BTC network to make it known they found a valid block and have their block included into the next work generated vs a different block found at nearly the same time. As such, yes any pool can and will from time to time have orphans but a well connected pool should have very few.
full member
Activity: 1022
Merit: 221
We are not retail.
May 27, 2020, 09:53:07 AM
#27
Our server is highly optimized and more efficient than any other pool on market. Full stop.

I would invite everyone to read our whitepaper and note the section on networking which was drafted by -ck with minuscule edits (a few double spaces). We have optimized mining conditions for the user in every avenue and provided a hyper competitive product against any scoring scheme including PPS. Our limited user space is specifically designed to produce optimal coinbase transactions for the group. I would be happy to elaborate more in our own thread but technical questions may have to be differed to -ck which his focus on bitcointalk will likely be his own products and projects.

Mine Farm Buy LLC is to manage clients and our front end while -ck is to manage server, code, payout and is literally the only person we would trust to do so (which other pool operators obviously are malicious and produce loss to their users, ie. changing scoring scheme).

This is a completely separate product and not intended to replace a beloved community pool in ckpool.org which was closed at the sole discretion of -ck himself and after our soft launch. 

Kano is using this thread to promote his own product, in a poor attempt to discredit our hard work and personnel knowingly full well -ck refuses to interact with him due to his condescending, self destructive, alienating nature. 

We have done exceptional work bring our model to market and have very much limited the "BAD risk" that other pools overlook to their users by thoughtful design, experience, and market analysis. Again, making this thread baseless defamation and conjecture, and obviously extremely biased.

Everyone is allowed to post constructive feedback in our own thread. Please note Kano knowingly posted inflammatory, baseless content there to be removed and under the guise of censorship opened this thread which isn't any different. He and all are welcome to join us there, all we ask is people interact with a small sense of courtesy when directing comments specifically at individuals.

Thank you though to Kano for promoting our services for us, hits on our landing page have been highly accelerated of late. Unfortunately this will be last reply here, as hopefully the reasons for this decision are abundantly clear. #mineon
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
May 27, 2020, 01:39:05 AM
#26
I moved the reply to where it belongs:
https://bitcointalksearch.org/topic/m.54514603
Pages:
Jump to: