Trezor firmware, private view key, key image and privacy

It is my understanding that the Monero trezor firmware uses the private view key.

Monero Trezor has access to all your keys, but it's contained in the device and thus safe to use.

  This might lead to some privacy concerns.

There can be no privacy concerns considering how everything works. Only you have access to your keys and the keys never leave the device (Trezor).

  I have read that key image can be used to check balance of a paperwallet.

Yes, the key images are used to check the balance of a paper wallet but you still need the fully-synced view-only wallet.

  Does this mean that it is possible to develop a firmware for the trezor that will only use transactions key image to check balance?

Kind of, but it wouldn't make any sense as the purpose of Trezor is for more than just checking the balance - to safe keep your private keys and allow you to also spend without ever exposing your private key. You still need a view-only wallet to make sure that a corresponding key image was produced for every output.

  Could this be a privacy improvement?

Over what? There is no privacy loss involved in using Trezor. The only risk is that someone gets your view-only wallet from your PC and the wallet password. Then, he would be able to see the incoming outputs, and that's it. This risk is completely unrelated to Trezor, though.

Monero works with 2 key-pairs: view and spend, and each have the private and public counterpart. The purpose of each is as follows:

Private view key allows the recipient to see which transaction on the blockchain belongs to him. Without it, he's clueless, because all outputs look the same. Monero are only ever sent to one-time destinations and your address never appears on the blockchain. Only with the view key, you can know which one is for you.
Private spend key allows the recipient to spend an output by signing a transaction. Also, he signs a key image which is used as a way to prevent double-spends. For each signed output, there's one key image, and if you try to spend the same output again, the resulting key image will be the same and will be rejected by the network.
Public parts make up the monero address, and are needed by the sender to be able to generate an one-time destination for the recipient.

From the above, with the view key, you can only know what you received, but not if it was later spent or not. Sending the same monero back to yourself would make it look like you just doubled your balance which is not true becasue now the originating output has been spent.

To detect if an output has been spent, the key images are used. Each output corresponds to one key image, but to generate it you need the private spend key. For auditing, you skip the transaction signing, and just produce a key image for each output detected using the private view key. Then, anyone can check the balance, if given the private view key and all the signed key images.

Now, how this relates to Trezor?

Trezor is a device which keeps all your keys. The thing is, those keys never leave the device, and that's what makes everything secure. Your hot-wallet resides on your PC, but is view-only. To spend anything, the Trezor needs to sign the transaction and give the signed version back to your PC in order to push it to the network. You never disclose your view key or your view wallet to a 3rd party so I don't understand what you mean by "privacy concerns".


get_bulk_payments is not a monerod RPC, it's a wallet RPC.
Run monero-wallet-rpc, and connect to its RPC port to use get_bulk_payments.

BTW, you wrote "get_payments" in the query JSON, not "get_bulk_payments".


You have to launch monero-wallet-cli from the terminal (on Linux and mac OS X) or from the command prompt (on Windows) with the --restore-deterministic-wallet flag. Thus:

For Mac and Linux:

./monero-wallet-cli --restore-deterministic-wallet

Make sure the terminal is opened in the same directory as monero-wallet-cli is located in.

On Windows make sure to launch it from the command line. Go to the folder monero-cli-wallet 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:

monero-wallet-cli.exe --restore-deterministic-wallet

For all operating systems it will first ask you for a new wallet name and password. Subsequently, you have to enter the 25 word mnemonic seed. Lastly, enter refresh into monero-wallet-cli.

P.S. Note that simplewallet was renamed to monero-wallet-cli in v0.10.0.


Seems like multisig works as a normal wallet so same as with a regular one you use the same command for it and then add following addresses and amounts you need. That's it.


Is there a way to see the blockheight at a specific point in time?

Monero targets a new block every 2 minutes, so if we set H as the current block height, N as the current timestamp, T as the past timestamp of the datetime you want to know the block height of, then:

H - (N - T) / 120

Gets you very near. Blocks aren't mined exactly every 2 minutes, so there will be fluctuation. To narrow down further, you can then use a block explorer like https://xmrchain.net/, or your local node.

For example, trying to find the first block mined on March 21st 2019:

1885896 - (1564019260 - 1553126400) / 120 = 1795122

Which is a couple of hours off: 2019-03-20 21:42:02. Using the block explorer, you can skip forward and find that block 1795175 was mined at 2019-03-21 00:02:52.


Sure, assuming you have not made any branches, and that doesn't sound likely, follow these steps:

if you have made any changes to the repo: git stash
git pull --rebase
if you have made any changes to the repo: git stash pop

So in the likely case you haven't changed anything, it's just one step. Then build again (make).

If you did make changes, there's a possibility your changes will conflict with the upstream changes. In that case, it gets complicated, and you'll want to read the git docs. If the changes you made were trivial, it's easier to redo them manually.


How do I enable Confidential Transactions?

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.


This setting is adopted from the original i2pd and the documentation tells:

  Bandwidth limit: integer in KBps or letters: L (32), O (256), P (2048), X (>9000)


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

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

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

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

This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.
You need to run / use GUI v0.12.3.0, which can be found here. You can, if you're still running an older version, use the instructions in aforementioned Reddit post to upgrade.
You need to install the Ledger Monero app. Instructions can be found here.
All Monero related processes need to be closed.
Your Ledger needs to be plugged in and the Ledger Monero app should be running.

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

Go to the directory / folder monero-wallet-gui.exe (GUI v0.12.3.0) is located (note that monero-wallet-cli.exe will be in the same directory / folder as monero-wallet-gui.exe).
Open a new command prompt / powershell. This is done by first making sure your cursor isn't located on any of the files and subsequently doing SHIFT + right click. It will give you an option to "Open command window here". If you're using Windows 10, it'll, most likely, give you an option to open the Powershell.
Now type:

monero-wallet-cli.exe --generate-from-device <new-wallet-name> --restore-height 1585000 --subaddress-lookahead 3:200 (Win 7 + 8)

.\monero-wallet-cli.exe --generate-from-device <new-wallet-name> --restore-height 1585000 --subaddress-lookahead 3:200 (Win 10)

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

monero-wallet-cli.exe --generate-from-device MoneroWallet --restore-height 1585000 --subaddress-lookahead 3:200 (Win 7 + 8)

.\monero-wallet-cli.exe --generate-from-device MoneroWallet --restore-height 1585000 --subaddress-lookahead 3:200 (Win 10)

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

A few final notes:

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

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

[2] Open monero-wallet-gui

[3] Enter the password to open the wallet.

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


Can the receiver determine the value $r$ from the stealth address?

Assuming that by stealth address you mean the output one time key, then no, it it not possible. r is the secret key corresponding to the R public key which gets included in the transaction. The recipient will use that public key only, and never learn r, using the fact that aR == rA.


You probably should be using subaddresses instead of integrated addresses. You can have a view only wallet so that if your server is compromised, your funds cannot be stolen.

If you really want to generate an integrated address without a wallet see here on how to do so: Generate an integrated address using javascript in the browser?


Monero GUI Changing from host node to local node

With Monero, the daemon takes care of syncing the blockchain, while the wallet handles private keys. The daemon never has access to private keys [1], only the wallet does. Therefore, if you switch daemons, your wallet address does not change, as long as you continue loading the same wallet. The wallet software will just scan for blocks from a different source of blocks.

[1] this will soon change a little, as the daemon will gain the ability to scan the chain using a wallet's private view key, but this isn't relevant here.


What is the command in monero cli to send some coins to an address or multiple addresses at once?

