This wording is refering to a list of known block hashes embedded in the monerod binary. These hashes correspond to the first N blocks in the Monero blockchain, and are intended to allow the daemon to skip some expensive checks for "known good" blocks. If your daemon receives a block at height H, and that block's hash matches the "known good" has for that height, then a faster verification is made.

This is in a way something that goes against decentralization, since the list of known good block hashes is made by the Monero team. However, the speedup it offers to first time users is substantial, and the known blocks are only for historical blocks (I think till 1 million at the moment, and we have 1.2 million blocks).

This system can be avoided by not building in the block hashes when building. Syncing will then do the whole set of checks from the start, and also be much slower, but it allows you to verify that you indeed have a good valid chain.


How to run monero-wallet-rpc in background without revealing my password to the server?

One possibility is to run it with --wallet-dir option instead. Then use the open_wallet RPC when you're ready to use it.


When should I choose "MEDIUM" or "HIGH" transaction priority?

Transaction priority is a setting used to set your payment apart from other payments in the mempool if there is any competition, confirming your payment sooner. This can be seen in Bitcoin, where low-fee transactions can take hours at various times to complete, while higher fee transactions are completed relatively quicker since miners (who confirm every transaction) prefer those with higher fees since it earns them more money.

As you correctly stated, blocks currently are not very full in Monero, so there's no reason to choose a higher fee at this time. However, blocks may increase in size, so this could change, perhaps with the switch to RingCT and the larger block size that will entail.


Daemon after update to v0.13.0.3 gives ERROR output

