Be more precise in text descriptions concerning hardware advantages about blur HOT 16 CLOSED

I’m sorry, but I don’t see anywhere that claims our code is GPU-resistant, or ASIC-resistant for that matter, on this repository. Further, hashing without a CPU would be very inefficient. A miner needs a node being run at least, to do the calculations. If these are being communicated remotely, as with pools and gpus, things get pretty inefficient for those devices, relative to other algorithms. GPUs have only a small advantage over CPUs, if any.

I appreciate you proving that a GPU miner is possible, seemingly on any algorithm variant. This means that virtually all of crypto appears to be under the illusion that resistance is possible to hardware types. Clearly, it is not.

We only claim to favor CPUs, by drawing blockchain data directly from the block header. This data is then used within the calculation that dictates the count of iterations in cryptonight. As a result, the iterations cannot be predetermined, since they function on the previous block’s hash directly.

It is clear that the best that can be done (in terms of resistance) is simply requiring that a daemon is being run somewhere to fetch the data. We do not claim or seek to be resistant, due to this fact. It is an infinite game of cat-and-mouse, designed to distract users and keep eyes away from other areas (in my belief). And this is if we ignore insider threat...

We don’t “market” BLUR. Have never, will never. This coin is a technological experiment, designed to uncover truths similar to those you have helped us see more clearly. Calling what we are working on “misleading” is simply untrue. I’ve said many times we won’t continually fork to create the appearance of “resistance” whether that be to pools, GPUs, or otherwise. We simply don’t officially support GPU miners, or pools.

Apart from that... the pool you were running only managed to send a couple jobs to workers, before becoming inactive. Can you elaborate on why the pool only sent out a couple templates? @fart-master

from blur.

Title should be changed to something accurate, as we don’t claim anywhere to be “cpu-only”. Only that we favor CPU strengths. “Fake advertising” seems particularly inflammatory and quite possibly maliciously seeks to give a false impression.

from blur.

With all that said, the website text will be amended once our team gets around to it. Those words were true at the time of writing, but you are correct that some of them no longer are. Regardless, the network thanks you for your adversarial development of a miner. While intent was Im sure less than productive, we welcome others to challenge our model in the open source manner that you have.

from blur.

Will leave this open for a few days to see if we can get a dialogue going.

@fart-master would be great if you could address my question regarding the breaking of pool template dispatching

from blur.

I will attempt to address what you are saying in point form

1. Your website specifically states that GOUs don't work. You also have a graphic with a big cross through the word GPU and a tick on the word CPU. You can try to split all the hairs you want. You are clearly giving people the impression this is a CPU only coin when it isn't.

2. A node is not required. the GPU miner can run against a synced node, but there is also a working pool i have in a private repo.

3. You aren't using "blockchain data". You are using the previous block hash, which is part of the block hashing blob. literally every piece of "blockchain data" is available to the user when they receive the mining job

4. It is not required to predetermine the number of iterations and there is no advantage in this approach to reducing the mining performance of a GPU. All you have to do is pass the new number of iterations to the GPU as a kernel argument when a new job arrives and that is the only change. There is no compile time optimization done on this number, so it can be changed at will without sacrificing any performance. You say you are "favoring CPU stengths". This is also inaccurate. Any suggestion this algorithm is better suited to CPU is false.

5. Every miner requires a node to be run somewhere. pools run nodes. But as i already stated, all the information required to hash a block with this algorithm is included in the block hashing blob.

6. The pool operated for a number of days. i don't think you know what you are talking about here. it was taken down because the node backing it was losing connection to the network and the point had already been made. I have since modified the node software to not validate any incoming blocks and it now maintains a network connection, so it is possible to relaunch the pool and i believe those problems will be resolved. So it was not a problem with the pool, but of the blur software it was running on and it's inability to stay connected.

7. There were undoubtedly private GPU miners running on blur. What i did was make this public. I don't see how this is "less than productive". I tried to tell you a GPU miner was possible.

8. What are you even talking about would be great if you could address my question regarding the breaking of pool template dispatching. As already stated, nothing is broken except the ability of a blur node to maintain a network connection, which i have since fixed.

In summation. the blur algorithm is easily minable via GPU with no performance degradation. the hashrate ratio between cpu and gpu is about the same as monero CNv2, even though the raw numbers are different due to the reduced scratchpad size and iteration count. This is due to the fact that besides those coupld of minor tweaks and this variable iteration count, the blur algorithm IS CNv2. To suggest that the blur algorithm is more biased towartd CPU mining is the same as saying CNv2 is more biased towards CPU, which most people know to be false.

