Issue with unforgeability proof of ASNL in RingCT paper

Github user divbit responded to the issue on Github here. To quote:

Hi, the paper states that it is a sketch of a proof (mainly it's a sketch because the things are no more efficient than the Borromean ones which are mentioned could be used on a previous page, and possibly less efficient according to the Borromean paper, in some cases (e.g. higher bases than 2 or whatever, and I guess at the time of writing the Borromean paper didn't have a proof written out, but it was sort of publicly in progress on their github, so the author didn't want to sort of steal possibly a big chunk of their paper).
Anyway, I think the point in assuming the 'a', 'b' values is that since various other bits of information are determined by the time-travel stuff (since you have to produce L1, L2 before knowing c1, c2) then at the end you need to find a scalar 's' so would need some way to get a scalar from the other bits of information which are already determined at that point). Moving sG by itself, it is easier to find an 's' when you already know a,b, so presumably if you can't find 's' with that advantage, then you can't find 's' without the advantage. But- this section of the paper hasn't been reviewed much, and it is just a sketch, so let me know if you see an error in that. BTW, the author e-mail is apparently not provided at the paper, so one might assume they are not open to correspondence, however, it's sort of publicly known from their github (shen.noether@gmx.com) which is linked on the first page of the paper, so I would assume they are open to correspondence for this type of question.


Why wallet app from getmonero.org need 3 pieces of information to recover wallet, when only 1 is enough?

Secret view key can usually be derived from secret spend key. It is only the case if you generate a wallet this way. It does not have to be this way. The address can be derived from both secret keys. Asking the address too introduces a way to spot errors when entering the data. If the address does not match what the secret keys generated, then you know you made a mistake in the inputs.


monerod v0.12.2.0 does not start on Linux because of "./monerod: error while loading shared libraries: libpcsclite.so.1"

This particular issue is resolved in CLI & GUI v0.13.

First, this error is caused by the libpcsclite dependency (which is required by Ledger) not being properly compiled statically. Fortunately, however, this error is trivially resolved by installing libpcsclite1. That is:

sudo apt-get install libpcsclite1

Fedora:

dnf install pcsc-lite

If, after installing this dependency, monerod still does not run and throws the same error, I'd recommend installing libpcsclite-dev (Ubuntu / Debian) or pcsc-lite-devel (Fedora)

Sources:

https://www.reddit.com/r/Monero/comments/8ok4hg/v01220_binaries_released/e0e0zoq/
https://www.reddit.com/r/Monero/comments/8ok4hg/v01220_binaries_released/e04w05u/


Does /get_transaction return ring signatures or key image?


Benefits of running a Monero GUI and full node over Raspberry PI with Tails rather than on home PC

1)

  what is the IP and is it broadcasted when you do transactions?

The IP is whatever IP your ISP assigned to you. If you use a remote public node when transacting, it is leaked. It is not however "broadcast" in the tx.

  I don't understand how running your own node is better for privacy when the transaction has to be broadcast

Because when you create a tx and let your own full node broadcast it, other nodes have no way of knowing whether your node is the original node sending the tx (i.e. nodes just relay transactions to their connected peers).

Contrast this to using a public remote node instead of your own node. That public node knows you are the source of the tx. A malicious operator could log your IP address alongside the tx ID.

  doesn't your home IP address which your ISP gives you get broadcasted

See previous point. Your node leaks your IP to other connected peers, but when you relay a tx, the other nodes have no idea if your node was the first/original node (i.e. whether you created the tx). So using your own node, all you are essentially leaking is the fact you are using Monero.

2) No you do not need to keep your node running 24/7. Every time you start it, it will sync up from where it was last.

3) The Raspberry Pi is a poor choice to run Monero on. It has no hardware AES. There are better equivalent SBCs such as Rock64/Rock64Pro, Odroid and others. Some obvious reasons people may prefer these to a full on Windows PC are because they the are low power, small size, cheap and silent - ideal to just setup, switch-on and leave running.

4) Probably, but why not just buy (but not an RPi, see previous point) and install your own? You're asking all the questions after all.

5) Answered in point 3.


Is there a command line tool like bx to bitcoin that I can use with cryptographs

Monero uses several special methods like Keccak hash function or CRC32 etc

There is nothing particularly special w.r.t. Monero's usage of Keccak or CRC32.

  Is there a command line tool like bx to bitcoin ... I would like to generate key pairs from seeds manually.

I'm not familiar with bx, but the official monero-wallet-cli can be used to convert a seed phrase into a wallet file, a keys file (private view and spend keys) and a Monero address (public view and spend keys). For example:

monero-wallet-cli --restore-from-seed --generate-new-wallet new-filename \
    --electrum-seed "your seed words..." \
    --mnemonic-language English \
    --password "some optional new password" \
    --restore-date `date "+%Y-%m-%d"`

Or to get the seed words etc for a given key:

monero-wallet-cli --generate-from-spend-key new-filename \
    --mnemonic-language English \
    --password "some optional new password" \
    --restore-date `date "+%Y-%m-%d"`

There are also various implementations floating around to create addresses/seeds, such as https://xmr.llcoins.net/ and you can use various tools to create valid ed25519 keys, such as openssl genpkey -algorithm ed25519.


My hash rate is low and volatile and my wattage is high?

Take a deep breath.

Use restore points.

Follow the guide provided by CircusDad at vega.miningguides.
You should be able to run your Vegas at much lower than 300W and keep stability.


WINDOWS - GUI v0.12 does not launch / start

This issue can be caused by two things, namely (i) the path to monero-wallet-gui.exe contains a non-ASCII character or (ii) monero-wallet-gui.exe cannot properly use OpenGL rendering. The first issue will throw an error similar to this:

"Runtime Error" - This application requested the runtime to exit in an unusual way.

The second issue, however, will not throw an error. These issues are resolved as follows:
Issue 1:
Ensure the GUI v0.12 binaries (the .zip file) are extracted to a directory whose full path does not include non-ASCII characters. Thereafter, however, it could be that you incur issue 2.

Issue 2:
Launch the GUI v0.12 via the start-low-graphics-mode.bat that is included. This ensures the GUI uses the Qt Quick 2D Renderer instead of relying on OpenGL. More information about the Qt Quick 2D Renderer can be found here.

Qt Quick 2D Renderer is an alternative renderer for Qt Quick 2 that uses the Raster paint engine to render the contents of the scene graph instead of OpenGL. As a result of not using OpenGL to render the scene graph, some features and optimizations are no longer available. Most Qt Quick 2 applications will run without modification though any attempts to use unsupported features will be ignored. By using the Qt Quick 2D Renderer it is now possible to run Qt Quick 2 applications on hardware and platforms that do not have OpenGL support.
Qt Quick 2D Renderer is a Qt module that contains a scene graph renderer plugin.


What is the difference between Monero (XMR) and Grin (GRIN)?

Pardon the image, but there is no way to create tables in StackExchange.

Grin's privacy is best characterized as "Monero with aggressive pruning and no ring signatures." Users who are unable to get access to old information cannot pull up past transaction information by looking at the current ledger state. However, those who receive transactions as they are broadcast can see the inputs and outputs for individual transactions. This effectively indicates whether outputs are spent, something that is not possible with Monero. Grin uses "confidential transactions," a technology that hides transaction amounts, nothing else. The output transaction graph is hidden through obscurity of information, not anything committed on-chain.

Monero's scalability has improved significantly over recent years. Transaction sizes fell from ~13 kB to ~1.5kB. Monero now supports pruning, allowing users to ignore most of the information for old transactions. Still, Grin allows more information to be pruned, and they prune it much faster.

I did not include network privacy on this chart, since both Monero and Grin provide network privacy. Monero provides support for Tor and i2p, and it later will provide support for Dandelion++. Grin supports Dandelion++, and users can use Tor or i2p if they configure it manually. Transaction network obfuscation is important, but it's less important for most people than graph protection.

I like to think of Monero and Grin as projects that are pushing the privacy and scalability boundaries, each beginning in different positions. Monero is focused on a privacy angle with scalability second, whereas Grin has the opposite focus.


To call the binary methods, you have to send raw binary data as an application/octet-stream in the request body and read the binary data sent back in the response body.

There's a StackOverflow answer that shows making binary requests using Python here. Quoting the requests library example:

import requests

data = 'test data'
res = requests.post(url='http://localhost:8888',
                data=data,
                headers={'Content-Type': 'application/octet-stream'})

Here you would replace data with the binary tx id (which is 32 bytes), wrapped as a Levin packet. A brief overview can be found here.

For working out how to serialize the request data and deserialize the returned response data, you should start by looking in this folder.

Here is an annotated response for the interested:

0111010101010201        signature
01                      version
0c                      section
09 6f5f696e6465786573   field: string length then data: o_indexes
85                      type (uint64 | array flag)
08                      length 2 (0x08 >> 2)
aca87f0000000000        idx
ada87f0000000000        idx
06 737461747573         field: string length then data: status
0a                      type (string)
08                      length 2 (0x08 >> 2)
4f4b                    OK
09 756e74727573746564   field: string length then data: untrusted
0b                      type (bool)
00                      false

Here is a quick and dirty example of calling then parsing the response using Python.


Genesis block successfully created but not visable in wallet-cli

i had the same problem. The thing is that the wallet does not process the genesis coinbase tx.

To process it,  edit the src/wallet/wallet2.cpp after line #2131.

add

if ((m_blockchain.size() == 1) && (start_height == 0)) {
    cryptonote::block genesis;
    generate_genesis(genesis);
    if (m_blockchain[0] == get_block_hash(genesis)) {
      LOG_PRINT_L2("Processing genesis transaction: " << string_tools::pod_to_hex(get_transaction_hash(genesis.miner_tx)));
      std::vector o_indices_genesis = {0}; //genesis transaction output
      process_new_transaction(get_transaction_hash(genesis.miner_tx), genesis.miner_tx, o_indices_genesis, 0, genesis.timestamp, true, false, false, {});
    } else {
      LOG_ERROR("Skip processing of genesis transaction, genesis block hash does not match: " << string_tools::pod_to_hex(get_block_hash(genesis)));
  }
 }

