The description of the CryptoNight hash algorithm and the steps it performs can be found in the code as well as in a written file by the CryptoNote team, which can be found here. Lastly, in his blog, professor David Anderson also briefly describes the CryptoNight algorithm with an accompanying graph that illustrates it. From the blog:
This was a ...
Yes. Essentially, you can split up the private spend key according to a (k,n)-secret sharing scheme. Then any k participants can collect the keys together to recreate this private spend key and then sign transactions.
Now the question is, how is the key generated, how are the shares generated, and who/what brings the shares together.
One simple way is this ...
It will get wrapped around because it's later passed through sc_reduce32 function which performs mod l operation on the input.
See below example using silent Matt's big int library which is loaded with llcoins. Easiest to just open the developer tab and type stuff into JS console.
To calculate 2^252 + 27742317777372353535851937790883648493:
l = JSBigInt(2)...
The paper is incorrect; it's actually mod l, not q. l is the curve order of ed25519. The primary reason AFAIK is that the code doesn't work correctly with scalars above a certain multiple of l. The random_scalar() function outputs an integer
Originally Monero used non-deterministic wallets. Deterministic (and mnemonics) are a convenience feature.
Take a look at the --non-deterministic command-line flag, which will generate a non-deterministic wallet, and also --restore-from-keys flag, which will restore a non-deterministic wallet (by prompting for the view and spend keys).
No functionality is ...
G is defined in the definition of the signature scheme, Edwards-curve Digital Signature Algorithm (EdDSA)in the case of Cryptonote and Monero.
As explained in this answer in crypo.SE :
the base point is chosen pretty arbitrarily. As described in the Ed25519 paper, it arises from the choice u=9 in the original Curve25519 paper
The details of this choice ...
This was answered by core-team member smooth on Reddit:
First one has a trusted setup. I don't know what issues there might be with the other one. I remember the MRL guys look at some sublinear ring sig at one point a year or two ago and it had high minimum size, such that it would only be useful for very large mix sets. That could still be an improvement ...
The Monero blockchain is full of test cases: for every block, you can assemble the hashing blob for that block, hash it with your new implementation, and check the resulting hash is below the target for that block. This will be done automatically if you replace monerod's Cryptonight implementation with your own, and try to sync the chain from scratch.
Quoting SChernykh (one of the CryptonightR authors):
CryptonightR is a modification to Cryptonight whereas RandomX is done completely from scratch. The main purpose of CryptonightR is to be the next PoW for Monero until RandomX is ready.
Which leads to why RandomX needs more auditing/testing. RandomX is a completely new PoW algorithm, not just a modified ...
A hex string is created using a hash_hmac(serverSeed, clientSeed_nonce) function, where "clientSeed_nonce" is literally the client seed, the underscore character, and the nonce, all concatenated together.
Then five characters are taken from the hex string to create a roll number.
If the roll number is over 999 999 the process is repeated with the next ...
An AES round uses the three functions (SubBytes, ShiftRows and MixColumns).
The Wikipedia article on AES has a high-level description of the algorithm and links to the AES standard, reference source code, etc.
The Hp and Hs hash functions of the Cryptonote paper are called hash_to_ec and hash_to_scalar in the Monero code base, and they are based on the Keccak1600 hash function (called fast_hash in the code), not Cryptonight (called slow-hash in the code).
A one time address for Bob is generated by taking a random r, multiply by Bob's public spend key, hash the result and multiply it by the curve base point, adding (in ECC terms) Bob's public view key.
The private key can be derived from this public key without further information.
See 4.3 in https://cryptonote.org/whitepaper.pdf for the details.
The scratchpad is filled with pseudo-random data based on the state (using rounds of the AES block cipher).
Check https://cryptonote.org/cns/cns008.txt for a detailed description of the algorithm (without the modifications introduced in version 7 of the protocol).
Sure there is.
Do a npm search cryptonight-hashing and take a pick :)
NAME | DESCRIPTION | AUTHOR | DATE | VERSION | KEYWORD
cryptonight-hashing | node-cryptonight-ha… | =moneroocean | 2018-10-04 | 3.0.5 | crypton
node-cryptonight-lite | node bindings for… | =excitableaard… | 2018-02-01 | 1.0....
You can find the difficulty of a submitted hash (which is just a big endian hex encoded string) by dividing the base difficulty (2^256-1) by your hash.
As such, nodejs-pool (the most common pool software), checks your submitted hash difficulty as follows:
let hashArray = hash.toByteArray().reverse();
let hashNum = bignum.fromBuffer(new Buffer(hashArray));
If all the computers have a good network connectivity, the probability of successfully mining a block is proportional to your total hash rate.
Mining with 10 CPUs doing 200 h/s each and mining with 1 CPU doing 2000 h/s will give the same probability of finding a block.
Can someone explain the algorithm to compute Monero transaction fee?
The computation of the current dynamic fee algorithm is explained, in detail, here: https://web.getmonero.org/2017/12/11/A-note-on-fees.html.
I have seen somewhere it is based transaction size (or something called "weight"?), and some other vague explanation.
"weight" is just another ...
Miners and nodes are updated ahead of time with new software. This software is hard coded to know in advance the block height at which the mining algorithm is agreed to change over. Block height is simply a count of the number of blocks since the very first block ever mined (also known as the genesis block). When the block at the agreed upon changeover block ...
The order for both ed25519 and curve25519 curves can be found from libgcrypt-1.8.5/cipher/ecc-curves.c in hex is 1000000000000000000000000000000014DEF9DEA2F79CD65812631A5CF5D3ED.
Examine the following that normalizes either an ed25519 or curve25519 private key to their common shared order:
% echo ...
Why was the choice made to reduce CRC32's effect...?
Well it doesn't actually reduce the intended effect in this use-case. It's purpose is to quickly detect if a wrong set of words was entered, nothing more.
Also, as @user36303 commented above regarding cryptosteel, a nice side effect is you can reduce the seed words from 25 to 24 words by simply writing ...