How do I generate a Ledger Monero wallet with the CLI (monero-wallet-cli)? According to the release notes v0.12.2.0 includes Ledger support. How do I generate a Ledger Monero wallet with the CLI (monero-wallet-cli)?

Windows
We first have to ensure that we're sufficiently prepared. This entails the following:

This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.

You need to run / use CLI v0.17.1.9, which can be found here or on the downloads page of the official website.

You need to install the Ledger Monero app. Instructions can be found here. In addition, make sure to set the network to Mainnet

Your Ledger needs to be plugged in and the Ledger Monero app should be running.

Either your daemon (monerod.exe) should be running and preferably be fully synced or you should connect to a remote node.

Now that we're sufficiently prepared, let's start!

Go to the directory / folder v0.17.1.9 monerod.exe and monero-wallet-cli.exe are located.

Open a new command prompt / powershell. This is done by first making sure your cursor isn't located on any of the files and subsequently doing SHIFT + right click. It will give you an option to "Open command window here". If you're using Windows 10, it'll, most likely, give you an option to open the Powershell.

Now type:
monero-wallet-cli.exe --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200 (Win 7 + 8)
.\monero-wallet-cli.exe --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200 (Win 10)

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
monero-wallet-cli.exe --generate-from-device MoneroWallet --subaddress-lookahead 3:200 (Win 7 + 8)
.\monero-wallet-cli.exe --generate-from-device MoneroWallet --subaddress-lookahead 3:200 (Win 10)

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.17.1.9) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one caveat. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.

You may have to hit confirm twice before it proceeds.

Your Ledger Monero wallet will now be generated. Note that this may take up to 5-10 minutes. Furthermore, there will be no immediate feedback in the CLI nor on the Ledger.

monero-wallet-cli will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Ledger Monero wallet in conjunction with the CLI.

Mac OS X
We first have to ensure that we're sufficiently prepared. This entails the following:

This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.

You need to run / use CLI v0.17.1.9, which can be found here or on the downloads page of the official website.

You need to install the Ledger Monero app.

Your Ledger needs to be plugged in and the Ledger Monero app should be running.

Either your daemon (monerod) should be running and preferably be fully synced or you should connect to a remote node.

Now that we're sufficiently prepared, let's start!

Use Finder to browse to the directory / folder monero-wallet-cli (CLI v0.17.1.9) is located.

Go to your desktop.

Open a new terminal (if don't know how to open a terminal, see here).

Drag monero-wallet-cli in the terminal. It should add the full path to the terminal. Do not hit enter.

Now type:
--generate-from-device <new-wallet-name> --subaddress-lookahead 3:200

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
--generate-from-device MoneroWallet --subaddress-lookahead 3:200
Note that aforementioned text will be appended to the path of monero-wallet-cli. Thus, before you hit enter, your terminal should look like:
/full/path/to/monero-wallet-cli --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200
Where the full path is, intuitively, the actual path on your Mac OS X.

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.17.1.9) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one caveat. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.

You may have to hit confirm twice before it proceeds.

monero-wallet-cli will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Ledger Monero wallet in conjunction with the CLI.

Linux
We first have to ensure that we're sufficiently prepared. This entails the following:

This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.

You need to run / use CLI v0.17.1.9, which can be found here or on the downloads page of the official website.

You need to install the Ledger Monero app. In addition, you may have to add some udev-rules. A script can be found here.

Your Ledger needs to be plugged in and the Ledger Monero app should be running.

Either your daemon (monerod) should be running and preferably be fully synced or you should connect to a remote node.

Now that we're sufficiently prepared, let's start!

Go to the directory / folder v0.17.1.9 monero-wallet-cli and monerod are located.

Open a new terminal.

Now type:
./monero-wallet-cli --generate-from-device <new-wallet-name> --subaddress-lookahead 3:200

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
./monero-wallet-cli --generate-from-device MoneroWallet --subaddress-lookahead 3:200

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.17.1.9) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one caveat. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.

You may have to hit confirm twice before it proceeds.

Your Ledger Monero wallet will now be generated. Note that this may take up to 5-10 minutes. Furthermore, there will be no immediate feedback in the CLI nor on the Ledger.

monero-wallet-cli will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Ledger Monero wallet in conjunction with the CLI.

A few final notes:

I'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet. Note that, upon recreating / restoring the wallet, you ought to append the --restore-height flag (with a block height before the height of your first transaction to the wallet) to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux). More information about the restore height and how to approximate it can be found here.

If you use a remote node, append the --daemon-address host:port flag to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux).

If desired, you can manually tweak the --subaddress-lookahead value. The first value is the number of accounts and the second value is the number of subaddresses per account. Thus, if you, for instance, want to pregenerate 5 accounts with 100 subaddresses each, use --subaddress-lookahead 5:100. Bear in mind that, the more subaddresses you pregenerate, the longer it takes for the Ledger to create your wallet.

You only have to use the --generate-from-device flag once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the CLI. That is:

[1]  Make sure your Ledger is plugged in and the Monero app is running.
[2] Open monero-wallet-cli
[3] Enter the wallet name of your Ledger Monero wallet.
[4] Enter the password to open the wallet.
If the Ledger wallet files are not in the same directory as monero-wallet-cli, you ought to open monero-wallet-cli with the --wallet-file /path/to/wallet.keys/file flag. Alternatively, you can copy the Ledger wallet files to the same directory as monero-wallet-cli.

It's imperative that the closing process of your Ledger Monero wallet is done in this specific consecutive order:

[1] Exit monero-wallet-cli by typing exit
[2] Exit the Ledger Monero app.
[3] Unplug the Ledger device.

If you have any further questions or need assistance, please leave a comment in this thread.


Should I use a hardware wallet? I hear a lot about hardware wallets and I would like to know if, in terms of security and functionality, it makes sense to switch to one of them.

Thanks in advance for answers.

In it's simplest form, a hardware wallet is for holding your private keys on a non-internet connected device. It is also designed to be easy to use with your internet connected machine whereby it can sign transactions without you having to transfer keys to your regular internet connected computer.

Should you switch is entirely personal choice and threat profile. There are alternative ways to achieve what's outlined above, such as using a computer that is never connected to the internet for holding your keys and signing transactions on that machine then transferring the signed tx to your regular internet connected machine for broadcasting.

Another option is to use multiple wallets, one with small holdings on your regular computer for daily use and another being a paper wallet for larger longer-term larger holdings.


How will the ring CT fork be rolled out? I understand that the latest monero software already has all the RCT code. Does it mean that no upgrade will be required prior to RCT HF? If so, is the block height at which RCT will be allowed already hardcoded - at which block?

Does it mean that no upgrade will be required prior to RCT HF?

This is currently correct. However, Ring CT is also in a testing phase on testnet. Therefore, there exists a possibility that bugs are found that have to be fixed before the v4 fork enables Ring CT transactions on mainnet. If this happens, it would be wise to upgrade your software to the latest binaries before the v4 fork occurs.

  If so, is the block height at which RCT will be allowed already hardcoded - at which block?

Yes it is, from the code:

  // version 4 starts from block 1220517, which is on or around the 5th of January, 2017.


Byte Size of other cryptonote network blockchains Is there a resource to see the byte size of other cryptonote network blockchains, such as Monero, Aeon, Boolberry, and more

As many cryptonote networks have the codebase that puts the entire blockchain in memory, I would like to know what kind of resources would be necessary for me to experiment around with them, into the foreseeable future

You could try chainradar.com, which may or may not be a trustworthy source.

But the real answer, and only thing relevant here, is that Monero does not put the entire blockchain into memory, and the rest of the question is therefore mostly beyond the scope of this SE. The question doesn't apply to Monero but might apply to other cryptonote-based coins that keep the blockchain in memory.

Edit: If you used chainradar to get blockchain size, you would probably need to use the API and get the block size for every block in existence and sum them. http://chainradar.com/api


Is using a remote node more private than using Electrum on Tails Is it more private to use Monero on Tails with a remote node then it would be to use Electrum (with BTC) on Tails?

When using Tails (so Tor for your internet traffic) it is "safer", from an IP tracking perspective, than using clearnet. From an IP tracking perspective there is really no difference in safety between using an SPV wallet such as Electrum or the Monero wallets with a remote node, they both work in a similar fashion and what you are doing by using Tails (so Tor) is trying to make tracking your internet traffic difficult. Of course, using Monero instead of Bitcoin has significant privacy advantages.

So in summation, yes, using a remote node (Monero) is more private than using Electrum (Bitcoin), because Monero uses stealth addresses (so hides your address) and hides the amounts (Confidential Transactions). Using via tor/i2p adds further privacy by hiding your IP address (whichever you use, Monero or Bitcoin).


CryptoNote features in other cryptocurrencies How many CryptoNote based currencies exist today?

Have ring signatures appeared in any cryptocurrencies that are not based on CryptoNote?

How many CryptoNote coins are not using a CryptoNight based PoW?

There's less than a couple dozen CN based currencies. See http://mapofcoins.com/bytecoin.

Shadowcash tried to implement ring signatures on a Bitcoin code base. See https://shnoe.wordpress.com/2016/02/11/de-anonymizing-shadowcash-and-oz-coin/.

To my knowledge, no non-CN coin uses Cryptonight. -- Oops, I misread that last question, see lethos3's answer to that one below.


how is the transaction fee calculated? I've tried Monero-wallet-cli, and following are two transactions:

0.01 XMR by 526 bytes:
http://moneroblocks.info/tx/99dae4c9ec68c8b4eb7f9f40a2c01f481d3b979ce97b5e0b2b5f55c759be11f6

0.008 XMR by 3709 bytes:
http://moneroblocks.info/tx/9554b072a522e12bf6de27668cfb34cb1351891635ac49c132aeefa3e16bea8d

Why the second transaction is with 0.008 given by 3709 bytes? Which is much larger than 526 bytes. Because monero transaction fee is not calculated by size?

Update:

The first transaction, I used transfer command, and I was actually transferring 0.2 XMR. monero-wallet-cli added another 0.09 xmr, and locked it for a while.

The second transaction I used sweep_all command to transfer all out of my wallet.

thank you :)

The base transaction fee is 0.002 monero per kB. However, change below 0.01 is not retrieved, but kept in the fee, to avoid generating unreasonably small outputs spamming the blockchain, so you may get up to 0.01 extra as the fee in those cases. This threshold is going to decrease soon too (see https://github.com/monero-project/monero/issues/1199).

In your case, both the fees are within 0.01 of 0.002/kB.


What cryptographic assumptions is Monero based on? Most crypto systems security are based on assumptions that certain problems are difficult, or some mathematical conjecture is true. The only counterexamples I can think of are the one time pad and shamirs secret sharing scheme (which coincidentally are also informationly secure).

What cryptographic assumptions is the Monero protocol based on (and is planning to be based on).

Firstly, Monero relies on the safety of Ed25519 (as opposed to secp256k1 for Bitcoin) and EdDSA. Note that if EdDSA/Ed25519 breaks, a lot more than Monero will be impacted, including SSH, Tor, I2P, OpenBSD, GnuPG and many more

From the Surae Noether CryptoNote white paper review

Implementation and use key images to prevent double spending

  The CN protocol implements a piece of cryptography unseen in cryptocurrencies before, in particular, the idea of using key images to protect against double spending. This is boldly treading on dangerous ground; no matter how deeply I, or any mathematician scrutinizes an algorithm in any white paper, it’s possible some 16 year old in South Africa will figure out a way to crack the encryption.

New PoW (CryptoNight)

  Implementing an entirely new Proof-of-Work algorithm could be just as vulnerable to exploitation as implementing any new piece of software. To be frank, without any sort of explicit, clear explanation of how it’s been done, it can’t necessarily be trusted. With Bitcoin,the task was clear: find the nonce so that the SHA hash is small. With this algorithm? I have no idea

Elliptic curve contants

  My single biggest question after reading the entire paper
  is the “how did they choose their elliptic curve constants?” The protocol appears sound; who chose the constants? Will there be a plan for choosing new constants in the future if needed? How can I choose other constants if I decide to fork it? Did the NSA come up with CryptoNote and choose these constants so any CryptoNote network has 10% the entropy of any other coin? Who knows. It’s probably not a big deal, and every coin has this as a critical point. Indeed, it’s a centralization point. If we all go happily forking the CryptoNote code left and right, we are trusting those developers to have made good decisions on the constants.

  However, having said all that, CryptoNote is absolutely spectacular. If you have a problem with the constants, and if you can figure out how to generate new ones, I say go for it. The protocol looks secure and tight.


Generate an integrated address using javascript in the browser? Is there a way to generate an integrated address (monero address + payment id) using javascript or PHP? This is assuming we just need the public monero address or do we also need the public view key and spend key too?

You can generate an integrated address if you just have the monero public address. See here: https://dustinlemos.com/integrated-address-demo/

Source from that site:

    <title>Integrated Address Demo</title>
      <meta charset="utf-8">

Integrated Address Demo

      <input id='input-address' type="text" style="padding: 5px; width: 700px;" placeholder="Enter a standard (netbyte 12) XMR Address" />

    <button id='generate'>Generate Integrated Address</button>

      Address:

      Payment ID:

      Integrated address:

addresses.js file:

//This file was created using code from luigi1111's address tools
//located at https://xmr.llcoins.net/
//see copyright below

//functions for various XMR/Cryptonote stuff
//(c) 2016 luigi1111
//can't imagine this is useful for anything but this site, but
//Licensed under the MIT license:
//http://www.opensource.org/licenses/MIT

//requires cn_util.js, mnemonic.js, sha3.js, and their requirements

generateIntegratedAddress = function (walletAddress) {
    var addr58 = walletAddress;
    var pubSpend2 = {};
    var pubView2 = {};
    var pubAddrHex = {};
    var pubAddrChksum = {};
    var pubAddrForHash = {};
    var pubAddrHash = {};
    var pubAddrChksum2 = {};
    var xmrAddr = {};

  if (addr58.length !== 95 && addr58.length !== 97 && addr58.length !== 51 && addr58.length !== 106){
    throw "Invalid Address Length!";
  }
  //Get the netbyte
  var addrHex = cnBase58.decode(addr58);
  if (addrHex.length === 140){
    var netbyte = addrHex.slice(0,4);
  } else {
    var netbyte = addrHex.slice(0,2);
  }
  //viewkey + pID stuff
  if (netbyte === "13"){
    throw "Invalid Address (netbyte 13): you must use a standard XMR address (netbyte 12)";
  }
  if (netbyte === "11"){
    throw "Invalid Address (netbyte 11): please use a standard XMR address (netbyte 12)";
  } else if (addrHex.length === 140){
    pubView2.value = addrHex.slice(68,132);
  } else {
    pubView2.value = addrHex.slice(66,130);
  }
  if ((netbyte !== "11" && netbyte !== "13") && addrHex.length !== 138 && addrHex.length !== 140){
    throw "Invalid Address Length!";
  }
  var addrHash = cn_fast_hash(addrHex.slice(0,-8));
  pubAddrHex.value = addrHex;
  if (addrHex.length === 140){
    pubSpend2.value = addrHex.slice(4,68);
  } else {
    pubSpend2.value = addrHex.slice(2,66);
  }
  pubAddrChksum.value = addrHex.slice(-8);
  pubAddrForHash.value = addrHex.slice(0,-8);
  pubAddrHash.value = addrHash;
  pubAddrChksum2.value = addrHash.slice(0,8);

  if (addrHex.slice(-8) != addrHash.slice(0,8)) {
    throw "checksum invalid!"
  }
  // *** Generate random payment ID
  var pID = rand_32().slice(0,16);
  xmrAddr.value = toPublicAddr("13", pubSpend2.value, pubView2.value, pID);
  return {
    // "publicViewKey": pubView2.value,
    // "publicSpendKey": pubSpend2.value,
    "integratedAddress": xmrAddr.value,
    "paymentId": pID
  }
};

function toPublicAddr(netbyte, pubsk, pubvk, pid){
  if (pubvk === undefined){pubk = "";}
  if (pid === undefined){pid = "";}
  if ((netbyte !== "13" && pid !== "") || (netbyte === "13" && pid === "")){throw "pid or no pid with wrong address type";}
  if (netbyte === "11"){pubvk = "";}
  var preAddr = netbyte + pubsk + pubvk + pid;
  var hash = cn_fast_hash(preAddr);
  var addrHex = preAddr + hash.slice(0,8);
  return cnBase58.encode(addrHex);
}


Does Aeon have a web wallet? Does Aeon have a web wallet, similar to MyMonero?

An Aeon web wallet AEON Pocket was recently announced on Reddit.


How much arbitrary data I can embed in a transaction? How much arbitrary data I can embed in a transaction?

Does Monero have something something similar to Bitcoin's OP_RETURN?

An arbitrary amount of arbitrary data can be added in a transaction. The extra field contains data with a high level structure. Several fields are predefined, such as public key, or extra nonce. In order to add custom data there, you would need to define another data type, and store it in that extra field. Minergate recently did just this, adding 32 bytes of data with unknown semantics.

Note that since Monero has transactions fees which depend on transaction size, the more data you add to the extra field, the more you will have to pay in fees (currently 0.01 monero per kB).


Cryptonote SHA3 bigger than 64byte? (Scratchpad Initialization) The cryptonote whitepaper says

  First, the input is hashed using Keccak [KECCAK] with parameters b =
     1600 and c = 512. [..]

That's nothing else as hashing the input with SHA3. The size of a SHA3 hash is 512 bit = 64 byte. The paper continues

  [..] The bytes 64..191
     are extracted from the Keccak final state and split into 8 blocks of
     16 bytes each.

How can I extract the bytes from 64 to 191 when the size of the hash is only 64 byte?

Edit: Does Keccak final state refer to the internal state of the SHA3 algorithm and not to the output? If yes that leads to the question how can I get this value when I use a normal SHA3 hashing function that just returns the output. Or - oh my gosh - do I need to implement SHA3 by my own?

Keccak has a 200 bytes internal state.

For SHA3, the produced hash is only a part of the final Keccak internal state (e.g. the first 64 bytes).

However, the scratchpad initialization function of CryptoNight uses data from almost all the final internal Keccak state. The first 32 bytes are used as an AES-256 key and the 128 bytes from byte 64 to byte 191 are used as initial data. The initial data is then encrypted with AES rounds to make the first 128 bytes of the scratchpad.

Therefore, you can't get all the required data from the 64 byte output of the official SHA3/512 hash function.

EDIT: The function used by Monero is not based on SHA3 with a 64 bytes output, but on the original Keccak with a 32 byte output (the message paddings of SHA3 and Keccak are not the same).


How Monero transactions related with mixins Can anyone explain me is there a relationship between transaction outputs with the number of mixins using in the transaction? I meant If someone sends 12XMR to someone else with 5-mixins how many outputs could be there? Any idea of it? For above Tx number of inputs is 6? Am I correct?

"Mixins," known more commonly as "decoys," impact the input side of the transaction. They do not have anything to do with the number of outputs.

Each input has the number of decoys included in the ring signature. If multiple inputs are used, then there will be multiple ring signatures, each with their own set of decoys.

Each transaction has a minimum of two outputs, even if there is no change.

If I send 12 XMR in a single input to a single person with 5 decoys (6 ringsize), then the transaction will have 6 total possible inputs and two outputs.

If I send 12 XMR in two inputs (eg: 10 XMR and 2 XMR) to a single person with 5 decoys (6 ringsize), then the transaction will have 12 possible inputs (6 ringsize x 2 spent inputs) and two outputs.


Is it possible to solo mine Monero (XMR) using AMD and Nvidia GPUs in the same rig? I've been looking into this a lot over the past 2 days.

I have found ways to use AMD and Nvidia GPUs in a mining pool (XMR-stak), but I haven't been able to find any info on solo mining with both of these GPUs.

Does anyone know if its possible to do so? If so, is there a good guide?

Also, I'm using Windows 10.

Yes, you can solo mine using both cards if you use a miner like xmr-stak and point it to a pool that supports solo mining.


How might one stop pruning when started in monerod? How do I gracefully stop blockchain pruning done by monerod?
I have started monerod to update the blockchain and when it finished syncing it I decided to try to save some disk space as the database grew to a lot.
I started pruning by running the prune-blockchain command inside of monerod. Sadly, I later learned that such way of pruning does not do any good for the disk space usage. Now I want to gracefully stop this process in order to not corrupt the existing database.
I have tried from a new shell to do
monerod exit

this indicates that the signal for termination is sent but the deamon keeps running. The shell where monerod is running does not react to any input.
How might I stop pruning gracefully when it was started by prune_blockchain from monerod cli?

One does not. Pruning is a long one shot operation.
If your database is too large, pruning in place will not actually decrease the file size. You will need to resync from scratch with --prune-blockchain for this, which neatly moots your question in the first place :)