reference : gist.github.com/atanmarko/63815fc18a936d8a985a37e64d84b06d

make sure the one-time pub key at the genesis-hex-tx is well generated. if it is so , with this code you should see the reward on your wallet.

if it not so see

Monero Genesis transaction & nonce - clarification

hope this helps you


You can have a look at the hashrates of various GPUs and CPUs on monerobenchmarks.info or google docs monero gpu/cpu comparison.

The GTX 1080 should get around 590 H/s, which at the current difficulty should get you around 0.04 XMR per day.

Whether this is profitable or not depends on your electricity costs, at $0.12/kwH, you should expect the card to cost about $0.51 in power per day to run (not including the rest of the system).

You can use the cryptocompare mining calculator to check things out for yourself.

Have fun :)


If you want to do it by yourself and not rely on a block explorer, you should read the Daemon RPC Guide and look specifically at the get_block method.


The dev branch has been canned, and the 0MQ effort is being refactored / partially rewritten by tewinget. Unfortunately the net_skeleton licensing issue isn't one we can work around, as far as we can tell, so we are actively looking at an alternative. Note that you can, right now, stick something like nginx in front of it to handle both authentication and TLS, and use nginx's proxy_pass to reverse proxy the RPC calls. In fact, this may be a preferable route for a security-conscious exchange, as nginx can provide fine-grained control over user access, TLS cipher suites, and so on.


Miner publishes a block to the network with a lag

When a block is found by a single party it is not added to the blockchain immediately as it is only accepted as a true block by one party, more confirmations are needed by other miners first before the hash found is considered to be an accepted block on the chain.

Thus, more confirmations are needed before everyone can see the newly found block on their nodes.


Do I need to wait for the entire blockchain to download before daemon will connect to wallet?

When you setup your wallet, you will have had an option to use a Bootstrap Node. A bootstrap node allows you to use your wallet whilst your own full node is downloading the blockchain.

