How long should the GUI wallet take to synchronize? This is my first question (on any StackExchange), so sorry if it's 'stupid' or already answered somewhere else.

I've just downloaded the beta GUI wallet (MacOS) and it is now 'sychronizing blocks' (with a progress bar in the bottom left corner) but it seems to be doing so incredibly slowly. How long would you expect this to take (HDD, 8GB RAM)?

Is it downloading the entire blockchain? If so, does that have to be done? I'm comparing it to Electrum for bitcoin which works without having to download the entire blockchain.

I'm happy to download the blockchain if that's required, I guess I just want to know if its necessary and whether my slow synchronizing is betraying a different problem.

Thanks!

It is significantly slower with an HDD compared to an SSD. Bandwith is also a significant factor.

Yes, if you clicked on the defaults, then you are downloading the entire blockchain. See this exchange for details on the necessity, and this one for light clients (like Electrum).

A very vague approximation would be 24h ( ~80% margin of error :) ). Currently, the blockchain size is ~10GB.


How does OpenAlias compare with NameID? How does OpenAlias compare with alternatives such as NameID

Which alternative does better at attempting to complete Zooko's Triangle?

Can either OpenAlias or NameID assign aliases based on subdomains?

Which system is more resistant against:

Trademark claims?
Hacking?
Attempts to breach the desire of the owner to keep their identity private?

Since OpenAlias supports Namecoin-based identities it has the exact same properties as NameID. The primary advantage to OpenAlias is that it avoids the land-rush issue, where someone grabs the alias WaffleTown and then tries to steal payments destined for WaffleTown. Instead, WaffleTown could provide something like payments.waffletown.com, without needing to care about the blockchain-based / decentralised scheme.


How can monero remain private in a soon to be virtual reality world? 2016 is said to be the year of virtual and augmented reality as these technologies come to market.

As these technologies are stuffed with a lot of sensors, how do you see a way for us to make payments to, for example, Pokemon Go (trading fluffymon) and remain "private"?

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

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

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

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


What are precomputed blocks? When monerod is initializing, it says Loading precomputed blocks: 1200001.

What are precomputed blocks? Where are they loaded from?

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

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

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


How do I handle "WARNING: You may not have a high enough lockable memory limit, see ulimit -l"? Upon running monero-wallet-cli after a fresh master build of Monero 'Boron Butterfly' (v0.14.1.0-5fbfa8a) I received the message:

  WARNING: You may not have a high enough lockable memory limit, see ulimit -l.

I tried it out.

$ ulimit -l
64

The 64 refers to KB.  I'm not sure what to do though.  I have about 8 GB of RAM.  htop reflects usage of 307M/7.72G. This Linux box doesn't do much else besides act as a node. Should I increase the operating system's ability to lock more RAM?  How far should I go?  What are the consequences of making such a change?  Can I make the increase only available to monerod or monero-wallet-cli?

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


Saving hashes of data in Monero blockchain It is possible to store some information in the Monero blockchain that isn't strictly related to a cryptocurrency transaction?
For example, let's say I have a txt file, I calculate its SHA1 hash and then I create a mock transaction (maybe between two wallets which I both control) to insert that hash inside the metadata. Later, when it is confirmed by the network, I can go to some explorer (e.g. https://moneroblocks.info/) and look inside the right block to check it out, and it will stay there forever (at least as long the monero blockchain continues to exist).
I was wondering if a thing like could be applicated, or, because Monero expose very little data -basically only the fee payed to the miners- it's just structurally impossible.

It's possible to store arbitrary data in the tx extra field. You'd have to manually construct your tx though (no wallets allow for this) and block explorers will only show the hex data of it, if at all.


I now get the message "monero-core" is not responding I applied the update monero.gui.0.16.0.3 from monero.gui.v0.16.0.2 on Zorin 15.2 and followed the instructions for a new installation
from your website.

The issue was resolved by starting the GUI as follows:
QMLSCENE_DEVICE=softwarecontext ./monero-wallet-gui
QMLSCENE_DEVICE=softwarecontext is basically a fallback mode with respect to graphics. It can be utilized in case the 'default graphics' do not properly support the rendering of the GUI.


how to cpu mine on arch linux after installing monero-v0.10.3.1? I use Arch Linux and installed monero-v0.10.3.1, started monerod and also created a wallet.

How can I start CPU mining?

Do I need additional tools?

Open the monero daemon (monerod) and type start_mining followed by your wallet address and then the number of threads.

For example:

start_mining 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A 4

This would start mining with 4 threads to the monero donation address. However this is solo-mining and it is unlikely unless you have high hashrates to actually find a block so I would recommend you join a pool.

A list of pools can be found here:

http://moneropools.com/

http://chainradar.com/xmr/pools

And a guide to mining to pools can be found here:

https://www.reddit.com/r/MoneroMining/wiki/index

https://www.cryptocompare.com/mining/guides/how-to-mine-monero/

It should be noted that mining to a pool requires additional software:

Confusion over Monero Mining Software

https://www.reddit.com/r/MoneroMining/wiki/index/windows-pool


When is it safe to confirm the transaction? I am trying to make a monero payment receiving platform and I've found out that it takes about 30-40 minutes for the transaction's height to be 10, which then will the payment be released to me.

For small payments like >USD 10, I think i will accept the transaction when the height is 3 or more.

How much is the possibility for the transaction to be reversed when the height is 3 and 5?

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.


How would Monero verify transactions on a 2-way pegged sidechain? From my understanding, in order to retrieve tokens on a side-chain, you would have to send your XMR to some address that would then be unlocked when you burn the side-chain tokens.

How could Monero verify that anything has actually occurred on the side-chain and unlock the XMR?

dEBRUYNE answered the following in relation to a side-chain question:

  To prevent issues with the mainchain we would have to implement a
  cryptographic proof, i.e., the amount of XMR that went into the
  sidechain would have to be equal to the amount of XMR that goes back
  into the "mainchain".

I guess I'd like a little more explanation of what the cryptographic proof would be / how it would be implemented?

The proofs would be 1) a multisig 2-2 transaction initially created on the main-chain and 2) the multiple parties signing (to spend agreed balances) at settlement. What happens on the side-chain is irrelevant to the main-chain as all it need care about is the XMR are locked up in the 2-2 multisig and at some point they may be spent (so long as the signatories agree, e.g. sign).


Can i receive payment from bittrex without payment id? I created offline paper wallet from moneroaddress.org and i gave me no payment ID.

 asks for payment ID.Can i receive my funds from Bittrex just using my public address without payment ID?

You don't have to use a payment ID when you're sending to your own wallet. Thus, simply put your wallet's address in the Base Address box, specify a Quantity, and leave the Payment_ID box blank. More information about use cases of the payment ID:

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

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

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

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


Why are there many Monero addresses starting with 4JUdGzv...QvVCjZb? So far I've found:

4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkNrSqtCoRUrEDAgRwsQvVCjZbRx8NCvspxJMRJcG69H
4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkNrSqtCoRUrEDAgRwsQvVCjZbRyrP3MvTGHZ5ASzpW8
4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkNrSqtCoRUrEDAgRwsQvVCjZbRydwE9i8Yg26PQWw8e
4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkNrSqtCoRUrEDAgRwsQvVCjZbS31oxhFoqyC1zg7KGP

These come from:

my XMR deposit address at Poloniex
the donation address at www.monero.how
a random post at forum.bits.media
a random post at YouTube

They're all Poloniex's deposit address. The bit at the end is the payment ID used to identify the depositor's Poloniex account. You can read more about integrated addresses here: What is an integrated address?


When a 8-byte block address generation is less than 11 characters. Do you add 1 to be start or end of the block? When generating a monero address and one of the 8-byte blocks is less than 11 characters, it states I can pad it with the character 1. Do I always add 1 to the beginning of the block output or at the end?
if a particular block converts to <11 characters, the conversion pads it with "1"s (1 is 0 in Base58)

Monero base58 is not like Bitcoin base58, bytes are converted in
8-byte blocks. The last block can have less than 8 bytes, but at least
1 byte. Eight bytes converts to 11 or less Base58 characters; if a
particular block converts to <11 characters, the conversion pads it
with "1"s (1 is 0 in Base58). Likewise, the final block can convert to
11 or less Base58 digits.
Due to the conditional padding, the 69-byte string, like Monero
addresses, will always convert to 95 Base58 characters (8 * 11 + 7);
where 7 is length of the last block of 5 bytes.
The alphabet is composed of 58 characters visually not similar to
avoid confusion, e.g. both 1 and l are not part of the alphabet
together, only 1 is present. The full alphabet is composed of:
123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

Address:
43pQ9h9F7KBFgDpFB1aa9ZAvqbxXa7zixfuFAUoybXzbnsy89jVH4YUG8Wwn1BzSFir8WGMkxHpq91XVNhcaaF27UsGFQw
[18, 57, 233, 247, 246, 39, 189, 38] -- Generates: 43pQ9h9F7KB
[87, 190, 79, 202, 198, 114, 137, 252] -- Generates: FgDpFB1aa9Z
[59, 91, 105, 62, 142, 212, 126, 5] -- Generates: AvqbxXa7zix
[4, 2, 134, 215, 55, 25, 186, 141] -- Generates: fuFAUoybXz (only 10 characters)
[208, 0, 122, 244, 178, 147, 68, 205] -- Generates: bnsy89jVH4Y
[162, 251, 100, 144, 167, 8, 96, 108] -- Generates: UG8Wwn1BzSF
[250, 47, 237, 93, 107, 240, 113, 30] -- Generates: ir8WGMkxHpq
[47, 226, 16, 79, 77, 51, 197, 105] -- Generates: 91XVNhcaaF2