transfer should do it

  transfer [< priority>] [< ring_size>] < address> < amount> [< payment_id>] - Transfer < amount> to < address>. < priority> is the priority of the transaction. The higher the priority, the higher the fee of the transaction. Valid values in priority order (from lowest to highest) are: unimportant, normal, elevated, priority. If omitted, the default value (see the command "set priority") is used. < ring_size> is the number of inputs to include for untraceability. Multiple payments can be made at once by adding < address_2> < amount_2> etcetera (before the payment ID, if it's included)

you can transfer to multiple addresses but you can transfer using only one payment_id per transaction ie:

transfer <address_1> <amount_1> <address_2> <amount_2> <address_3> <amount_3> <payment_id>


From Cryptonote Address Tests

  Cryptonote Public Addresses differ in several ways compared to Bitcoin. First, Cryptonote uses two keypairs, known as the spend keypair and the view keypair. Furthermore, these keys are EdDSA (specifically ed25519) keys, whereas Bitcoin uses ECDSA (specifically secp256k1) keys. Finally, Cryptonote Public Addresses are direct representations of the pair of public keys, whereas Bitcoin (and clones) uses a hash of the single public key.

  (...)

  To create the actual Public Address, the following is performed:

  The pair of public keys are prepended with one network byte (the number 18, 0x12, for Monero). It looks like this: (network byte) + (32-byte public spend key) + (32-byte public view key).
  These 65 bytes are hashed with Keccak-256.
  The first four bytes of the hash from 2. are appended to 1., creating a 69-byte Public Address.
  As a last step, this 69-byte string is converted to Base58. However, it's not done all at once like a Bitcoin address, but rather in 8-byte blocks. This gives us eight full-sized blocks and one 5-byte block. 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 5-byte block can convert to 7 or less Base58 digits; the conversion will ensure the result is 7 digits. Due to the conditional padding, the 69-byte string will always convert to 95 Base58 characters (8 * 11 + 7).
  This 95-character result is the (obscenely long) Cryptonote Public Address!


Where can I find a description of the CryptoNight hash algorithm?

The description of the CryptoNight hash algorithm and the steps it performs can be found in the code as well as in a written file by the CryptoNote team, which can be found here. Lastly, in his blog, professor David Anderson also briefly describes the CryptoNight algorithm with an accompanying graph that illustrates it. From the blog:

This was a brilliantly designed proof-of-work function targeting the strengths of modern CPUs -- native AES encryption and fast 64 bit multipliers -- tuned to use a scratchpad exactly the size of the per-core L3 cache on Intel CPUs (about 2MB) that someone then wrapped in such a thick blanket of crap it was nearly unrecognizable until you started jumping in, tearing it apart, and putting it back together again.
Here's what it looks like without the crud (diagram shows one round):  Some initial 128 bit values are determined by hashing the block state using a Keccak (sha3) variant - call them A and B.  The big lookup table is also populated using that same state, mixed around using AES.  Then, executed 500,000 times, are rounds of mixing as shown at the right:  Use A to determine a pseudorandom location in the scratchpad, take that, mix it in, AES encrypt it (one round), use the result to determine a second location, use that in a 64 bit multiply, store it back, and repeat.  Elegantly simple.


How do you make sure a sender isn't sending bogus funds?

If the sender would be giving more monero than his balance,

In this event, he can't sign the transaction because the actual transaction input (P,C) is previous transaction output someone sent to this sender and (P,C) was recorded by blockchain.

P is the stealth address, C contains the amount.


How does sending transactions to myself reduce privacy?

Due to the way Monero works, sending to yourself actually increases your privacy, but why is that?

When you receive monero, they're always stored in some one-time destination(s) which only your wallet can access. Every time some monero moves, some existing one-time destinations are permanently spent in their entirety and brand new ones created by the sender, of the same total amount. Trick is, the new ones always have a random factor in them, so whether you send monero to someone else or to yourself - it's all the same to some outside observer, as there's no way to tell who owns the new destination. Only spending it could give away some hints, but that's why we have ring signatures.

A ring signature will add a factor of uncertainty each time the funds move. Say you actually move funds from one-time destination A and create a new one-time destination Z. Thing is, when you're spending from A, you're "pretending" to be spending from any of A,B,C,D,E which are equal members in the ring signature. So, someone can say only: Z originated from either A, B, C, D or E. Now, we spend Z to create X, and "ring" with F,G,H,I. Now, someone can say only: X came from either Z,F,G,H or I. Thing is, each of those has another 5 potential sources, and then each of those sources has 5 potential and so on... the deeper you try to go, more easily you get lost following a potential trail. So, the more transactions you move from some "hidden source", the link between it and final destination will be better obfuscated. It doesn't matter if both X and Z belong to you. When you move from Z to someone else, that means now there's at least 3 "hops" to get to your actual source of funds.


Why does my monerod always consume all the RAM?

It eats up all the RAM because it uses a very large memory mapped database (up to about 20 GB for now), and nothing else seems to need the RAM. If you really want to limit it, you could check ulimit (a bash internal command), which allows you to limit memory consumption:

$ ulimit -a
  [...]
  virtual memory          (kbytes, -v) unlimited

eg, to limit usage to a bit less than 5 GB: ulimit -v 5000000

Note that if other programs need the RAM, they'll just take it, LMDB won't hold on to it (within reason). Unused RAM is not helping anyone, after al.


monerod --test-drop-download vs --fast-block-sync

The help strings pretty much describe the differences.

The --test-drop-download version wont save the blocks, it's used for testing downloading of blocks.

The --fast-block-sync is a mode for normal operation (not testing) which will still save the downloaded blocks.


Why are there 4 types of range proofs in the Monero code base?

They all essentially do the same thing, prove a value falls within a range, but have speed/optimization differences. The latter two allow aggregating multiple proofs into a single proof for example. Again for optimization purposes.

  My confusion is why are all of these distinctions needed?

Every time a new type of signature is added to Monero (or an existing type modified/improved), a new type is obviously created and the old ones remain so that past transactions (using those older types) can still be validated. If they were removed, you wouldn't be able to verify the entire blockchain all the way back to the first block.


I couldn't find a public remote testnet node, so I created one on a VPS.

Here's the address...

159.203.250.205:38081

If you're testing the official CLI wallet, include these options...

./monero-wallet-cli --testnet --daemon-address 159.203.250.205:38081

If you're testing the official GUI wallet, you need to do the following...

open monero-core.conf
find daemon_address=localhost:38081
replace with daemon_address=159.203.250.205:38081


There was a portability issue with the wallet (i.e., the wallet cache file, exported outputs, unsigned/singed transfers) which was fixed only after the release of the 0.10.1 binary, see pull requests #1462 and #1515.

What happened in your scenario is that the outputs exported from the recent master build are in the new portable file format and thus cannot be read by the release 10.1 binary which uses the old unportable file format. Output files exported using the 10.1 binary can be read from your cold wallet that uses the same 10.1 binary.


How can I get a transaction history of sent and received transfers for my account?

This is simply done by entering the show_transfers command into monero-wallet-cli. It will show the blockheight, in/out, date, transaction hash, recipient address (outgoing transfers only), amount, fee (outgoing transfers only), and payment ID. If you also want to obtain the private tx keys you have to enter the get_tx_key <transaction hash> command into monero-wallet-cli.


JSON-RPC Not Working as Shown in Wallet Guide

That looks very much like user error.

You use port 18081, which is the default daemon RPC port, and are giving it a wallet RPC.

Ask the wallet instead, using the port you selected for it.


Are there separate view keys for each account in a Monero wallet?

Does this mean that all accounts have the same view key(because the
  view keys are directly derived from the seed and not from the
  accounts)?

Just to clarify, "account" is just about grouping sets of subaddresses together. There are only subaddresses, and we decided to group them into accounts that would share the same balance for presentation purposes only. The blockchain has no idea what an account is. Accounts are only really part of a two tier numbering scheme, and nothing special.

Subaddresses were specifically designed so that the same private view key is used to scan for all incoming funds to all subaddresses.

  If so does this mean every subaddress generated is using
  the same public view key no matter the account it is in?

They're all generated from the same private view key

  Is there any way or plan in the future to have different view keys for each account
  in a wallet?

They share the same private view key for performance reasons. If you had N different private view keys, wallet scanning time (which is computationally expensive due to elliptic curve operations) would take N times longer. Thus, if you really want multiple private view keys, we decided that separate wallets were the best approach. This is just wallet logic though, and nothing is stopping someone from forking the Monero wallet and implementing a scheme with multiple view keys. This fork of the wallet software would be totally compatible with the Monero network and blockchain.

  I know there is no limit to the number of subaddresses an
  account can have - is there a limit(or recommended limit) for the max
  number of accounts the monero-wallet-cli can handle?

There technically is a limit, which is 2^32 (approx 4 billion) accounts, each with 2^32 subaddresses.

  Looking at the RPC commands on getmonero.org I don't see a way to see payments coming
  into a specific subaddress. Is there a command like get_payments (even
  just locally in monero-wallet-cli) that can break out payments to a
  specific subaddress?

get_payments does return a "subaddr_index" with a major and minor index (account and subaddress index).

  Why would some outgoing transactions not be viewable after June 2017?

Monero's privacy mechanisms are designed so that you can't tell for sure if an output has been spent, unless you know both the private view key and the private spend key. Thus it has never been enough to only know the private view key, if you want to know for sure about outgoing transactions. Some wallets may have tried to guess at outgoing transactions, based on the receipt of change outputs that happen to mention other outputs received to your wallet in the list of spent outputs. You need to know the private spend key in order to know the key images for your outputs, and only someone with the knowledge of the key images can tell whether outputs have been spent. I don't see how June 2017 would have changed this, unless some wallets that had previously been guessing at outgoing transactions decided to stop guessing.


I want to run a node. Is it better for the community for me to run it at home, or on a VPS?

Firstly, welcome!

  Is one option "better" than the other for the community?

This is a somewhat nuanced question unfortunately. It depends firstly on whether you are planning to open up you node for inbound connections (thus allowing others to sync blocks from you) and whether you also open up the RPC (so other user's wallets can use your node as a remote node). If this is your intention, then the more bandwidth you make available, the "better" it will be. So when judging which route to take, factor in your bandwidth costs too.

  Is there a risk to my home network if I run the node at my house?

If you run an open node (so having p2p and RPC open for inbound connections), the biggest "risk" is having your bandwidth exhausted. To mitigate this, you can make use of the daemon options:

--limit-rate-up arg (=-1)             set limit-rate-up [kB/s]
--limit-rate-down arg (=-1)           set limit-rate-down [kB/s]
--limit-rate arg (=-1)                set limit-rate [kB/s]

You should also make use of the --restricted-rpc flag, or use a separate port for public usage via --rpc-restricted-bind-port, to ensure you don't leak any unnecessary, private information.

  I know I need to forward a port, but does the monerod software encrypt all traffic?

Traffic is not encrypted (although there are some SSL features coming in the next release). If you goal is to offer an extra layer of privacy for users, consider running the node as a tor/i2p hidden service. That would be very helpful as there is easier tor/i2p integration coming in the next release too - and the more nodes we have on privacy networks, the better.

I hope this is useful and thanks for considering taking the extra step for the ecosystem.


Unauthorized access when calling monero-wallet-rpc

Either disable RPC authentication (--disable-rpc-login) or give user:password to curl in digest mode.


Failure when using XMR Stak CPU Miner on Linux

It seems (after some troubleshooting and a few direct messages to the author of XMR-Stak-CPU, /u/fireice_uk on reddit) that I've found the solution:

As it turns out, the sudo sysctl -w vm.nr_hugepages=128 command that must be run to fix the "MEMORY ALLOC FAILURE" error must be run every boot.

Hope this helps someone!


Which reasons were discussed for potentially changing the proof-of-work algorithm?

One of the main reasons Cuckoo cycle is atractive when compared to Cryptonight is that it is very fast to verify. This is one drawback of Cryptonight: it makes all operations that need to verify Cryptonight hashes slower.

Another reason to want a switch to Cuckoo cycle would be to keep the CPU/GPU/ASIC performance within a reasonable scale. Should ASICs pop up with enough memory allowing them to leave CPUs and/or GPUs behind by too high a margin, this would be undesirable from a decentralization point of view.

A more obscure reason to prefer Cuckoo cycle is that it is difficult to make a similar pool mining setup to bitcoin or monero. What these do is get miners to find a share at a lower difficulty than needed for a block, because a valid block solution will also be a valid share. For Cuckoo cycle, this is not the case, so a miner can't periodically send a "proof of work" to the pool. It is not quite clear whether this particularity is wanted or not. While it will force miners to solo mine (increasing decentralization), many might decide to stop mining instead (decreasing overall network security).


Generating a new wallet, locally, from your android wallet app

monero-wallet-gui can be seen as a "wrapper" for wallet2.cpp, and it can be built for android with NDK.

Alternatively, monero-wallet-cli can also be built with android NDK, but you would need a terminal emulator to run it (except if you use adb ), so better to  just use the provided arm binaries.

Finally, if it's only about generating keys, you can use a web page, like moneromooo's wallet generator but stored locally.

Edit: i may have misread the question

Android java apps can use JNI to have an instance of  WalletManager and call WalletManager::createWallet.


The incredible high/impossible hashrate suggest something went wrong indeed.

If you have overclocked your graphics card, then revert to the original factory settings and try again.

Also you should try again with a lower amount of blocks/threads and slowly increase it.

Finally you should also update your drivers to the latest version, if your not already on latest one.


Why some coinbase transactions have very long extra field, and some short?

Because miners are free to put whatever they want in there.

For example, if you parse the 2nd as ASCII codes, it can be decoded to:

4,QAy^0P<ºÈ±ùGÛg¥g=ÆúòVø9QÇ?MinerGate001!>Õºâ¨ªËq©ä9{ê¤^KPÀÙ^ñÈýdÇG)ù


Will Monero mnemonic seeds need to be converted to BIP 39 for standardization reasons?

To answer if it will be converted is really opinion-based as I'm not aware of anybody working on it.

To answer if there's an actual need is a harder one, but let's try.

Trezor support is on the way, despite Monero being a deviant child and daring to go its own way. If there's a real need for a BIP-39 variant, it will be done by whomever finds it important enough to do it. It's an open-source project after all so no permission is needed to come up with a scheme which would enable Monero wallet generation from the same word-list as used by Bitcoin. There shouldn't be any obstructions for adding such an option to the current wallet software, if someone was to code it and make a pull request.

But, let's consider few things. Just because something has a BIP number, and is presented in a clear and concise way, doesn't mean it's a standard, or a good solution for that matter. See also here for some considerations.

Current scheme used by Monero has some neat features which may be seen as advantageous over BIP-39:

It's fairly simple and is a reversible conversion between any integer and a mnemonic. This means you can also find the mnemonic from your seed, even if your seed was generated by other means. BIP-39 uses hashing, so there's no way back - you can't work out the mnemonic from the seed.
The above enables having different dictionaries / languages all encoding the same seed and you can freely transform from one to the other. I could even make my custom secret dictionary and use it without telling anybody, so nobody would even know what my mnemonic is actually used for. As long as I don't lose the dictionary myself, I'm safe.
The scheme uses a wordlist prefix where every word has a unique first n letters. This allows for some optimizations. For example the dictionary storage requirement of some software used just to restore a seed could be reduced. It also allows users to mistype the remaining letters or even use alternative words which have the same first n letters.

Yes, you'd have to keep the dictionary around otherwise you lose the way to recover the seed. I'd argue you always need to keep something, even if it's a piece of software or a print-out of BIP-39 paper. What if in 10 years you can't google BIP-39, or the dictionary used in 2016?

Considering the above, what would be the advantage of moving to BIP-39 scheme? Which problem would it solve? Adding support is a non-issue, but why would one want to replace the current scheme by BIP-39? Chances are that it hasn't been adapted by Monero simply because there's no apparent benefit to it. To do anything, there needs to be a motivation. So, before talking about implementing it, one would have to ask first the question - which is the benefit? There are no standards in this space, and just because someone came up with a scheme which gained some traction doesn't make it a standard which everyone needs to follow.

If by convert you meant: take the Monero wallet, and generate a BIP-39 mnemonic from it - it's practically impossible. This is because BIP-39 is a one-way function, as mentioned above.

Let's consider the purpose of BIP-39,

  It consists of two parts: generating the mnemonic, and converting it
  into a binary seed. This seed can be later used to generate
  deterministic wallets using BIP-0032 or similar methods.

and how it works.

  To create a binary seed from the mnemonic, we use the PBKDF2 function
  with a mnemonic sentence (in UTF-8 NFKD) used as the password and the
  string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt.
  The iteration count is set to 2048 and HMAC-SHA512 is used as the
  pseudo-random function. The length of the derived key is 512 bits (=
  64 bytes).

So, we have a way of going from "anything" to 512 bits. In Bitcoin, these are used to further derive address keypairs using some HD scheme, like BIP-32, which uses secp256k1 curve to derive the keypairs, so for sure there would have to be some major changes done to it to be able to generate Monero keypairs.

Now, if we want to go from 512 bits to a Monero wallet, what are the options?

You could use the first 256 bits as the private spend key and 2nd 256 bits as the private view key. This would make the 2 keys independent, so it would break compatibility with Monero seed scheme.
You could use the first 256 bits (or hash the 512 bits to 256 bits) as the monero seed, and go from there. This would let you keep the compatibility with the current Monero scheme as you could also generate a Monero mnemonic from it, if you would want to do so.
Something else.

On another note, Monero doesn't really need HD wallets, as there is no problem it would be fixing, unlike with Bitcoin where you're supposed to use a different address each time. There's a saying: "To a hammer, everything looks like a nail." For some cases there could be an use, but then the above point of being open-source would apply again.


Multisignature - get one signed transaction, send another, use first signed transaction

Assuming those two transactions do not double spend each other, it's perfectly acceptable. If the second transaction double spends the first one (which hasn't been mined yet), then the first one will be rejected if it's broadcast to the network.

You can't sign twice with the same multisig data, but that does not prevent a signed transaction from being held for a while before being broadcast.


How does the ring sig work: practical explanation?

Then look for another tx, fetch K inputs and outputs from that tx along with their public keys.

You simply find decoy outputs from anywhere on the blockchain. You'd never only choose decoys from a single transaction.

  Then add those K inputs as inputs to my tx, along with the corresponding outputs for them

There is no need to match inputs and outputs from other transactions. The ring signature proves that for at least one combination of inputs, the inputs balance out with the outputs and fees.


Using monero-php, I am getting "Method not found" when calling open_wallet

The wallet RPC and daemon RPC are different. Refer to the projects documentation on how to run both wallet and daemon RPCs.

The node you reference at node.xmr.to is a daemon RPC, not a wallet RPC, therefore you cannot use it for any of the wallet commands, only daemon commands.

To use a wallet RPC (like you are trying to do from php), you have to run this wallet RPC yourself (e.g. the app monero-wallet-rpc, again mentioned in the monerophp documentation). Note, the wallet RPC still needs to connect to a daemon (monerod), for which you can specify a remote daemon if you are not running your own local full node.

For the wallet RPC to use a remote daemon, you launch passing the parameter --daemon-address. E.g.

./monero-wallet-rpc --help
...
--daemon-address arg                  Use daemon instance at <host>:<port>
...


Buy with Address instead of integrated address - monero wallet GUI

Your screenshot proves that the transaction was sent. By using your view key and address in the decode outputs section of that page you can also see the amounts (currently hidden thanks to RingCT).

The fact that you are attempting to connect to a remote node (based on your comments about connecting to the moneroworld node) seems to indicate that you have not synced your own node yet. If your node is stuck, please try this

Alternatively you CAN connect to a remote node (until you have the time to sync your own node). Follow the instructions on this page again. A list of available nodes is available here


How does the dynamic fee calculation work?

According to the pull request from  moneromooo-monero on behalf of ArticMine:

  The dynamic fee is based on the block size in a past window, and the current block reward. It is expressed by kB. This function calculates an estimate for a dynamic fee which will be valid for the next grace_blocks

According to dEBRUYNE_1 this change will take effect with v4 in January 2017 and can be represented with the following formula:

The fee will vary based on the base reward and the current

block size limit:

fee = (R/R0) * (M0/M) * F0

R: base reward

R0: reference base reward (10 monero)

M: block size limit

M0: minimum block size limit (60000)

F0: 0.002 monero

According to this recent study, there are some theoretical (but serious) security risks in situations where transaction fees exceed block rewards. (R/R0) will help keep fees in check by reducing them as block reward falls to buffer against this risk.

(M0/M) acts as a sanity check. When blocks are mostly empty it does not make sense to increase the cap. If the network (that previously had relatively empty blocks) is temporarily spammed in order to increase the block size limit, the network does not benefit so the (M0/M) will punish miners by reducing transaction fees. However when legitimate network usage increases over time the amount of increased transactions will compensate for the reduction in transaction fees as the block size cap scales naturally.

With regard to your spam attack tag and how this will change things:

Transaction fees will scale downwards on a per tx basis in the case of an increasing block size limit as the result of the "M" being larger in the (M0/M) part of the equation. However total transaction fees will increase overall as the number of transactions more than cancels out the reduced fee per tx. Spamming the network to increase the block size will remain expensive after this pull request is activated. In addition, for the reason described below such an impact on tx fees would only be temporary.

It is important to note that the (M0/M) portion of new dynamic fee calculation scales in both directions. Appropriate transaction fees differ based on network utilization which is capable of both increasing and decreasing due to countless unpredictable market factors. This new dynamic tx fee formula allows for both upwards and downwards tx fee scaling.


Will we eventually get rid of "locked" and "unlocked" balances?

The amount which remains unlocked after a transaction depends on the number of unspent outputs (UTXO) you have in the wallet.

Consider those scenarios:

A: One UTXO

You have filled the wallet with one transaction of 10 XMR. That means your wallet has only one UTXO containing entire balance.
You spend 1 XMR.
The transaction you create has one input of 10 XMR and two outputs of:

1 XMR you pay, which goes to recipient's address
9 XMR (minus fee) change output that goes back to your address

Again, you have 1 UTXO in the wallet. However, before the transaction has received 10 confirmations, its' outputs remain locked.
Therefore, the unlocked balance of your wallet remains 0 for next ~20 minutes.

B: Multiple UTXO

You have received 100 transactions of 0.1 XMR each. Your wallet has now 100 UTXOs.
You spend 1 XMR.
The transaction has 11 inputs and two outputs:

10 × 0.1 XMR → 1 XMR you pay, which goes to the recipient
1 × 0.1 XMR → fee + change output

As a result, your wallet remains with 89 old and 1 new UTXOs.
The unlocked balance is now 8.9 XMR, while locked balance = 9 XMR -
fee

Fees: The transaction from variant B incurs much higher fee because of 11× bigger input set, which makes the resulting transaction significantly bigger.

TL;DR: Funding the wallet with more smaller payments makes it harder to lock-out all funds but results in higher fees.


The current blockchain size is around 50 GB as of October, 2018.

On Windows platforms, you can check the size of the blockchain by checking the size of C:\ProgramData\bitmonero\lmdb\.

On Linux/UNIX platforms, you can check the size of the blockchain in the terminal by executing du -sh ~/.bitmonero/lmdb/.

The Wolfram Warptangent v0.10.0 release bundled in some rather significant database optimizations started by the late developer warptangent (continued and finished by hyc), which shrunk the blockchain down to around 7 GB from 17 GB back in summer 2016.

The Monero blockchain grew fairly quickly in 2017 due to rapid adoption. An optimization known as "Bulletproofs" which significantly reduced the size of all subsequent transactions (~80% reduction) was activated on October 18th, 2018 with the v8 hard fork.

To check the current size of the blockchain (as well as look up historic growth of the blockchain), see https://moneroblocks.info/stats/blockchain-growth


What Happens When a Miner Doesn't Reach Minimum Payment Threshold?

When a block is found, the block reward is divided among the miners, pro rata with the difficulty weighted shares they submitted for this block. This is done by the pool software's own accounting, not on chain.

On chain transactions only happen when a miner's pending balance reaches the payment threshold. At that point, some amount (based on the denomination set in the pool's configuration) is sent to the miner, and any remnant is kept in the miner's pending balance.

