 Show Posts
|
|
Pages: « 1 2 3 [4] 5 6 »
|
|
Only up to the tag. But it seems the recent commits haven't had the bug fixed.
|
|
|
|
|
I might have found a bug in hp7. I copied the hp7 code over to Reaper, and found some weird behavior. I noticed that many shares/blocks it found, had a difficulty with a fractional part of 0.
Function: FermatProbablePrimalityTestFast. It does a Fermat test, and if it fails, it calculates the fractional part. However, there's a fast division test before the Fermat test. If the fast division test is succesful, the function is returned from and the fractional part isn't calculated. If it just happened to be the last number in a chain, the fractional part isn't calculated and is left at 0. This means if the difficulty is for example 6.2, and the miner found a block of difficulty 6.3, it's possible that the fractional part was left uncalculated, and the miner thinks it's difficulty 6.0. The block doesn't get submitted and lots of profit has been lost.
The same applies to EulerLagrangeLifchitzPrimalityTestFast.
Right now I don't have git set up, I can't submit a patch.
|
|
|
|
|
I just finished importing the hp7 code to Reaper, and mined the first testnet block using the CPU miner! I'm a bit behind schedule, but now I've finally started on the GPU code.
|
|
|
|
Do you accept donations in other cryptocurrencies, for example, XPM? Yes, I mean equivalent value to 1 BTC.
Yeah LTC would be good too BTC only, because I don't want any currency risk. You can always exchange for BTC yourself. |
|
|
|
mtrlt, can you confirm you are still going to honor those that donated with a pre-public release?
Yes, of course. If we donate on the day its released will we get access?
Yes, and the price will still be 1 BTC. I thought about raising the price, but it just doesn't feel like the right thing to do. |
|
|
|
Are those blocks rejected by client or by network?
By the client. Most rejections are due to an invalid merkle root, and some are because even though Reaper thinks the block is diff 5 or so, the client says it's far lower, usually diff 0. Yeah I know how to read thank you.  Key word "If all goes well" ... Seems to me there is no way to be done by then, that is why I asked. The CPU miner is almost working already, and GPU coding won't take more than a day. |
|
|
|
Reaper can now mine and submit blocks (EDIT: Clarification: using the CPU, not the GPU yet). However, there are some bugs left that make 80% of all blocks found invalid.  I will now start writing GPU code, and fix the bugs later. |
|
|
|
|
Yes, the final product will include both CPU and GPU mining.
|
|
|
|
|
More updates.
Today I got Reaper to generate prime chains on the CPU. However, it's still missing code that actually assembles and submits blocks. Once I get that working, I will start optimizing the CPU code. Once that's done, I will port the optimized code onto the GPU. At that point, I will be able to give speed estimates, and shortly after the beta will be ready for all you people who donated and will donate.
Thanks to every single one of you who has donated! I wouldn't be able to do this without your help!
|
|
|
|
|
Small progress report time!
Most of the first day was spent setting up the dev environment... libblkmaker doesn't compile under Visual Studio, I had to move to use MinGW for everything. Everything's fine though. This was predictable, and didn't delay development.
|
|
|
|
How fast is the miner going to be?
It is very difficult to say at this point. Some people have/had a bounty for a CUDA miner that is twice the speed of the CPU miner. I think that's definitely achievable.
about what speed are we talking? please give us a more concrete example: what can a HD6990 do or a HD 5850 or a HD 7950 - in PPS please... round-about-numbers... I will have numbers in a few days. I don't want to make baseless claims. |
|
|
|
|
I updated the OP for answers to some of the questions.
|
|
|
|
|
Does it work after N hits 8192?
|
|
|
|
Close but reverse.
I had read the whitepaper and got what I thought was a good understanding, of the way scrypt was supposed to work.
Then I looked at the code and I saw RND being called repeatedly. Of course to my mind it all made perfect sense at that point. You were clearly re-seeding a random number generator. (rounds of SHA256 had dropped out of my head). The reference to SHA256 in the function name didn't really register, but the couple of times I did see it, my internal explanation was along the lines of "ok so he took the framework from the SHA256 algo and modified it to the scrypt algo". At this point SHA256 rounds in scrypt had completely fallen out of my head.
Anyways, yeah I saw RND, realized in my infinite wisdom that you would need a custom seedable random number generator, tracked down the RND at the top said to myself "ok that could in fact work as a way of generating a random list". Never crossed my mind to compare it to SHA256. I get the concept of rounds, but at this point my mind saw that as being somewhere in a loop somewhere. I didn't need to account for it just then.
Whitepapers can leave one very confused, I for one have never read the scrypt whitepaper. I've just taken a cursory glance at it and decided I can't possibly understand its complex language within a reasonable time. Looking at code is far more productive. And yes, the SHA-256 rounds can be in a loop, but usually it's unrolled for speed. Once I saw the section though, that's where I realized that this could be optimized and probably should be optimized by a custom core with only the logic to perform this function. Putting it in the stack unrolled or as a function call would likely be much slower than a call out to a logic unit optimized to the specific task. However the reads and writes in memory would be problematic, hence the idea of sharing on-die memory. Still hadn't quite worked out the nuts and bolts of how it would fit together.
I still feel that way. I'm still studying it, but I do still feel that way.
If you still feel that way, you have to strive to discard that feeling from your mind as quickly as possible, because that way is wrong. SHA-256 is neither the problem nor the hard part in LTC mining. |
|
|
|
|
Silly kitchen psychology coming right up..
I don't think your problem is your age. Then again, I don't know your age, and I'm not old enough to know the effects of aging for sure. (I'm 24.) I think your problem is overconfidence. When you generate a hypothesis out of thin air (which is a valid way of generating hypotheses, and without any information indeed the only way), you assume it must be close to the truth, instead of finding out whether it's even related. Example: You assumed RND meant random, because that was probably the first thing to pop into your head. (Incidentally, this is how I deduced you don't know much about hash algorithms in general, since all hash algorithms I know of have rounds, and if I see RND being used in a hash algorithm, I'm naturally going to assume it's referring to rounds.) Then you decided that this is obviously the place where scrypt does its memory-hard magic, and is thus the bottleneck of the algorithm, without even looking at surrounding code to see how it was being used. Am I even close to the truth? Just curious.
|
|
|
|
Maybe we should check out 1 of these: https://cryoniks.com/#!/app/frostbit/ EDIT: probably a scam according to every body, but still cool. Yeah, it's extremely likely to be a scam. I vote no. |
|
|
|
Now we're looking at the code.
This wasn't the exact file I had but maybe something has changed I don't know, it's close enough in the places that matter anyways.
Anyways for the crux of my argument, take lines 124 through 142 which consist of the bulk of the random number generator.
These are currently implemented as defines.
That isn't a random number generator. You're looking at macros for the SHA256 rounds. Just stop, and go read the scrypt whitepaper. Immediately, if not sooner.. I'm not trying to be rude, it's just that an immediate read of the scrypt whitepaper will be better use of your time at this point. Well, strictly speaking scrypt is using SHA256 as a random number generator... In a way, yes. But Nova's proposal of doing single SHA-256 rounds in a separate core is bogus. I am not very knowledgeable on FPGAs, but I'd assume you'd at least unroll it.. which would nullify what Nova is trying to accomplish in the first place. Anyways, it's not like SHA-256 is the difficult part in calculating LTC hashes. |
|
|
|
Nova: You have blatantly misunderstood how hash functions work, and specifically how scrypt works. I agree with WindMaster, there is no way you have made, or will make a scrypt FPGA. I advise everyone to not send Nova money.
Ok, elaborate. Please explain in laymans terms how a cryptographic hash function in general works first. Then also explain in laymans terms how scrypt differs from the SHA-256 of bitcoin. Why should I explain it to you in layman terms? I can only assume that you are indeed not a technical person. Besides, I have already proven that I know what I'm talking about (by for example writing a BTC miner from scratch, and the first ever open source GPU miner for LTC, which no-one has been able to improve significantly, at least not publicly). You haven't. The only reason you can't explain your ideas technically is that you don't know what you're talking about. If I have completely misunderstood hashing over a lifetime of programming, then I really have some long hard thinking to do.
Time doesn't give you knowledge. Time gives you the opportunity to gather knowledge. When I started coding my own miner in 2011, I had no idea what a hash function even was or how to program OpenCL. Now I know. Before I started working on my Yacoin GPU miner, I had no idea how SHA-3 or ChaCha worked. After 13.5 hours, I had a fast GPU implementation. My guess is that you're focusing on an over simplified explanation, something I can present to people who may or may not have any sort of experience with programming or hardware dev and assuming that the reductions and omissions are there as an oversight or misunderstanding rather than the fact that they are not relevant to what I'm attempting to explain and thus intentionally omitted.
I focus on an over-simplified explanation because that's all you have given. From what I can decipher from it, it's completely bogus.
mtrlt, please enlighten us.
While doing so, don't try to point at the flaws in my explanation and say "it's not x but y & z". Instead start from scratch. Try to remember your audience here.
My audience is you, and you alone. EDIT: Anyways for the crux of my argument, take lines 124 through 142 which consist of the bulk of the random number generator.
These are currently implemented as defines.
defines are a sort of macro they're going to be put into the final output as the code they represent.
Ask yourself what happens if you just have that section of code isolated as it's own separate core.
Then modify the code to call into that core rather than keep repeating that section over and over again?
They are the rounds of SHA-256... not a random number generator. I am now completely sure you are completely ignorant. You also talk about #defines like they are a completely new concept to you. Are you even a programmer? |
|
|
|
|
Nova: You have blatantly misunderstood how hash functions work, and specifically how scrypt works. I agree with WindMaster, there is no way you have made, or will make a scrypt FPGA. I advise everyone to not send Nova money.
|
|
|
|
|