This is a known bug to do with wallet/daemon communication when the wallet tries to read the txpool. It is fixed on github (https://github.com/monero-project/monero/pull/4636), and will be fixed in 0.13.0.4 soon.

It does not mean your blockchain is corrupted, and you do not need to resync it or otherwise fix it. Either apply the patch above if you can, or wait for 0.13.0.4.


When you create a transaction, you consume existing outputs and create new outputs. Each output has its own unique public and private key. This means outputs are not associated with a wallet address on the blockchain, like they are in Bitcoin.

In Bitcoin, when an output is created, the output is associated with a hash of the wallet address that is authorized to then spend it. In Monero, nothing is associated with a wallet address. The recipient directly spends the output that they have received in a transaction when it is time to spend it, using their sole knowledge of the private key of the output that was created for them when someone else sent them funds.

In Bitcoin, you specifically identify the outputs you are spending in a transaction.

In Monero, a ring signature hides the information about the actual outputs being spent. Let's say you want to spend an output you own. You then select 4 other random outputs on the blockchain, and create a 'ring' with 5 members. Therefore the ring consists of one output you do own and four outputs you don't.

You then create a ring signature which proves to the world that you definitely own one of the 5 outputs, but it will be mathematically ambiguous as to which output that is.

No outputs are 'hidden'. What is hidden is the reference to the output being spent. You reference a ring of possible outputs being spent, instead of directly referencing the actual output being spent.

There is therefore no such thing as a decoy of a decoy. A decoy is a real output that isn't the output you are actually spending. All outputs that exist on the blockchain are real outputs. All references to outputs are references to real outputs.

To put it another way, the blockchain does not consist of real and decoy outputs. The blockchain only consists of real outputs. 'Decoy' is a term that solely applies to references.

Note that the block explorer does not call the ring members 'decoys'. This is because one of the ring members is not a decoy. The block explorer does not know which is not a decoy reference. Therefore it simply states that the outputs are all 'ring members', because that is all that can be known as an outside observer.

You can look up any output on the blockchain that is referenced as a ring member in a transaction. The specific block explorer you have been using may not allow you to search for it directly, but that's only a limitation of that particular block explorer. The 64 character representation of each ring member is a hex representation of the public key of the output being referenced, and is not a hash.


How to compile monero quickly after code modification

If you just need one particular program, you can build just that one, eg:

make -C build/release daemon
  make -C build/release simplewallet

etc.

If the line you changed is in a header file, then a lot will be recompiled, but if in a cpp file, only that one will be rebuilt (plus libs/binaries).

If you change a line in a header file, then ccache might help. If the line change ends up such that some preprocessed translation units end up identical, then ccache will avoid rebuilding those.

Another way is to use precompiled headers. There was a short lived PR adding those to Monero, but is was apparently saving not very much, and actually making things slower in other cases, so it was closed. Maybe this is something that can be looked at again.

Other possible ways: remove optimization flags such as -O2, ensure lots of RAM is available for caching headers/libs, move the tree and headers to a SSD, use -jN if you have the RAM and CPU.


There is a high-level description of this algorithm at http://cpucoinlist.com/cryptocurrency-algorithms/wild-keccack/ which reports as follows:

  Wild Keccak is a Keccak hybrid which uses blockchain data as
  scratchpad. After each Keccak round, pseudo-randomly addressed [state
  vector used as addresses] data is taken from scratchpad and XORed with
  state. Calculating each block PoW usually hits about 1100 randomly
  addressed reading of blocks by 32 bytes.


The chains are exactly the same. V0.10 continues on where v0.9 left off. Actually, right now you can use either version of the software, com January you will need to use v0.10. This is not because v0.10 is on another chain, but rather because in January v0.10 will start enforcing some rules that v0.9 won't understand.

The way your address and wallet is built is all backwards and forwards compatible though. The wallet itself might quit functioning some day, but the keys are still good. You just need to upgrade the software.


How do I move the blockchain (data.mdb) to a different directory during (or after) the initial sync without losing the progress?

This is, fortunately, fairly trivial and you won't lose any of the progress. It is done as follows.

If you're using the GUI, perform the following steps:

Create a new directory on the other/external drive. In addition, create a subdirectory called lmdb. Thus, if you, for example, created a directory called MoneroBlockchain on the other/external drive, you should also have MoneroBlockchain/lmdb (Linux & Mac OS X) or MoneroBlockchain\lmdb (Windows)
Go to the Settings page of the GUI and add the full path of the new directory as Blockchain location
Click in another box (on the Settings page) to ensure your settings are properly saved.
Exit the GUI and make sure to stop the daemon as well.
Browse to default directory for the blockchain (C:\ProgramData\bitmonero\lmdb on Windows | ~/.bitmonero/lmdb on Linux and Mac OS X)
Note that aforementioned directories are hidden. On Windows, you can use the explorer to manually browse to it. On Mac OS X, you can typically use CMD+SHIFT+DOT to unhide directories. Lastly, on Linux, you can typically use CTRL + H to unhide directories.
Copy data.mdb (the blockchain) to the new lmdb subdirectory directory.
Restart the GUI.
Use Show status (on the Settings) to verify that your daemon is properly syncing (i.e. fetching new blocks) to the new directory.

If you're using the CLI or running monerod separately from the GUI, perform the following steps:

[1] Exit the current monerod gracefully by typing exit

[2] Create a new directory on the other/external drive. In addition, create a subdirectory called lmdb. Thus, if you created a directory called MoneroBlockchain on the other/external drive, you should also have MoneroBlockchain/lmdb (Linux & Mac OS X) or MoneroBlockchain\lmdb (Windows).

[3] Browse to default directory for the blockchain (C:\ProgramData\bitmonero\lmdb on Windows | ~/.bitmonero/lmdb on Linux and Mac OS X).

[4] Note that aforementioned directories are, by default, hidden. On Windows, you can use the explorer to manually browse to it. On Mac OS X, you can typically use CMD+SHIFT+DOT to unhide directories. Lastly, on Linux, you can typically use CTRL + H to unhide directories.

[5] Copy data.mdb (the blockchain) to the new lmdb subdirectory directory.

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

[6b] On Linux and Mac OS X, open a new terminal from the same directory as monerod

[7a] On Windows, type the following command in the command prompt:

monerod.exe --data-dir path\to\new\directory

If that doesn't work in the Powershell, type:

.\monerod.exe --data-dir path\to\new\directory

If that doesn't work either in the Powershell, type:

./monerod.exe --data-dir path\to\new\directory

[7b] On Linux and Mac OS X, type the following command in the terminal:

./monerod --data-dir path/to/new/directory

[8] Note that, if you're running monerod separately, you have to apply the flags every time you start monerod. Thus, on Windows, probably most convenient to create a shortcut, go to properties, and add the flags after the Target. On Linux and Mac OS X, it's probably most convenient to create a little script.

[9] Once monerod starts it should state (in the terminal or command prompt) where it's loading the blockchain from. Check whether this is the correct directory.


How many transactions per second can the Monero network handle?

Monero transaction confirmations are very quick on modern computers. With LMDB estimates from developers Smooth and NoodleDoodle are that Monero can handle 1700 TPS (up from 1600 TPS pre LMDB).

Confirmation time is definitely not the limiting factor. Many nodes do not have the bandwidth to support 1700 TPS based on current transaction sizes.

Monero can have very large blocks thanks to its adaptive blocksize. However by the time that we reached 1700 TPS memory requirements would also be too much for many nodes.

In order of importance, I would say the TPS limiting factors today bandwidth and memory. LMDB did speed up CPU confirmation time but it was not the limiting factor in TPS even before the improvement.


You can see the list of Portugese words Monero uses here.

Only the first 4 letters of each word matters (for Portugese). For other languages, it may be 3 or 4. You can test this by restoring from your mnemonic seed, changing 'togoles' to 'togoabc'. It should still restore.

If there is a better word you feel should be used instead of togoles that begins with togo-, then feel free to suggest changes on the Monero Github.


See Creating a Payment ID

On GNU/Linux just type openssl rand 32 -hex on a terminal.


Is CryptoNight the hash function which plays the role of the "random oracle"?

The Hp and Hs hash functions of the Cryptonote paper are called hash_to_ec and hash_to_scalar in the Monero code base, and they are based on the Keccak1600 hash function (called fast_hash in the code), not Cryptonight (called slow-hash in the code).


Maximizing privacy when dealing with pre RingCT outputs

I'd do a sweep_all with a bigger ringsize to merge them all in one RCT output, followed by a couple of sweep_all to yourself (AKA "churn") with default ringsize at random intervals.

You can send that first TX directly to your Ledger and then use the Ledger to do the churning TXes, as it will likely be more user friendly than "manually" with the cold wallet CLI where you have to pass around some files. Preferably hide your IP via Tor/VPN if you want to hide the metadata as well.


Can you have a multsig wallet with the current Monero protocol?

Yes. Essentially, you can split up the private spend key according to a (k,n)-secret sharing scheme. Then any k participants can collect the keys together to recreate this private spend key and then sign transactions.

Now the question is, how is the key generated, how are the shares generated, and who/what brings the shares together.

One simple way is this have a trusted dealer generate the key and distribute the shares, and a trusted signer to collect the shares and sign transactions. If you are doing this for your own cold storage uses, this should be sufficient.

If you don't want a trusted signer, you can use secure multi-party computation. You can have a transaction X, and then k participants can do a computation that signs X. By the properties of Secure multi-party computation, the shares won't be revealed, and the only thing computed is a signature for X. In this way, the k participants don't have to trust any central signer, or even each other.

If you don't want a trusted dealer, you can again use secure multi-party computation. In particular, you can design an algorithm that produces a spend-key, produces shares of it according to the secret sharing scheme, and then encrypts each share with a public key of a participant, P_n. This algorithm requires a certain amount of random data r. The m dealers each generate their own random data or entropy r_i, and do the above computation using r = the xor of all the r_i. As long as one dealer chooses a random r_i and then destroys that r_i, r can not be calculated. These m dealers can be the n participants, although in practice you would probably only need k of the participants to be dealers, since they have spend power anyways.

By using both of these suggestions, this multisig scheme is as powerful as a bitcoin style multisig. It can actually be implemented in any cryptocurrency, regardless of protocol. It actually is a little bit better than a bitcoin multisig because:

It is indistinguishable from a monero address, helping to protect privacy. (Bitcoin miners and nodes which actually ignore multisig transactions with too many participants).
The above property also makes this cheaper as well, since transactions to and from an address are the same size regardless of whether its multisig or not.

Unfortunately, I don't know any software that implements this yet. It would make a good project, if anyone's up for it.

EDIT: Just found the fair play project. It can be used for secure multiparty computation.


Can I retroactively add the spendkey to a watch only wallet?

As per Jolly Mort's comment, this is currently not possible.


Using Monero as a payment source for my business

I believe you are looking for subaddress


The minimum transaction fee is proportional to the size of the transaction data. Assuming you are making a typical transaction and are not using custom privacy levels, then the minimum transaction fee depends on the number of inputs being spent. The number of inputs being spent is a consequence of the size of the stray change outputs and the size of the typical transaction amounts you receive relative to the amount you're sending. It's not easy therefore to correlate the number of inputs being spent to the amount being spent in a transaction.

The fee can be increased to give the transaction higher priority. You could argue that high value transactions are more likely to be given an expensive fee because the transaction is more important. This is a weak correlation though.

The main thing to note is that there is no rule that requires the fee to be proportional to the amount being spent, so disclosure of the fee does not give away much. Disclosure of the fee is necessary, because miners need to know what fee is being offered in order to decide whether the fee is enough to allow the transaction to compete for inclusion in the next block being mined.


What is the other file created alongside .keys?

The cache contains data that's retrieved from the blockchain. It includes the hashes of blocks (used to detect reorgs), then data for every transaction that you sent or received, custom information like user tx notes, secret transaction keys, that kind of thing. It will grow as you transact in Monero.


Since your question is not a duplicate of that other one as it's more detailed, my answer will just be a part of the the answer to that other one:

There is no length requirement (within reason - don't go using 4 billion character password or you'll run out of memory, and there might be a standard C++ library string limit, but if there is, it's likely pretty high).


Where can I get a printable version of a Monero Paper Wallet to be used as gifts?

You've probably seen the paper wallet at the Monero.how site. The site explains:

  For security reasons, we chose to create a paper wallet that requires
  us to write the seed onto it with a pen instead of printing the
  information directly onto the wallet. This is to avoid security
  threats from compromised printers and compromised smartphone QR
  readers. When you print something, there is a good chance that the
  images are being sent unencrypted across your network and stored
  unencrypted in the printer's memory even after the printing is
  complete. Because printer firmware tends not to be security hardened,
  it is not inconceivable that a virus could exist either now or in the
  future that would scan all print jobs for anything resembling a
  cryptocurrency key and transmit it to an attacker. We sleep better at
  night knowing that we used a pen.

If you wanted to use an existing paper wallet and modify it to include a QR code instead of the written seed words, then the first question you'd want to ask is "what should the QR code contain?".

If there is a specific app you know of that can scan QR codes that could directly read a 32 byte sequence representing the wallet seed, then that would be the most compact QR code representation.

However, anyone using the standard GetMonero.org desktop wallet would find that QR code useless. Therefore I'd recommend you create a QR code that simply includes the plain text seed words, which someone could scan and use to more easily enter the seed words into any Monero wallet. Be sure to download QR code creating software rather than using a web site to create the QR code. You would not want to accidentally use a hacked web site that is looking out for cryptocurrency keys that it can steal funds from.


What are the standard fee multiplier levels?

I can't speak to why the GUI has them labeled that way, but the current, actual fee multipliers are:

1, 5, 25, 1000 [ref].

What confuses this a little further though is that the default strategy is to use auto-low fees. The default/automatic multiplier that gets used is 5, which potentially gets adjusted down to 1 (based on network/chain conditions) [ref] [ref].

Armed with this information and reviewing the source code, selecting "Normal" eventually ends up with a multiplier of 5 and selecting "Slow" ends up with a multiplier of 1, which explains your 1/5 observation. If you selected "Automatic" in the GUI, you'd be using a multiplier of 5, which may get adjusted down to 1.

As the labels in the GUI are scaled to the "Normal" being x1, they should probably read x0.2, x1, x5 and x200 respectively, slow to fastest.


onion-monero-blockchain-explorer together with Apache webserver

Not a Monero question, but the answer can be found in Apache documentation.

ProxyPass "/"  "http://www.example.com/"
ProxyPassReverse "/"  "http://www.example.com/"

Replacing www.example.com with 127.0.0.1:8081.


What is the most efficient number of threads to run using a VPS with 32 cores?

Typically, a VPS provider will throttle or kill processes which eat up too much CPU.

That said, each mining thread will need 2 MB of fast (cache) memory. So you'll want to have one thread per 2 MB of cache you have, even if you have more cores available. You will want to play around with different values around this to see how your particular system behaves though, as other processes may jostle for cache usage too.


Creating a wallet from the command line using monero-cli command?

Use the monero-wallet-rpc calling it's create_wallet method. https://getmonero.org/resources/developer-guides/wallet-rpc.html#create_wallet


No, not really. If you didn't include a big enough fee or something it will fall out of the mempool after a day or so, but there's no way to ask all the nodes that have your TX in their mempool to kindly forget about it, afaik.


My dog ate the USB key with 10000 monero wallet. Are they lost forever?

When you create a new wallet, the software gives you a "mnemonic seed". It's a list of words that can be used to regenerate your wallet file and rescan the block chain to find your transactions.

By writing the seed on paper and storing it in a safe place (or by memorizing it if your memory is good), your moneros would not be lost forever in case of a dying hard disk (or hungry dog).


No, but there's nothing preventing it - either.

We have the TX-extra data field which could be used to embed a return address. For example, you could store an encrypred return address. However, how does the recipient know that those apparently random numbers represent an address? So, there needs to be some convention amongst supporting wallets on the method to write and recognize this.


Trojans and generic suspicious malware blocked by MalwareByte while downloading blockchain

Those ports have nothing to do with monerod.
It is likely that your computer is infected with some kind of malware.
You should avoid using a spend wallet on this computer, keep it as a read-only/audit wallet here at best.
You may lose a bit of privacy but not your money doing so.

Anyway, I strongly advise you to format your disks & reinstall your operating system.

Regards.


Why is there only one GPU miner for NVIDIA cards?

There was a proposal on the Monero Forum Funding System for someone to create an improved NVIDIA miner. Unfortunately, the developer never followed through and the project was closed.


That's correct. Also, it's more simple to check resulting wallet address (not the integrated one, but the first one on the top under "Receive" tab) and you don't have to rescan the 2nd one (unless you want to access your "account" from that instance, too). If the wallet address is matching for both seeds then it's correct!


How to use the sweep_all command with options like ring_size or priority

First, it should be noted that sweep_all combines all available unspent outputs in the current account in a single transaction. Thus, your transaction may have a lot of inputs, which could be detrimental to your privacy if you received outputs that are close in proximity, i.e., from the same transaction or from multiple transactions in the same block.

Now, if you type help into monero-wallet-cli and look at sweep_all, it will show the following:

sweep_all [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] <address> [<payment_id>]

Note that [] indicates that the parameter is optional. Thus, index, priority, ring_size, and payment_id are all optional parameters, whereas address is a mandatory parameter. Let's discuss all these parameters separately.

[index=<N1>[,<N2>,...]

The index parameter can take any argument as long as it's an (unsigned) integer that corresponds to a primary address or subaddress that possesses a balance. For example, let's say your current account has three subaddresses all possessing a balance of 0.1 XMR and a main / primary address possessing a balance of 0.5 XMR. If you use sweep_all index=1,2 <address>, it will only spend the 0.1 XMR of subaddress A and the 0.1 XMR of subaddress B for a combined 0.2 XMR. Similarly, if you use sweep_all index=0,3 <address> it will only spend the 0.5 XMR of the main / primary address and the 0.1 XMR of subaddresses C for a combined 0.6 XMR. If this parameter is omitted, sweep_all will use all available unspent outputs within the account.

[<priority>]

The priority parameter has four available arguments, namely unimportant, normal, elevated, and priority. In monero-wallet-cli, the corresponding arguments to the priority parameter can only be passed as string. Put differently, you cannot specify them as (unsigned) integer. In addition, the default will be used if this parameter is omitted. More specifically, by default, the wallet will use the unimportant level if there's low traffic on the network, whereas it will use the normal level if there's considerable traffic on the network. Considerable traffic is defined as 80% of the last blocks being full and the mempool not containing a backlog. Lastly, note that any argument specified by the set priority command (e.g. set priority 1) will override this default behavior.

[<ring_size>]

The ring size parameter can take any argument as long as it's an (unsigned) integer that is equal to or greater than 7 (the current minimum ring size enforced on the protocol level). The default of 7 will be used if this parameter is omitted.

<address>

The address parameter can take a standard / plain address, a subaddress, or an integrated address as argument. Address is a mandatory parameter and thus cannot be omitted.

[<payment_id>]

The payment ID parameter can either take a short, encrypted 8-byte (16 hexadecimal characters) payment ID or a long, unencrypted 32-byte (64 hexadecimal characters) payment ID as argument. Two things to note. First, reusing a long, unencrypted payment ID will result in your transactions (that use the same payment ID) being linkable. Second, an integrated address is basically the result of embedding the short, encrypted payment-ID in the plain / standard address. Therefore, separately specifying the short, encrypted payment ID when sending to an integrated address is redundant and may even result in an error. Lastly, no payment ID will be attached to the sweep_all transaction if the payment ID parameter is omitted.

As a practical example, let's say you want to send an unimportant sweep_all transaction from the main / primary address (within the account) using ring size 10 to the general dev fund with a long, unencrypted payment ID attached (we'll use 1234567890123456789012345678901234567890123456789012345678901234 for this example). The command would then be:

sweep_all index=0 unimportant 10 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A 1234567890123456789012345678901234567890123456789012345678901234


"v12" refers to the hard fork version, not the tx version. Given that, and by the mere definition a genesis block is the first block mined, what you're asking makes little sense - compounded by the fact you talk of block versions but are actually referencing the miner tx of a genesis block.
If you are trying to fork Monero with a new chain that starts with v12 functionality, it's not the genesis tx that needs changing, rather a bunch of other code.


Why Brick and Mortar Merchants should support Cryptocurrency

Not only that but if merchants solely accepted payments in crypto, another plus is that PCI-DSS compliance cost associated with accepting credit card payments on a commerce server checkout cart goes to zero. A commerce server has absolutely no need to store any private keys online. The same applies to a brick and mortar checkout station.


If I only have the one-time public and private key of a transaction, can I spend it?

That's right. Normally, your wallet uses your private view and spend keys to recover the one-time key and uses it to sign a transaction spending that one-time key. If you already have the one-time private key somehow, you don't need to recover it and you could spend it by itself. I'm not aware of any tools existing which would let you do it, but they could be built.


If I have to reformat a disk where I'm storing a wallet, if the OS is Ubuntu, which files should be be saved prior to the reformat?

Each wallet will have 3 files, see here for more details.

The files are:

wallet-name - wallet cache, note that there's no extension
wallet-name.keys - the most important one (your keys)
wallet-name.address.txt - only the plaintext address inside, not really needed

If you've used defaults, they should be all in the same folder as your Monero executables. All you have to do is copy these files, and that's it. When re-installing, you copy them back or use the

--wallet-file <path>\wallet-name

argument to tell the wallet where to look for the files and access them from there.


Can't verify Gitian deterministic build signatures with GPG

I found out that the problem was in line endings.
On Windows it's defaulted to CRLF of course with core.autocrlf set to true.

If I manually change line endings to Unix-style LF all checks pass okay:

C:\monero\monero-gitian\v0.15.0.1-win\dikdust>gpg --verify monero-win-0.15-build.assert.sig
gpg: assuming signed data in 'monero-win-0.15-build.assert'
gpg: Signature made 11/24/19 21:06:59 UTC
gpg:                using RSA key 7A499ECDBF8A30A8B3B8A190144D6E86DA9446B8
gpg: Good signature from "Antonio Alessio "dikdust" Di Pinto <dikdust@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7A49 9ECD BF8A 30A8 B3B8  A190 144D 6E86 DA94 46B8

My suggestion: *.assert files should be considered as binary.


Are reserve_size bytes really related to mining the final nonce?

The extra reserved bytes are taken into consideration to compute the block hash.

There are 4 bytes reserved for a nonce in the block header (the nonce that appears in the hashing blob).

In addition, you can reserve extra bytes (reserve_size) for a second nonce in the extra field of the block reward transaction. It allows searching for a nonce giving a valid block in a space bigger than the default 32 bit space available with the block header. When you change these bytes, the hash of the block reward transaction changes, therefore the root hash of the transaction merkle tree changes, therefore the block hash changes.

The hashing blob is a piece of data where the transaction merkle tree has already been computed, this is why the second nonce doesn't appear in it.
When you change the second nonce, you have to compute the new hashing blob before continuing the mining process.


Can a DEX like bisq.network profit from Kovri?

The approach of network traffic obfuscation is quite similar in both projects, however there are some major differences.

TOR is used by a vast majority of users as a proxy service for the clearnet, what we commonly call "internet" but only a small percentage of users are acting as nodes actually relaying traffic for others.

I2P on which Kovri is based has a different approach and is not designed to proxy clearnet traffic but to build a really decentralised network of equal nodes which all act as relays by default.

In general, TOR is more centralised, since comparatively few strong nodes with good connectivity are relaying most of the traffic. This is even more valid for "exit" nodes to the internet, since many relays don't want to act as such for security or legal reasons. An attacker might setup many of these strong nodes to control a major chunk of all relayed traffic and log its activity on the network to determine where it actually comes from and where it goes to.

These aspects disappear for I2P network since there are no "exit" nodes and for any node it is not distinguishable if the current traffic it relays (which is encrypted) is intended for the node it is actually communicating or if it is just another relay. Every single user / node makes the network stronger against attacks aiming to overtake the network and log its traffic.

Summing up probably it would benefit decentralised exchanges to choose I2P over TOR and it would also benefit the I2P network, since TOR (at least in terms of users) is probably more popular. However, when it comes to relaying nodes it probably is not.


How does one prove ownership of a Monero address?

Best is to sign a message consisting of your address, with your address.
The sign and verify commands have been merged just yesterday: https://github.com/monero-project/bitmonero/pull/818

First, make a file with the data you want. It just happens that, when creating a wallet, your address is saved in WALLETNAME.address.txt.

Then, sign:
sign WALLETNAME.address.txt

Then send the signature output by that command to the other party, who can now verify:
verify WALLETNAME.address.txt 4xxxxxx SigV1xxxxxx


"waiting on daemon synchronization to finish" Issue

Try starting the monerod separately from the GUI instead of starting the daemon within the GUI.  You should be able to more easily troubleshoot any issues you are experiencing with the daemon with its console messages showing on the screen.

Depending on your Internet connection it may take a while to download and sync the blockchain.

If you run monerod in a separate window, you can type "status" to see:


What will be the effect on monero if bitcoin deploys schnorr sig's?

I didn't know about Schnorr. But Imo, it's not the same lvl of privacy that monero offers.
Plus, there's no interest for bitcoin to include anonimity in transactions. Bitcoin still suffers of its pseudo-anonimity. Even in 2016, there's still dumb political/financial reviews that point the btc as "money laudering, terrorist act, drugs implication" ...
Btc has never been and will never be an anonymous crypto and the fact that the btc is still rising and consolodidating after years is directly related to the fact that the bitcoin comunity want to prove his credentials as a concurrent of fiat currency.

Sorry for my english


This file is a copy of the cache file (walletname) as it was when the cache file format changed to use a more portable data storing library. It was kept as a safeguard in case the new format proved buggy, so it can now be discarded.

For reference, the old format was boost serialization, and the new format is portable boost serialization, which is not yet merged in boost to my knowledge.


How is block hash calculated?

You create a block hashing blob (which is the block header, the tree root hash of the blocks transactions and a varint of the transaction count), then hash this using the RandomX1 hashing algorithm.

The hash blob returned for get_block(1)["blob"] is...

That is not a block hashing blob, that's the block blob as returned from the RPC get_block.

How do I calculate the hashes for an existing block?

For an existing block, obtain the block blob (per above), parse it to extract the header and transactions, construct your hashing blob (per above) and hash that.

...then to combine it with nonce

An existing block already has the nonce data, which can be in both the block header / in the miner transaction. Thus you don't need to do anything particular with the nonce data for an existing block - rather what you need is the block blob data and a way to parse it (extract the header and transactions) so you can construct a hashing blob.
1 Note you need to use the correct PoW hashing algorithm based on the block height you are checking as the algorithm bas changed over time. The current algorithm is RandomX, but if you want to validate block 1 (which is something you mentioned) you'd need to use the original CryptoNight algorithm in that case.
UPDATE (based on comments below)
Note the term "block hash" can refer to either the PoW hash or the block ID (as used by block explorers etc). These use the same input data as described above but use different hash functions. For the latter you need to use Keccak-256.


How Ed25519 curve relates to Borromean Ring Signature scheme?

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

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

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

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


I have not heard of one. But eventually, if Monero continues to grow and get mass adopted, a documentary is inevitable.

They'll have plenty of material to work with, considering our origins are as mysterious as Bitcoins. Yet we also have the whole CryptoNote/Bytecoin scam drama to add, alongside thankful_for_today's shenanigans, so it could be a colorful flick.

Personally I'm hoping for some silky narration by Fluffypony over HD coastal vistas of Plettenberg Bay.


The payment ID you are trying to use is too long (32 bytes, when it should be 8 bytes).
From the documentation:

payment_id - string; (Optional, defaults to a random ID) 16 characters hex encoded.

Example call:
 curl -sd '{"jsonrpc":"2.0","id":"0", "method":"make_integrated_address","params": {"payment_id":"5b67d705bbf72c77"}}' http://localhost:28084/json_rpc

And response:
{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "integrated_address": "A8mA7fFvCnjhmoNQpCrDBQXFM25rqFBZYBq8RepazSLSBwsj5kRtuM9iCSuz3vs9KbfZhrQj1BKRxVCpyqii7pca5EzinX4GnyZEXS34vk",
    "payment_id": "5b67d705bbf72c77"
  }
}

@user36303 also correctly points out you have not quoted the parameter name payment_id.


Harmonizing Monero with HD Wallet BIP 39 Technology?

Yes it does make sense for Monero to support BIP 39 words used by traditional HD hardware wallets such as Trezor, Keepkey or Ledger.

We will see how much the https://forum.getmonero.org/4/academic-and-technical/2495/experimental-trezor-firmware-testing distribution for tailored Monero Trezor firmware, a forked simplewallet, and a forked trezorctl command will support the recommendations above.

Specifically, the trezorctl recover_mnemonic command line is the use case for converting BIP 39 seed words provided by a Trezor device and converts them to Electrum seed words for wallet recovery outside a Trezor hardware wallet.

For more information, see With Monero firmware loaded on a Trezor, how does one create private spend keys from the BIP 39 seed words supplied during a Trezor's configuration? that also desires to push the envelope for having Monero provide nominal BIP 44 support.


Will the viewkey ever be able to view both incoming and outgoing transactions in a wallet?

Very unlikely, unless the crypto changes substantially.

However, if your goal is to see whether your cold storage has gone bye bye, there is a way to do this (though no current tooling to allow you to do this easily currently): the cold wallet can export the key images for the outputs it received, and a hot wallet can watch the blockchain for those. If they appear at some point, it means the corresponding output was spent. Hopefully by you :)

