What are the shortcuts available in the official GUI?

Ctrl+S: go to panel "Send"

Ctrl+R: go to panel "Receive"

Ctrl+K: go to panel "Verify Payment"

Ctrl+H: go to panel "History" (of transactions)

Ctrl+B: go to the panel "AddressBook"

Ctrl+M: go to the panel "Mining" (not implemented yet)

Ctrl+I: go to the panel "Sign/Verify"

Ctrl+E: go to the panel "Settings"

Ctrl+Tab or Alt+Tab: cycle among panels in the order Dashboard, Transfer, History, AddressBook, Mining, Settings.

Ctrl+Shift+Tab or Alt+Shift+Tab: cycle among panels in reverse order.

I you press control, you will see the possibilities displayed.

Source


Which characters are allowed in creating a wallet password?

The getchar standard library function is used to read the password from standard input. There is no per character blacklist nor whitelist. This means that any character is accepted. It also means that non ASCII characters are being read as your OS might encoded them. Thus, using non ASCII characters may yield different passwords on different OSes. If you wish to copy a password protected wallet between OSes, you'd be prudent to keep to ASCII characters.


Currently, the GUI isn't distributed as an app. Thus, it has to be started from the terminal. As Linux Elementary is based on Ubuntu, simply perform these steps:

Browse to the directory monero-wallet-gui is located.
Open a new terminal.
Type -> ./start-gui.sh

You should now be able to use the GUI.


CryptoKingdom currency usage of both CKG and XMR