Do I always add 1 to the beginning of the block output or at the end?

The end start of the block.
After much discussion with rbrunner on Reddit, it turns out the padding is at the start.


What is the best way to mine Monero on Macbook Pro? I have started mining Monero using the MineXMR pool and an XMRig miner. I have done some calculations and found that, at my current rate of roughly 800H/s, it would take me four years to mine one coin. Am I missing something? Is there a way to optimise this without investing in specialised equipment CPUs etc? I would be grateful for any help on this.

Please note that I am using a MacbookPro with a 2.3GHz processor and 8GB memory. Preferably, I want to increase my mining rate solely with this hardware.

Just like your laptop won't be particularly good at rendering large amounts of video/audio, playing the latest video games or compiling large codebases, it's not going to be very good at mining. One can build a desktop PC for less than a $1000 that will mine at ~14kh/s - that's not a particularly "specialized" PC. Using a laptop for mining 24/7 is not the smartest move either as it will struggle to keep cool and shorten it's lifespan.


What is 'smart mining'? I'd like to learn more about mining Monero and I heard about smart mining.

How does 'smart mining' differ from regular mining? What are the trade-offs involved?

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

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

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

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


How do you force create a new monero address on coinomi? A withdrawal from an exchange has been pending and I need to make a second withdrawal but I don't wan't to link to the first by sending to the same address. Is there any way to force coinomi android to create a new address before receiving a payment? What about just opening monero core and creating a new address with the same seed. Will coinomi pick it up?

It appears that pressing the refresh symbol by payment id creates a new address and random payment id. Can someone confirm this is the correct way to send a second payment to coinomi as I thought payment id was being redacted by monero.

Also, on the Monero Gui client (non-coinomi), is it possible to remove added accounts or addresses that are unused. Like if I created 10 accounts, can I delete 9 from the GUI without reinstalling?

Here is the official coinomi response:
If you need a completely separate address for this monero TX then you can add a second wallet from +coins. In Coinomi you cannot select which UTXOs are spent in each transaction, this is automatically done by the app.

The 'refresh' icon on the receive page, creates an integrated address - this address is the same receive address with a payment ID attached.

Monero Core/Coinomi: you can use the recovery tool listed at the bottom of our recovery guide for converting your Coinomi phrase to be used in the monero wallet. However, this is not needed since you can add a second XMR wallet in Coinomi (+coins) or simply just use the one address. - You will be happy to know that we have plans to add XMR sub-address support in the future too.

Hope this helps

Kind Regards,
Coinomi Support


Why does Monero prevent transactions from being spent without 10 confirmations? When I receive monero they are unavailable to be spent for 10 blocks because of the CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE (Required confirmations before newly received Monero can be spent).

Why is this the case?

With other cryptocurrencies the receiver can decide when to use an output again. With Bitcoin, the network even accepts unconfirmed inputs.

If the spendable age makes Monero insecure why is that the case?

What is the reason 10 confirmations was chosen as the spendable age requirement?

Cryptonote is more sensitive to reorganizations than Bitcoin.

In Bitcoin, if N blocks are reverted, all the transactions they contain are now ready to be mined again (or might already be included in blocks that replace those N blocks).

In Cryptonote, if N blocks are reverted, any transaction that include an output created in those N blocks is also (probably) invalid, since outputs are refered to by their index within an amount. This means those transactions will be rejected, and will have to be recreated. Bear in mind that, due to ring signatures, the recipient of a coin is not the only one to include it in a subsequent transaction. Third parties also do.

Now, there are ways around that. The simplest is to prevent outputs from being used within a given number of blocks. Another would be to include public keys of inputs in a transaction, instead of indices. This would increase the size of a transaction markedly, though an optimization could be made when storing the transaction (turning public keys into their index). However, this is a bit complex, since you have to keep the public keys for a while, in case those outputs end up in a reorg.

As a last point: this has to be both a wallet and daemon rule, otherwise someone would be able to tell whether an input that was created very recently is the real one or not.


What is the Bikercoin currency? Bikercoin is a new currency (released on June 7th 2016) based on the CryptoNote protocol.

What are the major differences between Bikercoin and Monero? What source code are they forking from?

Since this is a Monero stack exchange I'm not going to go too deep into what differentiates Bikercoin from Monero. However, a quick examination of their listed GitHub repository indicates that it is indeed a fork from CryptoNote.

The commit history indicates a substantial number of adjustments (including change donation) and there are currently no pull requests in place which indicate a largely solo or small team effort.

Given the overall level of activity and network effect on the back end it seems prudent to dismiss this as a simple alt-coin that doesn't add much value to the Monero ecosystem.


Understanding Monero addresses in the wallet GUI I tried to read a Monero guide but I don't understand some things.
I have addresses that start with 4wzx, 8AAA and 8sgs in Accounts and 8AAA and 8gjm in Receive. Why are 8AAA and 8AAA the same, but 8sgs and 8gjm different? To which address will money belong if someone sends Monero to the 8gjm subaddress?
Can I send money to the Accounts subaddress and the other address? Or maybe I should use only Receive subaddresses?
What's the difference between Accounts subaddresses and Receive subaddresses?
Thanks.

A wallet has a primary address (that starts with a 4) and can have any number of subaddresses (that start with an 8). Accounts are just an abstraction which allow subaddresses to be separated - you could create one account for your savings and one for daily spending for example.
When someone sends you XMR to an address, it is sent to that address. The wallet that the address belongs to can then spend the received XMR.


My blockchain is stuck, how do I "unstuck" it? During the last few weeks a common, reoccurring, question seems to be how to get one's blockchain "unstuck". This guide will, hopefully, provide some assistance in doing so.

Note that, if you are stuck on block 1288639 (or block 1400001) or a few blocks later, you are using a wrong, outdated, version and you should upgrade to the latest version, which can be found here. In addition, this won't require a resync from scratch, as the "new" monerod will automatically use the blockchain that was used with the previous version and pick up syncing where it left off.

The first step in getting your blockchain unstuck is making sure that no Monero related process is running anymore. Thus, close the GUI by clicking on the x and make sure to stop the daemon as well. If you're using the CLI, type exit into both monero-wallet-cli and monerod. Thereafter, use your task manager to check whether all Monero related processes are closed. Alternatively, you could simply reboot.

Now that no Monero related processes are running anymore, delete p2pstate.bin. On Windows it can be found in the following directory:

C:\ProgramData\bitmonero

Note that, by default, the ProgramData directory is hidden. Therefore, use the explorer to manually navigate to aforementioned directory.

On Linux and Mac OS X:

$HOME/.bitmonero

This directory is hidden by default too. On Linux you can use CTRL + H to unhide directories (note that this might not work on all Linux distributions), whereas on Mac OS X you can use cmd-shift-dot unhide directories.

After you've deleted p2pstate.bin you can restart monerod / the GUI. If this didn't resolve your issue, please read further and make sure monerod / the GUI is closed again.

We're going to add the following flag:

--block-sync-size 10

This will change the batch of fetched blocks from 20 to 10.

You can add the flag as follows:

If you are using the GUI, simply add --block-sync-size 10 as daemon startup flag. You can do this on the Settings page of the GUI. Note that you'll have to restart the GUI + daemon for the flag to take effect. Thus, add the flag, exit the GUI and stop the daemon as well, and lastly restart the GUI + daemon.

If you are using the CLI, please see below.

On Windows make sure to launch it from the command line. Go to the folder monerod is located and make sure your cursor isn't located on any of the files. Subsequently do SHIFT + right click and it will give you an option to "Open command window here". Lastly, type the following command:

monerod --block-sync-size 10

On Linux and Mac OS X you should use the terminal to launch monerod. Note that this has to be done from the directory monerod is located in. The command is as follows:

./monerod --block-sync-size 10

If your blockchain is still stuck after adding this flag, please browse again to C:\ProgramData\bitmonero (Windows) or $HOME/.bitmonero (Linux and Mac OS X), open bitmonero.log and check it for any errors. If you see any of these errors (or similar to them), your blockchain is most likely corrupted and you need to resync from scratch.

Error opening database: Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid

Failed to parse and validate tx from blob (per MoneroMooo: This can be a corrupt blockchain, if this comes from a block inside the db. However, it's much more likely to be an old version not knowing about a new fork)

This is done by deleting data.mdb from C:\ProgramData\bitmonero\lmdb (Windows) or $HOME/.bitmonero/lmdb (Linux and Mac OS X), which will trigger the resync.


How to check payments and process new deposits Is there a method for checking payments within one account in addition to get_bulk_payments?

We have a lot of payment_id to check, and day by day the request is longer and longer.

Is there any method to avoid this and to get the incoming payments?

Take a look at get_transfers. It has many options for filtering your transfers.


Could not find Boost libraries or Version is too old I tried to compile Monero Core for Debian platform, but I got this error

Could not find Boost libraries, please make sure you have installed
Boost or libboost-all-dev (1.58) or the equivalent.

What should I do in order to resolve this problem?

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

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

decompress the archive

tar -xf boost_1_58_0.tar.gz

then navigate to the folder

cd boost_1_58_0

and run the bash script for configuration of building Boost

./bootstrap.sh

Finally compile!

./b2

Install by sudo ./bjam install

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

make clean
make


What technique(s) should be used to secure funds in my wallet(s)? So I know that there might not be a straight forward answer besides having a cold and hot wallet available that you can access with your own daemon and simplewallet. But I feel like there might be more ways/techniques that some of you might do  to better secure your funds.

So how many cold and hot wallets do you have and how should you distribute your funds amongst them, or do you? Do you give the wallets really obscure names on simple wallet? Super long and random passwords? Or is none of these super paranoid tactics really worth it for monero?

The first line of defense: use a secure operating system. This means no Windows, no running random binaries (except below), and keeping patches up to date. If you know how to use them, use VMs, and do all risky stuff on VMs, not the host.

When you've done that, backup your wallet/seed, use a complex password for your keys file.


I cannot start monero-wallet-rpc. I receive the error: no connection to daemon I can't start monero-wallet-rpc. I received an error: ERROR wallet. RPC Src / Wallet / wallet_rpc_server. cpp: 3443 wallet initialization failed: no connection to daemon. Thanks.

Firstly, you have to be running monerod for monero-wallet-rpc to work.

Next, if you start monerod with --stagenet, you have to start the wallet with --stagenet also. If you create a wallet for mainnet, it won't open on stagenet, same as for testnet. You cannot mix networks / daemons / wallets.

Next, you only need specify a rpc-bind-ip if you will be connecting remotely to the wallet RPC or daemon RPC. By default they listen on localhost so if you want to allow remote connections, you must specify an IP address they will bind to.

So, with all this understood, a setup with locally accessible only daemon and remotely accessible wallet RPC running from the same host, and both with their RPC's requiring login, you could start like:

monerod --rpc-login daemon-user:daemon-pass --detach

monero-wallet-rpc --rpc-bind-port 18089 --rpc-bind-ip 0.0.0.0 --confirm-external-bind \
  --rpc-login rpc-user:rpc-pass --daemon-login daemon-user:daemon-pass \
  --prompt-for-password --wallet-file my-wallet

If you add --stagenet to one, add it to the other too.

Here's a variation which will allow both of these RPC servers to be externally accessible and using non-standard ports for demonstration:

monerod --rpc-bind-ip 0.0.0.0 --rpc-bind-port 18088 --confirm-external-bind \
  --rpc-login daemon-user:daemon-pass --detach

monero-wallet-rpc --rpc-bind-ip 0.0.0.0 --rpc-bind-port 18089 --confirm-external-bind \
  --rpc-login rpc-user:rpc-pass --daemon-login daemon-user:daemon-pass \
  --daemon-port 18088 --prompt-for-password --wallet-file my-wallet

Lastly, all these flags are documented:

monerod --help
monero-wallet-rpc --help


RingCT migration to Borromean Ring Signatures and testing With the recent discovery of a bug in the original ringCT code, and the subsequent update from using ASNL to Borromean Ring Signatures, how much testing has been done since that change, and what kind of fail safes are in place in case another bug is found and there is not enough time to patch and test the code? Is it at all possible to avoid the hard fork if it ever comes to that?

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


What is the fastest way to synchronize the daemon? Running the daemon without any modifications can take a long time to synchronize. Are there any faster options for synchronizing the daemon with the network?

The fastest way to achieve this, is to download the current blockchain and import it into the daemon:

Step 1: Move into the folder where you downloaded the Monero Gui Wallet, e.g:
cd ~/Downloads/monero-gui-0.10.3.1-beta2

Step 2: Download the raw block chain from a trusted source, e.g:
wget -c --progress=bar https://downloads.getmonero.org/blockchain.raw

If it fails half-way, just re-run it. The above command will continue where it left off.

Step 3: Import the downloaded blockchain into the daemon:
./monero-blockchain-import --dangerous-unverified-import 0 --input-file ./blockchain.raw

Do remember though, run with --dangerous-unverified-import 0 only from a trusted source like the above. The option was previously called either --guard-against-pwnage and --verify

Step 4: You can now remove the raw blockchain to free up disk space:
rm -rf ./blockchain.raw

Step 5: You can now start the Monero daemon, either from Settings in Monero Gui Wallet, or directly from the terminal in detached/background mode with:
./monerod --detach


How necessary are transaction fees? How necessary are transaction fees? Why isn’t the block reward enough to maintain a community of miners?

Two main reasons:

The block reward is going to decrease over time, and even in Monero where there is a tail emission (i.e. the emission rate bottoms out at a nonzero value) the block reward isn't guaranteed to be greater than electricity costs.
Transaction fees allow miners to prioritize more important transactions if the network is congested, because people will generally be willing to pay more for more important transactions. Transaction fees also will reduce demand for block space during such periods of congestion, because the transaction fees will increase in response as users have to out-bid each other to get included in a block.

EDIT: It's also important to note that if posting a transaction has no cost, the demand for transactions has no hard limit. Eventually, people will find more uses for the blockchain (or spam the network with transactions that don't do anything), until the system reaches its limits. When that happens, transaction fees will be necessary to keep demand under control.


How do I manually decode outputs? I'm currently coding a small Monero tool just to better understand how it all works. I already implemented address-generation from scratch (thanks to luigis address test page) and the next step is to scan the whole Blockchain for transactions that have outputs associated with an address. I have found the site xmrchain which lets you do just that for single transactions, like this random one: https://xmrchain.net/tx/a8fdf7a2fb4f153980f7b5b968f54bde375b0484fd897a2f9fb3139a9fe91c46
There, you can click on "decode outputs", supply your private viewkey and address, and it shows you which outputs belong to you.

Unfortunately, all these calculations are done on the server. Could someone explain to me how I would do the same thing manually, with my private/public viewkey, address, and all the transaction data you get with the /gettransactions RPC-call?

The math behind output checking is as follows

When output is created (by the sender), it's created as:

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

where P is the output, H_s the hash to scalar function, r the TX private key (randomly generated by the sender), A the recipient public view key, i the output index in the transaction (|| is concatenation), G the basepoint of the elliptic curve, and B the recipient public spend key.

Thanks to elliptic curve arithmetic, rA == aR holds true, where a is the recipient private view key, and R is the TX  public key. This is what is know as shared secret since only the sender and recipient know it but they never had to communicate it to one another.

When the recipient is looking for his outputs, he's doing, for each TX on the blockchain:

Get the TX public key R, outputs P and output indexes i.
For each index, compute P' = H_s(aR||i) + B
Compare P' == P ?
If equal, it's a match, continue to decode the amount.

For implementation, tha xmrchain block explorer is actually open source and you can inspect the source.

Also, there's a TX checker on Luigi's page, which is another implementation of the above.

Note that PR-2056 will change this somewhat for some cases, so it's worth looking into.


What is the most efficient number of threads to run using a VPS with 32 cores? Is it 64 or will a reduced number be more efficient?

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

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


How do I enable Confidential Transactions? I understood that Confidential Transactions was included in the last fork but not on by default. How do I enable it for my txs?

The code for RCT has been included, but the network still doesn't allow RCT transactions. If my (basic) understanding of the code is correct, starting from the V4 fork, RCT transactions will be performed by default if using software ver. 0.10., so there will be nothing special that you need to do.

However, old non-RCT transactions will still be allowed, for those using ver. 0.9.4., and after V5 fork those will not be allowed anymore and it will be possible to use only RCT transactions. Note that your funds will be safe and there's nothing special you will need to do to "convert" except be running the latest software.

For some details on how/when the V4 fork will be rolled-out, see here.


Is there a coin time lock ability in Monero like the one in Bitcoin? Is there a way to lock my Monero coins for X amount of time into the future? Like how bitcoin has a time lock feature on coins? I want to be able to just put some away and not ever use it until X amount of blocks.

In monero-wallet-cli you can use the locked_transfer command to send money to yourself and lock it for a number of blocks.


Where is the mempool stored? Is the mempool stored on the blockchain? If it is, isn't it then easily possible to have all wallets scan the mempool in order to give immediate updates that a trx was actually sent? Just knowing that a trx is actually sent is a big deal for a receiver rather than have to wait for the tx to be included in a block first which can take some time if the mempool is congested, or if a block takes a long time to be mined.

Actual confirmations is another subject and not what I'm asking.

The transaction pool is not stored on the blockchain: it is the set of transactions that are used to feed new blocks. Nodes store it in memory, and a poolstate.bin file when the node exits.
The wallet currently scans the txpool for new transactions. If you run show_transfers pool in monero-wallet-cli, you will see them, for example. I believe monero-wallet-gui also shows them, but I'm less sure about it.
A useful, but mostly unknown feature in monero-wallet-gui is incoming transaction tracking: in the Receive page, there is a "Tracking" line which will check the blockchain and txpool in realtime for transactions matching the settings (payment ID and optional amount) set above it. If you are on this screen while waiting for your transaction to arrive, you will see that line change as your transaction is seen in the txpool, then in the blockchain.
I'll quote the "Help" link's text here for more information:

This is a simple sales tracker:
Click Generate to create a random payment id for a new customer
Let your customer scan that QR code to make a payment (if that customer has software which supports QR code scanning).
This page will automatically scan the blockchain and the tx pool for incoming transactions using this QR code. If you input an amount, it will also check that incoming transactions total up to that amount.
It's up to you whether to accept unconfirmed transactions or not. It is likely they'll be confirmed in short order, but there is still a possibility they might not, so for larger values you may want to wait for one or more confirmation(s).