This pending balance is not per block: it is permanent, and a miner mines to it, block after block. Therefore, if a miner's share of a given block is below the payout threshold, the balance (in the pool's accounting) increases by that small amount, and counts for future blocks. This means that small miners will get paid something every N blocks found, while large miners may be paid something every block found.


Reward penalty: how to control the block size?

But I fail to see how a miner, who just "packs" transactions in a block, can control the size of the blocks he or she mines.

Exactly like that. You pack until you get to the target size. Then, you simply don't pack the rest of the queue and leave it for the next block. Or you swap low fee tx-es with ones with higher fee, still keeping the size below the limit. You can choose any packing strategy you want, as long as you're able to express it with code.

It's a dynamic process. Any change gives a different hash and could become the winning block if it hits the target. Then, you submit what you had and start with next one.


How does the seed offset passphrase affect entropy?

All the "seed offset password" does is modify the existing key before getting the seed words. It works as follows:

seed_words = get_words(sc_add(key, cn_slow_hash(password)))

Where sc_add is scalar addition modulo the curve order.

Therefore:

  I figure that a portion of the random space has to be sacrificed for including an additional passphrase chosen by the user.

Is incorrect. Nothing is "sacrificed". The seed password does not affect the randomness of the key generation, it only modifies the key when used to get the seed words.