Feel free to file a bug on https://github.com/monero-project/bitmonero/issues asking for that particular capability to be added to the tooling.


If you want to join a specific pool for example monerol.com, you can go to its getting started page which is http://monerol.com/#getting_started

As you can see there are many ways to connect to the pool just select the mining app of your choice. Normally, a VPS does not have GPU so select the one that support CPU mining. For example  you can use minerd like this

minerd -a cryptonight -o stratum+tcp://monerol.com:3333 -u YOUR_WALLET_ADDRESS -p x

You can install minerd by downloading and compiling it. The source is at https://github.com/wolf9466/cpuminer-multi

Edit: Another miner which is good is called xmr-stak-cpu you can get its source code here https://github.com/fireice-uk/xmr-stak-cpu

Hope this helps.


How will the ring CT fork be rolled out?

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

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

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

Yes it is, from the code:

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


Is it possible to have simplewallet start scanning from a certain block instead of the beginning of the blockchain when refreshing a new wallet?

In the current code in git, yes there is a --restore-height parameter that does what you want. But for a newly created wallet, simplewallet will find out the current last block from the daemon, and set this parameter automatically, so you don't even need to specify it.

This feature will be in the next release (v0.10.0). With this feature a newly created wallet can sync to a daemon on localhost in just a few seconds.