Problem with speed of synchronization I have mined 0.1 Monero on MinerGate and since yesterday am transferring it to the wallet. After 24 hours it's got about 20% ... Is this slowness normal ..? It will take about 5 days to finish the transfer.

It really depends on your hardware and its bottlenecks.

With the current 0.10.3.1 release, monerod downloads a lot more data than needed. This could be a bottleneck in your case. Current master version (and the soon-to-be-released 0.11) will use up a lot less.

If your CPU does not have hardware AES-NI, block hash verification will be a lot slower.

If you have a hard disk (instead of a SSD), writes will be a lot slower. For this.

One good thing to try is to run monerod with --block-sync-size 20, it might well help sync speed. Running current master will also help (it includes this for recent blocks).


Go or Rust library to use Monero Is there any library for Go (Golang) or Rust that I can use in order to generate the key pair,  manually build a transaction, sign it and broadcast it to a remote node?

I searched GitHub and either the libraries are unmaintained / don't have all this functionality.

There are generally two approaches to getting Monero functionality into other languages: 1) to make use of the JSON-RPC interfaces and 2) building Monero source files and creating bindings. The former is the simplest and easiest to maintain. The latter gives more fine grained control but requires thought for portability.

Jumping back to your requirements:

  generate key pair, manually build a transaction, sign it and broadcast it to a remote node

Generating keys is fairly simple and can be done without a "monero" library.

Manually building a transaction is not as simple. This requires a running node and wallet file. This is because you will need (amongst other things) to select inputs and outputs. Using the JSON-RPC interface is definitely the best route for this.


How does Dandelion work on old nodes? AFAIK, Dandelion is not a hard-forking addition to Monero. Meaning, there could still be old nodes in the network that do not support it. How does that work? And what impact do old nodes in the network have on Dandelion?
In general, I am interested in learning more about Dandelion in Monero. If you have any links documenting the implementation I would be happy to know.

Dandelion works by setting a flag in the transaction message. If the flag is set, nodes should perform the dandelion steps (ie, decide whether to continue dandelion routing or send to all peers), otherwise not. The existing transaction message format is unchanged.
An old node will not know of that flag, so will understand that message as it used to, and will proceed to send that transaction to all its peers as usual.
This means that if Dandelion supporting nodes are few and far between, the network as a whole will behave much like previously: most txes will get relayed to all peers in short order. Only when most nodes support Dandelion will the effectiveness of Dandelion reach its peak. However, in all cases it will "just work".


How to open a Monero CLI wallet by specifying the wallet name? I have wallet file. How I can open it from command line parameters?

Use the parameter: --wallet-file <file name here>. E.g.

monero-wallet-cli --wallet-file MyWallet

(assuming you have a wallet file named "MyWallet" in the current working directory)


Where in the PoW block header is the variant version? I asked this question: How do miners, connected to a pool via stratum, know when to switch PoW variant during a hard fork?

Which was marked as a duplicate of this question: Can pool miners update early and then the pool software will automatically ask its workers for new POW when necessary?

I cannot comment on this second question as I do not have enough "points". So I am opening a new more specific question.

The answer to this second question is vague and contradicts the block header documentation.

This second answer only says "This is possible because the block template which a pool sends a miner contains the block version number, which is incremented at each fork".

However reading the block header breakdown here: What is the format of a block in the Monero Blockchain?

This states that the major_version is "always 1", and that the minor_version is "now used as a voting mechanism, rather than how this particular block is built".

Is this information correct? What does it mean "a voting mechanism"? Where is the variant version actually stored in the block header? Which field is it stored in? What is the present number of this field? What number will it be after the October hardfork?

The duplicate is correct. Block header version number changes when there is a fork (network upgrade).

  However reading the block header breakdown here: What is the format of a block in the Monero Blockchain?

If you read on in the answer:

  Note that major version is used for hard-fork upgrade counting, as seen in Monero source code (1, 2). Looks like it's not exactly following the CN specification, where it was supposed to be changed only if the header parsing scheme changes.

A miner could alternatively change algorithm based on the current block height, as the fork version changes at a predetermined block height (i.e. when a fork is scheduled, it is done so in the Monero code against a block height).

Either method works.


How are fees computed? Can someone explain the algorithm to compute Monero transaction fee?

I have seen somewhere it is based transaction size (or something called "weight"?), and some other vague explanation. But I would like to know more deeply how it works.

EDIT:
This is basically the same question as How does the dynamic fee calculation work? but the answer to that question looks out of date. I would like to know how it works in the protocol today.

Can someone explain the algorithm to compute Monero transaction fee?

The computation of the current dynamic fee algorithm is explained, in detail, here: https://web.getmonero.org/2017/12/11/A-note-on-fees.html.

  I have seen somewhere it is based transaction size (or something called "weight"?), and some other vague explanation.

"weight" is just another term for size. However, It's not just tx weight that is used in the calculation.

  But I would like to know more deeply how it works.

https://web.getmonero.org/2017/12/11/A-note-on-fees.html


How does one craft a Monero transaction locally, sign with their private key and then broadcast using javascript? I'm looking for the specs to craft a Monero transaction and then sign this transaction with my Monero private spend key. Then broadcast this signed transaction to a node. I want to do this in javascript. Is there an easy to follow tutorial on how to go about doing this?

Monero transactions are much more than some simple data that is signed with a private key. You need outputs to spend, mixin outputs from the blockchain, lot's of math for RingCT etc. This is one of the reasons the RPC interfaces (daemon and wallet) exist. These can be called by any language which can call a URL and create/parse JSON.

If you use the wallet RPC, you can call transfer with get_tx_metadata: true and do_not_relay: true to get tx_metadata which can later be broadcast with submit_transfer (or of course do this all in one step with just transfer, without the aforementioned parameters).

If you just want to understand the math that goes into RingCT, read the MRL-0005 paper, or the broader Zero to Monero book. And if you just want to understand the structure of a transaction, see the Monero source code which defines the structures used.


Is the high transaction fees problem addressed in the upcoming monero v7 upgrade? I've read the official release notes for Lithium Luna but there is no mention of any solution for the problem. At the same time I saw on twitter/forums some devs comment that it is addressed.

Does someone have more information on this topic?

Are there changes in the XMR constants per kb?

Are the bulletproofs comming in the September's upgrade?

Monero's (dynamic) fee structure is very depending on the dynamic block size and the other way round and all changes have to be very carefully evaluated since otherwise the penalty algo for miners increasing block size might get obsolete.

For now, in the v7 upgrade (Monero 0.12) there has been just a quick fix implemented choosing low priority, so 0.25x of the standard fee if these criteria match:

there's no backlog in the tx pool for the low priority fee level
the last N (=10) blocks are not 'almost full' (>80%) (estimated by summing up the last N block sizes and dividing it by N times the current full reward zone)

There were no changes made to the constants per kB in this release and the fee structure is meant to be evaluated for the September hard fork along with Bulletproofs, which will be released if there is no serious flaw found during the currently ongoing external audits.


What prevents double-spending? Let's say I have three outputs that I own:
1st output with 1 Monero,
2nd output with 1 Monero,
3rd output with 100 Monero.

The logic of range proofs supposes that the amount of input Monero equals to the amount of output Monero.

What prevents me from creating two separate transactions that are spending outputs 1st and 2nd (and specifying corresponding Key Images, as usual), both of them are specifying the 3rd output as a "fake input" despite the fact I know all secret info, but the amount of output Monero in both of them, let's say, 90 Monero and 11 Monero are used for "balancing" the entire amount of outputs.

1st (1 Monero) + 3rd (100 Monero) = 4th_Mine (90 Monero) + range proof balancing (11 Monero)

2nd (1 Monero) + 3rd (100 Monero) = 5th_Mine (90 Monero) + range proof balancing (11 Monero)

In these two cases, I spent two outputs that originally had 1 Monero each but supposedly succeeded in creating a total output of 180 Monero.

1st (1 Monero) + 3rd (100 Monero) = 4th_Mine (90 Monero) + range proof balancing (11 Monero)
2nd (1 Monero) + 3rd (100 Monero) = 5th_Mine (90 Monero) + range proof balancing (11 Monero)

Let's call these TX1 and TX2 and lay them out a little more accurately.
The outputs either being spent or created are denoted by oN. Each real spend output appears in its own ring of decoy outputs, dN. For each created output there is a range proof bN.
TX1:
  Input rings:
    [o1, dN, dN, dN]
    [o3, dN, dN, dN]

  Key images:
    k1, k3

  Created outputs:
    o4, o5

  Range proofs:
    b4, b5

TX2:
  Input rings:
    [o2, dN, dN, dN]
    [o3, dN, dN, dN]

  Key images:
    k2, k3

  Created outputs:
    o6, o7

  Range proofs:
    b6, b7

In these two cases, I spent two outputs that originally had 1 Monero each but supposedly succeeded in creating a total output of 180 Monero.

But no. Only one of the above transactions will work, the other will be rejected.

What can prevent me from creating [these] two separate transactions...

The key image k3. As soon as a transaction is seen using kN, no subsequent transaction will be accepted trying to use the same key image. This is our double-spend protection.

The logic of range proofs supposes that the amount of input Monero equals to the amount of output Monero.

Not quite. The purpose of the range proofs are to ensure the outputs are within a non-negative range (e.g. [0, ..., 264-1]), they have nothing to do with double-spending. They aid in the balancing, only so far as to ensure none of the values used are negative, which could introduce a hidden inflation.


