update build.sh

integrate

add verus directory files

update Readme

Check for cpu temperature in thermal class

yescrypt variants cputest

yescrypt: add support for yescryptr8, yescryptr16 and yescryptr32.

Those are slight variations of the yescrypt algorithm, used notably by
bitzeny (yescryptr8), yenten (yescryptr16), and wavi (yescryptr32).

Fix compile error with GCC 11

Based on https://github.com/JayDDee/cpuminer-opt/commit/3c5e8921b764e03ef09c57b2207b9960d45123b0

Co-authored-by: Jay D Dee <[email protected]>

ifdef fix for armv7 (PR #50)

increase version to 1.3.7

README markdown quotes (#40)

readme: add zlib1g-dev dep on deb-based Linux (#41)

X16Rv2: pad zeros with 32-bits integers at once

X16Rv2 Algorithm (for RVN and clones)

Force __arm__ define on aarch64

phi2: avoid possible memory overflow

restore build.sh code

fix os x build with asm (#14)

Add geek algo (#35)

properly...

rainforest: add missing entry in cputest

and fix modifier for arm64

rainforest: fix compilation for windows (#37)

rainforest: avoid the slow memcpy() operation to reset the state

It's really expensive to use memcpy() to copy 16 kB of data on some
small processors like ARM Cortex A53 which only have 64-bit data paths
from the L1 cache. This roughly consumes 2k cycles just for the copy.
"Perf top" shows that half of the time is spent in memcpy(), and given
that this exhausts the L1 cache, the rest of the operations must cause
a lot of thrashing.

Since there are few modifications applied to the rambox between two
consecutive calls, better keep a history of recent changes inside
the context itself. This doesn't cost much because the write bus
between the CPU and the L1 cache is 128 bit on A53 so we can afford
a few writes. Also, the typical amount of updates apparently is
between 16 and 32 so it makes sense to put an upper bound on 32 and
remain the memory footprint low..

The performance is roughly multiplied by 5 on A53 just by doing this,
the hash rate reaches about 14.4k/s on NanoPI-Neo4, or almost 10 times
the performance of the original code.

rainforest: avoid closing the hash when it doesn't match

Drop all hashes which will have one of their highest 16 bits set since
they will not match. This saves 4 calls to rf256_one_round() via
rf256_final() and almost doubles the performance.

rainforest: optimize rf_ctx organization for better cache locality

By moving some fields in the structure, we can increase the performance
by an extra 6% on Cortex-A53 at least.

rainforest: optimize rf_rambox()

it is counter productive to avoid writing 50% of the times, it
adds conditional jumps which are mispredicted half of the times.
Better use conditional moves and always write. This increase
performance by 6% on ARMv8.

rainforest: do not emit rf_crc32_table if not needed

it's only needed on platforms who don't have a CRC32 instruction.

build: add a build file for linux on ARM boards

ARM boards don't build when enabling ASM, and some of them benefit from
using -march=native. Let's have a dedicated build file for this. Also it
takes care of cleaning old autoconf/automake remains that can make the
build fail after pulling updates.

vstudio: fix typo

lyra2v3 algo for incoming VTC fork

Signed-off-by: Tanguy Pruvot <[email protected]>

blake2b algo

x20r: secure the algo, dont hash random data

x20r algo with saphir panama and radiogatun (#33)

X20r algo - this is x16r extended with the addition of haval, gost, radioatun and panama

+ space/tabs cleanup, algo order and missing vstudio files...

cpuid: fix for intel compiler (#31)

made an error when using intel compiler. compiles fine now.

rainforest: vstudio fixes

add rainforest algo (#29)

A quick benchmark shows 1795 kH/s on a core i7/4790K at 4000 MHz and 795 kH/s on a Odroid-C2 ARM board at 1752 MHz lacking crypto extensions. Pretty nice for such a small device. (MikeMurdo)

It is very impressive on a Raspberry-Pi 3B+, it gives 668 kH/s, or roughly 1/3 of my skylake 4 GHz for 1/30 of the power usage and 1/18 of the price! Test report here : https://www.linkedin.com/pulse/more-efficient-mining-raspberry-pi-julien-delorme . The skylake also outperforms the GPU! (jdelorme3)

FWIW I just tested on NanoPI-Fire3 at 8*1.6 GHz and it's way faster (1825 kH/s). Apparently the algo makes use of crypto extensions which are enabled on this board but are not on raspi. It's fun to see a $35 device beat a $500 PC (wtarreau)

From https://github.com/bschn2/rainforest

small cleanup, reduce warnings with gcc 7.3

cputest: add missing entries

handle new monero algo, hardcoded

Signed-off-by: Tanguy Pruvot <[email protected]>

handle new cryptolight variant

Signed-off-by: Tanguy Pruvot <[email protected]>

add also sonoa algo

phi2: handle new 144-bytes header, if needed

phi and phi2 algos

phi2 is a new test algo for LUX, may change again if required...

cpu hashrate remains almost identical, 230 vs 250 kH/s
but gpu speed is slower by a bigger factor.

It should be harder to implement on fpgas,
and fixes the original algo power issue due to over-optimised heavy gpu code

Adding lyra and some other memory ops allow the gpu to breath between heavy algos (gost/echo)

allium algo, with proper pool diff ratio 256

cleaned up...

v1.3.4

x12 algo

x16s warning fix + readme + vcxproj

add x16s algo (PigeonCoin) (#26)

fix for ARM support (#24)

Fix construction of BIP34 coinbase.

The expected coinbase for BIP34 blocks is constructed by serialising a
script with the block height as integer.  In the end, this leads to the
code in CScriptNum::serialize in the Bitcoin Core codebase.

Specifically, for positive numbers (as in the case of a block height),
the rule [1] is that another zero byte has to be pushed in case the last
byte had the highest bit set (since that bit is used to indicate the sign).

[1] https://github.com/bitcoin/bitcoin/blob/e117cfe45eee9169409e74a44ef4a866be25bc35/src/script/script.h#L351

handle keccakc variant (refreshed keccak stratum) #21

keccakc is the same as the original keccak,
but the previous was using a different (early) stratum protocol and factor.

This new implementation use a stratum factor of 256 and a sha256d merkle tree

x16r algo: beware, this algo hashrate is not constant

unlike timetravel, a fast algo can be used 16 times in theory

Signed-off-by: Tanguy Pruvot <[email protected]>

autoconf: restore ssl lib checks

arm64: fix wrong ifdef

Update README.md

Fixed compilation on Pi64

handle a new tribus algo

Signed-off-by: Tanguy Pruvot <[email protected]>

add the JHA algo

Signed-off-by: Tanguy Pruvot <[email protected]>

bitcore timetravel-10 algo

Signed-off-by: Tanguy Pruvot <[email protected]>

timetravel: fix for g++ buggy linker

cputest: fix memset typo

Use unsigned long format string for unsigned long value

This makes sure one doesn't see negative numbers and makes job numbers
match the job_ids in the debug output.

README update

release

timetravel: huge optimisation (up to 250x :p)

300kH on an i5 4440 (with bmw512 as first algo)

limit per-core hashrate logs to 5 sec intervals

tunable with --max-log-rate (when not using --quiet)

prepare next version

Timetravel hash function from Machinecoin project

note tpruvot: nice commit, proper...  Waaaaahhhh ^^

small change for cputest

Update docker file

release v1.3

show diff by default, like ccminer

vstudio: add missing project files

prepare xevan algo (default stratum factor 256)

Add missing x17 algo

Update readme

veltor algo

Added needed packages for Ubuntu

The list of packages to install was missing "g++" and "make".

sia stratum (suprnova version)

Signed-off-by: Tanguy Pruvot <[email protected]>

blake2b component algo for later use, not enough for sia

lbry sha/ripemd algo

beware, different data size and different stratum protocol (notify)

add x11evo algo

Signed-off-by: Tanguy Pruvot <[email protected]>

small changes in --version output

+ add sph haval which was half there in the vstudio project

windows: get the proper cpu name like linux

tested ok on mingw64 and vstudio x64 + x86

fix a few vstudio warnings

stats: add cores count to the cpu vid

update sample config, default to decred on yiimp

stratum: pool benchmark + new methods

+ model/stepping cpu id to get the same vid on linux and windows

blake2s midstate, +10%

Happy this algo was working well without even a test ^^

Signed-off-by: Tanguy Pruvot <[email protected]>

decred simplified stratum (getwork over stratum)

Signed-off-by: Tanguy Pruvot <[email protected]>

decred: randomize all scans

decred: longpoll/getwork modes

tested ok on suprnova and multicoin

Signed-off-by: Tanguy Pruvot <[email protected]>

blake: some cleanup

Some other hwmon paths may be present

vanilla algo (Blake256 8 rounds - double sha256)

1.2 release

stratum: show real target diff for all algos

some algos use a diff factor, so show the real target value with --show-diff

[2016-01-06 09:35:44] Stratum difficulty set to 1 (0.00002)
[2016-01-06 09:35:44] m7m block 638158, diff 1.255

diff: show share diff and solved blocs + api

(require the --show-diff parameter)

diff: prepare all algos for diff report (part 2)

we need to pass the work structure to store the solved diff

Signed-off-by: Tanguy Pruvot <[email protected]>

linux: build with native arch if the cpu supports avx

workaround to handle the pentium G detected as the Core i5/7 but not compatible with avx

update readme, list debian/ubuntu required packages

tested ok on Ubuntu 10.04 to 15.10, and debian 7