This said (and assuming you didn't select to use a bootstrap node), the fact the GUI says it is not connected to the daemon suggests some other issue. Even though you can see in another window the blockchain is downloading, the GUI should still be connected and a progress bar showing progress of the blockchain sync. I suggest killing all Monero processes and restarting the GUI as a first step.


If I delete the .bitmonero data.mdb, will it delete my wallet or the ability for me to access my wallet?

No, deleting data.mdb will not delete your wallet.  The data.mdb file is the blockchain.  Deleting it does not affect your wallet.

Your wallet has a name of its own.  You'll know what it is because it has at least one sister file that holds its keys.  In other words, you'll know what "your_wallet" is because you'll see your_wallet and your_wallet.keys (and maybe your_wallet.txt).

A blockchain and its daemon are needed to be able to update your wallet and send funds.  If you delete the blockchain, it implies you're happy sacrificing some level of privacy in favor of saving the space and related minor benefits.  The privacy sacrifice is because you'll be forced to use a remote node.  There are other posts on the Stack Exchange that explain the implications of using a remote node over your own node.


How does key images work when you create a transaction using two or more of your previously unspent transaction outputs?

Monero's ring signatures typically use a ring size of 7, which means 1 real output and 6 decoy outputs.

However, there are several rings if you spend several outputs. Therefore if you spend 5 outputs, there will be 6*5=30 decoys.


Possible error in book Zero to Monero: Second Edition

Is this an error or am I misunderstand something?

No it is not an error, you are misunderstanding.

Since the group is cyclic, we can identify it with... Next we check if 5 is in...

Group elements are EC points, not scalars.

Now 2 · 5 ...

In the book, page 15 bullet 3, hP is a point multiplication, i.e. point P added to itself h times.
UPDATE incorporating your question edits above and comments below
With an initial group of {0, P, 2P, 3P, 4P, 5P} then using point 2P to select a subgroup with order l = 3, we have the subgroup {0, 2P, 4P}.
Now per the book, selecting a random point (5P in this example), we have:
h = N/l = 6/3 = 2
P' = 5P
P = hP' = 2P' = 4P

Again per the book, because P (here P = hP' = 2P' = 4P) is not 0, it is in the subgroup of order l = 3, which we can see is correct, 4P is indeed in the subgroup {0, 2P, 4P}.
I believe your confusion is this:

So by the algorithm, 5P' is in Z/(l)!

This statement is incorrect. Using your notation, the algorithm is actually saying 2(5P') is in Z/(l).


I get "bus error 10" when trying to run monerod

BUS error most likely happens when you have a corrupt database, which causes the LMDB code to try to access an invalid memory page, causing the SIGBUS.

Unfortunately, it means you have to delete your data.mdb and resync from the network.

If you're seeing this, it might be prudent to set a "safer" database acccess mode. See Why does my bitmonero fail to load?


What would be the fastest way to implement Dominant Assurance Contracts (which depend on multisignature transactions) with Monero?

There is no simple built-in multisig option for now with Monero, we'll have to wait for RingCT and the multisig extension built on it.

So for now, probably there is no option to implement it at all.


To my understanding, if not specified, account_index will default to 0, while subaddr_indices will allow the wallet to use outputs from specified sub-address indexes as inputs.
If you specify multiple subaddr_indices, you restrain the wallet to only pick from those. But it will depend on the outputs available and the amount you want to transfer. It could pick one from one subaddresses, or more from the same or from other subaddresses.
However, you cannot send from multiple accounts at the same time.


How do I make my macOS detect my Ledger Nano S when plugged in?

PLEASE NOTE!!!!!! With the launch of the official 0.13 Beryllium Bullet CLI and GUI wallets, the following guide is now redundant. You should be able to set up the Ledger Nano S without the need to complete this guide.

Part 1 - Check if you have Smart Card Services installed.

Open a Finder window. Then press CMD + SHIFT + G. Paste the following into the prompt window and select Go:

/usr/libexec/SmartCardServices/drivers/

If Finder can find this folder, then you have Smart Card Services installed and can move onto Part 2. If Finder doesn't find this folder, then you will have to install the the Smart Card Services by choosing the correct installer for the macOS version you are using. You can find the installers here:

https://smartcardservices.github.io/installers/

Once installed, you can move onto Part 2.

Part 2 - Disabling SIP (System Integrity Protection) in order to edit a file.

You will need to boot into your Mac's Recovery OS in order to edit a file. To do this, restart your Mac and immediately hold down the CMD + R keys after you hear the Apple startup 'boooong', until you  notice you are in the Recovery OS (this will have a light grey background and will look different to your usual user account desktop). Ignore the macOS Utilities window and move onto point 2.
Launch Terminal from the Utilities menu.
Enter the following command and press Return:

csrutil disable

Restart your Mac.
Once restarted, open a Terminal window and type:

csrutil status

Press Return and you should see the following message:

System Integrity Protection status: disabled.

If it says that it's enabled then you may have to repeat Part 2.

Part 3 - Editing a file.

Open a Terminal window and paste this command:

sudo nano /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist

Press Return and you will get asked for your user password. Enter it and press Return. You will then enter the editor.

Using your down arrow key (or you might be able to scroll using your mouse), scroll down the file until you see:

<key>ifdVendorID</key>

Immediately following this, you will see there is an <array> tag. Inside the <array> tag there are many <string> tags on separate lines. Begin to scroll down the <string> tags until you get to the last one inside the <array>. Move the cursor after the last closing </string> tag and press Return to go onto a new line.

Press the Tab key twice to indent the cursor and then paste/type the following:

<string>0x2C97</string>

Immediately after the closing </array> tag, you will see the following:

<key>ifdProductID</key>

Like before, begin to scroll down the <string> tags until you get to the last one.

After the final </string> tag, make a new line, indent twice and paste the following:

<string>0x0001</string>

Immediately after the closing </array> tag, you will see the following:

<key>ifdFriendlyName</key>

Like before, begin to scroll down the <string> tags until you get to the last one.

After the final </string> tag, make a new line, indent twice and paste the following:

<string>Ledger Token</string>

To save/write out the file, press CTRL + O. Then press Return. The file has been saved.
Press CTRL + X to exit the editor and then close Terminal.

Please note: Even if the <string> you need to add already exists, you will still need to add it, despite it being a duplicate.

Part 4 - Enabling SIP (System Integrity Protection) to restore Mac OS security.

Once again, boot to the Recovery OS by restarting your machine (see Part 2.1 for this explanation).
Launch Terminal from the Utilities menu.
Enter the following command and press Return:

csrutil enable

Restart your Mac.
You can check that SIP has been enabled by opening up a new Terminal window and typing:

csrutil status

Press Return and you see the following message:

System Integrity Protection status: enabled.

If the status is disabled, then you will need to redo Part 4, otherwise your Mac might be at risk.

You are now ready to generate a wallet from your Ledger Nano S.

Further information

Configuring SIP


Anyway to pick which monero subaddresses one can use?

Subaddresses are deterministic. Your wallet will only search ahead 200 subaddresses at a time in order to check for incoming funds at those addresses. Therefore it would not be recommended to attempt to discover 'vanity' subaddresses, because it would later be more complicated to restore your wallet from seed and instruct it to search for incoming funds at very high subaddress indices.

If you really want to do this, you can just keep clicking the button to create additional subaddresses in the GUI, or use the address new command repeatedly in the CLI. See instructions here for restoring your wallet in a way that will scan to higher subaddress indices: Funds received from subwallet are not showing

Setting up the wallet to scan for larger numbers of subaddresses is a computationally expensive one-time operation, after which blockchain scanning speed will not be increased. This means that if you're willing to tolerate the one-time setup costs, you can monitor huge numbers of subaddresses without slowing your computer down.


How can I check if my node allows incoming connections?

You can type the command status in monerod. This will show something like the following, in green:

  Height: 1226605/1226605 (100.0%) on mainnet, not mining, net hash
  51.39 MH/s, v4, up to date, 8+6 connections

The first number in the 8+6 connections part refers to the number of outgoing connections. The second number refers to the number of incoming connections.

If you see a positive number after the plus (+) sign, then your node is allowing incoming connections. In the example above, 6 incoming users are connected to my node. If it showed 8+0 instead, I would have no incoming connections on my node and it is probably not set up properly to allow incoming connections.


http://xmr.llcoins.net/checktx.html tool does not work

Yes, a couple of people reported it already. Unfortunately, it's up to the moneroblocks site to resolve the matter or to the author of the webpage (or anyone else, really) to change the service from which the site fetches block info.

Alternatively, you can use this block explorer to check any TX, as in the linked example. Just find it first and use the interface to input address and viewkey and it will show you the real output and the amount!


What is meant by "Diffie-Hellman exchange" in the official CryptoNote paper?

Diffie-Hellman key exchange is a key negotiation mechanism to agree on a common key between two parties using an insecure channel. How can you do a key exchange between two values both available to you?

Both values are not available to the party you want to communicate with. If you were to transmit both values, then someone could intercept them and know the secret as well.

Sender: has TX private key r ("sender's random data" in CN WP) & recipient public view key A.

Recipient: has TX public key R (published on the blockchain) & recipient private view key a.

Product will be the same. You can get the shared secret as either rA or aR.

Where's the money? Money resides on one-time key P (AKA "output"), deterministically constructed from the shared secret and the recipient's public spend key.

The sender is communicating the R and the P via insecure channel - the blockchain. Anyone can see R and P, but only the one knowing both the shared secret and the public spend key will be able to recognize the funds. To spend, he would need the private spend key. Why can he recognize the funds? Because the Ps are deterministically made from shared secret. The sender just computes the aR, generates some P, and if it matches the one in the TX - it must be for him.

It's important to understand that one-time keys are all that exists on the blockchain. An address is nothing but an instruction to sender, allowing him to use the DH to construct such output which only the intended recipient can decode and spend. The address is never recorded to the blockchain.

  I thought the recipient's address is public and therefore no connection is required.

The address is public. Since it's really an instruction, and following the instruction requires some "random data" as an ingredient, nobody can ever tell which instruction was followed to create a particular one-time key (AKA "output") on the blockchain.

  Also, if there is a DH between the sender and the recipient how is that anonymous?

Because what happens is that nobody knows who the "message" is for (message being the output in any TX) unless he's able to reconstruct a match - which means it's either for him, or he's the one who sent it. Anyone receiving needs to take the R, pretend all outputs are "for him" and see if he gets a match. That's also the reason wallet scan takes time.

  Where is the other party?

Other party is the recipient.

  Where is the insecure channel?

That's the blockchain.

  Also, why not use just a simple hash of those two values?

Actually, it's used. Look at how outputs are constructed:

P = H_s(rA||i)G + B

H_s is the hash function, r is the TX private key randomly generated by the sender, i is output index in the TX (0, 1 ...), and B is the recipient public spend key. Note that recipient address is made of A and B.

Send & Receive Process

Here's a step-by-step:

Recipient asks the sender for payment and transmits his address to the sender. That's the two public keys A & B. Suppose Eve is listening on that communication - she now knows the address being transmitted.
Sender generates some random r which will be used as private TX key.
Sender calculates the public TX key by multiplying the r with elliptic curve base-point. R = rG. This goes into TX header, and will be published on the blockchain with the TX. Eve is of course monitoring the blockchain, and now she has A, B, and R.
Sender calculates the P which will hold the funds. P = H_s(rA||i)G + B.
Sender publishes the TX with the R and P to the blockchain. This is practically what defines your TX output side. The rest of the data is the signature & key image. This is all that's recorded. Notice how there's no recipient address :)
Here's where DH happens. The recipient will need to try and reconstruct the P, but to do it he needs all the parts. All parts but one are public, and Eve will also know all of them. Thing is, the recipient doesn't know the last bit (the r) and neither does Eve. Without the r, the recipient could be anyone as hash function makes the output look like it's just some random number, same like any other. However, the recipient doesn't need the r as he knows another secret (his private viewkey a) and he can use it instead. The recipient takes the R and i from the TX, does P' = H_s(aR||i)G + B, and if it matches the one in the TX, ka-ching.

So, without the last secret ingredient, Eve remains clueless. She knows that I gave you my address. She knows about all TX-es on the blockchain. She can't tell whether I ever received anything to that address.

If I, the recipient, leak my a to Eve, she can check the entire blockchain and see all TX-es I received. If you, the sender, leak your r to Eve, she can only check a particular TX against some address and see if it's a match. So, thanks to DH, we both get to keep our secrets but are able to safely communicate the following info "this output was made for you".


What is the reason for using the smoothly decreasing block reward?

One of the pros for a smooth curve is to avoid the arbitrary sudden changes.

A second, more subtle, reason is to allow a block size penalty. In most Cryptonote coins, including Monero, it is possible for a miner to create blocks up to the current block size limit (that block size limit is variable, based on the recent history). However, if the block size is between M and 2M, with M being the median of the last 100 block sizes, the block reward will be less than the full reward. This incentivizes miners to not go over the median, which will cause the block size limit to shrink, unless they can make up the loss from transaction fees.

When such a penalty occurs, the recurrence function pushes back the unpaid block reward to the remainer of the emission, slightly increase every single block reward thereafter till the minimum emission (0.3 monero a minute) is hit. This would be difficult to do with a hard segmented block reward.


Suggestions on how to consistently get more outputs?

Take a look at a response to issue #2351:

  You can send 50 monero 20 times in one tx to yourself (make sure you have set merge-destinations to 0 first). This will break up the 1000 output.
  Also set min-outputs-count and min-outputs-value to, say, 20 and 10, see the commit message for 0ad87db for an explantion of how they work. Last, you can pay several destinations in the same tx, which means no intervening change. Payment id is per tx, so if you have two payment ids, you have to make two txes at least. Just make the payout limit higher for people with a payment id.

Maybe that's what you are looking for.


Please Help! -- GUI wallet Daemon failed to start and can't find log or monerod

monerod.exe is not applicable, it is a Windows program.   You can find monerod inside the monero GUI app folder. It would be located here normally: /Applications/monero-wallet-gui.app/Contents/MacOS/monerod.  The GUI would be in the same folder.

It sounds like you are still very new to all of this, so you might consider connecting to someone else's remote monero node initially, then setup your own full node once you have more experience.


Compile any miner into assembly for WebAssembly

i havent seen it implimented in this way anywhere else. there is jsecoin that is emerging with similar setup.
i am no programmer but have been looking at exactly the same thing since discovering coin hive. i think a web page that enables people to use a simple miner like xmr stak cpu would be a great way to get people introduced to monero etc. i would like to set up a page that points to a pool i use instead of coinhive.


Blockchain syncing and transactions verification

Unless you had --fast-block-sync 0 as a command-line flag, it should've already been skipping both POW checks and ring signature checks. With the transaction rates we've had in much of the coin's history, checking POW actually takes longer than signatures.

You might also try bumping --db-sync-mode arg (=fast:async:1000) to something higher (10000?), and possibly switching to "fastest". --db-sync-mode fastest:async:10000 Note that there have been some corruptions on fastest (can happen if sync is interrupted).


Can one reduce the monero pruned blockchain further below 25gb?

Technically, it is possible to decrease the size further.

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

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


How can I delete the last X blocks from my local copy of the blockchain and retrieve them again from the network?

monero-blockchain-import --pop-blocks n

Where n is the number of blocks you want to remove from the end of the blockchain.


What causes transactions to exit the Memory Pool?

Usually, a timeout, if the transaction could not find its way in a block within a day (the timeout is seven days if the transaction was added in a block which was reorganized away). Why the transaction can't get in a block is another matter, but typically this can be due to a double spend, fee too low, or violating the minimum mixin rules, among others.

Another possibility is if the transaction was manually flushed (ie, either remove the poolstate.bin file and restart the daemon, or use the flush_txpool command in the daemon). In those two cases, the transaction is likely to be received again from peers as they rebroadcast.


When asking for help about a particular error, it is a good idea to include that message. After all, we're not omniscient.

Your blockchain is probably corrupted, which will require a sync from scratch. This does not risk your monero being lost, though. Once you've synced again, your wallet will see your monero just fine.

monerod uses a faster, but more risky sync mode when downloading the chain. It usually works fine, but is prone to this sort of corruption when the OS/computer crashes. If your computer often does this sort of thing and you can't change the OS (or hardware if it's a hardware fault), you can force a safer sync mode (though it may be a lot slower):

monerod --db-sync-mode safe:async:1000

Once the initial sync is complete, monerod will automatically switch to this safer mode, as database speed is less of an issue then.


Can I accept payment to my local wallet?

Yes, of course.

  Do I have to leave my pc open all day long to accept the payments or it will synch when i get login?

Transactions are stored on the blockchain, your Monero wallet is not needed for them to work. You only need it to check your balance and perform transactions yourself.

  Are there any transaction fees when I am using my local wallet?

No, transaction fees are paid by the sender.

  What information do I have to ask from the buyer to confirm the payment?

You should provide the buyer with a Payment ID that lets you identify the transaction.


Not receiving stagenet XMR to cli-wallet

Your transaction is apparently in stagenet block at height 565903, but the daemon you are using appears to be stuck back on height 558151 (at time of writing). Thus you need to use a daemon that is up-to-date.

Seeing as you are using the xmr.to explorer and faucet, perhaps use their stagenet daemon too: https://community.xmr.to/nodes.html.

E.g.

./monero-wallet-cli --daemon-address node.xmr.to:38081 --stagenet \
    --wallet-file example_stagenet_wallet


Recovering monero wallet files on drive that was previously dualbooting Windows and linux. Now I only run linux

I've done that before (Win10 to Mint18).

It's as simple as copying the two wallet files (<Wallet name> without extension and <Wallet name>.keys) from Windows' Monero folder to Linux's Monero directory, start GUI/CLI wallet client on Linux, and enter your wallet password. The Linux executable is happy with wallet files generated by Windows executable. I believe the files will also work across architectures (x86/x64/ARM) but I have only tried x64 to x64.