Copied blockchain and gui still saying syncing for aeons I've downloaded the blockchain on one machine with the 0.11.0.0 release and then copied that lmdb directory to another machine. Started the gui wallet and pointed it at the lmdb directory but it still looks like it's syncing completely fresh.

The daemon log says synchronised ok. Why doesn't the gui wallet just connect and go?

There are two synchronizations that happen.  The daemon needs to synchronize the blockchain with the network.  It sounds like you did that, and then you transferred the blockchain to another computer.  The next sync is the wallet syncing with the blockchain, where it scans for transactions that belong to it.

If you didn't specify a starting height, the wallet will scan all blocks to ensure there are no outputs destined for it.  If you were to have specified a starting height - since you knew the address was just created - the wallet would have only started scanning at that height, and therefore been done very quickly.


Total Amount Of Monero Wallets Is there currently a way in which to view the total amount of Wallets that have been created for Monero and deposited too?

and/or an estimate located anywhere as to the total amount of wallets created and/or the average quantity of monero inside the average wallet?

There is no way and there won't ever be a way.
This is becasue Monero is unlinkable, meaning no two destinations can be linked together. In other words, nobody can tell where certain Monero went to, so can't really calculate any stats.

This is achieved by utilizing stealth addresses, where the sender generates a one-time destination from the recipient's address. Unlike with Bitcoin, no Monero are actually sent to the stealth address itself (your wallet address never ever appears on the blockchain), but are sent to something derived from it (one-time public key). All the destinations (one-time public keys) look the same and this takes care of the recipient's privacy. The owner of an address is the only one able to know which one-time public keys "belong" to him, by means of a private view key.

The only way to gather some partial stats would be through centralized services such as a web-wallet provider mymonero.com. They can know how much their users received, stored and sent out, because their backend stores the users private view key and updates the balance every time the user logs in (they don't publish this data, though). It's worth noting that these stats could be misleading. The user could spend his Monero by other means (through the standard wallet) and the site would have no knowledge of the changed balance until the user would log back in. Also, he could keep re-sending to himself and the site would see inflated balance, because it would have no knowledge that it's the same Monero going back and forth.


Is mining monero to a subaddress supported? I tried to send coin for a monero address and I tried also to mining this address  but an error message will be displayed :
" Error: subaddress for mining reward is not yet supported!"
How can I support a monero address ?
Can you help me please !

The message is quite clear: you're trying to mine to a subaddress, which is unsupported at the moment. A Pull Request is open to add the feature, but the devs aren't agreeing apon the necessity of it.
If you want to solo-mine XMR, only use your main address and you'll be fine.
However, you should be able to ask a pool too use your subaddress to send your mining reward. If it's a pool issue, then get in touch with the pool owner and ask him to support transaction to subaddresses.


How do fees affect tx priority and how did these specific high fee tx's sit unconfirmed for > 1hr Can anyone explain to me why several high fee (0.1-0.15) RingCT tx's, that did not look abnormal, sat in the mempool for over an hour unconfirmed, while lower fee (.025 ish) similar looking RingCT tx's got processed in front of them and 5 empty blocks were mined?

Unless I am missing something, this seems highly irratonal as far as miners are concerned, and suboptimal in terms of how the network is performing. It was my understanding that that there was such  thing as 'fee priority', but in this instance that does not appear to be the case / is not working as it should.

The tx's concerned were eventually mined in blocks 1226464 and 1226465, and the first 3 characters of the ones i was watching were 230, 2ac, d76 and 56c. The latter was mined in 1226465 and had a fee of 0.15 for a size of 14kb, the others in 1226464 with a fee of 0.1 and sizes of 13kb. Input/output were 2/2,9/2,3/2 and 6/2 respectively.

http://blox.supportxmr.com/block/1226464

http://blox.supportxmr.com/block/1226465

http://imgur.com/8EvtEss - mempool screenshot

Looking forward to an explanation that will deepen my understanding of how the network functions

Thanks

I asked the same question over on reddit, and
although I did not get to the bottom of why these particular txs sat there so long, I did learn several things which may be helpful/interesting for others...

As mentioned by samwellj above and nanoakron on reddit, the PR to prioritise txs by age has only just been merged, so unless all miners have already updated or are using custom software, it is likely that it is not in full effect yet (and was not at the time of these txs), but it is on its way. Nice work, I look forward to seeing it fully implemented in due course.

That answers one aspect of the question - why 'time in mempool' was not a factor in tx processing.

The second aspect regarding fees is a bit murkier. Monero has had a 'prioritise by fee' algorithm for a while now and it functions on a fee per byte basis (thanks smooth for your patience on that one). Currently there are 3 presets in the GUI/CLI to prioritise txs using a fee multiplier of 1x, 20x and 166x. The reasons for the 'super multiplier' of 166 is to pay a fee high enough at times of high load to compensate /incentivise miners to take a block reward penalty and increase the block size above the permitted % over the median, thus allowing the block size to increase faster if people are prepared to pay for it, and allowing any backlog to clear quicker. Very cool.

No firm answer on why these tx's did not get prioritised by fee, and it looks like we are not going to get one, but hey, I learnt plenty along the way and I hope this information is useful to others too.

One question that is raised for me now is how do the 'prioritise by time' and 'prioritise by fee' algorithms interact with each other. Do fees trump time, or is there something more complex at play?

Obviously tx prioritisation has only really come into focus since the HF due to the larger size of RingCT txs and the more frequent though relatively small mempool backlogs. I imagine we have not yet arrived at a final destination here (will we ever!), and that things will be optimised as the system is observed.


Is my ccminer working? Got ccminer to work on my Acer Predator Laptop w/ 1060 Nvidia GeForce
GTX. I'm seeing a lot of retry messages in the miner log and I'm unable to tell if it's working.

When I input my address into monerohash.com it says "Not found". Not sure if that's because I've only been mining for about an hour. Any pointers would be much appreciated.

ccminer -o stratum+tcp://monerohash.com:3333 -u <address removed> -p x
*** ccminer-cryptonight for nVidia GPUs by tsiv ***
based on ccMiner by Christian Buchner and Christian H.
based on cpuminer-multi by LucasJones
based on pooler-cpuminer 2.3.2 (c) 2010 Jeff Garzik, 2012 pooler
BTC donation address: 1JHDKp59t1RhHFXsTw2UQpR3F9BBz3R3cs
DRK donation address: XrHp267JNTVdw5P3dsBpqYfgTpWnzoESPQ
JPC donation address: Jb9hFeBgakCXvM5u27rTZoYR9j13JGmuc2
VTC donation address: VwYsZFPb6KMeWuP4voiS9H1kqxcU9kGbsw
XMR donation address:
(man these are long... single address, split on two lines)
42uasNqYPnSaG3TwRtTeVbQ4aRY3n9jY6VXX3mfgerWt4ohDQLVaBPv3cYGKDXasTUVuLvhxetcuS16ynt85czQ48mbSrWX
[2018-01-01 19:18:12] Using JSON-RPC 2.0
[2018-01-01 19:18:12] 1 miner threads started, using 'cryptonight' algorithm.
[2018-01-01 19:18:12] GPU #0: GeForce GTX 1060 (10 SMX), using 40 blocks of 8 threads
[2018-01-01 19:18:12] Starting Stratum on stratum+tcp://monerohash.com:3333
[2018-01-01 19:18:12] ...retry after 30 seconds
[2018-01-01 19:18:13] GPU #0: GeForce GTX 1060, 314.56 H/s
[2018-01-01 19:18:42] ...retry after 30 seconds
[2018-01-01 19:18:43] GPU #0: GeForce GTX 1060, 179.07 H/s
[2018-01-01 19:19:12] ...retry after 30 seconds
[2018-01-01 19:19:12] GPU #0: GeForce GTX 1060, 162.70 H/s
[2018-01-01 19:19:43] ...retry after 30 seconds
[2018-01-01 19:19:44] GPU #0: GeForce GTX 1060, 172.14 H/s
[2018-01-01 19:20:13] ...retry after 30 seconds
[2018-01-01 19:20:15] GPU #0: GeForce GTX 1060, 168.19 H/s
[2018-01-01 19:20:43] ...retry after 30 seconds
[2018-01-01 19:20:45] GPU #0: GeForce GTX 1060, 170.79 H/s
[2018-01-01 19:21:14] ...retry after 30 seconds
[2018-01-01 19:21:14] GPU #0: GeForce GTX 1060, 160.07 H/s
[2018-01-01 19:21:44] ...retry after 30 seconds
[2018-01-01 19:21:45] GPU #0: GeForce GTX 1060, 169.88 H/s
[2018-01-01 19:22:14] ...retry after 30 seconds
[2018-01-01 19:22:14] GPU #0: GeForce GTX 1060, 162.26 H/s
[2018-01-01 19:22:45] ...retry after 30 seconds
[2018-01-01 19:22:46] GPU #0: GeForce GTX 1060, 173.16 H/s
[2018-01-01 19:23:15] GPU #0: GeForce GTX 1060, 262.47 H/s
[2018-01-01 19:23:15] ...retry after 30 seconds
[2018-01-01 19:23:45] GPU #0: GeForce GTX 1060, 422.18 H/s
[2018-01-01 19:23:45] ...retry after 30 seconds
[2018-01-01 19:24:16] GPU #0: GeForce GTX 1060, 421.60 H/s
[2018-01-01 19:24:16] ...retry after 30 seconds
[2018-01-01 19:24:46] ...retry after 30 seconds
[2018-01-01 19:24:46] GPU #0: GeForce GTX 1060, 426.30 H/s
[2018-01-01 19:25:16] ...retry after 30 seconds
[2018-01-01 19:25:17] GPU #0: GeForce GTX 1060, 421.94 H/s
[2018-01-01 19:25:46] ...retry after 30 seconds
[2018-01-01 19:25:47] GPU #0: GeForce GTX 1060, 414.55 H/s
[2018-01-01 19:26:17] ...retry after 30 seconds
[2018-01-01 19:26:17] GPU #0: GeForce GTX 1060, 425.48 H/s
[2018-01-01 19:26:47] GPU #0: GeForce GTX 1060, 414.14 H/s
[2018-01-01 19:26:47] ...retry after 30 seconds
[2018-01-01 19:27:17] ...retry after 30 seconds
[2018-01-01 19:27:18] GPU #0: GeForce GTX 1060, 409.28 H/s

You don't have your wallet ID/payment address after -u .. if that wasn't redacted for this post then that may be your issue.  You can have a look at my pool which has a configuration utility that might help:

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


How do I check balance on my offline wallet while I did not assign any transaction ID? I generated adresses at moneroaddress.org and sent to them my funds from Poloniex. I have installed Monero Gui Beta 1 and when I import wallets with seed frases I see no funds at all. How do I solve it?

If you are using the GUI, and restoring from seed you'll need to scan the blockchain from scratch to find your deposited coins. This is a time consuming process so you'll need to be patient and ideally do it with your own node if you want to preserve your privacy, or make the process faster. If you know the blockheight of the first deposit you can save yourself a lot of time by inputting the blockheight when you restore from seed.

Until you've scanned the blockchain you'll not know your balance, but it only needs to be done once as the wallet will progressively check the blockchain as new blocks come in. If you haven't specified remote node, or don't have a local node to connect to this will never happen though. It requires to make sure you have one of these things in order to scan the blockchain.


Monero double spends in the txpool If a transaction A enters the txpool at timepoint A', and then a second transaction B enters the txpool at timepoint B' at a location distant enough to have not received information about transaction A, how does the Monero protocol handle this double spend attempt?

First one to get in a block wins, there can be no other way as far as I understand. I mean, who has the authority to say which one came first?
For this, we have PoW and the blockchain - to avoid having to rely on "someone said this came first". Until it's mined, it's undefined.


Are the developer's guides outdated? I was trying to find docs about how to create a new subaddress using the CLI wallet RPC but it seems that dev guides at https://getmonero.org/resources/developer-guides/ are not updated to reflect 0.12.* version.

Are they simply not updated or there is another reason to be in the current state?

Is there an issue tracker where to report this problem?

I know the daemon RPC guide has recently been fully updated and the wallet RPC guide has recent updates.

Issues can be tracked (and contributions to update) at https://github.com/monero-project/monero-site/


Do cryptonight hash speeds mirror scrypt and SHA-256 hash speeds? There are various websites that tabulate SHA-256 & scrypt hash speeds of various hardware. I wonder how these correspond to crytonight hash speeds. Are they correlated? Or does the correlation break depending on chip architecture?

AFAIK, there is strictly no correlation between the hash speed of different hashing algorithms.

I guess it can possibly make sense for hardware that are capable of dual mining.

But, currently, hardware for SHA-256 & scrypt are ASICs, so they won't work for others hashing algorithms


How do exchanges adopt Monero? Exchanges such as Poloniex.com that trade in Monero are limited as compared to other cryptocurrencies.  Is Monero trading more difficult to implement than, say, a Bitcoin-based exchange?  What are the unique challenges required and technical steps needed for an exchange to adopt Monero?

Many altcoins fork from Bitcoin so their codebase is often not much different from Bitcoin. That's why it's relatively easy to make all existing tools work with a coin forked from Bitcoin. Therefore exchanges don't need to spend much development time to implement most altcoins.

Monero is based on CryptoNote, which is a new protocol and very different from Bitcoin. In order to make Monero work they need to change most of their tools. That's a lot of development time the exchanges need to invest.


Installation and Update of monero cli and gui I tried out monero cli and gui and created two wallets with each version, named Walletcli and Walletgui. There is now a Walletcli file in the program directory but no Walletgui file, where is it? Which files are created by the program on which location (Windows)? Where ist the blockchain?
How can I update the program, just copying the new files over the old?
Unfortunately there is no instruction or setup.

but no Walletgui file, where is it?

Looking for "Monero Wallets" folder on your disk

  Which files are created by the program on which location (Windows)? Where ist the blockchain?

On Windows the blockchain is stored in C:\ProgramData\bitmonero\lmdb. It's a hidden folder.

  How can I update the program, just copying the new files over the old?

Yes, you should make a back up if things gone wrong.


How will RingCT dust work? Right now, if you have a small piece of Monero, you can spend it with mixin 0. That way, you can collect a bunch of them without paying too high of fees.

RingCT will hide amounts, meaning it won't be apparent to the blockchain if something is dust. Will you be able to collect dust with 0 mixin if you reveal the amount (which would also allow the range proof to be omitted), or if you shrink the range of the range proof to prove that it is dust?

There were two main reasons outputs were called dust:

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

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

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

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

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

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

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

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


does current monero support submitting signed transactions from file? I generated unsigned_monero_tx on a disconnected computer, and copied it to a connected one.  I placed it in my home directory, and ran submit_transfer.  This gave the error:

Error: Failed to load transaction from file

which is not a helpful error message.

I compiled the software from master (5fbfa8a65663e807c6500ae9485e898df9b7c470) because I read that the offline signing functionality is broken in the current tagged release (!), and because my old monero softwares all stopped working, because apparently they expect to be continually updated (!!).

The content of my signed_monero_tx file begins with the text "Monero signed tx set".

How do I broadcast it using the monero software?

Edit: stackexchange has asked me to edit the question to explain how it is not answered by How do I use cold transaction signing?.

That q+a describes how to do offline signing with things working.  My question is asking about a case of the software not working.  A bug, glitch.  It fails.  That is what my question is about.

Those transfer files need to be read and written using the same version of monero (or similar ones anyway).

Monero needs to be updated about twice a year, so you always have software which can work with the regular updates. Failing to do so means you'll drop off the network (but if others also do, you'll end up on a dead fork). The daemon should warn you if this is the case.

