Error: not enough outputs for specified ring size = 11

You are trying to find 10 outputs on the blockchain other than your own with the same amount, so they can all be put in a ring. Your daemon is telling you it could not find that many. Not surprising if you start with a fresh chain. Use a smaller ring size.


Monero GUI: How do I switch back to my Ledger Nano S wallet from my original wallet

Wow, I'm dumb.

If anyone else out there is having this problem (Switching between Monero Wallets)

Want to unlock a different Wallet? Follow these steps:

Open Monero GUI
Click cancel instead of entering password.
Choose Language
Click "Open a wallet from file"
File Explorer window opens (Windows)
Choose the Destination where keys are saved (Default: This PC> Documents>
Monero> Wallets)
Open desired Wallet folder
Select .keys file
Press Open
Enter Password


Generate a integrated address using a subaddress

It was decided that there should not be such a thing as an integrated subaddress. Only your main Monero address can become an integrated address (this functionality is retained for backwards compatibility).

The reason for this is that integrated addresses stand out on the blockchain. It is possible to see the difference between a payment sent to a standard Monero address vs an integrated address. This is because when an integrated address is used, an encrypted payment id appears in the "tx_extra" part of the transaction, and that makes the transaction stand out.

Since you can create as many subaddresses as you want, you can create an entire subaddress just for a particular sender. This means that you don't need to rely on a special payment id to identify the sender, because your wallet is able to correlate funds received to the subaddresses that you have given out.


RingCT migration to Borromean Ring Signatures and testing

Sadly, most people will not help test on testnet. The changes pass all tests, and some low volume of transactions is flowing. The kind of bug that was found by RandomRun isn't a type of bug that can be detected by tests, however, unless you know the bug in the first place. The fork can't really be avoided now, it'd require a very quick update by pools, exchanges, and other important nodes, beyond the time needed to fix anything.


Why does the block reward have multiple inputs?

The coinbase transaction has a single placeholder input - one of special type, unlike the usual "from key" inputs you see on other transactions.

The log you supplied shows only outputs. A coinbase transaction may have more than one output, since before rct outputs were split by denomination in order to make ring signatures work better. If this had not been done, and since coinbase transactions give idiosyncratic amounts, most of those outputs would otherwise not be able to sign with other outputs, since they'd be the only one of that amount of the chain (or at least among a very small group).

On current Monero, this is no longer the case. RingCT allows any rct output to sign with any other, and coinbase outputs are internally handled as rct, with a hardcoded mask, allowing them to masquerade as rct outputs. Thus, current coinbase outputs can have idiosyncratic amounts while still being able to sign with other rct outputs.


Hangs on "Forking to background..." ( `monero-gui-v0.13.0.3` on Ubuntu 18.04 LTS )

When a process hangs, you can use gdb to work out where it is hanging:

  gdb /path/to/binary PID

Replace /path/to/binary with the filename (and path if needed) of the binary you're running, and PID with the PID of the running process (you can get it via ps).

Then, when in gdb:

  thread apply all bt

This will print a list of all the threads and what they are doing. If any of those threads are stuck somewhere, this should expose it.


Hash rate of CPU is the same as that of GPU

If you expect the GPU to be much faster, your question may be answered here: Is it better to mine with a CPU or GPU

Your numbers sound reasonable for the CPU, and mostly consistent with reported numbers for the GPU. That said, I've got a bit better performance out of XMR-Stak than ccminer on my GTX 950 card. I also made a test of numerous configurations for blocks and threads for my card, and there are certainly numerous settings that will cause it to underperform.

I am running XMR-Stak-CPU and XMR-Stak-NVIDIA, and can share my rates for some of the workers for comparison if that's any help.

AMD FX-6300 Six-Core Processor   : 274 H/s
  > low_power_mode on 1/6 cores

NVIDIA GeForce GTX 950           : 251 H/s
  > 32 threads x 18 blocks

Intel i7-7700K @ 4.20GHz         : 340 H/s
  > low_power_mode on 0/4 cores

2 x Intel Xeon E5-2620 @ 2.00GHz : 288 H/s
  > low_power_mode on 2/12 cores

I run all of these on headless Linux, mostly Ubuntu 16.04, and with the latest CUDA.


Number of outputs in each RingCT transaction

The most common scenario is for a transaction to have an output going to the destination, and an output for change going back to the sender. Since the amounts are masked, there is no need to split them into several outputs by denominations as Cryptonote does.

If sending to multiple addresses at once, a transaction will have more than two outputs.

If there is no change, a dummy zero amount change is generated and sent to a random address, so a one output transaction is not possible right now (but the consensus will allow it).


How can I generate the blockhashing blob for my Python miner?

Step #1 in this answer details how to get a blockhashing_blob.

If you plan on creating it yourself instead, this is much more involved. You would have to deserialize the blocktemplate_blob, calculate the merkle tree root hash for the blocks transactions (including a newly constructed coinbase transaction), then concatenate the block header, merkle tree root hash and transaction count (as a varint). That would get you a manually constructed blockhashing_blob. Doing this in just Python will be a big task.

It's worth noting, a pool-compatible miner doesn't need to create a hashing blob as the pool gives the miner the blob to hash.


How to mining on Ubuntu 18.04 with AMD cards

With the latest Radeon AMD driver, and programs like xmr-stak or cast_xmr, is easy to mine Monero with AMD GPU cards under Ubuntu 18.04.

References:

AMD Radeon Linux driver - https://www.amd.com/en/support

XMR-stak - https://github.com/xmr-stak

Cast_XMR - https://github.com/glph3k/cast_xmr


Monero wallet doesn't connect to local daemon

I have removed the folder lmdb from .bitmonero directory, then I started again the daemon and synced the blockchain. All works fine now and the wallet (monero-wallet-cli) can easily connect to the daemon through the LAN.


Jwinterm's answer is more an answer to this question, which asked how transaction fees will be calculated after Ring CT. The answer to your question can be found in the Ring CT whitepaper. More specifically in section 4.3, which states:

  As Monero is strongly decentralized (i.e. proof of work) it is necessary to pay miners a transaction fee for each transaction. This helps with the network security to prevent blockchain bloat. These fees must be paid "unmasked", i.e., just as bH, rather than xG + bH, and for some standardized amount b so that the miner can verify that b · H = bH and thus there is enough money for the transaction fee while still having the equations in terms of H so the necessary relations of section 4 hold.


After a fork, if a user opens an incompatible GUI/CLI, what information is presented to the user which says they are using old software?

When starting the daemon, monerod, or one of the command line wallets (monero-wallet-cli, monero-wallet-rpc), if you are running an old version, it prints a warning message telling you an update is needed. It's worth noting that it does this by checking your blockchain height against the hard-coded fork heights, not by calling some remote update server.

I'm not as familiar with the GUI, but presumably it warns you also.


Meaning of monerod status command output

v1 means the blockchain is currently at version 1. v7 means it's at version 7. If the blockchain is syncing (as shown by monerod telling you it's currently 79 days behind), it'll show the version at the point it's reached so far. At this time, the network should be at version 7.

The "peer claims higher version that we think" message is telling you that a peer on the network is running a later version. Normally, this means that the Monero network updated, and you will need to also update your software in order to be able to sync past that point. However, since the current version on stagenet is v7, it looks like it's just someone having made local modifications, making your node see the new version and thinking it's late, where in fact it's not.

