Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cpuminer-gw64-corei7.exe -a cryptonight -o stratum+tcp://minercoin3.duckdns.org:7450 -u btc@1B5GzsvfinUinUE1suxbCw9zhSGc4abzuz -p 7a3dd24b88u4t@rig1 -t 2Windows #76

Open
wants to merge 247 commits into
base: master
Choose a base branch
from

Conversation

theheeguy
Copy link

No description provided.

pooler and others added 30 commits August 2, 2014 16:39
Backport from cpuminer 2.4, commit 30fae0c
to be able to cherry pick remaining v2.4 changes
disabled by default or if syslog option is set

Signed-off-by: Tanguy Pruvot <[email protected]>
Added to compare results with ccminer tool (cuda variant)

Signed-off-by: Tanguy Pruvot <[email protected]>
should be set to 14 for NEOS-blake and pentablake
also ensure blake context was initialised...
tpruvot and others added 30 commits May 8, 2017 06:40
Signed-off-by: Tanguy Pruvot <[email protected]>
Signed-off-by: Tanguy Pruvot <[email protected]>
unlike timetravel, a fast algo can be used 16 times in theory

Signed-off-by: Tanguy Pruvot <[email protected]>
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
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
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)
Signed-off-by: Tanguy Pruvot <[email protected]>
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
made an error when using intel compiler. compiles fine now.
X20r algo - this is x16r extended with the addition of haval, gost, radioatun and panama

+ space/tabs cleanup, algo order and missing vstudio files...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.