Does each node have a maximum number of peers?

A node will connect to up to 8 peers by default (P2P_DEFAULT_CONNECTIONS_COUNT in src/cryptonote_config.h). I think there is no set limit of incoming connections, though if a lot of peers try to connect, you might end up hitting your open files quota.

The more peers you are connected to, the more traffic you will have to propagate blocks and transactions. If many of those peers are not up to date and are syncing historical blocks, then you will be sending a lot of data. The upload and download rates can be throttled via the --limit-rate-up and --limit-rate-down bitmonerod command line switches (adjustable at runtime in the daemon console with limit_up and limit_down).


What purpose is served by the file p2pstate.bin?

This file contains the list of peers the node knows about, along with the time they were last seen. Deleting it clears that memory, and the node will have to rely on seed nodes to get a new list of peers.

Keeping this file means that you don't have to rely on the seed nodes to be able to connect to the Monero network, as you already know of a large number of other potential nodes to connect to. This decreases the centralization whic comes with asking the seed nodes first (while there are a dozen or so, I believe they're run by the Monero core team).

When talking to other nodes, lists of known peers are exchanged, so you can then keep up to date without having a need for seed nodes (though those may also be contacted, as they are normal Monero nodes too).


How can I contribute to Monero as a software developer

The primary ways to start are to become familiar with the codebase, the cryptonote standards, and to engage with other developers. All of the developers communicate via IRC on #monero-dev or #monero on freenode's IRC servers.

Documentation is severely lacking so the most efficient way to obtain any information that you can't find is to ask on #monero or #monero-dev. Please stick around, your question will eventually be answered.


How did Monero Research Lab members learn about Monero?

I am not sure how the connection was established, but Surae Noether was paid by the then core-team to review the CryptoNote whitepaper (and thus the CryptoNote protocol), and some of the code of Bytecoin, where Monero forked from. From the review of the CryptoNote whitepaper we can read the following:

  For full disclosure, I was hired by the Monero (XMR) developers to investigate the CryptoNote protocol and the ByteCoin code base from which Monero has been forked. The folks involved in hiring me have had no involvement in my review process other than answering my technical questions and sending me money occasionally when I ask them politely and show them the annotations I’ve made. They are paying me in Bitcoin, not in any CryptoNote based currency. Yes, I do own and hold CryptoNote currencies.

As far as I know, there is no public information about how the other two members, Shen Noether and Sarang Noether, heard about CryptoNote and/or Monero, and how they joined the Monero Research Lab. This is a likely result of them wanting to stay anonymous and therefore using pseudonyms to publish their papers.

It should be noted though, that core-team member fluffypony has met all three members of the Monero Research Lab and thus most likely verified their credentials as well. From the missive:

  Over the weekend of the 8th and 9th of November 2014, the Monero Research Lab had a closed mini-meetup in Salt Lake City, Utah, USA. In attendance were surae, sarang, and shen, as well as tewinget and fluffypony. A great time was had by all attendees meeting for the first time, and long academic discussions were the order of the day.


It baffles me why pools attack each other, but that asside, there are other providers that offer DDoS services (sometimes for free) on top of their servers.

As per comment thread above, if you intend to stay with the same hosting company which is capping the protection, one way round this is to make use of another provider as a proxy.

N.b. your linked iptables article is pretty good too. I would use that on the proxy too.


Saving isn't really needed now. All it does is call mdb_env_sync, which will flush the filesystem, so the OS really writes things on the disk. Exiting bitmonerod normally will also call this, so using save before exit is unneeded.

Originally, save was needed because the blockchain was all held in RAM, so if your node was running long term and crashed, you'd lose days or weeks or even months of sync time. This is not the case anymore, and the use of LMDB means any changes are reflected on disk automatically (that is, depending on whether the OS decides to keep certain pages in its disk cache, and this is where mdb_env_sync comes into play).

Ideally, there should not be corruption if bitmonerod crashes. I don't know the details of db transactions though, so if you can, always exit gracefully, but if you can't, it should usually be OK. However, there have been reports of failing to start back up, which I've not seen here when killing bitmonerod abruptly, so better safe than sorry.


Is it possible to solo-mine on a non-public node?

Those outgoing connections are also 2-way. All connections are 2-way. Having an incoming means that your node can listen for others that want to connect. With no incoming, your node can still connect to other nodes.

So long story short, you can solo mine on a non-public node.


Help-Sent Monero From Changelly and did not received funds