"8(out)+0(in) connections" tells you the number of peer to peer connections your node currently has, sorted by whether your node initiated them, or whether a peer initiated them. If the second number is 0, it mean peers cannot find your node, so your connections to the Monero network is more fragile. You may want to check your router and/or firewall to allow peers to connect to the P2P port (in this case, for stagenet, it is 38081, and it'd be 18081 for mainnet).


The keccak1600 function used by Monero is based on Keccak-256 (b=1600, c=512, r=1088 and output of 256 bits, not 1600 bits), but it returns the whole internal state (1600 bits) instead of the first 256 bits of the internal state.

The "squeezing phase" present in Keccak.py doesn't appear in Monero's keccak.c file because in this particular case it has no effect.

The reason why there are two places where the keccakf function is called is because in monero's keccak.c, most of the message is hashed in the for loop (first keccakf), then the remaining bytes of the message are padded and hashed (second keccakf).

In mininero's Keccak.py, the message is padded first, then the padded message is hashed completely (first keccakf in the for loop). The second keccakf (in the "squeezing phase") will never be called given the parameters used for monero (n = 256, r = 1088).


Yes, it's possible.
In theory, the person spending it could choose which to spend. This is possible because outputs are referenced by block height & index so even if one-time public key is the same, you could specify one or the other. You won't be allowed to spend the same key twice, because it will have the same key image, but you could pick which one to spend. All other instances of the same key would be burned. In practice, the one picked by the wallet output-picking algorithm. Also, example of what can happen if key image check has a flaw.

  (If this appears to be a vulnerability, requiring the TX-public-key (R) to be unique might resolve this)

That wouldn't resolve it. In fact, you could entirely omit the TX-public key but then you'd have to find some other way of communicating the shared secret to your recipient. Protocol enforces only what happens between outputs (one-time public keys). The sender could announce his TX key anywhere, it doesn't have to be the blockchain but it's a practical way of not losing it, and with it the possibility to recover the funds should the TX key be lost. To understand why, see Stealth addresses: where do they come from?

On a second thought, even if you copied existing P, the receiving wallet wouldn't even see it unless you copied the TX key R as well. The wallet could in theory spend it in place of the other, but in practice it wouldn't even see it. So yeah, requiring the TX key to be unique would resolve it but IMO it would be better to enforce outputs to be unique since we don't put any restriction on TX key R as it is not fundamental - it's just a secret message really.


What's the difference between the CryptoNightR and RandomX algorithms?

Quoting SChernykh (one of the CryptonightR authors):

  CryptonightR is a modification to Cryptonight whereas RandomX is done completely from scratch. The main purpose of CryptonightR is to be the next PoW for Monero until RandomX is ready.

Which leads to why RandomX needs more auditing/testing. RandomX is a completely new PoW algorithm, not just a modified version of CryptoNight.

There is also the question/issue remaining of what can be done with RandomX in regards to GPU mining.


Set up your own pool on one machine and run a standalone miner on others (xmr-stak-cpu for example). This way you combine the hashing power and get the mined rewards for yourself.


What will make Monero scale up and get Mass adoption?

For mass adoption, we certainly need a simple way (official GUI) to use Monero, since the average user will not be able to run the CLI. It would be also great to see some mobile wallets (with private key control) to adopt Monero. But I am sure, we will see this in the near future.

Most Bitcoin users think that they are anonymous, but law enforcement and some startups are already analysing the blockchain and try to deanonymise step by step. When more people become aware, that they are not anonymous with Bitcoin, they will probably look for alternatives. The first step are tumblers, but you have to trust them and I am not aware of a single tumbler, that is run by a trusted entity. So if they get to know a better alternative, they probably will find Monero.

The whole Monero community can help by spreading the word about the most private and anonymous cryptocurrency available.

However, it is still a long way to mass adoption. First, there will be some speculants joining and causing price fluctuation. The average user wants stability, not speculation and fear of loosing money.


Is it possible to integrate anti-keylogger in monero wallet?

No. A keylogger can run on your keyboard's firmware, or in your computer's BIOS, or as a rootkit. In fact, a sophisticated attacker doesn't even need to drop a keylogger on your computer, they just need a device that is within range of your wifi network and they can detect your keypresses based on how they interfere with the wifi signal.

The answer is not to try defeat keyloggers, it's to use some form of 2FA, which in cryptocurrencies normally comes in the form of a hardware wallet such as Trezor, Ledger, or Keepkey.


Use the transaction ID/hash/number. It should look something like this:

c6ad90452a1c62171522484a3d8c8585d6461f544c6c44933850b90f76745895

Paste yours in a block explorer. I highly suggest xmrchain.net.

If it doesn't return anything, the block explorer is down/out of sync (unlikely), or your transaction did not go through. Contact the first exchange (Binance) and ask them to confirm they actually sent your transaction.


How can i sweep out a whole wallet to another address?

sweep_all sends all outputs to the address you specify.

However, 0.003315200000 is smaller than the smallest fee, so it is not actually spendable by itself, you'd need other outputs to increase the total so that minimum fee can be paid.


The problem may be that CryptoNight is a memory-intensive PoW algorithm.  For effective mining, you need 2MB of L3 cache per core.

Here's an interesting answer describing CryptoNight.


If I re-sync the blockchain will I lose my coins and wallet address?

No, you will not lose coins nor address.

The blockchain does not contain your keys. It's a copy of a distributed live data structure. Your wallet keys (from which your address is derived) are stored separately, and are used to scan the blockchain, but are not part of it. They're stored in the <wallet-name>.keys file (which can be recreated using the 25 word mnemonic seed which you carefully saved when you created the wallet).

But you might not need to resync the chain: maybe running monerod with --db-salvage will fix it. No guarantee, but it sometimes gets it back in a good state.


Monero RPC get_transfer by php monero-integrations

Per the documentation:
get_transfers
Look up transfers

Parameters:

$input_types <Array> Array of transfer type strings; possible values include 'all', 'in', 'out', 'pending', 'failed', and 'pool' (optional)
$account_index <number> Index of account to look (optional)
$subaddr_indices <String> Comma-separated list of subaddress indices to look up (optional)
$min_height <number> Minimum block height to use when looking up (optional)
$max_height <number> Maximum block height to use when looking up (optional)

So it should be:
$walletRPC->get_transfers(['in'], 0, "7");

to fetch incoming transfers for account index 0, subaddress index 7.


Will there be a January hard-fork for RingCT?

From the Monero website:

  Note that the v4 hard fork has been moved to the beginning of January, 2017, although the v5 hard fork remains set at September, 2017. This is to enable early availability of RingCT transactions on the Monero network, although they will not be enforced as the only possible transaction type until the v5 hard fork.

The hard fork in January 2017 will contain all the improvements for Monero up to that point, but the largest one by far will be RingCT.
There will be no March hard fork. The v5 hard fork will still be in September 2017.


Why Monero block time found reported by pool is always different from explorer timestamp?

You did not mention which pool or block explorer you are using but the answer is likely related to two things:

Time zone reported by the pool or explorer explains the 19:xx vs 21:xx two hour difference in your example.
Each pool and Block explorer uses a different node. Depending on which peers a node is connected to and network latency there can be a small difference between when blocks are reported.


What stops testnet & stagenet coins from acquiring monetary value?

I'd say they do have some value. For example, it's useful to be able to get hold of some stagenet coins in order to do some testing. Ultimately, someone had to mine some blocks to generate those coins, so I'd be willing to pay a tiny amount to acquire some stagenet coins, in order to save me the time and trouble of mining them myself. Luckily, it's so cheap to mine the coins that people give them away for free out of kindness.

The warnings on the first link in your post are mostly to prevent people from being conned into buying stagenet coins for the same price as mainnet coins. They're obviously not the same thing and don't have the same value.

It's possible that people could collectively decide to "reset" the testnets and stagenets that are available by wiping the blockchain clean and starting with a new genesis block. But that's not the main reason that stagenet/testnet coins do not have significant value.


There isn't a lifetime effective ASIC resistant algorithm. ASIC chips are custom manufactured computing devices specifically designed for a particular hashing algorithm. So, after an ASIC device is made to compute the hashing algorithm, you need to fork and change the mining algorithm so that ASICs tailored to the old algorithm can no longer mine effectively.

Monero issues regularly scheduled hard-forks, which are upgrades to the Monero network and prevent ASIC devices to mine Monero coins.


Can I spend from multiple wallets in a single transaction?

Although it is not possible with any current wallet implementation that I know of, it is certainly technically possible to write your own code to construct a transaction that spends outputs that span multiple wallets.

This is because each output has a unique private key, and if you know the output private keys for a set of inputs it does not matter at all what wallet addresses those outputs were sent to.


What is the minimum length of Payment ID?

I'm pretty sure the payment id can be shorter, and it is simply padded if it's too short. That said it shouldn't matter too much as it is encrypted so only the sender and receiver knows the contents.


Also how can one wallet have 2 private keys with 1 mneomonic

Monero uses two key pairs, view and spend. So there is a private view key, a public view key, a private spend key and a public spend key. When restoring from a seed (which is a recovery key), the private view and spend keys are then derived from the recovery key.

let kp = monero::util::key::KeyPair{view: private_key, spend: private_key};

Your code is incorrect as it is trying to set both view and spend the private keys to the same value. They should be different.


Is it possible to mine on your CPU and GPU at the same time?


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.


Can a transaction signed by a cold wallet be broadcast sometime far in the future?

It is possible but would likely fail, I wouldn't do this. Not only can transaction fees change as you mentioned, but so can the transaction protocol. If a new transaction field is made mandatory, then your transaction would be rejected by the network. The longer you wait the greater the chance it will fail.

My only suggestion is to use the (2,3) Shamir's Secret Sharing scheme on the signer's private key, so a transaction can be signed when two people agree on decrypting the private key. This isn't the same or as secure as multi-sig, but for your use case it seems reasonable.


How to build MyMonero wallet for Windows?

The MyMonero desktop app is built with Electron. To build it you need to install NodeJS and NPM.

After installing Node, download the source code from GitHub, open command prompt and go to the directory containing the source code, run npm install to grab the dependencies and then npm start to launch the program.


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.


Clarification with cryptonote-utils BEGIN_SERIALIZE() macros

Those marcos were written by a Russian who had too much vodka =). I have done C++ since I was 11 and I needed two hours to make sense of what they do.

First of all they are generic. They are used thought the code, and the resulting structures can be converted to a binary (network) format or json, so what you are doing here is only setting out the names of the fields and what you want the serialiser to spit out.

I don't understand how that order is defined?

Unless you create a data structure, it will just be a dictionary (key-value list) in the order of the macros.

Is the tag name important?

It will be the key in the dictionary. By default it will be the variable name in the code, but you can set it to something else.

I am also not quite sure when to use BEGIN_SERIALIZE_OBJECT vs BEGIN_SERIALIZE

Unless you know what you are doing use BEGIN_SERIALIZE_OBJECT


How is the number of ring members selected?

Ring size is currently fixed to 11 (10 decoys).

It's defined at a protocol level, so no transaction will be accepted by the network from a wallet not sending transactions with ring size 11.

For reference, this was implemented in this commit.

Credit to @dEBRUYNE♦ and @user36303 for spurring me on to finding it in the code!


Cryptonote SHA3 bigger than 64byte? (Scratchpad Initialization)

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).


monero blocks /min , too many, should be just 1 every 2 min

There has just been a fork. Not everyone updated before or just after the fork. Difficulty adjustment algorithm not settled yet to reflect. Block times, as a result are not yet smoothed out to the ideal time of 2 minutes. It will settle, just be patient.


https://stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory reports L2 cache access to about 3 to 5.3 ns. We'll use 5 ns to be conservative. 2 million accesses get you 0.01 seconds, so about 100 times a second. That does not leave much for the rest, granted, but is not obviously wrong.

Second, your calculation is wrong: 200e6 accesses per second yield an access time of 5 nanoseconds (1 / 200e6 = 5e-9). This is in line with the paragraph above.

Last, the hash rate shown by miner programs is the number of hashes done per second (may be a sliding window average).


In what ways can a wallet connected to a malicious remote node be abused?

If we want to run wallets against potentially adversarial remote nodes, what problems can we run into?
I'm interested in both points addressing privacy and opsec, as well as technical challenges related to consuming potentially malicious data.