In effect, what this means is, you need both the password and the seed words (as obtained above), to get the actual key.

For example:

key = sc_sub(get_key(seed_words), cn_slow_hash(password))

Where sc_sub is scalar subtraction modulo the curve order.


How many different developers have made contributions to Monero source code?

Looking at solely GitHub commits, there have been 46 contributors to the bitmonero repository. If we count contributors to other Monero related repositories such as Kovri the number would be significantly larger.

There are many ways to track developer interest but marketcap alone is not the best indicator. One of the most popular developer score rankings is from CoinGecko which currently places Monero 5th among all cryptocurrencies. Just like Github, CoinGecko reports Monero as having 46 contributors.

Bitcoin leads all cryptocurrencies with 347 contributors. Ethereum comes in 2nd with 44 contributors, Counterparty 3rd with 27 contributors and Siacoin 4th with 12 contributors.

From that same Coingecko list, Dash in 6th place has 29 contributors, Storjcoin in 7th place has 15 contributors, the (now defunct) DAO in 8th place has 16 contributors and Ripple in 9th place has 19 contributors and Namecoin in 10th place has 25 contributors

The great majority of all cryptocurrencies are forked from Bitcoin and therefore will have a vastly inflated number of commits, and contributers, solely because of their merging of Bitcoin pull requests. This partially explains the reason why Monero only ranks 5th on the list above despite having more contributors than every project besides Bitcoin according to CoinGecko.

Monero is based on CryptoNote and has an entirely different codebase than Bitcoin. Developer interest is relatively high despite the much steeper learning curve (from those used to the Bitcoin codebase). The fact that academic research of Monero is also higher than most other currencies might be a leading indicator of increased developer interest in the future as documentation to help with the learning curve improves.


Monero Research Lab - Talent Acquisition. Whom would/do they want?

I think that anyone who has the abilities and intent to do formal research on crypto/monero related subjects would be welcomed. Of course, this does not mean "limited abilities" and "wishy washy intent". I think we can all apply some common sense to this. However, I don't think there is any particular requirement of academic specialization. If you do, you're in, as in most open source and free software. You might have to show your worth first though, as in most open source and free software.

The legend says you should contact the "Fluffy Pony" if you're interested in becoming part of the MRL, and strange and magical things may happen from there.


Is there any advantage for a regular user to run a node?

By running a Monero node, you gain access to a fungible currency (albeit with large price volatility). It is like Bitcoin, but better (subjective, of course, there are pros and cons). You can send and receive monero privately (privacy/fungibiity are the twinned major changes from Bitcoin).

The network gains decentralization too: it becomes harder to perform segregation/partitioning attacks. If you mine, you make it harder to an attacker to 51% the network (and you also get block rewards, albeit infrequently).


Are mobile wallets downloading the whole blockchain as the regular wallets?

I'll talk about monero-wallet-cli and monero-wallet-gui, since I don't know about other wallets.

It does not download the whole blockchain from the daemon. There are two things that get cut out:

first, all blocks up to (a little bit before) the wallet creation height are not downloaded at all.
second, for those blocks which are downloaded, tx signatures and related things are not downloaded

If you're creating a new wallet, this means about 1.4 million blocks aren't downloaded. For those later blocks which get downloaded, most of the block size is taken by range proofs, which are part of the data that's not downloaded.

So, in short, monero-wallet-cli does not download anywhere near the entire blockchain.

Now, monerod may be running anywhere you want. Either on the same machine/VM as the wallet, or elsewhere. If you're using the wallet on a phone, then you're probably going to run monerod either on a home machine, or a VPS, and connect your wallet to it. monerod will obviously get the whole blockchain, so you get the benefit of checking it for validity.

Last, MyMonero is being changed to that anyone will be able to run a mymonero node (at home or on a VPS, again), and you'll connect to that from your phone wallet. This will be even lighter than the current wallets, since only your own transactions (to/from you) will be downloaded, as the scanning will be offloaded to the MyMonero style server you'd be running. This is a work in progress that is not yet ready, however.


Could MimbleWimble increase privacy in the Monero network?

It's hard to answer such broad questions because answering it requires deep understanding of both technologies. But in general, throwing one thing on top of another doesn't necessarily make it better, especially if a desired feature is already present by some other means, as it is with Monero. Mimblewimble is interesting, but on its own.

It's a novel approach to a problem, but it doesn't feel like it could be compatible with what Monero is already doing in a diferent way. See here for some considerations.


