Why is my Monero transaction not appearing in wallet?

The wallet needs to synchronize with blockchain. In Monero, where transactions are encrypted, it means the wallet must download all the data and try to decrypt every single transaction in order to check if it received any funds.

Every wallet remembers the blockchain height at which it was synchronized last time, and each time you open it, all following blocks are downloaded. You may choose between syncing often or waiting a long time when you sync seldom.

I'll also answer two questions that may arise:

When creating a new wallet, the code estimates creation time measured in block numbers that should have been mined until that moment (a block is being mined every ~2 minutes). Then it just requests those above the level.
When a wallet is being restored from keys or mnemonic, it must download, scan and discard entire blockchain. In such situation it's worth considering to download the blockchain to permanent storage and run full node.


How to change location of the Blockchain with monero GUI?

The GUI has two ways to do that:
When starting the Daemon:

Or in the settings Page:

As a note: on Linux and OS-X it's: --data-dir /path/to/your/blockchain


Is there a reason moneroblocks.info is several days behind on the blockchain?

It appears as if the daemon relied upon by that block-explorer is currently down. Only the operator of moneroblocks can answer why it is down or when it will be working again.

For now you can rely on one of several other options such as on Monero Explorer.


Unable to send amount below one (.x) in Mac OS and Windows OS GUI

An amount below 1 has to be entered as 0.x and not as .x in the GUI. Put differently, the GUI will not accept amounts that are stated as .x

Note that we (the GUI contributors) are working on making improvements in this regard.


How do I, as a recipient, verify that my transaction actually arrived?

First, theoretical background can be found here:

Selective transparency in Monero vs Zcash

Why is the viewkey able to track incoming transactions, but not outgoing transactions?

Is there any way to construct a transaction manually?

Basically the gist is that you know a (the private view key) and R (the public tx key). As a result, you are able to compute the shared secret (aR = D') and "decrypt" the transaction.

If you are using the CLI, you ought to perform the following steps:

In the CLI type viewkey, copy the private / secret view key.
Go to this tool, which was created by core-team member luigi1111. Furthermore, "Note: this site operates completely on client-side Javascript; no data is ever sent to the web server."
Enter your transaction ID / hash in box 1. Transaction Hash:
Enter your private / secret view key in box 2. Private Key
Enter your public address in box 3. Recipient's Public Address:
Press on Check.
If it shows This address owns output        x with pubkey: y for amount: z it proves you correctly received your XMR.
Note that a typical Monero transaction contains two outputs, of which one goes to the recipient (you) and one goes back to the sender as change. Intuitively, you can only "decrypt" the output that is going to you.

If you are using the GUI, you ought to perform the following steps:

Go to the Settings page of the GUI and press on Show seed & keys. Subsequently, copy the private / secret view key.
Go to this tool, which was created by core-team member luigi1111. Furthermore, "Note: this site operates completely on client-side Javascript; no data is ever sent to the web server."
Enter your transaction ID / hash in box 1. Transaction Hash:
Enter your private / secret view key in box 2. Private Key
Enter your public address in box 3. Recipient's Public Address:
Press on Check.
If it shows This address owns output        x with pubkey: y for amount: z it proves you correctly received your XMR.
Note that a typical Monero transaction contains two outputs, of which one goes to the recipient (you) and one goes back to the sender as change. Intuitively, you can only "decrypt" the output that is going to you.

If you are using the MyMonero, you ought to perform the following steps:

On MyMonero, go to account details.
Copy the private view key (called View Key (Private) on MyMonero).
Go to this tool, which was created by core-team member luigi1111. Furthermore, "Note: this site operates completely on client-side Javascript; no data is ever sent to the web server."
Enter your transaction ID / hash in box 1. Transaction Hash:
Enter your private / secret view key in box 2. Private Key
Enter your public address in box 3. Recipient's Public Address:
Press on Check.
If it shows This address owns output        x with pubkey: y for amount: z it proves you correctly received your XMR.
Note that a typical Monero transaction contains two outputs, of which one goes to the recipient (you) and one goes back to the sender as change. Intuitively, you can only "decrypt" the output that is going to you.


Not enough spendable outputs error on MyMonero

When you send a Monero transaction the sum of the outputs used in the ring transaction will exceed the amount of your payment. Once the transaction is confirmed the change is returned to your wallet. Change like all incoming transactions is unlocked after 10 blocks.

Change:

  Monero sent as part of a transaction, but unique in that returns to your account instead of going to a recipient.

Monero does not support chained payments in the same block. Doing so would not be practical on chain. Off chain solutions would bring additional security and privacy concerns.


Are Confidential Transactions in Monero perfectly binding or hiding?

Perfectly hiding. I don't think perfectly binding even existed at the time RCT was developed (not sure, though).

As to what should be chosen, think about this:

  We can always replace lost money, but we can't ever replace lost privacy.


How does the wallet software choose mixins (decoy outputs)?

Currently, it's chosen randomly. Half the fake outputs are chosen over the whole chain, and half over the last 1.8 days. In both cases, a triangular distribution is used over the possible fake outputs based on their order of appearance on the blockchain. See wallet2::get_outs in src/wallet/wallet2.cpp.

There is a patch on Github to switch to a single set, using a gamma distribution over the possible fake outputs' age, as found to be close to the real usage distribution in a paper from Miller et al. See https://github.com/monero-project/monero/pull/3528


What are the 'Login (optional)' fields for in the GUI settings?

These fields are used to connect to a daemon requiring a username and a password (when the monerod daemon was started with the --rpc-login option).


I'm very new at this, but I think that particular block was the fork.  This means you have to be running the newest Monero software, and the first version will not sync past that point.  (I'm having a similar problem, with a different block.)


Is the GUI Safe for storing thousands of monero?

As of today's date, there have been no publicly reported losses of XMR due to the newness of the GUI, so using it is likely safe. However, the Monero-Wallet-CLI (available at https://www.getmonero.org/downloads/) has a long track record of being trustworthy and secure, so using it is best practice for significant Monero storage and transactions.

Once the GUI is out of beta, it should be good for large funding amounts as well.

That said, the truly safest way to store large amounts of Monero (for example: 5000 XMR is worth $90,000 today) is in a securely generated paper wallet as outlined by Gingeropolous here: https://www.reddit.com/r/Monero/comments/48cgmd/an_extensive_guide_for_securely_generating_an/


The paper is incorrect; it's actually mod l, not q. l is the curve order of ed25519. The primary reason AFAIK is that the code doesn't work correctly with scalars above a certain multiple of l. The random_scalar() function outputs an integer


Answering whether a mining pool (or anything in the cryptocurrency space) is safe is an especially tough challenge, but I will try to look at the things that you should consider if you are evaluating a pool's trustworthiness.

First, let's look at the pool's size:

moneropool.com currently has a reported hashrate of ~517 kH/s out of a total network hashrate of ~24.7 MH/s according to http://minexmr.com/pools.html.
According to the pool, it currently has ~135 workers.
This means the pool's workers average ~3.8 kH/s each.

For comparison, one of the largest Monero pools throughout the currency's history is monero.crypto-pool.fr, which has a hashrate of ~4.4 MH/s and ~350 workers, or 12.6 kH/s per worker.

What we can draw from this is that moneropool.com is relatively small in the grand scheme of Monero at a little more than 2% of the total network, and also that smaller miners tend to use the pool. Neither one of those things sound unreasonable, and even at 2% the pool should be able to pull in ~14 blocks per day (there are ~720 blocks each day, once every two minutes). As a sanity check, the pool's reported 11 blocks found in the past 24 hours as of this moment, but over 30 in the past 48 hours. Since some variance is to be expected, this all sounds good.

Now, lets look at some other indicators:

According to minexmr.com/pools.html, moneropool.com seems to have a somewhat sinusoidal (wave-like) pattern to its usage, with significant daily highs and lows in terms of hashrate. This could be a number of things, but a few come to mind:

One or more sysadmins mine with moneropool.com, and use unused servers and computer resources to mine at night when their systems are idling.
moneropool.com miners have found some pattern with Monero and another coin that shows that it is more profitable to mine one during the day and the other at night.
A botnet is mining with moneropool.com that relies of computer systems either idling at night or being turned on during the day.

Please note, none of those three things necessarily say anything about the pool. But they may make you more or less inclined to participate.
moneropool.com is using what has essentially become the gold standard in Monero mining pool software, Matt Little's node-cryptonote-pool (https://github.com/zone117x/node-cryptonote-pool). This seems reasonable, and at first glance nothing seems forged or off about it.
moneropool.com has a relatively small payout threshold of 0.5 XMR. This seems both reasonable and like a good way to promote a pool to small miners.
A quick whois lookup for moneropool.com shows that it was registered through Namecheap.com, a relatively common domain seller, and has been in operation since 15 May 2014, meaning it is over two years old.

Now what does all that mean?

Well, as I prefaced, it can be challenging to say with certainty that a pool is legitimate. However, a quick look at some basic stats do seem to suggest that moneropool.com is at least worth considering. My suggestion? Use it for a week with a small hashrate, then use another pool for a week, and see which pool you like better. Ultimately, there is only so much "evil" any mining pool can do.

My other bit if advice? If a pool suggests a specific miner, be sure to check with a number of other pools to see if they also suggest that miner. Then ask on reddit, bitcointalk, or here to make sure the mining software is valid. Mining software, and not the pools, are where you can really get in trouble if someone is looking to compromise your computer or wallet.


An example of transaction with at least two subaddress destinations

This is such an example transaction on stagenet where I sent 1 XMR to a subaddress and 2 XMR to a standard address (and the change goes back to myself):

https://community.xmr.to/explorer/stagenet/tx/bd82785dc41a608b9796eeca31ba6b4b8d7a9c194691c136e2baf916c66fa98a

The tx_extra contains the following information:

01                                                                # standard tx pubkey tag
3b3625cfb65842fc3e445245908f9b171b4e1899543fb70d85424fd9b1c95eb9
04                                                                # additional tx pubkeys tag
03                                                                # number of additional tx pubkeys
fc1776e142ade7a4ad5e00bd27a480013f06c45d5ac80807d3609500bdd26cf2  # additional tx pubkey 0
98705ffac66ef63d67cb5872b6fc222879902edbe7a3ccb83278c82a5fad097c  # additional tx pubkey 1
cfc1d89d5e5fba53a68a238239ebd5f60d60327d22da3ee95a9c070674ea525a  # additional tx pubkey 2