Check that Changly actually sent the funds. Get the TXID from them and try to find it here: https://xmrchain.net/ If they didn't send, you need to work it out with them.
If funds were sent, you can verify they were sent to the correct address even if your wallet is not yet up to date: https://monero.stackexchange.com/a/4598/57
If you verified it was sent correctly, try this: Outputs on xmrchain.net show that I have a balance but command line says no balance


The GUI wallet came packaged with a node compatible with the wallet. If you are running a node in the background while starting up the GUI try shutting it down and just start the GUI by itself. The node will start up and the GUI should run properly.


What is the difference between mixin and ringsize?

There is a small difference. In summary, ringsize will always equal mixin + 1. So, a mixin of 2 is the same as a ringsize of 3.

Mixin refers to the number of other inputs used in a ring signature that you do not control.

Ringsize refers to the number of total inputs used in a ring signature, including ones you control.


As someone who runs both Windows and Linux, I'd say that there is no bad choice but there certainly are better ones for specific use cases.

Casual use: Windows - no need to dual boot or learn a new OS. Mining, running a full node work fine.
Competitive mining: Linux for superior performance
Storing funds: Linux for superior security. (Still requires sane best practices like not running a web browser on a machine with >$xx,xxx worth of monero on it)
Storing lots of funds: Neither. Use a paper wallet generated on an offline machine.
Development: Hands down Linux, unless you are a strong C# dev and know your way around the windows development environment.


Can I specify a payment ID when using the sweep_all command?

It looks like it's undocumented, but I just tested with version 0.10 and it behaves as expected with your syntax.
sweep_all <address> <payment_id>


The key derivation (ECDH shared secret) is now only computed once per tx, whereas before it was done per output. With a basic 2 output RingCT transaction, this should amount to approximately a 33% performance improvement (more for old-style transactions with more outputs).


How many lines of source code does Monero have?

I do not know the exact number of lines of Monero source code, but there are a few methods to calculate it, which are described here.

Monero is not based on the Bitcoin code base and is rather complex. Because of this there has been a major effort to document and cleanup Monero source code:

  There are over 70,000 lines of source in the src/ folder alone, and there is code in other folders that brings the total to over 100k, so this is no small task!

The Bitcoin source code has grown dramatically since its inception. In early years Bitcoin only had about 3k lines of source code, as described by Greg Maxwell. Currently, the Bitcoin Core source code contains more 100k lines of code which is roughly equivalent to Monero.

Documentation for Bitcoin is far better than it is for Monero making it much easier for developers to understand.  This was the motivating factor for the Monero source code cleanup effort and is far more important than the number of lines of source code.


Would I be able to restore my GUI wallet using the .keys file using a different OS?

Yes, as long as the encryption and decryption algorithm are the same used.
Here are a few tips in case you have problems accessing your wallet:

check if it's the right wallet and not your donation one or other ones (usually different .keys files)
check if the password is written in the correct case and you didn't misspelled it
I suggest you to download the latest version of the software, as it might just be a bug in the software you're using


My wallet won't connect to the daemon, re downloading doesn't help either. Can't reach my funds!

I don't know if solution was found but mine was :
- Delete the folder %programdata%\bitmonero
- Run monerod.exe
- then launch monero-wallet-gui.exe if needed

Hope it helps :)


How to properly transfer XMR in monero-wallet-cli?

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

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

Usually I use the following command to transfer XMR...

You do not need to specify the optional parameters (the ones enclosed in [] from the help).

What is the default ring size and priority for the second command?

Ring size is currently 11. You actually can't use anything other than 11 as all Monero transactions now use the same fixed ring size.
Priority is normal unless you changed the default wallet setting or specify explicitly in transfer ...

And what command should I use?

transfer <address> <amount> is the simplest and uses sensible defaults.


How to generate a Monero wallet programatically?

You have a couple of options.

One option is to have a running wallet RPC: monero-wallet-rpc --wallet-dir . --rpc-bind-port 18085 --disable-rpc-login

Which you can then call its create_wallet method like:

curl -X POST http://localhost:18085/json_rpc -d \
  '{"jsonrpc":"2.0","id":"0","method":"create_wallet","params":\
  {"filename":"monerowallet","password":"pass","language":"English"}}' \
  -H 'Content-Type: application/json'

Another option would be to use monero-wallet-cli --generate-from-json wallet.json when you have a wallet.json with content like:

{
  "version": 1,
  "filename": "monerowallet",
  "scan_from_height": 1796000,
  "password": "pass",
  "seed": "some valid seed ..."
}

But of course that requires you to have already created a seed.

Lastly, another approach I've seen used is to create a wrapper script around monero-wallet-cli --generate-new-wallet which uses redirection to echo input to the monero-wallet-cli processes stdin. There are many ways to accomplish this and is very much shell specific.

The RPC method is probably your best option (without knowing your use-case).


Smart mining is the process of having a throttled miner mine when it otherwise does not cause drawbacks. Drawbacks include increases heat, slower machine, depleting battery, etc.

As JustinEU4 mentioned, the intent of smart mining is to increase network security by allowing as many people as possible to let the smart miner on all the time. For this to work, the miner must prove unobtrusive, or it will be turned off, depriving the monero network from a little bit of security. As such, it is likely that a smart miner will miner more slowly than a normal miner on the same hardware.

Smart mining was started in 2014, but the contributor had to leave due to lack of time. The current code is at https://github.com/oranjuice/bitmonero/tree/smart-mining.

When this is finished, it is hoped that the relative slowness of a smart miner will be offset by the large amount of people running a miner for a possible "lottery win", and thus increase the monero network security by a non trivial amount.


Transfer using cli and choosing lowest fee?

You have to understand priority levels using the transfer command. Read: What does the "default" priority (priority = 0) do in monero-wallet-cli?

There are 4 levels:

First note that the priority levels unimportant, normal, elevated, and priority correspond to multipliers of x1, x4, x20, and x166, respectively.

To send with lowest you would do:

transfer unimportant <address> <amount>

Example output:

[wallet 46xxxx]: transfer unimportant 4BSX2Par....LU2T6xxx 2

There is currently a 1 block backlog at that fee level. Is this okay?  (Y/Yes/N/No)Y
Sending 2.000000000000.  The transaction fee is 0.003088120000
Is this okay?  (Y/Yes/N/No): Y
Transaction successfully submitted, transaction <xx9xcvd3434...3243>
You can check its status by using the `show_transfers` command.
[wallet 46hxxxx]:


getbalance json-rpc call just gives one big integer

The "human friendly" amounts have a decimal place at 12 digits, so in this case, 140000000000 atomic units would be 0.140000000000 monero.


Is there a way to check if wallet sees monerod over the LAN?

With the new 0.13.0.4 Beryllium Bullet version of the daemon and CLI software, all is working fine under Linux. No more issues.


from reading this issue thread it appears to be hardware related make sure to double check your equipment and overclocks if you have them also if you're exceeding the wattage of your PSU.


Why is monero mined coins called tail emissions? Why not just call it "mined coins"?

Tail emission specifically refers to newly mined coins after Monero is mostly mined out. With Monero, the block reward slowly decreases with each block. When it eventually gets to 0.6 XMR per two minute block, it stops decreasing and flattens out at that rate. This is referred to as the tail emission, and is a characteristic of Monero that Bitcoin does not have.


Do I need mod approval to get my "idea" moved into the funding required phase on the getmonero.org forum?

You first need to post your idea as a link on reddit, asking for others to comment, to give suggestions. Optionally, post the FFS Link or Reddit post link on IRC monero-community channel.
Then when a few of us will have asked to move your idea down to "funding required", either ask a Core Team Member on IRC to do it (but they are really busy), or wait for the Next community meeting to talk about it (with a prepared explanation of your idea and the link to the FFS proposal).


Who will receive the Monero tail emission

After 18 million coins or by may 2022 the last block would be mined

After ~18 million coins, the last pre-tail emission block will be mined. After this, all blocks mined will have a block reward of 0.6 Monero.

  Who will receive this tail emission?

The miners who mine the blocks.


How to send XMR from Minergate to Poloniex?

To see your Monero deposit address on Poloniex click Show me the Deposit Address when viewing your payment ID.


Is there an RPC call to get the txFee of a block?

Presumably you'd have to use the getblock method to get the transactions also and then iterate the transactions to add up total fees of a block.

Update: doc


How to bind daemon to inbound/outbound listening port on ubuntu

Basically, you have to open the port to outside connections. A tutorial that covers this is on the getmonero.org webpage: https://getmonero.org/knowledge-base/user-guides/vps_run_node

If you are running this from your home, you will likely have to configure your router as well to allow such connections. This will vary by router, but usually just involves forwarding a port to your node.

Finally, make sure you launch bitmonerod with the --restricted-rpc parameter to make sure folks don't mine on your node or anything.


How do I get Monero if I am in USA and don't want to do ID verification with SSN etc?

Purchase BTC on Local Bitcoins, then exchange to XMR.
https://localbitcoins.com/


I need a manual how to mine aeon with daemon

Using the daemon you can solo mine, and it's quite simple. Just sync the daemon, open and sync your wallet, then type:

 start_mining <number of threads>

Except replace  with the number of threads you would like use, probably 2 or 4.

You can also do it without even starting the wallet, just the daemon as described here: How to solo-mine Aeon?


Stealth addresses take care of the receiver's privacy, not the sender's.

In cryptocurrency, the ability to spend a certain amount of coins is the same as the knowledge of the private key to the public key associated with the coins.