As long as you still have access to your Windows partition (and the files therein), these steps should bring your wallet back with all funds intact. If your Windows partition is intact but you can't access it, consult your Linux distribution's documentation and/or head to Unix.SE.

If, however, your Windows partition is gone and you don't have the wallet files nor your mnemonic seed, your Monero are unfortunately lost. Take it as a lesson learnt and have proper backups in the future.


This was discussed in the dev meeting held on 2016-08-28:

  fluffypony: NoodleDoodle: do you want to talk about Trezor at all?

  NoodleDoodle: Sure :P

  fluffypony: yay, take it away

  NoodleDoodle: I'm about 1296 behind in commits. Rebasing is pretty much out of the question. Have to manually merge then release.

  fluffypony: NoodleDoodle: do you want any help with that?

  NoodleDoodle: The trezor firmware itself should be easier, except it's split into 5 or 6 repos

  fluffypony: ok cool

  NoodleDoodle: I should be able to do it.

  fluffypony: NoodleDoodle: do you want us to host it on the monero-project Github in its own repo, obvs giving you collab access, to make it more "formal" and part of the core project?

  NoodleDoodle: Sure, anything. I actually started on keepkey awhile back as well, although it's not as complete as trezor.

  fluffypony: ok cool

  fluffypony: I've been fiddling with Ledger Blue, as I have the Blue and the Nano S

  fluffypony: I have a feeling they'll be a cinch after Trezor / Keepkey

  fluffypony: and, hopefully, we can PR it in to be part of the default firmware on these devices

  fluffypony: if they'll have us


What is Monero's mechanism for defending against a double-spend attack?

Double spends are prevented by the use of key images, which are sent along with each output being spent in a transaction, and which are checked for uniqueness before allowing the transaction.

In the Cryptonote protocol, an output's private key can be used to uniquely generate a key image in such a way that a miner can check a purported key image really is correct. When spending an output, its key image is calculated by the sender, and included in the transaction. Miners then check these key images are real, and check whether they were already seen in the blockchain. If they were, it means the output being spent was already spent in a previous transaction, which is then discarded.

Since a miner can verify a purported key image, but not create one without the private key (similar to a cryptographic signature), only the owner of the output may spend it - just once.

The set of key images must then be kept for lookup by miners and other nodes. This is the "unbounded TXO set" that is often mentioned as a cons of using Monero/Cryptonote. Each key image is 32 bytes long.

Once RingCT is enabled, this system will not change, as RingCT includes that system as well. However, since transactions will not have to split amounts anymore, that TXO set growth will substantially decrease.

UPDATE: RingCT is now enabled.  You can read more about it here: What is RingCT and how does it make Monero private?


First, not all shares are of equal value. A share with a difficulty of 25000 is worth more that a share with a difficulty of 250.
Second, it's worth understanding that difficulty (in PoW terms) is harder the lower the number, but in pools, will often be termed the other way round. I.e. they refer to the same thing but flipped around. With PoW you are trying to find a number smaller than another number. For example, with 0 being the hardest and 10 being the easiest, if you have a difficulty of 3, you are trying to find a number smaller than 3 (so 0, 1 or 2). With a difficulty of 3 (smallest hardest), you can flip that around to say greater than 7, and this is what you'll see with pools when referring to share difficulty. As 7 increases, the work is harder (and worth more), because you're ultimately trying to find a number smaller than max minus difficulty.
The hash function is just giving you a random number between 0 and 2^256-1. In the example above with 0 being hardest and 10 being easiest, that would be equivalent to a hash function returning a random number between 0 and 9.

Do I need to finish 25000 times of hash computing in a limited time to get a valid share?

No, you do not need to hash 25000 times to solve a job with a difficulty (in pool terms) of 25000. You need to find a valid hash* within a certain amount of time. The pool will send you work based on how quickly you solved previous work so you end up submitting work at an approximate rate, typically ~30 seconds per job.
*Note that 25000 is only the top 32 bits of the actual difficulty number. See this answer which explains further.

Is there a possibility that I just need to finish parts of the 25000 to get a valid share? In extreme cases, do I only need to calculate one hash to get a valid share?

You will on average find a valid hash (number) within the timeframe the pool targeted your job difficulty for. Sometimes it will take you longer, others less; extremes included.


What's the maximum amount of transactions returned by the get_transfer RPC method?

As per the documentation you linked to, you can filter by min_height/max_height and account_index/subaddr_indices, not timestamp. As Monero blocks are mined roughly every 2 minutes, you can use heights as an approximation of time.

There is no restriction imposed as to the amount of transactions returned other than by the filter options.


Subadderess transaction. How to receive?

To my knowledge, none of the current pool software supports subaddresses. Your best bet is to reach out to the pool operators and give them your standard address so they can update the pools database.


You can sell for USD on Bitfinex or on bitsquare.io


How can monero remain private in a soon to be virtual reality world?

Wow, that is a phenomenal question, and I'm sure others will chime in as well.  It's a difficult question to attack since crypto-related legislation is evolving at an increasing pace.

However, the first thing that comes to mind is if biometric scanning were to ever become a requirement for accessing certain forms of VR. As far as I am aware that is not yet a requirement, but if it ever comes to be then the only advice I could offer at this point would be to steer clear of those particular services. This is why some forms of crypto ATM's are immediately discounted by Monero community members, and I see the same attitude carrying over to any other theoretical implantation of such identification methods.

Additionally, if future services employ a know your customer (KYC) approach to identifying users, then that too would be up to each user's level of comfort. A relevant case would be the crypto exchange Poloniex's sudden statement last year, requiring that all customers provide several tiers of personal information, thus cutting off their fund withdrawal ability to whatever tier they had reached (I believe the first was to provide just a first and last name, which could conceivably be faked). Should this come up in the future, again, this would depend on each unique user's preferences, but it may still be possible to use a false alias and retain access to the service as is possible with Poloniex's first layer of identification.

This is just what's popped into my mind, and I'd be delighted of others had additional input.


Building a service to hold Monero private keys. I need to update user's balance every 1-3 hours

The only way I can see to speed this up is to write some code that does parallel crypto ops at a lowish level, roughly where the calls to is_out_to_acc_precomp are made. You can then save all the tx processing, and you then compute the crypto part for N keys rather than one. You can also early out when one key finds a match, since other keys won't find a match for the same output. Doing it this way allows you to have a very parallel run of many times the same small amount of crypto code, which you can offload to a GPU, as those are pretty good at that type of workload.


Is there a way to send unconfirmed transactions and get them accepted by the network? Something like in bitcoin, where if you send a transaction that is using unconfirmed inputs, the outputs will only be confirmed when the inputs are?

No. Monero does not support chained payments within the same block. Outputs must be available before they can be spent. Because of how ring signatures work, Monero is not easily comparable to Bitcoin in this regard.

  If not, could you tell me what's the best way to speed up the time it takes to have the newly received funds ready to be sent?

You cannot speed up confirmation time unless you have access to a huge amount of hashing power which you can activate on demand to (temporarily) speed up block discovery until the network difficulty adjusts.

A better solution would be to have a Monero wallet that has a balance that is always available to you. In that case you can spend that amount of Monero at any time without needing to wait for incoming transactions to be confirmed first. If the incoming transaction is from a third party keep in mind the security implications of accepting transactions that have not yet been accepted by the network.

  Would using the lowest possible mixin value have an influence?

No.

  Lastly, what is Monero's confirmation time? It is in blocks, right?

Yes. Each block is approximately 2 minutes apart (on average) but incoming transactions require 10 blocks before the funds can be spent, regardless of how long those ten blocks take.


How do I handle "WARNING: You may not have a high enough lockable memory limit, see ulimit -l"?

I have 131072 kB and don't get any locking issues here. It may be much more than needed.
If you don't know what to do, I suggest trying twice what you have now, and see if that fixes the warning. If not, double again, etc. The more unswappable memory you have, the less leeway your OS has in choosing what to swap out when more memory is needed. If you do this in a particular shell, I think the change only applies to that shell and its children (or that's what the man page claims, but you probably saw that already).


Received monero, how many confirmations do I need to wait before fully confirmed?

Seeing as you mixed two concepts in your question, receiving and full confirmation...

Just like practically every other cryptocurrency, two things happen when you send money: 1) the transaction gets broadcast and placed in a transaction pool. Your wallet sees (receives) this almost straight away, but it is locked until 2) it is mined in a block and then N subsequent blocks have been mined afterwards. In Monero's case, wallets keep the funds locked for N=10 blocks (which is roughly 20 minutes).

Cryptocurrencies do this locking / confirmation wait because of a few reasons, mostly to avoid double spends (whether intentional or accidental), but also because of the possibility of orphaned blocks.

With this knowledge,

  Why do we need to wait for such a long time when receiving monero?

You don't. Your wallet receives / sees the transaction almost instantly.

  I thought it was 2 minutes only, but it seems that is not the case and I have to wait still a good 5+ minutes for a transaction to confirm.

You thought wrong. For the transaction to be fully confirmed (unlocked) by your wallet, it takes 10 blocks (roughly 20 minutes). For comparison, Bitcoin aims for a 10 minute confirmation / unlock time.

Lastly, it's worth noting, there is nothing at the consensus level enforcing an N blocks lock time. The wallets / merchants implement this. Some wallets / merchants accept a lower block confirmation (even zero in some cases), but that's a risk they are willing to take (a risk they never get to use the funds because of a double spend for example).

UPDATE (for v0.15+)

The 10 block lock time is now enforced by the protocol (consensus). Therefore it is now only possible to spend funds with at least 10 blocks of age.


Linux beta binaries are built on Ubuntu 16.04. No sure which GCC version Fluffypony used but the downloadable bins on buildserver are built with GCC 5.4.0. Until next release we will try to complete a fully static linux build or at least bins targeted for other distros.


Why isn't communication between wallet and daemon encrypted?