Note that no one can tell which of the three outputs are the change, the subaddress destination, or the standard address destination. Also note that the standard tx pubkey is used for generating shared secrets for destinations using standard addresses.


How do I start accepting monero at my restaurant/store?

There are two main ways you can go:

run your own Monero infrastructure
use a payment processor to do it for you

The first one has you running a Monero node and wallet, and use monero RPC to manage payment ids, track incoming transactions, etc. There are early plugins for some common store software: https://github.com/monero-integrations/monerowp/releases/tag/0.1 for Woocommerce, and a work in progress for Prestashop: https://github.com/monero-integrations/monerops, both by the same author (serhack). You can also do custom integration, and you can find instructions on using the RPC at https://getmonero.org/get-started/accepting/. Likely you will need help if you go this route, and the people in #monero (Freenode IRC) will be able to give a hand should you need to.

A variant of "doing it yourself" if all payments are face to face is to use the monero GUI alone, or Kasisto (What is Kasisto?): those have a "payment tracker", in which you can generate a payment id for a customer, and scan the blockchain for incoming payments matching that payment and owed amount.

The second one requires you to pay a service provider such as https://www.coinpayments.net/ or, at some point in the (hopefully near) future, https://payb.ee to handle Monero-to-fiat conversion.


It is normally the current blockchain height. Do you see a different behavior? How do you tell it's not the blockchain height from wallet creation time?


Can't create transaction: unexpected error: Cannot deserialize mg[i]

This is an error I've never seen before, and looks like a bug at first glance.
You should file an issue on https://github.com/monero-project/monero with the logs you can when trying to send again when using monero-wallet-gui with --log-level 2 (this will contain some private information relating to your address, feel free to replace your address with a placeholder for privacy).


How to enable pruning in the command line of the monero blockchain in version v0.14.1?

Quoting relevant part of the commit message:

  There are three ways to prune a blockchain:

  run monerod with --prune-blockchain
  run "prune_blockchain" in the monerod console
  run the monero-blockchain-prune utility

  The first two will prune in place. Due to how LMDB works, this will
  not reduce the blockchain size on disk. Instead, it will mark parts of
  the file as free, so that future data will use that free space,
  causing the file to not grow until free space grows scarce.

  The third way will create a second database, a pruned copy of the
  original one. Since this is a new file, this one will be smaller than
  the original one.

  Once the database is pruned, it will stay pruned as it syncs. That is,
  there is no need to use --prune-blockchain again, etc.


How to reduce the CPU consumption of my Monero node?

The nodes only really consume high amounts of system resources upon syncing large amounts of blocks. Thus, if you don't leave them running continuously, and only start them up occasionally, they will have a larger number of blocks to sync and will therefore require high amounts of system resources.

The simplest fix is to leave them running continuously - which is how they are designed to operate. Otherwise you can use make use of various tools, such as cpulimit.


Does anyone have test data that illustrates the CryptoNight 7 algorithm?

One simple way is to call the daemon RPC's method getblock. From this you can get the result.blob (the data to be hashed) and from the result.block_header.hash, the expected hash result.


What are some ways I can disguise my mnemonic seed?

From fluffyponyza here:

  Due to the nature of the key you can write it as part of something else - eg. write a fake love letter to your wife so that the 24 words on the left hand side are your key or whatever. Then write a bunch of extra love letters. That way, if your deposit box is ever discovered, it'll be disregarded as unimportant love letters".

Also, only the 3 or 4 first letters (3 for english, 4 for other languages)  of each word matters


Why is there a penalty on large block sizes?

If you were a bank, then I agree with you - clearing all transactions as fast as possible makes the most sense for your customers. After all, you would control all the account information, have plenty of computing power, and would enjoy all the transaction fees that go with them.

We don't want centralization, we want as many people as possible to run a full node. That includes people with laptops, older desktops, and smaller cloud instances (like AWS). Increasing the blocksize makes this difficult to achieve since every full node needs to store, validate, and propagate transactions and blocks. Bigger blocks mean more CPU and bandwidth, so there would be a decline in full node numbers. Bad!

With unlimited block sizes I could also maliciously submit invalid large blocks that take a long time to reject.

This would also benefit miners with the largest hashrate. Suppose a large mining pool mines a block with a huge number of transactions. They know it's valid and immediately start mining the next block as they send out their solved block. Being a large block, it takes additional time to validate this block and propagate it to other miners. An additional 10-20 second delay is a great advantage in a 2-minute block cycle.

So to recap, blocksize must increase over time to accommodate increasing transaction volume. The amount of increase will be debatable at any given time given the available bandwidth, and processing power of the network (nodes and miners) as a whole.


That's because your daemon isn't getting new blocks however the blockchain is advancing the reason your "falling behind" is because you are on a specific block say 100 and the blockchain is at 110 your daemon says 10 blocks behind. now a new block is found block 111 your daemon now says 11 blocks behind because it is still on block 100. So synchronisation isn't going backwards it's just stopped.


How do I constrain memory usage during initial blockchain sync

During sync, Monero will add chunks of 200 blocks at a time. The speedup gained from this quickly goes into diminishing returns as the chunk size grows, but the memory usage grows linearly, so it's possible to decrease that chunk size with the --block-sync-size N parameter. A plausible value for N is 20 instead of 200, and the speed will be similar (if you're memory starved, it could even be faster since your machine might stop swapping if it was doing so with the defaults).


If you solo mine through the GUI, version 0.17.1.9-3ca5f10f (Qt5.15.2), how or where would you get paid if you were lucky enough to earn anything?

If you do find a block, you will get a new transaction to your wallet with the block reward on it - currently about 1.1 monero. If you have several wallets, it will go to the one that was loaded at the time you started mining.


Does Monero network difficulty affect the amount of XMR I get from a pool?

Difficulty is the same as network hash rate, but expressed differently.


The Mnemonic seed is imutable. It does not change upon a version upgrade.
If your seed is recognized by the GUI or CLI, then it is valid.
Did you checked your balance before deleting your wallet file? Was it accurate?
You should see the incomming and outgoing transaction in your history after the wallet is synced. Check if nothing's missing here.


At what point will Monero forego forced hardforks

samwellj posted the answer 'hardforks are good for updating the network'.
The Monero dev's are taking a different stance on hardforks than bitcoin does, but it's a weighted decision where hardforks are announced 6 months beforehand and miners activate hardforks by sagnalling for it.

If I understand correctly, a certain percentage of miners signalling for the hardfork is what activates it. An argument in moneros favor for miner-signalled hard-forks are it's  (potentially) more decentralized mining.  If bitcoin tried that we'd be forked already


Performance comparison of Wolf's open source compared with Claymore's closed source miner

I have MSI R9 290X and on stock settings it gives 775H/s with Wolf's miner vs 790H/s with Claymore's miner with fee turned on. With -nofee 1 flag Claymore's miner shows 760H/s. Of course these numbers slightly vary.


Are there any fair strategies to dynamically adjust the transaction fee?

Dynamic fees currently do not exist yet and currently the fee is hardcoded at 0.01 XMR per KB. There is a lot of discussion on how to address this subject and core-team member ArticMine is looking into it. However, given that there is nothing concrete yet, it is not possible currently to answer your question.

One thing I've seen discussed is looking at the median blocksize as indicator of transaction volume. Intuitively, a higher median block size equates higher usage (transaction volume). In Bitcoin, as can be seen from here, the price is positively and strongly correlated with transaction volume. Therefore, this is one method that could work. However, it should be noted that the correlation in Monero is currently less strong than in Bitcoin. Although, this correlation will probably increase now that there is real-world demand for Monero (most notably darknetmarkets).


For the CLI wallet, how can I teach myself all that it can do?

Utilise the "flag" --help to see additional options regarding the software. i.e './monerod --help'


Pretty much anything could be done.

I'd been thinking about a block tree, where you'd have geographically [1] close miners mining at a low difficulty and low block time, and making their own quick chain. Every, say, 10 blocks, they'd hash their blocks (or 10 blocks in the recent past, to guard against reorgs) and a higher level set of miners would have a slower blockchain embed these hashes. Any number of levels. This would allow (A) faster confirmations on a local level without much more orphans due to the geographical (2) proximity, and (B) the ability to scale the blockchain to very distant regions. Like, you know, the actual moon.

This might or might not be similar to what Ethereum is doing, but it's certainly fun to think about.

[1] Doesn't work well with I2P
[2] Well, closeness with a metric based on ping, rather than distances


How do I restore / recreate my Ledger Monero wallet?

I've noticed some confusion lately on how to restore one's Ledger Monero wallet. I have therefore written this guide.
In case you have also lost (access to) your Ledger device, you first have to restore the 24 word Ledger mnemonic seed in another Ledger device.
Restoring / recreating a Ledger Monero wallet is fortunately fairly trivial thereafter.
GUI:

Basically you ought to follow this guide with one minor tweak to recreate / restore the Ledger Monero wallet. That is, the Restore a wallet from device option has to be selected (in step 8). This allows you to set a Restore height that is in advance of the first transaction to your Ledger Monero wallet. A detailed explanation about the Restore height parameter can be found here. For convenience, I've added a table with restore heights to the appendix.

Note: Use this work around if you cannot access the Restore height box:

There is a fix for the time being: You can access the restore height window by selecting the wallet location and pressing tab once.

CLI:

Basically you ought to follow this guide with one minor tweak to recreate / restore the Ledger Monero wallet. That is, you have to append the --restore-height flag (with a proper block height as value) to the command that is used / executed to recreate / restore the Ledger Monero wallet. A proper restore height is set by choosing a value (block height) that is in advance of the first transaction to your wallet. A detailed explanation about the Restore height parameter can be found here. For convenience, I've added a table with restore heights to the appendix.

