I had to watch a really boring "entertainment" program and used that time to edit the above file into a working C++ program. Echo was never used. Due to the peculiar permutation order Blake and Bmw are always fixed at position 0 and 1 respectively, only the remaining 8 positions change. So using the terminology from the whitefire990's post above timetravel10 requires only 9 reconfigurable blocks assuming that only Groestl requires a double block. #include <algorithm> // std::next_permutation
#include <iostream>
#include <inttypes.h>
#define HASH_FUNC_BASE_TIMESTAMP 1492973331 // BitCore: Genesis Timestamp
#define HASH_FUNC_COUNT 10 // BitCore: HASH_FUNC_COUNT of 11
#define HASH_FUNC_COUNT_PERMUTATIONS 40320 // BitCore: HASH_FUNC_COUNT!
int main()
{
// We want to permute algorithms. To get started we
// initialize an array with a sorted sequence of unique
// integers where every integer represents its own algorithm.
uint32_t permutation[HASH_FUNC_COUNT];
for (uint32_t i=0; i < HASH_FUNC_COUNT; i++) {
permutation[i]=i;
}
// Compute the next permuation
uint32_t steps = HASH_FUNC_COUNT_PERMUTATIONS;
for (uint32_t i=0; i < steps; i++) {
for (uint32_t i=0; i < HASH_FUNC_COUNT; i++) {
switch(permutation[i]) {
case 0:
std::cout << "blake ";
break;
case 1:
std::cout << "bmw ";
break;
case 2:
std::cout << "groestl ";
break;
case 3:
std::cout << "skein ";
break;
case 4:
std::cout << "jh ";
break;
case 5:
std::cout << "keccak ";
break;
case 6:
std::cout << "luffa ";
break;
case 7:
std::cout << "cubehash ";
break;
case 8:
std::cout << "shavite ";
break;
case 9:
std::cout << "simd ";
break;
case 10:
std::cout << "echo ";
break;
}
}
std::cout << std::endl;
std::next_permutation(permutation, permutation + HASH_FUNC_COUNT);
}
return 0;
}
|
|
|
|
0->10, echo is 10 and the loop breaks on 11.
We must be looking at a different code then. #define HASH_FUNC_COUNT 10 // BitCore: HASH_FUNC_COUNT of 11
uint32_t permutation[HASH_FUNC_COUNT];
for (uint32_t i=0; i < HASH_FUNC_COUNT; i++) {
permutation[i]=i;
}
// Compute the next permuation
...
for (uint32_t i=0; i < HASH_FUNC_COUNT; i++) {
switch(permutation[i]) {
// cases 0 to 9 here
case 10:
// Echo is here, but isn't ever executed
break;
}
The code (and comments on the marketing websites) shows that initially there were 11! permutations, but right now that was reduced to 10! . |
|
|
|
Timetravel10 fits in a single VU13P. You partition the FPGA into 16 blocks, and store about 14 partial bitstreams for each block. Then you do a dynamic partial reconfiguration from DDR4 to build the pipeline at the start of each block based on the current algorithm sequence. Yielding one hash per clock (i.e. 500MH/s @ 500MHz). You need 16 blocks because some functions like Groestl and Echo require 2 blocks. The FPGA can reconfigure itself in 0.25 seconds. The problem with Timetravel and X16R/X16S is the long time it takes to load the DDR4 bitstream table via USB. And you lose it if there is a power outage and must reprogram the DDR4 on each FPGA. This where utilizing the PCI bus would be an advantage.
My naïve reading of the above-linked code is that Echo is coded, but never used. Am I wrong? |
|
|
|
Ran through timetravel10 today, looks like with 8 fpgas (one dedicated to each algo) you might be able to get up into 1-10Gh/s. Bitcore definitely needs to do something. A small fpga cluster could 51% them pretty easily.
You've made some interesting optimizations. My naïve reading is: a) they have 11 algorithms coded b) only first 10 are used c) the whole hash is a nesting of always 10 sub-hashes d) chosen without repetition e) which gives 10! possibilities f) the choice of permutation is keyed from the block height g) not sequentially, but skipping up to 8! permutations So my naïve implementation (one card dedicated to each sub-hash) would require 10 FPGA cards. What is your secret ingredient? Edit: Link to the source code: https://github.com/LIMXTEC/BitCore/blob/master/src/crypto/hashblock.h |
|
|
|
So, in effect, we should take the opposite approach and lower the bar, not raise it. If ASICs are inevitable, they should be as widely available as possible.
That is the general idea. Some already been arguing that the common CPUs and GPUs are ASIC, where the Specific Application that they are optimized for is a well known von Neumann architecture or 3D visualization pipeline. So the ball is on the software engineer's side and they need to find how to fully utilize the strength of the devices that everyone and their dog already have. Make it easier for a greater number of manufacturers to create ASICs, not harder.
I would reword it to the effect that we don't really need many manufacturers, we need many alternative uses and prospective users for the hardware used for mining. The software engineers designing PoW algorithms are mostly too focused on how to spoil other's game instead on how to improve their own game. Anyway, Bitmain responded to the above article: https://blog.bitmain.com/en/bitmain-sia-state-cryptocurrency-mining/which will definitely interest the readers. |
|
|
|
lol yea multiplication and division are the same thing...come on guys
Well, Chuck Norris is known to successfully divide by zero. Maybe he's posting here under an alias? Or maybe he had spread his knowledge of previously illegal operations to the "energy industry" or the "GPU hoarders"? Who knows? |
|
|
|
Really not meaning to offend anyone, this has been a very interesting and entertaining thread, even inspiring all around in a way that leads to substantially more decentralization. However, as an energy industry professional I must say that a kw/h and a kWh is substantially exactly the same thing. Not sure what you guys are onto here... a kW is a unit of energy, it is a 1,000 Watts. Watts are convertible to Joules or Therms or any other unit of energy. And a kW/h is the number of kiloWatts consumed in an hour, as is a kWh, the number of kiloWatts consumed in an hour. a kW is a measurement of power, and a kWh is a volumetric measurement of energy. you can use 100kW in one hour is 100kWh or you can use 50kW for 30 minutes and 150kW for 30 minutes and it will also be 100kWh.
I don't think anyone here would get offended. I'm even grateful for your post as it helped to prove my point. I'm also grateful for the correction below that is the other half of the proof of my point. You can convert Joule to Wh, it is indeed a measurement of amount of energy. Watt's cannot be converted to Joules directly as much as velocity cannot directly be converted to distance without the input of other parameters to build an equation. And a kW/h is the number of kiloWatts consumed in an hour, as is a kWh A kWh is not the number of kiloWatts consumed in an hour, same difference as you can't say that 'distance is the is the number of meters travelled in an hour'. In the analogy with distance, velocity & time; kW/h would be acceleration (how much the energy flow changes per unit of time), kW would be velocity (amount of energy flow), kWh would be distance (how much energy has flown) You can not 'use' xx kW in one hour, you can use xx kWh in one hour though. kW/h is simply the wrong unit to use. But as an energy industry professional you of course know better  This is not really on-topic though but it is simply confusing to people who have little knowledge about this. It might be that most understand that it's an error but using the wrong units on purpose because everyone understands is not productive. I will not go deeper into this as we might as well be discussing whether the earth is flat or not. |
|
|
|
Just wondering why you don't develop a new algo..you seem to have a handle on what is needed..its people like you that are needed to move this forward..
I'll take this as a straight question, not a rhetorical question. The answer is three fold: 1) due to other commitments I have not enough time to get seriously involved in such a project. At the same time I don't want to get tangled in some abandonware crapcoin, even if just part-time. 2) it is my observation that the publicly stated goals of majority cryptocoin projects are very different from the personal goals of the authors. It is a conflict of interest minefield. 3) the whole market of floating-point developers and users is deeply split in their understanding what does it mean to have "reproducible results": 3a) some want that their simulations differ very little or not at all. I'm more in this group and that is the approach to be included in cryptocurrency. 3b) others focus on the reproducibility of the end results, e.g. the launched missiles hit the evading targets or the cell phones keep the connection when driving in or out of the tunnel. Those people would laugh at trying to incorporate floating-point calculations in the PoW code. None of the above two camps have monopoly on being good or bad, right or wrong. If you (or some other reader) is interested about the above split it is worthwhile to study how the Java language introduced the keyword strictfp. Intel is definitely serving camp 3a). Nvidia is started in 3b). AMD started in 3a) but shifted into center after acquisition of ATI from 3b). FPGA vendors try to serve both camps, but have way more success stories in 3b). |
|
|
|
I’ll see if I can dig up recent ones. A lot of people pull up the old CUDA vs FPGA academic papers that are focused on very old architectures.
Thanks in advance. I'll put the blame squarely on the vendor's lap. Intel which now acquired Altera still lists "An Independent Analysis of Altera’s FPGA Floating-point DSP Design Flow" from 2011 as the only source mentioning "accuracy". I've found several other, newer papers; but they all repeat the old bullshit methodology: only using single-precision and only estimating the errors. At most they'll show fused-multiply-add like if double precision or https://en.wikipedia.org/wiki/Kahan_summation_algorithm never existed, or didn't apply. As to GPU floating point performance, you don’t need a benchmark. The figures are right in the ISA documents. Single precision TFLOPs are usually given in terms of FMA unit operations though, which is a bit misleading.
The FPGAs are a bit harder to get TFLOPs numbers for given the flexibility, it since most of the performance actually comes from the DSP blocks you can calculate those. If you’ve never read them Xilinx gives extremely detailed performance metrics for every chip for most IP blocks, as well as frequency numbers for the hard blocks in the AC/DC switching characteristic docs. Agner Fog publishes a very detailed set of specifications for the performance of those units on most every CPU/APU available as well.
The funny thing is that the closest to honest comparison of Xilinx's FP I've found on the Altera's site: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/wp/wp-01222-understanding-peak-floating-point-performance-claims.pdfThe main resource CPUs and GPUs have is instruction flexibility. Until a PoW hash truly requires most of the full instruction to be supported to implement it will be hard to keep out ASIC/FPGA.
I think this claim is true, but somewhat pessimistic. I think it would be fairly easy once wider range of cryptocurrency programmers start to appreciate floating point and https://en.wikipedia.org/wiki/Chaos_theory as an useful building blocks for the proof-of-work algorithms. I've only skimmed the currently available literature on the subject, but it is next to trivial to demolish all the current claims of FPGA superiority that I was able to find today: 1) use double precision 2) use division or reciprocal (either accurate or approximate) 3) use square-root or reciprocal square-root (either accurate or approximate) and I haven't even gotten into transcendental functions (on CPUs) or using later, pixel-oriented hardware in the shaders (on GPUs). You did, however, motivated me to reconsider Altera/Quartus for certain future projects. They are now shipping limited, but fully hardware implemented single-precision floating-point in their DSP blocks and their toolchain had improved in terms of supported OS-es/device-drivers. |
|
|
|
Are you so sure about that? The floating point performance of modern FPGAs per Watt is much better than GPUs. Even in the 28nm Virtex 7 days TFLOPs were roughly on-par, it’s neck and neck now and the next gen FPGAs are leading ahead on the AI/ half precision’s stuff. That Floating point performance gap was true several years ago but has rapidly closed since.
The types of instructions you’re listing also take many many clock cycles on GPUs and CPUs, and can almost always be implemented faster in FPGAs
I've never seen a honest comparison involving actual verification of accuracy, not even bit-accuracy. I've seen some very skewed benchmarks made with very ugly code that conflated/convolved FPU performance with memory bandwidth/latency limitations. https://en.wikipedia.org/wiki/False_sharing seems to be in fashion nowadays for obfuscation purposes. Frequently the comparison don't even use the real floating-point but some extended-precision fixed-point in the inner loops because the original CPU/GPU implementation was just a generic library code versus carefully-optimized special-purpose code for the FPGA. It does make business sense, especially with regards to time-to-market; but I wouldn't call that science, even if published in the ostensibly scientific journal. Do you recall where you've seen those comparisons? |
|
|
|
FPGA can change to do the new algo in hours.
Until some day that one of those altcoin programmers discovers that his CPU has some interesting instructions like: FILD, FIST, FDIV, FSINCOS, etc. Then the hours become months, and even after that the FPGA will have hard time beating even a cheap Atom CPU. I tried to research exactly emulating 80x87 couple of years ago. There was exactly nothing available open source, with exception of an exact re-implementation of FDIV in Mathematica. The available closed-source code was not only expensive but had mandatory royalties and defense-grade NDA requirements. |
|
|
|
I strongly stand by the statement that there is no algorithm that is somehow going to be magically possible on GPUs but not possible on any FPGA hardware configuration. There is simply no resource to exploit unique to GPUs.
Nothing magic is required, just design an algorithm that actually plays to the real strengths of the GPUs. In particular all currently popular hashing algorithms completely ignore the super fast floating point units in the GPUs and CPUs. Ultimately, some future generations of FPGAs will start including FPU blocks, very much like they started including DSP blocks years ago. But currently the FPU performance gap is quite wide. Picking winners in the ASIC game is relatively easy if one isn't afraid of occasionally changing the source code. When properly designed, it even doesn't need to be hard fork, just the version number of the PoW function needs to be explicitly recorded. At the moment I don't have time to write a longer discussion, so for now I'll repost what I wrote in another thread. We'll see which of those new threads will get most intelligent discussion. a non-trivial portion of the more complex parts of the instrucion set
Yeah, that is the key. As a miner, this frightens me because when this era of "flexible ASICs" arrive, GPU miners will definitely be obsolete. Add this to the threat of Ethereum going POS, it seems like the odds are stacked against us regular home-based miners. This might be a signal that now is a good time to liquidate mining rig assets and just directly invest in coins.
The thing is that it is relatively easy to write hash function that are very ASIC-proof or FPGA-proof. Bytom folks are a good example. Their goal was not to be general-ASIC-proof but to make sure that the ASIC that is fast at implementing their hash in their ASIC. So they wrote a hash function that uses lots of floating point calculations exactly in the way that their AI-oriented ASIC does. The hard part of understanding Bytom's "Tensority" algorithm is finding exact information about the actual ASIC chips that are efficient doing those calculations. But the general idea is very simple: if you don't want your XYZ devices to become, play to their strengths in designing the hash function. For XYZ==GPU start with GPUs strengths. I haven't studied the recent GPU universal shader architecture, but the main idea was to optimize particular floating point computation used in 3D graphics using homogeneous coordinates, like AX=Y, where A is 4*4 matrix and X is 4*1 vector <x,y,z,w> where w==1. So include lots of those in your hash function. In particular GPUs are especially fast when using FP16, a half-precision floating point. For XYZ==CPU made by Intel/AMD using x86 architecture, again start with their strengths. They have unique FPU unit with unique 10-byte floating point format and unique 8-byte BCD decimal integer format. Additionally they have dedicated hardware to compute various transcendental functions. So use a lot of those doing chaotic irreducible calculations like https://en.wikipedia.org/wiki/Logistic_map or https://en.wikipedia.org/wiki/Lorenz_system . Of course one could write an emulation of those formats using quad-precision floating point (pairs of double-precision floats), but it will take many months. During those months you have additional time to research more strengths of your GPUs or CPUs. Use them in a hard-fork to assure that the preferred vendor of your mining hardware continues to be Intel/AMD/Nvidia. |
|
|
|
Would it be worth pursuing the obverse strategy also, i.e. try to target the weaknesses of ASICs when designing the hash algorithm?
That approach in reality becomes: play to the weaknesses of the education of the cryptocoin developers. The sad reality is that nowadays most of the computer science graduates have no idea about logic design and architecture beyond the ubiquitous https://en.wikipedia.org/wiki/Von_Neumann_architecture from 1945. Moreover, after learning what the typical fixed-program ASIC does they are still mentally stuck in the next decade: https://en.wikipedia.org/wiki/Mealy_machine (1955) https://en.wikipedia.org/wiki/Moore_machine (1956). You really should read the other referenced threads, e.g. "ASICs mining game" https://bitcointalk.org/index.php?topic=3788591.0and the referenced external post https://blog.sia.tech/the-state-of-cryptocurrency-mining-538004a37f9b : The vast majority of ASIC-resistant algorithms were designed by software engineers making assumptions about the limitations of custom hardware. These assumptions tend to be incorrect.
An idea I've been fond of in the past is using a series of hash algos drawn randomly from a set, with the series also changing size randomly within a range, and a random interval between changes in the composition and size of the series (credit to Meni Rosenfeld for that idea).
If Meni really proposed this that this is just a proof that he would have flunked the basic logic design course using an FPGA as a teaching aid. It is now being actively demolished in the other thread https://bitcointalk.org/index.php?topic=3459858.0 , profitable even when paying outrageous charges for the Amazon's EC2 F1 instances ( $1.65 $0.495 per Hour) . That idea is now implemented by altcoins using x16r, x16s and similar algorithms. But could there be other techniques to use the same strategy? Could a hash be written such that the potential for physical flaws in an attempted ASIC chip die would undermine the manufacturing yield, e.g. force chip designers to make individual chips that would need to be >30 cm2?
You were educated in humanities, didn't you? Try finding the essay from Bruce Schneier where he explains why in order to design a strong cipher one does need experience in cipher-breaking. It is not enough to simply pile-on the complexity. In my experience his argumentation was convincing to the people with education in humanities. Edit: corrected the Amazon's pricing point for F1. |
|
|
|
Before you read this I really urge you to revert the title of this thread to the original. It was much better at eye-catching, even if somewhat poetic in its approach to mathematics. But finding the right way to exaggerate is helping in creating great art (and science.) Right maybe orthonormal basis in general vector space should be more precise here for an analogy. As you noted my point is how to find out such a basis or analogous merit senders in the entire merit network space. It would be well-defined problem if it is e.g. some general vector space in mathematics as we could basically follow the Gram-Schmidt orthogonalization process for given liner independent vectors to construct a good basis. This process is not clear for the merit network space, but at least the visualization provides an intuitive approach.
To orthonormalize you'll have to both normalize and orthogonalize. The open question is how to normalize merit transfers? This "normalized merit" would have to meet the conditions of being a https://en.wikipedia.org/wiki/Lebesgue_measure , preferably of the order 2, which is an equivalent of the most common https://en.wikipedia.org/wiki/Euclidean_distance measure, also known as https://en.wikipedia.org/wiki/Root_mean_square in statistics. In the SVD article there's a mention of open source algorithm used by Netflix to find similarities between films and user's tastes with the help of star ratings. I never had a Netflix account, but I believe the users assign films star ratings in the range 1-5 or 1-10. So they get normalization almost for free. I am not sure how the least square method works for resolving the issue, as it is not clear to me what we should minimize or fit to find out independent merit senders, but you seem to have some idea?
I was trying to make a funny reference to https://en.wikipedia.org/wiki/Ordinary_least_squares , a form of https://en.wikipedia.org/wiki/Regression_analysis . Perhaps you were trying to intuit some form of https://en.wikipedia.org/wiki/Correlation_clustering ? Please do continue your research. |
|
|
|
No one seemed to want to believe me and for whatever reason very few every considered consulting me despite my obvious position in the mining world.
Changing the proof of work algorithm will NOT, as the article said, make any difference at all; a new asic arms race will simply replace the old one.
Personally, I think you are just too pessimistic about the whole issue, possibly because you were ignored for so long despite your openness. Picking winners in the ASIC game is relatively easy if one isn't afraid of occasionally changing the source code. When properly designed, it even doesn't need to be hard fork, just the version number of the PoW function needs to be explicitly recorded. At the moment I don't have time to write a longer discussion, so for now I'll repost what I wrote in another thread. We'll see which of those new threads will get most intelligent discussion. a non-trivial portion of the more complex parts of the instrucion set
Yeah, that is the key. As a miner, this frightens me because when this era of "flexible ASICs" arrive, GPU miners will definitely be obsolete. Add this to the threat of Ethereum going POS, it seems like the odds are stacked against us regular home-based miners. This might be a signal that now is a good time to liquidate mining rig assets and just directly invest in coins.
The thing is that it is relatively easy to write hash function that are very ASIC-proof or FPGA-proof. Bytom folks are a good example. Their goal was not to be general-ASIC-proof but to make sure that the ASIC that is fast at implementing their hash it their ASIC. So they wrote a hash function that uses lots of floating point calculations exactly in the way that their AI-oriented ASIC does. The hard part of understanding Bytom's "Tensority" algorithm is finding exact information about the actual ASIC chips that are efficient doing those calculations. But the general idea is very simple: if you don't want your XYZ devices to become, play to their strengths in designing the hash function. For XYZ==GPU start with GPUs strengths. I haven't studied the recent GPU universal shader architecture, but the main idea was to optimize particular floating point computation used in 3D graphics using homogeneous coordinates, like AX=Y, where A is 4*4 matrix and X is 4*1 vector <x,y,z,w> where w==1. So include lots of those in your hash function. In particular GPUs are especially fast when using FP16, a half-precision floating point. For XYZ==CPU made by Intel/AMD using x86 architecture, again start with their strengths. They have unique FPU unit with unique 10-byte floating point format and unique 8-byte BCD decimal integer format. Additionally they have dedicated hardware to compute various transcendental functions. So use a lot of those doing chaotic irreducible calculations like https://en.wikipedia.org/wiki/Logistic_map or https://en.wikipedia.org/wiki/Lorenz_system . Of course one could write an emulation of those formats using quad-precision floating point (pairs of double-precision floats), but it will take many months. During those months you have additional time to research more strengths of your GPUs or CPUs. Use them in a hard-fork to assure that the preferred vendor of your mining hardware continues to be Intel/AMD/Nvidia. |
|
|
|
a non-trivial portion of the more complex parts of the instrucion set
Yeah, that is the key. At the moment I don't have time to write a longer discussion, so for now I'll repost what I wrote in another thread. We'll see which of those new threads will get most intelligent discussion. As a miner, this frightens me because when this era of "flexible ASICs" arrive, GPU miners will definitely be obsolete. Add this to the threat of Ethereum going POS, it seems like the odds are stacked against us regular home-based miners. This might be a signal that now is a good time to liquidate mining rig assets and just directly invest in coins.
The thing is that it is relatively easy to write hash function that are very ASIC-proof or FPGA-proof. Bytom folks are a good example. Their goal was not to be general-ASIC-proof but to make sure that the ASIC that is fast at implementing their hash it their ASIC. So they wrote a hash function that uses lots of floating point calculations exactly in the way that their AI-oriented ASIC does. The hard part of understanding Bytom's "Tensority" algorithm is finding exact information about the actual ASIC chips that are efficient doing those calculations. But the general idea is very simple: if you don't want your XYZ devices to become, play to their strengths in designing the hash function. For XYZ==GPU start with GPUs strengths. I haven't studied the recent GPU universal shader architecture, but the main idea was to optimize particular floating point computation used in 3D graphics using homogeneous coordinates, like AX=Y, where A is 4*4 matrix and X is 4*1 vector <x,y,z,w> where w==1. So include lots of those in your hash function. In particular GPUs are especially fast when using FP16, a half-precision floating point. For XYZ==CPU made by Intel/AMD using x86 architecture, again start with their strengths. They have unique FPU unit with unique 10-byte floating point format and unique 8-byte BCD decimal integer format. Additionally they have dedicated hardware to compute various transcendental functions. So use a lot of those doing chaotic irreducible calculations like https://en.wikipedia.org/wiki/Logistic_map or https://en.wikipedia.org/wiki/Lorenz_system . Of course one could write an emulation of those formats using quad-precision floating point (pairs of double-precision floats), but it will take many months. During those months you have additional time to research more strengths of your GPUs or CPUs. Use them in a hard-fork to assure that the preferred vendor of your mining hardware continues to be Intel/AMD/Nvidia. |
|
|
|
As a miner, this frightens me because when this era of "flexible ASICs" arrive, GPU miners will definitely be obsolete. Add this to the threat of Ethereum going POS, it seems like the odds are stacked against us regular home-based miners. This might be a signal that now is a good time to liquidate mining rig assets and just directly invest in coins.
The thing is that it is relatively easy to write hash function that are very ASIC-proof or FPGA-proof. Bytom folks are a good example. Their goal was not to be general-ASIC-proof but to make sure that the ASIC that is fast at implementing their hash it their ASIC. So they wrote a hash function that uses lots of floating point calculations exactly in the way that their AI-oriented ASIC does. The hard part of understanding Bytom's "Tensority" algorithm is finding exact information about the actual ASIC chips that are efficient doing those calculations. But the general idea is very simple: if you don't want your XYZ devices to become, play to their strengths in designing the hash function. For XYZ==GPU start with GPUs strengths. I haven't studied the recent GPU universal shader architecture, but the main idea was to optimize particular floating point computation used in 3D graphics using homogeneous coordinates, like AX=Y, where A is 4*4 matrix and X is 4*1 vector <x,y,z,w> where w==1. So include lots of those in your hash function. In particular GPUs are especially fast when using FP16, a half-precision floating point. For XYZ==CPU made by Intel/AMD using x86 architecture, again start with their strengths. They have unique FPU unit with unique 10-byte floating point format and unique 8-byte BCD decimal integer format. Additionally they have dedicated hardware to compute various transcendental functions. So use a lot of those doing chaotic irreducible calculations like https://en.wikipedia.org/wiki/Logistic_map or https://en.wikipedia.org/wiki/Lorenz_system . Of course one could write an emulation of those formats using quad-precision floating point (pairs of double-precision floats), but it will take many months. During those months you have additional time to research more strengths of your GPUs or CPUs. Use them in a hard-fork to assure that the preferred vendor of your mining hardware continues to be Intel/AMD/Nvidia. |
|
|
|
I'm sorry, due to other commitments I'm unable to finish the reply below. Sorry for the incompleteness. I may be able to follow up in the coming weeks. I think you precisely missed my statement about being pedantic. I knew what you meant and was saying that everyone reading the marketing speak knew what they meant. They used the wrong unit but everyone still understood, and nothing of value was lost other than it clearly irritates you.
Certainly, not "everyone reading". I'm not as pessimistic as nsummy to say 95%, but somewhere between 25% and 50% of readers will get confused. Whether that's intentional or accidental is a different story. The investment in technology mail fail not only because it was a scam or something not physically realizable. It may well be doable relatively easy, but fail because the management developed substance abuse problem or the people with real required knowledge either departed or were never on the team. There are many things that one can surmise from simple observation of progressing dyslexia or repetitive mistakes. Agree that everyone here that doesn’t do this type of work themselves should proceed cautiously and be responsible for their own destiny. I’m amazed when I see people immediately pop up and want to order 100 of something with zero understanding or evidence. Fear of missing out or hoping to be the first in and get rich before the jig is up?
Firstly, some users here have way more play money than the others. Secondly, it really cuts both ways. Some users here may have supremely effective ways of debt collection, e.g. charging one finger per week for overdue delivery. |
|
|
|
What’s wrong with 900W to 1kw per hour exactly? Other than being pedantic I think that saying consumption is 0.9-1 KWH is understood.
Your teacher should have explained to you what is the difference between kW/h and kWh. But on a marketing site dedicated for miners, that to quote earlier post in this thread: The fact is that 95% of miners out there have a very rudimentary understanding of computers, algorithms, and programming.
I would add that they also have rudimentary understanding of literacy and numeracy. This is what makes reading mining forums such a great fun. Are people really that stupid or are they just pretending? How to they are going to bamboozle people with bullshit calculations involving non-existing units of measure like kelvin-watt-henry? On this occasion I'd like to post a good advice that reeses had given about a year six years ago: I'd recommend reading "The Big Con" for some of the history, and watching Confidence and The Sting as examples of the "classic" con games.
I read that book, and although it was written between the world wars, it is very pertaining to Bitcoin all cryptocurrecies. Here's a short excerpt: - Locating and investigating a well-to-do victim. (Putting the mark up.)
- Gaining the victim’s confidence. (Playing the con for him.)
- Steering him to meet the insideman. (Roping the mark.)
- Permitting the insideman to show him how he can make a large amount of money dishonestly. (Telling him the tale.)
- Allowing the victim to make a substantial profit. (Giving him the convincer.)
- Determining exactly how much he will invest. (Giving him the breakdown.)
- Sending him home for his amount of money. (Putting him on the send.)
- Playing him against a big store and fleecing him. (Taking off the touch.)
- Getting him out of the way as quietly as possible. (Blowing him off.)
- Forestalling action by the law. (Putting in the fix.)
|
|
|
|
|
Show Posts