So (simplifying a bit), in Bitcoin if there is 1 bitcoin associated to the public key P and if Bob knows the corresponding private key x such that P = xG, then he can spend the Bitcoin by submitting a message (transaction) to the network signed with x.

There is one privacy issue, though: if Bob keeps using the same P to receive bitcoins, then any observer will be able to see all payments were made to the same entity that controls P (Bob). This is the problem that stealth addresses solve.

In the context of stealth addresses, addresses are now composed of two public keys, and the coins sent to Bob will not be sent to his stealth address on the blockchain, rather the stealth address will be used by the sender to produce fresh new bitcoin addresses for every new transaction. These new addresses, even though generated by the sender (Alice) and unknown to Bob until the transaction is made, will nonetheless be controlled by Bob! Here is how it works:

Bob creates two pairs of private and public keys. Let's denote them by (a,A) and (b,B), where by definition A = aG and B = bG. Bob makes the pair of public keys (A,B) available to the network; this will be his stealth address.

Alice wishes to send 1 bitcoin to Bob; that is, she wants to assign 1 bitcoin to a public key P such that Bob knows x and P = xG. She will construct such P using Bob's stealth address by using a hashing function H, choosing a random big number r, and setting P = H(rA)G + B. Then Alice sends the bitcoin to P, the transaction is broadcast along with R = rG (but not r, which can't be recovered from R).

Now how does Bob get the money? Well he has to keep listening on the network for all new transactions in the hopes that they are for him. When he sees Alice's transaction, he performs x := H(aR)+b and realizes that:

xG = (H(aR)+b)G = H(aR)G+bG = H(arG)G+B = H(raG)G+B = H(rA)G+B = P,