If the computer running your cold wallet is using old software, you need to update it first.


Are RingCT transaction bigger than an average ring signature transaction? Are RingCT transaction bigger than an average ring signature transaction?

If yes how much bigger?

Yes, they are a bit in practice, but according to the RingCT paper of Shen Noether on http://eprint.iacr.org/2015/1098 it seems it cannot be much:


Is there any benefit to the network by running multiple full nodes from one location? I have a bunch of spare computers lying around at home and have currently got each of them running a full node. Does this benefit the network more than running a full node on one computer only?

It's even harming the network, since every full node will be synching the whole blockchain from other nodes and using their bandwidth without giving more back to the network than one full node at this location would do alone.

However for one location, there are several possibilities, which differ a little bit from each other:

Home internet access provides probably very little upload speeds at most locations, so each node will sharing very little with other nodes but still synching the whole blockchain from them.
VPS or Cloud servers at one location like Amazon AWS can make sense, since they have a very good outbound connection and each one with a small CPU/memory config can reach its limits. Also recommended as remote node for privacy concerned users who want to run an own node but their home connectivity doesn't allow them due to bandwidth limits.
Dedicated servers hosted in the same datacenter are still very helpful for the network, since they have mostly a good connectivity and a lot of bandwidth and hardware resources. In most cases they will be operated by different people what decentralises the control and distribution of the blockchain.

So no, several full nodes at one location sharing the same internet connectivity and controlled by one and the same person are no benefit for the network. At home the best solution is probably to run one energy savvy device like a RaspPi or similar for a full node and connect all other devices to this node.


How does Monero's multisig work under the hood? I read Luigi's post about how multisig worked when he released the first test version, but I found it very complicated and hard to understand. Maybe it was the format, or maybe it was just more complex than I was expecting. In any case, I was wondering if there is already a more didactic and detailed explanation on how things work under the hood, or if not then maybe someone could try to explain it here?

Thanks in advance!

I can only explain it to the extent I understand myself.
As written in the original post, we have user 1 with address (B, A) and user 2 with address (C, A), where B and C are individual public spend keys and A is the shared public view key (further on, small-caps will mean secret keys).
So, the 2/2 multisig address is obtained by simply summing the public spend keys of individual participants. The address is then (B+C, A). That's the address, but who can spend from it once some funds are received?
To an outsider it's just like any other address (F, A), where F = B+C. If you give the address to someone and say "send to this", he has no idea that the public spend key is actually composed of 2 (or more) keys, he sees only the combined key F. In fact, there exists a wallet which is able to spend from the multisig address alone. It can be constructed by whomever obtains the required number of individual secret keys. For doing this, there's a tool being added in PR-2218 (currently only N/N). Even without any special way of constructing TX-es, this allows for an one-time use multisig wallet. User 1 gives the private spend key to user 2 who constructs the master wallet and does whatever he wants with it further on.
But we want to sign individual transactions and avoid handing over control of the entire wallet. That makes it a bit more complicated, as the TX construction has to be done in steps which don't reveal the secret key to the other pary.
So, both parties already have the shared secret view key a and the combined public spend key F. This lets them both have a watch-only wallet and scan for incoming transfer. Recall how one-time public keys destined for this wallet are constructed:
P = Hs(rA||i)G + F,
and the recipient (any 1 of them) can check:
P' = Hs(aR||i)G + F, P = P' ?.
That's the output. To spend, we must produce a key image (also to check spent status) and produce a signature with the corresponding one-time secret key, but without revealing the "owning" wallet secret spend key.
As described in Luigi's write-up, fist step is key image creation.
Normally, the key image would be:
I = xHp(P),
but to construct it you need to know x, and you can't know x without the "master wallet" secret spend key, because:
x = Hs(aR||i) + f.
However, we can build it in parts:
User 1 does: I_1' = bHp(P), and
user 2 does: I_2' = cHp(P).
Any user can compute the complete key image from the partial pieces:
I = Hs(aR||i)Hp(P) + I_1 + I_2,
which works because:
I = Hs(aR||i)*Hp(P) + I_1 + I_2 =
= Hs(aR||i)Hp(P) + bHp(P) + cHp(P)
= (Hs(aR||i) + b + c)Hp(P)
= (Hs(aR||i) + f)Hp(P)
= xHp(P)
Further on, we construct the ring signature, etc. but that part I don't understand well, so can't continue.


