Bitcoin Forum
May 27, 2018, 12:04:25 AM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 109
1  Bitcoin / Mining speculation / Re: GMO miner B2: 7NM mining within reach? on: May 25, 2018, 01:41:56 AM
I just highly doubt any company that is getting it's major funding via ICO token sales and pre-orders can pull this off or be trusted.

On the Intel Foundry services bit - that was new to me. I get a lot of feeds from Intel (mostly about their FPGA's) plus several electronic design feeds - never saw mention of it.
Well, I don't know about the vagaries of Intel's marketing. I'm somewhat more interested in how the rumor mills work on this forum or in somewhat broader cryptocurrency news/rumor mills. Nowadays whatever QuintLeo says, I'm immediately thinking that opposite is true. And you have started to repeat a lot of his proclamations.

Thanks for clarification.
2  Other / Off-topic / Re: Router with many devices on: May 25, 2018, 12:06:56 AM
Sorry, I don't know off-hand how to do that using modern hardware and software. I've done it in the past on the hardware from 2003/2004.

You should seriously consider just buying a better gateway. Either buy Asus DSL-AC68U to replace your BT jobbie, or:

3) reconfigure your BT jobbie to a bridge and and a plain Ethernet gateway like Asus RT-AC68U.

4) hire somebody locally to consult you.
3  Bitcoin / Mining speculation / Re: GMO miner B2: 7NM mining within reach? on: May 23, 2018, 09:36:26 PM
Riiiight... And what Foundry will they be using? None are anywhere near even limited production status @ 7nm. Yes Samsung and GF are doing "tape out' for engineering testing of the layouts but that has little to do with being anywhere close to a viable production status.
Do you know this from some source at the foundries or do you just repeat somebody's baseless speculation? Edit: Wasn't that QuintLeo who convinced you that Intel isn't offering foundry services? End edit.

It would seem that Bitcoin mining IC is near perfect test product for a new process: it is repetitive, it tolerates bad yield, it is free of actual trade secrets or intellectual property in its circuitry. It would be beneficial for both foundry and designers to cooperate and profitably sell the wafers fabricated during process bring-up.

GMO being Japanese could have an additional benefit of really being able to sign binding non-disclosure agreements, unlike the mainland Chinese.

I would love to hear from somebody who has current experience. Mine is really dated, but even a very small fab-less company had been trusted with internal fabrication process metrics provided that they made actual technological and legal effort to protect the trade secrets of the fab.
4  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 23, 2018, 01:52:05 PM
PCIe 4x? does it need the 4x? ie, will running it on a single PCIe lane hurt performance?

i have an onda mining board with 8 full size 16x slots but i believe they run in 1x mode, so any PCIe  ->m2 adapter card would run at 1x.
It costs next to nothing, basically only traces, all the logic is synthesized in the FPGA. Gives the board other uses besides mining.

The reason why old ZTEX boards have much better resale value than the old mining-only boards from ngzhang. His Lancelot & Icarus boards were really crippled by not having any way to get signals to the IO pads of the FPGA. They had only 2 (out of 8 available) signals connected between USB USART chip, greatly reducing available bandwidth and protocols. Similar weak connectivity was between the two FPGA chips on the board. It makes the whole board unusable for anything else, not even toy projects could be reasonably built on them.
5  Other / Off-topic / Re: Router with many devices on: May 23, 2018, 12:15:41 AM
Do noise numbers looks good?
They look fine for the moment. You'll need to write a script to scrape those numbers every hour and see if they are stable. If they are stable you shouldn't have problem staying continuously online for months at a time or even years.

It's really not heavy.
True, it isn't.

I'm guessing you have this: . If I'm not mistaken this is a French SagemCom re-branded for British Telecom with absolute minimum of internal memory. They are generally of shitty quality and with lots of functionality intentionally disabled. Instead you get pretty graphics and pointless animations.

Why BT Smart Scan is useful? The BT Smart Hub is so smart that it improves how it works by itself. By using BT Smart Scan, if it finds a way to work better, it waits for a quiet moment and then reboots itself. Giving you advanced reliability automatically.
See if you can disable that "Smart" shit or just reconfigure it so it never finds "a quiet moment". To me it looks like some sort of temporary workaround for the problem on the provider's side. Other ADSL modems are capable of retraining to the line quality without rebooting, it is observable as just a short hiccup in the flow of the traffic.

The hub supports static IP for web hosting and remote access too. And with the latest IPv6 addresses provided as standard, the BT Business Smart Hub saves your business time and money.
You really need to learn how they provision your IP addresses, both IPv4 and IPv6. There are just to many variants of dual-stack provisioning to give you a reliable advice. Linux on a regular PC is certainly much better router than whatever is inside that box. But you may need to invest in a wireless network card or separate wireless access point (without router) to replace the WiFi functionality of your BT box.

Just don't make a mistake of trying to configure Linux to bridge. It is doable, but it wont help you. Linux on the PC has to be a router and a NAT box (sometimes called masquerading,) the BT box needs to be reconfigured for bridging.

Edit: At least it looks like they didn't disable bridging:

Edit2: For my own reference I've found the closest SagemCom model: F@St 5360
Those things are known to hold the xDSL sessions really well, half-a-year at a time, but are rather weak NAT boxes. WiFi is fast, but low range.