There is no requirement for running nodes beyond what is already a requirement to running a pool. Running a pool does not concern me. I have already proven it possible, but if you would like a blur pool, let me know and i'll relaunch it.

if you feel i have not addressed anything, please reply and i will provide clarification

from blur.

Your website specifically states that GOUs don't work. You also have a graphic with a big cross through the word GPU and a tick on the word CPU. You can try to split all the hairs you want. You are clearly giving people the impression this is a CPU only coin when it isn't.

We are forked from Nerva. The only claims being made there, are ones that were inherited from them, and were assumed correct. As you've said, it is clear that those assumptions were incorrect. However you may interpret the graphic is subjective. Our goal is making CPU mining logically viable for a longer period of time. That means not officially supporting technologies that lead to degradation of network integrity through centralization.

A node is not required. the GPU miner can run against a synced node, but there is also a working pool i have in a private repo.

and

You aren't using "blockchain data". You are using the previous block hash, which is part of the block hashing blob. literally every piece of "blockchain data" is available to the user when they receive the mining job

A node is required to fetch the data. That node needs run somewhere, at best... as I said. One must know the previous block's hash, which is indeed historical blockchain data. Adding any further reads to the database does nothing to prevent the same practice. We use the header, because it prevents other miners from needing to keep a running lookup table. Our goal was to ensure that those who may wish to disprove our methods, have a simple entry to do so.

We're seeking to try new things, and find out if they work! That doesn't mean we intend to make it extremely hard for others to prove they do not work. On the contrary, actually. So again, I appreciate you being the one to help us out with an adversarial perspective. It helps the tech improve, when this takes place in the open instead of inside developer-owned walled-off gardens.

It is not required to predetermine the number of iterations and there is no advantage in this approach to reducing the mining performance of a GPU. All you have to do is pass the new number of iterations to the GPU as a kernel argument when a new job arrives and that is the only change.

In passing the new number as an argument, that number needs fed into the kernel code by something that can use types not limited by constexpr. Variable arguments make declaring a function constexpr generate an error, at compile time. What you're referring to is gpu-optimization. Nothing can prevent optimization by a heterogeneous mixture of hardware. Its quite literally why these devices exist separately.

So it was not a problem with the pool, but of the blur software it was running on and it's inability to stay connected.