Can a message be encrypted with a Monero address and then decrypted by the address's owner? Some Bitcoin wallets have this functionality: they let you encrypt an arbitrary text with a Bitcoin address such that only the owner of the address can read the text.

The Monero wallet software allows you to sign a message with your own private keys, but I'm asking about encrypting with someone else's [public] address. (I'm not asking about embedding messages in transactions.)

It is theoretically possible (that is what the short payment ids are), but I don't think there's any existing command for this at the moment.


How do I manually generate a base58 private key from my secret spendkey? What are the steps for deriving a base58 private key from a secret spendkey?  Sort of like the answer here, but for Monero or another Cryptonote: https://bitcoin.stackexchange.com/questions/8247/how-can-i-convert-a-sha256-hash-into-a-bitcoin-base58-private-key

Monero has some base58 functions in src/common/base58.*.
If for some reason you wanted to store your secret keys as base58, you could use those. There are usage examples in tests/unit_tests/base58.cpp.


Anybody tied High Throughtput Mining with NVidia GPGPU - Planning to buy a server I am planning to buy a server with following specs to follow my passion for mining currencies and make money too. Someone suggested me to buy this server.

Intel® C612 Chipset - Dual 1-Gigabit Ethernet - 4U GPU Server - 2000W (2+2) Redundant Power Supply
2 x Twenty-Two-Core Intel® Xeon® Processor E5-2699A v4 2.40GHz 55MB Cache (145W)
8 x 32GB PC4-19200 2400MHz DDR4 ECC Registered Load-Reduced DIMM
No SATA Disk on Module for boot
No Optical Drive Support
8 x Integrated Video (Included with Motherboard)
8 x NVIDIA® Tesla™ K80 GPU Computing Accelerator - 24GB GDDR5 - Passive Cooler
Intel® Ethernet Server Adapter I350-T2V2 Dual Port (2x RJ-45)
2 x Intel® SSD DC P3520 Series 1.2TB PCIe 3.0 x4 NVMe Solid State Addon Card
Replacement Chassis Top Cover (required for NVIDIA GeForce GTX graphics card support)

Since I am only into AltCoins and that too just cryptonotes have thought of buying the above server. Can someone calculate & suggest the hashrate it would be able to generate. Cost of this server is very high and would be putting in plenty of money to acquire it.

Any suggestions or guidance would be highly appreciated.

Regards,
Pundit

check on http://monerobenchmarks.info/ the tesla and xeon are both on the list


Monero Pool job contents, blob length I am trying to understand the contents, their meaning and their volatility of the job we receive from Monero pool. For example

data from pool: {"id":1,"jsonrpc":"2.0","error":null,"result":{"id":"300955505552701","job":
{"blob":"0202b4d88cd005723910a7844c6cf04bb10af456fdf6e4b352e1839747d3e971117b7550da82550000000028b751d55f1b5c591ef82e4ec90a621a32f48044e8e112fa8ff4be5b3b046a6a04","job_id":"129359229584224","target":"9bc42000"},"status":"OK"}}

Now I can understand things like Id, jobid, target, status etc. The question I have is, in blob is the length always 76 bytes? can it change from 76 to something and if it does when and why?

Also what does exactly the blob represent? I know the first 39 bytes are something and then 4 bytes are nonce then remaining 33 bytes are something. Those 39 and 33 bytes are what?

Thanks

Mining Blob
The mining blob is the block header + merkle root + number of TX-es. It's similar to block identifier as defined in CNS003:

Calculation of Block Identifier
The identifier of a block is the result of hashing the following data with Keccak:

size of [block_header, Merkle root hash, and the number of transactions] in bytes (varint)

block_header,

Merkle root hash,

number of transactions (varint).

The goal of the Merkle root hash is to "attach" the transactions referred to in the list to the block header: once the Merkle root hash is fixed, the transactions cannot be modified.

Note that the block identifier is the result of hashing the blob with Keccak and it is not the same as PoW hash. The PoW hash is obtained by hashing the blob with CryptoNight, and it doesn't contain the "size of [block header, ..." which is used exclusively for the block identifier.
See get_block_hashing_blob implementation in Monero source code for details.
  blobdata get_block_hashing_blob(const block& b)
  {
    blobdata blob = t_serializable_object_to_blob(static_cast<block_header>(b));
    crypto::hash tree_root_hash = get_tx_tree_hash(b);
    blob.append(reinterpret_cast<const char*>(&tree_root_hash), sizeof(tree_root_hash));
    blob.append(tools::get_varint_data(b.tx_hashes.size()+1));
    return blob;
  }

As you can see, it retrieves the block header blob, and appends Merkle tree root and number of transactions to the blob.
Block Header
Block header is also defined in CNS003:

4.1  Block Header
Each block starts with a block header. The major version defines the block header parsing rules (i.e. block header format) and is incremented with each block header format update. The table below describes version 1 of the block header format. The minor version defines the interpretation details that are not related to block header parsing.
It is always safe to parse the block header of a particular major version with a parsing procedure suitable for said version, even if the minor version is unknown. Parsing the block header with an unknown major version is not safe as the content of the block header may be misinterpreted.

   +---------------+------------------+--------------------------------+
   |     Field     |       Type       |            Content             |
   +---------------+------------------+--------------------------------+
   | major_version | varint           | Major block header version     |
   |               |                  | (always 1)                     |
   +---------------+------------------+--------------------------------+
   | minor_version | varint           | Minor block header version     |
   |               |                  |                                |
   +---------------+------------------+--------------------------------+
   | timestamp     | varint           | Block creation time            |
   |               |                  | (UNIX timestamp)               |
   +---------------+------------------+--------------------------------+
   | prev_id       | hash             | Identifier of the previous     |
   |               |                  | block                          |
   +---------------+------------------+--------------------------------+
   | nonce         | 4 bytes          | Any value which is used in the |
   |               |                  | network consensus algorithm    |
   +---------------+------------------+--------------------------------+

             Table 4.1: Block header structure description

The definition of block header is found in Monero source code as well.
  struct block_header
  {
    uint8_t major_version;
    uint8_t minor_version;  // now used as a voting mechanism, rather than how this particular block is built
    uint64_t timestamp;
    crypto::hash  prev_id;
    uint32_t nonce;

Note that major version is used for hard-fork upgrade counting, as seen in Monero source code (1, 2). Looks like it's not exactly following the CN specification, where it was supposed to be changed only if the header parsing scheme changes.
Block PoW Hashing
For actual hashing, see get_block_longhash implementation in Monero source code and explanation of the "block 202612 bug workaround": What happened at block 202612?


How is the number of ring members selected? How is the number of ring members signing a transaction selected? Is it selected randomly by the sender or is it defined by the Monero wallet?

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

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

For reference, this was implemented in this commit.

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


How to keep Monero daemon from crashing during initial sync? I found that my Monero GUI wallet keeps crashing during the initial blockchain synchronization, and when I start off from where it crashed, data.mdb in C:\ProgramData\bitmonero\lmdb has been corrupted (the Error opening database: Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid response in the command prompt). Typically, it gets 2.0 to 3.0 GB in size, though sometimes as much as 6.0 GB.
To work around this, I've been running monerod.exe in the Windows 10 command prompt and adding flags such as these in order to keep the synchronization from using too much CPU power or bandwidth:
--max-concurrency 1
--block-sync-size 10
--out-peers 5
--limit-rate 500
Unfortunately, none of these have been successful regardless of the numerical values in the flags. Do I need to install the wallet on another computer, or could I try another workaround?
EDIT: After updating to the latest version and reducing out-peers to 3, I'm having more success. The daemon didn't so much crash as freeze the computer and corrupt the databases. Two crashes without corruptions later, and I have over 70% of the database saved. The remainder will take several more days.

Monero prior to 0.17.1.9 had a DoS vector where someone could send monerod a massive ~100 MB packet, crafted such that parsing it would take lots of memory (on the order to 30 GB I think, I might be off). I assume this is what you both got, and the OS killed the process due to no RAM available, rather than an actual crash. Update to 0.17.1.9 and if it still happens, then it's another problem which should be reported to https://github.com/monero-project/monero.


'monerod status' mining hash rate Does the monerod status command show the mining hash rate per thread or in total ?

eg

Height: 1461927/1461927 (100.0%) on mainnet, mining at 50 H/s, net hash
381.26 MH/s, v6, up to date, 9(out)+0(in) connections, uptime 0d 0h 20m 36s

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


What is the relationship between view key and random r value for pedersen commitment? Suppose I make a transaction from User1 to User2 with TX amount 2.5 XMR using RingCT. The transaction amount is encrypted using Pedersen commitment with a random value r.
I have a public view key of PubView1 for the transaction.
Can I see the transaction amount if I only have the public view key? I don't have the "r" value.
What is the relationship between view key and the random r value in Pedersen commitment?

The transaction amount is encrypted using Pedersen commitment with a random value r.

The amount is encrypted using the shared secret rA and committed to in a Pederson commitment.
Amount encryption:
b = n xor8 Hs(“amount”|Hs(rA|i))

Where n here denotes the unencrypted amount, rA is the shared secret, i is the output index, | is concatenation, Hs is hash to scalar and b is the final encrypted amount.
Then the Pedersen commitment C:
y = Hs(“commitment mask”|Hs(rA|i))
C = yG + bH

So one either needs r or a (private terms of the shared secret) and either R or A respectively, the public terms. R is rG, the tx public key and A is the receivers public view key. Thus with a (the receivers private key) and the tx public key R, one can decode the amount. As can the sender as they have r and A. This is because rA == aR.

Can I see the transaction amount if I only have the public view key?

No. You need some secret information, either r or a.

What is the relationship between view key and the random r value in Pedersen commitment?

See above.


What is the Chinese translation for "Monero"? What is the Chinese translation for "Monero"? (in both simplified and traditional)

How has it been chosen?

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

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


Are there any blockexplorers that will track RingCT usage after the v4 fork? Statistics on mixin data is useful to anyone interested in privacy levels of Monero network transactions. I would like to track what percentage of transactions use RingCT between v4 activation and v5 enforcement.

Will there be RingCT statistics available starting the first day after the v4 fork?

Yes, the Onion Monero Blockchain Explorer supports RingCT. Currently it is:

  the only explorer supporting Monero testnet network and RingCT,

More blockexplorers may add support in the coming weeks but I am not aware of any specific announcements.


Why does monerod consume so much CPU? I'm on an i7 core but monerod consumes up to 300% CPU at times. When I am catching up on the blockchain, it renders my computer nearly unusable. Is this normal?

When the chain is synced, CPU use is OK.

Basically what jwinterm said.

I think your best bet, assuming you want to do something else with your computer while catching up rather than catch up ASAP, would be to add --prep-blocks-threads 1 (or 2; it defaults to 4) to your command line. This will make it use only one (or two) core(s) to compute POW while in "catch up" mode.


Monero trademark control and potential for abuse Recently, I read about the Zcash Electric Coin Company “Zcash” trademark and  active efforts to prevent others from using that name by making pull requests in competing forks and legal reminders.

Does any individual or company have control of the Monero trademark? Could a Monero trademark be abused to "to bully alternate development teams from improving the protocol and/or implementations" in a manner similar to what Peter Todd described in Zcash concern 1.8 below?

We applied for a trademark, and it almost got accepted, but then the now-defunct Moneero company got in the way. In our discussions with the Software Freedom Law Centre, who defended us against Moneero's threats, we learnt that there is a thing in trademark law (US specifically, but many other countries have a similar law) called the doctrine of equivalents. Basically this says that you can't break trademark restrictions by using a foreign word. For example, you can't register "Mela" as a trademark for a computer company in the USA, because that's the Italian word for apple:)

The upshot of this is that Monero is, most likely, actually impossible to trademark. Anyone that tries to register Monero as a trademark will be challenged by us on the basis that Monero is a foreign word (Esperanto) that means coin, and you couldn't register "coin" as a trademark. We can challenge this even if we only discover a trademark registration after the fact.

Because of this there is, or at least should be, no threat to any entities that use the Monero name, because it simply cannot be trademarked and used to threaten individuals or companies.


Buying Monero Privately in Toronto Canada I would like to buy Monero PRIVATELY in Toronto Canada. I am new to Monero and would love to buy it privately without having to give up my personal info to an exchange to buy it.  Can you please let me know of a place I can go to to buy it privately?

Popular places to buy without KYC are Bisq and LocalMonero.


Full nodes suddenly appearing and dissapearing in a geographic region Aside from changing mining profitability, what are some reasons why large numbers of full nodes would suddenly appear (and later disappear) within a certain geographic region.

For example, what could have caused the number of full nodes in China to jump from 8 to 38 over just a few days last month with fairly fast drop back down near prior levels (11 as of today) shortly afterwards?

There is a suspected bug in the P2P connectivity code, which causes some nodes to not see the entire Monero network, so the monerohash.com only sees part of the network. It is unknown how much of the network this "hides" from the statistics.


What are the standard fee multiplier levels? In the GUI wallet the fees are written as

Slow: x0.25
Normal: x1
Fast: x5
Fastest: x41.5

But I just made two transactions with slow and normal fee respectively and the slow fee was 1/5 of the normal fee. Does anyone know the real levels?

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

1, 5, 25, 1000 [ref].

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

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

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


About mining pool selection I am looking at some different pools.

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

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

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

More hashrate means more work.

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

An example:

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

300000000/3000000*120/(60*60)

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

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

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

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

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


Source code history "immutability" I'm fairly new to git and it seems surprisingly easy to rewrite past commits.

I'm aware of the signed commits, and if I understand it correctly, it prevents against unauthorized/untrusted  write access, including a compromission of the github platform itself.

But what happens if the private key of a single trusted account on github gets compromised ? How can I check that from now on, there are only new commits ?

If history is rewritten, you will not be able to pull over an existing tree (it's a bit more complicated, but in the general case where you're only ever on master, it holds). This is the "fast forward" mode. If history you already have is rewritten, git will fetch the new data, but will complain that it can't fast forward, and leave you with your master branch, and the new commits in origin/master (assuming it's named that way in your tree).