I'm not qualified to answer this but I'll provide this in answer in the hopes that someone more qualified will step in. There is no reason why you shouldn't connect to a remote node, but any node you connect to (local or remote) should be your own, because you can trust your own nodes. In any case, if the node you are going to connect to is remote, you should encrypt communication from the wallet to it with a tunnel. Once zeromq communication has been implemented, tunneling will no longer be necessary since the communication will be encrypted automatically by zeromq.


Why limit the CRC by a modulo of 24 rather than 1626?

Why was the choice made to reduce CRC32's effect...?

Well it doesn't actually reduce the intended effect in this use-case. It's purpose is to quickly detect if a wrong set of words was entered, nothing more.

Also, as @user36303 commented above regarding cryptosteel, a nice side effect is you can reduce the seed words from 25 to 24 words by simply writing the word that happens to also be the checksum upside-down.


Monero has a "smooth" emission. This means the block reward decreases gradually until it hits 0.3 XMR per minute. Subsequently, the tail emission kicks in and the block reward will remain 0.3 XMR per minute indefinitely. This will occur in approximately 2023. Note that the tail emission is not inherent to CryptoNote, but was specifically implemented in Monero.

In the CryptoNote whitepaper the emission is described as follows:

  6.1 Smooth emission

  The upper bound for the overall amount of CryptoNote digital coins is:

  MSupply = 2^64 − 1 atomic units.

  This is a natural restriction based only on implementation limits, not on intuition such as “N coins ought to be enough for anybody”. To ensure the smoothness of the emission process we use the following formula for block
  rewards:

  BaseReward = (MSupply − A) >> 18

  Where A is amount of previously generated coins.


How does Monero verify a tx outputs key image?

Intuitively:
You are spending an output P, where P=xG. You spend an output by providing a signature proving you know the private key x corresponding to the public key P.
If you also declare the key image I=xHp(P) as part of the transaction, you are declaring a public key I with private key x.
You are correct that in isolation, transaction verifiers cannot know you have declared the correct key image.
However, when you provide your signature proving you know x for P, you extend the signature to simultaneously prove you know x for I, in a way such that mathematically, the combined proof would only verify if both values of x were the same.
Thus, you have proven that the key image was calculated using the same private key x that applied to the output one-time public key.
You can't use just any value of Hp(P), since the verifier calculates that themselves based on the P you are spending, and uses that calculated value to verify the signature.
For the math, see page 30 of Zero to Monero


Can the same input appear in a block multiple times?


What is the block maturity value seen in many pool interfaces?

