Undefined reference to NeoScrypt when using -DASM

[globaltoken]

Hello @ghostlander,

While compiling I receive an error: "unresolved refference to neoscrypt", which is just caused when using neoscrypt with -DSHA256 -DOPT -DASM -DMINER_4WAY.
If I delete -DASM -DMINER_4WAY, it works.

Why is neoscrypt not defined for -DASM -DMINER_4WAY?
And what to use at neoscrypt_4way *scratchpad arg?
What is scratchpad? any doc available?

Regards,
Pawel

[ghostlander]

If you define -DASM, you have to assemble neoscrypt_asm.S and link towards neoscrypt_asm.o

Scratchpad is a fixed size buffer in memory. Caller allocates and manages it. neoscrypt_4way() doesn't do memory allocation on its own unlike neoscrypt()

[globaltoken]

@ghostlander Thanks for answering.
I linked the asm code, and it did not worked.

Another strange thing: For hashing blocks with nVersion it is not working. Neither scrypt or yescrypt.
While mining blocks with neoscrypt it goes through the whole loop and after 0xffff loop tries it repeats everything with nonce 0. So you have 65536 times the same hash, and after reset you have another different hash. I dont know what I missed here. It just finds block with nonce 0.

[ghostlander]

Well, at least the PXC, ORB and HAL wallets use -DASM, so it's working.

It's up to a miner or daemon to assemble properly a 80-byte block header hashed by NeoScrypt. Nonce can be any between 0 and 0xFFFFFFFF. There is also extra nonce in coin base.

[globaltoken]

@ghostlander Is just 80 byte possible? My blocks require min 81 byte or more because of Auxpow and nAlgo

[ghostlander]

AuxPoW is for merged mining. The hashing is done on the parent chain. Aux chains verify PoW by reconstructing the block header as it could appear on the parent chain.

[globaltoken]

Thank you.
I checked PXC and I saw that you Reverse the Bytes?
Is this necessary for neoscrypt blocks?
Because it seems that just neoscrypt blocks dont use any nonce while daemon generates blocks, and regtest takes very long to generate one block, other algos works fine (excluding yescrypt or scrypt).

Sometimes I tried to generate Blocks in Regtest and it tooked about 30 minutes until I generated a yescrypt, scrypt or neoscrypt block.
This just happens on daemon side mining as it seems.
Any idea?

Regards,
Pawel

[ghostlander]

Byte order of NeoScrypt is different to Scrypt or SHA-256. It's native little endian. It takes a while to generate a valid hash on CPU even at the lowest difficulty such as 1 / 2^12.

[globaltoken]

@ghostlander Thanks for your reply.
If I just use the basic header, it works, with 80 bytes size.
But if I use nAlgo with 81 bytes size it did not hash, every hash is the same.
Do you know where to change this in the Blockchain?

Thanks for your help.

• Pawel

[ghostlander]

It has to be 80 bytes exactly or padded up to. Mix nAlgo into an existing field such as nVersion.

[globaltoken]

Thanks @ghostlander for your help.
I extracted the Basic 80 byte Header in a new Class for POW Validation and it worked, nAlgo and other things are in CBlock now, and GetPoWHash is in another class with just 80 bytes.

Again thanks for your help.
The other point: -DASM still not work, the neoscrypt_asm.o is compiled and linked.
I use the newest neoscrypt Code that you have in this repo.
I checked other neoscrypt Blockchains, they use another neoscrypt version where -DASM is not needed.

Any suggestions here?

Regards,
Pawel

[ghostlander]

That's an older version.

[globaltoken]

@ghostlander Okay where can I find newest Version?

[ghostlander]

The newest is on GitHub as usual.

[globaltoken]

@ghostlander Oh I used Latest commit 9a52159 on 14 Mar 2016