Where is a good gauge of the development activity and discussions for Monero?

You can look at the commits ready for pulling at https://github.com/monero-project/monero/pulls

You can also idle in #monero-dev on Freenode IRC.


New outputs are locked for 10 blocks (unless the sender selects more), which is about 20 minutes on average. If all your monero is in a single output, then sending it will lock your entire balance for that number of blocks. There are two ways to avoid having to wait when sending to multiple recipients:

ensure your wallet is made up of several outputs, so only what you send gets locked
send to several recipients in the same transaction

For the first case, you can send to yourself, ie:

transfer MYADDRESS 10 MYADDRESS 10 MYADDRESS 10 MYADDRESS 10 MYADDRESS 10

This will send 50 monero to yourself, and you'll end up with 5 outputs of 10 monero each.
For the second case, something similar:

transfer ADDRESS1 10 ADDRESS2 5 ADDRESS3 2

The change will still be locked for 10 blocks, but you've paid the three recipients already.


Issue with Hardware Wallet after GUI v0.16 upgrade

Please see:

  Ledger Monero users, please be aware that a new version of the Ledger Monero App is required in order to properly use GUI v0.16. This release is not yet out, but forthcoming.

As far as I know, the new version of the Ledger Monero App will be out soon.

Meanwhile, you can revert back to using v0.15 until the new Ledger version is released.

EDIT: The new version of the Ledger Monero App (v1.6.0) has been released.


CLI: The new version (v0.11.0.0 at the time of writing) has an option to change your password. Simply type password and it'll provide you with an option to change your password. As a general remark, you can type help to obtain a list of commands and their options.

GUI: Currently aforementioned option isn't implemented (yet). You'd have to create a new wallet by restoring from the 25 word mnemonic seed, which allows you to set a new, different password as well.


Formulas for calculating current target and difficulty

The specific difficulty target function can be found in the source code here.

Difficulty is adjusted so that a block is mined every 120 seconds on average. What affects this is the total network hashrate and the time it's taking to mine a block. If total network hashrate is high, difficulty is adjusted up. If total network hashrate is low, difficulty is adjusted down, so that a block is expected to be be mined in 120 seconds.


I used Shapeshift to transfer BTC to Monero about 18 hours ago and it is still not showing in GUI wallet?

Check to make sure you have the latest version of the Monero wallet 0.11.1.0. The sync will stop if you have an older version.


MoneroWorld is not dead.
Unlikely a ports issue, it's all outbound. You are connecting to it then trying to start_mining and herein lies your issue - you are trying to mine on a remote public node. Please see this Q&A.


How to strengthen a light/mobile wallet such as MyMonero

The article Javascript Cryptography Considered Harmful goes through this quite well.

  Secure delivery of Javascript to browsers is a chicken-egg problem.

Newer browsers that support Subresource Integrity allow a website to specify a file hash for an external resource (a stylesheet or some Javascript). This is nice but there is nothing stopping an attacker calculating a hash for their malicious code and inserting that into the integrity attribute.


Are there any plans to make monero addresses shorter?

No. The 2 keys from which the address is made are 256-bits each, and that's how it is. You can't put 2 cups of water in 1 cup. Not using "hex" but base58 for the encoding already made them shorter, but there's only so many letters in the alphabet. If you used a bigger alphabet it would make them shorter, but probably impractical.


Is it possible to tell apart real and testnet Integrated Address

Testnet integrated addresses have 0x36 as prefix.

See src/cryptonote_config.h


(1) I understand that currently, the range proofs are done with Borromean signatures, isn't it? Not ASLN?

ASNL had a flaw, so it was changed to Borromean: What was the problem with ASNL forgery?

  (2) Does the sender communicate the blinding factors from the Pedersen commitments to the receiver? If not, how can he verify the actual amounts?

The network verifies the sum of commitments, and with that it is indirectly verified that sum(inputs) == sum(outputs). The recipient is the only one who can actually see the amount in his output, as he will know the shared secret which is used to decode the amount.

  (3) Are the commitments to 0 or to zG as suggested in the paper mentioned? I didn't quite get the need for the latter, but I'm probably missing something

I think the links above answer this as well.

  Is there more updated documentation of the current protocol available?

I don't think there is. There's the RCT paper (with ASNL) and the Borromean fix is documented here.


It is stored in /Users/[your username here]/.bitmonero

Example: /Users/sgp/.bitmonero

The .bitmonero folder is hidden by default, but it is there. The easiest is to open a Finder, hit CMD+SHIFT+G (keyboard shortcut for "Go to folder") and enter the path to open that location.


What recommendations would you have on how I can best (and most rapidly) familiarize myself with the Monero development community?

From a dev perspective, the best places to start are probably the IRC channels #monero-dev and #monero-research-lab, both of which have regular meetings and discussion. There are also open the issues and pull requests on GitHub for seeing things actively being proposed, fixed or worked on.

  I'm considering starting an open-source project for mining on Android devices (even with the inherent computational inefficiencies) as a proof-of-skill mechanism. I know of the ARMv7 code on the main branch, but is there any other relevant projects?

Monero certainly builds and runs on Android fine; there are instructions for compilation (inc. armv6, armv7 & armv8) in the main project page. It's difficult to answer your question w.r.t. other relevant projects without knowing more specifics, but there are certainly others adding Monero mining capabilities to phones, such as an recent news about HTC launching a phone that will be shipped with a Monero miner [src].


What's the difference between block height and block number?

The block height refers to the most recent block that has been mined. The block number refers to any block up until and including the current block height.

Blockchain exploring sites are generally slightly behind on listing the most current block height. When you use the status argument, the first values returned are [currently synced block]/[current block height]. The block height shown in moderod is likely to be higher than the one listed on a blockchain exploring website. I believe they rely on more confirmations before committing it to the list.


Will Monero have unconfirmed transactions problems like bitcoin?

Bitcoin has a backlog because there's only so many transactions that can fit into their 1mb blocks.

Monero has an adaptive blocksize limit so in general it doesn't suffer from this problem.  There can, however, be periods where there is a backlog because the blocksize limit isn't increasing rapidly enough.

If a miner mines a block that is too large, compared to recent blocks, it will forfeit the blockreward.  If however the transaction backlog becomes large enough a rational miner will mine a big block anyway, because a large block full of fee-paying transaction can net more than the blockreward.


How should I approach the issue that bans do not persist after ending the monerod process?

1) Not that I know of.

2) & 3) One way would be to make use of the built-in monerod commands and a little scripting. E.g.

monerod bans | awk  'NR>2 {print $1}' > bans.txt

Gets a list of any currently banned IPs. After you have restarted monerod, you could then:

cat bans.txt | while read ip; do monerod ban "$ip"; done

Which will re-ban them all.

If you want to permanently ban them though, I would add them to your firewall instead. I.e. block via iptables rules.


Why is the content of tx different between monero-utils-deserialize and print_block?

A block is not a transaction. Obviously, if you print different things, you will get different results. This should not come as a surprise.

A block may contain more than one transaction (in addition to the coinbase transaction). It appears you are comparing the block's coinbase transaction to the transactiou you had the txid for. These things are also different, and will give you different results.


What is the proper Freenode IRC channel for my needs?

In general, you can always start out on #monero, and people will point you in the right direction if another channel seems more useful. However, if you don't feel like checking in the #monero channel first, please use this guide:

For questions and discussions related to the:

use of the monero software as it exists in the release binaries and general discussions about monero, use #monero

mining of monero, use #monero-pools

trade of monero for other currencies, use #monero-markets

discussion of monero activism, use #monero-community

use of the mymonero.com web wallet, use #mymonero

active writing, modification, debugging of existing code in the github repository, use #monero-dev

active research of features that may end up being used in Monero, use #monero-research-lab

general chat with other monerians about things that aren't monero, #monero-offtopic


Monero wallet balance still zero after transfer

If setup is correct, typically how long before the coins should arrive?

One to five minutes.

  Would there be any issue with my server and wallet being offline at the time?

As long as the daemon (monerod) is synced through the date/time of the transaction, then it doesn't need to be online when using monero-wallet-cli to refresh your wallet's balance.

  if the coins don't arrive, is there anyway I can trace this from my end? What information from my friend do I need to trace?

Transaction ID's are public, so he/she can provide you that.  You could then use a block explorer like xmrchain.net or moneroblocks.info to verify the transaction is recorded in the blockchain.  On certain block explorers, you can input your address and private view key and it'll show you which outputs were sent to your address.

  Is there any issue running with the ./monerod daemon with the --offline command

Taking into account my answer to your second question, no, there's no issue. (Well, that's assuming you don't need to send Monero. If you do need to send, then you should probably not run in --offline mode when you generate the transfer, though I think you don't technically have to be online).

  On typing balance, the number of coins is still zero.

I recommend typing status into the daemon to verify the extent to which it has synced.  I would also verify the transaction sent to you is in fact recorded in the blockchain (and at what block).


How to ask a running monerod instance for mining hashrate when restricted-rpc is enabled?