It seems like a certain number of steps or confirmations needed when a block is found by a pool (I guess it's the same when mining solo), but I can't be sure.

This is exactly right. When a block is mined, it cannot be spent until 60 blocks after it has been mined (with a 2 minute block time, this means roughly 2 hours). The same applies when solo mining. When mining solo, the block reward will show up right away in your wallet, but it won't be in the "unlocked" portion of your balance until 60 more blocks have been mined.


What keys are being used to create the key image and how is it verified?

I = xH_p(P) which secret and public keys are being used here?

x and P are the one-time output private and public keys, respectively.

  To my understanding it have to be the one-time public and secret keys of the transaction addressed to you

There is a transaction public and private key, but this is only related to addressing inputs to particular wallets and allowing the recipient to calculate the correct private and public keys for the outputs destined for them. Ring signatures are purely about proving that the private keys of particular outputs are known.

  how is the key image verified?

  All if found is that it's checked if this key image has been used
  before, but not if it's actually valid. Is the verification part of
  the signature check as whole and is not explicitly checked?

The cryptonote white paper does a good job of putting this into English:

  The meaning of the protocol: by applying L-transformations the signer
  proves that he knows such x that at least one Pi = xG. To make this
  proof non-repeatable we introduce the key image as I = xHp(P). The
  signer uses the same coefficients (ri , ci) to prove almost the same
  statement: he knows such x that at least one Hp(Pi) = I · x^−1

  The signer cannot make two signatures with different I’s and the same x

In other words, the key image could not have just been some random made-up key image, because the verification of the ring signature mathematically proves that for one of the outputs in each ring, the key image the spender declared was calculated as xHp(P), where that x is the same x that the ring signature also proves must have been the secret key of one of the outputs being spent.

Perhaps the simplest way to state this is: Monero uses linkable ring signatures, which is a way of proving that for one particular unidentifiable public key in a set, the corresponding private key is known and that the corresponding key image has been correctly declared.


Is there a step by step tutorial on how to compile from source for Monero cli on ubuntu 16?

This is what I did on a ubuntu 16.04.
Dependencies
First I installed all the dependencies show here

sudo apt-get install libssl-dev build-essential cmake pkg-config libboost-all-dev libzmq3-dev libunbound-dev libsodium-dev

And build this dependency manually.

sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make && sudo mv libg* /usr/lib/

Source Code
Next get the source code via git.

git clone --recursive https://github.com/monero-project/monero

If git is not found install it via

sudo apt-get install git

Than go into the monero folder and build it via:

cd monero
make

On a oDroid c2 mini pc this took about 8-10 hours.
For me the tests fail in the end but the executables were in
monero/build/release/bin

All this information can be found in the readme from the monero repository here


Monero is built on Cryptonote, which uses ring signatures (which it created in the context of cryptocurrencies) and stealth addresses. ShadowCash is built on Bitcoin, and reimplemented ring signatures (in a way that broke anonymity, see https://shnoe.wordpress.com/2016/02/11/de-anonymizing-shadowcash-and-oz-coin/). I have seen claims that they have stealth addresses, however you can see an address' balance, so it seems contradictory. That's also a difference with Monero, where you can't tell an address' balance.

Monero uses a single token. ShadowCash uses two, an anonymous one and a non-anonymous one, and can transfer between the two. This causes the anonymity set to be a fraction of what it'd otherwise be.

Monero has by all accounts had a fair launch. ShadowCash is said to have a very skewed distribution (though probably less bad than the winners of such schemes, Dash and Bytecoin).

Monero is PoW. ShadowCash is PoS (after a short period of PoW). This probably explains the previous point in large part.


Where is the global array of outputs of type txout_to_key?

When you read in the blockchain from scratch, your daemon will start building a table of each output encountered in chronological order. Prior to RingCT, outputs had cleartext amounts. RingCT outputs have the amount '0' assigned to them. Outputs are looked up by both their amount and offset. This means that an output with amount 0 at the 3rd offset would be the 3rd ever output observed which had an amount 0.

Therefore, if you want to look up a key_offset, you need to query your daemon's database. You can make an RPC call to do this, using the "get_outs" method.


How many languages will the official GUI support?

7 mnemonic seed languages will be available for the GUI:

  +List of available languages for your wallet's seed:
    +0 : English
    +1 : Spanish
    +2 : German
    +3 : Italian
    +4 : Portuguese
    +5 : Russian
    +6 : Japanese

11 wallet "locales" are supported with 5 different languages:

+        <language display_name="US English" locale="en_US" wallet_language="English" flag="/lang/flags/usa.png" qs="none"/>
+        <language display_name="UK English" locale="en_GB" wallet_language="English" flag="/lang/flags/uk.png" qs="none"/>
+        <language display_name="Russia"     locale="ru_RU" wallet_language="Russian" flag="/lang/flags/russia.png" qs="none"/>
+        <language display_name="RPA"        locale="en_SA" wallet_language="English" flag="/lang/flags/rpa.png" qs="none"/>
+        <language display_name="Palestine"  locale="ar_PS" wallet_language="English" flag="/lang/flags/palestine.png" qs="none"/>
+        <language display_name="India"      locale="hi_IN" wallet_language="English" flag="/lang/flags/india.png" qs="none"/>
+        <language display_name="Italy"      locale="it_IT" wallet_language="Italian" flag="/lang/flags/italy.png" qs="none"/>
+        <language display_name="German"     locale="de_DE" wallet_language="German"  flag="/lang/flags/german.png" qs="none"/>
+        <language display_name="China"      locale="zh_CN" wallet_language="English" flag="/lang/flags/china.png" qs="none"/>
+        <language display_name="Brazil"     locale="pt_BR" wallet_language="Portuguese" flag="/lang/flags/brazil.png" qs="none"/>
+        <language display_name="Bangladesh" locale="en_US" wallet_language="English" flag="/lang/flags/bangladesh.png" qs="none"/>

Translations will be automatic with the support of QML which relies on the internationalization capabilities provided by Qt on which the new Monero GUI is being built.


What does the "default" priority (priority = 0) do in monero-wallet-cli?

With priority set to 0, what does that actually mean in practice?

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

With priority set to 0 it will use the default fee multiplier, which is x4. In addition, the fee priority level is static, i.e., it won't change automatically if the mempoool grows and users have to set it manually. Transaction using the default priority will give miners sufficient incentive to raise the blocksize limit.  By contrast, if everyone would use the lowest priority (x1), miners wouldn't have sufficient incentive to raise the blocksize limit and the mempool would, most likely, become clogged.

  why not have the options as priority [1|2|3|4] - unimportant/normal/elevated/priority fee, with the default setting as 2?

The current implementation was probably designed for convenience. That is, after manually changing the fee priority level, it is probably more convenient to switch back to the default level, as it implies the standard / default setting recommended. By contrast, the term "normal" might be less efficient in conveying this.

More information about fee multipliers and the adaptive blocksize algorithm can be found here.


How to create wallets using monero-wallet-rpc?

Yes you can do this. First make sure you start the wallet RPC with a wallet dir that exists and is writeable. Next you can make use of the methods create_wallet, open_wallet and close_wallet. All the methods are documented here: https://www.getmonero.org/resources/developer-guides/wallet-rpc.html

I don't recall if you are required to start the RPC with an existing wallet, but if you are, just create an empty wallet to use for starting up the wallet RPC with.


Can't find the .bitmonero directory to set up the blockchain.raw file in Ubuntu 17.10?

You can put this file anywhere, you just need to add --input-file XX and put the file and its path instead of XX, eg:

monero-blockchain-import --input-file $HOME/blockchain.raw

As for  "monero-blockchain-import doesn't exist" errors, this is unrelated, and just means monero-blockchain-import is not in your PATH environment variable. Either add its directory to your PATH, or give the whole path to it (either relative or absolute), eg:

./monero-blockchain-import --input-file $HOME/blockchain.raw

if it's in the current directory, or maybe:

build/release/bin/monero-blockchain-import --input-file $HOME/blockchain.raw

if you've just built it.


So the transaction splitting function is not an anonymity thing, it's due to the dynamic block size limiter. Right now testnet is on the block median, and you're trying to create a transaction that is much larger than that block limit. So it tries to split the transaction up into several that fit into the block limit, but if it needs to create thousands of transactions to do that it would chew up your computer for ages, so it eventually wipes out. You would either have to wait until the block median is higher (unlikely any time soon on testnet) or you'd have to send it in smaller chunks:)


Where is the Monero blockchain stored on Linux build?

The blockchain is stored in $HOME/.bitmonero

For testnet, it'll be in $HOME/.bitmonero/testnet

You can select a different directory with the --data-dir option if needed, eg:

./monerod --data-dir /var/tmp/monero


It is my understanding that the NVidia P106 (if this is what you mean) are GTX without the display port. If I am correct, you should be able to use any NVidia compatible mining application based on your OS. CCMINER should do admirably.

Feel free to give a test on my Monero Pool and if I'm around I'll try and help via the chatbox.

Gulf Coast Mining
https://mon.gulfcoastmining.com


Various scammers have operated under the name "Bitcoin Fog" (and many domains) for years.

They most likely stole your money:
https://www.reddit.com/r/BitcoinFog/

Generally speaking, there should not be a away to accidentally add a Monero address where a Bitcoin address is expected.  It is technically possible of course, but hard to imagine any website being that terribly programmed.  If they are that bad at making websites, then they definitely should not be trusted to handle cryptocurrency anyway.


What is the cause of this "std::runtime_error"?

According to developer hyc the error is cause my not specifying a file name and can be resolves in the following manner:

  "Use an actual filename for --output-file, not a directory name."


How do I upgrade my software to v0.11.1.0?

CLI:

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

Download the new binaries from here.
Extract the new binaries to a new directory of your liking.
Copy over the wallet files from the old directory (the one that contains the v0.11.0.0 binaries).

Note that a blockchain resync is not needed. If you open monerod-v.0.11.1.0 it simply picks up where it left off.

GUI:

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

Download the new binaries from here.
Extract the new binaries to a new directory of your liking.
Open monero-wallet-gui^1. It should automatically load your "old" wallet.

(1) On Linux you ought to start the GUI with the start-gui.sh script.


A "node" is the monerod daemon. It can support arbitrarily many wallets connecting to it concurrently. A wallet generally supports only one user at a time.


How does the wallet scan for outputs belonging to it?

As far as I can tell from the code, the option 1 seems to be the case. Most of the core functions of the wallet are implemented in src/wallet/wallet2.cpp. In pull_blocks which is called from within refresh, the wallet fetches individual blocks in its entirety. Subsequent to that function is process_blocks which then calls process_new_blockchain_entry which then calls process_new_transaction. In that function, the wallet generates the key derivation (i.e. the shared secret aR) which is passed to check_acc_out_precomp to test if each output in the given transaction belongs to the wallet. The actual test is performed by cryptonote::is_out_to_acc_precomp defined in src/cryptonote_core/cryptonote_format_utils.cpp.

The option 2 seems to be a natural approach for implementing light wallets and I guess it's quite feasible; I'm curious what the core devs have to say :)


Missing monero sent from one GUI wallet to another

"This address received xx.xx monero, but the transaction is not yet mined" means that the transaction is seen by the Monero network, but has not been mined yet. Miners select transactions based on the highest fee per byte, to maximize their income. If your transaction has a fee that's a bit on the low side and there is a continuous stream of incoming transactions with a higher (even by a little) fee per byte ratio, those other transactions will be selected and mined first. Your transaction will be mined when there are no more other transactions with a higher fee per byte than yours (or not enough to prevent yours from being included in a block).

Alternatively, your transaction is invalid (for instance, it tries to double spend one or more of its inputs), but that is less likely. If this is the case, the transaction will disappear from the network after 24 hours and the monero will reappear in the sender's wallet (though the double spent inputs are really spent, so the real balance will be smaller as the original was incorrect).


I sent XMR from wallet 1 to wallet 2 and it says 0 coins

Ok so what i did was completely delete the log and did a full restore wallet and let it fully resynchronized and the funds show now.


What is the speed difference between CryptoNote Easy Miner and Monero Spelunker?

Monero spelunker is just a GUI wrapper for Wolf's cpu miner. It looks like the easy miner one also generates a wallet and mines to that address, where as for spelunker you have to generate your own wallet. It also appears that easy miner comes bundled with very old simplewallet binaries, so you probably don't want to generate your wallet that way. It's not clear if the miner bundled with easy miner uses aes (wolf version) or not (lucasjones version), but spelunker is bundled with wolf version, so if you have aes that might make spelunker significantly faster.


Total and fee calculation seems to happen here:

// give user total and fee, and prompt to confirm
uint64_t total_fee = 0, total_unmixable = 0;
for (size_t n = 0; n < ptx_vector.size(); ++n)
{
  total_fee += ptx_vector[n].fee;
  for (const auto &vin: ptx_vector[n].tx.vin)
  {
    if (vin.type() == typeid(txin_to_key))
      total_unmixable += boost::get<txin_to_key>(vin).amount;
  }
}

Printing happens a few lines later:

prompt_str = (boost::format(tr("Sweeping %s for a total fee of %s.  Is this okay?  (Y/Yes/N/No)")) %
    print_money(total_unmixable) %
    print_money(total_fee)).str();

Since the correct amount of Monero was actually swept and transacted, the bug is most likely somewhere in the printing, though I'm not seeing anything obvious.

Edit: This is an open issue on github


Where can I find examples of txout_to_script and tx_out_to_scripthash Transactions?

Nowhere. These are not implemented, and will be rejected by the network.


How many destinations can there be for a single transaction?

There is no hard coded limit to the quantity of destinations in a single transaction. However, there is an overall transaction weight limit, which is roughly half the block weight. Therefore, if you tried to pack in an unusually high quantity of inputs / outputs, you could end up with a transaction that exceeds the maximum allowed tx weight limit and thus gets rejected.

So:

  Can I transfer to as many addresses as I'd like in a given transaction?

No.

  Is there a technical upper bound?

Yes. The transaction cannot exceed its overall weight limit, which is half the penalty-free block weight.

  is there a reason why the upper bound was chosen?

Presumably to prevent spam attacks.

  Is it a "consensus" limit or just a software default?

It's consensus level.

  If there is a limit, was there always a limit?

There has always been a limit to the maximum tx weight. Prior to HF version 8, this limit was the set to the penalty-free block weight. Since version 8, it's half the penalty-free block weight.

UPDATE

Since bulletproofs, there is also a maximum of 16 outputs per transaction.


What contributions (if any) are there to the overall blockchain size, other than the actual transaction sizes?

The main factor is the number of signatures included in a transaction. With Bitcoin you only have 1 signature per input, whereas with Monero you have N number of signatures (depending on your choice for that transaction) per input. There should be little else that affects the blockchain size as directly as that.


Moving monero from Poloniex or Bittrex to a paper wallet

Yes, that would work. Just make sure you don't lose the seed for your paper wallet.


Is running a full node on an HDD bad for the network?

No.

In any case, internet connection bandwidth and access is far more impactful to the network.

Using a spinning disk, it's just you who will feel the pain during your initial full sync. Once you have got the blockchain on your spinning disk however, there is really no issue keeping it synced up, so long as you keep it running.


Does using MyMonero online wallet and sending it to yourself (churning) help increase privacy?

Leaving aside MyMonero online wallets, the benefits or churning are debatable. There are really only a couple of very specific cases where churning can be beneficial (such as breaking the linkage between specific tx outputs, i.e. seep_single, [ref]), but naively just churning all the time, in most cases actually just reduces privacy [ref]. The best advice is to just use Monero normally, as intended.

  I hear people say churning is good for the network.

This is nonsense that was peddled by one specific group of people. The benefit to the network is soo small it's utterly insignificant.

  But online wallets do sacrifice some privacy for convenience.

This has nothing to do with churning. Online wallets have numerous downsides, none specific to "churning".

  MyMonero has users' public addresses and view keys. Does churning do anything then?

Again, not specific to churning, but you are taking huge heavy privacy and security risks using online wallets disclosing any information to them. The moment you are trusting some service with your wallet view key, wallet address and your IP address, you've already obliterated a huge amount of your privacy. Thus whether you churn or not at this stage is largely irrelevant.


What would we call Monero users in Esperanto?

The 'j' at the end is for the plural, so a single user should be a "monerano,"  I think.  I've just picked up a little Esperanto in recent weeks.

Thanks to

https://www.reddit.com/user/lethos3


I want to view addresses that I've sent payments to in the past?

The set of historical destination addresses is not something that can be obtained from the blockchain, so the only place it is is in your wallet cache. If you clear it, then this info is lost forever. Whether you remove the cache file or restore from seed or run a rescan_bc, it's gone.


What does this ERROR from the daemon mean?

This happens when the data inside a ringct transaction is invalid in a certain way. For instance, an previous version of ringct had the same layout, but used the data in it differently, with different assumptions, checked there, so a tx made with a wallet from that version would trigger this.

It is possibly doable to have more in depth preliminary checking, but it is unclear whether it'd require redoing part of the rct code in the preliminary check code.

Unless your daemon stops syncing, this is ignorable.


How can I verify the Monero coin supply without using a block explorer?

Starting with v0.10.1, there is now a command print_coinbase_tx_sum that give you this information.


Is there a monero address monitoring service?

There is none so far. You'd need to give it also your private view key, and it would have to spend some CPU resources to keep scanning. I assume that's one of the reasons nobody created such service.


How the sender recover the transactions that he spent?

The user can recover the dates and amounts of the transactions they have made, but not the destination wallet addresses of any of those transactions or any encrypted payment id. They would be able to see any old style 256-bit payment id, because those old style transaction ids are not encrypted on the blockchain. The new style 64 bit payment ids (as used in integrated addresses) would be encrypted.

The spent outputs can be discovered because the user can use their private spend key to determine the 'key images' of all of their received outputs. Key images are published with every transaction, so they can scan the blockchain to determine which of their outputs have been spent. Therefore they can subtract the amount of that spent output from their wallet balance. They know the amount of that output for the same reason they knew it when they first received it. That reason is that it's communicated to them in the ecdhInfo part of the transaction, and encrypted using the transaction shared secret so that only they can decrypt it using their private view key.

The outgoing transaction payment ids cannot be recovered because they would have been encrypted with the transaction shared secret. As the sender, they would have needed to retain the transaction private key to know the transaction shared secret.

In algebra, the sender knows the shared secret as Hs(rA), and the recipient knows the same shared secret as Hs(aR). This is why the sender cannot recover the shared secret later. The sender would have needed to know both the transaction private key r and the recipient's public view key A in order to recover the transaction shared secret.


monero was not received into my MyMonero wallet

Actually many people are having the same problem at Cryptopia while trying to withdraw their XMR, and there are people actuallly waiting for 9 days! Just keep away from them until the exchange resolves the issue.


The Cryptonight description by the Cryptonote team states that

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

In the primitive family Keccak, b is the width of bit block of the permutation function.

  Given an input bit string N, a padding function pad, a permutation
  function f that operates on bit blocks of width b, a rate r and an
  output length d, we have capacity c = b − r and the sponge
  construction Z = spongef,pad,r, yielding a bit string Z of
  length d, works as follows

This value of b is also used by SHA-3 for instance.

EDIT

Regarding your question about the location of the value 1600 in the code:

Function keccak1600 is defined as a special case of function keccak with parameter mdlen equal to the size in bits of the type state_t. This type is an array of 25 uint64_t so the total size is 25*64=1600.


Throttling/Adjusting Bandwidth in Conjunction with Bitmonerod

All of these are measured in kB (1024 bytes). See src/p2p/net_node.inl, in set_rate_up_limit.

The defaults are 2048 kB/s upload, and 8192 kB/s download. If those are near or above your connection's capabilities, you may want to lower them to a bit lower, to keep some QoS. Similarly if you have a fast connection, you might want to increase them.


How to create a 12 word brain wallet seed that is compatible with monero-wallet-cli?

I understand you want to generate a truly random seed and memorize it, which is good as this would avoid the inherent weakness in human brain's capability to produce randomness.

  I know there is https://xmr.llcoins.net/addresstests.html and
  https://moneroaddress.org/ but are these good enough rng for creating
  seed?

Probably yes. See here for some details on how the RNG used works.

  I hear you could do roll a 6 sided dice 100 times for good randomness,
  but how would that translate into a seed?

If you want to use dice rolls, you could use this generator, which is a modded version of moneroaddress.org and gives you the option to use dice rolls practically directly as the seed. Details on how it works can be found here. It's reversible, so in theory it's possible to calculate which dice rolls would give a certain seed. Essentially it's just converting between base6 and base16 number representations. Considering it's hosted at a simple site with no https, if you're going to use it, better check the signature or get it straight from github.

The original one could be used but you'd enter dice rolls in the custom entropy field. I think the way it works is that it hashes whatever is inputted there with some rounds of Keccak hash function and uses the result as seed. You could enter anything you want in the custom entropy field. As long as the input has enough entropy, it should be ok.

Now, the result of either of above would be a 256-bit seed, resulting in a 25-word mnemonic. In lieu of a better solution, you could take the first (or last, or middle, or randomly picked) 128-bits of your resulting seed and feed them here to generate the mnemonic, keys and address. I'd still use 256-bits of entropy to generate it though, just in case.

  lastly how would you restore that 12 word seed in monero-wallet-cli?
  thanks a lot

To restore, you could always start your wallet like this monero-wallet-cli --generate-from-keys <filename> and you will be prompted for address, keys and password. If you know the block height when it was created, you could speed up the initial sync by starting it with additional --restore-height <height> argument. Need to be sure of the correct  because if you had anything sent to the wallet before the  it will not show it.


Understanding MLSAG in Monero transaction

Page 11 in that paper is still only concerned with the general ring signature case, not particularly focused on the Pedersen Commitment part.

The MGs field corresponds to the struct mgSig in src/ringct/rctTypes.h:

typedef std::vector<key> keyV; //vector of keys
typedef std::vector<keyV> keyM; //matrix of keys (indexed by column first)
struct mgSig {
    keyM ss;
    key cc;
    keyV II;
};

In this case, ss is a matrix of 2 rows and 5 columns, and two entries in each j-th column are (P_j, C_j - \sum_{i} C_{i,out}). II corresponds to the key images.

To answer your question 2., yes, we do need two secret keys x and z, for the output public key P_s = x*G and its corresponding commitment part C_s - \sum_{i} C_{i,out} = z*G, respectively. We don't need the second key image corresponding to z, because the output public key P and its commitment C are always coupled, so double spend checking using just one key image suffices.


Hash rate of three million mining Monero?

"Is this article truthful when it quotes a hash rate of three million when mining Monero?"
Answer: No. If the hashrate was 3 million, then everyone who was mining Bitcoin must've moved for no reason.
"If so, what is the way to learn and apply the RandomX algorithm in FPGA hardware? What knowledge is required?"
Answer: It is not possible to apply the RandomX Algorithm to FGPA hardware (Currently).


Does Monero protect against timing analysis?

This is somewhat related to the Temporal Associations, described in MRL4 here, and temporal alignment, described in this SE question.

To specifically answer your questions:

  However, if UserA broadcasts that TX at 8:00PM, is there any record of that?

The broadcast of the transaction isn't stored in the blockchain, but its time of inclusion into the blockchain is (the timestamp of the block). However, someone sniffing the network could record the time of all transaction broadcasts.

  Assuming there is a record, and assuming the analyst sees it is currently 8:01PM, could analysts determine that the most recently created output has a high(er) probability that UserA was the authentic sender?

Theoretically, yes. However, this is only problematic under the following circumstances. 1- you just received your monero, so you only own recent outputs. 2) you only own outputs in 1 block.