Now, I am not 100% sure this is not gameable, since git does not use cryptographically strong hashes AFAIK. But it'd take some doing, at least.

Note that if the rewriting happens all in (from your point of view) future history (ie, in commits you have never pulled yet), you will not see this.


Will it be possible to see the mixin number with ringct on? I was thinking if it was true you could see mixin number with ringct transaction? thanks everyone

Yes, it will be possible to see. Consider that you're submitting n one-time public keys in each transaction, where one of them belongs to you and others are decoys. There's really no way to hide this. Mixin is the number of those decoys used in a transaction, so mixin = n-1.

Major change with ringCT, apart from hiding the amounts, will be reduced number of outputs per transaction.

For example, currently when sending 123xmr, it would be split into denominations of 100, 20, and 3. Each of them would then be obfuscated with 4 decoy outputs resulting in total of 15 outputs in a single transaction. RingCT will bring this down to 5, as 123xmr could be used as it is, without splitting, because the amount will be hidden.


Multiple outputs & expected reward from coinbase transaction I set up a private testnet to play around with and I am currently mining empty blocks. I was surprised to see that the coinbase transaction created by the getblocktemplate RPC had 5 outputs instead of only 1, which is what I normally get on the mainnet. For example, below are the outputs for one particular block:

0.001253953260
0.070000000000
0.400000000000
7.000000000000
10.000000000000

Why does Monero split up the rewards in this instance?

Also, a follow-up question: I'm having a bit of trouble calculating expected rewards from the coinbase transaction. For example, one block's expected reward is 17472187044247, and using the equations from here, 17472187044247 = (2^63 - A) / 2^19, so A = 2^63 - 2^19 * 17472187044247. Using this value of A, we can get the reward from the very next block with R = (2^63 - A - 17472187044247) / 2^19, which gives us R = 17472153718694. However, the actual expected reward of the next block is 17472170381470. I was able to verify this formula on the mainnet, so I'm not sure why the actual reward is greater than the calculated one.

Why does Monero split up the rewards in this instance?

This answer requires a bit of history first to be sufficiently explanatory.

In the first years of Monero's existence amounts were not encrypted yet. In addition, output amounts were "split" into denominations to the power of 10 to ensure they could be used as decoy outputs (i.e. ring partners). Thus, for instance, an amount of 101.1234 was split into denominations of 100, 1, 0.1, 0.02, 0.003, and 0.0004. To reiterate, this was required in order for ring signatures to work properly. That is, if the amount of 101.1234 was not split into denominations, it would be fairly unlikely that one could find two other (decoy) outputs of 101.1234 to create a ring with. By contrast, plenty of decoy outputs (ring partners) can be found for an output amount of 100. In September 2016, RingCT, which, in a nutshell, allows one to encrypt output amounts, was activated on testnet. A few months later, in the beginning of 2017, RingCT was activated on mainnet.

Now, as you can see from here, the hard fork which activated RingCT on testnet was triggered by block 80xxxx. Intuitively, all blocks before the fork block contain transactions with non-RingCT outputs, which are unencrypted and split into denominations to the power of 10. It logically follows that, if you create a private testnet (which starts from block 0), the blocks on your private testnet contain transactions with non-RingCT outputs until RingCT activation is triggered. Basically, you'd need to mine ~800k blocks before RingCT gets activated. You can, however, tweak the fork heights in the code, recompile, and set up a new private testnet.

  Also, a follow-up question: I'm having a bit of trouble calculating expected rewards from the coinbase transaction.

The slight discrepancy between the expected reward and actual reward is, if I recall correctly, caused by the penalty (i.e. miners incur a penalty if they mine a block bigger than the minimum block size limit of 300 kB) being deferred to future miners.