that is, Bob can reconstruct x such that P = xG and is therefore the owner of the bitcoin! Notice that neither Alice nor any observer has the ability to derive x (because they don't know a and b), and that besides Alice and Bob no one knows that (x,P) was generated from Bob's stealth address (because they don't know r).

Note that, as mentioned, this protects Bob privacy, but it is still visible to the network that Alice, the entity that used to control that bitcoin, made a transaction. In order to obfuscate that action, Monero implements the use of Ring Signatures, which will allow Alice to, instead of directly signing the transaction, produce a proof that her, or several other people, did send a coin to Bob. The math behind Ring Signatures is not as simple as in Stealth Addresses, but it is still very approachable.

So, in a nutshell:

Stealth addresses take care of recipient's privacy.

Ring Signatures take care of sender's privacy.


How do I purchase Monero when I live in US?

There are plenty of exchanges that allow you to trade Monero, even if you live in the US.


Which country operates the most Monero nodes per capita?

The distribution of nodes varies over time and not all nodes are visible

https://monerohash.com/nodes-distribution.html
Currently the United States has more publicly visible nodes than any other country. However that does not mean that US residents control the most nodes. Since nodes can be hosted remotely and run on VPS, nodes with an IP located in one country can be controlled by someone living in another country across the world.
Network latency can be influenced by geography but there are other factors involved. The increase from 1 to 2 minute blocks helped to level the playing field for miners with slightly worse network latency (and also has helped decrease the frequency of orphaned blocks). It is also worth noting that not every node is a miner.


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


Why were Monero Disposable addresses dropped?

Disposable addresses require the sender to use an unencrypted payment id specified by the receiver.

This means that if funds are sent to a disposable address more than once, an observer can tell that two transactions on the blockchain have the same recipient  because both transactions will share the same payment id. It may have been difficult to educate people that they should not give out the same disposable address to more than one person, and that they should not receive multiple payments even from the same person to any particular disposable address.

Subaddresses can be used instead of disposable addresses, can be safely reused, and can be combined with encrypted payment ids if necessary. The advantage of disposable addresses though is that unlimited disposable addresses can be issued without any kind of "counter" being used.

A counter needs to be used with subaddresses because to check for incoming funds to a subaddress, a lookup table of subaddresses needs to be generated prior to scanning the blockchain for incoming payments. Lookup table generation is a one-off operation (when you first create a wallet), but it does take a few seconds per 10,000 subaddresses to be generated for the lookup table. Therefore you can't just pick a large random number to generate a one-off subaddress that is unlikely to clash with a previously issued subaddress. A counter needs to be used to ensure the subaddress you generate is both unique and within the bounds of your lookup table.

It is possible that disposable addresses may be introduced in the future if there is a strong use case for them that outweighs the risk of their accidental reuse.


Can the sender of the transaction find out via any blockchain explorer, how much money he sent?

Using your spend secret key, you can calculate the key images for all your outputs. Using your view secret key, you can see their amounts. When you check the outgoing transaction in question, you can see which outputs of yours were spent by looking up the key images. This gets you the amount.

A block explorer does not have your secret keys, so is unable to see this.


Where can I find some test inputs and outputs for the CryptoNight (Monero PoW) hash algorithm?

There's a test code for hash functions (https://github.com/monero-project/monero/tree/master/tests/hash) where the expected values are in the txt files.


Installing XMR-stak CPU only on Ubuntu 18.04

You can find instructions on xmr-stak repository itself.
You should basically download the ubuntu/debian release, extract the file, and launch the miner through cli.
It does auto configuration on the first launch IIRC.


How do I connect monero-wallet-cli to a remote node?

monero-wallet-cli supports a command line argument "daemon-address" that allows you to specify the host and port to use instead of the defaults. The argument value takes the form host:port.

So if you wanted to run monero-wallet-cli using a remote node being hosted by node.moneroworld.com, you would launch simplewallet with the following arguments:

  monero-wallet-cli --daemon-address node.moneroworld.com:18089

You can see some of the code that deals with initialization and connecting to the daemon on the github:
https://github.com/monero-project/bitmonero/blob/master/src/simplewallet/simplewallet.cpp#L1215


How can I import a blackball database to improve my privacy?

A Monero blackball database can increase your privacy by avoiding outputs that are known to be spent in other transactions. You wallet will ignore these "bad" outputs and select other "good" outputs instead.

Acquiring the Database

You can acquire a database in several ways, but it's best to build the database yourself. See this answer on how to run the tool. Make sure to convert it from the LMDB file to a text file readable by the software.

If you prefer to trust someone else to provide the database, you can download one at moneroblackball.com.

GUI

To import the blackball database in the GUI, open the program, click on Advanced then Shared RingDB. This will pull up a list of several options. We are interested in the first box here. Click Browse and select the data.txt file you have created or downloaded. Then press Load. It may take a while to load the database, and there is no progress bar at this time. The GUI will become unresponsive while the database is being loaded.

CLI

After opening the CLI, run blackball <filename> add

Example: blackball /home/data.txt add

Note that the file path in the wallet must not contain any spaces.


How does Monero privacy and security compare to Zcash?

As described by Monero Research Lab academic Shen Noether with regard to the anonymity set:

Monero (although the zcash proponents note that a ring signature is a "smaller" anonymity set, they usually don't mention that the stealth address factor actually means that each transaction is masked, whereas the ring signatures provide additional plausible deniability, furthermore, since keys appear in different ring signatures in different blocks in time, the anonymity set for when a given key is spent grows infinitely, and could eventually grow larger than the zcash anonymity set at any fixed instant in time) vs Zcash (anonymity set is the entire blockchain)

The above quote demonstrates that while a Monero ring signature may be a "smaller" anonymity set, stealth addresses mask the receivers identity while the ring signature guarantees plausible deniability. When RingCT is activated in January, 2017 the amount of Monero spent in each RingCT transaction will also become protected.
Zcash uses much newer zero-knowledge proof cryptography called zk-SNARKs. Thanks to zk-SNARKs nodes do not need to store signatures or public keys forever on the blockchain. All transaction data is completely private, including metadata which is encrypted:

Instead of publicly demonstrating spend-authority and transaction values, the transaction metadata is encrypted

Ring signatures are much older than zk-SNARKs and have had many years of extensive peer review. With RingCT, which combine Monero ring signatures and Confidential Transaction As developed for Bitcoin by Greg Maxwell Monero transaction amounts will be hidden and Kovri (I2P C++ implementation) will hide IP addresses. MRL has spend a lot of time researching RingCT and Monero now has funded an experienced full time I2P developer to work Kovri.
Perhaps the biggest security risk with Zcash is the possibility of collusion among those participating in the trusted setup. If all parties involved in the "trusted setup collude (either willingly or under duress) then there would become a possibility for the creation of an unlimited number of coins without detection. Zcash is so private that even the coin supply cannot be verified if the trusted setup described above fails.
Monero did not require a "trusted setup" and total coin supply is easily verifiable on the blockchain in real time. Therefore any exploit altering the Monero coin supply (other than ordinary coinbase transactions) would immediately be noticed.
More details on trustless vs trusted systems and the risks associated with a trusted setup can be found here. In the case of Zcash, only six people participated in the trusted setup process:

The ceremony used a multi-party computation protocol with the property that the resulting parameters are secure unless all of the participants were dishonest or compromised during the ceremony.

This setup process has been received a lot of criticism, and even some critique from one of the best known Zcash advisors, Vitalik Buterin but with a subsequent edit to clarify that he still thinks the risk of compromise is quite low:

I actually recommended a different process for the trusted setup - my preference was to not bother with the airgaps, DVDs, offline laptops, etc and make up for it by having 20-30 participants instead of six and make sure they come from different countries, backgrounds, etc. I got this instinct from my experience managing the ethereum foundation wallet - our original setup was 3-of-4 but had lots of fancy secret sharing, encryption, offline signing and other machinery on each device but at one point it nearly broke, and since then we're using a 4-of-7 hot wallet between online laptops, and I feel much more comfortable with the security of the latter. But these are only my views, not shared by everyone, and others of course have different opinions how the risks and benefits should be balanced.
EDIT: just to be clear, I still personally think that the risks of the current setup having been compromised are quite low.

Peter Todd, one of the trusted setup participants was much more critical:


Preparation

Make sure you have the latest binaries from the official website. Download and extract these. Make a shortcut of monerod.exe. If you would like to run the daemon with certain parameters, create a .bat file and then create a shortcut of the .bat file instead. You can create a shortcut of a file by right clicking a file and then clicking Create a shortcut.

Adding the Shortcut to the Startup Folder

Windows has several startup folders. You can either put it in a folder that runs when a certain user logs in, or in a folder that runs for all users.

Specific User

Go to C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, replacing Username with your actual username. Copy the shortcut here.

Alternatively, you can open Run and type shell:startup to get to this folder.

All Users

Go to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. Copy the shortcut here.

Alternatively, you can open Run and type shell:common startup to get to this folder.


Absolute paths in linux start with /. So it seems you are missing /in your path. It should be /home/samuel/wallet/wallet2


So what exactly the miner_tx_hash field in the block, and what is its relation to the miner_tx and other transactions in the block?

miner_tx_hash is just that - the transaction hash of the miner transaction. The miner transaction is the transaction that pays out the reward for mining the block. The inputs to this tx are type gen as they literally generate new Monero.

  If I use get_transactions() with the value of miner_tx_hash, it seems to find a transaction, but this transaction seems quite different from miner_tx embedded in the block. The one I get from get_transactions() has many more inputs and outputs etc.

Perhaps you are calling or parsing incorrectly. Here is a concrete example using testnet:

curl -d '{"jsonrpc":"2.0","id":"0","method":"get_block","params":{"height":1234567}}' \
  http://localhost:28081/json_rpc \
  | jq .result.block_header.miner_tx_hash

Extracts the miner tx hash: c37d119798660baed9ee62b3fc7323f98487b2e9c6a155be843e238e31fdb415

And:

curl -d '{"jsonrpc":"2.0","id":"0","method":"get_block","params":{"height":1234567}}' \
  http://localhost:28081/json_rpc \
  | jq .result.json | jq -r | jq .miner_tx

Will extract the miner tx (form the same result, get_block with height 1234567):

{
  "version": 2,
  "unlock_time": 1234627,
  "vin": [
    {
      "gen": {
        "height": 1234567
      }
    }
  ],
  "vout": [
    {
      "amount": 6059550665332,
      "target": {
        "key": "81fb44f0bbd9e38e467461aed50ded48f2301ee0b0d553a1d0bc5a8a07cd0263"
      }
    }
  ],
  "extra": [
    1, ..., 78
  ],
  "rct_signatures": {
    "type": 0
  }
}

Now using get_transactions with the miner tx hash obtained above:

curl -d '{"txs_hashes":["c37d119798660baed9ee62b3fc7323f98487b2e9c6a155be843e238e31fdb415"],"decode_as_json":true}' \
  http://localhost:28081/get_transactions \
  | jq .txs[0].as_json | jq -r

Yields:

{
  "version": 2,
  "unlock_time": 1234627,
  "vin": [ {
      "gen": {
        "height": 1234567
      }
    }
  ],
  "vout": [ {
      "amount": 6059550665332,
      "target": {
        "key": "81fb44f0bbd9e38e467461aed50ded48f2301ee0b0d553a1d0bc5a8a07cd0263"
      }
    }
  ],
  "extra": [ 1, ..., 78
  ],
  "rct_signatures": {
    "type": 0
  }
}

Identical.


How is Monero going to defend itself against future attacks on the community, politics etc?

I think that Monero community is adamant at keeping the corrupting money away (the kind of money which could force another direction of the project). This is amplified by the fact that many of contributors are already having a steady cash flow by other means, so they can't really be bought easily. There was an interesting related question on whether the developers should be employed full time.

It is in the nature of open source projects that people just come and do what they like to do, by their own free will. Most of the worlds open source projects don't involve money, but solve some other problem, so it's hard to corrupt those. I believe it is important to keep that kind of open source spirit in the Monero community, and so far it looks like it isn't going anywhere :)

Ideally, contributors would be motivated by only wanting to solve a problem, or build and improve something, just because they like doing it. Pick a problem you like to solve, and just go ahead and solve it. If you involve money in the equation, in a way "you will get paid X to keep doing Y" then it becomes a job and it could mean you're not anymore doing what you like, but are forced to do "Y". It would suck - who wants a 2nd job like this, or even to replace the one they're currently doing just to have all this pressure from various "investors" on their back? That's why I get annoyed by people thinking they can "push" for GUI, it shows that they don't respect people's free time or the open source spirit. In the end, it is the beauty of open source that you're free to say "No".

Also consider, that if someone believes in the project and is willing to spend his time and energy working on it, that he probably loaded up on Monero while it was still around 2$/xmr. I mean, if you're investing your time in future of money, you might as well invest some of your money to capitalize on your efforts. I certainly hope that all the contributors had their bags filled before the run up to 10$.

So to answer your question: by maintaining awareness of how money can corrupt, and keeping the spirit of the project going.


Comparison of Curve25519 with secp256k1?

https://safecurves.cr.yp.to/ (joint work between Daniel J. Bernstein, University of Illinois at Chicago, USA, and Tanja Lange, Technische Universiteit Eindhoven, Netherlands) has rated Curve25519 as "safe"

The specific reasons why CryptoNote creators chose Curve25519 are unclear but it appears to be trusted by top cryptographers.

Monero developers trust DJB, Curve25519 and the fast Schnorr algo (EdDSA).

Riccardo Spagni has stated:

  We will absolutely switch curves if sufficient evidence shows that the curves / algos we use are questionable.


Does monero p2p protocol use magic bytes?

Monero uses the Levin protocol for p2p comms.
Similar question here.

The definitions for the commands are here.


Can Monero ever have a 10 sec. block-time?

I don't think so, and I'm not sure it would work out long term for ethereum either, although they plan to switch to proof-of-stake and implement sharding, both of which would possibly help.

Monero actually used to have a 60 second block time, and then in March of 2016 switched to a 120 second target time. There are several issues with a very fast block time, some general and some unique to Monero (or other coins using a slow to verify hash like cryptonight).

The shorter the block time the more bloat you get for empty or nearly empty blocks. By forcing users to store empty blocks you are just wasting space basically. By increasing block time you should get more txs per block and therefore more efficiency. This probably becomes moot once a coin gets widely used, but that is basically only Bitcoin at this point.
The shorter the block time the higher the probability of orphans. Ethereum deals with this using their uncle concept, which I believes rewards miners even if their block gets orphaned, but that concept doesn't exist in Monero. Monero's proof-of-work algorithm is also pretty slow to verify, so for very short block times this may become a factor that contributes to increasing the orphan rate even more.


Monero-specific podcasts:

Monero missives : 11 episodes are available on Monero official site. Last one is from March 19th, 2015
Monero Monitor : a podcast started in March 2017 by bigreddmachine

Episodes:

The Bitcoin Game : core member fluffyponyza was the invitee of a double episode in 2017 (part1, part2)


No. There is no current public I2P testnet.

The I2P protocol already specifies a NETWORK_ID (equal to 2 for mainnet), so it should be easy to add.


Why don't the XMR-Stak Linux release binaries support NVIDIA GPUs for cryptonight_r?

XMR-Stak makes use of NVRTC for mining CN/R on NVIDIA GPUs. NVRTC was added in 1cb52145, and then was disabled in 42112950 for the Linux release build.

On Windows, they ship the NVRTC shared libraries (.dll files) alongside the release executable, and because of the way Windows searches for needed DLLs, it will also search in the current directory of the executable for them - meaning they will be found and loaded fine at runtime.

On Linux, you cannot just place shared libraries in the same directory as the application and expect the loader to find them. It doesn't work like this on Linux. There are a number of ways to achieve the same, but each way has its own strengths and weaknesses. So I can only presume it comes down to how important this is to the developers & community - especially given that CN/R is only really a stop-gap until RandomX is released, and the fact that Linux users are likely far more comfortable compiling and installing from source than your average Windows user.


How do I make RingCT transactions now after the recent hardfork?

You will need to wait activation first, which will happen in about 8hrs or so.

For end users, it will be seamless: the transfer command will be making RCT transactions by default. Just make sure you're running v0.10.1. The GUI will also default to RCT transactions.


Coins Not Appearing (GUI Wallet) - Transaction on Blockchain, Wallet Synced, Cache Deleted

Try mymonero first, maybe your local data was not updated.

国人？


How can I distinguish between transactions (send vs. receive)?

If a transaction includes a key image in a ring which corresponds to one of the outputs you own, then it is a transaction you sent. If no key image in a tx corresponds, then it is not a transaction you sent. This holds regardless of whether any output is sent to your address. Usually, when you send money, there will be a change output back to you, but not always.


XMR-STAK [CUDA] Error: the launch timed out and was terminated

I haven't played with my systemctl script in a while, but here are my notes. They are close to yours, except for my file name is xmr.service and there are two additional commands at the end. Hope this helps.

Create systemd startup script
Create new file xmr.service in /etc/systemd/system

Add the following snippet:

[Unit]
Description=XMRig
After=network-online.target

[Service]
ExecStart=/PATH/TO/MINER

[Install]
WantedBy=multi-user.target

Perform these commands:

systemctl daemon-reload

systemctl start xmr.service

systemctl enable xmr.service


I answered this on Reddit. Basically this error is caused by an incompatible wallet cache, which results in the GUI not being able to open the wallet. Therefore, one has to "trick" the GUI into creating a new, compatible wallet cache. This is done as follows:

Exit the GUI.
Browse to the directory your wallet files are located (Documents\Monero\<wallet-name> on Windows | home/<username>/Monero/<wallet-name> on Linux | Users/<username>/Monero/<wallet-name> Mac OS X).
Rename <wallet-name> (the file without extension, i.e., the wallet cache) to <wallet-name>-old
Restart the GUI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.


From the pools docs:

Required fields are payment address and MinerIdentifier

    Username format : address.paymentID+FixedDifficulty
    Password Format : MinerIdentifier:Email

So your password needs to be your_miner_id:you@email.com.

EDIT:
Of course the above is for your miner settings. When you have the miner with these settings, you can then login to the dashboard with your payment address as username and email address as the password. If you did not set your miner settings correctly, you won't be able to login to the dashboard.


Correct Monero address but wrong payment id - MyMonero wallet

You don't have to use a payment ID when you're sending to your own wallet. Thus, simply use your wallet's address and nothing else. More information about use cases of the payment ID:

What is a payment ID, and why is it used?

https://monero.stackexchange.com/questions/tagged/payment-id

P.S. If you want to verify that your transaction correctly arrived, use this guide:

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


Can you make a send transaction with a monero remote node setup?

Yes, you can.
First of all, a "remote node" simply means a full node which is not running on the same machine as your wallet software. Any remote node is a full node. Maybe you control it, maybe you don't. If you connect to some node on node.moneroworld.com then those will belong to other people who're running a full node and have opened them to remote wallets.

In the diagram above, we can say the following:

Network 2 is probably the most common set-up. One machine, one node, one wallet. Node N5 is a localhost node to wallet W4 because they're on the same computer as the node. The node N5 is not accepting wallet connections from outside, so it can not be used as a remote node. This is the default set-up for people running a full node. Of course, the user can add more wallets easily, they will all connect to N5 automatically.

Node N1 is a localhost node to wallets W1 and W2 because they're on the same machine as the node.
The node is also accepting wallet connections from local network and because of that N1 is a remote node to wallet W3 since N1 and W3 are running on different machines. Since N1 is not accepting wallet connections from the internet but just from local network, we could say it's a private remote node.

Machine PC4 runs only the wallet W5 and no node. It must connect to some remote node to be able to refresh the wallet and send transactions. It's connected to a public remote node N2. If owner of machine PC4 wants to sync another wallet, he must connect it to a remote node as well. Since every new wallet refresh requires sending some data between the wallet and the node, it's not efficient to use remote nodes for many wallets. Would be better to download the whole blockchain by running a node and then you're much faster to sync each wallet.

Setting up a remote node requires access to a full node that has the entire blockchain downloaded right?

"Setting up a remote node" just means that you run your node with a few extra parameters, and that you allow your firewall to accept incoming connections, as explained on the same site you linked. So, a remote node is a full node and it also has the full blockchain downloaded - just like any node.

How To Include Your Node On Moneroworld
If you would like to offer your node up for inclusion in the Moneroworld Network of Open Nodes, you can simply add the code bellow to the launch of your daemon (and open your firewall), and the MoneroWorld script will sniff you out and add your node to the random list.

--rpc-bind-ip YOUR.EXTERNAL_IP.GOES.HERE --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind

So does this mean my remote node can do everything as if it had the full blockchain downloaded?

"as if it had the full blockchain downloaded" doesn't make sense. Any node has the full blockchain downloaded by definition. If you mean whether your wallet connected to a remote node can do everything then yes, it mostly can. You can refresh and send, but can't mine or control the node in other ways.

What are some cons about this setup?

It's slower and wasteful if you need to sync multiple wallets
It's putting extra load on people who volunteer to run their remote nodes
It doesn't help the network
It allows your TX-es and IP to be linked by the node
Maybe some other privacy loss (because the node provides you with the decoy outputs as well but I'm not sure if the wallet or the node decides the block heights)

Can I make a send transaction using a remote node setup? Currently the remote node is setup to node.moneroworld.com port 18089

Yes.


How to have visitors mine on my websites and is it legal?

As long as you ask for their permission I can't see why it could be considered illegal. Coinhive considers it a viable alternative to adverts thus not illegal. In addition I don't think mining on peoples computers using a webpage is any worse than reselling customer information to advertisers.


Pool live tracker showing different hash rate than the miner log

What your miner reports and what the effective hash rate your pool receives are often different. I'd say 10-30% lower than what your machine reports sounds about right, actually.

This is mostly because not every hash your machine produces is accepted by the pool, and so you have a certain threshold of shares that don't get submitted or accepted. The hash rate you see on your pool is an approximate guess at your hash rate based on the number of accepted shares you receive over time.

However, if you did want to test to see if you aren't getting messed around by your pool, try connecting to a different one for a couple of hours and compare results. Also be aware that it is possible that your mining software reports hash rates which are higher than they actually are. Some software providers have been known to do this to give the appearance that their mining software is better somehow.


Generated wallets on testnet receive no transactions

This is most likely the bug fixed in https://github.com/monero-project/monero/pull/2542. If you can't or won't patch your copy to include this small fix, a workaround is to ensure you have a synced daemon when you create the wallet, so that monero-wallet-cli can access it to query the current blockchain height.


Monero Daemon - cannot send transaction(s) no available connections

This means exactly what it says: you have no peers (or no suitable peers) to which to send transactions. This happens at startup if you have transactions in your txpool, since you've not connected to the network just yet.
If it happens later, it can mean you've been disconnected from the network for a few minutes, or your daemon is forked from the network.
If you're using Tor and/or I2P, it can mean monerod cannot find enough peers of that type to keep an active connection all the time.
If you run "status" in the daemon, you'll get the current number of in and out connections to other monero peers. If you have 0 and 0, you are disconnected from the network.


Monero wallet stuck synchronising and I don't understand the "unstuck" guide: please clarify

If you're stuck on height 1400001, it's very likely you're using an old version which doesn't know about the new fork consensus rules, so fails to see the new blocks as valid. You need to update your wallet to 0.11.1.0 (0.11.0.0 would also work, but has a few sync bugs, so switching to 0.11.1.0 directly is best). Just replace the binaries with the new ones, or pull from git and build, that's all you need to do. After restarting monerod and wallet to use the new code, it should start syncing again till the end.


monerod block height is 1,500,000 - How do i pop off 100,000 blocks and start syncing at 1,400,000 instead?

The command you are searching for on linux called:

  ./monero-blockchain-import --pop-blocks 100000

and on windows you need to use

  monero-blockchain-import.exe --pop-blocks 100000

A detailed howto is on point 4 at this answer from dEBRUYNE.


ELI5 why Monero blacklists are impossible

The recipient of a transaction does not know the address the money came from. Monero addresses aren't on the blockchain at all.

In Monero, every single output is on its own one time address. Only someone with the view secret key of the matching Monero standard address can tell whether a given output corresponds to that address. So the recipient of the transaction, having just their own view secret key, can only tell the incoming outputs are for that address (good!), but cannot tell where they are from.

A good way to visually understand this is to imagine a large open ground, with lots of RC vehicles in there, and a number of people at the side, each controlling a number of those. The people on the side have their standard address and keys (the remote controls), and the state of the vehicles on the open ground is the blockchain.

Now, an observer can't tell which vehicle is controlled by whom. Everyone's playing with their remote controls, vehicles drive around, but no way to tell who controls what.

Now, a vehicle sports a slogan a prosecutor deems Very Bad(tm). The prosecutor wants to know who controlled that vehicle. No way to know without extraneous evidence (eg, CCTV evidence showing the person handling the vehicle, etc).

Now, every single person will know which cars are theirs, and they're able to leave them stopped, or move them around. But an observer doesn't know.

You can then give one of your remote control to another person. That person now controls your car, and you can't anymore. Someone watching the open ground can't tell what happened. The car can still move around, but the controller is different.

Note that this addresses your question about "funds coming from a certain monero address". There are other arguments that can be made for other requests such as "funds moving this particular output on the blockchain", if you were to ask that question :)


What’s the difference between sharding and pruning?

Pruning the blockchain means removing some data from it, like old transaction signatures and range proofs.
For example, your Monero daemon could store an incomplete version of all the blocks older than one week (no signatures, no range proofs) to save some space, and it would still have all the info (inputs, outputs) allowing a wallet to check its balance.

Sharding means means separating the blockchain data in several sets, and storing only one of these sets.
For example, if there were a set for blocks with an even block height and a set for odd block height, your Monero daemon could store the data for blocks with an even block height only. In this case, a wallet would have to connect to several nodes (at least one in each set) to get all the info allowing it to check its balance.