Issue number 2 will be somewhat fixed with RingCT because denominations will not be necessary so there will no need to stack many outputs into a transaction - so no alignment.

Issue number 1 can only be dealt with (using the current Monero client) by letting your monero "bake" in the blockchain. Future developments could include custom ring partner (mixin, fake output) selection, such that the user could decide which ring partner collection (created at random using probability density functions of different distributions) will work best for the outputs owned by the user.


How will Lightning effect the privacy properties of Monero?

Note that the Lightning Network spec is still in flux with compatibility only for Bitcoin and Litecoin currently being developed.  Monero is not compatible with the Lightning Network (lacks script support, has different timelock model, multisig works differently, etc), therefore this question makes little sense today.

That being said, the Lightning Network protocol (for Bitcoin) will enable Onion Routing which will help aleviate the IP address concern.

Subaddresses should aleviate the concern about addresses being "leaked" as they can be single-use.

There is some concern about how a long-lived payment channel might allow greater passive surveillance (transaction correlation) than is currently possible in Monero's on-chain transactions, so we'll have to see how this unfolds.

Note: if you are interested in something "like" Lightning then that may be feasible in the near future.  Still, none of this is currently the focus.


There's already some answer here: Where can I find a description of the CryptoNight hash algorithm?

Here's a schematic of CryptoNight algorithm: Source

In the node software, the hash function is called cn_slow_hash, see here. Also, there's a JavaScript implementation as well which may be easier to study.

Looking into code of some existing miners should help you as well:

https://github.com/OhGodAPet/wolf-xmr-miner/releases

https://github.com/fireice-uk/xmr-stak-cpu/releases

https://github.com/xmrig/xmrig/releases


Blocks, txs, outputs, and spent keys are already indexed. What else is there? The complete DB schema is here https://github.com/monero-project/monero/blob/master/src/blockchain_db/lmdb/db_lmdb.cpp#L148


At this time, no way to make xmr-stak (xmr-stak-amd is legacy) with the open-source AMD Linux driver.

Apart from that, the latest xmr-stak works like a charm with new Ubuntu 18.04 LTS version and the AMD Linux proprietary driver.


Which entities are related to Bytecoin and Minergate?

There is a lot of evidence connecting all of the companies mentioned in your question. There may be more connected companies that we are not yet aware of. From Wikipedia:

The first Changelly prototype was created as a startup in 2013 by the enthusiastic team of MinerGate, a mining pool, that has one of the longest track record in the crypto industry.

More evidence for the Changelly/Minergate connection has been reported by Monero users on Reddit:

There is a reason why you are not listed on getmonero.org. You are never responsive to questions and getting support is almost impossible unless you are willing to beg mods in the Minergate troll box.

Bytecoin, publicly launched in 2014 contrary to false claims of a 2012 launch but significant effort was expended prior to that time to develop the CryptoNote protocol, which is not based on Bitcoin. Due to their proven high familiarity with the complex CryptoNote protocol (at the time) nobody aside from the Bytecoin creators could be behind Minergate.

MinerGate was founded on 24th of March, 2014. It was the first mining pool for CryptoNote based currencies

Readers of Cointelegraph were surprised to learn that according to a former writer, they were funded by Bytecoin:

While some have cast doubt on my assertion, I have no doubt that CoinTelegraph was funded by Bytecoin from at least when I started and continues to get funding from the stable of CryptoNote coins, among other clients.
My suspicion is that someone close to the Bytecoin team, perhaps the Bytecoin team itself, owns CoinTelegraph. But it could be as CryptoCoinNews P. H. Madore proposed, that they are simply funded by MinerGate, which they certainly have connections to.