6  Other / Off-topic / Re: Router with many devices on: May 22, 2018, 06:48:04 PM
In the past I've used TP-Link TD-W8970 in similar situation (not miners, but a farm of computers for tests). The manufacturer has marked it end-of-life, I had hard time even finding the information. Other people used ASUS xDSL gateways, e.g. ASUS DSL-AC68U, but I don't know what was changed in the recent firmware.

Your best bet is probably:

1) convert your B.T. device to bridge mode and use a regular PC or Mac to share your connection.

2) buy an end-of-life Cisco IOS router (e.g. Cisco 1801 (ADSL over POTS), Cisco 1802 (ADSL over ISDN), Cisco 1841 + HWIC-1ADSL + HWIC-AP WLAN). They are now super cheap, but they aren't easy to set up, because they use Cisco's crown jewel IOS (Internetworking Operating System). On the flip side, there are plenty of sources to learn and get help. This is rock-solid industrial-grade solution for businesses and it was quite popular before VDSL or optical fiber pushed it out of the market.

Does B.T. charge you rental for your gateway or do you own it outright?

Also, are you sure that it is your router crashing&rebooting and not some line problems (real or artificially created). Where I used to live ISPs would remotely force customer's devices to reboot frequently to force them to upgrade to VDSL or fiber-optics. Do you know the noise margins and bit error rates on your line? I don't know the situation in the UK, but in many other countries ADSL was somewhat mired in political/financial problems on the provider side that made it hard to support for them.

Edit: Also, tell us how BT provides you with an IP address, is it via PPPoE, PPPoA, DHCP, L2TP, MER or something proprietary? This is very important!

Edit2: It was TD-W8970 or TD-W8980, just from the look of it. I recall returning TD-W8968 as it wasn't crashing, but it was just slow under load. Or it was TD-8961ND that I returned, again just from the look of it.

Edit3: I'll just cut&paste this from my gateway for my own reference, although we no longer have any xDSL where I live:
DSL line status
2.1 DSL link status
2.2 DSL synchronization mode
2.3 DSL last synchronization
2.4 DSL synchronization uptime 00 d 00 h 00 m 00 s
Rate and noise margin
2.5 DSL synchronization up Kb/s
2.6 DSL synchronization down Kb/s
2.7 noise margin down dB
Line quality (errors)
2.8 Errored seconds (ES) of downstream (since last synchronisation)
2.9 Severely errored seconds (SES) of downstream (since last synchronisation)
7  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 20, 2018, 02:25:50 AM
Does SDAccel provide an effective software development environment / workflow for developing for the VCU1525
Not really. It is a Visual Basic for FPGAs. Only good enough for quick&dirty or fast prototyping.

8  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 20, 2018, 02:05:24 AM
Or does the card design also come into play?
Bitstream is both chip- and board-dependent.

Chip-dependent quite obviously because FPGA is a complex two-dimensional (or even 3D) device, not an array of bytes, or 72-bit words, etc. according to some JEDEC standard.

Board-dependent for the same reason: which signals go to which pin of the chip isn't standardized either. Some dependencies could be resolved, but it isn't clear that the boards are compatible enough. It was discussed at the beginning of this thread.

Additionally some boards may not have enough power to continuously supply the required current for full performance. You would then be forced to severely under-clock them to avoid tripping the on-board over-current protection.
9  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 18, 2018, 05:48:33 AM
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

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++) {

    // 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 ";
            case 1:
std::cout << "bmw ";
            case 2:
std::cout << "groestl ";
            case 3:
std::cout << "skein ";
            case 4:
std::cout << "jh ";
            case 5:
std::cout << "keccak ";
            case 6:
std::cout << "luffa ";
            case 7:
std::cout << "cubehash ";
            case 8:
std::cout << "shavite ";
            case 9:
std::cout << "simd ";
            case 10:
std::cout << "echo ";
std::cout << std::endl;
        std::next_permutation(permutation, permutation + HASH_FUNC_COUNT);
    return 0;
10  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 18, 2018, 02:44:36 AM
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++) {
    // 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
The code (and comments on the marketing websites) shows that initially there were 11! permutations, but right now that was reduced to 10! .
11  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 18, 2018, 01:57:53 AM
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?

12  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 18, 2018, 01:18:03 AM
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:
13  Bitcoin / Development & Technical Discussion / Re: Resurrecting the Champ: PoW to become Bitmain/Buterin resistant on: May 16, 2018, 09:15:20 PM
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:

which will definitely interest the readers.
14  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 16, 2018, 08:14:42 PM
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?
15  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 16, 2018, 07:57:30 PM
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 Wink

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.
16  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 16, 2018, 07:50:50 PM
Just wondering why you don't develop a new 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).
17  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 16, 2018, 02:41:08 AM
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 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:

The 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 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.
18  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 16, 2018, 12:27:30 AM
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. 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?
19  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 15, 2018, 11:20:16 PM
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. 
20  Alternate cryptocurrencies / Mining (Altcoins) / Re: DIY FPGA Mining rig for any algorithm with fast ROI on: May 15, 2018, 10:44:49 PM
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 or . 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.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 109
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!