Appendix:
My wallet was created in | Restore Height I should use
November  2020           | 2175000
October   2020           | 2155000
September 2020           | 2135000
August    2020           | 2115000
July      2020           | 2095000
June      2020           | 2075000
May       2020           | 2055000
April     2020           | 2035000
March     2020           | 2015000
February  2020           | 1995000
January   2020           | 1975000
December  2019           | 1955000
November  2019           | 1935000
October   2019           | 1915000
September 2019           | 1895000
August    2019           | 1875000
July      2019           | 1855000
June      2019           | 1835000
May       2019           | 1815000
April     2019           | 1795000
March     2019           | 1775000
February  2019           | 1755000
January   2019           | 1735000
December  2018           | 1715000
November  2018           | 1690000
October   2018           | 1665000
September 2018           | 1640000
August    2018           | 1615000
July      2018           | 1590000
June      2018           | 1565000
May       2018           | 1540000
April     2018           | 1515000


Using the rpc_access_data method Daemon RPC

This method is not accessible via the json rpc yet.
https://github.com/monero-project/monero/issues/7178


Riccardo Spagni (fluffypony) stated that the logo uses Century Gothic here.

The 'R' used in some versions (current branding package) doesn't seem to belong in the font family though. The 'E' also looks slighty wider. It's likely customized from the original submission.


What privacy or security trade offs are associated with not running your own full node?

Using a third party node has drawbacks in two main categories: privacy, and performance.

When you refresh your wallet, the daemon sends blocks and transactions to your wallet, which then inspects each transaction to see if you received any monero. If you did, the wallet will, at least currently, ask the daemon for more information about that transaction (technically, the global indices of the outputs for that transaction). This lets the node know that at least one of the outputs in that transaction is yours. Note that this is about to change,This is now fixed, and global indices will be are sent with all blocks as soon as https://github.com/moneromooo-monero/bitmonero/commit/30203f11f1581deec214e5a45ead36ac35c3a316 is merged. The result is that the daemon can not tell anymore which transactions contain inputs to the wallet.

When you send a transaction, the wallet will request fake outputs to mix with from the node. Thus, the node will know which output in a ring signature is the real one once you send the transaction: it's the one it did not supply. If the daemon did by chance supply your output, then it won't know, however. This is pretty easy to change (just request twice as many fake outputs, and pick locally), but is not done yet. This is now done: the wallet selects the outputs it wants, so the daemon only knows that one of them is the real one, but not which, which is the same as any blockchain observer can know.

Some less used commands also leak information to the node: the rescan_spent command will send the daemon a list of your outputs, to know which ones are considered spent on the blockchain. For this reason, this command is disabled by default when you are using a remote node (see the --trusted-daemon option in simplewallet).

Starting mining in the wallet tells the daemon your standard address (to get the block reward). This should not be done on a remote node, but I include this for completeness.

Performance wise, using a node that's not local is just slower. Not only is the node on the internet, but other people may also be using it at the same time, compounding the slowdown.


Downloading Monero updates using the existing Monero P2P network

It would be technically possible. However, several considerations apply:

how do you trust what you receive is really a bona fide update ? You trust the blockchain because it's got PoW with high enough difficulty, but transactions are arbitrary. There is no mechanism to authentify the origin of something on the Monero P2P network.
you don't want to put this on the blockchain. Monero is supposed to fork every six months. This would mean a number of multi megabytes blobs on the chain. At last one for Windows, which is (according to https://getmonero.org/downloads/) 48.6 MB for Win64. If you intended this to be the main update mechanism, you'd want all major platforms to have ready made binaries. Win32, Win64, Linux, Mac, and a source fallback (how this'd work is left as an exercise for the reader). So maybe 400 MB a year. It'd be a noticeable bump on the blockchain, and I've not even counted the ARM versions, etc.
if it's not on the blockchain, but just offered as a download via the Monero P2P network, then a node has a choice: either download all the updates, or download just the one for that node's architecture, thereby giving away some identifying information.
Last in this list, you would want to ensure the update really comes from someone trusted. In this case, a member of the core team (I'll ignore all problems related to changes in trust over time here). You'll want a signature with something like GPG, so you can ensure the update was signed with a key that you trust. When you do this, you could have downloaded the update from anywhere. Verifying it means you could downloaded it from nsa.gov or scammers-r-us.com, and be as safe as it you had got it directly from getmonero.org.
All that said, the advantage of having an update available via the P2P network is that, assuming Kovri, you can download the update transparently, and without letting your snooping ISP (because, let's face it, all of them are creepy peeping toms) know you are downloading a Monero update. You'd want to use a temporary one shot Kovri identity for the download though, to protect your OS configuration (I'm not sure how much fingerprinting is possible via I2P).


How to know when I get paid from mining Monero

You can check with the pool. Many pools will inform you when you stop hashing and when they make payments.


Can you lose your mined XMR from a pool?

It clearly says this in the Terms and conditions page.
"Accounts which are inactive for longer than 365 days may be deleted. Any remaining balance will be treated as a donation to the Pool."
https://minexmr.com/terms
So yes you can loose your mined coins by being inactive for long.


Will quantum computer break ring signatures?

"Normal" ring signatures aren't broken (meaning the true signer is revealed) by QC, but their security certainly is (unforgeability). However, the traceable version Monero uses (for double-spending prevention) is indeed able to be broken (meaning public key linked to key image and thus signer revealed) due to the existence of a key image.


I want to mine Monero but I do not have money for a better GPU / equipment

Firstly, if you are trying to mine for profit, that wont happen with a notebook of your spec.

Next, you cannot mine with a GPU using the Monero GUI. Only the CPU. If you want to mine with a GPU you will need to use a dedicated miner application. This said, mining with your GPU is again pointless, as the spec is very low (even if you can find a miner that supports it).

If you really want to get into mining, you are going to have to do lots more research and invest in better equipment to mine with.


What are "white" and "gray" in the peer list?

White peers are online and reachable and grey peers are offline.

The longer period of time it has been since you last used your daemon, the more grey peers you are likely to see.

White peers that fail to upgrade during a hard fork are (eventually) dropped from the network and become grey. People move and change VPS hosting providers, so peer status will always change over time.


Can someone help me understand the dynamic block size in Monero?

The constants you reference specify the maximum block size you can reach before the dynamic fee calculation is used.

Therefore, if the block size is below 300000, the full reward is granted and there is no need for the dynamic fee calculation. If however the block is larger than 300000, the dynamic fee calculation is applied. This doesn't mean a full reward is not granted, rather there may be a penalty applied.

A little outdated, but https://web.getmonero.org/2017/12/11/A-note-on-fees.html details more on how the dynamic fee calculation works.

Lastly, "dynamic block size" and "dynamic fee" are related terms. Monero does not have a maximum block size, therefore, it is a dynamic block size. However, dependent on the size of the block being mined (in relation to average block size over the last N blocks), it can only grow by a certain amount before incurring a penalty fee. This is where the term "dynamic fee" applies.


How to increase monero node connectivity?

Some suggestions...

Relying on those publicly known/advertised nodes is probably a bad idea to start with. Lots of people use those as remote nodes for their wallets for example, so I'd expect the operators make sensible use of the limit-rate-... options.

Which brings me to the next point, what limit settings are you using? You should set these according to your available bandwidth and the amount of peers you plan to connect with.

Also, don't expect that just because you started with allowing an inbound of 1024 your node will somehow instantly have 1024 connections - it could take some period to fill that many.

Lastly, and perhaps most importantly, if you're not going to run your own set of geographically distributed nodes, thus want to have fast reliable connections to other people's nodes, you are going to want to write a script to ping and/or read the data rates as reported by print_cn for the peers your node finds and kick any that are particularly slow.


monerod getting killed, out of mermory possibly?

--block-sync-size refers to the batch size of blocks to sync when downloading new blocks. It defaults to 200 blocks. With a synced up node it really has little effect as you are typically only getting/sending a few blocks at a time. However, syncing from scratch, it will of course affect how many blocks are transferred each time. Tweaking this will affect how quickly nodes sync from scratch.

It's unlikely this setting is your problem. Probably best to create an issue on GitHub with as much detail as possible (log file, crash log, version, OS etc).


Determining the number of available outputs by denomination

There is a bitmonerod command, output_histogram [[mincount] maxcount], which lists (amount, instances) pairs of outputs on the blockchain. The output is sorted by instances.

output_histogram takes an optional first parameter, which is an instances count minimum cutoff. That is, it will display all amounts with at least that many instances. The second parameter is an optional maximum cutoff. The default is to display all of them. For instance, outout_histogram 5 9 will display a sorted set of amounts for which there are between 5 and 9 intances on the chain, inclusive.

Note that this is rather slow as it reads a lot from the database.

The wallet uses this to determine which outputs can be used for the requested mixin (in that case, assuming a trusted daemon, the wallet will supply the amounts to check, which is a lot faster).


Monero cpu mining handling huge number of machines

You could setup your own mining pool using node-cryptonote-pool or something similar. Then each computer could mine for the pool


BIP32 recommends that 256 bits of entropy are used to generate a Bitcoin wallet. See https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Master_key_generation

This means that the 13 word, 128 bit seeds used in many Bitcoin wallets actually go against the recommendation in BIP32.

Monero is following the recommendations of BIP32 by using 256 bits of entropy via a 25 word seed.

I asked the author of BIP32, Pieter Wuille, why 256 bits were recommended instead of 128. He responded in the comments here: https://bitcoin.stackexchange.com/questions/72612/bip32-recommends-a-256-bit-seed-why-do-most-bitcoin-wallets-only-use-a-128-bit

He said:

  Well, being able to break an EC key with just 2^128 steps is somewhat
  theoretical. In practice, these algorithms have significant memory/cpu
  tradeoffs, and in practice would still be much slower than a straight
  2^128 exhaustive search on keys with just 128 bits of entropy. I guess
  the answer is defense in depth: less than 128 bits of entropy
  definitely hurts security. Less than 256 bits may hurt.

We therefore have an answer. 256 bits gives us defense in depth, because fewer than 128 bits of entropy may hurt security.


How to automatically start XMRig on Ubuntu 18.04?

There are many ways to do this. One simple way is via cron:

In a shell execute crontab -e then add and edit the line:

@reboot /path/to/xmrig -B [--syslog | --log-file=/some/file.log] [your other options]

Save and exit.

The -B option runs it in the background and you add either the --syslog or --log-file option so you can get at its output.

Many other Ubuntu examples of running things at startup here: https://askubuntu.com/questions/814/how-to-run-scripts-on-start-up


Is it possible to prove that two outgoing transactions were sent to the same person?

Unless the sender included such information in the transaction (ie, an unencrypted payment id that is identical in both transactions, or very specific amounts sent), it is not possible to determine that two transactions where to the same standard address.

In Cryptonote, all outputs go to a separate one time address. Those one time addresses are generated in such a way that the recipient is able to derive the private key to them using their own private key, but an observer without those private keys is unable to. Thus, the observer sees that those two transactions send N1 and N2 outputs to a set of one time addresses, but can't correlate them. Indeed, the observer cannot tell which of the outputs in a transaction go to the recipient, and which are change.

Once RingCT takes effect, even trying to spot very specific amounts will cease to be a possible avenue since amounts will be encrypted (and only the recipient of an output will be able to decrypt it).


The Monero code is built using gcc. There is no support for building with Microsoft's tools, and it is not expected to work.


When Monero is worth $10,000 will fees in xmr be the same or lower/higher?

When XMR reaches a higher price will these fees stay the same in XMR terms?

Yes, they stay the same in XMR terms. I.e. XMR fee level is not based on any exchange rate.

If so won't that cause for concern like how ETH and BTC is now with outrageous fees of $5-$50 per transaction? Basically a scalability problem.

No. The fee and scalability problem with Bitcoin happens because Bitcoin imposes a block size constraint which limits throughput, causes competition for block space and thus a fee market is present. When usage is high people are competing to get their transactions in the next block and thus pay higher fees. Monero doesn't have this problem and in fact with higher usage fees actually go down (in XMR terms).


BtcRecover is for cases where you already know most of your password or seed. If you don't remember nothing of your password or seed, this program is useless. Even all the supercomputers in the world couldn't brute force a Monero seed or correctly created password.


Kovri for all intents and purposes is dead and development towards an I2P Java Router lite alternative continues with I2P-zero and tini2p.

As of September 2, 2019, I2P via proxy is supported in Monero. To run in this mode, start monerod with the options --proxy i2p,127.0.0.1:9000 (for outbound connections) and --anonymous-inbound cmeua5767mz2q5jsaelk2rxhf67agrwuetaso5dzbenyzwlbkg2q.b32.i2p:5000,127.0.0.1:30000 (for inbound connections). See ANONYMITY_NETWORKS.md for information.


How does difficulty impact on cpu small mining?

Assuming the total hashrate is the same, both the group of small miners and the large miner have the same probability of finding a block.

That's assuming that the small miner mine through a pool where they share their hashes. Otherwise group of small miners will be at a slight disadvantage due to network latency.


Is the raw Monero blockchain file different for Linux, Windows, or Mac?

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

Even before v.0.10.0 you could import it using the tools available.

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

You can download it here. The simple structure means also that if it gets updated on the site, you can add the difference on top of the file you had downloaded in the past, without having to download from scratch. I did this using the wget tool: wget --continue --output-document=blockchain.raw https://downloads.getmonero.org/blockchain.raw


bitmonerod data-dir in a virtualbox shared folder

This will not work. VirtualBox shared folders don't support mmap, which is required for LMDB (and BDB).


Will integrated addresses ultimately replace payment IDs?

One of the biggest reasons for using integrated addresses is that exchanges no long need to require users to deal with an extra address field (the payment ID) when sending Monero. Seeing how easy it is to manage integrated addresses, being adding or retrieving the embedded payment ID from a regular address, I do say its a matter of time for it to completely replace regular payment IDs.


Can I send monero, even if it doesn't appear in my wallet?

No.

You're right that the blockchain does know that the funds exist. The blockchain doesn't know the amounts of the funds though (due to Monero's confidential transaction encrypted payment amounts), or that you own them (due to Monero's stealth addresses). If your wallet isn't aware of the funds, it will not know how to reference those funds or create the necessary cryptographic signatures in order to spend them.


Can I identify the true input of a transaction as the spender on an explorer?

Every transaction declares a key image for each ring of outputs being spent, where that key image relates to the true output being spent.

The only way to know whether that transaction is spending your output is to check whether any of the key images declared are key images for outputs you've previously received.

The only way to know which outputs you've previously received is to scan the entire blockchain for any outputs destined for your wallet.

Since explorers typically will not replicate this 'wallet-like' functionality for scanning the entire blockchain with your private view key to discover outputs you own, this would not be possible to do with an explorer.

If you have previously used a wallet to discover which outputs you own, you could make a note of the key images of any outputs you own (this requires knowledge of both your private spend and private view keys). You could then compare those key images with those presented by an explorer.


how come my Monero wallet's unlocked balance is zero?

Consider this:

The wallet receives one single transaction A of 1000 XMR.
You send out 0.2 XMR to a customer, creating transaction B.

What is the unlocked balance of the wallet now?

The answer is: 0 XMR. Why?

Transaction A had one output, which became the only input of transaction B. Inputs are spent entirely, which means that transaction B takes the only input with all of your balance and creates 2 outputs (a simplification disregarding fees):

0.2 XMR that goes to your customer,
999.8 XMR that goes back to your wallet as change output

Before B receives 10 confirmations, all the outputs, including change, are locked.

So, if you received your funds in a low number of incoming transactions, it's easy to get locked out. Basically, you may send as many instant transactions as many incoming ones have filled your wallet (another simplification). Then you'll have to wait.

Frequently used wallets with multiple small payments are more liquid due to fragmentation and high number of unspent outputs.


Formula to calculate mining earnings (PPLNS/PPS)

Calculate earnings specifically for PPS or for PPLNS is pointless as the divergence is based on how often the pool find a block. If you are trying to find an average, then both payment methods equals.

So the formula you found is the best you may have to estimate your earnings.

If you want to calculate the expected earnings from a past day where you know the time window (the N * blocktime from PPLNS) and the number of block found you have to calculate earning from each block based on your average hashrate divided by the average pool hashrate on the same time window.

A basic formula would be ((your hashrate) / (the network hashrate)) * (720 blocks per day) * (block reward) = XMR/day then - (wattage cost per day)


Am I missing something really obvious?

Yes.
Now, you don't state whether you are solo mining or pool mining so I'll cover both. You also don't state your hashrate, but given your stated hardware of only 3 CPU cores and a mid-range GPU we can use 1.5 KH/s as a modest example - i.e. very low hashrate.
Solo mining: you don't earn any XMR till you mine a block. Given your low hashrate, you're looking at years before you mine a block, not hours or days.
Pool mining: you don't get paid anything until 1) the pool mines a block in a period you were mining and 2) you have reached the pool's minimum payout threshold. So even assuming #1 (the pool has mined in a block in the last 30 hours), again given your low hashrate, you undoubtedly haven't reached any payout minimum.


Can you make contingent payments in Monero?

Indeed you can. Let's say Alice has Y XMR and Bob knows a secret s. Let's also say that there is program C that checks if s is correct (I will assume that C is known by both Alice and Bob, but this could be modified). For example, in the case of P2SH, it could check that Hash(s)=x for some x, or could check if a painting is beautiful or not.

1-4. Do step 1-4 from here to set up a time locked multisig wallet that sends Alice her funds back in 24 hours.

Bob generates keys k_1 and k_2. This keys can be either private-public or symmetric (I would recommend symmetric, since they are more secure, and smaller), and they may be the same if she likes.
Bob sends Alice z=Enc_k_1(s).
Alice and Bob do a Secure two-party computation with Alice's multisig key, Bob's multisig key, k_1, k_2 as secret input. It will first perform C(Dec_k_1(z)). If it yields false, the computation terminates with "Bob cheated, Trade Aborted" (in this case, Alice retrieves her Y XMR once the escape transactions from step 3 becomes valid). If C yields true, the computation yields Enc_k_2(transaction of Y XMR from multisig wallet to Bob, with payment id that contains k_1).
Bob decrypts and publishes the transaction from step 7, which gives him his Y XMR. Doing so, Alice can see k_1, decrypt z, and learn the information.

To see this is secure, note that:

If Alice or Bob refuses to do any of step 1-4, no valid transaction has been signed, and trade is aborted.
If Bob refuses to do 5 and 6, the trade is aborted. Alice can recover her Monero after 24 hours.
If Alice or Bob refuse to do step 7, the trade is aborted. Alice can recover her Monero after 24 hours. Alice has not learned the secret unless you she can break the AES key k_1.
In a multiparty computation, it is possible for a malicious party to learn the output and then prevent the other party from learning the output. In this case, it is only important that Bob learns the output. If Alice learns the output and prevents Bob from learning it, the trade is aborted. She can not learn anything without breaking the AES key k_2. (She will be able to recover her Monero in 24 hours).
If Bob refuses to do step 8, the trade is aborted. By not publishing the transaction, he can not get his Y XMR, so Alice and recover it in 24 hours. (She also won't be able to learn the secret.)

Note: Payment ids are 1024 bits, AES keys are 256 bits. Therefore, a random 768 bit identifier could be added to the payment id in step 7 to help Alice find (instead of having to check every payment id of every transaction).


Question about incoming/outgoing merging of transaction identity

Accounts are groupings of subaddresses for presentation purposes. There is also the side effect that when you spend out of an account, any outputs received at any subaddresses within that account may be combined. This is purely wallet logic.

Funds cannot usually be spent across subaddresses which span multiple accounts because of wallet logic. The wallet requires you transfer funds between accounts (which automatically gives you one level of churn if you do so).

Note that neither subaddresses nor accounts ever appear on the blockchain, because outputs simply appear to have random one-time public keys. You only need to worry about linkage if the same person (or colluding parties) gave outputs to you via many of those subaddresses, and are now observing the blockchain to see if those outputs are ever referenced together in a transaction. Third parties cannot make sense of anything.

Any kind of combination of outputs across subaddresses (whether from the same account or different accounts) will risk linking those subaddresses together, only in the eyes of someone that knows about outputs given to you at those particular subaddresses. There is no such thing as linking accounts together, only linking particular subaddresses together.

So the bottom line is, if you spend outputs together in the same transaction, and those outputs spanned several subaddresses, then those subaddresses are at risk of being linked regardless of whether those subaddresses were all from the same account or from multiple accounts. And again, the risk is only there if someone knows of outputs sent to each of those subaddresses, because only one-time output public keys are written into the blockchain, and addresses/subaddresses are never written into the blockchain.

Finally, if there is no prior suspicion that subaddresses may be linked, then someone is going to have to send multiple outputs per subaddress to you on multiple occasions in order to know whether they're observing random references to outputs or a real pattern. This greatly reduces the threat.

Think of it like this: every time there is a transaction, fresh notes with fresh random serial numbers are given to the recipient. Any time someone spends notes in a transaction, the whole world (via the blockchain) is told about the new random serial numbers generated, as well as the serial numbers of notes that are spent together in that transaction. In addition to the serial numbers of the actual notes being spent, the transaction also includes the serial numbers of lots of other notes that are randomly chosen from the blockchain as decoys. This means no one can be sure which notes are really being spent, but coincidences can be spotted under very particular circumstances by people that gave out particular notes to a particular person whose real identity they know. That's pretty much all the knowledge you need to be able to directly reason about the threat involved.

( answer originally provided by knaccc )


How does Monero protect users from inflation bugs if the blockchain can't be audited?

The daemon command print_coinbase_tx_sum is useful for auditing the supply (sum of all coinbase transactions).

help print_coinbase_tx_sum

Command usage:
  print_coinbase_tx_sum <start_height> [<block_count>]

Command description:
  Print the sum of coinbase transactions.

You then verify, the amount obtained from above, is less than per the Emission curve allows for. Example code to get this value for a given height here.

For anything else, you would have to audit the code (for bugs) and the math (for soundness).


Cannot get version 2 transactions to work on private testnet

As dEBRUYNE told me once on reddit:

Testnet has different forks (and fork heights), which can be found here:
https://github.com/monero-project/monero/blob/master/src/cryptonote_core/blockchain.cpp#L120

You should edit the forks height and recompile to get your testnet to the HF where it has been implemented (v5 if I'm correct for testnet).


Basic idea can be explained by simple arithmetics.
Now, we're checking that sum of all inputs must be equal to sum of all outputs. For example:

1+2+3+4 = 3+5+2

Literally, "what comes in must come out", and that's how we assert no coins were created or destroyed in the transaction.
And you can see the amounts. If you multiply everything by some random number A, you get the below:

(1A) + (2A) + (3A) + (4A) = (3A) + (5A) + (2*A).
which can be written as:

A * ( 1+2+3+4) = A * (3 + 5 + 2), so we can be sure that 1+2+3+4 = 3+5+2 still holds true.

Trick is, with ringCT, only the sender and receiver know the value of A. All the rest see only the already multiplied values (2A), (3A)... so they can check that there's no cheating, but they don't know A, so they can't tell the exact amounts involved.
Of course, it's not implemented exactly as above, but I think you can get the idea.


What does "transaction failed" mean in simplewallet?

Once the wallet creates a transaction, it can fail at several steps.

The first one is to be rejected by the daemon. This can happen if the daemon sees that transction uses already spent key images, has too low a fee, etc. Normally, this should not happen, and the ringCT branch contains fixes for a few of these problems - hopefully fixing all of it.

When this happens, the wallet will warn you with a red message when trying to send.

The second one is that the transaction will never be mined. It may be that the daemon accepted the transction, but other nodes will not accept it, or will never mine it, or simply were never told about it (the latter one could be a temporary problem if using a new daemon with an older wallet).

When this happens, the wallet will first show the transaction as pending
in the transactions history (show_transfers), while the transaction is waiting to be mined in the pool. If it is dropped by the pool, and was not added to the blockchain, this status will then change to failed. At this point, you used to need to run rescan_spent as the wallet became confused about which coins were spent and which were not, but this is now fixed in the RingCT branch (this one does seem to fix a lot of things, doesn't it).


They are all group elements (hence the ge_ prefix) and are different representations.

From some ed25519 source:

ge means group element.

Here the group is the set of pairs (x,y) of field elements (see fe.h)
satisfying -x^2 + y^2 = 1 + d x^2y^2
where d = -121665/121666.

Representations:
  ge_p2 (projective): (X:Y:Z) satisfying x=X/Z, y=Y/Z
  ge_p3 (extended): (X:Y:Z:T) satisfying x=X/Z, y=Y/Z, XY=ZT
  ge_p1p1 (completed): ((X:Z),(Y:T)) satisfying x=X/Z, y=Y/T
  ge_precomp (Duif): (y+x,y-x,2dxy)


List of common Monero terms and definitions

There are several lists, each of which is community generated and a work in progress. Since Monero technology continues to evolve, there will always be a need to add additional terms, and in some cases depreciate old ones that are no longer used.

This stack has a list of Monero tags that is continually user updated with new and improved definitions

Moneropedia on the official Monero website has many important definitions but is in need of more. Community members are encouraged to build upon the current Moneropedia list.

The Monero and CryptoNote wikipedia pages are also helpful community generated resources for learning the meaning of Monero terminology.


Connecting to remote daemon in testnet is not working

the current code on testnet.xmrchain.net does not allow transfers (it's a bug which is fixed but not yet deployed there). just run your own testnet node.


To add to the answer provided by fluffyponyza. Hard drive IO is a major bottleneck with synchronizing the blockchain. As an example synchronizing on my desktop took approximately 50 hours on a traditional 7200 rpm disk drive. My laptop was able to fully synchronize the blockchain from scratch in 2-3 hours on its SSD.


Is the syncing time a good benchmark to evaluate Monero resource requirement with high tx/s?

It's going to vary quite a bit between machines, the CONOP (Cost Of Node OPeration) should hopefully average out such that the tps of any given day will be reflective of the number of nodes in operation to verify and relay those transactions without performance degrading to the point that miners lose money.

This video on dynamic blocksizes and CONOP breakdown to determine decentralisation and scaling may provide some useful info on the subject.


Can the concept in a hardware wallet like ledger unplugged be ported over to Monero

I'm not a expert but it seems to me that since the source code is out there for the ledger unplugged it might not be that hard to port over.

That might be the case if Monero was a Bitcoin clone. However Monero uses a completely different codebase than Bitcoin. The Ledger firmware that works for Bitcoin is completely different than what would be needed for a Monero implementation.

If there is sufficient demand for another hardware option after the Monero Trezor firmware is merged by Satoshi Labs then maybe a Monero developer would consider working on Ledger firmware at that time. Monero developer, NoodleDoodle would like to see his Trezor firmware code updated for RingCT compatibility before being merged. Therefore, a large amount of developer focus given to Ledger is unlikely to come soon.


Impact of Collective Code Construction Contract on Monero development

C4 is a ZeroMQ spec inspired by Pieter Hintjens and the Monero ZeroMQ implementation meant meant to provide a

  reusable optimal collaboration model for open source software projects

According to the specific spec the goals are:

  To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
  To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
  To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
  To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
  To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
  To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.

For purposes of Monero development the C4 process going forward is designed to look like this:

  for i = 1 to 180 days               # 6 months of 30 days each, this is a magic for loop that knows when a day passes
  for i = 1 to 180 days               # 6 months of 30 days each, this is a magic for loop that knows when a day passes

  new PR gets eyeball review
  PR is merged to dev branch
  if merge == crap, new PR made to address crap, goto 1. elseif, goto 4
  if i == 180, merge to master. elseif, goto 1

Compared to historical practices the above will help reduce the workload of some Monero core developers, whose previous practice was to thoroughly review each new PR upon submission. In the past PRs often went to master right away and in the new system they will sit in dev branch for quite some time before being moved to master. This will allow more time (and eyeballs) to review the code long before it has have potential to do harm in master.

This process should be more welcoming to developers new to the XMR codebase who don't need to worry about immediately breaking something in master or requiring a lot of time from the core development team to thoroughly review their PRs right away.

The system is not perfect and it is still possible that hard to detect malicious code could eventually by merged into master, but there are safeguards in place to minimize this risk. On balance the benefits of inclusion and efficiency outweigh the risks in the opinion of the Monero core development team.


In Javascript, how can one verify a signed message using a provided monero address?

Check out Lugi's repo. There's a page sign.html which will have the code you need.

  generates and verifies signatures on arbitrary data using one of your account private keys (spend key or view key)

The same tools are hosted here for experimenting: https://xmr.llcoins.net/sign.html


How do I check my public facing remote node is up and running via a web browser?

You can easily test via the daemon RPC interface. Assuming default ports used, you can browse to:

http://x.x.x.x:18081/get_info

Replacing x.x.x.x with your servers IP address. This will return some JSON like follows if the node is up and there are no firewalls blocking it:

{
  "alt_blocks_count": 0,
  "block_size_limit": 600000,
  "block_size_median": 85,
  "block_weight_limit": 600000,
  "block_weight_median": 85,
  "bootstrap_daemon_address": "",
  "cumulative_difficulty": 49806683508,
  "database_size": 2565951488,
  "difficulty": 68748,
  "free_space": 92892508160,
  "grey_peerlist_size": 373,
  "height": 1138572,
  "height_without_bootstrap": 1138572,
  "incoming_connections_count": 0,
  "mainnet": false,
  "nettype": "testnet",
  "offline": false,
  "outgoing_connections_count": 8,
  "rpc_connections_count": 1,
  "stagenet": false,
  "start_time": 1548297116,
  "status": "OK",
  "target": 120,
  "target_height": 0,
  "testnet": true,
  "top_block_hash": "398f1733354f8371440d9ecb9947e69f7a615353f32c630b220083bb674192af",
  "tx_count": 57606,
  "tx_pool_size": 1,
  "untrusted": false,
  "update_available": false,
  "version": "0.13.0.0-master",
  "was_bootstrap_ever_used": false,
  "white_peerlist_size": 43
}


How can someone verify funds in a XMR wallet usint public viewkey?

A view only wallet only allows seeing incoming transactions.

https://src.getmonero.org/resources/user-guides/view_only.html

  A view-only wallet can only see which incoming transactions belong to
  you. It can not spend any of your Monero, in fact it can't even see
  outgoing transactions from this wallet. This makes view-only wallets
  particularly interesting for

  Developers writing libraries to validate payments End users validating
  incoming transactions to cold wallets

To check a transaction on the blockchain (like with your linked service), you need either the transaction private key or the wallet private view key.

To be clear, you cannot track transactions on the blockchain with only a wallets public view key.


What is the CLI command to make use of tx_extra field in a transaction? And how does one retrieve this data back on the receiver's end?

The wallets only add specific data to tx extra (e.g. tx public key, payment ID etc) and do not offer options to embed arbitrary data. If you need to add your own arbitrary data, such as your example of embedding a Bitcoin address, you will need to manually construct and broadcast the tx. Of course, embedding something like this will make your tx stick out, which kind of defeats the purpose of using Monero in the first place.


There is a block size limitation.

The maximum block size is variable, and a function of the size of the previous blocks.

More precisely, the maximum block size at a given height is the maximum of (1) 60000 bytes and (2) twice the median size of the last 100 blocks.

The intent is that, as transaction traffic increases, blocks fill up. When enough do, the maximum block size will increase too. When transaction traffic decreases, block size goes down, and the maximum block size will follow, up to the 60000 bytes limit.

This prevents an attacker from submitting lots of transactions to overwhelm the network at once, while allowing some artificial space scarcity to create a fee market.


There is no command to permanently ban, but you can set a lengthy ban time using the daemon command ban <IP> [<seconds>], or using the RPC method set_bans.

So if you set the seconds parameter to 4294967295, that will ban for just over 136 years.


Previously, a method to prove a payment would have been just to reveal the TX secret key r. This worked, because someone knowing the r and the destination address can only unmask destination one-time keys (aka output) in that particular TX and verify that funds sent to some one-time key were indeed sent to a correct address.

Problem is, if you reveal r, it's out in the "public". So while anyone can verify the destination, how can you confirm who the sender is? If now both you and me know your r, I could claim I'm the sender, and you'd have to go through extra hoops to prove me lying. So until now, proving that you're the sender relied on the assumption that you didn't already leak the r to someone else.

With the new method, you can also prove the destination and amount sent, but without ever revealing r. Instead, it uses r to sign a message which can be verified by anyone using the public TX key R. Also, it uses the shared secret rA to prove the amount. Shared secret is not public, but it's not really a problem to reveal it considering the recipient already knows it. Also, if recipient made his view key a public, then ALL of his shared secrets are also shared with the public anyway (because rA == aR). Revealing rA works like a selective view key - it reveals only what's in some particular TX. However, you get to keep the r private and thanks to that you'll still be the only one able to produce the signature.

There's another way to prove who the sender is, but whether it's useful is yet to be seen as it can't prove the destination without support from the recipient: https://github.com/monero-project/monero/issues/2065


Support for a Ledger Nano S Recovery Plan B?

The original answer is found at https://github.com/LedgerHQ/ledger-app-monero/tree/master/tools/python.

For OSX hosts, to complement the ledger-app-monero documentation, the Homebrew package manager's brew command is used instead of the apt command to install two dependent packages. The ledger-app-monero application has a dependency upon the libusb and libusb-compat packages that can be installed using:

% brew install libusb libusb-compat

The Advanced Package Tool package manager's apt command is frequently used for Ubuntu and Debian hosts. Those hosts need the libusb-dev and libudev-dev packages to be installed, per ledger-app-monero documentation.

After cloning the ledger-app-monero package and satisfying documented pip3 python package dependencies, change into your local the ledger-app-monero/tools/python/src directory and execute the following:

% python3 -m ledger.monero.seedconv offline

Unfortunately, the results for the README.md 12 word test vector did not match.  Here are my results that are also embedded in code here.

BIP 39 Test Vector with no passphrase:
abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about

Test Vector Monero Electrum words:
tavern judge beyond bifocals deepest mural onward dummy eagle diode gained vacation rally cause firm idled jerseys moat vigilant upload bobsled jobs cunning doing jobs

Independently validated the Monero seed words synthesized using ledger/monero/seedconv.py (that was supplied with the same 24 BIP 39 seed words and a BIP 39 passphrase used to configure a Ledger Nano S) were successfully loaded into Monerujo and CakeWallet mobile wallets and the same addresses appeared in both software wallets and a Nano S.

For the same test vector above, the m/44'/128'/0'/0/0 technique shown below using bitcoin-explorer is documented further here.

% echo "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" | bx mnemonic-to-seed -p "" | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 128 |  bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | ./kec256 | ./xmr

Seed                 : 907cf0eb0e0bbd761a7ed9bc8777fa5530e8262792a3e718533a1a357a1e4199
Private Spend Key    : 3b094ca7218f175e91fa2402b4ae239a2fe8262792a3e718533a1a357a1e4109
Private View Key     : 0f3fe25d0c6d4c94dde0c0bcc214b233e9c72927f813728b0f01f28f9d5e1201
Public Spend Key     : dae41d6b13568fdd71ec3d20c2f614c65fe819f36ca5da8d24df3bd89b2bad9d
Public View Key      : 865cbfab852a1d1ccdfc7328e4dac90f78fc2154257d07522e9b79e637326dfa
Monero Address       : 49vDbkSo7eve3J41sBdjvjaBUyz8qHohsQcGtRf63qEUTMBvmA45fpp5pSacMdSg7A3b71RejLzB8EkGbfjp5PELVF2N4Zn
Electrum Seed Words  : tavern judge beyond bifocals deepest mural onward dummy eagle diode gained vacation rally cause firm idled jerseys moat vigilant upload bobsled jobs cunning doing jobs

Here is an update concerning Trezor Model T Monero capabilities:

When contrasted to the Ledger Nano S and Nano X, the Trezor Model T uses a different HD path and replaces the secp256k1 elliptic curve with the ed25519 elliptic curve when computing a seed for the m/44'/128'/a' HD wallet path, see https://github.com/trezor/trezor-core/tree/master/docs/coins#list-of-used-derivation-paths.

The default primary address a Model T uses follows a different path and complies with SLIP-10 and the application of the ed25519 curve (not the secp256k1 curve) when computing HD keys. This creates an BIP 39 seed word wallet restoration interoperability issue between Ledger and Trezor hardware devices:

% trezorctl monero-get-address -n "m/44'/128'/0'"

44jKQv6ZKMd5ecLLmkNJGi7azgSptEq8ki7TFiat1TfLfdDQ1tQ7ZYa3cRh7X2uRwvLDjddWh97ajeyhR2seKSECQeDx1WR

The trezorctl Python command above queried a Model T, previously configured with the "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" seed words, for its root level Monero address of account number 0.

Since libbitcoin's bx command is not currently SLIP-10 enabled to directly support the ed25519 elliptic curve (bx only implicitly supports the secp256k1 elliptic curve), custom code needed to be developed to mimic SLIP 10 ed25519 behaviors. The following independently developed code of piped command lines generates the same result as Trezor hardware wallets.

% echo "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" | bx mnemonic-to-seed -p "" | ./slip10 --ed25519 | ./slip10 -i 44 | ./slip10 -i 128 | ./slip10 -i 0 | xmr

    Seed                 : 98f0cdd5993ce34eb46b57c1fa6399f6643516416fae089d74ecfd0c389a6bd8
    Private Spend Key    : 8f2d521d4334f4d5d174c47aacb346e7633516416fae089d74ecfd0c389a6b08
    Private View Key     : 84b0087a63854856686f80596a5a1a6090795b4d1311139173262170d7e7180f
    Public Spend Key     : 51fd81faa5e2641bca8a5c43d764ab276033c12b459fd9f5c9c23b7733af67e6
    Public View Key      : eb8855fd7d21670f9bdfc0cdcfa54172e80322c4eaee5ce30d85cb9ec90d21d1
    Monero Address       : 44jKQv6ZKMd5ecLLmkNJGi7azgSptEq8ki7TFiat1TfLfdDQ1tQ7ZYa3cRh7X2uRwvLDjddWh97ajeyhR2seKSECQeDx1WR
    Electrum Seed Words  : symptoms ugly ablaze anchor roster neon feel gemstone spud plywood extra daft alchemy apart fowls dexterity puck films liquid vigilant yesterday people awful blender plywood

The SLIP 10 path above is applied to generate a Monero seed that then must be little-endian normalized/reduced to ed25519's curve order 1000000000000000000000000000000014DEF9DEA2F79CD65812631A5CF5D3ED using Monero's sc_reduce32() function to produce a private key.

% echo 98f0cdd5993ce34eb46b57c1fa6399f6643516416fae089d74ecfd0c389a6bd8 | sc_reduce32
8f2d521d4334f4d5d174c47aacb346e7633516416fae089d74ecfd0c389a6b08

Eventually there will be independent bx open source code made available to implement implement SLIP 10's ed25519 behaviors that Satoshi Labs  defined openly.


There were two main reasons outputs were called dust:

small outputs (typically well below 0.01, which is the fee per kB)
"complex looking" amounts, such 0.000013852456

The problem with the first type is that they might not "pay for themselves" in fees. Since fees in Monero are 0.01 per kB, if you use only small outputs, you may end up with a transaction with a sum of inputs that is below the needed fee.

The problem with the second type is that these weird non-denominated amounts are unlikely to have other outputs of the same amount on the blockchain, so they can't be spent in a mixin > 0 transaction.

With RingCT, the first problem stays. However, such outputs are much less likely to be created again. The second problem is gone altogether, since RingCT outputs can mix with any other RingCT output, regardless of their actual amount, since an external observer (including miners) cannot know its actual value.

Thus, the dust problem pretty much vanishes with RingCT. If you still have very small outputs that can't "pay for themselves", they can be spent alongside a larger input, and create a large "funny looking" rct output. But funny looking outputs are no more a problem with mixing, so it's all fine now.

After hard fork 5, when pre-rct transasctions are typically forbidden, they will still be allowed if spending unmmixable pre-rct inputs (ie, the rules that currently allow 0 mixin txes).

If you somehow end up with a very small rct output, then it will have to be spent alongside a larger one to meet the fee. There are no plans to "unmask" an rct output's amount. If you somehow end up with only very small rct outputs, then:

they're pretty much worthless anyway
you can wait for monero to become very expensive, in which case fees will go down


How do I get a testnet wallet in Monero GUI?

You can select Testnet as network parameter in the wizard (setup) of the GUI (under Advanced options). See this part of the Monero GUI guide and corresponding screenshot.
https://github.com/monero-ecosystem/monero-GUI-guide/blob/master/monero-GUI-guide.md#create-a-wallet
In case you choose to use a remote node, make sure to connect to a testnet remote node.


Are the LMDB files cross-platform compatible?

As of v0.10.0, yes the LMDB files are cross-compatible between 32 and 64bit architectures. They have always been cross-compatible between OSs. They are still byte-order dependent but almost everyone uses little-endian CPUs these days so it's not much of an issue.


How can I add Monero to wallets such as Atomic/Exodus/Coinomi using the ERC-20 Eth contract address?

Coinomi supports every ERC20 token. If the one you want to store isn't already on the "Add tokens - Ethereum" list in the app you can follow the instructions here to manually add the token wallet: https://coinomi.freshdesk.com/support/solutions/articles/29000009779-how-to-manually-add-an-erc20-token-


How do I create a stealth address using the cli monero wallet?

You don't, it is created for you when you send. You don't see stealth addresses directly unless you look at a block explorer. Every new output you send is sent to a new one-time stealth address that the recipient can derive the private key for.


How do I allow incoming connections to my node running on Tor?

Monero does not have an hidden service as Bitcoin does. This would be needed in order for an external client to connect via Tor. Allowing clients to connect via clearnet would need code changes in Monero so outgoing connections could be made via Tor, while listening for incoming connections could be made normally. Alternatively, allowing proxy connections should also work. None of these things are done in monerod.


How to prove my Monero balance to the world?

This is only feasible with the latest simplewallet from https://github.com/monero-project/bitmonero/, which adds a couple new commands for this (export_key_images and import_key_images).

You, who want to prove balance, need to do a few things:

in simplewallet, run export_key_images key-images

This will save a signed list of key images to the file key-images.

Send the auditor(s) (or make public) your wallet address, the view private key of that wallet, as well as the key-images file you just made.

The auditor then creates a view wallet for your key:

./simplewalet --generate-from-view-key

There will be prompts for address and view key. Then run this command in simplewallet: import_key_images key-images

Include a path to the file if it's not in the current directory.

If all goes well, the view wallet's balance will match the original one.

See Can I fake a balance by giving the view key to an auditor but omitting some transactions and key images? for more information why this cannot be gamed.


Discrepancy CNS006 and CryptoNote whitepaper one-time key generation

The CNS006 is correct. In the past outputs had to be split into denominations and without concatenations that'd generate multiple identical outputs (of different amounts) to the same wallet, effectively burning all but 1. With the concatenation, it's guaranteed that outputs will be unique, even if going to the same address.


How do I safely shutdown the daemon in ubuntu?

There is no problem in forcibly stopping monerod, the daemon is constantly writing the received blocks into the disk and LMDB is one of the most robust databases on the market, it doesn't corrupt easily unless there is a hardware problem, only thing that doesn't get saved are the IP bans but this will be fixed in a next release.
To make sure everything is saved type exit in the daemon window.


Why are rich lists impossible to create for Monero?

Using a combination of ring signatures (collections of cryptographic signatures with at least one real participant in each group) and stealth addresses (requiring the sender to create one-time addresses for every transaction they make), Monero effectively obfuscates transactions and account balances on the blockchain thus eliminating any possibility of "rich lists".

RingCT, which is currently under active development, will add further layers of anonymity to Monero transactions.  Here is a link to the RingCT whitepaper: https://eprint.iacr.org/2015/1098.pdf

To respond to your second question, Monero's viewkey (a private key that shows all incoming account transactions) allows for optional transparency, thus allowing organizations to publish proof of their XMR holdings (but not grant spend access since the viewkey is more of a "look, but don't touch" tool).

In this sense, Monero is private by default due to its ring signatures and stealth addresses, and it is optionally transparent by way of the viewkey.


No, not at all. Bitcoin ASICs are designed with the singular purpose of performing Sha-256 hashing - it's literally written in the silicon. Monero uses the Cryptonight hash function which makes use of AES encryption and several hashing algorithms, Keccak, Blake-256, JH-256, Groestl-256, and Skein-256.

Reference: https://cryptonote.org/cns/cns008.txt


In Monero, coins are received to a unique, one-time stealth address. The formula for stealth addresses is as follows:

P = Hs(rA)G + B

Where:

P -- the final stealth address (one-time output key, the destination where funds will actually be sent);
Hs* -- a hashing algorithm that returns a scalar (i.e., the hash output is interpreted as an integer and reduced modulo l);
r -- the new random scalar Alice chose for this transaction;
A -- Bob's public view key;
G -- the standard Ed25519 base point;
B -- Bob's public spend key.

You provided us with the private view key (a) and private spend key (b), and the public view key (A) and public spend key (B). In addition, we have the base point (G). It should be noted that you forgot to reduce modulo l your private view key. Your correct private view key (a) is:

faa5defce980fdbd03b9dd4841371dfcdc1f2fc6f1145de131fd52a5b468790d

This gives the correct public view key (A), which is:

3c450f27cd6849d9130addb2c566d910c5ef9bf4cecaed547004496fda52a4ff

I don't know what you used to get to your public spend key (B), but it returns differently for me, namely:

b66991d7d7c68513533d0560f820d75adfb0911487ba62274b759f7b3ccd4a90

For what it's worth, the curve constants from the CryptoNote whitepaper can be seen here. Note that for a dual-key stealth address to be created, the sender (Alice) does ECDH (Elliptic curve Diffie–Hellman) with her randomly-chosen r (private tx key) and the receiver's (Bob) public view key, A. This is point D (D = rA), which is a shared, secret point known only to Alice and Bob (D = D'). Thus, no one other than Alice or Bob is able to compute D. Second, Alice uses D to generate a new scalar, f, with f = Hs(D). Third, Alice computes F = fG. Lastly, Alice computes P = F + B (Bob's public spend key). Note that F is equal to Hs(rA)G in the formula above.

Back to your question. You first have to generate a random r, which can be done as follows in the Chrome console using Javascript on this page. Since you already generated a random private spend key, we only have to generate a random r. This can be done by using random_scalar();. Using this I get:

9f558def5f918481f3c130d4cbea908f0cef9aedc5f5b259bb18b3b9ea4e5b0e

The public tx key (R) is then:

11f63287b184708fd40618154a19afa35e2366ef22417223e8feac1639b68ace

For what it is worth, the public address is:

48Y3H2eSZ6C4EUjY1B5viSGCbCLPcmMiy7aD69yqUsaHR8GLE3rvSwrdJtpZYG1peC3oipCqfUvCcF89i86kuEjVVr5GCdj

Thus, to summarize, our "start" variables are:

var b = "198584347013dd91832be3d82529437db7cc8e1850e559cdd3872b29ca819601"; |  Your private spend key
var a = hash_to_scalar(b); | Your private view key (deterministic derivation) | a = "faa5defce980fdbd03b9dd4841371dfcdc1f2fc6f1145de131fd52a5b468790d"
var B = sec_key_to_pub(b); | Your public spend key, this function multiplies base G by its input | B = "b66991d7d7c68513533d0560f820d75adfb0911487ba62274b759f7b3ccd4a90"
var A = sec_key_to_pub(a); | Your public view key | A = "3c450f27cd6849d9130addb2c566d910c5ef9bf4cecaed547004496fda52a4ff"
pubkeys_to_string(B,A); | This will return your public address | Public Address = "48Y3H2eSZ6C4EUjY1B5viSGCbCLPcmMiy7aD69yqUsaHR8GLE3rvSwrdJtpZYG1peC3oipCqfUvCcF89i86kuEjVVr5GCdj"
var r = "9f558def5f918481f3c130d4cbea908f0cef9aedc5f5b259bb18b3b9ea4e5b0e"; | private tx key
var R = sec_key_to_pub(r); | Public tx key | R = "11f63287b184708fd40618154a19afa35e2366ef22417223e8feac1639b68ace"

Now let's create a stealth address! This is done as follows:

var D = generate_key_derivation(A, r); | ECDH, rA | D = "b2896554aa33603868b4c5d106f4873620aabb96d22bc236192f1bcfa38451bb"
var f = derivation_to_scalar(D, 0); | 0 is the output index. The standard method combines these last few steps into one, but for clarity they are split here | f = "236b65c107cf838db70d41f5e795e526e2043f471d2b2daefa24fb4b22f0340c"
var F = sec_key_to_pub(f); | F = "2dd26c9941f5fe2aeeab30d2ebc41dd21241cb4d4327c27588bde076a0e893f4"
var P = ge_add(F,B); | "ge" means group element. This function adds two points together. Note that F is Hs(rA)G | P = "b696760c160efa648d681a7a65cdee3c5f0c23d3866c08c90473021d7892f1a3"

P (b696760c160efa648d681a7a65cdee3c5f0c23d3866c08c90473021d7892f1a3) is a valid stealth address. An image of the aforementioned steps performed in the browser console on https://xmr.llcoins.net can be seen here.

Note, however, that in Monero the stealth addresses are created by the sender and not by the receiver. Thus, those last four steps are performed by the sender (Alice) in Monero.

Sources:

https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-introduction

https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-part-2-stealth-addresses


You don't need to "login" to pool per say. Username is almost always your wallet address. Password can usually literally be anything, something you can use to identify which of your machines is mining. Most pools allow you to use the format anything:you@example.com so you can get alerts and such like at your email address.


Monerobase is run and maintained by community member Aerbax.
Anyone is free to create an account and contribute to the wiki.


If you get the daemon up and running after building it then you could just write a script to run git pull and check if there's any updates and if so rebuild then restart the daemon. Or similarly if you're just downloading a binary check the hash of the binary file every day or week to see if it's changed, and if so download new version, stop old one, and start new version. I don't think there's an easy out of the box solution for this though, probably going to have to kind of roll your own.


Unable to connect to monero-wallet-rpc from code

You are trying to use digest authentication in your javascript but the wallet RPC uses basic authorization.


Will the RingCT fork make it harder for other CryptoNote coins to merge improvements made to Monero?

Yes, it will. Every time a substantial change is made in one fork, the other forks will find it more difficult to port anything they might want where it conflicts.

I'd say the main change from the point of view of mergeability between forks was the LMDB change, which rewrote a large part of the blockchain handling.

Cryptonote has also changed a lot since Monero forked, and it would also be difficult for Monero to merge code from newer forks.

I don't think there's been a particular desire from other CN projects to merge code from Monero, however. Some things were merged (payment id related code, some fixes), but I don't think it was that much. Same as Monero did not merge XDN's messaging, for instance.


What is the best hardware wallet for Monero?

Currently, there are not any hardware wallets with Monero compatibility. Ledger and Trezor have both expressed interest in adding Monero support but nothing is forthcoming, at least that is public knowledge.


Can I generate a spend-proof with a cold-wallet?

You cannot prove you have spent anything until you broadcast a transaction. So you'll do this on your hot wallet, when you broadcast the transaction. See this answer for how to prove a payment.

For performing a cold and hot wallet tx, see this answer, and do the get_tx_key txid after step 11.


Is public testnet for RingCT planned prior to its release?

There will be a public testnet once there is some code review.
I'm not sure whether the code will be merged prior to the public testnet or not. If it is, then you will be able to pull from master and run in testnet mode. If not, you will have to build from moneromooo's branch. From today's dev meeting, the testnet should happen a few days after the PR receives basic reviews, with more reviews hopefully continuing parallel to the testnet. It is expected that the testnet walk through forks quickly to get to the point where Ring CT transactions are available (in mainnet, it should be half a year, though there was talk about possibly making them available earlier).


Understanding the `set` command in monero-wallet-cli

If you type help into monero-wallet-cli it will show you all available options for set with a bit of explanation for each of them and their options. That is:

set                  Available options:

seed language - set wallet seed language;

This is the language of your 25 word mnemonic seed. The default language is English as far as I know and also what most people choose.

always-confirm-transfers <1|0> - whether to confirm unsplit txes;

If this is set to 1 if will ask for confirmation before sending the transaction. If set to 0 it will not.

store-tx-info <1|0> - whether to store outgoing tx info (destination address, payment ID, tx secret key) for future reference;

If this is set to 1 it will store outgoing transaction info. Note that the tx secret key is quite important to save, since it is able to prove that you paid someone in case of a dispute. Bitsquare also requires the secret tx key in case of dispute

default-mixin <n> - set default mixin (default default is 4);

This is fairly straightforward.

auto-refresh <1|0> - whether to automatically sync new blocks from the daemon;

If this is set to one the wallet will refresh automatically when it is connected to your own daemon or a remote daemon. Note that the daemon is monerod. If this is set to 0 you'll have to type refresh once in a while to get new blocks.

refresh-type <full|optimize-coinbase|no-coinbase|default> - set wallet refresh behaviour;

I am not entirely sure about this one, but I think if it is set to no-coinbase it won't scan coinbase transactions for outputs / transactions that belong to your wallet. Conversely, optimize-coinbase will look if the first output of the coinbase transaction belongs to your wallet and if not it will skip it. I'd advise to not change this unless you know what you are doing.

priority [1|2|3] - normal/elevated/priority fee

These are simply multiples of the default fee. That is, priority 1 / normal fee is the default fee, priority 2 / elevated fee is the default fee multiplied by 20, and priority 3 / priority fee is the default fee multiplied by 166. This should be left to normal currently, but might be convenient in times the blocksize is ramping up and blocks can be quite full. Bear in mind that the adaptive blocksize algorithm allows the blocksize to grow, but there could still be a few hours that blocks are somewhat "full".

It's fairly trivial to change them. If you want, for instance, to set confirmation for your transfers you have to type the following command into monero-wallet-cli:

set always-confirm-transfers 1

Similarly, if you want to turn it off:

set always-confirm-transfers 0


How do I know if Monero is running on Putty?

Once you have PuTTY open and you have an SSH connection to your VPN server try the following commands:
Download the current Monero Core binaries
wget https://downloads.getmonero.org/linux64
Make a directory and extract the files
mkdir monero
tar -xjvf linux64 -C monero

Keep monerod running forever by using Linux Screen
screen -S myFullNode

This ensures that when you close the PuTTY SSH connection the node will continue to run. There is an optional flag for monerod --detach but I don't use this.
It should be installed already, if not yum install screen

Launch the daemon
cd monero
./monerod

Return to main terminal to run your wallet or w/e
Ctrl + a + d
cd monero
./monero-wallet-cli

Make a new wallet, open an existing wallet or w/e

To view your monerod node
screen -r myFullNode


The block will not be rejected if it's included in a block mined by another miner who accepted it. See src/cryptonote_core/tx_pool.cpp, line 137 (or just after FEE_PER_KB).

This implies a miner is free to mine transactions with a fee lower than this, and any block found with such transactions will be accepted.


Which keccak algorithm does Monero use in its initial has function?

Monero uses keccak-256, where 256 refers to the bit length of the hash produced.

Note that SHA-3-256 is slightly different, and so will not produce the same result as keccak-256.

This library will produce the correct hash: https://www.npmjs.com/package/keccak


When using integrated_address, does the sender HAVE to include the random payment ID?

The network will absolutely accept it just fine; it doesn't know if a Tx is supposed to have a payment ID or not.

However, if a receiver is giving you an integrated address, they are probably expecting to receive a payment with that ID attached. If that ID isn't included, the transaction might not be properly recognized by them.


Is it viable to attack Monero by artificially bloating blocks and make it harder to run a full node due to the increased blockchain burden?

The largest size of the next block is limited to 2x the median size of last 100 blocks. Creating a block this large imposes a penalty equal to the block subsidy, so the miners entire revenue would have to come from transactions, thus the transaction fees would have to be at least as large as the block reward to entice the miner.

Realistically, a miner would only mine the larger blocks for more money, not just the block reward, so let's assume that you'd need to pay 2 x the block reward in fees to incentivize miners.

The current block reward stands @ ~5.5 XMR per minute, or ~11 XMR per block. Under our assumption, the attacker would need to pay 11 XMR every 2 minutes (block time) to get his ever increasing blocks. With 200k XMR, he could keep this up for about 18,000 blocks, or 25 days.

Based on a spam attack in 2014, a day is enough for that limit to double, so we're looking at blocks that would be about 25x as large by the end of the attack.

In my opinion, 25x is purely theoretical because we would never approach that since there are multiple costs/incentives at play that change as the blocks grow ever larger and the block reward gets pushed off.

First you have the storage of the penalty XMRs waiting to be paid out to a miner that mines a smaller block (I'm not super fluent on the penalty payout, so someone please correct me if I have this wrong). Then you have the increasing CONOP that comes with larger blocks, which will incentivize miners to require even more then 2x the block reward to mine another larger block. All of this acts to effectively reduce the time of the attack. I'm not sure how the numbers all break down, but I'm relatively certain that the incentives are such for all involved that there wouldn't be this death spiral to infinity GB blocks.

Edit: if the penalty is cumulative then the attack time shrinks significantly since the attacker would need to pay more than the accumulating reward every block to keep up the attack.

Also, once the attacker runs out of money, the block size would come back down (adaptive block sizes are awesome).


How often does Getmonero.org update its source code?

Given that Fluffypony updates the website, he is basically the only one that can give you a certain answer. However, usually the site gets updated shortly after the pull requests are merged.


Why will the v5 fork raise the min block size to 300,000 bytes?

@Jollymort will probably answer this better but the current dynamic size algorithm didn't work well with RingCT transactions. It worked well with non RingCT transactions, which were smaller.

Once a miner has put enough transactions in a block to reach the median size of the last 100 blocks she faces this decision:

add one more transaction, which, in case of RingCT, is about 13kB, get the associated fee and pay a penalty
push the block without going above the median block size

The only situations where option 1 makes sense are when:

the fee of the additional block is at least as much as the penalty, or
the daemon that the miner is running is altruistic

At the moment, the first situation is rare and the penalty is generally much more than a typical fee.

And the network can't really count on miners being altruistic to grow (note that the algorithm of some daemons is in that situation and will grow the size even if it costs money, due to a bug - that possibly explains why the median size grew to 100 kB or so a few days ago).

Hence the idea to grow the block size limit to 300kB, point at which the penalty of adding one transaction is offset by a typical fee and miners have an incentive to slowly grow block sizes.


I think the overall answer is "it's ridiculously impractical to perform by hand". The Cryptonight hash operates over a 2 megabyte data space, using multiple rounds of AES along with a variety of other cryptographic hash algorithms. What human is going to have the patience to write out 2 million bytes of data even once, let alone multiple times?

I would downvote this question as being utterly ludicrous. Some of it is blindingly obvious:

E.g. "How much harder is hashing CryptoNight by hand compared to hashing SHA-256 by hand?" - The ratio of difficulty for CryptoNight vs SHA-256 is the same, whether calculating by hand or by computer. The difference in amount of computations is the same either way. This is a stupid question.

A valid question would be "where can I find a description of the CryptoNight hash algorithm".


Is it true that the larger the hashrate that the mining pool has, the greater the amount of mining?

More hashrate means more work.

The more hashrate a pool has, the more likely (more frequently), it is to mine blocks.

An example:

If the network hashrate is 300 MH/S (that is the hashrate of all miners mining Monero), and the pool hashrate is 3 MH/S, the pool is expected to mine a block roughly every 3 hours.

300000000/3000000*120/(60*60)

Your payout of the blocks mined is based on how much hashrate you contributed to the pool. Thus, the larger the pool hashrate is compared to your own, the less share of the rewards you get.

Over time, it shouldn't matter which pool you use, you'll end up with the same reward. Pool mining, as opposed to solo mining, just guaranties a regular more even payout schedule (i.e. regular small amounts vs more spread out larger rewards). And the same logic goes into comparing different pools. If you use a pool with a larger hashrate, you are going to get more regular, but smaller payouts than using a pool with less hashrate. Over time, you'll get the same amount.

  So should I use a pool with a high hash rate?

Hopefully above answers this now, but I'll labor the point. If you need/want small frequent payments, use a bigger pool. If you are happy with less frequent but bigger payments, use a smaller pool. If you have reasonable hashrate and can wait longer, solo mine. It all boils down to frequency and size of payment.

Now, there's one other thing to bring up. Decentralization. It's bad for the currency overall if too much hashrate is controlled by only a few large pools. This is why it's encouraged to mine with the smaller pools (or better still, solo mine) - to increase decentralization.