More details on the connections can be found in this interview with Ian  DeMartino, the writer quoted above. CoinTelegraph has partnerships with a number of companies which you did not mention, which could help explain why HitBTC is still listed on CMC, and why BCN no longer has a premine flag.
According to this 2014 Bitcointalk advertising opportunity announcement Coinmarketcap is part of "The CoinTelegraph Media Group"
Freewallet uses the Changelly API to facilitate cryptocurrency exchanges. They also introduce serious security risks typical of other Bytecoin and closed source Minergate affiliated services:

Also, they implement XMR wallets with your own unique address but they are holding the private key (from you), under the incredible justification of doing it so for "security" of the user.

Chainradar was launched in 2014 by imready2rock and shares data with Minergate. On Chainradar you will find price quotes "powered by HitBTC" and on Minergate you will find many banner adds for HitBTC. Both focus on CryptoNote coins and sometimes offer gimmicks to encourage users to download closed source software.
Read this answer about the failed attempt to force XMR/BCN merge mining shortly after launch. Combine that with more recent plans to promote merge mining with XDN. Only one Monero mining pool supports XMR/XDN merge mining. By this point which one should be obvious. The Minergate mining pool is also the one one that adds strange things to tx extra:

01c4230d59c83b3042fd82999cfda5be6b77c1673d9442d1f21c7ab9215bdc6c18021198414900000000000000000000000000000321004bff195014248ae22838853bcf293b8945f9baaac693c2d05bafe2f0f3e6c69e

The above test means that by mining on minergate you are "spamming the blockchain with whatever that crap is".
In addition to popular coins, BTC, XMR and DOGE, Fairproof supports the scarcely used XDN and BCN, which coincidentally were discussed above in the context of merged mining proposals. Minergate denied an official connection to fairproof when asked about running fairproof banner ads. However there is a lot of circumstantial evidence to counter than claim including website design and FairProof advertising in both the BCN and XDN Bitcointalk threads. Supporting hardly used coins when trying to run a successful business makes little sense, unless you have ulterior motives such as using them to promote merge mining with Monero, which is only offered if users download and use closed source Minergate software.
Based on similar circumstantial evidence such as design and an "Exchange rate provided by HitBTC" BTCLevels could also possibly be connected.


In Monero GUI Beta 2, is rewarding the solo miner automatic?

If you start solo mining, any block reward you find will appear in your wallet automatically, without any further action needed on your part. As a reminder, if you exit the daemon, you will have to start mining again, as the GUI merely instructs the dameon to mine.

Note that the likelihood of finding a block solo mining on an average computer is pretty small: currently, assuming 200 hashes a second, you can expect a block every... 1/(720 * 200 / 220e6), that is about 1500 days. However, if you do find a block, then you get 6.9*130 = $900 at current prices. So it's a lottery in exchange for helping the Monero network.

Good luck!


What are the primary differences between Monero and Bitcoin?

Privacy

You won't find your standard address on the blockchain. Every single output is its own one time address, there is no choice about it (as opposed to Bitcoin, where address reuse is discouraged, but commonplace, and easy to do).

Ring signatures allow transactions to be ambiguous about which outputs are spent, since any one of the N inputs in a ring signature appears to be a possible candidate.

Once RingCT is merged, transaction amounts will be fully obscured (they currently are ambiguous due to the split by denominations). Bitcoin amounts are in the clear (but may not be in the future, if CT gets merged to Bitcoin).

Auditability is based on voluntary disclosure of, depending on the task at hand, the private view key (allows a third party to see all your income, but not your spends, nor spend anything), the per tx keys (allows a third party to ascertain whether you did send a tx, as well as the amounts sent - useful for arbitration is someone claims you have not paid them), and signed key images (allows someone with your view secret key to determine which outputs of yours were spent, and which were not - essentially, your outgoings, also proof of reserves - but not where they were spent).

With Monero, nobody can see your balance from looking at the blockchain.

Scaling

This is a bit of a mixed bag. Monero transactions are larger than bitcoin (typical transaction is a few kB, while in bitcoin they can easily be sub kB). Higher mixin (for better privacy) also increases transaction size.

On the other hand, Monero has no fixed blocksize limit. While there is a blocksize limit for any given block, this limit evolves based on demand in the previous blocks, allowing increasing demand to increase block size, and vice versa.

Pruning is possible both with Bitcoin and Monero. In Monero, signatures are a large part of a transaction's size (even more with RingCT), and a node does not have to keep them once they've been verified (a side effect is that this node can't serve a verifiable blockchain to other nodes after pruning). Some kind of SegWit system is also possible with Monero, though I do not know the details.

Cryptonight is heavy to verify, contrary to SHA-2. This implies CPU load on nodes, which may become significant if transaction volume increases. There has been talk of switching PoW to Cuckoo Cycle, another hash algorithm with the same goals as Cryptonight, to alleviate this.

Last, since Monero is ambiguous wrt which outputs are spent, the TXO set never decreases (or very, very seldom does), whereas with Bitcoin, spent outputs can be removed from the UTXO set.

Security

Monero uses Cryptonight instead of SHA-2. There are currently no ASICs available for Cryptonight, which was designed to diminish the performance gap between CPUs, GPUs, and ASICs by demanding comparatively large amounts of memory (which are commonly available in today's PCs but very expensive to have in ASICs). This means that CPU mining is still possible, whereas in Bitcoin, CPU mining is utterly pointless. The hope is that this will encourage people to mine with existing computers, preventing too much centralization, like we see in Bitcoin with a few Chinese pools having the majority of Bitcoin hash rate.

As a consequence, CPU mining makes Monero more attractive to botnet miners as various (news) reports prove (e.g. 1, 2 and 3). This is an interesting point, because it harms zombies' owners, while benefiting Monero. While this can be seen as an overall plus, since botnets exist anyway, and are providing a good thing (Monero security) to society at large, instead of a bad one (sending spam, or serving child porn, or whatever it is they would do otherwise), it can also be interpreted as an additional (a presumably very strong) financial incentive to expand existing botnets and put more ressources into malware distribution.

On the other hand, the value of Bitcoin now has attracted a lot of miners, and it is vastly more costly to attack Bitcoin than to attack Monero. Hopefully this will change if Monero attracts a lot of attention from miners, but this is not a given.


Is there any connection between botnets PhotoMiner and Linux.Lady?

Although its common practice for malware, they both try to locate and infect vulnerable machines and services (PhotoMiner: FTP servers, Linux.Lady: Redis servers), what caught my attention was this excerpt from the GuardiCore webpage with an analysis of the PhotoMiner malware:

  Recent variants of the malware have upgraded this attack by adding
  server-side code injection and attempting to install a Linux based
  miner.

They didn't went into detail about the Linux variant so I can't say how close it is to Linux.DownLoader.196 used by Linux.Lady. The Softpedia article also goes on about other possible similarities:

  Just like PhotoMiner, Linux.Lady comes with self-propagation features.
  The trojan includes a function that detects the IP address of the
  infected computer, scans the local network, and probes for other
  vulnerable Redis servers that don't feature a password on the admin
  account.

About how much of the hashrate is dominated by botnets I would say its minimal:

  My view is that botnets "dominating" mining, after working out
  reasonable assumptions about hash rate of the network and of bot
  nodes, would require many hundreds of thousands to millions of botnet
  nodes and if that were going on, it would have a huge visibility
  footprint. Since no such thing is visible, it almost certainly isn't
  happening. Smaller botnets exist.

source: https://www.reddit.com/r/Monero/comments/4rpcbl/are_there_any_known_significant_monero_miners/d53i6i7

And he was proven right.

As we can see malware like these (CPU-intensive) are spotted pretty quickly, but as there are a large amount of unprotected and unattended machines over the web your guess is as good as mine.


Sent to wallet address before synchronization?

It is a common misconception to those new to cryptocurrencies that the coins are "stored" in a wallet.  In fact, the coins are stored on the blockchain.  They are always there, waiting to be accessed and spent.  Your wallet, at its core, is simply a key holder.  Your wallet holds the key(s) that allow you to spend your coins.

The answer is no, your coins are not lost forever.  Your wallet's public address was used to generate a transaction that consists (among other things) of an output that only your wallet knows belongs to it (because of your wallet's private viewkey), and only your wallet can spend (because of your wallet's private spendkey). (Nearly all cryptocurrencies only have one private key.  Monero is an exception to this.)

Your wallet needs to sync with a fully synced node.  The GUI can be used to connect to and sync with a remote node.  Many people do this (at the potential expense of some privacy).  Usually (but not always), the node you connect to will be in sync with the blockchain; and when your wallet syncs with it, the coins sent to it will appear.  The GUI can also basically act as its own node, in which case it will download the blockchain and verify that it is legitimate.  Once the blockchain sync is complete, your wallet will sync, and you'll see your coins.

In some instances, the blockchain will be fully synced, and the wallet will fully sync, but the coins don't show up.  This is rare, but it happens.  Generally, having the wallet rescan the blockchain will remedy that.  But also, make sure you didn't accidentally set up a new wallet with a new seed, because then your address will be different, and the wallet keys will be different, so your new wallet won't be able to find the transaction output destined for the old wallet.


If you omit a payment id, the monero still reaches the destination wallet owner, but that wallet owner does not have the information needed to know what the incoming monero is intended for (ie, for which of my clients is it). You then have to ask the recipient to do the manual work of checking they received the monero, and credit them to your account specifically. For this, you will need at least the transaction id, but more info (such as amount) is better, as anyone else could otherwise claim this txid and "brute force" the recipient.
The recipient could also ask you to prove your transaction. This is done using the get_tx_key command in monero-wallet-cli. This prevents any spoofing. In any case, this is manual work for the recipient, so please try to remember to include any payment id that's requested next time.


Is there a limit to the number of PIDs in a transfer command?

One payment ID at most is allowed, as seen in the help blurb for the transfer command (see the end):

transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] <address> <amount> [<payment_id>] - 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 fee of the transaction. 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 <address_2> <amount_2> etcetera (before the payment ID, if it's included)

If you want more than one payment id, use as many transactions.