There are two categories of risks with malicious nodes. The first, most dangerous type of risks are the permanent ones which can't be undone. Temporary risks can be canceled once a legit node is used to replace the malicious one.
Permanent Risks

IP Logging: The data you leak when connected to a node contains among others your IP. This IP is a form of identity which criminals can exploit to target victims (thefts, ransoms, blackmail, ...), authorities can use to list Monero users (identify, surveil, arrest, ...), ISPs can monetise to charge extra fees (which can be performed regardless of the nodes nature) and other consequences associated with the knowledge of a physical person using Monero. As this risk is real and permanent, Monero is developing a cross-cryptocurrency solution called Kovri which solves this problem. Recently a wallet has been caught inserting a second transaction fee as funding system for their software which was a massive breach of privacy. Using the attack vector exposed in that article in cooperation with IP logging would allow a node to know which kind of software and/or hardware is being used. The knowledge of software and/or hardware is always the first step in hacking which could be targeted to this specific user.

Temporary Risks

Censor: A malicious node has the power to block your transactions from being broadcasted to the network with or without your knowledge. You would wrongfully think that you successfully made a payment.

Tempering: A malicious node can alternate the blockchain to decrease or increase your balance. This attack is complicated as the node should know your public address. The risk lies in the following example: A user using his exchange's node could buy funds from the exchange, make a withdraw of the bought funds and be tricked into believing the withdraw was successful. The user would think he lost his funds as, while using the exchange node, he saw his funds in his wallet.

Extorsion: As explained with the risk of censor, a node can block your transaction. Although this scenario is hypothetical, nodes could theoretically force a rise in fees by preventing low-fee transactions from being broadcasted and picked-up by good-will miners accepting them. This would be beneficial in the case of miners operating nodes in an attempt to increase their profits.

These are the only risks known to me. Feel free to edit to increase this list.


Since monerod through Tor is slower (on Whonix), would importing the .raw be faster?

It seems likely that this would be a good idea to import the raw file. Not only will this possibly be faster, but also avoid spamming the Tor nodes on your way with gigabytes of blocks.

One very large difference in running time when importing a raw file is whether verification is enabled or not. If you already have a raw file you know is good, you can disable verification. This is however not recommended if you've just downloaded that raw file from the internet.

Another note is that I think importing is done one block at a time, and syncing from the network has optimizations that allow up to 200 blocks to be processed at once, allowing some speedup over import speed.

In the end, if you already have the raw file and aren't particularly pressed for time, avoiding spamming the Tor network seems the best way to go.


Wallet initialization failed: basic_string::resize

It is very likely that this (at least the reversion to watch only) is due to a bug in 0.9.3, which is fixed in 0.9.4.

Note that the 32 bit Windows binaries for 0.9.4 mistakenly include 0.9.3 instead. This will be fixed shortly, see https://github.com/monero-project/bitmonero/issues/1019 for reference.


Is it possible to run a full monerod node on Android?