You probably started monerod with --restricted-rpc. This will deny access to the mining information, as it is private (ie, none of any third party's business).

You can now start a daemon with two RPC ports, one with restricted RPC (presumably exposed to the internet) and one not. See this in monerod --help:

  --rpc-bind-port arg (=18081)          Port for RPC server
  --rpc-restricted-bind-port arg        Port for restricted RPC server

Another way is to ask the JSON RPC directly:

curl -v -X POST http://127.0.0.1:18081/mining_status -d '{}' -H 'Content-Type: application/json'

You then get the hash rate in the speed field.


Did you send funds from your wallet back to that same wallet? This warning message might reflect an inability, when observing the blockchain, to distinguish between the amount sent and the change.

When you send a transaction back to yourself, you'll create two outputs destined for your own wallet. One will be the "amount sent", and the other will be "change". Change is generated because the amount you're sending to yourself probably isn't the exact same amount as the output you're spending (especially after fees are deducted). Since both outputs are sent back to you, it's hard to later distinguish between the amount sent and the change amount, since they are both outputs indistinguishably addressed to you.


Why are there so many non-denominated amounts in the result of output_histogram?

Old dust that has never been swept. Denominations and other enhancements weren't around when Monero launched.


GUI on Windows 10 x64 with high DPI screen

This is a known issue that has been reported a week ago and not yet fixed.


I started mining right away in the XMRPool, using my payment address as the username and [worker label]:[my email] as the password.

When I login, I paste my payment address and use my email as the password. No worker label.

In the dashboard, paste your payment address again and click track live stats, so you can get a nice graph and some additional information.


converting view-only wallet to spend wallet

You do the same, except using monero-wallet-cli --generate-from-keys, which will use the spend key in addition to the view key.

You will be prompted for the information when you run this.

See a guide for using --generate-from-keys here: If I saved my view key and spend key can I recover my wallet if my mnemonic seed is lost?


Are there any proposals to create a view only wallet that lets you see outgoing and incoming funds?

View-only wallets can see the outgoing transfers if key images are imported.

In a regular wallet, the private spend key creates a key image for any output owned by the wallet.  This happens during the scan.  The key image will be there waiting when the time comes to spend an output.  At the time of preparing a transaction, the key image will be included, and the private spend key will also have to sign the transaction.

If key images are imported into a view-only wallet, the wallet will be able to find out from the daemon whether the key image is in the blockchain's list of key images.  If the key image is there, then the wallet knows that the corresponding output has been spent.

I said it already, but note that the key images alone do not allow the view-only wallet to sign a transaction, so there is no risk of turning a view-only wallet into a hot wallet by importing key images.

To address your question more directly, there have been informal proposals for view-only wallets that have a built-in ability to see outgoing transactions, but they would require further modifications to Cryptonote, and they would not come without trade-offs.  Perhaps someone else will chime in with greater detail on those trade-offs.


Will the experimental Monero Trezor firmware continue to work after January?

RingCT is not mandatory until September 2017.  Compiled v0.10.1 last night, and V0313 experimental Trezor still saw the proper balance with the new node. Have not tested sending a new transaction yet. Without the guru, we will probably need to wait until 2017-01-10 before we know the truth.

Be sure you have tested the conversion of 24 BIP 39 seed words to Electrum seed words to recover without the need for a Trezor. Test the recovery process in advance. I'm sticking with V0313 with a simplewallet --hardware-wallet 0 until judgement time.

Read NoodleDoodle's comments here, the Monero H/W wallet guru.

The edit dEBRUYNE recommended below to Monero v0.10.1 source code appears to breathe new life into Trezor V0313 Monero firmware. This has the potential to be a stop gap solution that might last until September 2017.

10 January 2017 Update:  HARD FORK DEFINITELY BROKE TREZOR V0313 FUNCTIONALITY.
[4NoT0K]: refresh
Starting refresh...
Error: refresh failed: refresh error: block parse error. Blocks received: 0
Error: block parse error Blocks received: 0
Error: block parse error Blocks received: 0
Error: block parse error Blocks received: 0
Error: block parse error Blocks received: 0


Is there an easy way of creating a transaction in NodeJs?

You can set up a Monero daemon and then connect to it with this node.js client

You should also check out  rx-monero-wallet

Both of these are reasonably documented


It's at 14.3GB (16-Jul 2017)

If you're already partially synced, you can first generate the .raw file from the data you already have:

monero-blockchain-export

and then continue downloading only what's missing:

wget -c -O ~/.bitmonero/export/blockchain.raw https://downloads.getmonero.org/blockchain.raw

and finally import the now full .raw file

monero-blockchain-import


How do I confirm that my address is attached to my wallet?

I'll take a guess you are trying to run more than one monerod instance at a time. You can do this if you assign them different ports, otherwise you'll get that address already in use error. You only need one monerod instance running at a time.

With monerod running, open monero-wallet-cli. It will ask you for your wallet file location and the password. Once provided type the command address and it will display the address associated with that wallet.


how do I make monerod play nice with process supervision?

Monero now has this feature, added two months after the question was asked (way to go responsive devs!).  Here is the pull request that added it:

https://github.com/monero-project/monero/pull/1897

To use the feature, just launch monerod using the extra option shown below:

 monerod --non-interactive

to the command line when launching monerod.  This will make it act differently than a normal unix daemon and not exit right after starting up.  Works great!


Are there any neat tricks to enable SPV like functionality for Monero?

There are various things which have been implemented to aid in light, SPV-like wallets. E.g. light-wallet support for MyMonero, more recently and related, pruning. But you correctly identify one of the main obstacles - scanning the blockchain for receiving funds.

The biggest problem with your suggested approach is divulging the view key to someone else. This is a huge privacy leak. Ultimately, you have to scan the blockchain with your view key to update your balance and get your fresh unspent outputs. This is why there has been a fair amount of work minimizing what a client wallet needs to sync to enable the scanning (this has been dramatically improved over the last year). Currently, using a remote node, the data transferred is pretty minimal for wallets to scan and the scanning code itself has been pretty well optimized.

I do like your thinking outside-the-box though. I'd suggest it best to sound these kind of ideas out in the dev IRC channel #monero-dev rather than SE - it's better suited to this kind of discussion.


How to do a lookup on a Loki Name Service (LNS) record?

The loki cli wallet has a new command titled lns_print_name_to_owners

lns_print_name_to_owners lnsname


Started monerod 0.10.1 on an AWS EC2 t2.micro instance, why does it sync so slowly?

I now found the reason, and it perfectly makes sense (took me a while to realize though, being a first time AWS user).

My instance is running on an SSD (more specifically, the volume type is called gp2), but of course I have to share the hardware with a lot of other users, so Amazon limits the IOPS. Currently you get 3 IOPS per GB as baseline performance (but at least 100 IOPS for small volumes), and you're allowed to burst up to 3000 IOPS as long as you have what they call credits. Initially you get 5.4 million credits, which allows you to burst at 3000 IOPS for 30 minutes. After that you fall back to baseline performance, and during times when you don't use the volume your credits are filled up again at the baseline rate. More details here: Amazon EBS volume types

This matches the behaviour that I observed: Synching started out quite fast, but became incredibly slow later. Based on the above, it must have slowed down after around 30 minutes, which wasn't enough to sync the whole blockchain from scratch. Hence, when running on such an instance, it might make sense to download the blockchain from the monero website.


Im going to assume you've setup a mining pool for your "custom coin", just set the correct algo perimeters on xmrig and point it to your mining pool. Nothing needs to be modified in XMRig


Simulating stealth address construction with JavaScript

1) Private keys are a randomly chosen 256-bit number mod l. l being 2^252 + 27742317777372353535851937790883648493.

2) All the functions needed are in the source files of the site linked in the questions answer you linked to. Just use your browser debugger to access them.


How can I check my balance in mining pools that dont have an login/account option? like XMRpool

So problem solved - I did a stupid mistake. I did everything acording to this tutorial https://www.usxmrpool.com/#easy_mining_guide, which I find well done (for noobs like me), but I wanted to mine in a different pool, than the tutorial shows. When I checked the pool adress in config file, I overloocked that I didnt change it. There is a lot of pools with similar names so be avare of it (like xmrpool.eu and usxmrpool.com).
Thank you


Is it possible to fake the date of arrival of funds?

No, this is not possible.

Knowledge of the private keys for a wallet will identify the specific outputs on the blockchain owned by the wallet. The blockchain holds an immutable record of the creation timestamps of those outputs.

The closest thing to what you're looking to achieve is to send the funds from your wallet to the other person's wallet. Monero's ring signature will obfuscate the actual outputs on the blockchain that you're spending. If your ring size is 7, then for each real output you're spending, there are 6 other outputs your transaction will reference that you could have been spending instead. Therefore the timestamps of the outputs being spent could be the timestamps of any of those 7 outputs.

To fake a particular timestamp for the outputs you're claiming to spend, you'd therefore need to ensure that for each real output you're spending, your transaction's ring signature references a decoy output that has the timestamp you wish to fake. This would require manual construction of your transaction so that you can directly specify which outputs to use as decoys. This is a feature that does not yet exist, so you'd need to make modifications to your wallet software to do this.

Of course, this method falls apart if they simply ask you for the wallet view key for the outputs you claim to originally have received. You'd have to claim you lost it after sending them the funds...


Is userland running monero gui possible and safe?

As with any used computer, I'd advise wiping it, reinstalling the operating system before using it, to ensure the previous owner hasn't installed anything malicious on it.

Then running Monero on it will be fine. Running in userland (user space), is preferred.


How do I check balance on my offline wallet while I did not assign any transaction ID?

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.


This Wiki article on CryptoNote explains it better than anyone could do in the confines of a Stackexchange reply.

The Proof-of-Work algorithm is called CryptoNight and has several distinct differences/improvements over the earlier SHA256 algorithm used by Bitcoin and clones.

edit: This looks more like an actual specification