What does getblocktemplate return? Looking on the forum, it seems that getblocktemplate RPC call returns both a blockhashing_blob and blocktemplate_blob, but on the monerod documentation i didn't find anything about the blockhashing_blob.

As i understood, it returns a blocktemplate_blob, that is an entire block blob, with a reserverd field (nonce), that you can change trying to make the block hash below the target.
It seems to be complete with miner coinbase transaction, and all the other stuff belonging to a block.

Is there anything that i didn't catch?

blockhashing_blob is the block header and Merkle tree root hash. The block header has a nonce field and it is this a miner updates and then hashes the blockhashing_blob (which contains the header and updated nonce).

blocktemplate_blob is the whole block with transactions (including any requested reserved space). Nobody hashes the blocktemplate_blob directly, rather, they use this to create a blockhashing_blob to hash.

The reason both are returned from getblocktemplate is because a miner / pool / proxy may want to modify the block's reserved space before creating the blockhashing_blob. This reserved space can only be easily changed before creating the blockhashing_blob because you need to know it's offset. Conversely, the nonce can be updated in the blockhashing_blob directly because it's at a fixed location.

Lastly, it is the updated blocktemplate_blob that's submitted back to the network when a successful hash is found. This has been updated to include the successful nonce and any reserved data. Setting aside other validation, other nodes simply convert the submitted blocktemplate_blob to a hashing blob, hash then check resulting hash meets the difficulty target. I.e. they do not need to edit anything.


Which mining software is most efficient for CPU mining? Given that there are a couple of different miners out there, such as the standard monerod, Wolfs XMR or lucasjones XMR miner, which one would be best suited for CPU mining? Is there any code difference between those choices, or are they just optimised builds for specific architectures (ie. different CFLAGS for monerod)? Do pools oblige one to use specific software?

I use wolf's XMR miner and am very happy with the results, compiled from source. However, your performance with any miner is going to be dependent upon the OS you are running (I run varying flavors of Debian for reference).

As far as pool preference, they don't care what miner you are running just that you are submitting hashes.


In which order does a node select peers to create a connection? In the function connections_maker in net_node.inl a node selects the peers to which it tries to create a connection. This computation seems to be important in which order we select the peers: either from anchor list, white list and grey list or from grey list and white list. However, I have some troubles to figure out when we select which order. Can anybody explain that?


0 - 100 % GPU spikes when mining [NVIDIA GTX 750 TI] when I start mining using XMR-Stark my GPU (GTX 750 TI) is showing weird 0-100% spikes like this: Task Manager, GPU-Z.

My CPU (i7-4790K) is consistent: Task Manager.

My hashrate (cpu+gpu) is consistently around 400 and my GPU temperatures are fine: HWMonitor

The only solutions I found when googling were to change the settings in the NVIDIA Control Panel to maximum performance but that didn't help.

I am not overclocking my CPU nor my GPU. I am using the latest GPU drivers, latest Windows 10 version, and latest XMR-Stark version.

Does anybody know how to fix this (and possibly increase my hashrate)?

Thank you

You must open nvidia.txt (a file that xmr-stak creates after running for the first time) and set bsleep and bfactor to something other than the default "0". Try "bfactor" : 8, "bsleep" :  25, then restart xmr-stak.


Possible lengths of Monero addresses? I'm doing crude client-side verification of a form that includes an input for a Monero wallet. What are the possible lengths of an address? Are 106 and 95 the only possible lengths?

For now, the are two used formats: standard (95 characters long) and integrated (106 characters long).

Subaddresses are a new type, but differ from standard addresses only by their prefix, so are also 95 characters long.


What would be good metrics to measure impact on miners when tweaking hardware/system? Let's start with wolf's miner and Linux kernel 3.x at least.

What would be some good metrics to measure (+/-) impact for tweaking kernel (kernel cmdline like nohz_full/tickless/ intel.cstate), pinning process and sysctl like vm.stat_interval?

Strongly reducing the OS jitter on hashing thread can save some context switching overhead and rescheduling load, and give more CPU time per second to hashing process.

Do you consider hashrate to be a good metric with a static diff of course?
Or do you think reducing OS jitter will not improve hashrate, but the number of submitted shares per time slot might increase?

For example, pinning thread to dedicated core seems to reduce the hashrate. But is the impact positive or negative?

The hash rate is of course the main metric to consider, since it determines how fast the miner can go through nonces in order to find a hash that meets the difficulty. Whether the difficulty is static or not is not really important, since it only determines when a found hash will be submitted to the pool. This does add some overhead if you're submitting too often, of course, but I think it is minimal.

Another thing to consider is energy expenditure. If you run on a laptop, a tool like powertop can help you see power usage. If you're on a machine without a battery that can report such things, I'm not sure there's a good tool for this, though.

A less interesting metric might be network latency between the miner and the pool. However, this is likely to have only minimal impact.

If you want to go lower level, the tool perf can show you what a process is busy doing, so you know what parts of the code is the current bottleneck.

/proc/$PID/ has a number of interesting things you could check:
/proc/$PID/status gives you number of context switches. Other files may have other interesting statistics on a running program.

Last, Wolf's miner has a --benchmark option. It may or may not be in working order in your version, but IIRC the changes needed to revive it were minimal (it was a long time ago, I don't remember what they were off the top of my head).


Raspberry pi cold wallet safety I don't have an old computer to make an air gap. I do have a raspberry pi from 2012 though. If I made a new SD card with fresh OS would this be safe enough to make cold wallets on? It would be easy to hide, also.

Sure!
Boot the Raspberry, change admin password (keep this safe!) turn off the wifi and bluetooth.

Turn wifi and bluetooth off:

sudo nano /boot/config.txt
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt

Reboot and NEVER turn on the internet again on this Raspberry.

Note all the software you think you will need (Monero, gpg and maybe KeePassX). Download them on your online mac/pc, checksum all the files and signatures, move to usb stick. Plug into Raspberry and checksum again all the files.
Install what you need, store your password for the Monero Wallet in KeePassX (maybe also use an extra usb-stick as a KeePassX-keyfile).

Some more information on making a cold wallet and a view-only wallet on your online machine to check the balance:

Monero, how to create a view-only wallet and verify cold wallet's balance - Youtube tutorial

Setup view only wallet and check balance - Reddit topic


What's the easiest way to create a unique job for every worker of monero mining pool? There are several mining pool servers.

Each server polls monerod for a new job.

I want to generate a unique job on each server for all the workers of my distributed pool.

It is very important to note that I want to generate unique among all my servers.

What is the simplest to do this?

Would it be the simplest way to use an algorithm similar to this algorithm from the sources of mining pool implementation? (and the question of uniqueness interests me the most)

Generate a server ID (4 bytes).
Use extra nonce integer (4 bytes).
And put this (1, 2) as extra data of miner’s transaction.
Regenerate
hashing blob by using parse_and_validate_block_from_blob and
get_block_hashing_blob functions.

Every Monero pool I know of (including the pool you linked), reserves 32 bytes in the block template for the purposes of dealing with job uniqueness, which is laid out something like:

job_nonce | instance_nonce | pool_nonce | worker_nonce

Here, job_nonce would be unique to the job, instance_nonce unique to the server and lastly pool_nonce and worker_nonce is space a mining proxy can use.

Thus each server, as you correctly observe, needs to use a unique instance_nonce (per the example above). It doesn't matter what it is, but it needs to be unique. The simplest way of achieving this is to read 4 random bytes. This can be read from /dev/random or /dev/urandom, or anything which sources random data (such as a UUID). Alternatively you could set an instance ID via a pool config file, removing the need to create a random ID, but you'd have to make sure each pool was configured with it's own unique ID.

If you don't need to support proxies, you don't need to reserve the space for the proxy related nonces.

  What is the simplest to do this?

Simplest is probably reading 4 bytes from /dev/random.


Can't create transaction: internal error: Daemon response did not include the requested real output When I try to send a transaction from the 0.13.0.3 GUI, I keep getting stuck with an error:

  Can't create transaction: internal error: Daemon response did not
  include the requested real output

I tried to close the wallet and open it back, but nothing changes.

I also tried from the 0.13.0.3 CLI, unfortunately the problem is the same.

I tried on multiple different computers (with same keys), but the issue is still the same.

Now I can see that the unlocked balance has this status (waiting for blocks):

The problem happened after I tried to send moneros from the Monero wallet GUI v0.11.1.0 (please check this post: How to unlock a PENDING order in Monero Wallet GUI?). The order was stucked with PENDING status during hours, so I updated to Wallet v0.13.0.3 and was finally able to cancel the order. Then I tried again to send money to the same address, but it didn't work and I am still stucked since.

EDIT

The weirdest point is that I can't no more access my key with the wallet v0.11.1.0, I have an error "Couldn't open wallet: invalid password". Still working with v0.13.0.3

EDIT

Here are some of the last daemon logs:

You are now synchronized with the network. You may now start monero-wallet-cli.
2018-10-23 10:43:48.270 [P2P2]  INFO    global  src/blockchain_db/lmdb/db_lmdb.cpp:600  [batch] DB resize needed
2018-10-23 12:06:53.123 [P2P0]  WARN    global  src/p2p/net_node.inl:1338       [1;31mNo incoming connections - check firewalls/routers allow port 18080[0m
2018-10-23 12:35:11.569 [P2P5]  ERROR   blockchain      src/cryptonote_core/blockchain.cpp:2380 Borromean range proofs are not allowed after v8
2018-10-23 14:22:20.833 [P2P8]  WARN    net.dns src/common/dns_utils.cpp:519    WARNING: no two valid MoneroPulse DNS checkpoint records were received

Is there something wrong there?

You can open a 0.11 wallet with 0.13, but not the other way around. The format was updated, and encryption was strenghtened. Once you've updated, you can't go back.

Are you using the same daemon version as wallet version ? If not, that's probably the problem.

In particular, a 0.11 daemon will not be able to sync current blocks, so will not know about any newer output of yours.

For the record, for a testnet wallet (which is not your case here, but putting it here in case people find this), then the problem may also be that you had outputs on the old testnet chain, as it was reorganized after a small consensus change in bulletproof format.


How can I start to use tippero on #monero Freenode IRC? I need to have my nickname registered with Freenode for some of the #monero IRC features, including tippero. How can I register my nickname?

There are some instructions on this web page: https://freenode.net/kb/answer/registration

Basically, you enter the command:

/msg NickServ REGISTER yourpassword youremail@example.com

Then you will receive an email containing a command you will have to run to complete the registration.

After that, to connect to Freenode with your nickname, you can either use SASL (https://freenode.net/kb/answer/sasl) or connect with the command:

/connect chat.freenode.net 6667 yournickname:yourpassword


Missing transaction. XMR sent to Monerujo wallet I have a basic understanding and ability to deal with a number of cryptocurrencies and recently decided to acquire a small amount of Monero. I purchased via Binance and found a wallet (Monerujo), that I transferred XMR to. At least I thought I did. The transfer to my public address took place, according to Binance, but nothing is showing in my wallet. It continues to display zero.

I found a thread that contained a utility to use to confirm a transaction. I used this and received the follow response:

This address doesn't own output 0 with pubkey: 555b...7c9f for amount: Confidential
This address owns output        1 with pubkey: 238a...48ce for amount: 0.297602

Total received: 0.297602
Found payment ID: 0000000000000000

What is going on? Can anyone help me understand the above as well as gain access to my XMR?

Thanks

Each Monero transaction contains multiple inputs/outputs. It is not expected that you own all of the outputs of the transaction; only those destined for you.

The utility you used is reporting:

  This address owns output 1 with pubkey: 238a...48ce for amount: 0.297602

Which indicates that your address did, in fact, receive 0.297602 XMR.


How can Monero best be used within a commercial business? If a business owner wants to hold Monero and potentially use it for business transactions, using for example the GUI wallet, how would this best work?

I'm thinking in terms of who would hold the password and mnemonic seed? If more than two individuals were to have access to this, then how best to prevent one of them spending the coins without the others knowing who was responsible?

Is there a way that more than one of the company's office bearers would have to sign off on any send transaction?  Otherwise, I could imagine that only a CEO or CFO would be able to make transactons, which might work for a small company but not a larger one with many employees who need to make transactions.

Probably multisig.

Multisig is when M of N (2 out of 3, or 3 out of 5, or anything, like 2 out of 10, for example) signatures are required in order to spend. In your example, there may be a Monero wallet with several private keys associated with it.  Perhaps management's/ownership's plan is for requiring at least two signatures per transaction.  How it will probably work is that one of the signers would initiate the transaction, and then the transaction would need to be signed by another private key holder before the transaction would be valid and broadcast to the network.

There are many interesting things that can be done with multisig.  For example, perhaps a small company requires three signatures, and the owner holds three keys.  But there may be several other individuals also holding a key, in which case they can only create a legitimate transaction among themselves if at least three non-owners agree.  This brings risk, but also accountability*.

Monero doesn't currently support multisig, as of the beginning of 2017, but it is under development.  The 'holdup' was RingCT, whose implementation needed to be finalized first, before work could progress with multisig.

Update: Monero implemented (M-1)/M multisig first later in 2017, and then added M/N multisig in 2018.

*The accountability aspect is tricky.  In an example where a multisig account (a) is set up with six private keys, (b) requires three signatures, (c) the owner owns three of the keys, and (d) three trusted employees each own the other three keys, there would be no way to tell whether the owner signed with her three keys or the trusted employees signed with their three keys.


Could a tipbot be construed as a money service business? In the United States this would impose obligations on the owner of the bot to log info and request KYC info from users to comply with the Bank Secrecy Act I believe. I'm not sure where tippero lives, but I imagine there are similar regulations in other countries. Does anyone have any insight into what levels of money would make a bot or other service fall into this category in any jurisdiction?

Gov'ts seem to like making rules and seem to think that numbers (aka Mathematics, aka. crypto currencies) must be regulated by them.

Check your gov't, but assume the answer is yes.


Is userland running monero gui possible and safe? I'm thinking of buying a used tablet with Android and installing user land then installing the Monero GUI in user land.  Is this a security risk?

As with any used computer, I'd advise wiping it, reinstalling the operating system before using it, to ensure the previous owner hasn't installed anything malicious on it.

Then running Monero on it will be fine. Running in userland (user space), is preferred.


Can one reduce the monero pruned blockchain further below 25gb? Bitcoin core has the ability to prune its blockchain all the way down to 550MB, but monero after pruning is 25GB. Why can't monero also give users the ability to prune to an amount of our choosing?

Technically, it is possible to decrease the size further.

However, there are diminishing returns, pros and cons of futher pruning (currently, a pruned node can still serve some of the blockchain, by design), pros and cons of ease and speed of accessing data (some data is kept duplicated in the database for lookup purposes), etc.

You bring a comparison with Bitcoin, and one important point of difference between the two is that Monero's RingCT outputs are pretty much never known spent, so you can't drop these ever, whereas Bitcoin can.


What is the best way to debug a `segfault-ing` monero daemon on ubuntu Does it require compiling a debug build, or can it be done with a release build as well? I assume it can be done, but might lack proper feedback!?

Either way; which tools are needed and which guidelines should i follow?

For example, would;

  gdb monerod
  run
  -segfault-
  bt

Generate enough information for the devs to work with? Or are there better ways?

You have the right steps, but a release build will not provide enough info so it would be better to compile a debug build.


Why isn't simplewallet relatively safe with a very strong password? Very new to crypto-currency.
From what I understand the only way to gain access to my wallet funds is:

get my mnemonic seed.
get my key file + password.

lets say my password is a huge strong password I keep in a safe spot,
Why is that 'not enough' ? ( I see lots of posts encouraging cold wallets)

Thanks and sorry if this is very basic...

Used correctly simplewallet (named monero-wallet-cli in the new release) is relatively safe compared to an exchange or web wallet, but it will never be as safe as cold storage.

  lets say my password is a huge strong password I keep in a safe spot

As soon as you enter your strong password (or mnemonic seed) on your computer to use your wallet, it could potentially be exposed to a keylogger.

Properly created cold storage wallets by definition never have their passwords or mnemonic keys exposed to an internet connected device.


The process has no code signature I run Little Snitch on my Mac, and when I run the Monero GUI, it warns me numerous times "The process has no code signature. The executable can be maliciously modified without being detected." for many, many IP addresses.

Is this normal?

I see a lot of outgoing traffic, too, and I'm curious: why is Monero so chatty through a process that has no code signature and is susceptible to being modified? Isn't that a fairly large security risk?

The Monero developers didn't bother to buy an Apple developer license, so that's why the binary isn't signed and thus throws up that error.


How to nodes discover other nodes? How do nodes/wallets know what is the IP of the "nearby" node running monerod. How do they discover other nodes?

Monero wallet's daemon monerod initially and when all recent peers are offline tries to connect to one of the hard coded seed nodes, currently these are:

seeds.moneroseeds.se
seeds.moneroseeds.ae.org
seeds.moneroseeds.ch
seeds.moneroseeds.li

If it peers with enough regular network nodes, these nodes are not used any more unless all known peers are offline.


Monero - Checkpoint Validation Failed Could you help me with this error? I do not know what I'm doing wrong. I started to mine a fork of monero from block genesis, but I did the error that is seen in the image and I do not know where to investigate that error.

"If you want to have a mainnet custom chain, remove the checkpoints in checkpoints.cpp (and disable that define)." -moneromooo, IRC, 2017-Oct


Would this be considered good OpSec? Buy any altcoin on an exchange on the clearnet (on PC1 running OSX)
and have it converted to XMR wallet 1 (on PC2 running Tails)
Then send those coins from wallet 1 to another XMR wallet, wallet 2.
Finally wallet 2 to the marketplace where I wish to buy stuff

Of course I'd be waiting a couple days between each step. Would it be smart to at least do the last step on a crowded public wifi? I do not have any VPN whatsoever.

Just a couple days ago I thought I'd "just" setup a remote node on a PC which is on the clearnet and then somehow connect to it from a public wifi. All this just because my current USB-drive (8GB/ PC2) wouldn't have enough storage for the Monero blockchain. But as some people suggested that operating a remote node on a clearnet (PC1), of which I'd be the only user isn't safe; and also because I don't know much about Terminal/command line/SSH and would only be able to stick to internet guides I thought the following method should also do the job.

Would it be sufficient if I acquired myself a let's say 64GB USB-drive running Tails and have the blockchain downloaded on it? I would be following this guide step by step: https://medium.com/@Electricsheep56/sheeps-noob-guide-to-monero-gui-in-tails-3-2-d75c4e829c17

That guide recommends to download the blockchain onto an external drive, which confuses me. I do currently have an external HDD, which I have for normal/non-"anonymous" use. Could I instead of buying a 64GB USB-drive just have the blockchain downloaded on that and run Tails? Would that leave any trails or anything that could lead back to my activities on the HDD?

Would this be considered good OpSec?

Thanks!

Small question on the side: https://garlicgambit.wordpress.com/2017/04/16/monero-gui-on-tails-3/ This guide shows one how to create a bootable Tails with Monero preinstalled on it. I'm not really sure what that would be useful for if you can just download it directly from getmonero.org and use it instantly. Is it for that cold storage thing? Is "cold storage" needed if I just want to convert regular money into altcoins and spend it in a timespan of a month?

It's fine for the HDD to have the blockchain installed on it as long as it has no ties to your wallet, Keep the wallet keys on the persistent storage.


Monero origins - optimized / crippled miner I understand that soon after monero was created, some users discovered that it's possible to optimize the miner for multiple orders of magnitude.
This led to realization that it was probably the original mining software, inherited from bytecoin, which was intentionaly crippled. What exactly happened during this time?

The following text addresses the the crippled miner story. It has been copied verbatim from the original source, https://da-data.blogspot.com/2014/08/minting-money-with-monero-and-cpu.html

Minting Money with Monero ... and CPU vector intrinsics

August 28, 2014

I woke up on May 28th, 2014, on vacation with my family in the middle of the desert, to find a copy of my private source code plastered across the bitcointalk message board. Announced as a "new optimized version" of the Monero currency miner, it was enthusiastically adopted by cryptocurrency miners across the world. And in the process of doing so, my daily profit from the Monero Mining Project dropped by over five thousand dollars per day.

But let's start at the beginning, when I started getting in to a loose collaboration with three people I've never met---one whose name I'm not even confident I really know---with hundreds of thousands of dollars worth of a nebulous new cryptocurrency at stake.

It started with a cryptic note from someone I'd met online, with a link to a bitcointalk.org message board discussion for a new currency called "bitmonero". His note said only:

"this looks interesting."

From prior collaborations with him, I knew he had a good nose for opportunities in cryptocurrencies. Within an hour or two, he followed up noting:

"Regarding bitmonero it is profitable with aws with the wallet miner. Seem like some people have got optimised miner which is a few times faster as well so there obviously room for improvement..."

AWS, of course, was Amazon Web Services' spot market, which will let you cheaply rent mind-boggling amounts of compute power on short (1 hour) timescales. AWS profitability is a key ingredient for making money on cryptocurrency mining, because it scales: You can rent one machine or 10,000, and the only thing you have to worry about is if you start to use too many, the price will go up.

I was busy with the end of the semester and didn't respond quickly. The next day, I had an email from him offering 1 Bitcoin (about $600) to develop a 5x faster miner, and from chat, we discussed splitting the profits after that 50/50. I was still feeling overwhelmed with real work, but I took a brief look at the code, and something... well, something smelled funny. So funny that I got home, couldn't get it out of my head, and spent the next 6 hours playing around with it -- and got a 3x speedup.

The next day, I dropped my contact a note:

I'm giving it a little go at rewriting the entire thing in SSE for fun. I finally get it - they basically took scrypt as their model but make the whole thing a big long dependent chain. Hard to shave memory but at the cost of slow verification.

Followed a day later by raising that to a 5x speedup, and then an 8x speedup, and within a week, an 11x speedup. That was pretty remarkable, given that a developer had already started trickling optimizations into the codebase.

The more I looked at it, the more clear it became: The original developers deliberately crippled the miner. It wasn't just slow, and it wasn't just naive; it was deliberately obfuscated and made slow by the use of completely superfluous copies, function calls, use of 8 bit pointer types, and accompanied by the most ridiculously slow implementation of the AES encryption algorithm one could imagine.

Now, the history of "Bitmonero" (now called Monero) started to become relevant. In Feb 2014, an anonymous group of developers released a coin called "Bytecoin" based on an entirely new implementation of a bitcoin-like cryptocurrency called Cryptonote, but with much stronger anonymity built in through the use of a clever Diffie-Hellman like mechanism for encrypting destination addresses and the use of Rivest's ring signatures to provide a transaction-level mixnet without the need for realtime mixing. It's not perfect, but it's clever, and the most important thing is that it's new, and fundamentally different from Bitcoin. That attracted a lot of attention.

But when Bytecoin was released, it was presented as though it emerged from two years on the "dark web" (Tor onion sites and the like), during which time, 80% of the possible coins that could ever be minted, had been minted. The reception in the cryptocurrency community was heavily skeptical.

My strong belief is that the skepticism was warranted: Here's the original slow-hash from bytecoin as it was copied into Bitmonero. It has some doozies. For example, on line 100, you might note that for every iteration through an inner loop repeated tens of thousands of times, the AES key is re-imported into the library. The later loop, starting on line 113, is repeated half a million times, and is so abstracted through lots of memcpys and pointer manipulation it's hard to tell that all it really does is one round of AES encryption, a pointer dereference into a random scratchpad, a 64 bit multiplication, and another pointer dereference. Phew. This original code was roughly 50x slower than my final optimized code, and could have easily been used to fake two years of blockchain data on a single computer or a small cluster. I'm pretty sure that's what happened.

Bitmonero was a fork of Bytecoin designed to not have the 80% premine. But its initial developer either didn't know, didn't care, or wanted to profit from the de-optimized hashing. That initial developer was pretty quickly given the boot by the community, and in came an unrelated group of developers who took it over---who were, as far as I can tell, completely unaware of the deoptimization. So things sat there for a few weeks in the same state as Bytecoin.

By the time I got into it, developer "NoodleDoodle" (hey, this is crypto, people can pick whatever names they want -- Satoshi Nakamoto?) had already untwisted the first "de-optimization" with the AES encryption key. But the rest was ripe pickin's. Most importantly, the entire use of AES in the inner loop was one instruction on modern x86 CPUs.

This was a brilliantly designed proof-of-work function targeting the strengths of modern CPUs -- native AES encryption and fast 64 bit multipliers -- tuned to use a scratchpad exactly the size of the per-core L3 cache on Intel CPUs (about 2MB) that someone then wrapped in such a thick blanket of crap it was nearly unrecognizable until you started jumping in, tearing it apart, and putting it back together again.

Here's what it looks like without the crud (diagram shows one round): Some initial 128 bit values are determined by hashing the block state using a Keccak (sha3) variant - call them A and B. The big lookup table is also populated using that same state, mixed around using AES. Then, executed 500,000 times, are rounds of mixing as shown at the right: Use A to determine a pseudorandom location in the scratchpad, take that, mix it in, AES encrypt it (one round), use the result to determine a second location, use that in a 64 bit multiply, store it back, and repeat. Elegantly simple.

I didn't have the AWS account limits (or credit cards!) to really do it right, so I delivered some code to my contact and we went to town.

By the 14th of May, we were 45% of the total hashing power on the coin. Things started to get a little exciting:

I think i should make almost 6 btc in the last 24hr... will send you 3 if i manage to sell all the MRO.

$1500 per day was starting to seem like a very interesting ROI. I gave up on sleep for a while, and begged my family for permission to continue the project for a few hours per day while we were on vacation. Permission granted. I decided we'd made the right decision when on May 21st, we each netted 13 BTC (about $6500 USD), and 17BTC the next day. I think we exceeded 60% of the net hash of the coin at a few points. That's enough to play nasty games, but we weren't interested in that (and doing so would have required me to understand the rest of the code much more deeply than I had), so we just sold as fast as we could mine.

That was eye-opening. Because of the newness of the codebase and its actual, significant technical advances in anonymity (and a lot of growing pains and scalability challenges notwithstanding), a decent bit of Bitcoin money started flowing in to the coin. Some well-known and less well-known folks who'd made millions investing in Bitcoin started viewing Monero as an interesting high-risk hedge for a small percent of their Bitcoin holdings.

By May 16th, I'd squeezed about 90% of the optimizations out of it, and we were running 100x faster than the coin was at its initial release. That didn't stop me from obsessing about speed tweaks for the next week or so, but it gave me a little breathing room to start thinking about the next step.

The natural evolution of cryptocurrencies is that they start out being mined on CPUs, because that's easy. Then someone writes a GPU-optimized miner for them. The big ones jump to FPGA and then ASIC, though as far as the general community knows, only coins using SHA256d (Bitcoin and family) and scrypt (Litecoin, Dogecoin, etc.) have ASIC implementations.

So, why not take the next leap? We needed a GPU miner to keep ahead of the inevitable optimizations that others would release. In fact, the writing was already on the horizon -- NoodleDoodle had released another 2x speedup already, and was talking about getting an even bigger one out. It was only a matter of time until some of the dangerous experts in crypto started getting involved, and yvg1900 had been talking about developing a miner for Monero. The altcoin mining software world is small enough that there aren't too many people out there who can beat my optimizations without help, but yvg is one of them, and I knew that once he was in the game, before too long, I and everyone else would be running his code instead.

(And history showed that this was right - his final release beat my code by about 10%, and he was nice enough to share a few x86/Haswell micro-op optimization ideas with me.)

I've developed some GPU miner software as I blogged about earlier, but I'm not the best out there. Fortunately, in the process of doing so, I met some of the best. I dropped them a note, explained the opportunity, and they signed on. Pretty soon, we had in our arsenal not only a super-fast CPU miner, but also a great little GPU miner.

The beauty of having both was that it reduced our cost basis by a factor of two. While the GPU miner wasn't all that much faster than a CPU miner, due to the way pricing on the spot market often works out, you can rent a machine with a GPU for a similar price to one that only has a CPU. So within a few weeks, we were able to mine on both the GPU and CPU at the same time.

Which was fortunate, because that rock-in-my-guts May 28th incident rolled around sooner than I'd have ever guessed.

From what I can back-patch of it, my contact checked with another developer to see if there was room to further optimize my code on a contract basis. I don't know the details of that contact, so I won't speculate, but something somewhere went very wrong, and the other developer incorporated my optimizations into an open source release. Overnight, our edge started to disappear.

I gave up sleep for another night and eked out one last 5% performance boost to my code, but now we were really depending on having fast GPU code and on minimizing mining cost. We all spent some time benchmarking and running price/performance analyses about the types of instances available at Amazon, and reduced the cost a little through that. But then we got the GPU miner done, and, bogglingly, found ourselves back in business!

Things continued well for a week or two, until on June 4, another GPU developer, Claymore, released his own GPU miner -- but it targeted only AMD GPUs, and Amazon's were Nvidia. It was also more than 2x slower than ours -- three cheers for fast code. We held our breath waiting for an onslaught of new miners, but it never came. My best guess is that the newness of the Cryptonote software, as well as some difficulty getting it running because of a lot of dependencies on Boost and other libraries, scared a lot of people off and kept the technical barriers to entry high.

In the end, our game continued into July -- almost two months of mining at an advantage large enough to make a profit on Amazon. We spent over a quarter of a million dollars renting cloud compute time, to the point where I had a great phone call with the manager of the Spot instance program at Amazon who was trying to figure out how they could improve usability for weirdos like us.

It was a wild experience, and while I was, ahh, financially inconvenienced by the code leak, I'm also obliquely glad my optimizations made their way into the public (I'd have released them eventually, but hadn't planned on doing it quite so early). It's informative that throughout the many ways I've explored of getting paid to improve the state of the art in cryptocurrency software, the most profitable by over an order of magnitude was the most greedy approach of keeping the software entirely private. That's something the developers of future currencies should ponder -- it's probably worth up-front investment to pay someone to release an optimized CPU and GPU optimized miner for your coin, because if they're making a profit afterwords, it could be very hard to convince them to give up the margin.

25 lines mixing C, one instruction of inline assembly, and some AVX intrinsics -- one of the most fun, exciting, and profitable side projects I've ever been involved in. Like everything in crypto, it moved at the speed of light -- it was like launching and then folding up a small startup in the course of two months. And that's why I now have 6 high-end GPU mining rigs in my basement to heat the house through winter and some fun war stories about the importance of operational security and paying attention to low-level programming tricks in school.

(As a note: I make some positive statements about Monero in here, and I really do admire the technical advance it represents in anonymous cryptocurrencies. But please don't read anything I'm writing here as suggesting I think you should buy it -- I view all cryptocurrencies as exceptionally high risk, on a spectrum from "eek" to "stay the heck away!" There's an enormous amount of risk in all of the currencies, and while I talked about the technical positives of Monero here, it also has some very significant technical challenges. I don't personally own any, nor do I hold any Bitcoin - I mine and sell for the most part, to minimize my risk exposure.)


Why won't monerod.exe connect to daemon? I have tried the following to get monerod.exe to work:

placed all monero related folders in the exception section of my antivirus (AV originally quarantined and blocked several files)
removed monerod.exe from antivirus quarantine

please advise, thanks.

I solved the issue by connecting to a remote node.  I used the following as a guide.

How to connect to a remote node within GUI wallet:

[https://web.getmonero.org/resources/user-guides/remote_node_gui.html#:~:targetText=Connecting%20to%20the%20node%20from%20the%20GUI%20wallet&targetText=Click%20on%20it%2C%20and%20you,you%20want%20to%20connect%20to.][1]


Are RingCT signatures malleable? Can a RingCT signature of a transaction be slightly modified to create an equivalent transaction (same inputs, same outputs) with a different transaction id?

The transaction ID is based on the hash of everything in the transaction, and the MLSAGs sign everything in the transaction except the MLSAGs themselves.

Therefore, changing anything in the transaction will change the tx hash and thus the ID.


Is it feasible to introduce output key reuse checking? Reuse of output key P=H(rA)G+B (which effectively burns fund) could potentially occur if the same random r was used in multiple transactions to transfer fund to the same recipient (A,B), most likely due to the use of bad pseudorandom number generator. Is it feasible to introduce an additional checking step so that the second transfer reusing the same P simply gets bounced, pretty much like how key images are checked to prevent double-spend? I heard somewhere that output keys are stored in an array instead of a hash table; will this make the situation a lot harder than it is with key images?

P.S. This question arose in the context of the possibility of one-time receiving address, a nice bonus that provides privacy even outside the blockchain and can be easily implemented if this reuse checking is available.

Answered by smooth_xmr:

  We looked at this but it would add additional permanent overhead and reduce scalability to prevent what is essentially burning coins, which is silly. Someone who wants to burn coins can do so other ways.


What does 'dynamically scalable' mean? I heard this term being used in a monero promo video I saw on Reddit but don't know what it means. Something to do with the size of the blocks maybe?

The blocksize can automatically adjust over the course of time by the miners including more or less transactions than what has recently been the norm however they have to pay a penalty fee if they increase it by more than a certain distance from the median of recent blocks. I guess the idea is to let the market decide what the blocksize should be rather than have the kind of issues bitcoin is having right now.


Export the blockchain from database format to raw vs just moving the files What are the pros and cons of using the following command to export the Monero blockchain from a Linux OS to a flash drive?

  monero-blockchain-export --output-file /media/a/Transcend/

How does the export method above compare to the method below?

  just move the files (preferably your whole .bitmonero folder) and use the switch --data-dir usb/path/to/.bitmonero-folder when starting monerod.

Pros:

Fallback method which is sure to always work, as it is virtually the same as getting all the blockchain data you'd get from another node, but in one single file.
It's lighter because it doesn't have any overhead for indexing etc.
It can be appended to easily when new data is available.

Cons:

Slower, because the daemon needs to verify all the data, the same as it would do when getting blocks one by one from the connected nodes.
Also, if you keep both LMDB and the .raw on the same drive, the performance impact will be amplified as the same drive will be used for read/write and it can't do both operations at the same time.

In the past, the LMDB database format was not compatible across platforms. This is an optimized storage built with performance and robustness in mind, to allow the wallet to quickly access and use the data it needs.

On the other hand, the .raw file is "raw" as the name implies, meaning it should be platform-agnostic, ie, the data inside is the bare minimum, unoptimized, blockchain data, as it flies over the network, and nothing else. Think of it as just copying and pasting block data one on top of another and saving this into a file. The .raw file, then, is just a collection of all the blocks in the correct sequence.

When importing, the wallet needs to check it for consistency, by validating each block in the .raw file against concensus rules, because it can't know whether it had been constructed in the correct way, so it needs to check the signatures, PoW etc., unless you exported the .raw yourself or got it from a trusted source.


Does publishing view key and key images give the auditor the information on where I sent the funds? I see here that it's possible to provide information to an auditor to prove the balance at a certain point in time (block height). Would this tell the auditor to where were the funds were sent? Based on my understanding, the answer should be no - is it because the addresses themselves don't appear anywhere on the blockchain and stealth addresses are used?

Consequentially, is it correct to assert that if I lose my wallet file, I also lose the history of destination addresses? If I would later recover my wallet from keys (or seed) and re-scan the blockchain, I would be able to see only that the input has been spent, and the related payment ID of the tx, but not the address of the recipient, as it's not recorded on the blockchain due to stealth addresses being used as destination.

If the auditor wanted to confirm you had sent funds to a specific address, they'll then need to have the view key of that address also. The only thing the view key of your address can determine which outputs were sent to its corresponding public key. The key images can confirm when a transaction took place, and how much was was moved from your address. It can't verify who you sent it to, or who you received it from.


Can a 3 letter agency see if I am running Kovri? When Kovri comes out will a 3 letter agency see if I am running it?

It depends on where they're listening, but yes in the sense you probably mean.

The I2P protocol underlying Kovri has a signature like any other protocol, and anybody who can see all of your traffic can see that you're using I2P. I don't think I2P even tries to make that hard at all... and if it did there would still be limits to what it could do against a sophisticated adversary.

Corporate firewalls, ISP traffic statistics and quality of service equipment, and the like can also detect that you're using I2P if they care to look for it.

Like Tor, I2P mostly tries to hide what you're doing, rather than hiding that you're doing anything.


How Ed25519 curve relates to Borromean Ring Signature scheme? Is it correct to say that Monero private keys are generated using Ed25519 curve and then Borromean Ring Signature scheme is used to sign transactions?

In other words, is Ed25519 curve "compatible" with Borromean Ring Signature scheme?

Monero currently uses MLSAG ring signatures for the ring of possible outputs being spent.

Borromean ring signatures are currently used only for the 'range proofs' which demonstrate that output amount Pedersen commitments are not negative.

Later this year, the Borromean signatures for range proofs will be swapped out in favor of Bulletproofs, which are more compact. See https://github.com/AdamISZ/from0k2bp/blob/master/testzkp.pdf

It is correct that Monero keys are generated on the Ed25519 curve. Borromean ring signatures can be used with any cryptographically sound elliptic curve. Monero could have used a different elliptic curve too, but Twisted Edwards curves (e.g. Ed25519) are particularly efficient for performing certain types of point multiplication that are heavily used for Monero's existing signature verification algorithms (specifically a type of multiplication called doublescalarbasemult).


Monero Wallet GUI daemon version 0.16 stops syncing blockchain at block 2210016 both on Windows and Mac Please let me know if there is an option NOT to upgrade to V 0.17 of monero GUI wallet and continue using v 0.16. I need to run v 0.16 because I can not update firmware of my ledger nano s.

If you want to actually use Monero you will have to update to v0.17 (which Ledger also supports).


Connecting Kovri through a VPN vs using Kovri directly In terms of privacy and security what are the differences between to connecting Kovri through a VPN compared running Kovri directly?

Would home, business or VPS IP addresses be better protected if a VPN is used to connect Kovri?

Would VPNs be able to tell that someone is using Monero or that someone is using Kovri/I2P?

When using Kovri alone, the ISP/your employer/whoever is able to see that you are using Kovri, but not what you're doing on Kovri (e.g. using Monero).

When using Kovri with a VPN, the ISP will just be able to see that you're connecting to a VPN. However the VPN provider and their ISP will be able to see that you're connecting to Kovri.

Personally I think that it's better to use Kovri alone, but if you're feeling extra paranoid and want to use a VPN, the only harm would be some increased latency and decreased speeds.


How can I set a wallet to use no-coinbase mode before syncing? I am trying to configure a wallet to use refresh-type=no-coinbase. I am not entirely sure how to do this without waiting until it is done syncing.

As soon as I open ./monero-wallet-cli, it asks me to create a wallet and proceeds to sync with the blockchain. This is not especially helpful if a user wants to avoid these outputs before syncing.

I tried running the following:

./monero-wallet-cli --restore-deterministic-wallet --refresh-type=no-coinbase

./monero-wallet-cli --restore-deterministic-wallet --no-coinbase

Neither of these worked.

How can I configure the wallet software to accept an input to avoid scanning coinbase outputs before the wallet is already done syncing?

You can ^C while it's syncing in the foreground. The background refresh will take over while you are at the prompt.

^C while not in foreground syncing quits the wallet.


Monero blockchain usage after importing .raw file I am wondering how to use blockchain after conversion of the .raw file through blockchain-import. I already have a data.mdb file, but it seems like the new .raw file is bigger now, so I have to sync it again. It took 4 days to import the .raw file to .mdb. Is there any way to use GUI to sync the rest?

When I try to use the .mdb directory it starts syncing again from 0.

There's little reason to be downloading and importing the raw blockchain these days. Just running the daemon and letting it sync the blockchain is almost always the best approach. If for whatever reason you need to download and import the raw file instead, you should follow the guide.

Addressing some specific points in your question:

  It took 4 days to import .raw file

Then you are most likely using a spinning disk. The Monero blockchain is best suited to solid state drives. It will sync on spinning HDDs, but take longer. If you plan on keeping the node running 24/7, using a HDD is fine, because once synced, the slowness won't impact you. If however you are not going to keep your node running 24/7, you will certainly want to either have the blockchain on an SSD or use a remote node.

  Is there any way to use GUI to sync the rest?

It will do so automatically.

  When I try to use the .mdb directory it starts syncing again from 0?

If after importing a raw file, your daemon starts syncing from zero, you have something pointed at the wrong data dir. Note also there is a difference between syncing the blockchain and scanning the blockchain. If you are using the GUI after importing the blockchain, it will still need to scan the blockchain.


Syncing my full node - only connects to 1 peer So I get the following error while trying to sync my full node:

https://gyazo.com/fb60b6b862f08d95abbe702b85ec6be4

Basically it seems like I'm only connecting to one node, and rejecting all the others, this makes me worried that I'm syncing to the wrong chain. This is my first time running a full node, so I have no experience how to check if this is correct or not.

Edit: I just noticed I'm running v0.11.1.0. Which is not the latest one, no idea how I downloaded that version tbh, but I'm running v0.12.0.0 and I'm syncing smoothly.

As you have found, you need to run a v0.12 release (currently 0.12.1.0). So download the current release and sync. As @user3603 mentioned in the comment, 0.12.2.0 will be released very soon. You can still use the current release to sync and then update to 0.12.2.0 when that gets released (or just wait for 12.2).


What is the max no of input for Monero tx? How does it affect the no of decoys? Assume the ring size = 11.

If I have 1 input, 10 decoys are added. 1 key image.

If I have N input, 11 - N decoys are added. N key image.

Is the above statement true?

Does it mean that if the number of inputs increases, there is less privacy?

What is the max no of input for Monero tx?

The only restriction affecting the quantity of inputs a tx can include is the overall tx size maximum, 149.4kB [src].

  How does it affect the no of decoys?

Each input has its own ring. Thus for each input being spent there is the input itself, 10 decoys and 1 key image.

  Does it mean that if the number of inputs increases, there is less privacy?

No. See previous point.


How is Monero compared to Dash? There are 2 main privacy-centric Bitcoin-like payment blockchain and cryptocurrencies – Dash and Monero and are always being compared to one another.

What are their similarities and differences?

Dash uses a modified version of coinjoin to enable its users to mix their outputs with each other. Coinjoin was originally proposed by Gregory Maxwell, and has been available for use in Bitcoin for some time.
There are a number of services which connect Bitcoin users looking to mix their outputs, the most popular of these being JoinMarket.

Dash's privacy feature, called PrivateSend, is a series of chained coinjoins. To use PrivateSend, you must first allow the Dash client to "mix" your coins. Once this feature is enabled by a user, the client will start looking for other users with whom to mix. Depending on the number of "rounds" selected, this process can take anywhere from half an hour to several hours.

Each round refers to an individual coinjoin with at least 2 other users.  These individual coinjoins are then chained, which simply means that multiple coinjoins are performed one after another, ideally with different users participating in each coinjoin. According to the Dash developers, a higher number of PrivateSend rounds increases the privacy of a user's transactions.

PrivateSend does have a potentially serious flaw. Each coinjoin requires a server to facilitate the mixing. This requires users to trust that the server is not recording details on where each user's outputs are ending up. Dash attempts to mitigate this risk by using what they call "masternodes".  Masternodes are the servers which coordinate PrivateSend. These masternodes require a deposit of 1000 Dash to run. In theory, this collateral prevents someone from creating an arbitrary number of nodes for the purpose of recording coinjoin details.

Does this really mitigate the risk of coinjoin details being recorded, enabling transactions to be traced? Not reliably. The reality is that the majority of masternodes are hosted by a small number of VPS providers. These VPS providers could easily record the transactions being facilitated  by any masternode that they host.

Monero uses a cryptographic primitive called ring signatures. As implemented in Monero, a ring signature joins a user's transaction with other transactions, such that an observer can not tell which transaction in the ring is the "real" one. These other transactions do not need to occur simultaneously with the one that a user wishes to create. Monero can use any transaction in the blockchain as a participant in a new ring, assuming the correct outputs are present.

This is superior to coinjoin for a number of reasons. First, there is no need to trust a mixing server. Valid transactions are created by a user's client and then submitted to the network. Second, the privacy afforded by Monero is ensured through cryptography. Ring signatures have gone through decades of peer review in academic journals. This is time tested cryptography, which means a significantly higher degree of reliability.

Finally, Monero is one of very few cryptocurrencies which have actual cryptographers working on them. If you visit the Monero Research Labs page on Monero's website, you can view some of the research that has been published. These cryptographers are actively working on identifying and correcting any flaws in Monero.


How to generate integrated addresses without a node? I am working on a Monero invoice solution for a client, and I would like to use integrated addresses to allow the client to reconcile payments. It's cost prohibitive to run a private node just to generate these addresses. Is there a JS library for generating an integrated address?

You do not need a node to generate an integrated address.
You only need the monero-wallet-rpc and call the appropriate method.

Edit: but you should also look at the subaddresses which are designed for the same purpose and will be available for a longer time.

Btw, how do you expect to confirm payment without a node?
A remote node does not seems trustworthy for such use case.


CPU getting more hash than GPU I have Intel Xeon CPU E3-1271 v3 @ 3.60 GHz and a Nvidia Quadro K620 GPU. Windows 7 SP1 OS.

xmr-stak-cpu is giving a hashrate of more than 300 H/s on the CPU.

Whereas xmr-stak-nvidia is giving hashrate of 111.5 H/s on the GPU.

With null gpu_threads_conf, the xmr-stak-nvidia miner gave me following suggestion:

"gpu_threads_conf" : [
{ "index" : 0,
"threads" : 64, "blocks" : 9,
"bfactor" : 6, "bsleep" : 25,
"affine_to_cpu" : false,
},
],

When I run the miner with this configuration, the miner crashes and following error pops: nvidia graphics driver stopped responding and has recovered

Then I tuned the parameters. Following is working:
"threads" : 64, "blocks" : 6

Also, threads-32, blocks-12;
threads-16, blocks-27,24
give same hashrate

and I'm getting hashrate of 111.5 H/s in the miner.

Is this expected? What can I do?

According to these benchmarks, K620 is supose to get around 120 H/s

http://monerobenchmarks.info/ (threads 32, block 6s)

Also XEON E3-1271 gets 338 H/s

So yes, its probably correct. But you can always tweak it a little bit.


Does mining use a lot of bandwidth? If I setup a mining rig, will this use a lot of internet bandwidth? Do you know how many MB per day would be required? Is there a difference for mining pools and solo mining?

Solo mining requires running a full node, pool mining does not. Also, when solo mining, it will usually take much longer to find a block when compared to a pool. Pools do charge a fee, normally 1-2% of the block reward.

When pool mining on a Windows PC, I use less than 20 Mb/day download and less than 5 Mb/day upload. Solo mining will be more bandwidth intensive due to running a full node.


Is the communication between wallet and remote node encrypted? If I understand it correctly, the wallet provides the remote node with view keys so it can find the corresponding outputs, and later the wallet may also send a signed transaction for the remote node to broadcast.

Can someone listening to the communication gain access to the view keys and the transaction information, or is that communication encrypted?

No, the wallet does not provide the remote node with the view keys. I think you are confusing this with the web wallet MyMonero which requires the view key.

The only thing that the remote node will know about you is your IP Address.

Edit: The remote node will also know what are your mixins, so best to keep changing remote nodes.

Edit: To answer your additional questions.

The connection between remote node and client (GUI or CLI) does NOT add encryption from what I read. However, the actual transactions which you broadcast your transfers are signed already by your keys - so already encrypted.

Furthermore, when connected to a remote node you have to read all transactions because on your client side you have to check if the transaction is yours. This will take some time that uses network and cpu resources.

Lastly, the remote node is useful since it alleviates the bandwidth usage  and time to synchronize with other peers in the network.

Here is some additional information that talks about what information are sent and received from the daemon (this is also applicable to a remote node)

How much information is passed from the daemon to simplewallet when scanning for a wallet's transactions?
Is it safe to share a daemon with a roommate?


allow access to the daemon for everyone I want to make my daemon accessible to anyone, is there an additional command besides this?

--confirm-external-bind

--rpc-access-control-origins

are there other additions that I have to use?
the example of the daemon I run on my vm with the address 12.325.25.3

To allow inbound connections to the daemon p2p and the RPC (assuming default ports are used), you would need:

--rpc-bind-ip 0.0.0.0
--confirm-external-bind

And ensure your firewall allows inbound connections on ports 18080 and 18081.

If you are behind a router, that would also need configuring to forward traffic on those ports to your machine running the daemon.

Note, you may also want to add the login option for the RPC:

--rpc-login arg                       Specify username[:password] required
                                      for RPC server

And if you want to allow javascript access:

--rpc-access-control-origins arg      Specify a comma separated list of
                                      origins to allow cross origin resource
                                      sharing


Decrypting payment Id of integrated address I am using monero-nodejs liberary for rpc calls. I generated an integrated address and made a payment to this address.

By splitting the integrated address, I could see the paymentId is a33582a5a77c125b.

But when I check payments of this address, I get nothing (empty object)

Wallet.getPayments(req.params.id)

Do I need any decoding on this paymentId? I can see the tx mined.

MyMonero provides a useful JavaScript library (mymonero-core-js) for dealing with this sort of thing.

Here is a code snippet that shows how to encrypt/decrypt a payment id using this bit of code from mymonero-core-js.

const mm = require('mymonero-core-js').monero_utils

const viewKey = mm.random_keypair()
const txKey = mm.random_keypair()
const paymentId = 'badc0ffeefabcafe'

const INTEGRATED_ID_SIZE = 8
const ENCRYPTED_PAYMENT_ID_TAIL = 0x8d

// If you have the private tx key and public view key
const pidKey = mm.cn_fast_hash(
  mm.generate_key_derivation(viewKey.pub, txKey.sec) +
  ENCRYPTED_PAYMENT_ID_TAIL.toString(16)
).slice(0, INTEGRATED_ID_SIZE * 2)

// If you have the private view key and public tx key
const pidKey2 = mm.cn_fast_hash(
  mm.generate_key_derivation(txKey.pub, viewKey.sec) +
  ENCRYPTED_PAYMENT_ID_TAIL.toString(16)
).slice(0, INTEGRATED_ID_SIZE * 2)

// Assert that the pidKeys are equal
console.log((pidKey === pidKey2)
  ? 'pidKeys are equal (expected)'
  : 'pidKeys are not equal (unexpected)')

// Encrypt Payment ID
const encryptedPaymentId = mm.hex_xor(paymentId, pidKey)
console.log('Encrypted: ' + encryptedPaymentId)

// Decrypt Payment ID
const decryptedPaymentId = mm.hex_xor(encryptedPaymentId, pidKey)
console.log('Decrypted: ' + decryptedPaymentId)

// Assert that the original and decrypted payment ids are equal
console.log((decryptedPaymentId === paymentId)
  ? 'Successful Decryption!'
  : 'Unsuccessful Decryption')

Should provide an output similar to:

pidKeys are equal (expected)
Encrypted: cfc3f2120b7db7c0
Decrypted: badc0ffeefabcafe
Successful Decryption!

Hope this helps!


Is the payment ID the equivalent of the op_return in bitcoin? Many devs use the op_return in Bitcoin to store some arbitrary data. In Monero, is the payment ID the equivalent?

Arbitrary data can be stored in the extra field in a Monero transaction. The payment ID uses the extra field, and is often used as a container for arbitrary data, because it is easy to use. However, it is (1) limited in size and (2) sometimes required by the recipient. For more flexible use, having a custom field in extra seems best. However, this will require the sender and recipient (or sender and the target population at large) to agree on the semantics of that extra data in the first place, so that it can be parsed and understood. The amount of data which can be placed in the extra field is limited by the maximum block size.


How to interpret the output from the 'print_ring' command in monero-wallet-cli? My objective is to identify the true input of a transaction as the spender.

Simply keeping track of transaction hashes, in which I am the receiver, does not seem to help, as my own coin can be included in a ring as a decoy in other transactions.

I tried using the print_ring <tx_id> command in monero-wallet-cli, but am having trouble interpreting the results, which look as follows:

f6755e91a53485ddcaa7b1aa2132b101cedfdd32928780ba13c56aefff08dea9 absolute 17100 21558 25253 28804 28854 28932 28981 29049 29272 29292 29341
915a22c9e3047a26305541c25ed1113f47ac90f9f3dba7a8578ad3ff06323fe7 absolute 11992 20083 21404 22989 24068 28325 28717 28860 29098 29132 29176

How can I use this information to discern the true input of the transaction?

How can I use this information to discern the true input of the transaction?

You can't. The output format for print_ring is:

K absolute N,N,...,N
...

Where K is the key image hex and each N is an absolute global output index of an output possibly being spent (e.g. a ring member). Each row represents an input of the tx.

This does not tell you which output is the real spend output.

You can use the cli command incoming_transfers uses to see the global index and uses of each of your owned outputs.


Does monero-gui 14.0 still work? Is Monero 14.0 still operable on Macbook Pro? I can't sign in. I have OS 10.10.5.  Is there an update that is compatible with my system?

I assume you mean 0.14.0.x. If so, it will continue syncing part of the chain only. To sync the entirety of the chain, you need at least 0.16.x.y, but 0.17.x.y is strongly recommended, since in about a month (mid october 2020), 0.16.x.y will stop syncing too.
The 0.17.x.y daemon is available on getmonero.org as binaries for Mac if needed.


How do I operate the Monero GUI as a 'cold' wallet from an air-gapped computer? How do I operate the Monero GUI as a 'cold' wallet from an air-gapped computer, especially in the context of validating a send transaction created from a hot wallet? I've read the other Q&As on this subject but I only saw ones that are for the CLI, not the GUI. I poked around the 'Send' tab but didn't see any options, so I just sent it out as a regular transaction while in 'Simple' mode. Is using a hardware wallet with the Monero GUI that is connected to the network considered 'cold' enough since the hardware device is holding the private spend key? Is there even a way to run the Monero GUI without it connecting to the network?

***UPDATE
I read the other question posted as possibly similar but it doesn't address the airgapped computer aspect of my question so I'll ask it again, in a slightly different way:

Can the Monero GUI run in an airgapped computer without connecting to the network? From what I understand, all three modes (Simple, Simple+Bootstrap, and Advanced) need to connect to the network.

I read the other question posted as possibly similar but it doesn't address the airgapped computer aspect of my question

An air-gapped computer cold signs. That's the point here.

  Can the Monero GUI run in an airgapped computer without connecting to the network?

Yes. This is cold signing. Cold as in "not connected to the internet".

  From what I understand, all three modes (Simple, Simple+Bootstrap, and Advanced) need to connect to the network.

No. The official wallets (GUI and command-line), both support cold signing transactions. In the GUI version, you have to use the wallet in "advanced" mode. They do not need to be connected to the internet/network to do this.

Annotating/expanding the duplicate questions answer for you:

First create your offline cold wallet, in the GUI, on your offline (air-gapped) computer. Use "advanced mode". Cold-signing transactions is after all an "advanced" thing to be doing.

  Create a view only wallet (settings page)

You do this on your offline (air-gapped) computer.

  Open view wallet and create a transfer, save with "Save tx" button

You do this on your online computer.

  In original wallet, click "Sign tx" on send page and select the file

You do this on your offline (air-gapped) computer.

  in view wallet, click "Submit tx" and select the signed tx file

You do this on your online computer.


What is the current supply of wownero as of 2018-08-01 What is the current supply of wownero and mining reward?

As of 2018-08-01, circulating supply is around 6 million out of a total of about 184 million, which will be emitted over the course of 50 years with no tail emission after depletion.

The block reward is about 170 WOW.


Why are all build statuses on Monero's Github failing? Should I use a Debian distro with an armv8 architecture if I am looking for stability?

The main reason is that the crypto tests include a set of expected values from the pseudo random number generator, which was recently changed to remove a tiny bias, thereby changing the returned values. A patch which was supposed to update the values did not actually fix it, and another needs to be made instead.

The Windows platforms were also broken for a couple days near your post's date when the block/tx notifications went in as they tried to build the POSIX code.

At least one of the ARM build machines is also missing some necessary libraries and needs updating.


What other cryptocurrency has implemented the RandomX PoW for mining? With the move to RandomX for PoW mining on Monero, what other coins have forked RandomX into their coin? I know Loki has done it with RandomXL but have any others implemented it?

Wownero and Loki are the only other currencies I know of that plan on, or are currently implementing, variants of RandomX.


Internet access lost due to DNS problems every time monerod starts Every time I start monerod.exe on my Win 10 x64 machine, every device connecting to the same router loses internet connection. Even the notebook (MS Surface Pro 4) running monerod loses connection to DNS servers, and nothing has a connection except for monerod. Internet browsers return the error message: "DNS address could not be found." After stopping monerod, I also have to restart the router so that internet services recover. It also does not matter how much I restrict the traffic. This is way below the bandwidth we have at home, and it still kills internet in the whole household:

monerod --limit-rate-down=300 --limit-rate-up=10 --out-peers=1

Erdogan posted something similar but probably not the same, since his internet connection recovers after stopping monerod, whereas I need to restart the router. Anyway, solutions suggested to him did not work for me.

Any help is much appreciated.

You might want to try adding --no-igd and see if that helps.

Another thing to try is to run with the environment variable DNS_PUBLIC=tcp.

In any case, it looks like a bug in your router.


What cryptography primitives/concepts, other than the basic ones, does Monero use? The following are the "basic" cryptography primitives/concepts, taught in all beginner textbooks on cryptography:

symmetric encryption (stream and block ciphers. AES, etc.)
asymmetric public-key encryption (RSA, elliptic curves, discrete logarithm)
digital signatures
hash functions
MACs
key establishment

Can you list all the cryptography primitives/concepts used by Monero that are not taught in these beginner textbooks? I already know of two:

Ring signatures
CryptoNight

What are all the others?

Pedersen Commitments and Range Proofs

See https://people.xiph.org/~greg/confidential_values.txt