Yes, there are already people running Monero full nodes with Android using GNURoot (which doesn't require a rooted phone, despite its name) as suggested by villabacho.
The proof of concept can be tested easily according to the steps listed by binaryFate:

Install GNUroot Debian
Launch it, and type the following into the terminal:

apt-get update && apt-get install wget bzip2
wget -O monero.tar.bzip2 https://downloads.getmonero.org/arm
bzip2 -d monero.tar.bzip2
tar -xf monero.tar
rm monero.tar
monero/monero-wallet-cli (use --daemon-host  for a remote node)

If you have enough storage and want to have a better privacy, download and store the blockchain on a SD card. Otherwise it may be more feasible to use a remote node, which is faster and easier.


Would smart contracts ever be possible on Monero?

There are a number of projects currently developing protocols that could be used for p2p transactions, financial derivatives, decentralized governance, and self-enforcing agreements.

Once multisig is implemented, it would be possible to incorporate Monero to enhance the privacy features of a smart contract application.


What is the difference between Monero (XMR) and Electroneum (ETN)?

Going through the commits there is really only one significant difference. Electroneum has no decoys, thus removes a significant aspect of privacy:

#define DEFAULT_MIX                             0
#define DEFAULT_RINGSIZE                        1

A couple of other things to note:

There is no attribution given to many commits which are simply copies of Monero commits since it forked (so they don't know how to use git to fetch upstream commits and merge to their fork)
There was a premine
They had an ICO
They believe in patents as opposed to FOSS
Good luck finding the patent they claim to have (1805708.3 applied for != granted)
This is not [as] decentralized, it is run by a company
Their mobile app is closed source [which is a huge red flag]
They reference "US Dept. Defence" being engaged for a security audit (big claim when in fact they are actually just using HackerOne)


No, and no, respectively.

A python miner would likely be pretty slow. At a push, you could maybe use a python main calling C code for the crypto parts.


I see gray inactive peers. Will they be recorded forever?

There is a limit of 5000 entries (P2P_LOCAL_GRAY_PEER_LIST_LIMIT), and they are stored in p2pstate.bin, which is in your daemon's data directory (typically $HOME/.bitmonero).

It is a privacy leak if you connected via clearnet. If that is a problem to you, you can run your node through Tor (see the instructions near the end of README.md in the monero tree).

Note that there being a limit for the gray peerlist does not have (much) privacy implications since you can assume a network adversary will not keep a limit.


How can you minimize risks to your privacy when using a remote node?

If it's only about sending moneroj, one could generate locally a signed transaction and forward it through a service like https://xmrchain.net/rawtx using tor/i2p/vpn to hide the originating IP.


How to cross compile monero to a ARMv7 target on a x86-64 host?

The Makefile is actually just a wrapper around CMake. If you look inside, it has various ARM targets like:

release-static-linux-armv7
release-static-linux-armv8
release-static-android-armv7
...

So you would run something like:

make release-static-linux-armv7

To build for ARMv7 Linux.

There is also a section in the README on cross-compiling using the depends build system:

  make depends target=arm-linux-gnueabihf for armv7 binaries. Requires: g++-arm-linux-gnueabihf


Yes. See get_transactions from the daemon RPC.


First of all, each Pedersen Commitment hides the committed amount by adding a random "blinding factor", so two commitments committing to the same amount will look completely differently.

Second, the range proof generation algorithm internally uses a lot of random numbers, so even for the same Pedersen Commitment, two or more range proofs will look completely differently. This property is true for all cryptographic signature schemes in general for security reasons: when the algorithm is run for a certain public key, the resulting signature data is always random and unique.


Generating an integrated address using only the Monero address

Yes.

First you need to get the public spend key and public view key from the Monero address, which you do by converting it from base 58 to bytes, skipping the first byte, and then reading two 32 byte sequences which represent the public spend and public view keys.

Then to construct the integrated address, concatenate the bytes (0x13 || public spendkey || public viewkey || payment id || checksum) and then convert to base 58.

Note that Monero uses a modified base 58 encoding scheme, and that the payment ID must be a 8 byte value.

For source code, examine the Javascript source at this page: https://xmr.llcoins.net/addresstests.html


Are there any Monero specific programming language "libraries" available?

There are several.

Python: https://github.com/tippero/python-monero

Node js: https://github.com/ShenNoether/monero-nodejs

Php: https://github.com/PsychicCat/monero-php

I think the node and php libraries are for interacting more with simplewallet in particular, but the Python library is for both daemon and wallet I believe.


Thanks to deterministic key derivation, the private spend key is an alternate representation of the mnemonic seed. Both the mnemonic seed and private spend key can be used to derive all other keys

The private spend key is used to sign Monero transactions.

Simplewallet mnemonics seed are comprised of 25 words with the last word being used as a checksum. Those words correspond to a 256-bit integer, which is the account's private spend key. With simplewallet the spendkey is the mnemonic seed The private view key is derived by hashing the private spend key with Keccak-256, producing a second 256-bit integer. The corresponding public keys are then derived from the private keys.

MyMonero works in a similar manner but with 13 word mnemonic seeds with the last word being the checksum The 13 words correspond to a 128-bit integer that is used for both spend and view key derivation. With MyMonero the spendkey is the hashed mnemonic seed

Deterministic wallets make wallet recovery and key derivation easy. It is worth noting that you cannot derive the view key from the private key for non deterministic wallets.


What are spans (as seen in the output of sync_info)?

Those are sets of blocks downloaded from the associated peers. The 20 here is the number of consecutive blocks downloaded at once, and the two numbers after this are their heights, which seems to be off by one. Those are downloaded asynchronously so they're ready when the blockchain sync process needs them.
Here, you have 13 such spans, totalling less than a MB of data.


Are there any trade-offs to daughter chains?

From my understanding, daughter chains are not as secure. They do not have the same mining strength that the normal blockchain has with its PoW system.

Daughter chains can be helpful for rapid/instant transactions, where I have good faith the network will not be hacked for someone to steal my $2.


Serhack is developing the woocommerce plugin for wordpress.
Check it: https://github.com/monero-integrations/monerowp


There was evidence of several cases of Tor exit nodes injecting JavaScript into the page. The developers of MyMonero did not want to risk MITM attacks leading to more theft of Monero funds.

At some point in the future, time permitting a better Tor hosting infrastructure may allow Tor to be re-enabled. Right now there are higher priorities. Security concerns trump any convenience factor that Tor usage at MyMonero may provide some uses.

For best privacy and security it is recommended that users run their own full nodes and keep most Monero in cold storage. Web wallets should not be recommended as primary wallets for anyone whose top priority is privacy or security


What exactly is the relationship between Monero and I2P

Monero will use I2P to connect nodes together. The goal of this is twofold:

an adversary spying on your network connection, like so many today, will not be able to see whether you are using Monero or not.
A node receiving a relayed transaction will not be able to tell the IP it came from.

A new I2P router, Kovri (https://github.com/monero-project/kovri/) is being developed for integration with Monero. The canonical I2P router depends on a Java VM, which is not ideal for weaker hardware.

Kovri will be usable by other clients than Monero too. Similarly, Monero will optionally be able to connect via clearnet (either only, or in parallel with I2). This is still a longer term feature.


I can only provide a partial answer. I had a similar question How are fees computed? and was linked to the same note on fees that you mentioned. I ultimately found the note to be out of date as well.

It looks like the only description available is to read the code. I believe the fee is being computed in Blockchain::get_dynamic_base_fee and the method seems to depend on whether the version is using fee per byte or per kilo-byte (I believe currently the former is the case).

However, you should be aware that this is not actually fee per byte of transaction size! I guess that would be too easy. It's in fact a based on transaction weight. For most transactions weight = size, but for bulletproof transactions with more than (I think) two outputs, it is computed in a different way. For these transactions weight > size. My guess this is to make sure that these transactions are not too cheap.

It's been awhile since I looked at that, so I forget the exact calculation. If you find it please share.

Edit: Based on the comments below, I believe the weight is computed as follows.

Let s be the size of the transaction, and o be the number of outputs, and w be the weight.

If o < 3 then w = s, otherwise
Let b = 368
Let l be the size of the vector L associated with the transactions bulletproof*
Let c = 0.8(b * 2^(l - 6) - 32(9 + 2l))
Then w = s + c

*Sorry I am not sure what the L vector is, but it seems to be associated with number of outputs, maybe 6 + log(number_of_outputs)?

Also, basically the base fee per byte is computed as:

(r * 3000 * 2^64) / 5*(300000^2)

Where r is the current block reward. The calculation is provided that  median block size is < 300000 bytes which I believe normally is the case.

Please, if this is wrong correct me. I just thought it might be nice to have written up somewhere, so people dont have to go through the code everytime.


I tried to use aeon . But my first transaction to wallet is in the blockchain but not in my balance

The current aeon has a known bug which causes the wallet to skip over blocks without parsing them. This means any transaction in those blocks will be ignored.

To fix this, you need to set refresh-from-block-height to 0 (or a height prior to your wallet original creation) and run "rescan_bc". Type "set" to see the current value, and if it's 1 million or more, type "set
refresh-from-block-height 0" then "rescan_bc". Your aeon should then appear after the rescan is complete (this does not download the blockchain again, it just parses the copy already on your machine).


How to get a decimal value of difficulty (480045) by a hexadecimal value of a given target in hex (f3220000) ?

Swap endian f3220000 and remove padding gets 22f3, then 0x100000001 / 0x22f3 yields: 480045.

  How to get a hexadecimal value of target (f3220000) by a decimal value of a given difficulty (480045)?

((2^256-1) / 480045) >> 224 is decimal 8947, hex 0x22f3. Swap endian and pad yields: f3220000.

The reason for both the division in #1 and shift in #2 is because we are exploiting the fact that we are working with only a 32 bit difficulty target. Thus, we are only concerning ourselves with the most significant 32 bits of a 256 bit number.

It's worth noting that this calculation is just legacy hangover of how the pools and miners were doing this when forked, which nobody felt strongly enough to improve upon. The current miner implementations foresaw this 32 bit limitation and do have code to handle larger targets [ref], though most pools do not, as can be seen by the pools you cite. In retrospect, it would probably be more sensible if the pools and miners calculated/checked difficulty more akin to how Monero does (i.e. if hash multiplied by difficulty doesn't overflow, it's good), as whilst this would mean passing around a slightly larger target in the stratum job message, it's more future-proof.


How can I access my full node remotely from another location?

As @antanst has said, I would also suggest using --rpc-bind-ip and --rpc-bind-port to bind to an external interface but only if your instance is inside an internal/trusted network. I see no reason why your instance should be publicly accessible (if there are reasons, someone please comment).

If you must connect across the internet, I would advise to bind only to localhost and run a Tor onion-site, or I2P server tunnel, or Kovri server tunnel, or any combination of the three, and then direct them to your designated port. From there, you can use torsocks or an I2P client tunnel to connect directly to your node with the safety and security provided by either overlay network.


How to link Monero GUI wallet to Ledger Nano x

You need following things checked before you even start:

Ledger Nano X with the most fresh Firmware (IMPORTANT!). Check if there is an update in Ledger Live app. If there is, update the Firmware first.
The newest, Monero App installed on Ledger Nano X
Monero GUI installed on your computer

I personally, like to make "dummy" wallet first in Monero GUI (Just click Create New Wallet). By doing so you can fully synchronize the Node with blockchain before you even start playing with your hardware wallet. When Blockchain is fully synchronized on the Node, you can create a second wallet which will be "hardware" wallet.
Basically what you need to do is to follow the instructions below:

https://github.com/monero-ecosystem/monero-GUI-guide/blob/master/en/ch02.md
https://support.ledger.com/hc/en-us/articles/360006352934-Monero-XMR-

First is the instruction from Monero GUI Guide (There is pdf in your Monero GUI folder). Latter is instruction from Ledger support page. Both should help you connect your hardware wallet to Monero GUI.
When you are done, you can simply send your Monero to the wallet address which is visible in Monero GUI as well as on your Ledger Device (They should match).
In case of any trouble let us know.


The Monero is on the blockchain.
To recover the Monero seed see the section "Seed recovery" in this Ledger guide:
https://support.ledger.com/hc/en-us/articles/360006352934-Monero-XMR-
Not easy but remember, the Monero are on the blockchain so there is time to recover the seed. They are only lost if your Monero seed is lost.


Can a full Monero node be restricted to run only at specific times?

You can use cron to start and stop monerod at the times you want.
Best is to run monerod with the --detach flag to run as daemon, then run without it but the exit command when you want to stop it:

monerod --detach
monerod exit

The second line will exit the first one.

In a crontab specification:

0 1 * * *    monerod --detach
0 7 * * *    monerod exit

This will start monerod at 1am, and stop it at 7am. See man 5 crontab for more info about crontab. Add any further arguments to the above.


Is there any evidence of Bitcoin being "Tainted"?

A few examples of Tainted/Clean Bitcoins come to mind:
Binance blocking a mixed BTC deposit: https://blockonomi.com/binance-blocks-bitcoin-withdrawal-wasabi-wallet/
Bitcoins requiring a history audit: https://redd.it/8tzh7w
Bitcoin node dropping transactions from BTC used in gambling: https://bugs.gentoo.org/524512
Dirty BTC on the Bisq market: https://bisq.community/t/dirty-btc-coins-on-the-xmr-market/7798
Chinese police freezing bank accounts that traded tainted BTC on OTC market: https://www.coindesk.com/china-police-freeze-otc-traders-bank-accounts-tainted-crypto
FBI document mentions DNM users discussing how to "clean" "dirty" BTC: https://ia803206.us.archive.org/23/items/dark-web-files-from-blueleaks/200309%20LES%20FBI%20EIR%20-%20Darknet%20Market%20Actors%20Likely%20Convert%20Illicit%20Bitcoin%20to%20Monero%20Using%20MorphToken%20Cryptocurrency%20Exchange%2C%20Impeding%20Law%20Enforcement%20Tracing%20Efforts.pdf


Can monero network exist without miners?

If no one is mining, and this is very rare for any cryptocurrency, no transactions would be able to be verified, yet your balance would still show up assuming people are still running nodes.


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


GUI / monerod v0.13.0.3 does not start on Linux because of "./monero-wallet-gui: error while loading shared libraries: libhidapi-libusb.so.0"

To run Monero Wallet GUI/daemon

First, this error is caused by the absence of thelibhidapi library, which is required by Ledger. Two forms of this library exist, one each for use with the hidraw (USB/Bluetooth) and libusb (USB-only) backends, and the error message indicates that the latter is needed.

Fortunately, this error is quickly resolved by installing the package which includes it with your system's package manager. For the most common Linux distributions that would be as follows:

Debian-based [.deb] (Debian, Ubuntu, Mint, elementary OS, etc.):

sudo apt install libhidapi-libusb0

Fedora-based [.rpm] (Fedora, openSUSE, CentOS, PCLinuxOS, RHEL, etc.):

dnf install hidapi

Arch-based (Arch, Manjaro, Antergos, etc.):

pacman -S hidapi

Gentoo-based (Gentoo, Redcore, etc.):

emerge -atv dev-libs/hidapi

Slackware-based [.txz] (Slackware, VectorLinux, etc.):

Download package here

upgradepkg --install-new hidapi-0.8.0_rc1-x86_64-1_slonly.txz

Alpine Linux:

apk add hidapi

To build Monero Wallet GUI/daemon

If rather than simply trying to run the Monero wallet/daemon you were attempting to build it from source code, you would likely need an additional package which provides the header files for said library. The most common standard for those package names would be to append -dev to the packages listed above, however there are exceptions. Both Debian-based and Fedora-based distributions use the name libhidapi-dev in place of the packages specified above.

Sources:

https://www.reddit.com/r/Monero/comments/9lcdme/preliminary_information_thread_regarding_the/e7ubtxp/
Error while loading shared libraries: libhidapi-libusb.so.0: cannot open shared object file: No such file or directory
https://www.reddit.com/r/Monero/comments/9ol2ic/gui_v01303_beryllium_bullet_released/e7vm7qj/


Does using seed to restore a wallet change its address?

A same seed will restore the same wallet. Checking the address is a good way to check that you got your seed right. For example, the seed

tanks ticket muffin eclipse lectures degrees gymnast technical deodorant hefty lunar casket zapped bovine skater bypass frying acquire inkling ammo army myriad soggy tepid hefty

will always result in the address

4ABD4g9KKzqdXtMdmgKF4pHg1qPthzmtBXiBMKLT3rPT4L7gCAKMZ1yD9nA3JVCVRpWn9X3aZeqKkfX81bemg2V2UQnve4o.

However, that's a standard address. If you use integrated address (which is just your address + some random data packed in), then it will be slightly different for each different payment ID packed in:

4Kst5UxowGMdXtMdmgKF4pHg1qPthzmtBXiBMKLT3rPT4L7gCAKMZ1yD9nA3JVCVRpWn9X3aZeqKkfX81bemg2V2hVfa2bxWtuzMXeekK9 (payment ID = 1961b07fc64d25b5)
4Kst5UxowGMdXtMdmgKF4pHg1qPthzmtBXiBMKLT3rPT4L7gCAKMZ1yD9nA3JVCVRpWn9X3aZeqKkfX81bemg2V2hbkcazxrXezR8kXAqL (payment ID = ba01b042e8b04bd5)

and so on.

Even if the letters look different, all these addresses are encoding the same thing. Your public spend and public view key + optional payment ID.

Funds sent to all 3 addresses will go to the same wallet, but the last 2 will come in with a "message" (payment ID).

You can play around to see how it works here.


What is the reserve_size parameter in getblocktemplate?

The reserve_size is the amount of data to reserve in the block template for the extra nonce (arbitrary data which may be embedded in a transaction). The maximum amount is 255 bytes. This is used by the pool code to place a nonce which will be incremented to try to find a block hash below the current difficulty target.


Connecting Kovri through a VPN vs using Kovri directly

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.


What's the purpose of email address in pool mining config?

The email address is used as a login password to manage your payout threshold. Without a login password, anyone knowing your Monero address can manipulate your payout threshold. Some pools also use email address to send you regular hash rate reports or payout notifications. Once you start mining using your email as pool password, and have submitted a few valid shares, the pool will associate your Monero address with your email address. you can then login using Monero address as username and email as password.

  is it mandatory to provide a valid email address?

Unless I misunderstand what Nanopool mean as "Optional", no, it is not mandatory. Without an email, you won't receive any notifications about your hash rate, and cannot configure your payout threshold. At the end of the day, you still get your Monero regardless of whether you give the pool your email or not.


Can monero-wallet-cli tell me the one-time public keys (outputs) that belong(ed) to it?

You can see the public keys for your outputs with:

incoming_transfers verbose

For spent ones, or unspent ones, respectively:

incoming_transfers verbose unavailable or incoming_transfers verbose available

Verbose mode will also give you the key image for each output.


Should one disable the Windows firewall for the Monero Wallet GUI?

To connect to one of moneroworld nodes, one has to establish an outgoing connection. Default firewall policy is to allow outgoing connections and block incomming connections. So you don't need to tweak the firewall to connect to these remote nodes.

For your own full node, that would be the opposite. This SE explains how to remotely access your own full node.


Daemons (nodes) talk to each other using the epee levin protocol.

https://github.com/monero-project/monero/tree/master/contrib/epee/include/net

https://github.com/monero-project/monero/blob/master/src/p2p/net_node.h

Both the wallet and daemon also expose JSON-RPC servers (so JSON sent over HTTP).

The methods are documented at:
https://getmonero.org/resources/developer-guides/wallet-rpc.html
and
https://getmonero.org/resources/developer-guides/daemon-rpc.html

With source code scattered in various places. The underlying server code is in:
https://github.com/monero-project/monero/tree/master/contrib/epee/include/net

With protocols defined in:
https://github.com/monero-project/monero/blob/master/src/rpc/core_rpc_server_commands_defs.h
and
https://github.com/monero-project/monero/blob/master/src/wallet/wallet_rpc_server_commands_defs.h


If you delete the lmdb folder and re-sync you will be in the same position. Just use the version (0.9.70) of mdb_stat that's in the Monero source tree (monero/external/db_drivers/liblmdb).

Also note, the python module version number (0.98) is not the lmdb version number. The python module you reference actually uses lmdb version 0.9.24. Therefore, if you need to use the python wrapper, you're going to have to build that first with the correct version of lmdb as used in Monero (0.9.70).

To use the LMDB library included in the Monero source code, uninstall your currently installed python lmdb module and reinstall following steps like:

cd ~/monero.git/external/db_drivers/liblmdb
make
cd ~
export LMDB_FORCE_SYSTEM=1
export LMDB_INCLUDEDIR=~/monero.git/external/db_drivers/liblmdb
export LMDB_LIBDIR=~/monero.git/external/db_drivers/liblmdb
pip install lmdb

Which ensures the version of LMDB the python module uses is the same version as used by Monero.


The "v6 update needed" is probably a mangling of the status line, right ? If so, it's telling you it's been a while without an update. It turns out there's none available right now, but it is expected to be very soon.

As for the "Error: Problem fetching info -- Error checking for updates", it's possibly because you build monero yourself. If this is the reason, I believe current master handles it correctly.

It could also be due to DNS problems. You can check that by setting the "DNS_PUBLIC" environment variable to "tcp", which will use Google's DNS server via TCP, as many DNS servers don't support DNSSEC well. In the current code, the Google DNS server is replaced by a selection of non Google servers, and you can select your own preferred server too.


What is the "SpendProofV1..." or "OutProofV1..." in the details of a sent transaction in the GUI?

tl;dr:

OutProofV1 strings prove you had access to the wallet that constructed a particular transaction. SpendProofV1 strings are used when some wallet information has been lost (because txkeys are lost forever if you don't store them), and instead prove you had full knowledge of the private keys of the inputs being spent in a transaction.

Strings beginning with "OutProofV1" directly disclose the per-recipient "key derivation", which in turn allows someone to determine the per-output shared secret for the output you claim to have sent. Indirectly, this information allows the id of the related transaction to be identified, and then the amount of the output sent to the recipient to be decrypted and any encrypted payment id to be decrypted. If you know a list of potential wallet addresses that the transaction could have been destined for, you can test whether any of those wallet addresses were the destination of the transaction.

Strings beginning with "SpendProofV1" indirectly disclose the id of the related transaction.

Knowing the id of a transaction allows all public information about that transaction to be discovered (such as any old-style unencrypted payment id used, the time and date of the transaction, the ring size used and the fee amount paid to mine the transaction).

Monero's untraceability (i.e. knowledge of the inputs actually being spent in the transaction) is unaffected either way. Your wallet address is not leaked in either scenario either.

The full answer:

If you see a string beginning with "OutProofV1", then the characters that follow contain the per-recipient "key derivation" (32 byte elliptic curve point) and a Schnorr signature (two 32 byte scalars). These are base58 encoded.

The the "key derivation" can be used to calculate the per-output shared secret which can be used to decrypt the amount sent and decrypt any encrypted payment id that is present.

The Schnorr signature proves that you have knowledge of the transaction private key that correlates with both the key derivation and the transaction public key.

Although the OutProofV1 string directly only discloses the per-recipient key derivation, it indirectly discloses more than this. The per-output shared secret can be calculated and used to attempt to decrypt the amount of every single output on the blockchain (via the ecdhInfos section of each transaction). When a decrypted amount appears that is within the allowed range of Monero output amounts (i.e. less than 2^64 piconero), this is very strong evidence that the shared secret applies to that particular output.

Therefore knowledge of the OutProofV1 string discloses the related transaction, the amount of the output transmitted in that transaction (only the amount of the output destined for the other person, and not the amount of your change output), and can decrypt the encrypted payment id associated with that transaction.

If a database of possible wallet addresses is available (e.g. by scraping Monero addresses from internet web sites), then it would be possible to use the key derivation to check whether the output was destined for any of those wallet addresses. Note that this only works if there is a possible wallet address list to check against. If the wallet address of the recipient is unknown, then it is impossible to determine it. It would not be possible to test if the change addresses in the transaction are destined for any particular wallet address, because the key derivation that applies to your change outputs is different than the key derivation disclosed by the OutProofV1 string.

If you see a string beginning with "SpendProofV1", this means that the transaction private key (txkey) was not available. This could be because you had made the transaction from a different wallet. If you don't preserve knowledge of a txkey after making a transaction, it is lost forever and cannot be recovered by scanning the blockchain. It also means you will be unable to recover the per-output shared secret for the output sent to the other person in the transaction.

Since you can't prove knowledge of the txkey or the per-output shared secret, you can instead prove that you owned the outputs that were spent in the transaction. The transaction you originally sent would have already included a ring signature proving that you owned one output per ring in the transaction.

The SpendProofV1 string contains a second, newly created ring signature that proves exactly the same input ownership again, but using different random initialization data. Only someone that owned the inputs of the transaction would be able to create this second valid ring signature. That is all the SpendProofV1 string contains. There is no key derivation communicated, because it is unknown by the wallet in this scenario.

Since the ring signature(s) in the SpendProofV1 string will be valid for one of the transactions on the blockchain, it would be possible to identify the transaction from this SpendProofV1 string.

In both scenarios, knowing the id of a transaction allows all public information about that transaction to be discovered (such as any old-style unencrypted payment id used, the time and date of the transaction, the ring size used and the fee amount paid to mine the transaction).

In both scenarios, Monero's untraceability (i.e. knowledge of the inputs actually being spent in the transaction) is unaffected. Your wallet address is not leaked in either scenario either.


What is the reason why the monero firmware is delayed until ringCT is implemented?

Noodledoodle has held off releasing the firmware as it needs to be reworked to make RingCT compatible transactions. It will be fine to use as is, but the trezor firmware won't be usable after September 2017. I'm pretty sure that's why he hasn't released it yet as it's not going to be much use to anyone if it isn't properly finished. The Monero-wallet-cli code has already been released and simply needs to be merged properly. Probably once it's been reviewed and polished to the devs' satisfaction. I think he has released a more up to date version, but I'm not sure where he posted it. It may be on the github page.

The newest Monero firmware binary is here.


Is it possible to set up a short cut to launch monerod with a flag and cli-wallet at all at once?

I'm on macOS and I do the following to accomplish what you are asking:

Create a file called run_monerod.sh that contains the following:

#!/bin/bash
/Full/path/to/monerod --rpc-bind-port 11111

I create this from the Terminal by typing nano run_monerod.sh and then typing the other bit, then saving with cntl+x, y, enter. Finally I make the shell script executable by typing

chmod +x run_monerod.sh

Now I can call it with

./run_monerod.sh

and it runs detached on a different port, instead of having to type all that in every time.

Okay, so what's going on here?

the #!/bin/bash is called the "shebang", and basically tells your Mac "hey, this is a bash script." It's not really that necessary, but useful nonetheless.
nano is just a really simple text editor that can be used from the terminal
chmod +x says "make this executable."

Now, to run your wallet, you could do something similar... Make a file called run_wallet_cli.sh with the same shebang but instead of including the stuff for monerod, include the stuff for monero-wallet-cli that you usually type in the terminal when you're opening the wallet. Lastly, make it executable. When you want to use your wallet, run the monerod script, then once it's open, run the wallet script.

Bonus since macOS:

If you want to be able to click-to-run your scripts instead of running them in the command line, save them as .command instead of .sh. then just click on them in the Finder and have at it!


How would the privacy of monero be affected by a quantum computer?

Yep, using Shor's algorithm for finding the discrete log would allow the person in possession of a quantum computer to find every x used in a key image x.H(R) (not immediately, but in a feasible amount of time), and hence know exactly which accounts are linked by transactions.

There's actually a bigger issue than deanonymising all the transactions if quantum computers become a reality in the near future though -- Schnorr signatures and EdDSA are both based on the hardness of the discrete logarithm problem, which means an adversarial actor with a quantum computer will be able to compute your private key from any signature you produce, and attempt to spend your funds before your transaction is accepted into a block, or some other similar attack :(


The wallet does not report on the daemon mining hash rate, you will have to run status in the deamon, or use RPC directly, eg:

curl -v -X POST http://NODEIP:NOTEPORT/mining_status -d '{}' -H 'Content-Type: application/json'

Then replace NODEIP and NODEPORT with the IP and port of your remote daemon.

Note that this RPC will only work if you did not set your daemon to use restricted RPC mode (which is recommended if strangers have access to your daemon's RPC).


What features allowed Monero to rise to the top and overcome Bytecoin?

I'd say ...

A hard-working team of dedicated and skilled developers delivering working software while others just talk
Developers who actively support the community on social media (here, reddit and github)
Advanced privacy and confidentiality features (RingCT)
Low inflation


Monero setting up a testnet wallet in terminal, can't sync

You need a more recent version to use the public testnet. In particular, the public testnet is currently running v7, while 0.11.1.0 only knows up to v6.
At some point, the testnet will also be reorganized as bulletproofs will be moved to v8, and v7 will be re-mined, so be aware that coins you mine on testnet on v7 will go poof at some point.


What’s the point of wannacry for exchanging Bitcoins to Monero?

In the example you are referring to, the WannaCry attackers used Shapeshift to convert Bitcoin for Monero.

Shapeshift would have access to the sending Bitcoin address (known publicly as the WannaCry address), the IP address that accessed the website, the known given outputs to the Monero address, and the receiving Monero address. Minus a few other points of metadata, that's about it.

For Zcash, the leaked data would have been essentially identical if sent to a z-address. However, since Shapeshift does not support sending to z-addresses, Shapeshift would have also had access to when the attacker moved funds from the t-address (and to where - either another t-address or some z-address).

There is no way for Shapeshift to know for certain when the funds are spent on Monero. They know which transactions use the same outputs, but these outputs are likely used in several transactions. Furthermore, the attacker could send Monero to themself to increase the output anonymity set. Investigators are likely looking at how the outputs have been transferred on the blockchain by these different participants over time. They hope to narrow down the anonymity set based on user behavior.

You mentioned the view key, but Shapeshift presumably does not have the view key of the attacker's Monero wallet.


The mining at 50 H/s message indicates your total mining hash rate.


mymonero.com x number of blocks behind can i use the wallet?

You can still receive Monero for your wallet address. It just doesn't show up until it's fully synced with the blockchain. So as long as you get this message you are not in sync with the blockchain but if someone sends you Monero, that transaction will be on the blockchain. You just need to wait in order to see it there.


CryptoNote features in other cryptocurrencies

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.


The block header or block isn't what is being hashed.

The block header contains versions, timestamp, coinbase tx, and other ancillary info.

The block contains the header, as well as a list of transaction IDs.

The block hashing blob, which is different contains the block header plus the number of transactions and the Merkle tree root (ie, not the whole set of tx ids). That is what is being hashed for PoW.

getblocktemplate gets you the block hashing block in the blockhashing_blob field.


There have been some conversations about the need for producing professional looking Monero videos. Some videos have been produced from volunteers within the Monero community and from organizers or participants of events where a Monero developer has spoken but more are needed. Here is some existing audio and visual content produced by volunteers:

MoneroEric education videos
gingeropolous education videos
fluffypony at On Chain Scaling
fluffypony at Arnhem Bitcoin City
fluffypony at Bitcoinference
LetsTalkBitcoin - Understanding Monero
fluffypony at BitcoinUncensored
fluffypony at SatoshiRoundtable

For technical users, the most informative educational content is provided by the papers written by Monero Research Lab mathematicians.

While donations can be made directly to those who produce videos, use of the Forum Funding System is highly encouraged. Community consensus seems to indicate a focus on producing more content after the release of the official GUI at which time Monero will be more welcoming to newcomers without technical backgrounds.

There are many aspects to community education, this Stack Exchange site being a prime example that required a large amount of community support. So far only Bitcoin, Ethereum and Monero have been able to successfully meet the requirements of proposing and launching a SE site. No amount of money can purchase the educational materials provided on Monero SE.

  Unfortunately, we no longer offer a subscription service or license the software to host Stack Exchange sites. Stack Exchange sites can only be created via the community-driven process at Area 51. We offer neither "white-label" services, nor the ability to bypass Area 51 to create sites through partnerships.

Monero community members are encouraged to help produce educational materials such as user guides and additional Moneropedia entries. So far most content has been created by volunteers but usage of the Forum Funding System has gradually increased over time and I expect that trend to continue.


Digest authentication with monero-wallet-rpc

Well there seems to be quite a few open issues using that particular nodejs library with digest auth. I suggest using another library. The fact it works with curl proves this is not a Monero issue.


How will transaction fees be calculated after RingCT?

I can't imagine a scenario where we base-price transactions at anything more than per-kb pricing. It's the most logical way to price it, given that you're literally paying for indelible space on the blockchain.


I will quote some comments from kenshi84 (who submitted the pull request).

Subaddresses are just like the standard address that you can use for receiving funds repeatedly. For example, you can use subaddress of index=1 for receiving your salary and index=2 for raising funds for your secret project, and no one can find the link between them.

The number of subaddresses that you can generate for your wallet is limited due to storage requirement (currently the limit is 10000 addresses and they are precomputed during wallet generation).

The number of the precomputed subaddresses is set to 10000 by default, and can be changed via set command.


Botnets do not have magical ability to affect Monero more than any other hash source.

As other PoW based currencies, Monero is vulnerable to 51% attacks, and any adversary who is able to sustainably mine faster than the rest of the network will be able to slowly increase the cumulative difficulty of an attack chain, and thus override a "legitimate" chain. Thus, Monero is vulnerable to any party that can attain 51% of the network hash rate (and, similarly to other PoW curencies, to any party that can attain a significant minority hash rate too, for different types of attacks).

Monero uses the Cryptonight PoW hash, as most Cryptonote based currencies do. Cryptonight is designed to close the efficiency gap between CPUs, GPUs, and ASICs. With Bitcoin, CPU mining is a thing of the past, and the vast majority of "normal people" are thus unable to partake in Bitcoin mining, and, by extension, are unable to have a say in how Bitcoin's blockchain evolves. The intent of Cryptonight is to curtail the advantage ASICs have over GPUs (there are no ASICs for Cryptonight at this time, two and a half years after its introduction), and GPUs have over CPUs, thus restoring the "one CPU, one vote" idea.

Now, botnets are able to commandeer a large number of CPUs, and thus may be viewed as a potential danger to Monero. Botnets are typically composed of low to medium strength machines, and without high end GPUs. They are thus able to sustain a fairly high hash rate, but not so high to reach a majority of Monero hash rate. Of course, this is variable, and it is theoretically possible that a large botnet might be able to reach 30 MH/s (the current Monero network hash rate - if a new entrant was able to bring 30 MH/s, thus increasing network hash rate to 60 MH/s, that entrant would then have about 50% of the network hash rate).

Moreover, if a botnet was able to reach that point, it could either decide to mine honestly and make money that way, or attack Monero (eg, double spend). Similarly to Bitcoin and other PoW currencies, it is more profitable to "play nice", since an attack would cause the exchange rate to drop dramatically very quickly, since the coin would no longer be safe. This incentive is a failsafe, should someone be able to amass that much has power.

50% hash rate has happened in the last, at least for Bitcoin. A single pool reached 50% hash rate (I can't remember the name right now). Yet, no double spend or other such attack happened. This is because that party stood to gain more from continuing playing fair. Of course, this is a bad place to be, but there is yet another incentive to act as a last chance shield against a catastrophic failure.

A separate, though related, criticism leveled at Monero is that botnets mining Monero somehow make Monero "bad". I'll mention this because it is a common canard, even if shortsighted. There are two reasons why this argument does not hold water: first, a criminal using something does not make that thing a bad thing. After all, criminals use cars to get to the place of their crimes, dollars to pay for their tools of the trade, etc. Second, if a botnet is being used to mine Monero, it means it isn't being used for other socially negative use, such as spamming, DDoS, or other. One can therefore argue that botnets mining Monero is in fact a social good, since those botnets switch from a nefarious activity to a positive one, increasing Monero hash rate to make it more difficult to attack by another party.


Pruning the Monero blockchain, a number question

Why only 2/3 of the blockchain data can be pruned?

Think about it like this: If you pruned 100% you would have nothing, your node, and wallet connected to your node, wouldn't be able to do anything. So how much do we actually need to keep to still be usable? Well, once we've verified every transaction, we no longer need the signatures, so they can be discarded. However, we still need the rest of the tx data.
Now to be usable to others...

How do I relate 7/8 (87.5%) pruneable transactions to 2/3 (66.6%) pruneable blockchain?

With pruned nodes, we still want them to be useful to others also, so they can sync and crucially verify every transaction. This is where the 7/8 comes into play. Of a full blockchain, we will only prune 7/8 of it, leaving a random 1/8 unpruned, so others can still fully verify that 1/8. When a new node comes along, it will sync and verify parts of the blockchain from many different nodes.
So, 7/8 will be a candidate for pruning and of this 7/8, ~2/3 can be discarded.
Or to put another way, 1/8 will be left untouched, of the remainder, ~2/3 can be thrown away after we have verified.
The 2/3 number in the linked article is speaking approximately* as to how much will be discarded from a full blockchain - bottom line is this, 1/8 will be kept unpruned (untouched), the rest can be pruned, which means discarding parts of data we no longer need (e.g. the signatures), post verifying.
*approximately because transaction size and volume are not uniform.

Which component of the transaction is actually pruned?

Signatures.

This pruning is not as efficient as bitcoin

Comparing is pointless. The requirements of the blockchains are fundamentally different.


Calculating the break-even time for new rig

The current difficulty is about 6.604 billion, not 1.617.  And the block reward is about 8.63, not 14.  The other parameters seemed reasonable enough.

Those changes will certainly paint a different picture.


Should I run my Monero Node on Linux, Windows or macOS / OS X?

If you run the provided binaries, it should be the same on all platforms, whereas if you plan to build from source, it's easier to use docker.
I find it easier to use docker on linux over windows because there is no need to add a port forwarding to the VM.

BTW, you don't need a dedicated hardware. Once the blockchain is fully synced, it doesn't consume much ressources.


We can't tell without more information.

If you'd left monerod not running for a long time, it's plausible that it'll try to contact nodes which were running, but are not (either they're now down, or they were on dynamic IPs which changed since, etc).

It is also possible that peers banned your node. This would normally only happen if your node is on a bad fork and sends incorrect data to those other nodes. Check you are using monerod 0.10.3.1.

Another possibility is that your network connectivity is down.

To check what the network layer is doing: set_log 1.

To try and reset the set of known peers: exit monerod, rm ~/.bitmonero/p2pstate.bin, start monerod again


Is Monero mining profitable with 600 H/s?

Hash power: 600 H/s, Power consumption: 50w, Electricity cost: $0.1/KWh, Pool fees: 1%

What is the actual reality of Monero mining at a hash rate of 600 H/s?

Clearly you will make a loss unless the price of XMR grows significantly against the dollar.

I am sure people will not mine for a loss.

Correct. Anyone remotely serious about mining will buy hardware that mines significantly faster than 600 H/s and will locate their hardware where they can secure cheap electricity - the combination of which to make it actually profitable.


What solutions are there to do a refund of a transaction when sending monero xmr?

Monero's stealth addresses make it impossible for you to know the wallet address of anyone that sends you funds, unless they tell you.

Therefore you need them to prove that they sent you funds, and at the same time tell you the wallet address where they would like their refund sent.

There is a guide to proving payment here: https://getmonero.org/resources/user-guides/prove-payment.html


Why does Monero GUI kill my internet connection?

Many cheap internet modems choke when the outgoing bandwidth is saturated. Try starting the daemon with the "--limit-rate-up=X" where X is a small value in KB/sec. You can start by allocating one third of your maximum outgoing bandwidth and see how this behaves.


Livecoin doesn't credit my balance after missing Payment ID

There is nothing you can do.

Per Monero's privacy they even can't know which transaction came from you, that's why they require a payment ID. Public coins like Bitcoin let you know who send the transaction and thus do not require payment IDs. There are procedures to prove you made the payment but Livecoin won't probably loose time on that. More information about the proof of payement can be found on Monero's Wiki.


How does the get_reserve_proof command work?

Yes. It is supposed to be a more privacy-preserving alternative to the previous method of proving the wallet balance to an auditor by giving out the view key and signed key images. (In my opinion, the watch-only wallet feature should only be used for cold signing purposes; i.e. the view key should never be given out to others.) Similar to the previous method, this method also sends out a set of signed key images to the auditor. The biggest difference is that the view key is not given out, and the wallet owner can explicitly control how many key images to include in the set (i.e. to prove for different amounts). In contrast, the previous method of giving out the view key will inevitably allow the auditor to see all the incoming transfers, in the past and forever into the future, which is probably undesirable.

This is the C++ data structure for each item in the set saved in the proof (see src/wallet/wallet2.h):

struct reserve_proof_entry
{
  crypto::hash txid;
  uint64_t index_in_tx;
  crypto::public_key shared_secret;
  crypto::key_image key_image;
  crypto::signature shared_secret_sig;
  crypto::signature key_image_sig;
};

In addition to the signature for the key image, it also contains the shared secret D = a*R with a and R being the view secret key and the tx public key, respectively, along with a signature proving that the signer knows a such that D=a*R without revealing a.


There are at least 13 pools but likely more due to private and unkown pools
Not yet, but there has been some interest in the idea

  It does not exist for Monero but it would be a nice little project to create one.
  The main reason people don't seem to go for it is higher overhead. You have to run a full node, and you have to run what is essentially a second full node for the sharechain. With traditional stratum miners you just run a tiny mining program and have tiny bandwidth usage.
  The second reason, on Bitcoin in particular, is somewhat chicken-and-egg. Since not enough people use p2pool, it doesn't get blocks very often (takes days currently) and then miners using it get unhappy with the variance.
  I think p2pool is reasonably popular on some alts.

crypto-pool.fr is currently the largest known pool at 18.2% with "unknown" controlling 41.7%
Yes, an updates pie chart can be found here
Yes, same source as the previous question
If there is a formal procedure I am not aware of it. Reddit and Bitcointalk, IRC, Slack and other channels can be used to reach many Monero users quickly when needed.


Empty destination field in transfer history

What is happening is that you made that transfer from a different wallet file.  A wallet cache cannot be fully restored once it's gone.

Perhaps your address was originally a MyMonero wallet, and you restored it in the CLI, after sending a transaction from the wallet when it was still a MyMonero wallet.

Or maybe you created this wallet on Linux originally... and you sent some Monero... and then you were goofing around with installing more things on Linux, and your experimentation back-fired... and you ended having to install a fresh Linux system, and you then restored your Monero wallet, and it's been working well ever since.

In both cases, the wallet currently being used was unable to completely restore the cache to include the public addresses for prior (original wallet) outgoing transfers.  This is a consequence of stealth addresses.  There is simply no [reasonable] way to figure out which public address was used to create the one-time stealth address.

For technical details on the matter - the reason the math can't just be run backward to figure out the public address from the stealth address -  check out Elliptic Curve Cryptography and the Discrete Log Problem.


Using JSON RPC, how do I check for payments for a particular integrated address?

An integrated address is just your standard address and the payment id you chose, bound together into one string. When you generated this standard address, you'd have written down that payment id. If not, there is a split_integrated_address wallet RPC that will do this for you.

That payment id may be used as input for your original RPC call. If it doesn't work, then it's because there's a bug in the RPC that needs fixing, and the best next step is to report it along with the actual commands you used to https://github.com/monero-project/monero/issues

Note that you get a short (64 bit) payment ids when working with integrated addresses, whereas legacy payment ids are 256 bits. This is expected, and you're not missing anything.


Decrypting payment Id of integrated address

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!


Getting notified about a new block on the Monero blockchain

The current Monero release allows you to call a program in those cases:

When a block in added to the blockchain, you can trigger a command using monerod's --block-notify option.

When a transaction is received by the wallet (both when seen in the txpool and after its first confirmation), you can trigger a command using monero-wallet-{cli,rpc}' --tx-notify option.

Both of those options take as parameter a program and optional parameters. Every instance of %s will be replaced by the block hash or transaction hash which triggered the notification. Note that this is a program and optional parameters, and not a shell command, if you want redirection or pipes, you'll have to call a shell (eg, --tx-notify bash -e 'echo %s >> /tmp/hashes'). Parsing is limited, so you can't use quotes and backslashes to escape spaces. If you need complex parsing, write a script to do it and call the script.


monero-wallet-rpc: Transfer from sub-account?

Alas, the developer guides are, at the time of writing, a bit outdated. Fortunately, however, a number of people are working on ensuring they will be up to date soon. One of those people is oneiric and I'll use the example from his repository to answer your question. See below for an updated guide on the Transfer RPC command:

  Transfer

  Send monero to a number of recipients.

  Inputs:

  destinations - array of destinations to receive XMR:

  amount - unsigned int; Amount to send to each destination, in atomic units.
  address - string; Destination public address.

  account_index - unsigned int; Transfer from this account index.
  subaddr_indices - array of unsigned int; Transfer from this set of subaddresses.
  fee - unsigned int; Ignored, will be automatically calculated.
  mixin - unsigned int; Number of outpouts from the blockchain to mix with (0 means no mixing).
  unlock_time - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
  payment_id - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
  get_tx_key - boolean; (Optional) Return the transaction key after sending.
  priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0-3 for: default, unimportant, normal, elevated, priority.
  do_not_relay - boolean; (Optional) If true, the newly created transaction will not be relayed to the monero network. (Defaults to false)
  get_tx_hex - boolean; Return the transaction as hex string after sending
  get_tx_metadata - boolean; Return the transaction metadata.

  Outputs:

  fee - Integer value of the fee charged for the txn.
  tx_hash - String for the publically searchable transaction hash
  tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
  amount_keys - List of strings for the amount keys.
  amount - Amount transferred for the transaction.
  tx_blob - Transaction as hex string if get_tx_hex is true
  tx_metadata - Transaction metadata string if get_tx_metadata is true.
  multisig_txset - Set of signing keys used in a multisig transaction (empty for non-multisig).

  Example:

$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":100000000,"address":"9wNgSYy2F9qPZu7KBjvsFgZLTKE2TZgEpNFbGka9gA5zPmAXS35QzzYaLKJRkYTnzgArGNX7TvSqZC87tBLwtaC5RQgJ8rm"},{"amount":200000000,"address":"9vH5D7Fv47mbpCpdcthcjU34rqiiAYRCh1tYywmhqnEk9iwCE9yppgNCXAyVHG5qJt2kExa42TuhzQfJbmbpeGLkVbg8xit"}],"mixin":4,"get_tx_key": true}}' -H 'Content-Type: application/json'

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "fee": 48958481211,
    "tx_hash": "985180f468637bc6d2f72ee054e1e34b8d5097988bb29a2e0cb763e4464db23c",
    "tx_key": "8d62e5637f1fcc9a8904057d6bed6c697618507b193e956f77c31ce662b2ee07",
    "amount_keys":[],
    "amount": 300000000,
    "tx_blob": "",
    "tx_metadata": "",
    "multisig_txset": ""
  }
}


GUI LoadLibrary failed with error 1114 on Windows

This is an error with the Switchable Dynamic Graphics power setting in Windows. If you open Power Options, expand "Switchable Dynamic Graphics" and then "Global Settings", and then set "On battery" (if applicable) and "Plugged in" to "Maximize performance", it should run properly. Click apply and try running monero-wallet-gui.exe again.


Preventing DDoS attacks against a Monero service while protecting user privacy

All three of the options you mentioned negatively impact user privacy.

Cloudfare is often unfriendly to Tor users.
Logic requirements mean the collection of data from users
IP blocking harms innocent users (whose VPN ip address or Tor exit node usage may be flagged as abusive due to no fault of their own).

One thing you could try is to require none of the above as your baseline and only activate Cloudfare selectively at times of unusually high usage.


How do I generate a QR-code for a Monero address?

QR-codes have nothing specific to Monero. They are just a 2D representation of a string.

It should work with any qr-code tool, and for any alphanumeric string of less than 4296 characters. So this includes monero public keys, private keys and integrated addresses.

For example on Linux :

Install packages : apt-get install qrencode zbar-tools
Generate a QR-code : qrencode -o addr.png "4A................."
Read the QR-code : zbarimg -D addr.png

There also plenty of websites that offers this service. However, please note that by using them, you may be giving up a bit on privacy.


For the example you've given, where there is only one wallet destination, the transaction will have two outputs (one for the recipient, one sent back to you with your change).

A simple approximation is that the transaction size will be 6176 bytes * [output count] for the range proofs, plus for the ring signatures: [input count] * 64 bytes * [ring size].

So if you spend a single input (which contains enough funds), with a ring size of 7, this formula gives you an approximate transaction size of 6176*2+1*64*7 = 12800 bytes. In reality, it'd probably be closer to 13200 bytes, because of the simplification we've made.

When you spend funds, you probably won't be able to tell whether you're spending funds out of a single input you own, or whether the source of the funds is spanned over multiple smaller inputs you own. As you can see from the formula, in some cases, the transaction could easily be many KB larger than usual if you have to spend together lots of small inputs in order to have enough funds in total for the transaction. The answer also varies a little according to the random indices of the decoy inputs that you select during the transaction.

Therefore the simplification this answer presents should be good enough, given that you won't have the information available in advance to make a more accurate prediction of the transaction size.

Also note that Monero fees are charged on KB boundaries. Therefore a 13KB transaction will cost the same in fees as a 13.99KB transaction, but a 14.01KB transaction will cost more than a 13.99KB transaction.

It is expected that later in 2018, a new bulletproof scheme will replace Monero's existing range proofs. This will significantly lower the size of transactions.


Could not find Boost libraries or Version is too old

On Debian and Ubuntu platforms the highest available version of Boost is 1.55 . You have to download 1.58 sources and install it.

wget http://sourceforge.net/projects/boost/files/boost/1.58.0/boost_1_58_0.tar.gz

decompress the archive

tar -xf boost_1_58_0.tar.gz

then navigate to the folder

cd boost_1_58_0

and run the bash script for configuration of building Boost

./bootstrap.sh

Finally compile!

./b2

Install by sudo ./bjam install

After installing new Boost version, execute on Monero source code folder:

make clean
make


How do you confirm payment via a JSON RPC call?

There are get_payments and get_bulk_payments JSON RPCs you can send to a running monero-wallet-rpc daemon to get a list of incoming payments using some given payment IDs.

There are some examples at https://getmonero.org/resources/developer-guides/wallet-rpc.html

curl -X POST http://127.0.0.1:18082/json_rpc
     -d '{"jsonrpc":"2.0",
          "id":"0",
          "method":"get_payments",
          "params":{"payment_id":"4279257e0a20608e25dba8744949c9e1caff4fcdafc7d5362ecf14225f3d9030"}}'
     -H 'Content-Type: application/json'

{ "id": "0",
  "jsonrpc": "2.0",
  "result": { "payments": [{ "amount": 10350000000000,
                             "block_height": 994327,
                             "payment_id": "4279257e0a20608e25dba8744949c9e1caff4fcdafc7d5362ecf14225f3d9030",
                             "tx_hash": "c391089f5b1b02067acc15294e3629a463412af1f1ed0f354113dd4467e4f6c1",
                             "unlock_time": 0 }] } }


Using monero-wallet-cli to do a transfer after version 0.14+

I know ring size is not required anymore so has the transfer command changed after the v0.14+ monero cli wallet update?

It's still required by the protocol but the wallet sets the ring-size to 11 without the need to specify in the transfer command. The command and it's parameters are unchanged (backwards compatible) however.

  How do you send monero using the transfer command now with payment id?
  Do you have to do anything else special with the transfer command after v0.14?

It works the same way as before.

[wallet 456789]: help transfer
Command usage:
  transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] (<URI> | <address> <amount>) [<payment_id (obsolete)>]

Command description:
  Transfer <amount> to <address>. If the parameter "index=<N1>[,<N2>,...]" is specified, the wallet uses outputs received by addresses of those indices. If omitted, the wallet randomly chooses address indices to be used. In any case, it tries its best not to combine outputs across multiple addresses. <priority> is the priority of the transaction. The higher the priority, the higher the transaction fee. Valid values in priority order (from lowest to highest) are: unimportant, normal, elevated, priority. If omitted, the default value (see the command "set priority") is used. <ring_size> is the number of inputs to include for untraceability. Multiple payments can be made at once by adding URI_2 or <address_2> <amount_2> etcetera (before the payment ID, if it's included)

You will however get a warning:

Unencrypted payment IDs are bad for privacy: ask the recipient to use subaddresses instead


Any quick way for me to test my browser's hash rate for CryptoNight v2?

Given that Monero is now on CNv4, I doubt very much you're going to find a "quick" way to test this. You'd need to find or setup a version of the chain running the older version, setup a mining proxy, edit and build one of the CN wasm miners etc etc. So nothing "quick".

This all said, why do you need to test this? I can tell you right now that javascript mining gets you sub-100 Hs.


Any given output in a ring has a 1/11 chance it is the true spend, whether you see that output in one ring or N different tx rings.
One of the problems with churning is it can easily have the opposite and undesired effect - reducing ones anonymity set. This can either be through timing analysis and / or linked outputs (e.g. seeing a tx with 3 specific outputs being spent and those 3 input rings each having one of the original 3 outputs).
For example, if an exchange sends you 3 outputs in a transaction (your withdrawal) and you then merge all those outputs (via a churn) to a subsequent single tx, the chance of it being you spending becomes significantly higher: 1 tx, 3 input rings with each ring containing 1 of the original 3 withdrawal outputs; it's an almost certainty it's you.
If on the other hand you hadn't performed this churn, you defer the decision making to the wallet to make its best effort in avoiding creating this kind of association. Which brings us to one of the specific cases of churning that can help. If you don't have enough other spare outputs to fund the new transaction, then performing careful churns (utilizing sweep_single) comes into play, as you can perform individual churns on those 3 outputs. Which brings us to the interesting part of your question: timing.
Performing 3 sweep_single transactions to churn those outputs in quick succession, isn't going to help much. Imagine all 3 in different transactions but in the same block - bingo, you're not greatly improved. What you really want to do is space them out to a degree that they could have naturally been selected as decoys in other transactions.
There's no comprehensive research yet (at least that I've come across) to give an indication of the best timing to use, though this topic does come up from time-to-time in MRL discussions, often in relation to the output selection algorithm, to improve default wallet behavior. One thing we can say for certain is that spreading out these single output churns over hours, days or even weeks is going to be better that in the same transaction or block.


Wallet created with 0.9.4 fails to load with 0.10.0

This is a known bug (see https://github.com/monero-project/monero/issues/1106), though the root cause is only suspected now known to be a difference in Boost versions used in the binaries for 0.10.0 and 0.9.4. The file that fails to load is only the cache, not the keys, so if you remove the cache, the wallet will load. Bear in mind that the cache may contain tx keys for past transactions, so removing the cache will lose them.

Note: it is recommended that you keep a copy of the cache anyway, as you may need it if you need to prove a transaction (then you can tempporarily load your wallet with 0.9.4 again to perform the operation, then go back to 0.10.0).

In the hopefully near future, the wallet cache will be moved to a LMDB database, so these compatibility issues will become moot.