RingCT: What happens if accidentially decoy "Input + Output" sum up to 0?

Think of ring signatures as rows. When a single input is being spent, there is a row for each possible input (all are decoy inputs except for one real input). Each row contains a proof that a particular input is being spent, and a proof that the sum of that encrypted input amount - all encrypted output amounts - fee = 0.

The way ring signatures work is that you can't tell which row contains the real proof, but you know for sure that one of the rows must contain a valid proof (and that the valid proof row correlates with the declared input key image). Because each proof applies to the entire row, you can't mix and match encrypted input values from one possible input with a spend of a different input in the ring.

In the case of multiple inputs, there is a ring signature for each real input. The spender generates a "pseudo-out" for each of those rings, which is a re-encryption of the value of the real input being spent (using a different 'blinding factor' so that you can't tell which original encrypted input value this a re-encryption of). These pseudo-outs are declared by the spender as part of the  transaction. Each row also proves that the declared psuedo-out is an encryption of the same value as the original encrypted input amount value for the input in that row. It is also  then proven that the sum of all "pseudo-out" re-encrypted input amounts - all encrypted output amounts - fee = 0. Again, only the proof contained in one row of each ring signature is the genuine proof, and you can't tell which row this is.


Different view key and spend key after importing private key?

For deterministic wallets, you might want to use addresstests JavaScript-based code to examine a low valued Monero wallet.

Also examine results of the XMR C++ package script commands:

% echo "wipeout unnoticed origin timber corrode diet vats fences budget rotate iguana hive koala tuition shackles ticket fossil edited long beer shuffled lukewarm cogs atom hive" | ./inverse_mnemonics | ./xmr

Seed                 : b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9
Private Spend Key    : c3b6b5a322e23c37ec9ac7edadd379d6c384efe37a5380ee9088f7ace2efcd09
Private View Key     : c8bc08b2d1ddb3056c43326f3576f7b20e3f626bb00a8ef3b4975dceeab85301
Public Spend Key     : d4ccd3a5f5af9ae368ef20ddc33a7c6422945dc2d1cb61c10c201752ece97bcd
Public View Key      : 90311e7f42443ad0579229154164fbaf882e0b9b0ae3caa728fb9ba6010899e2
Monero Address       : 49gq7ur2BzHf3ALDLNBJ4jHkSGcUT92AtZHoUS6ykkBLbPDpWV2VJrDbrBPV5G5kpzWMt2iXUwYNDUxfQqe4McMvSc79f9W
Electrum Seed Words  : swiftly potato fugitive upstairs jailed people plywood moon koala reunion repent muffin knuckle tugs sewage ticket fossil edited long beer shuffled both gills hexagon beer

% ./sc_reduce32 b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

c3b6b5a322e23c37ec9ac7edadd379d6c384efe37a5380ee9088f7ace2efcd09

% echo b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9 | ./bytes_to_words

wipeout unnoticed origin timber corrode diet vats fences budget rotate iguana hive koala tuition shackles ticket fossil edited long beer shuffled lukewarm cogs atom hive

% echo c3b6b5a322e23c37ec9ac7edadd379d6c384efe37a5380ee9088f7ace2efcd09 | ./bytes_to_words

swiftly potato fugitive upstairs jailed people plywood moon koala reunion repent muffin knuckle tugs sewage ticket fossil edited long beer shuffled both gills hexagon beer

Notice with sc_reduce32 normalization how two different seeds (represented as hexadecimal numbers or Electrum seed words) will result in the same set of spend keys, view keys, and the same address.


Sometimes, the wallet's idea of what outputs are spent and what outputs are not get out of sync with the blockchain. This can happen if you exit the wallet without saving after sending a tx, or if it crashes.

rescan_spent will look for the key images on the blockchain to make sure it's up to date.

Since this involves sending your key images to the daemon, it needs a trust daemon, since otherwise this is a privacy breach. So if you are using a remote daemon, you will only be able to use that command if you started moneor-wallet-cli with the --trusted-daemon option (by default, local daemons are trusted).


Mining on Linux server, are there security risks?

There would be no inherit security risk with mining on your dedicated server.  As with all daemons, though, you would want to make sure to run it as an unprivileged (non-root) user just as a best practice.

Since you mention the server is normally doing other things (hosting websites) you could minimize its impact by running it the lowest priority possible (a 'nice' value of 19).  If you do that, it should effectively only utilize idle cpu cycles and not noticeably impact the performance of other processes.  Doing this is as simple as running:

nice -19 ./xmr-stak-cpu

Some important notes...

Keep in mind that your processor(s) will be running at 100% usage 24/7 no matter what's going on.  This effectively kills the usefulness of any sort of CPU metrics software and other performance monitoring software.
If you provide service to paying customers, note that they will be able to easily see the system is at 100% cpu usage through multiple means (SSH, PHP scripts, hosting control panel, etc).  They may not take kindly to this fact and feel you are not providing the service they're paying for.  Some users may suspect your server is compromised if they see a miner process in the process list.  This is because it is common for malicious users to compromise hosting accounts and run a monero or other cryptonight based coin miner on the server.  I imagine there's a debate to be had on the ethics of mining on a production hosting server with paying clients.
It will be much harder to identify if/when another user on the system is using excessive CPU since your system will always be at 100% CPU usage, unless you write some custom script that subtracts the relative usage of the miner from the rest of the system's usage.  Even then, it's going to be unreliable.
Even if you ONLY ran the miner on your server and didn't host websites or anything else, you're probably looking at between 200-250H/ max (for a Quad-Core single CPU dedicated server).  At the current network difficulty, a sustained 250H/s is going to net you about 0.05 XMR per month (I used cryptocompare.com's calculator to estimate).  A common minimum payout for current Monero mining pools is about 0.3 XMR.  So you are looking at 6 months mining before you get your first 0.3 XMR.  Coin emission only slows and difficulty only goes up as time goes on, so the reality of it is probably longer than 6 months.  If your server is somewhat busy and the miner runs at less H/s, then that time only gets longer.

In the end, only you can decide if it's "worth it".  But, it's by no means an ideal or lucrative situation.


Missing TX, 24+ hours and XMR is missing :(

If the transaction is not recorded on the blockchain (as suggested from you looking up your tx ID), then the outputs you were trying to spend are still unspent and still owned by your wallet.

Please update your daemon and wallet.  Your daemon may be on a forked-off outdated chain (along with other daemons who failed to update).  And then you may need to let your wallet rescan, once you know you're on the current (actual) chain.


You can purchase Monero for cash directly on sites like https://localmonero.co/. Alternatively buy BTC for cash somewhere like https://localbitcoins.com/ and convert to BTC to XMR on something like Bisq or ShapeShift.

You specifically stated "pay in cash" which is why I didn't list alternatives.

To store on a Ledger, you will need to set this up first (either using the Monero GUI or CLI) and use your new wallet address as your receiving wallet when you buy your XMR. A GUI guide can be found here and CLI here.


This is not a direct answer to your question, but instead another very security conscience approach that already has working code.

Hardware HD cryptocurrency wallets such as Trezor is a two factor device that is immune to key loggers. The Monero Team now has Monero functioning binary code for Trezor devices and its source code posted here. The code is experimental at the moment, but my testing indicates it is stable.

Additionally, the Trezor Password Manager is also very likely to be more secure than Keepass for managing symmetric personal website account passwords passwords.  Trezor also recently started to support U2F.


You need to have a cold and hot wallet pair for the same account.

In the hot wallet, make a transaction. It doesn't have the spend key, so instead of actually sending the transaction to the Monero network, it will save the necessary information to a file called unsigned_monero_tx (no choice of name for now).

Next step is to transfer that information to the cold wallet's computer. Depending on your degree of security, you may use a USB drive, transcribe it by hand, or find some file transfer program that uses QR codes, or whatever else you want.

On the cold wallet, run sign_transfer. This will load that file, and display the details of the transaction, then prompt you whether you want to sign it. If you do, the signed transaction will get written to signed_monero_tx. Which you get to copy back to the hot wallet computer.

On the hot wallet, run submit_transfer. This will relay the transaction to the Monero network, as well as update balance and spend state of the outputs.

Note that this system does not need the cold wallet to have a blockchain, as the unsigned_monero_tx contains all the information the cold wallet needs to sign the transaction. Only the hot wallet needs to talk to the daemon.


Making non-native tokens private by using RingCT

RingCT is basically the combination of three things: ring signatures, stealth addresses (one-time output keys) and CT (Confidential Transactions).

The ring signature provides sender ambiguity, the stealth addresses (one-time output keys) hide the recipient address from the blockchain and CT is used in hiding the amount. Combined, you have the properties needed for a private fungible asset because the asset has no history to follow - 1 XMR will always be worth 1 XMR - they are indistinguishable.

ERC721 is for non-fungible assets, so I'm not quite following why you would want to use RingCT. That said, if you just wanted to make use of CT, to hide the value (or any other integer for that matter), it is not a particularly difficult construct to grasp.

CT requires two generators, a binding factor and the amount. A Pedersen commitment is then created like xG + aH (x and a being the binding factor and amount, G and H being the generators). Note you cannot recover the amount from the commitment - its a commitment to a value, not encryption of a value. Therefore in Monero, ECDH is employed to pass the amount encrypted separately (within the tx), which also means you need some mechanism to have a shared secret, for which Monero neatly places in the tx extra field. Also note, if you are using CT for a tx amount on a blockchain, you will also want to employ a range proof to prove the amounts in the commitments fall within a positive range (to prevent inflation).

For reference, the original CT paper can be found here: Confidential Transactions

When I think of non-fungible assets, provenance springs to mind - you want a transparent history of that asset - which is contradictory to what you get with RingCT.


Why does my Monero wallet refresh so slowly?

Latest Monero software has improved a lot the speed of refresh, be sure to have the right version from GetMonero.Org installed.

Also, if you're using a remote node, try to check if another node is faster.


Is there a bitmonero.conf file where I can hard code a --daemon-address for use when running monero-wallet-cli?

There is no default wallet config file IIRC, so just put all your wallet specific settings in a file like ~/.bitmonero/wallet.conf and then start your wallet like:

monero-wallet-cli --config-file ~/.bitmonero/wallet.conf

You can put any of the startup paremeters as listed from monero-wallet-cli --help. Just omit the leading -- and place one option per line. So for your daemon-address it would look like:

daemon-address=node.moneroworld.com:18089


Lost monero money after switching wallets

What probably happened is that you hit a bug which skips early scanning, but skips too much.

If this is indeed the reason, you can fix it by doing this:

exit the GUI
rename the wallet cache, eg adding ".old" [1]
restart the GUI, and wait for the cache to be rebuilt

[1] The wallet cache is one of three files created by the wallet. Assuming you named your wallet "XYZ", then the files would be XYZ.keys (important, back this up and keep it secret), XYZ (that's the cache we're talking about here), and XYZ.address.txt (your public address). So in this example, you'd rename XYZ to XYZ.old. Those wallets are in ~/Monero/Accounts (if you're on Windows, just search the disk for XYZ.keys to find it).


Transaction structure: Question about ecdhInfo

Both the ecdhInfo mask and amount are encrypted by the sender of the transaction.

Both are encrypted (each in a slightly different way) using the transaction's shared secret (aR).

Therefore both encrypted values will be randomly distributed, and thus cannot be validated by a third party.

If the sender of the transaction had somehow written faulty values into the transaction, the only consequence would be that the outputs created by the transaction would be unspendable.

The code that encrypts and decrypts the ecdhInfo values is here: https://github.com/monero-project/monero/blob/2b00899bb28e09f0c44813689acc0add73832215/src/ringct/rctOps.cpp#L447


Elliptic curve encryption uses numbers called scalars (which are used as private keys). Valid scalars should be less than the group size of Monero's base point, i.e. the maximum allowable value of a scalar is 2^252 + 27742317777372353535851937790883648492

The sc_check method therefore verifies that the number is not too big. It does so in a strange way so that it runs in constant time. This prevents timing attacks that could leak information about the size of the scalar.

Math.pow(2,252) + 27742317777372353535851937790883648492 ==
1559614444 * Math.pow(2,8*4*0) +
1477600026 * Math.pow(2,8*4*1) +
2734136534 * Math.pow(2,8*4*2)  +
350157278 * Math.pow(2,8*4*3)  +
0 * Math.pow(2,8*4*4)  +
0 * Math.pow(2,8*4*5)  +
0 * Math.pow(2,8*4*6)  +
268435456 * Math.pow(2,8*4*7)


Mining from multiple servers to local wallet

While monerod does the mining, it does not control/manage wallets, and just uses whatever wallet address the user tells it to.

Therefore, if you created one wallet with address A on some computer, any monerod can mine to that wallet address by giving A to the start_mining command, ie:

start_mining A 3

This will start mining to wallet A with three threads.

Wallet A could well have been created on an offline computer. The public keys represented by the address are enough to mine to it.


Can Monero miners be picky about adding transactions to blocks

Partially.

Miners can't know who send how much to who. What miners do know is the fee associated to the transaction. One way miners can "select" transactions would be to prioritise higher fees, which is actually how a lot of cryptocurrencies work.

What miners can't do is prioritise transactions, on their own, to/from addresses. They would only be able to do so if the transaction maker gave them the tx-id.

  With Bitcoin, miners are picky about which transactions to add to blocks due to the limited block size

This won't happen on the long-term with Monero due to the Dynamic Block Size which specifically prevents a Bitcoin situation from occurring.


Monero fork wont mine blocks after height 3062

Block creation sometimes takes more time and sometimes less, also the time to be mined increases with difficulty.

Your daemon functions properly without any incoming connections, but if you want to open port 17070 in the right way, you have to forward/open it in your router too and not only in Linux/Windows firewall.


Your Monero is safe. There was a load-from-keys bug with v0.8.8.6

Download the current Monero release or build from source and you will be able to recover using your .keys file and password

After recovery use the "seed" command in simplewallet and record your mnemonic seed in a safe place for offline cold storage.


Does recipient of monero see wallet address?

No they will not see your address.

In the transaction recorded on the public blockchain, some of the inputs will reference outputs (belonging to you) of a previous transaction. Knowledge of those outputs alone will not be enough to find your public address.

Even if someone knew your wallet address, without your private view key, they will not be able to know which transactions are yours and how much monero you have.


If wallet addresses are like bank account numbers, then subaddresses are like having lots of different bank account numbers for the same bank account.

This means that if you want Alice and Bob to pay you, you can give out a different bank account number to each of them. They then can't confer to figure out they're dealing with the same person.

This also means that if you transact with Alice on multiple occasions, you can give her a different bank account number each time, and she won't be able to know you're a repeat customer.

It's up to you to decide whether this level of privacy is useful to you or not. There is no penalty for using subaddresses. Use them as much or as little as you want.


How to show fees paid on show_transfers command in monero cli?

It does in fact show the fee.
For incoming transaction, the columns in the show_transfers output are:

<block_height> in <date> <amount_received> <txid> <payment_id>

For outgoing transaction:

<block_height> out <date> <total_amount_sent> <txid> <payment_id> <fee> <receiving_addr_1> <amount_1> <receiving_addr_2> <amount_2> ...

Another option is to get the txid of the transaction you need, using show_transfers, and then you can run show_transfer <txid> (that's a different command, no 's' at the end) to get more details about this specific transaction, which includes the fee.


When you receive funds into your Monero wallet, Monero's privacy features mean that you cannot tell the wallet address of the sender.

Therefore if you have lots of people sending funds to you, you can ask people to identify themselves with a particular payment ID. Since you probably do not transact frequently, it will be obvious to you when the funds arrive from the exchange, so you do not need to provide them with a payment ID or any information other than your wallet address.


When constructing a change output, must it be destined for the main public address?

It's possible to send change to any subaddress/account inside any wallet where you know the private view key and public spend key for that wallet. (If you were not sending to a subaddress destination, then you could send change to any wallet where you only knew the public view and spend keys).

The wallet rule is currently that outputs can be spent together if they are received to any subaddress within the same account. Therefore to achieve what you're talking about, you'd need to send change to a different account within your wallet.

Now, however, you have a new problem. If change outputs from that new account were spent together, you'd have the same kinds of traceability problems.

If churning is deemed effective, the solution is probably to have a 'high privacy' wallet mode, where every change output is kept track of by the wallet, and churned several times before becoming available for spending. You'd not need to bother with sending change to different subaddresses, because the wallet would be easily capable of keeping track of which outputs are change and how many times each change output has been churned.

Alternatively, you could reason that as long as outputs in a particular account are always churned before entering that account, and if that account is only used to spend funds with entities that are not aware of your real-world identity, then it doesn't matter if change outputs are churned. You'd simply have an account for spending with people that know your real identity, and another account for people that don't. This has the benefit of it not being necessary to churn every single change output. You'd only need to churn prior to filling the high-privacy account with funds, and prior to withdrawing funds from that account to an exchange or real-world-identity account.


Some fixes were merged to the master branch recently, so should make the next release (any day now™).


Can monero-wallet-cli be run as a light wallet?

This is a bug: the restore height should have been taken into account. If you don't specify a restore height, it actually works (you get asked for one, which is used). This will be fixed.


The reason to use a hardware wallet is so that your seed is safe even if your PC has been compromised. So it's therefore by design that the seed is not visible in the GUI.

You need to back up the Ledger's main seed, which is what your Monero seed is derived from. This is how you will restore access to all funds held in the Ledger if you lose it or it breaks.

You can convert your Ledger seed into your Monero seed using this tool: https://github.com/LedgerHQ/ledger-app-monero/blob/master/tools/python/README.md


Great suggestion by PyRulez. Making up a song with the words is another way to memorise them. Of course, this doesn't mean you should only have the song, you need to have a physical backup too just in case!


How to switch the algorithm according to hard fork height?

Every hard fork introduces a new version that is programmed to "handle" the fork. Something like "Up until block height XXX do this, starting from block height XXX+1 do that".

Older versions will not be able to do that, because when they were released, no one knew what will the requirements be for the next hard fork. This is the reason that before every hard fork people are being told over and over to update their version.

Every hard fork relies on the hope that most of the network will upgrade to the new version - something that goes pretty well so far.


Transfer with wallet rpc do_not_relay=true do transfer

Your parameters account_index and do_not_relay are not in the params object, so are ignored.


Why is it necessary in confidential transactions to have two generators?

Normally C = xG + aH where a is the amount and x is the blinding factor.

The point of a Pedersen Commitment is to commit you to a certain value of a. If instead you had C = xG + aG, then this simplifies to C = (x+a)G. So you could claim any value of a later by claiming you'd used a different blinding factor. Using H, which has an unknown DL w.r.t. G, prevents you from doing this.