O)))

[alani123]

https://paste.ee/p/mSmUM

[1714525925]

1714525925

[Bluto]

This pool is a joke.

They send work packages of extremely low difficulty and don't adapt them to any miner's needs. They even don't allow the user to set difficulty.
Some mining software will outright refuse to send work to this pool as the work packages it requests are following a format that's so outdated they won't even recognize it.
Even if you hack a modern miner to send work to this pool, it will be very inneficient.

Also they're not utilizing coinbase2, instead stuffing a ton of trash in coinbase1. So they're likely rejecting many shares by modern hardware because of this.

Honesstly these things were taken care in mining even before ASIC miners existed. Why aren't they up to date with modern standards?

I can't even come to think that a bitcoin developer like Luke Dashjr is actually so incompetent. He must be blocking new hardware knowingly for some reason. Perhaps in his catholic mind it makes BTC more decentralzed in some odd way...? Who knows.

I wonder if Jack Dorsey funding this project is just an imbecile completely unaware of Luke's past antics though. Like, does Jack even know enough about BTC to understand that sending low dif work without ability for users to modify it and not using cb2 is like building a pool on 2010 code quality? Does such a project really need millions in funding? Luke blocking new hardware from mining in the pool is antithetical to the very notion of hosting a pool. Let alone "decentralizing" mining in any way.

tl;dr don't mine there. Luke is still a crazy mofo and the pool is even worse than eligius.

[kano]

Be reminded that the eligius python code was shockingly bad in performance such that it got very high orphan rates.
This was discussed in the eligius thread and ignored even though it was so high.
At one point, for a period of time, Luke restricted all blocks on the pool to only 32 transactions to try get around the problem.
Hopefully at least they threw that code away and got a real coder to write a new one.

[alani123]

O)))

[mikeywith]

I'm pretty sure you're just making all that up, because almost none of what you said is true.

How can you be so sure?

If you actually own a miner that isn't able to connect to the pool due to difficulty settings, there should be plenty of methods to tweak that locally too.

There are exactly ZERO ways to tweak that locally, the share diff is set by the pool, not the miner, the majority of pools nowadays don't even let you choose the diff, but they are smart enough to adapt to the miner hashrate, all pools would start with some low diff and then climb their way up to the point where shares at kept at a reasonable pace between the miner and the pool, too high diff and you can't check your work on the pool, too low diff and your miner is going to submit dozen of shares every second which is plain foolish.

Amazing luck so far.

I underlined the keywords.



I have not tested the pool nor do I have the intention to take the gamble, but I don't think that person is lying, it's stupid to lie about something that could be easily verified by others, I mean I just happen not to give a shit about said pool, or else, it takes little to no time to actually confirm/deny his claims.

[alani123]

O)))

[mikeywith]

I want to be clear, I didn't mean users could change what the pool does.

I only commented on this part

If you actually own a miner that isn't able to connect to the pool due to difficulty settings, there should be plenty of methods to tweak that locally too

So tweak what exactly?

Edit: For the rest, I can attest that what that user claimed about inefficient shares and rejecting hashrate is 100% false.
Connecting to OCEAN pool the performance of miners was the same as to different pools, and I've personally checked this using external monitoring.

Great then, the burden is on him to prove his claims, he needs to post solid evidence or else, nobody would take his claims seriously now that someone has came up with a counter claim.