Simply untrue. If this is the case, how are you keeping your private one running? I'd venture that it has to do with the timestamping and previous blockhash getting in the way of your template's accuracy. Latency within communications from pool to workers is a very real factor, when the template data needs to be accurate for the calculations to succeed. Our templates change more than once per block, due to the timestamp (and CN's decidedly different way of handling local node time).

Again, we do not claim resistance to any hardware. What we are doing here, is attacking the issue with a different approach. This is why we didn't fork away when you went on your "dev needs to fork the network" rant on Discord. We welcome this kind of development and, actually, needed this to happen before we had any logical reason to launch a GPU chain in the future.

I'm sure you're right that private GPU miners exist everywhere. We now have proof of concept in the open, which is what I was hoping to achieve. Such a thing simply doesn't happen elsewhere in crypto (mostly "CPU-only" coins).

To suggest that the blur algorithm is more biased towartd CPU mining is the same as saying CNv2 is more biased towards CPU, which most people know to be false.

I was not aware that such a thing was "known to be false." But, its why we're here doing what we are. Uncovering truth and knowledge, publicly, through experimentation and dialogue about these events. This is how that veiled culture within "secret miners" will come to the surface. I don't see another way. I'm still not sure I agree with your perspective that no CPU-bias exists there. But all dialogue and opinions is/are helpful.

from blur.

Running a pool does not concern me. I have already proven it possible, but if you would like a blur pool, let me know and i'll relaunch it.

It would be good to see one running in the open for longer than a few blocks, to observe. You've seen that I won't be deluding our users into wrongful perspectives on resistance. So yes, all mining adaptations are helpful to have around. Just let me know once you have one running publicly once again. No need for that to go on longer than an observational window, unless you feel like doing so.

Either way, we don't plan on getting in the way of what what miners want.

from blur.

where to begin.

A node is required to fetch the data. That node needs run somewhere, at best... as I said. One must know the previous block's hash, which is indeed historical blockchain data. Adding any further reads to the database does nothing to prevent the same practice. We use the header, because it prevents other miners from needing to keep a running lookup table. Our goal was to ensure that those who may wish to disprove our methods, have a simple entry to do so.

it is not required to read the previous block hash from the blockchain. it is part of the block hashing blob, which is what is hashed for proof of work. it is easy to extract this information as i demonstrated in the miner. saying the node needs to run somewhere is just silly. of course it does. pools run a node. but you don't need to "know" anything. the information is provided.

In passing the new number as an argument, that number needs fed into the kernel code by something that can use types not limited by constexpr. Variable arguments make declaring a function constexpr generate an error, at compile time. What you're referring to is gpu-optimization. Nothing can prevent optimization by a heterogeneous mixture of hardware. Its quite literally why these devices exist separately.

This is just bullshit bingo

Simply untrue. If this is the case, how are you keeping your private one running? I'd venture that it has to do with the timestamping and previous blockhash getting in the way of your template's accuracy. Latency within communications from pool to workers is a very real factor, when the template data needs to be accurate for the calculations to succeed. Our templates change more than once per block, due to the timestamp (and CN's decidedly different way of handling local node time).

You don't understand how your own code works. the timestamp is only relevant at the time the block template is generated. this does not need to happen every 5 seconds as is the default in the daemon. this is not a requirement of the code, just a default value. i have a modified node that will only generate a new block template each new block, or after 3 minutes if a block has not been mined in that time. You are relying on a default value anyone can change and claiming it to be part of your consencus mechanism, Also, as i already stated, i fixed my private node by hacking out the code that verifies incoming blocks, so there is indeed a problem with your code.

And surely you are either lying or simply ignorant if you believe this algorithm performs any differently to CNv2, when it is based almost entirely on CNv2.

A pool did run for more than a few blocks. it ran for a week or so. So please stop trying to diminish the issue.

i am also not sure why you need to make assumptions and guesses when the code is right in front of you. you can see what it is doing. you just have to look.

Finally, all the typing you are doing here is taking away from typing time that could be spent fixing the website

from blur.

And I see we have stopped wanting to have a conversation, and have devolved to your usual insults (appropriating insults from others, nonetheless - at least be original... Come on...)

Mind running that pool we talked about? Or are we just going to dodge some more?

I'll leave this open until the text on website is amended.

from blur.

Oh, also:

Also, as i already stated, i fixed my private node by hacking out the code that verifies incoming blocks, so there is indeed a problem with your code

This is inherited from the DoS-prone protocol code that was written for Monero. I won't be hacking out code that validates incoming blocks, but sync/protocol should definitely be rewritten to handle incoming blocks in a non-synchronous way. Putting a sync process in front of an async one... tsk-tsk :)

from blur.

I don't think you know what sync and async mean. there is no sync process in front of any async process. unless you can explain some part of the code i don't understand, which is doubtful. Probably not worth it to restart the pool seeing how no one is buying blur any more. Not sure what running a pool is going to prove to you. maybe you'll just claim the website is fake. But anyone that knows how pools work and looks at your code knows a pool is perfectly fine and reasonable. You aren't doing anything in the code to prevent it.

from blur.

Uhhh, the protocol's code begs to differ... even you agree with this, prior to this last message.

See:

Also, as i already stated, i fixed my private node by hacking out the code that verifies incoming blocks, so there is indeed a problem with your code.

This wouldn't work with an asynchronous process, because a queue would be properly utilized. So, either you "fixed" something, by hacking out part of the problematic sync process... Or you are lying and fixed nothing at all. Either way, what you're pushing is dishonest.

from blur.

You don't make any sense. I asked you to explain yourself. You didn't. You don't seem like you understand the code you work with. You want a conversation then waste time with nonsense. I see no point to continuing talking to you. I see you doing this a lot. Just talk meaningless nonsense until the other participants give up and leave. Is this a deliberate tactic to try and avoid rational conversation or hide deficiencies in your knowledge? Never mind, don't answer that, because then you will take it as an opportunity to be waste more time with nonsense

from blur.

Locked so that we can't waste any more of @fart-master's precious time, in his months-long, obsessive quest to malign BLUR

from blur.

Will still leave open until website text is amended.

from blur.

Closing, due to website text having been amended. Comment thread has been unlocked, as well.

from blur.