1 - CKG should be thought more of an asset/equity than a currency.  The town of CryptoKingdom (the game's governing body) pays dividends in-game to CKG holders based on the finances and holdings of the town.  The original stated purpose of the CKG asset sales was to bootstrap the development funding of the game.  CKG could be thought of a share in the town (game development).

2 - The in-game marketplace operates in Moneritos (0.000001 XMR), but OTC trades can happen between players for any items or assets agreed upon.  XMR is stored in a depository and in-game Moneritos are credited.  Withdrawl of XMR from the game requires destruction of the in-game Moneritos.

3 - There are no current plans to offer CKG vs Poloniex.  That being said, there is nothing stopping anyone from developing an outside tradeable asset representing in-game items equities.

4 - CKG/XMR is market based.  There is an in-game coinshop that makes the market for the 100g Gold bars (offering liquidity to sell and buy).  Buying and selling moves the price of these bars.  The historical price of CKG can be found here -
https://docs.google.com/spreadsheets/d/1tgIzgMza7NQsTpMO9pHke1ZVXYH7l5Sj5bHdZHItivo/edit#gid=1541996690


Correctly retrieving the tx_pubkey from a transaction

tx_extra can contain any number of items. The field is documented here: https://cryptonote.org/cns/cns005.txt

Therefore it can contain 0..N public keys. Usually there is just one public key in it (the tx public key), but there could be more. So do not rely on there just being one, you have to parse the field and respond accordingly.

One such example of a case where there can be more than one public key in the tx extra is for multi-destination transfers involving one or more subaddresses. I also seem to recall that multisig transfers add additional keys in the field.


Is there a way to make unsigned transaction, sign and submit manually using wallet RPC?

I have been trying to accomplish exactly what you are describing for the past few weeks and I have come to the conclusion that this is not possible via RPC. You can only do this via the CLI. I am in the process of writing a RPC wrapper around the CLI so that I can make programmatic RPC calls that issue the proper CLI commands. A step-by-step guide around the CLI process can be found here: How do I use cold transaction signing? but you've probably seen this already. I am using this as a guide for the RPC wrapper.


I've got a working JSON RPC wrapper with digest auth working in https://github.com/sneurlax/moneronodejs (merging into https://github.com/monero-integrations/moneronodejs, I hope.)  Here's the relevant code:

lib/walletRPC.js

  var request = require('request-promise');

  ...

  _run(method, params) {
    let options = {
      forever: true,
      json: {'jsonrpc': '2.0', 'id': '0', 'method': method}
      auth: {
        'user': 'rpcuser',
        'pass': 'rpcpass',
        'sendImmediately': false
      },
      params: params
    };

    return request.post(`http://127.0.0.1:28083/json_rpc`, options)
    .then((result) => {
      return result;
    });
  }

EDIT: also, in my library I have to call a throwaway get_balance() ... the first call always fails for me, but subsequent calls work fine.


With RingCT on, can I lower mixin safely to save on tx fees?

As in my comment:

  The transaction size is mainly determined by the number of outputs. The number of inputs and mixin have smaller impact on the tx size. To be more precise, each output comes with a range proof using Borromean ring signature containing 64 pubkeys (representing commitments of all digits) and 2*64+1 scalars. This amounts to 193 instances of 32byte data, i.e. 6kB per output.

Smaller mixin won't help in reducing the signature size. For example, see these two transactions with mixin 6 and 2, respectively:

ae199fd5a6869be3d3b0de5334bba3d33c8579ffaae8ce8add3b05fa82a84b0c
ba734dcdb78a98c1fb369252c5dd3ce388cedd1bf1c432d5a70705de8fbc992d

The fees are exactly the same.

Also note that the protocol required minimum mixin is 2; mixin 1 is not allowed.


What is the Chinese translation for "Monero"?

"monero" means "currency" in Esperanto, so traditional Chinese would be:
貨幣 (Huòbì)

Simplified Chinese would be:
货币 (Huòbì)


RPC 'create_address' after restart daemon creates same addresses again

Subaddresses are deterministic, so the same index will yield the same address. If the wallet daemon is returning repeat addresses, it means it does not remember it has already gone through them. Most likely, you did not save before stopping the wallet daemon. Call the store RPC before quitting, or after generating a new subaddress (saving can get slow for large wallets, so you may want to save on a timer instead in that case, details will depend on your particular conditions).


I took a look at the Domain registration WHOIS details for xmr-wallet.org and it doesn't look good, im afraid.

The domain was only registered on 31/10/17 and the DNS servers are hosted in Russia - NS1.FIRSTVDS.RU

Here's the info..

Registrant Contact
Name: Stefan Dorner
Organization:
Mailing Address: Pfarrgasse,, Rattenberg Rattenberg 6240 AT
Phone: +43.5337643152
Ext:
Fax:
Fax Ext:
Email:zewegohe@p33.org

Registrar
WHOIS Server: whois.registrar.eu
URL: http://www.openprovider.com
Registrar: Hosting Concepts B.V. d/b/a Openprovider
IANA ID: 1647
Abuse Contact Email:abuse@registrar.eu
Abuse Contact Phone: +31.4482297

Important Dates
Updated Date: 2017-10-31
Created Date: 2017-10-31
Registry Expiry Date: 2018-10-31

Name Servers
NS1.FIRSTVDS.RU
NS2.FIRSTVDS.RU

I'm guessing Stefan Dorner is a bogus name.

You may want to add this to the issue on Monero reddit https://www.reddit.com/r/Monero/ as well, to see if anyone knows anymore, plus I would contact Monero devs directly - Or hopefully they will check this soon.

Dell


How much money would be required to cloud mine 51% of the network hash rate?

Assuming a current hashrate of 21.1 MH/s, an attacker would need a bit more than 21.1 MH/s to perform a 51% attack. This assumes that doubling the hashrate for a day doesn't drive miners out. According to Fluffypony's slides¹ from his presentation to a group of bankers at the Thales User Group², the rental price of 1 KH/s is approximately 13.11$. Thus, an attacker would need to spend 13.11 * 22,000 (this gives you approximately 51%, i.e., 22/43.1 = 51.04%) = 288,420 $ per day to perform a 51% attack on Monero.

However, it should be noted that, in practice, less than 51% could be needed to perform an attack. If I recall correctly something like 35-40% is already sufficient, in case of lucky variance. This would bring the cost per day down to approximately 200,000 $ - 225,000 $ a day. However, to sustain his attack, an attacker would need to constantly have >50%, because variance reduces over time.

Sources:

[1] https://cloud.getmonero.org/index.php/s/gFLjnZ40Oo14kY5 - Slide 27

[2] https://twitter.com/fluffyponyza/status/760078858867671041


Here's an analysis I did of the monero thread on bitcointalk in May 2016:
https://bitcointalk.org/index.php?topic=583449.msg14785207#msg14785207

You have to figure that the number of posters/subscribers/users has gone up significantly in the last month or so though.


I think you should have a look at Monero's official Wallet RPC documentation. There's an example for each command.

Update: Those examples use the curl utility to send the HTTP request. The meaning of the parameters can be looked up in the man page.


Does fluffy pony really own and run MoneroDice website?

He responded to many topics regarding MoneroDice from his Reddit account and he's a moderator of the monerodice subreddit.

His GitHub account also confirms he's running the site.


"Insufficient disk space" - but it's not true

I'm making this an anser because it's too long and there's code, even though it doesn't actually really answer the question:

The message is buggy, / has precedence over <<, it should use si.available >> 20. I expect boost reports 94026, which is quite small. You could try a simple separate program which just prints this:

  #include <iostream>
  #include <boost/filesystem.hpp>
  int main()
  {
      std::cout << boost::filesystem::space("/home").available << std::endl;
      return 0;
  }

Compile it with: g++ filename -lboost_filesystem -lboost_system

Then run it, it should print the amount of space available in /home. If you have the Monero blockchain elsewhere, replace /home with the actual path.

If this does return a wrong number, then it's probably a bug somewhere in boost or ZFS reporting.

--

Based on the comment below, another program:

  #include <stdint.h>
  #include <stdio.h>
  #include <boost/filesystem.hpp>
  int main()
  {
    const uint64_t add_size = 1LL << 30;
    boost::filesystem::space_info si = boost::filesystem::space("/home");
    if(si.available < add_size)
    {
      printf("not enough\n");
    }
    return 0;
  }

This uses the same types and code as monerod.


If you read your logs:

W --public-node is enabled, but RPC server 127.0.0.1:18081 may be unreachable from outside, please check RPC server bind address

Then check the monerod --help output:
--rpc-bind-ip arg (=127.0.0.1)             Specify IP to bind RPC server
--rpc-restricted-bind-ip arg (=127.0.0.1)  Specify IP to bind restricted RPC server
--confirm-external-bind                    Confirm rpc-bind-ip value is NOT a loopback (local) IP

So to bind all interfaces (which includes external), use 0.0.0.0 instead of 127.0.0.1, and use --confirm-external-bind to state you know what you're doing.


As of the Monero 0.9.0 Hydrogen Helix release the minimum mixin is 2 (2 foreign outputs per ring for a total of 3) with the exception of dust transactions. The minimum mixin will be raised to 4 in a future fork probably at the same time as RingCT according to discussions from the most recent developer meeting.

The numbers above along with the simplewallet default come from Monero Research Lab recommendations:

  Our recommended improvements to Monero include a protocol-level network-wide minimum mix-in policy of n = 2 foreign outputs per ring signature, a protocol-level increase of this value to n = 4 after two years, and a wallet-level default value of n = 4 in the interim.

Poloniex upgraded along with every other exchange and major mining pool and therefore abides by the new minimum mixin rules.


Error when starting monerod: Failed to open db handle for m_blocks : MDB_CORRUPTED : Located page was wrong type

It is likely that this means blockchain database (LMDB) corruption.

The easiest way to fix it is to rename your corrupt lmdb folder to something else, for example:

Rename C:\ProgramData\bitmonero\lmdb to C:\ProgramData\bitmonero\lmdb-old and run monerod again.

It should start without errors and it will again create a fresh copy of C:\ProgramData\bitmonero\lmdb and sync from scratch. It will take some time to catch up with the network again, though.

Also, if you don't mind, please make a .zip archive of the C:\ProgramData\bitmonero\lmdb-old and upload somewhere for Monero dev. hyc, who is the creator of LMDB database, to examine (don't worry, your wallet data is not stored there, it's safe to share). This will help to understand why it had been corrupted and possibly prevent such occurances in the future.

At the end, when all is working, you can safely delete the C:\ProgramData\bitmonero\lmdb-old

Note: the example above is for Windows systems and default settings. On other systems, you'd need to locate your \lmdb folder and do practically the same, just at different folder location.


How can someone verify that the source downloaded from github is genuine?

Signed git commits allow a user to verify the source was signed by one of the contributors. In order for this to work, however, several steps have to be taken:

The user must have git and GPG installed. While git will typically be installed already if the user wants to use github, GPG may not be. Make sure to install it from your distribution's packages, or from its source, and verify signatures and/or hashes. Downloading a trojan GPG is not a great way to start.

The user must then import the public keys that will be trusted. Most of those public keys are in the Monero git tree (in the utils/gpg_keys directory). Simplest is to import them all, though some of the contributors are not active any more:

gpg --import utils/gpg_keys/*.asc

GPG now knows those keys, and will use them when verifying a signature.

To verify a commit, or a tag, git will automatically use GPG if told to:

For a commit (here, the last one):

git show --show-signature

For a tag (here, the tag for version 0.9.4):

git tag -v v0.9.4

When you download the tree, or update it, you'll want the first command. It will check the signature for the latest commit. It is implicit that, if you trust the person which signed that last commit, you trust that person to have built upon a tree that was also signed by someone they trusted, so you do not have to check every single commit - there'd be thousands.

If a commit is not signed, it will not say anything about GPG signatures, since there is nothing to check. If a commit is not signed, alarm bells should ring. Most of the Monero maintainers sign their commits, and, for those who don't, fluffypony signs the merge, so you should always see a signed commit by fluffypony as the latest commit. This may change in the future, but the latest commit should always be signed.

If a commit is signed, you will see a couple lines about the GPG signature. One line tells you a signature is present, and tells you the key id that made the signature. You also get an email address, but this is easy to forge, and meant just as an aid. You will want to double check the key which made the signature is indeed one you want to trust: one of the ones you imported in the step above. For instance, fluffypony's current signature id is 1CCD4FCD. Always good practice to verify several sources: when importing signatures, you should see that same key id. If not, then ask questions.

The second line tells you whether the signature was good. A good signature is one that corresponds to the commit being signed. A bad signature is one that doesn't (i.e., either the signature, or the commit being signed, was altered after the fact. Or both). If you do not get a "Good signature", then something is wrong.

Last, you might get a warning that the signature was not made by a trusted signature. This can be ignored, as you did not tell GPG to ultimately trust those signatures. You could do so if you wished, but that goes into editing key properties, so I will leave it at that. Suffice to say that the trust you should afford is whether they signature signing a commit is one of the ones from the Monero contributors, based on matching key ids (note that key ids are a bit short, so it's theoretically possible that a key is forged to get the same key id. I'm not sure how practically feasible this is at this time).

So now you hopefully have it all checked out and your Monero tree shows as being properly signed by the right key. :)

It is important to realize that if those signatures are checked, it is irrelevant to consider where the tree was obtained from. As long as the signature checks out, you can be sure that wherever it was, nobody could have tampered with it, or the signature would not check out. This makes it safe to pull a tree from a seedy place (save any exploits trying to pwn git or GPG themselves by crafted trees, etc, but this is becoming way more unlikely).

This takes care of the second question. With this knowledge, we can now answer the first:

Relying on GitHub's "Verified" label is better than not relying on anything, but worse than checking signatures yourself. Why? Because you are trusting a third party to check things for you and not lie to you, as well as opening yourself to MITM attacks, or GitHub being compromised. After all, what would prevent GitHub or someone compromising GitHub from placing a "Verified" label on the page? Nothing, but checking signatures yourself will uncover the treachery.

Last point: if you're going to pull and build often, there is a script that helps with this, posted by moneromooo, a Monero contributor: https://bitcointalk.org/index.php?topic=583449.msg15315904#msg15315904
This points to a signature, which you can check with the instructions supplied. Since it's signed with moneromooo's signature, which is in the Monero tree, it also can come from any random site, as long as you check the signature to be from that same key. It's a good exercise :)
This script is meant to replace running make. It checks signatures, then runs make if they check out (and complains loudly without running make if the signatures do not check out). This ensures that, if you use this script to build, you can't forget to check signatures and unwittingly run source that was tampered with. Why is this not in the Monero tree? See that post for details.

So the morale of the story is, always verify signatures!


Has Monero published a definitive, concise threat model?

There is none.

This is an excellent opportunity for a new contributor with knowledge of threat modelling :)


What are some use cases for setting a transaction unlock time?

Setting an unlock time has many possible uses such as but not limited to:

Scheduling annuity payments
Providing a child with spending money for an upcoming vacation while ensuring it cannot be spent before the vacation is scheduled.
Paying a developer a significant amount of Monero for work being performed now without the fear that the Monero will immediately be dumped on the market.
Alzheimer patient wanting to codifying desires of a will without fear of being convinced to change them later when having diminished mental capacity.
Scheduling the unlocking of monthly child support payments several years in advance to avoid any worries about forgetting or being short on funds at a later date.
Negotiating better loan rates because payments have been guaranteed in advance.

Transaction unlock time does not actually restrict the transaction from being included in a block like with the CLTV  Bitcoin feature. Instead it sets a time period before which such a subsequent transactions which can spend it's outputs.


How do I generate a Trezor Monero wallet with the GUI (monero-wallet-gui)?

Before we start, first two notes:

Using the official GUI in conjunction with a Trezor device is only available for the Trezor model T.

If you are using Windows or Mac OS X and run active AV (AntiVirus) software, the AV software will likely quarantine the binaries (i.e. the .zip file (Windows) or .tar.bz2 file (Mac OS X)) you download from the downloads page of the official website. To resolve this issue, I'd advise to use this guide.

Trezor has also written their own guide, which includes screenshots and may thus be useful as assistant:

https://wiki.trezor.io/Monero#How_to_use_Monero_with_Trezor
In addition, we have to ensure that we're sufficiently prepared. This entails the following:

This guide assumes you have already initialized your Trezor device and thus generated a 12 or 24 word mnemonic seed.

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

Make sure your firmware is up to date.

Your Trezor needs to be plugged in.

You may need to install the Trezor bridge (in case you get an error upon generating the Trezor Monero wallet).

Now that we're sufficiently prepared, let's start! Note that the following instructions are general. If anything is OS specific I'll mention it explicitly.

Browse to the directory / folder GUI v0.15.0.4 is located.

Open v0.15.0.4 monero-wallet-gui.app (Mac OS X) or monero-wallet-gui.exe (Windows) or monero-wallet-gui (Linux).

If it tries to open an existing wallet, click on the Change Wallet button. This will bring you back to the wizard.

On the first page of the wizard, select your desired language.

On the second page of the wizard, you will have to select a mode. There are three modes, namely Simple mode, Simple mode (bootstrap) and Advanced.

In Simple mode mode, the GUI wallet will automatically connect to a remote node and have a simple interface. This mode excludes the need for the blockchain sync and ensures you can immediately use the wallet. However, it weakens your privacy insofar as the remote node will be able to see your IP address as well as associate any of your transactions with your IP address. Besides, using a remote node does not contribute to the strength and decentralization of the network.
In Simple mode (bootstrap) mode, the wallet automatically connects to a remote node whilst syncing your own (local) node in the background. The wallet will subsequently switch to your own (local) node once it is fully synced. This allows you to immediately use the wallet while still eventually using your own (local) node (which is optimal for privacy and contributes to the strength and decentralization of the network). Additionally, this mode has a simple interface as well. This mode is the default and is thus recommended by the developers for new users.
In Advanced mode, you will perform the blockchain sync from scratch (which may take from 10-14 hours (with an SSD) to several days to complete (with an HDD) and requires approximately 75 GB of free disk space) without connecting to a remote node. Advanced mode also contains all features that were deemed as advanced by the developers (and thus were left out of the simple mode). Note that you won't be able to properly use your wallet until the blockchain sync from scratch has been completed. Lastly, Advanced mode allows you to customly set a remote node (in case you, for instance, want to connect to your own remote node).

On the third page of the wizard, choose Create a new wallet from hardware device

Enter a new Wallet name

Make sure the Create a new wallet from device option is selected.

Leave the Subaddress lookahead (optional) box blank.

Make sure the Device name is set to Trezor

Go to the next page. If you have the passphrase feature enabled, you will have to type in your passphrase.

On the device, confirm the export of watch-only credentials.

Your Trezor Monero wallet will now be generated. This will only take a few seconds.

Enter a password for your wallet. Note: this password is not required / needed to recover the Trezor Monero wallet.

Proceed to the next page, which will provide an overview (note: there will be an additional setup page in case you chose Advanced mode, please see the Addendum).

Press Use Monero.

Congratulations, you can now use your Trezor Monero wallet in conjunction with the GUI.

Addendum: (in case Advanced mode was chosen)
On the Daemon settings page you basically have three options. First, you can simply run a local node. This entails performing the full blockchain sync, which may take from 10-14 hours (with an SSD) to several days to complete (with an HDD). Second, you can run a local node and make use of a bootstrap node. This also entails performing the full blockchain sync. However, this option allows you to immediately use the wallet whilst your local node performs the initial blockchain sync in the background. Third, you can use a remote node, which allows you to immediately use the wallet. Using your own (local) node is most advantageous with respect to privacy and security plus it contributes to the strength and decentralization of the network. It, however, requires approximately 75 GB of free space. Furthermore, performing the initial blockchain sync is quite resource intensive and may cause the GUI to feel laggy / buggy. Although, this can be mitigated by applying this guide. Now, practically speaking, you can choose option 1 by leaving all boxes blank and, optionally, specifying a custom Blockchain location. Option 2 is chosen by entering a remote node (a list of remote nodes can be found here in the Bootstrap node box. Option 3 is chosen by first ticking the Connect to a remote node box and subsequently entering a remote node (to reiterate, a list of remote nodes can be found here.

A few final notes:

I'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet.

The wallet files are, by default, stored in /Users/<username>/Monero/<wallet-name> (Mac OS X) or Documents\Monero\<wallet-name> (Windows) or /home/<username>/Monero/<wallet-name> (Linux).

The .keys wallet file stored on your system contains some settings related to the wallet and your public keys. It does not contain your private spend key. Put differently, the private spend key remains on the Trezor device.

You only have to use this guide once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the GUI. That is:

[1] Make sure your Trezor is plugged in.
[2] Open GUI v0.17.1.9
[3] Enter the password to open the wallet.

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

[1] Exit the GUI by clicking on the x (right top).
[2] Unplug the Trezor device.

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


Make sure it isn't blocked by an antivirus (including Windows Defender), that would be the usual cause.


How does a wallet using a remote node select ring members?

This is indeed one of the problems with using a public remote node controlled by someone else. There is some related information in this answer.

For optimal privacy one should use their own node (whether local or remote).


Is anyone working on nVidia GPU mining software? How to improve it ourselves? Last release is from 2014.

There is this proposal but it did not get funded.


Yes, this is possible, though I don't think a wallet implementation of it exists at the moment.

First, we need to understand that OpenAlias is simply a protocol whereby a DNS lookup can be used to query an alias, such as donate@getmonero.org, and return a regular address. As of 21 March 2017 for this example, this is:

44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A

Understanding the construction of an address and of an integrated address is also crucial, and is discussed here: What is an integrated address?
Given that we understand how to construct both a normal address and an integrated address, a rundown of how a wallet could send to an integrated address using an OpenAlias name is as follows:

Given: donate@getmonero.com#057980027d4b36df

Parse:

OpenAlias: donate@getmonero.com
Payment ID: 057980027d4b36df

Get address via OpenAlias:
44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
Decode address:

Version (hex): 12
Public Spend Key: 42f18fc61586554095b0799b5c4b6f00cdeb26a93b20540d366932c6001617b7
Public View Key: 5db35109fbba7d5f275fef4b9c49e0cc1c84b219ec6ff652fda54f89f7f63c88

Encode integrated address:

Version (hex): 13 <-- Note that integrated addresses use a difference version #
Public Spend Key: 42f18fc61586554095b0799b5c4b6f00cdeb26a93b20540d366932c6001617b7
Public View Key: 5db35109fbba7d5f275fef4b9c49e0cc1c84b219ec6ff652fda54f89f7f63c88
Payment ID: 057980027d4b36df

Output Integrated Address: 4DrvGduF3ynBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVPkaWoLSK6nHSCXS5b6

So a company could easily say "please pay 4 XMR to pay@mystore.com#0123456789abcdef". The important thing in terms of making this useful is that the payment ID does not need to be included in the OpenAlias registration, which would be an unsustainable solution.


Daemon blocks remaining, Daemon is syncing but nothing happening?

There are two main possible bottlenecks: your internet and you disk speed.
Check how loaded your disk. If it's HDD and most time load nearby full, you can try to download blockchain on SSD (after that you can move it to HDD because you'll not download entire blockchain so it won't take as many time as first).


How is the commitment for a previous outpoint computed (tx v2)?

There is an outPk for each output in a transaction, and therefore you'll need the outPks from the transactions that created each of the inputs. (Where each outPk is C, i.e. the sum of Ci).

OutPks are stored after the pseudoOuts and ecdhInfos in every version 2 transaction.


How do I, on Mac OS X, generate a Ledger Monero wallet with the CLI and subsequently use it in the GUI?

The GUI is now able to directly generate a Ledger Monero wallet. Thus, please see this Q&A:

How do I generate a Ledger Monero wallet with the GUI (monero-wallet-gui)?

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

This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.
You need to run / use GUI v0.12.3.0, which can be found here. You can, if you're still running an older version, use the instructions in aforementioned Reddit post to upgrade.
You need to install the Ledger Monero app and configure your system. Instructions can be found here (sections 3.1.1 and 3.2.2 in particular).
Note that the instructions for system configuration (section 3.2.2) on Mac OS X are quite elaborate and can be perceived as slightly convoluted. Fortunately, tficharmers has created a guide here that you can use for assistance.
All Monero related processes need to be closed.
Your Ledger needs to be plugged in and the Ledger Monero app should be running.

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

Use Finder to browse to the directory / folder monero-wallet-gui.app (GUI v0.12.3.0) is located.
Right click on monero-wallet-gui.app -> Show contents
You should now see monero-wallet-cli
Go to your desktop.
Open a new terminal (if don't know how to open a terminal, see here).
Drag monero-wallet-cli in the terminal. It should add the full path to the terminal. Do not hit enter.
Now type:

--generate-from-device <new-wallet-name> --restore-height 1585000 --subaddress-lookahead 3:200

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:

--generate-from-device MoneroWallet --restore-height 1585000 --subaddress-lookahead 3:200

Note that aforementioned text will be appended to the path of monero-wallet-cli. Thus, before you hit enter, your terminal should look like:

/full/path/to/monero-wallet-cli --generate-from-device <new-wallet-name> --restore-height 1585000 --subaddress-lookahead 3:200

Where the full path is, intuitively, the actual path on your Mac OS X.

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.
The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.12.3.0) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one cavaet. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.
You may have to hit confirm twice before it proceeds.
Your Ledger Monero wallet will now be generated. Note that this may take up to 5-10 minutes. Furthermore, there will be no immediate feedback in the CLI nor on the Ledger.
You may, after the CLI has generated your wallet, get an error about the wallet not being connected to the daemon. You can ignore that for now.
Type exit into monero-wallet-cli to close the CLI.
Note that your wallet files will, most likely, be stored in ~, which is short for /Users/<username> on Mac OS X. This may be a bit inconvenient. Fortunately, however, you can simply copy the wallet files to a different preferred directory / folder.
Open GUI v0.12.3.0. If you have already created a wallet in the GUI, click Cancel when it prompts you for the password of your current wallet. This should bring you back to the wizard. If you haven't already created a wallet, you should automatically start in the wizard.
The first page of the wizard is language selection, which looks like this. Select your desired language to proceed.
On the second page of the wizard, which looks like this, select Open a wallet from file.
Select the wallet file (the .keys file, which, to reiterate, is stored in either Users/<username> or in your preferred directory / folder) you just created with the CLI.
Congratulations, you can now use your Ledger Monero wallet with the GUI! If you need any general assistance with the GUI, please see this guide.

A few final notes:

I'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet.
If desired, you can manually tweak the --subaddress-lookahead value. The first value is the number of accounts and the second value is the number of subaddresses per account. Thus, if you, for instance, want to pregenerate 5 accounts with 100 subaddresses each, use --subaddress-lookahead 5:100. Bear in mind that, the more subaddresses you pregenerate, the longer it takes for the Ledger to create your wallet.
You only have to use the --generate-from-device flag once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the GUI. That is:

[1] Make sure your Ledger is plugged in and the Monero app is running.

[2] Open monero-wallet-gui

[3] Enter the password to open the wallet.

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


Unable to send funds from GUI, error: Couldn't send the money: daemon is busy. Please try again later

"Busy" means one of two things:

the daemon has not finished syncing the blockchain
the daemon has not found at least one other peer

Run "status" in monerod, and it'll tell you about both these things:

The X/Y numbers at the start of the line tells you the height it's reached vs the height it thinks the network reached. It'll download and verify new blocks so X can increase to get to Y.

The X(out)+Y(in) numbers near the end of the line tell you the number of peers you connected to and connected to you, respectively. If they're both zero, then your daemon is unable to connect to the Monero network.


Is there a monero vanity address generator?

Go to https://xmr.llcoins.net/ and open up the Javascript console. Then run the command:

while(document.getElementById('pubAddr').value.substring(2).toLowerCase().indexOf('ABC'.toLowerCase())!=0) allRandom(); alert('done');

or to make a case sensitive match:

while(document.getElementById('pubAddr').value.substring(2).indexOf('ABC')!=0) allRandom(); alert('done');

(replacing 'ABC' with the string you're looking for).

Beware, brute force generation of Monero addresses requires elliptic curve multiplication, which is a slow operation. If you attempt a match that is longer than 2 or 3 characters, expect a wait of several hours. The time required for a match will rise geometrically with each additional character in the match string.

Monero addresses are represented in base 58, so you can have any alphanumeric characters excluding 0 (zero), O (capital o), I (capital i) and l (lower case L).


If I need to send a bunch of transactions, how can I stop the wallet from using my entire balance as change during the first transaction?

There's no direct way, but there could be a workaround.

The protocol doesn't limit the number of inputs/outputs. So, you could split the first transaction into many outputs where some (or all) of them are going back to yourself. This way, you'd do all your payments at once, and get more than one change output. Yes, you'd pay more fees but you'd then continue with enough unspent outputs to avoid the experience of having most funds locked on every transaction. You could do it with the CLI wallet, too! The transfer command allows for many destinations.

transfer [<mixin_count>] <addr_1> <amount_1> [<addr_2> <amount_2> ... <addr_N> <amount_N>] [payment_id] - Transfer <amount_1>,... <amount_N> to <address_1>,... <address_N>, respectively. <mixin_count> is the number of extra inputs to include for untraceability (from 2 to maximum available)"


How long are unmined transactions kept in the memory pool?

Transactions drop from the txpool:

after 7 days if they were included in a block that was orphaned
after 24 hours otherwise

The orphaned block case can happen with invalid transactions, if they were mined by a daemon which does not obey consensus (maybe an old one). This is something that may need a bit more work to determine when to apply the first limit, and when to apply the second one.

Once transactions drop off the txpool, the wallet should notice this in short order, and consider the transaction as failed, and its inputs spendable again.


How many new Monero are mined every day?

At time of writing, emission (new Monero) is 1.085279 per block. Block target time is 120 seconds, so that's an approximate 781 XMR per day (1.085279 * 720), which is constantly decreasing until it hits 0.6 XMR per block (tail emission, ~432 per day).


Will Monero ever move to Proof of Stake (PoS)?

Though your first sentence is not actually a question, I shall refute your statement. Energy is never burned using POW or wasted, every single bit of it serves an extremely valuable purpose, no miner is wasting energy, they all get paid for their contribution and that contribution is proportional to the usefulness and value of the network as a whole. It uses proven and sound principals to reach an outcome while ensuring it's integrity as a 100% decentralised autonomous network unlike PoS which has major deficits in it's decentralisation and viability as a network that can resist attack and maintain it's security and integrity. Monero's POW is however designed to make it less efficient to centralise as it has a large memory component, so this should mean mining on PCs and GPUs will be viable for at least several years to come, and then there is the option of stalling the jump to ASICs even further by employing cuckoo POW which is even more memory heavy (and results in much faster transaction verification times). Ecologically the argument is moot as Monero is not a system requires infinite growth, it will reach an equilibrium where the number of transactions, nodes, and services it can support will peak, and miners will stop growing with that. Unlike other financial systems that demand higher and higher consumption via debt to keep the financial wheels turning, systems that utilise PoW do not have such antiquated mechanisms and will reach equilibrium eventually. They are able to grow and shrink as needed to support the economy that it underpins and have no fundamental requirement to grow at all costs. Once big enough, their resource requirements will stabilise.

As to your actual question, those features are already in place in the monero-wallet-cli, it only needs to be specified when restoring your seed. As long as you know the blockheight from which the first transaction appears, you can skip scanning most of the blockchain up until that point.


How do I generate a Ledger Monero wallet with the CLI (monero-wallet-cli)?

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

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

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

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

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

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

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

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

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

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

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

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

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

You may have to hit confirm twice before it proceeds.

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

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

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

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

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

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

You need to install the Ledger Monero app.

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

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

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

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

Go to your desktop.

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

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

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

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

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

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

You may have to hit confirm twice before it proceeds.

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

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

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

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

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

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

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

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

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

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

Open a new terminal.

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

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

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

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

You may have to hit confirm twice before it proceeds.

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

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

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

A few final notes:

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

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

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

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

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

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

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

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


How will the temporal output alignment of ring partners (mixins) be addressed?

There are three main ways to fix this.

The first one is to attempt to select outputs which are unrelated, if possible. This only works if you are sending an amount of monero that can be represented with unrelated outputs. This means that if you have received a single payment, you won't be able to select unrelated inputs, since they're all related - unless one single input in that transaction is enough. This is partly taken care of by https://github.com/moneromooo-monero/bitmonero/commit/90fb5e411307a949779c65a1931f3462ee3a564d, which selects unrelated inputs first, before falling back to related ones. However, this can only work if you have enough unrelated outputs.

The second one is to add "streaming payments" to Monero. These would split a payment into multiple transactions, such that each transaction has a single input, and these transactions are randomly distributed in time, so they can't be linked together. This is a bit complicated, since it requires the recipient to have a concept of "not received, partly received, received", and it requires things like the wallet staying up long term so that transactions may be emitted over time.

The third one is to select fake outputs to be clustered around each real output. I'm not sure this really achieves the purpose. It might look good visually on the graph (ie, you can't see obvious correlations), but I think a computer will still see correlations just fine.

Once RingCT is in, this problem will also become less acute, since transactions will typically require less inputs, as amounts will not be split by denominations anymore. Howerver, it will still exist to some lesser extent, and that's the reason the patch above was made (and could be improved, I suppose, but it's unclear how right now).

tl;dr: just waiting a bit will fix most of it.


When is it safe to confirm the transaction?

It is very unlikely that a 3 or 5 block depth should be reverted. That would mean there was a chain split, and should be the result of an attack.
But after all, it's up to you to define how long you would wait to consider a transaction confirmed. For enormous payments, you may want to wait more than 10 blocks. And for small one, even 2 blocks could be considered enough.

It's all about the risks, and much more: is the transaction worth the cost (in hashpower) for the other party to try to split the chain?
Otherwise it would be a coincidence, and a fair customer will accept to send a payment again if the previous one was finally rejected because of some chain split occurring at the same time.


Transferred Monero from Shapeshift, want to send to different address

If you had used the Monero GUI (desktop app) to create your Monero receiving address, your address will not change if you decide to instruct the GUI to use a remote node.

Syncing with a remote node means you don't have to download and verify the entire blockchain, but you still need to download part of it and it still requires your PC to do some very heavy computation which could take several hours. The use of remote nodes will not make anything 'instant', in the way that using a Bitcoin light wallet would. This is because of Monero's "stealth address" privacy mechanism that requires you to scan the blockchain for incoming transactions. Your wallet will not reveal your Monero address to the remote node.


What is a dynamic dust threshold system?

Dust threshold used to be considered as a fixed amount. The threshold is now dynamic in relation to the transaction fee.


Details of multisig in the answers to this question: How to Use Monero Multisignature Wallets (2/2 & 2/3)

But no, actual signing doesn't need to be done while online.


Running a full node without revealing my home IP address

I can only speak for Tor: using torsocks can make monerod connect to other nodes via the Tor network.

This will run monerod with Tor:

DNS_PUBLIC=tcp torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd

If you cannot connect your wallet (which should not use Tor), you may need to add TORSOCKS_ALLOW_INBOUND. Apparently, different systems may or may not need this option:

DNS_PUBLIC=tcp TORSOCKS_ALLOW_INBOUND=1 torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd

In any case, make sure your firewall blocks the port monerod may listen for RPC connections, assuming the wallet runs locally.


You need a curly brace at the very end of the program.


Monero GUI 2 on tails os text not visible issue

To run Monero GUI wallet on tails use the 32 bit version.

Open the start-gui.sh file. This file is inside the folder where all the monero binaries are.

add this line before the ./monero-wallet-gui line.

export QT_QPA_FONTDIR=/usr/share/fonts/truetype/unifont/

This line will provide the path to the fonts folder. Now to run the gui use command:

bash start-gui.sh


On Mac, the chain and associated files are stored in this path ~/.bitmonero.

The wallet files are wherever you placed them.

For the binary, just delete the application from your applications folder.


I had this error, rolling back my drivers appeared to fix this. Nvidia Driver Rollback


Is Monero really decentralized, if the dev team can easily change the POW algorithm to fight off ASICs so easily?

Centralization is a continuum. Actions and circumstances move a particular system along that continuum.

There are several points which are topical here:

Monero development is made by a smallish number of people (more centralized)
Anybody with skills is free to join Monero development (less centralized)
A single party being able to dictate what gets mined is extremely centralized
Miners choose what code they run, regardless of what Monero developers do (less centralized)
The Monero community previously backed a stance of forking to prevent hash rate monopoly (less centralized)
Hardware with much higher efficiency than usual in the hands of very few parties is a very large centralization force

So when you consider this, you can deduce that, in this particular case, forking makes Monero less centralized than not forking.

Now, Monero is less decentralized that Bitcoin, which has more developers, and where the current mining distribution seems less concentrated. But more decentralized than many others cryptocurrencies.

I think one very important point that many people are missing is that of "but the Monero developers change the code, that's centralized". This is completely missing the point that Monero developers come and go, and that anyone is free to be part of this group. Indeed, a few people who have gone include NoodleDoodle (an original core team member), the late Warptangent, or tewinget. A few people who joined the developer team include moneromooo, hyc, or stoffu. Some are in both groups. What makes it seem centralized is that the current set of people who develop Monero are seen as a static "Monero developers" group, though this group is not static in the first place, it is just a term for whoever happens to be developing Monero at the time (many of these people being long term Monero developers, but not all).

Additionally, this was not fully without community feedback. While the original discussion was made privately to avoid tipping off those suspected ASIC operators early, public discussion was had afterwards to get to a consensus on what to release when.

As for your particular point about the longest chain: the rule is the longest valid chain wins. Once the fork happens, the chained mined by miners using the new code will not be valid anymore by the rules used by miners not using that new code, and vice versa.

tl;dr: That change in rules was made to help decentralization, and I believe it clearly does if you consider the points above.


Why aren't there any miners written in assembly for x86 / x64 etc?

The following was taken from here and expanded upon

C is easier to program in, compared to Assembly. There are obvious reasons not worth rehashing.
Being easier to use, C allows you to write programs faster. Generally these programs are           also easier to debug and easier to maintain. Furthermore, it's easier to manage large, complex programs in C.
Often times, code generated by a compiler is equally as good (in terms of speed and efficiency) as hand-written assembler - if not better.
C is pretty darn low-level, and it's rare that you'll want to go much lower. Having an added layer of abstraction is rarely a bad thing.
When you do need to go lower, you can use Assembly, otherwise you can use C.
You can write Assembly in C-code, but not C in Assembly-code.
A C compiler applies optimisations reliably and systematically - not just when it notices the opportunity
Creating a miner is often done in a collaboration and there are far less assembly programmers out there
C++ (which extends C) and is popular with miner development further improves development time, organization, and collaboration


You'll find some examples over at https://github.com/moneroexamples

However, Monero's blockchain does not offer as much information like Bitcoin's blockchain and you will fail to query balances of specific addresses or transaction details unless you have access to the private keys.


Monero deposit did not arrive on binance

First thing you have to do is, download the newest version of the Monero Client GUI and import your wallet there. Make sure to user version 0.12.

Then sync the blockchain and let's see if you still have that issue.

I think you will actually see that you still have your Moneros in your wallet and that the transaction didn't work out.


Why is it taking so long for GUI to Sync? My balance is still at zero

my balance is showing at zero - after 8 days mining, is this because the wallet hasn't synced yet or 8 days mining in minexmr at 150 H/S gives zero payout?

The minimum payout is 0.5 XMR from minexmr, as far as I know.  At 150 h/s, it will take several months to reach that threshold.

  Why does the synchronisation process take so long?

The Monero blockchain is opaque.  Balances aren't stored at addresses like in nearly every other blockchain.  Your wallet needs to scan blocks to try to "unlock" all the unique, one-time addresses on the blockchain to see which outputs are owned by it.  The most trustless and private way to do this is to first download a copy of the blockchain locally, which can take from several hours to several days.

  It seems like a lot of effort compared to other wallets/currencies I have used which 'sync' in one second. Why can't my wallet just find me in the blockchain and tell me what my balance is?

See previous answer.

  Or - as I say is it just because there probably hasn't been a payout yet. What do you think people?

In this case, it sounds like your wallet is probably empty anyway.  But, in general, it does take longer for new Monero users to get up and running than for other cryptocurrencies for the reasons mentioned above.


How to restore Monero RPC Wallet from seed

A command has been added to restore from a seed, the documentation is just a little outdated.

The parameters are:

  uint64_t restore_height;
  std::string filename;
  std::string seed;
  std::string seed_offset;
  std::string password;
  std::string language;

Which should all be self-explanatory.


Where is the code that generates stealth addresses and matches them with view keys?

Private spend and view keys for public Monero addresses are generated here: https://github.com/monero-project/monero/blob/102a51bcd48a3cd2cb794aab7dbe243393f155b3/src/cryptonote_basic/account.cpp#L81

Stealth addresses are generated here as part of generating a transaction: https://github.com/monero-project/monero/blob/102a51bcd48a3cd2cb794aab7dbe243393f155b3/src/cryptonote_core/cryptonote_tx_utils.cpp#L197

Stealth addresses are identified as belonging to a user's address through use of the private view key here: https://github.com/monero-project/monero/blob/102a51bcd48a3cd2cb794aab7dbe243393f155b3/src/cryptonote_basic/cryptonote_format_utils.cpp#L638 and https://github.com/monero-project/monero/blob/102a51bcd48a3cd2cb794aab7dbe243393f155b3/src/cryptonote_basic/cryptonote_format_utils.cpp#L595

Note that the Cryptonote whitepaper was written before subaddresses were devised. Subaddresses increase the complexity of scanning for outputs destined for a  wallet. Subaddresses are explained here: https://github.com/b-g-goodell/research-lab/blob/master/publications/bulletins/MRL-0006-subaddy/MRL-0006-subaddresses.pdf


Help! Trouble syncing daemon on mac wallet

Try starting the daemon with ./monerod --block-sync-size 10. Those messages are normal, but you should receive some updates on the progress every now and then.


Comparing with Bitcoin, since blocks in Monero are 5x "faster" (2 min X 10 min) we are roughly in mid-2012.


How much information is passed from the daemon to simplewallet when scanning for a wallet's transactions?

I captured the stream of RPC requests and answers between monero-wallet-cli and monerod (v0.10) with wireshark to see how much data is transferred during a synchronization.

It was a synchronization of 658 blocks (blocks 1159032 to 1159659), and the total amount of data exchanged was:

7662 bytes from the wallet to the daemon (get_version, getblocks.bin, get_transaction_pool and gettransactions requests)
5912493 bytes from the daemon to the wallet (almost all of which was answers to the getblocks.bin requests)

It means that on average the daemon sent between 8 kB and 9 kB of data per block to synchronize (RPC headers and JSON formatting included). I looked at the last 20 blocks of the synchronization and their average size is around 6 kB. In fact, the daemon sends the complete blocks to the wallet, and the wallet checks all the transactions in the received blocks to find its own.


What is SIGAINT

From their website:

  What is SIGAINT? SIGAINT is a darknet email service that allows you to send and receive email without revealing your location or identity. We provide this service to help journalists and activists combat the dragnet surveillance that exists on the Internet today. Even if you aren't in conflict with the state or anyone in particular you as a human being deserve privacy.

In addition, there is this Wikipedia entry.

  and why are they running a Monero node on Tor?

From their announcement:

  It enables a Tor user to easily transact in Monero using a thin-client while securely maintaining the keys to their wallet on their computer all while not even exiting Tor!

  Has SIGAINT made a statement explaining their rationale?

Yes, they have:

  Why Monero?

  The SIGAINT operators firmly believe that Monero is the next logical step in Darknet commerce. It solves most of the privacy problems that plague cryptocurrency systems such as Bitcoin. (Youtube video explaining how Monero works.)

There is one, additional, interesting bit from their announcement, namely:

  What about cryptocurrency X/Y/Z? I heard they can mix/join/ninja vanish.

  Bitcoin mixers (even coinjoin) are not enough to maintain transaction unlinkability. Not to mention the Bitcoin blockchain data is currently being mined and sold to law enforcement.

  Dash's supernodes could collude to reveal who you are.

  Zcash is operated by an LLC in the USA. Besides the obvious political problems, Zcash doesn't mix by default it is opt-in. Also, it may be possible for the maintainers to secretly inflate the currency by hiding inflation into zk-SNARK "pours".


Generating key derivation in construct_miner_tx

Let's start by first defining a couple of things. Outputs created in a coinbase transaction can later be spent by using them as inputs to a subsequent transaction. A transaction also has a public key, which is used as the public part of a secret (it's shared, it's in the tx which is on the blockchain).

When constructing a coinbase (miner) transaction, the generated coins are placed as outputs of the transaction. These outputs are only spendable by the miner - they are constructed in such a way that only the miner can spend them (you would need the miners private spend key).

So, in construct_miner_tx:

crypto::generate_key_derivation(miner_address.m_view_public_key, txkey.sec, derivation);

Where miner_address.m_view_public_key is A (the miners public view key) and txkey.sec is r (the tx private key), the output of the function generate_key_derivation (which is placed in derivation), is 8rA.

  So key derivation is 8*(PvK txsk), right?

Correct.

Then:

crypto::derive_public_key(derivation, no, miner_address.m_spend_public_key, out_eph_public_key);

This is placing H(8rA||i)G + B in out_eph_public_key. This is an output key that becomes spendable by the miner. There can be more than one output key (hence this is in a loop and is indexed by i in H(8rA||i)G + B).

  Then derive_public_key is H(8*(PvK txsk) || output_i)G + PsK?

Thus, correct.

  Do all my assumptions make sense? And is the output of generate_key_derivation a plain public key?

Not quite. generate_key_derivation is creating 8rA (a point), which is then used by derive_public_key to create an output key (or in Monero parlance, a stealth address).

  And is the shared secret key the output of hash_to_scalar?

No. hash_to_scalar just takes a hash and converts it to a scalar. The public part of the shared secret is the tx public key, created earlier in construct_miner_tx:

keypair txkey = keypair::generate(hw::get_device("default"));

This is creating r and R (in txkey). The shared part is R which is included in the tx as the tx public key (stuffed into the tx field tx_extra, add_tx_pub_key_to_extra). Only someone with r or a can derive the shared secret aR or rA (as used in the calculations above). The recipient uses aR in their side of the calculations when scanning transactions, to know the transaction is destined for them. r is not stored in the transaction, it is used for the sender-side of the shared secret (rA above).

Hope this helps!


Is it possible to remove unlock_time for a transaction?

Yes. You need overwrite the transaction with another transaction sans unlock_time. If the transaction in question is already in a block, then you'll need to reorganize the blockchain to the depth where this transaction was first added, removing it and adding your replacement.

The short version: "no". This is part of the immutability property of blockchains (unless you are ETH).


Do signed exported key images prove that the key images provided are legitimate?

When exporting signed key images, the signature of each key image is in fact a ring signature with the output public key P and the key image I as parameters.

Therefore it proves that the signer knows the output secret key x such that P = x·G and I = x·Hp(P) (see ring signature algorithm), which means that I is the correct key image of P.

In the source code of Monero, the function doing this is wallet2::export_key_images() in src/wallet/wallet2.cpp.


Does AEON offer a sweep transaction feature?

Right now, with release 0.9.8.0, it isn't possible, as there's no equivalent sweep command in Aeon's CLI.

I asked your question on Slack today, and this is what moneromooo had to say on the topic:

  I think it's fairly new in monero. I also think it relies on the new tx composition algorithm, so not an easy port.

  It'd be possible to add a function to do this using the previous algorithm, but it's less well suited and might well fail pretty often, which makes it not very useful.

Hope this answers your question.


Can I set up the GUI or daemon to use a non-standard blockchain location in Windows?

On Windows, this can actually be done fairly simply.  These options are slightly technical, but not terribly difficult, and only have to be done once.  There are a couple quick ways.

Option 1 - Make a copy of the shortcut link used for launching the GUI (or monerod).  Then right-click the copied shortcut to edit the shortcut's properties; and then add at the end of the Target: line/box --data-dir \path\where\bitmonero\folder\is. Click OK to save.  Double-clicking the link will launch the program with the --data-dir flag, which will be pointing to where you're keeping your copy of the blockchain.

Option 2 is to create and open a new text (*.txt) document, which you can do just by opening up Notepad.  Enter C:\path\to\monerod.exe --data-dir \path\to\bitmonero\folder.  Save the file with whatever name you like.  And then change the file extension from txt to bat.  This file will now behave just like the shortcut link from Option 1.


Could I use a Raspberry Pi to mine Monero?

I have my Pi3 mining away on my new pool:

Gulf Coast Mining (XMR)
https://mon.gulfcoastmining.com

I've created two "PI" specific ports on the pool to align difficulty:

PPLNS: 2222
SOLO:  2224

(SOLO of course being a long shot lottery but why not!!)

It's hashing at about 10H/s which even at that rate far exceeds any cost of electricity (yearly estimate is $6). It will get warm though if left on 24x7. I have it encased in an aluminum chassis that acts as a heatsink. I would definitely not do it without addressing the heat. It also gets hot enough in my case that small children should be sure to be beyond reach.

I compiled directly on the Pi3, set it up in a screen session and it has yet to have any issues.

https://github.com/tpruvot/cpuminer-multi


The underlying Elliptic Curve that is used for Monero's cryptography is the Twisted Edwards curve Ed25519, and this is the same curve used in applications like OpenSSH, Tor, Tox, I2P, Facebook Messenger, Google, Whatsapp, and others. That doesn't, by itself, guarantee that it is flawless, but it is a very good endorsement IMO, and it is a bigger test of time than Monero itself.


Where to find the Monero blockchain by itself?

The blockchain can be downloaded here: https://downloads.getmonero.org/blockchain.raw

Note that hours of processing power is still required to verify the blockchain when you import it. You can disable this verification by following the guide here: https://getmonero.org/resources/user-guides/importing_blockchain.html

Warning: The whole point of verification is that you can trust that the blockchain you download is not compromised. Turning verification off is not recommended.


Could I just delete the Monero GUI wallet and wouldn't it just go back to being cold?

You could delete it and it would become kind of "cold", but if it was "hot" at any moment in time, then during that time you were exposed to the risk of leaking your wallet file / password / mnemonic to some adversary if your computer was compromised at the time you made it hot.

It's all about managing risk. The CLI/GUI wallets are pretty safe even when "hot", and I'm not aware of anyone getting his funds stolen so far. But it's really as safe as your computer so one always needs to be careful! As a minimum, keep your computer clean and up to date with security fixes, have some anti-virus, don't open suspicious links or software, and use a strong password for the wallet. After all, being your own bank also means you have to take responsibility for your security.

  So if I ever wanted it to go hot again I would just reinstall the wallet and import the wallet from the seed and sync the chain?

That's right. But bear in mind that anyone could do the same with your mnemonic and steal your funds, so keep it safe!

If you want a compromise, I'd suggest running some "live-CD" Linux to access your wallet, and keep the copy of the blockchain on some USB drive so you don't have to re-sync the blockchain from scratch every time.


My Ledger Monero wallet shows an incoming transaction with a value of zero (0), how do I resolve this issue?

This bug is caused by the GUI wallet, if used in conjunction with Ledger Monero App v1.1.3 (or lower), not being able to properly decode the amount. Fortunately, however, the following fix can be used to resolve your issue:

In case you are using the GUI:

Exit the GUI (make sure you are using GUI v0.14.1.0).
Make sure your Ledger Monero app is upgraded to v1.3.1
Make sure your Ledger Live firmware is upgraded to v1.6.0
Browse to the directory your wallet files are located (Documents\Monero<wallet-name> on Windows | home/<username>/Monero/<wallet-name> on Linux | Users/<username>/Monero/<wallet-name> Mac OS X).
Rename <wallet-name> (the file without extension) to <wallet-name>-old
Restart the GUI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.

In case you are using the CLI:

Exit monero-wallet-cli (make sure you are using CLI v0.14.1.0).
Make sure your Ledger Monero app is upgraded to v1.3.1
Make sure your Ledger Live firmware is upgraded to v1.6.0
Browse to the directory your wallet files are located (normally in the same folder as monero-wallet-cli)
Rename <wallet-name> (the file without extension) to <wallet-name>-old
Restart monero-wallet-cli. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.


How will outputs be migrated to RingCT, in the transaction building level?

If you have unspent outputs from non-rct transactions, they are mixed with other non-rct transaction outputs in the same manner as before (an attempt is made to find a mixin number of other outputs of same amount). Then, the amounts of each output in the new rct-transaction are separately "masked". Each verifier (all other nodes), create an "identity" commitment for the inputs to verify no XMR was created in the process - this is identical to how miner outputs now work.

A picture might help, two unspent transactions with mixin 2:

[input amt: 2]--
                \
[input amt: 2]----[ring signature] --+
                /                    |
[input amt: 2]--                     |
                                     |
                                     +--[proof: (inputs - outputs) == 0]--+
                                     |                                    |
[input amt: 5]--                     |                                    |
                \                    |                                    |
[input amt: 5]----[ring signature] --+                                    |
                /                                                         |
[input amt: 5]--                                  [output amt: ?] ----    |
                                                                      \   |
                                                  [output amt: ?]---------+
                                                                      /
                                                  [output amt: ?] ----

I omitted transaction fees in this diagram (irrelevant for this discussion) - the 3 outputs must add up to 7 but the actual amounts are masked. So basically, the inputs to the transaction behave identical to pre-rct transactions, but the amount in each output is hidden.

So no sweep is necessary, until you have unmixable pre-rct unspent outputs. And even then, it is possible to do a transaction/sweep where the amounts in the input ring do not match (but this has not been implemented AFAIK).


How to batch-send multiple transactions

CLI: transfer address_1 amount_1 address_2 amount_2...
RPC: transfer / transfer_split destinations array.

So if you want to batch transactions (though this is a moot point given how low Monero transaction fees are), you must use either standard addresses or subaddresses. You can still use a payment ID, but only one.


How do I utilize blockchain pruning in the GUI (monero-wallet-gui)?

Pruning from scratch or enable pruning going forward
Pruning from scratch or enabling pruning going forward is fairly straight forward. It is done as follows:

Go to the Settings page and switch to the Node tab.

Make sure Local node is selected.

Add the --prune-blockchain flag to the Daemon startup flags box.

Restart (by clicking on the x (right top) and making sure to stop the daemon as well) the GUI to ensure the flag goes into effect.

Pruning is now enabled and will significantly reduce the amount of storage required.
Pruning an existing (synced) blockchain file
First, note that this requires approximately 30 GB of additional storage, as, initially, the Monero software will store both the 'old' non-pruned blockchain and the 'new' pruned blockchain. You can, after verifying that your GUI runs properly, delete the old file of course. The following steps are required to use blockchain pruning:
[1] Make sure all Monero related processes are closed.
[2] Browse to the directory v0.17.1.4 monero-wallet-gui is located.
[3] If you are using a custom data directory, skip step 4 and proceed to step 5.
[4] Run the monero-blockchain-prune tool (on MacOS, you will have to right click -> Show package contents -> Contents -> MacOS on monero-wallet-gui.app in order to see the tool). Note that this may take quite some time to complete. Thus, I'd advise to run it overnight.
[5a] Windows - custom data directory:

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

Type:

monero-blockchain-prune.exe --data-dir path\to\preferred\data\directory (Win 7 + 8)
.\monero-blockchain-prune.exe --data-dir path\to\preferred\data\directory (Win 10)
[5b] Linux - custom data directory:

Open a new command terminal from the directory of monero-wallet-gui

Type:

./monero-blockchain-prune --data-dir path/to/preferred/data/directory
[5c] MacOS - custom data directory:

Go to your desktop.

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

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

Now type:
--data-dir path/to/preferred/data/directory

Note that aforementioned text will be appended to the path of monero-blockchain-prune. Thus, before you hit enter, your terminal should look like:

/full/path/to/monero-blockchain-prune --data-dir path/to/preferred/data/directory
Where the full path is, intuitively, the actual path on your MacOS.
[6] Note that path/to/preferred/data/directory is a placeholder that should be replaced by the actual path. To reiterate, this may take quite some time to complete. Thus, I'd advise to run it overnight.
[7] After the monero-blockchain-prune tool has finished, open monero-wallet-gui and verify that it is running properly.
[8] You can now delete the 'old' non-pruned blockchain file.


Error calling RPC method create_wallet with curl

Are you saying you're asking a node to create a wallet ? A node cannot. A node doesn't deal in wallets, just in blockchain. Ask your local wallet, which in turns talks to the node hosted wherever.


When did Monero switch to 2 minute blocks?

The change occured at hard fork 2, on block 1009827 (see the table near the top of src/cryptonote_core/blockchain.cpp). This was in march 2016.


In ringct, how are the range proofs kept separate from the pedersen commitments in a transaction?

Suppose the sender wants to create a Pedersen Commitment to the amount of 23 XMR for a new output pubkey in a transaction. Without range proof, the sender simply creates the commitment as:

C = a G + 23 H

where a is a random scalar.

With range proof, there's an assumption in the protocol that any committed amount  falls within a certain range; let's say such a range is 0,1,...,31. (In practice it's [0, 2^64), see the code.) Since we can represent the amount of 23 XMR in the binary form as:

23 = 1 + 2 + 4 + 16

The sender creates a commitment as:

C_0 = a_0 G + 1 H
C_1 = a_1 G + 2 H
C_2 = a_2 G + 4 H
C_3 = a_3 G
C_4 = a_4 G + 16 H
C = C_0 + C_1 + C_2 + C_3 + C_4

where {a_i} are random scalars.
The idea of range proof is that the sender knows a private key of either C_i or C_i - 2^i H. Therefore, the sender can prove that the committed amount falls within the range [0,32) by generating 5 ring signatures containing two pubkeys each:

R_0 = {C_0, C_0 - H}
R_1 = {C_1, C_1 - 2 H}
R_2 = {C_2, C_2 - 4 H}
R_3 = {C_3, C_3 - 8 H}
R_4 = {C_4, C_4 - 16 H}

Borromean ring signature is suitable here for reducing the signature size.


I made up a payment ID when sending, will it go through?

If your exchange allows you to input a payment ID somewhere, they should be dealing with it appropriately. This means they should ensure it is the correct length / format and they should set it on the transaction correctly. When you executed the transfer, the exchange should also have given you a transaction ID which you can search for on a blockchain explorer such as xmrchain.net. Lastly, including a payment ID does not affect the destination. Whether you included a payment ID or not, your recipient should still receive the funds.


Are deducible monero transactions blackballed by default (or is there a need or plan to do so)?

There is code to do this, but it requires the database to be created, and this is a fairly heavy process.

You can do so by running monero-blockchain-blackball --inputs ~/.bitmonero.lmdb (on Windows, replace that path with wherever the blockchain is). This can be run every now and again (there is an incremental mode patch on github which will make it a lot faster to be run periodically).

There is no publicly available blackball database at this time. If you use a third party's database, it might lie, and therefore cause you to select outputs which are known spent, rather than the opposite, so you should only use a database from a trustworthy source (possibly yourself). It is possible that the Monero core team will make such a database available for download in the future.

Note that the vast majority of the 0 mixin transactions used pre-ringct outputs, so current transactions will not use them, even if the blackball database is not set up.


You may now start monero-wallet-cli. What should do I next?

I was need to start my wallet 1st and then typed: 'start_mining 4'
It solved my problem started mining with using 4 CPUs, don't need add command from 'monerod'


Why do we use different H values in a vector Pedersen Commitment?

It is correct that using the same H each time would be perfectly hiding. However, the job of a Pedersen Commitment is not only to hide, but to commit.

If you used the same H each time, then all you would be committing to would be the sum of all components. You could later pretend that you had committed to a different number of components or to different component values as long as they still added up to the same amount.


Why is the number of total block confirmations different in different pools?

This is arbitrary, and the pool chooses what they are confident with.

Some number of confirmations are needed to ensure the pool really has the mined monero before they pay miners. If a pool were to pay miners as soon as it mines a block, it would risk that block being orphaned (ie, another block takes its place on the chain), and it would have paid money that it does not, in fact, have, causing monetary loss to the pool. Since it becomes harder and harder to orphan a block as it gains confirmations, waiting fixes that problem.

Another reason for most pools to wait for 60 confirmations is that coinbase tx outputs are locked for 60 blocks, so those new monero are unusable for 60 blocks after mining. If a pool wishes to pay miners before 60 blocks, that pool has to have enough other monero to cover those young blocks.


If I'm running a full node and wallet on my local network can someone get my wallet information?

Just getting connection to your WIFI would not instantly allow someone to see your wallet information, gaining access to your WIFI is only allowing first and foremost access to your internet connection.

However, someone with access to your WIFI could essential hyjack your information, if a few other things fall into place first.

If your WIFI router is set up as a Home/Work Network and Network sharing is turned on, then a hyjacker, could potentially view any files/ documents shared on your network. Your computer would have to also be set-up, to share files with the Home/Work Network, therefore, if for whatever reason you stored your wallet information on a non-encrypted file, then the hyjacker would aslo be able to access this information.
Another method to gain access to your wallet data is through: packet-data sniffing; if a hyjacker has gained access to your WIFI, and they have hacking knowledge (pretty basic hacking knowledge in all honesty) then it is possible for the hacker to "sniff packets" of data that you send over your WIFI, if at any point you send your private wallet data over the WIFI, then it is highly likely that the hacker will be able to see your private wallet information that you have sent through the WIFI.

To ensure your WIFI is secure:

Ensure your router has a Strong and Unique WIFI password.
Ensure your router firmware is upto date.
Enable WIFI encryption WPA2 if your router is newer than 2006, else WPA should be adequate but less secure
Change your WIFI SSID (Name) to make it less easy for the hacker to directly relate the network to yourself and/or allow the user to identify the brand of router that your network uses.


Could IPFS (InterPlanetary File System) be used with Monero?

I'm going to attempt to answer the two parts of this question, but with the caveat that the second half of my answer is certainly at least in part opinion based.

Could IPFS be used with Monero's blockchain?

Yes. In theory, any blockchain could be used to store non-transaction-related information, and tokens could even be involved in such a storage scheme so as to incentivize such actions in some manner. In Monero's particular case, the TX-Extra field could probably be adapted to include extra data (right now it barely allows more than a few words of information, so we're talking a massive expansion of that field or the introduction of some new field.
Or, is there even a point to this?

With the caveat that this is highly opinion based, this would be a terrible use of the Monero blockchain. On the Monero Design Goals roadmap, there are a number of examples of potential future sidechains and daughterchains that could expand Monero's reach beyond monetary exchange, including a decentralized DNS service that is loosely related to this question.

However, to actually store what amounts to a permanent, distributed backup of all web content is both a ridiculous notion, given the shear quantity of information on the web, and not at all desirable. Why do we need a permanent archive of all blog posts, reddit discussions, cat memes, and other things that come and go? The IPFS site specifically states:

  Remember GeoCities? The web doesn't anymore. It's not good enough for the primary medium of our era to be so fragile.

Quite frankly, the reason GeoCities is lost in the depths of internet past is because it no longer served a purpose. With IPFS, it would be part of a permanent record, a website graveyard of sorts, that would be with us forever. Why do I want this, exactly?


I'm sure this reasoning is along the lines as saying:

I think my employer can't be trusted. I get paid, but they don't allow me to see my colleagues pay checks.

The important thing is to know is your hash rate. Try a few open source variants to get a base line average of your hashing power. Use available mining calculators such as this one to know what you can expect. Depending on the payout scheme this may not always be accurate, but it is a start.

Lastly, read reviews on mining pools. Try some out for a week or two to see where you make the most coin.

They can certainly prove they paid you if you didn't receive the funds. More info here


Running a Monero Node on Linux (Ubuntu 16.04) with no incoming connections

If you run a node and do not open inbound connections, then you cannot relay other users transactions or relay blocks. So having a full node in this scenario wont be helping the network. However, it is still useful for yourself, as it increases your security when creating and relaying your own transactions.

It's also worth noting that even if you do not specifically open-up/forward inbound connections, any p2p nodes your node initiates a connection to, can still sync blocks and receive transactions from you.


A code freeze wont prevent you from mining correctly. I suggest ensuring you are using a miner and pool that supports the current Monero hashing algorithm and ensure you have configured the miner correctly, as if you are getting shares rejected, this is the first place to look. But no, nothing to do with a code freeze would cause this.


How to increase CPU cache on Raspberry Pi?

You can't increase the CPU cache... For faster CPU performance a better CPU should be used.

Using a higher swapsize could be interesting but doesn't affect the CPU cache nor the hashrate...


How does a third-party verify that I have the XMR to make a payment?

According to Section 4.3 of the CryptoNote white paper, transactions aren't directly signed by the sender's spending key. Instead, they are signed by the private key goes with the one-time public key.

For example, suppose Alice sends Bob 5 XMR via pub, a generated transaction public key. Bob can see that pub is for him using his private keys. Whenever Bob wants to use this XMR, he generates the private key, priv, using his keys and the transaction's random data. He signs future spending of this money with priv.

I think Alice can see that priv was used. However, she cannot uncover priv. Also, she cannot see the recipient of the transaction because it is sent to a new generated public key.

Moreover, assuming no other income, Bob cannot send 6 XMR to Carol. Nodes assert this by checking where a transaction's XMR come from via pub. That is, a node would see that pub is only for a transaction that moved 5 XMR and thus cannot sign a transaction for 6 XMR.


Using a main address or subaddress, the result/act of churning is the same.


monerod, the Monero node, should not exit once it's synchronized. Maybe a bug caused it to crash. If this is so, please include any error messages or logs or console output.

As for the start_mining command, it takes a first parameter for the Monero address you want to mine with (the address to which any block reward will be paid to), and an optional number of threads to use (you want to ensure each thread has at least 2MB of cache memory to use).

For example:

start_mining 4xxxxxxxxxxxxxxx 2

This will start 2 mining threads, paying to 4xxxxxxxxxxxxxxx.

Note that this is solo mining, and the time between getting blocks can be pretty large if your hash rate isn't so good. If you have low hash rate, consider pool mining, unless the high variance doesn't bother you. In the long run, the payout is about the same.


A SHA-1 collision has been found. Does that mean the Monero repositories on Github can be compromised?

It'd need to wait for git to implement stronger collision resistance. Work is underway for this: http://www.metzdowd.com/pipermail/cryptography/2017-February/031606.html

However, Linus (original creator of git) thinks it's not that easy to exploit in git: https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL


What does Monero's scaling roadmap look like

I know Monero is dynamically scalable, but everyone knows that simply increasing blocksize does not make a blockchain scale.

Saying "everybody knows" doesn't really cut it. Who can say what kind of hardware will be available by the time usage of Monero network gets to the point where Bitcoin is today. It's really not possible to answer this honestly without backing it with proper research and hard data. The only thing we can say is that blockchains are horrible at scaling but they can scale. However, that doesn't mean we shouldn't consider 2nd layer solutions.

Maybe reading this post from a well known contributor hyc would provide some better insight.

  Nodes will still need to download the entire blockchain to function. The more transactions happen, the faster this will grow.

Some data like range proofs can be pruned, but that would only help storage but not bandwidth. Storage is cheap and practically unlimited. Network bandwidth, however, is not so focus should be there.

  Bitcoin is trying to solve this with Segregated Witness, to make each individual transaction smaller.

That's a misunderstanding, see here.

    Since signature data (witness data) is stored outside the transaction (and outside the standard block), it means that that data doesn't have to be counted towards the block size.

The main thing SW fixes is TX malleability which Monero never had to begin with, and which is required to make 2nd layer work. Yes, it will increase TX throughput but that's because the network will accept some extra data along the 1MB block but the data still has to be transmitted and recorded. Trick is, that extra data is going around the block size cap, but the total amount of data per block cycle will now be bigger than 1MB.

  I'd like to know how much bytes are needed now (on average) for each transaction, and what the roadmap is to decrease these transaction sizes (or go Lightning like Bitcoin).

For a normal TX it's about 13kB. That's about 25x normal Bitcoin TX IIRC. There are some optimizations to range proofs being worked on by Luigi, so the TX size could drop by 50% (preliminary estimate). At the same time, multi-signatures are being worked on, which is a pre-requirement to enable 2nd layer solutions if I understand correctly.

Another optimization is regarding block propagation, which is being tested at this time. It's similar to "compact blocks" in Bitcoin and should reduce the bandwidth footprint.

For long-term, there's the "Design and Development" road-map, which hasn't been updated in a while but can give you some idea. Another idea which has been mentioned was sharding the blockchain, but there's nothing of substance as of now.

Again, nothing is being worked on currently, but seeing how other projects are experimenting with solutions like lightning network, I believe this project will use some of those solutions as well in the future. Thing is, there's no urgency considering that level of adoption is nowhere close that of Bitcoin. I guess it can be the next research goal after multi-signatures are rolled out.


You would end up paying the transaction fee.

In every cryptocurrency I know of the sender submits the amount they want to the send to the network PLUS the fee they want to spend. The receiver gets the amount you wanted to send and the miner of your block takes the fee you put up, provided it is high enough.

So yes, if you send $20 of monero with a 10$ fee, you'll end up $30 poorer.


Why are the last 4 trxs in the mempool stuck?

From what I have heard those tx's were created with the 0.10.0 wallet and therefore used the deprecated ASNL signatures. After the ringCT hardfork the 0.10.1 software is a minimum requirement. Tx's created with older versions will not be included in blocks.


How are spend/out/in proofs sent to verifiers?

You can use email, or a USB stick, FTP, pastebin sites... It doesn't matter how you send that information, as long as it arrives verbatim.
The wallet saves the proofs as binary by default, but if you're going to transfer that data via text protocols which aren't 8 bit clean, you can switch it to ASCII export (using "set export-format ascii" in monero-wallet-cli).
These proofs should not be in the transactions, otherwise they'd necessarily be public, which would defeat the purpose of being private by default while being to prove particular things to a particular party.