How can I create a million blocks in regtest or testnet? Can anyone please tell me how to create a million blocks in regtest or testnet mode? Is there a way other than to start mining with the smallest difficulty?

Creating a private testnet and setting the difficulty very low is an easy way. You can start your testnet nodes passing the flag --fixed-difficulty N (where N is a very low number), so your mining node mines blocks near instantly.

There is also a new RPC command generateblocks, that can generate a bunch of blocks in regtest mode. It's currently not documented, but see the commit message. To use it, you would start monerod with the --regtest flag and the --fixed-difficulty flag (as detailed above). Then you can call the RPC interface passing the parameters: amount_of_blocks and wallet_address. For example:

curl -X POST http://127.0.0.1:18081/json_rpc -d
  '{"jsonrpc":"2.0","id":"0","method":"generateblocks","params":{
  "wallet_address":"44GBHzv...","amount_of_blocks":1000000}}'
  -H 'Content-Type: application/json'


How do I generate a Trezor Monero wallet with the GUI (monero-wallet-gui)? According to the release notes GUI v0.14.1.0 includes Trezor support (for the model T). How do I generate a Ledger Monero wallet with the GUI (monero-wallet-gui)?

Before we start, first two notes:

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

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

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

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

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

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

Make sure your firmware is up to date.

Your Trezor needs to be plugged in.

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

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

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

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

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

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

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

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

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

Enter a new Wallet name

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

Leave the Subaddress lookahead (optional) box blank.

Make sure the Device name is set to Trezor

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

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

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

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

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

Press Use Monero.

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

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

A few final notes:

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

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

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

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

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

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

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

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


Monerod has stopped working Monerod was working correctly, but suddenly stopped.  I tried downloading the latest version (monero-gui-0.11.0.0) in the hopes that that would solve the problem, but it doesn't.  When I try to start the program through the terminal rather than via the GUI, I am told the program doesn't exist even though the ls command shows it very clearly.

I am running Ubuntu 14.04, and was doing so when it worked correctly earlier.

The bitmonero.log says:

2017-09-14 10:57:06.331     7f1519564780    INFO    logging contrib/epee/src/mlog.cpp:148   New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO
2017-09-14 10:57:06.331     7f1519564780    ERROR   msgwriter   src/common/scoped_message_writer.h:102  Error: Couldn't connect to daemon: 127.0.0.1:18081

And the monero-wallet-gui. log says:

2017-09-14 10:56:52.394     7fab3bc417c0    INFO    logging contrib/epee/src/mlog.cpp:148   New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO
2017-09-14 10:56:52.792     7fab3bc417c0    INFO    logging contrib/epee/src/mlog.cpp:156   New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO
2017-09-14 10:56:52.991     7fab3bc417c0    INFO    logging contrib/epee/src/mlog.cpp:156   New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO
2017-09-14 10:56:53.037     7fab1bfff700    ERROR   net.http    contrib/epee/include/storages/portable_storage.h:161    portable_storage: wrong binary format - signature mismatch
2017-09-14 10:56:53.037     7fab1bfff700    ERROR   wallet.wallet2  src/wallet/wallet2.cpp:2128 !r. THROW EXCEPTION: error::invalid_password
2017-09-14 10:56:53.037     7fab1bfff700    WARN    net.http    src/wallet/wallet_errors.h:707  /home/vagrant/slave/monero-core-ubuntu-amd64/build/monero/src/wallet/wallet2.cpp:2128:N5tools5error16invalid_passwordE: invalid password
2017-09-14 10:56:53.038     7fab1bfff700    ERROR   WalletAPI   src/wallet/api/wallet.cpp:504   Error opening wallet: invalid password
2017-09-14 10:56:53.077     7fab1bfff700    ERROR   WalletAPI   src/wallet/api/wallet.cpp:553   Status_Critical - not storing wallet
2017-09-14 10:57:04.550     7fab1b7fe700    WARN    net.dns src/common/dns_utils.cpp:487    WARNING: no two valid MoneroPulse DNS checkpoint records were received

I am told the program doesn't exist even though the ls command shows it very clearly.

Need more info here.  Sounds like monerod is just not in your $PATH perhaps?  If so, you need to use the full path to the executable.

  monero-wallet-gui. log says...

I see invalid password in the log, have you checked for sure that the password is correct? (remove all special characters / symbols to test).  Are you even using a username / password?

Are you sure that monerod is configured to accept incoming RPC on IP 127.0.0.1 and port 18081? (the default)


How did it happen that there is a monerod process started by root on my laptop? Is it possible without installing any Monero related packages on my Ubuntu 16.04 laptop with a gforce gtx 960m, that I have a monerod process running, started by root?
Any virus?

Thanks.

If you did not install monerod, then someone else did, and it's likely malware. It seems surprising for two reasons, however:

that kind of malware usually runs on Windows
a mining malware would typically use a pool miner, since monerod needs to download the blockchain

Therefore, the most likely explanation is that you or someone who uses your computer installed Monero software.

One thing to note: the Monero GUI wallet can start monerod automatically, so if you tried it, this might be why.


What contributions (if any) are there to the overall blockchain size, other than the actual transaction sizes? Given that the median transaction sizes are so similar between Monero and Bitcoin (see this question), what other contributions are there to the overall blockchain size (e.g. database overheads or other Monero-specific contributions)?

I ask as someone not terribly familiar with databases and blockchain storage codebases between different cryptos. I don't see why there is so much concern over Monero's scalability with respect to blockchain size if the median transaction sizes are so close, unless there are other factors I am not aware of.

Edit: I have just realised that the statistics linked to in the answer to the question linked refer to the median block size, despite saying transactions size. If there are empty blocks then obviously that will bring down the median block size. What I am interested in is the median transactions size when compared to Bitcoin. If anyone can shed light on this then it would be much appreciated.

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


What is the purpose of the tail emission? What is the purpose of the tail emission? How does it relate to dynamic block sizes and miners penalties?

The first question one needs to ask before even considering adaptive
  blocksize limits is: Can a fee market actually work in the absence of
  a base emission?

  We first consider a blocksize large enough (or effectively infinite). In this scenario competition among miners will drive fees
  towards zero since there is no scarcity. This will in turn cause the
  difficulty and consequently the security of the crypto currency to
  collapse. We must keep in mind that orphan block based arguments will
  also fail since these are based on the presence of a base emission.
  This is in fact the very legitimate fear of the small block
  proponents.
  In the second case we consider a fixed blocksize, where the blocksize is small enough to impact fees. In this scenario we have a
  potentially infinite demand with a fixed supply. In theory fees
  therefore would go to infinity. We must keep in mind that as the
  legitimate demand rises towards the fixed limit, It becomes
  economically attractive for miners with a even small percentage of the
  hash rate to spam the network in order to profit by raising the
  overall fees. At this point only external competitive factors can stop
  the fees from rising to infinity. These take the form of fiat payment
  methods and other crypto currencies with the latter being not affected
  by a fixed blocksize limit. The impact of these external competitive
  factors is to reduce demand by devaluing the entire crypto currency.
  This will be delayed by miner spam, as miners will increase the spam
  in order to preserve the dwindling purchasing power of their fees
  until the system collapses to little or no transaction demand leading
  the first case above.

  The problem as I see it is that the system is inherently unstable.
  Either the mining revenue collapses first or the purchasing power of
  the mining revenue collapses first. We now come to the next question.
  Can one create an adaptive blocksize limit formula that does not
  converge as time increases towards (1) or (2) above? My instinct tells
  me no, particularly since the network has no way to measure the key
  parameter namely the amount of fees collected per block due to out of
  bound payments to miners. Furthermore there have been many brilliant
  minds looking at this issue and they have not come up with a solution.
  Proving this negative, in a rigorous mathematical sense, is of course
  another matter entirely. What the tail emission in Monero does is
  provide a stable anchor outside of the control of the miners on top of
  which an adaptive blocksize limit and a fee market can actually
  develop, by avoiding the instability above.

source: ArticMine


Can someone walk me through a simple example to explain how RingCT works? Original:
https://www.reddit.com/r/Monero/comments/5irg81/questions_regarding_the_cryptography_behind_ringct/

I just read the RingCT paper, and there are a couple things that could use some clearing up for me.

What is the m (message?) value that is used in all of the hashes (and one of the indexes for the signature)? Is this our mixin value?

Also, does the actual signature in the RingCT implementation contain the presumably long list of randomly generated s-values? And are all of those s values generated independently from one another? Are they basically the equivalent of the q and w random scalars chosen in the CryptoNote whitepaper?

Can someone walk me through a simple example showing how many of these random numbers must be generated for a given transaction? For instance, if I want to send to one person 18.37 XMR with a mixin of 4.

If there really are so many additional parameters, as seems to be the case, why exactly does RingCT take up less space on the blockchain?

Thank you so much!

Let's say you'll use two of your outputs, 12.34 XMR and 7.89 XMR and send 18.37 XMR to your recipient for a fee of 0.022 XMR and change of 1.838 XMR. If you use mixin of 4, you'll be creating two rings with 5 output keys contained in each. You'll pick a secret index between 1 and 5 for each ring, so let's say you picked 2 for the first and 4 for the second. I.e., you know the private keys of these two output public keys:

P_2^1 = x^1 G
P_4^2 = x^2 G

Here, underbar is used for denoting an index in a given ring (1,...,5), while hat is used for denoting the index of an input (1 or 2).
You also know the masks for the Pedersen Commitment paired with P_2^1 and P_4^2:

C_2^1 = a^1 G + 12.34 H
C_4^2 = a^2 G + 7.89 H

Then, you choose dummy ring partners to create two rings:

( P_1^1, P_2^1, P_3^1, P_4^1, P_5^1 )
( P_1^2, P_2^2, P_3^2, P_4^2, P_5^2 )

Note that each P_i^j has its associated Pedersen Commitment C_i^j.
Now you generate what's called pseudo output for each ring (which is not officially described in MRL-0005, see Issue #6 in the GitHub repository):

D^1 = b^1 G + 12.34 H
D^2 = b^2 G + 7.89 H

where b^1 and b^2 are random scalars. These pseudo outputs are recorded in the transaction. Let us define another pubkey:

Q_i^j = D^j - C_i^j

Important thing to note here is that you know the secret keys of:

Q_2^1 = (b^1 - a^1) G = z^1 G
Q_4^2 = (b^2 - a^2) G = z^2 G

These secret keys are needed for signature generation. You also need to generate two key images:

I^1 = x^1 HashP(P_2^1)        // HashP(.) outputs an EC point
I^2 = x^2 HashP(P_4^2)

With these ingredients at hand, you can generate the signature as follows: first randomly pick alpha^1 and beta^1 and compute:

L_2^1 = alpha^1 G
R_2^1 = alpha^1 HashP(P_2^1)
S_2^1 = beta^1 G
c_3^1 = HashS(Msg, L_2^1, R_2^1, S_2^1)     // HashS(.) outputs a scalar

Here, Msg is the message describing the transaction: e.g., which output pubkeys constitute each ring, the fee, the newly generated output pubkeys, etc.

Then you randomly choose r_3^1 and s_3^1 and compute:

L_3^1 = c_3^1 P_3^1 + r_3^1 G
R_3^1 = c_3^1 I^1   + r_3^1 HashP(P_3^1)
S_3^1 = c_3^1 Q_3^1 + s_3^1 G
c_4^1 = HashS(Msg, L_3^1, R_3^1, S_3^1)

You repeat this computation two more times with the index being incremented, and the index goes back from 5 to 1:

c_1^1 = HashS(Msg, L_5^1, R_5^1, S_5^1)
L_1^1 = c_1^1 P_1^1 + r_1^1 G
R_1^1 = c_1^1 I^1   + r_1^1 HashP(P_1^1)
S_1^1 = c_1^1 Q_1^1 + s_1^1 G
c_2^1 = HashS(Msg, L_1^1, R_1^1, S_1^1)

And you do a trick to r_2^1 and s_2^1 as:

r_2^1 = alpha^1 - c_2^1 x^1
s_2^1 = beta^1  - c_2^1 z^1

This makes the following magic possible:

c_2^1 P_2^1 + r_2^1 G            = c_2^1 P_2^1 + (alpha^1 - c_2^1 x^1) G            = alpha^1 G
c_2^1 I^1   + r_2^1 HashP(P_2^1) = c_2^1 I^1   + (alpha^1 - c_2^1 x^1) HashP(P_2^1) = alpha^1 HashP(P_2^1)
c_2^1 Q_2^1 + s_2^1 G            = c_2^1 Q_2^1 + (beta^1  - c_2^1 z^1) G            = beta^1 G

I.e., the hashed value c_3^1 becomes independent of (c_2^1,r_2^1,s_2^1).

For anyone but you, the resulting sequence of numbers (c_1^1, ..., c_5^1) looks really magical because the following special relationship holds:

c_2^1 = HashS(Msg, <some value depending on (c_1^1, r_1^1, s_1^1)>)
c_3^1 = HashS(Msg, <some value depending on (c_2^1, r_2^1, s_2^1)>)
c_4^1 = HashS(Msg, <some value depending on (c_3^1, r_3^1, s_3^1)>)
c_5^1 = HashS(Msg, <some value depending on (c_4^1, r_4^1, s_4^1)>)
c_1^1 = HashS(Msg, <some value depending on (c_5^1, r_5^1, s_5^1)>)

No one but you can create this and know which keys are fake, hence the unforgeability and anonymity of the ring signature scheme.

This way, the first ring signature is generated:

R^1 = [ Msg, (P_1^1,...,P_5^1), (C_1^1,...,C_5^1), I^1, D^1, c_1^1, (r_1^1,...,r_5^1), (s_1^1,...,s_5^1) ]

In practice, P_i^j and C_i^j are stored somewhere in the blockchain and the signature contains only indices of them. You do exactly the same computation for the other ring R^2.

You'll also create two new output pubkeys along with their associated commitments corresponding to 18.37 XMR for your recipient and 1.838 XMR for your change. You randomly choose e^1 and e^2 such that

b^1 + b^2 = e^1 + e^2

and compute two commitments:

E^1 = e^1 G + 18.37 H
E^2 = e^2 G + 1.838 H

This way, anyone can observe that the total amount is the same before and after the transaction:

D^1 + D^2 = E^1 + E^2 + 0.022 H

(I omitted the range proof part which is needed to ensure that every amount in a commitment is between 0 and 2^64 .)

See also: Can I manually check consistency of Pedersen Commitments in RingCT?


Several good CPUs with a very bad hash I have a question. I have 5 good machines mining Monero. In average each machine give me about 300H/s.

So if I have 5 machines, I am suppose to have 1500 H/s.

I am not doing solo mining but I am using a monero pool with 12MH/s.

My question is.. why when I check the pool website I never got my 1500H/s ? I see 1000, 600, 900, 1200, and other variations but never 1500H/s.

Is the pool the problem ? Should I try solo mining ?

Many thanks!!!

That is normal because the pool stats are generated based on actual number of accepted shares. The pool is counting how many valid shares it receives from you in some time window and calculates your average hashrate based on that. It's an estimate - the pool can not monitor your CPU cycles to know exactly how much hashes it actually generates to complete a share.

Because the process is not deterministic, it will always oscillate. Your CPU is really just rolling random numbers, doing some calculation on them, and checking it vs the share target. The pool doesn't know how many attempts it took to guess a solution, but the faster the CPU, the faster you'll be able to find a solution and the pool can only monitor the time between two solutions to estimate the hashrate.

Note that there's always some wasted time when communicating with the pool. You don't want to be finding shares too fast otherwise you'll have too much overhead just for "talking" with the pool. If you're solving shares too quickly, try increase the difficulty and see what happens, you could get more effective H/s. Just avoid setting it too high otherwise you'll get a lot stale shares so you're really looking for some optimum there. Trial & error :) Network latency is also a factor, so you might want to try a pool with the lowest ping.


How does one go about setting up a mining pool? There are already a number of mining pools out for Monero, are there instructions or software that people can use to set up their own mining pool?

The Monerodo OS from gingeropolous is a customized version of Ubuntu that includes Monero Core, Monero Pool Server, Nvidia mining software, various CPU mining software, and the MiniNodo Wallet server, already preinstalled and is easily configured with a simple text menu interface.

Step by step Monerodo OS instructions

Alternatively this CryptoNote pool mining software is free and open source

git clone https://github.com/zone117x/node-cryptonote-pool.git pool
cd pool
npm update

Configuration instructions can be found here


Physical vs. virtual mining Which would be better, many physical servers mining or one virtual machine running on openstack and adding hardware as you go?

Thanks.

Monero mining uses the AES-NI instructions from the Intel processor, as well as memory, and raw processor speed. Therefore, adding VMs will just add unnecessary overhead. The best way to mine is to run on the physical machine, with a number of threads that's optimal (determined by both the number of AES-NI capable cores and the amount of cache, as each mining thread needs 2 MB of fast memory).

Now, if your virtualization system can add additional hardware, then it might be worth it for convenience alone, as the overhead might not be too significant if the VM layer can offer access to the underlying AES-NI hardware.


I want my money to be private and to use it as needed each month to pay bills etc How do I get a Monero account?  What is the transition process from a bank account to Monero?  Do I transfer my bank account to a Monero account?  Or do I write a check?  Do I pay my bills with electronic Monero funds?  I really dont understand how I use Monero funds to pay bills.  This is new to me. Thanks.

I like your intentions.  But that's not really going to happen, for a long time, if ever.
As with all cryptocurrencies, the vendor, shop, utility, landlord, etc need to accept it.
There are ways to convert the cryptocurrencies to your local money, and/or to send that to a payee.  But they will give a bad exchange rate and add fees on top of that.

In a nutshell cryptocurrencies are LONG way away from being ready for everyday use.  It's the fault of the vendors not accepting it, and mostly because of the volatility of the value of the cryptocurrencies (which is why so few do accept it).


Is there a step by step tutorial on how to compile from source for Monero cli on ubuntu 16? Is there an easy to follow step by step guide on how to compile monero from source? Alot of the times I compiled previously it stops due to something missing, which goes for many times installing anything from source it seems.

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

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

And build this dependency manually.

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

Source Code
Next get the source code via git.

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

If git is not found install it via

sudo apt-get install git

Than go into the monero folder and build it via:

cd monero
make

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

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


How can I access my full node remotely from another location? What is the procedure for accessing my full node remotely from another location?

What security precautions are most important when doing so?

As @antanst has said, I would also suggest using --rpc-bind-ip and --rpc-bind-port to bind to an external interface but only if your instance is inside an internal/trusted network. I see no reason why your instance should be publicly accessible (if there are reasons, someone please comment).

If you must connect across the internet, I would advise to bind only to localhost and run a Tor onion-site, or I2P server tunnel, or Kovri server tunnel, or any combination of the three, and then direct them to your designated port. From there, you can use torsocks or an I2P client tunnel to connect directly to your node with the safety and security provided by either overlay network.


Blockchain synchronization fails, bus error I am using monerod 0.10.3.1 on Arch Linux. Towards the end of the process the synchronization with the blockchain fails:

2017-05-29 09:20:27.451 [P2P1]  WARN    net.dns
src/common/dns_utils.cpp:531    WARNING: no two valid MoneroPulse DNS
checkpoint records were received
2017-05-29 09:20:27.902 [P2P3]  INFO    global
src/cryptonote_protocol/cryptonote_protocol_handler.inl:293
[66.228.41.201:18080 OUT] Sync data returned a new top block
candidate: 1237496 -> 1320640 [Your node is 83144 blocks (115 days)
behind]
SYNCHRONIZATION started
 Bus error (core dumped)

Any idea what might be going wrong?

A bus error here is almost invariably due to a corrupt blockchain, so I'm afraid the only way out is to resync:

delete the chain (the files in in ~/.bitmonero/lmdb)
start monerod again, and wait for it to resync

You can get more info on that particular error, by running monerod again after running, in the same terminal: ulimit -c unlimited, then running gdb on the core which will be generated after the crash:

gdb monerod core*

Then, in gdb:

bt

You'll most likely find a stack trace crashing somewhere in the LMDB code, but if not, I'm interested to know where.


With a Churn: does it increase privacy more to do 1 TX with RingSize14 or 2 TX with RingSize7 or is it exactly the same? In terms of increasing the distant to the original output.

If you churn twice, and every input you reference came from transactions that used ring size 7 (where one of those transactions would have been your first churn transaction), then your anonymity set would be 7^2 = 49.

You're therefore far better off making two transactions.

If you'd made 3 transactions, your anonymity set would increase fo 7^3 = 343. If some of the transactions referenced had used a ring size lower than 7, then your anonymity set would be smaller. To determine the anonymity set size when ring sizes are not uniform, you'd have to add together the tree of possible outputs that would be formed by the references to past transactions by your transaction.

Note that this technique relies on churn transactions not being easily detectable on the blockchain. If you churned 10 times in a row in quick succession, this might be possible to detect. Churning is a matter of ongoing research at the Monero Research Lab.


Does the kovri pre-alpha build already work for running a monero node? As i understand kovri aims to add support for the I2P network through C++ code instead of the java code it is originally built on. Not only as a monero specific implementation, but also as a general I2P router, usable by other projects as well.

If i currently go to the trouble of building it, can a monero node be run on it on the mainnet/stablenet (as in non-testnet)? If so, does that even make sense at the moment?

From the Kovri FAQ:

What is the current state of Kovri?
Kovri is in active development and currently pre-alpha. Kovri is not yet integrated with monero but, in addition to several core features, we are developing a client and core API for monero and other applications to use.
Currently, you can use the Kovri to connect to (and partake in) the I2P network: browse eepsites, connect to IRC, and run client and server tunnels.

Is Kovri usable, partially usable, or recommended to not be used for actual privacy at the moment?
Kovri is usable to the extent of what ./kovri --help has to offer. Kovri currently has no interaction with Monero. With regard to privacy, we have fixed many security issues since inception but we are still in pre-alpha.
There is still much code to cover so don't expect a strong guarantee of anonymity like with Tor or even java I2P. Those projects have 10+ years of research and implementation experience - and we are just getting started.
Feel free to play the role of developer and experiment/play with Kovri but only if not being anonymous doesn't put you in danger - as there is always the risk of possible de-anonymization due to being in pre-alpha (this is not unique to Kovri).


What is the 'bootstrap node' when creating a monero wallet via the GUI? Been awhile since I generated a wallet with the monero GUI and noticed this new section called 'bootstrap node' in the daemon settings section when creating a new wallet - what exactly is this?

Recently seen dEBRUYNE_1's reddit post regarding making the monero-GUI plug and play by running the daemon in the background whilst being connected to a temporary remote node. This bootstrap node already in the GUI sounds like it does just this, is that correct?

In the GUI, bootstrap node is a remote node to use whilst also syncing the blockchain. This is different to a straight up remote node in that using a remote node will not also sync the blockchain to local.

With regards to dEBRUYNE_1's reddit post, what is described is to default to using a bootstrap node and then automatically switch to local node when the blockchain has fully synced.


Monero on Tails - Connection errors I have set up Monero on Tails as described on the GitHub page: Using Tor on Tails:

sudo iptables -I OUTPUT 2 -p tcp -d 127.0.0.1 -m tcp --dport 18081 -j ACCEPT
DNS_PUBLIC=tcp torsocks ./monerod --p2p-bind-ip 127.0.0.1 --no-igd --rpc-bind-ip 127.0.0.1 \
    --data-dir /home/amnesia/Persistent/your/directory/to/the/blockchain

However, it worked once and then I always get the following errors (though the internet connection works):

ERROR torsocks [15419]: General SOCKS server failure (in socks5_recv_connect_reply() at socks5.c:527)

Connection refused to Tor Socks (in socks5_recv_connect_replay() at socks5.c:543)

I have 3 questions:

1) I suppose I have to enter the iptables and DNS_PUBLIC command each time I start up Tails, correct? If so is there a way to make this persistent?

2) Why would I get the errors above and which steps would I have to take to avoid them?

3) Can I mine from Tails? When I tried I got an error.

1)

Tails is a live OS, therefore changes made to your firewall (iptables) will not persist restarts. As per your last question, the iptables command is a different command to the one you are using to start Monero, thus the command:

sudo iptables -I OUTPUT 2 -p tcp -d 127.0.0.1 -m tcp --dport 18081 -j ACCEPT

Needs running each time you boot into Tails and want to use Monero.

The second command:

DNS_PUBLIC=tcp torsocks ./monerod --p2p-bind-ip 127.0.0.1 --no-igd --rpc-bind-ip 127.0.0.1 \
    --data-dir /home/amnesia/Persistent/your/directory/to/the/blockchain

Needs running each time you wish to use Monero.

  If so is there a way to make this persistent?

As Tails is a live OS, I'd imagine you would need to build your own Tails image if you want the firewall rules to be persistent.

2)

  Why would I get the errors above and which steps would I have to take to avoid them?

This is a Tor specific question. According to this answer, you need a new bridge. I suggest you ask Tor questions on the Tor StackExchange site though.

3)

If you have the daemon running, you can mine. See the command start_mining:

help start_mining
Command usage:
  start_mining <addr> [<threads>|auto] [do_background_mining] [ignore_battery]

Command description:
  Start mining for specified address. Defaults to 1 thread and no background mining. Use "auto" to autodetect optimal number of threads.

If you want to pool mine (with something like XMRig), you're going to need to add appropriate firewall rules so the miner can communicate with the pool.


How does one convert the Trezor seed to a simplewallet seed and vice versa Now that the source is available I thought I'd bring up the subject of the seed difference between the Trezor and Simplewallet. The Trezor uses 24 words, while Simplewallet uses 24 plus an extra word as a checksum. How compatible are these two seeds? And what needs to be done to convert a simplewallet seed to a Trezor so that people don't need to "sweep" funds to a brand new seed, as well as doing the reverse?

In the experimental binaries, which can be found here, NoodleDoodle included a tool called trezorctl. With this tool you can convert your Trezor mnemonic seed to a mnemonic seed compatible with simplewallet. Thus, using this tool allows you to, after conversion, restore your wallet using simplewallet. The tool works as follows. Note that <word_list> is your 24 word Trezor mnemonic seed. On Linux and Mac OS:

./trezorctl recover_mnemonic <index> <passphrase> <language> <word_list>

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:

trezorctl.exe recover_mnemonic <index> <passphrase> <language> <word_list>

The default language is English for seeds. Note that simplewallet also supports Spanish, German, Italian, Japanese, Russian, and Portugese. Lastly, the trezorctrl output looks like this:

USAGE: trezorctl recover_mnemonic index passphrase language word_list
            Supported languages:
            English
            Spanish
            German
            Italian
            Portuguese
            Russian
            Japanese


Any way to reduce daemon verbosity? I've been mining XMR for a little while, and just decided to set up a private wallet and a node on my mini-PC at home.

The first thing I noticed is that the daemon's log output is very verbose. Is there any way to for instance remove the reference to source file and line? I.e. this part of the output?

src/cryptonote_protocol/cryptonote_protocol_handler.inl:1004

I tried to play with --log-level, but didn't see any improvement. I found no other option in --help that seemed relevant.

The reason I want to get rid of it, aside from readability in the terminal window, is that I also run a small webserver on the same box which displays excerpts from logs of various services. To do that effectively, smaller logs are preferable, and the extra information roughly doubles the log size currently.

Edited the log entry copy/paste to clarify what I want to get rid of.

You can set the MONERO_LOG_FORMAT environment variable to include whatever data you want to be output. The default is:

%datetime{%Y-%M-%d %H:%m:%s.%g}\t%thread\t%level\t%logger\t%loc\t%msg

The available variables are in the easylogging++ documentation, in the "Loging format specifiers" section:

https://github.com/muflihun/easyloggingpp


How "one-time ring signatures" anonymise the sender of a transaction? I'm interested in anonymity in Monero over Bitcoins where all transactions are public.

What are the "one-time ring signatures" in Monero and how they anonymise the sender of a transaction?

Ring signatures are a group of cryptographic signatures with at least one real participant, but no way to tell which in the group is the real one as they all appear valid

When sending a transaction, you select some random transaction outputs on the blockchain and mix those with your own coins
Mixing enforced across the network, meaning active participation is not required from owners of other outputs.
The owner of an output in every ring signature has plausible deniability
The key image prevents double spending.


Usage of a zero mixin (ring size =1) Zero mixin (ring size=1) transactions are no longer allowed (except for sweeping dust). When they were allowed before the March 2016 hard fork they were quite common.

Is there evidence to support the theory that most zero mixin usage (when allowed) came from exchanges? If so do we know if their reason was:

Attempt to save on transaction fees
Indifference to untraceability of transactions
Attempt to make it easier to track withdrawal transactions for customer identification or support purposes

Are there any known exchanges that voluntarily used non zero mixins for withdrawals (thereby enhancing user privacy) prior to being required by the protocol to do so?

It is known that Poloniex switched to non zero mixin for a short time for withdrawals. However, they reverted to zero not long after, and I believe this to be due to the increased fees. Unfortunately, exchanges have to deal with people sending very small amounts of every coin, as they mine directly to the exchange address, or if they don't, they send everything as soon as they've got any, for selling as soon as possible. This means that Poloniex ends up with a lot of small outputs. When people withdraw larger amounts (or maybe even not so large ones), Poloniex has to find a lot of outputs to build that withdrawed amount, making them all the more vulnerable to high transaction fees when using non zero mixin.


How does the recent patched key image exploit work in practice? For more info https://getmonero.org/2017/05/17/disclosure-of-a-major-bug-in-cryptonote-based-currencies.html This has been patched months ago and was never exploited which can be proven by running a node because it checks every transaction's key image to see if this exploit was executed and nodes now reject blocks containing transactions with this exploit so it is safe but I am interested in how the key image could be manipulated to do this

Looks like it was being exploited on Bytecoin

For example, these 2 transactions spend the output 26e8958fc2b227b045c3f489f2ef98f0d5dfac05d3c63339b13802886d53fc05 twice!

http://chainradar.com/bcn/transaction/cef289d7fab6e35ac123db8a3f06f7675b48067e0dff185c72b140845b8b3b23

http://chainradar.com/bcn/transaction/7e418cc77935cc349f007cd5409d2b6908e4130321fa6f97ee0fee64b000ff85

Notice how the key image differs only in last 2 digits! That's because it's forged - ie 2 slighthly different key images for 1 output, allowing you to spend it twice by tricking the pre-patch node into thinking that both key images are valid for the given output. There can really be only 1 which can be checked only with a patched node, and one of those TX-es would become invalid.

Note that it's later patched in the code, but the patch applies only after Bytecoin block 1267000, so those double-spend transactions are still in the Bytecoin blockchain and have artificially inflated the supply.

Note that while I was writing this, there were some problems with chainradar block explorer and those transactions disappeared for a while! That doesn't mean that they're not in the blockchain (really, the only way to be sure is to run a Bytecoin node and check yourself if they're still there), but only that chainradar was not showing them (seem to be back now).
Just in case, they can also be seen here:

https://minergate.com/blockchain/bcn/transaction/cef289d7fab6e35ac123db8a3f06f7675b48067e0dff185c72b140845b8b3b23

https://minergate.com/blockchain/bcn/transaction/7e418cc77935cc349f007cd5409d2b6908e4130321fa6f97ee0fee64b000ff85


What use cases exist for a high level of blockchain privacy? For people with nothing to hide, what does Monero offer that Bitcoin cannot?

If I do not care if people know how much money I spent purchasing a certain item, what benefit (if any) would using Monero have over using Bitcoin?

The issue that comes with saying, "I have nothing to hide" in a privacy debate is a thorny one.  For example, even though you may have nothing to hide in your private communications with friends and family, would you be comfortable publishing all of your conversations on a public ledger, or even just handing over your Facebook and e-mail passwords to a stranger?

With regards to personal finances specifically, even though you may not make any illegal purchases, you can still benefit from privacy for a number of reasons including protection from issues such as:

Receiving targeted advertising based on your spending habits.
Revealing your net worth or salary, possibly making you the target of thieves.
Revealing to which charities, political campaigns, or causes you donate that others may not agree with.

Additionally, adding a layer of  privacy to your spending also helps in preventing fungibility issues with a cryptocurrency such as receiving "tainted coins" or having your address blocked by a third party for falsely "suspicious activity."

The items above are far from exhaustive, but hopefully it is now more clear why everyone stands to benefit from the privacy Monero offers.


Wallet created with 0.9.4 fails to load with 0.10.0 I get this error when trying to open a wallet with 0.10.0 that I created with 0.9.4:

> ./monero/monero-wallet-cli --wallet-file wallet-2016-06-14
Creating the logger system
Monero 'Wolfram Warptangent' (v0.10.0.0-release)
Logging at log level 0 to /home/xxx/./monero/monero-wallet-cli.log
password: *********
Error: failed to load wallet: std::bad_alloc
Error: You may want to remove the file "wallet-2016-06-14" and try again

Shouldn't wallets be compatible between 0.9.4 and 0.10.0?
I'm running on OpenSuSE Leap 42.1 using the binaries from http://getmonero.org (both when I created the wallet with 0.9.4, and now with 0.10.0).

What should I do now to use my wallets with 0.10.0?

This is a known bug (see https://github.com/monero-project/monero/issues/1106), though the root cause is only suspected now known to be a difference in Boost versions used in the binaries for 0.10.0 and 0.9.4. The file that fails to load is only the cache, not the keys, so if you remove the cache, the wallet will load. Bear in mind that the cache may contain tx keys for past transactions, so removing the cache will lose them.

Note: it is recommended that you keep a copy of the cache anyway, as you may need it if you need to prove a transaction (then you can tempporarily load your wallet with 0.9.4 again to perform the operation, then go back to 0.10.0).

In the hopefully near future, the wallet cache will be moved to a LMDB database, so these compatibility issues will become moot.


Making a public Monero node with RPC open so I can connect to it from my app I have the following bitmonero.conf file on my VPS server:

no-igd=true

rpc-bind-ip=0.0.0.0
rpc-bind-port=18081
restricted-rpc=true
confirm-external-bind=true

rpc-login=abc:123

How do I make it open so I can do RPC calls from my desktop's monero-cli and monero-rpc command line?

Firstly, you are correctly binding to 0.0.0.0.

Next you need to make sure your firewall on your server is allowing inbound connections on the port you specified (18081). This step will vary based on what firewall you are using. For example, if you are using iptables and ufw, you would use the command sudo ufw allow 18081. Some VPS providers have a web-based firewall you would need to configure also.

Lastly, you connect to the server using the public IP address your provider assigned to your server.


Implementing Cryptonightv1 PoW algo change but miners are able to mine with both Cryptonightv0 or Cryptonightv1 now I am modifying a cryptonote to transition over to PoW algo cryptonightv1 from cryptonightv0 and I am having a weird issue that I can't figure out...I'm starting to pull out my hair over this.  I've studied the changes that Monero, Turtlecoin, Electroneum and Masari have done and implemented it on my own coin (which shares a similar code base to turtlecoin/original bcn) yet miners seem to be able to mine with either PoW algo now (cryptonightv0 or v1) instead of just v1, at least as far as I can tell when using a pool.  The tests/hash_tests app verifies that the PoW algos work correctly as I have these functions here that test cn_slow_hash with a variant=0 (for v0) and then with variant=1 (for v1):

static void cn_slow_hash_0(const void *data, size_t length, char *hash) {
      return cn_slow_hash(*context, data, length, *reinterpret_cast<chash *>(hash), 0);
  }
static void cn_slow_hash_1(const void *data, size_t length, char *hash) {
      return cn_slow_hash(*context, data, length, *reinterpret_cast<chash *>(hash), 1);
  }

The tests pass so I know that the actual PoW algorithm is implemented correctly in the sense that when cn_variant 0 is passed to cn_slow_hash() that it retrieves the hash for cryptonightv0 and when cn_variant 1 is passed it retrieves the hash for cryptonightv1.

The issue I am having is that when I start a local test net or live test net, I can mine with a pool with xmr-stak-nvidia with the miner algo set to "cryptonight" or "monero7" regardless of what height I am at (if I have the pool set to cryptonight then cryptonight works, if I have it set to v1 then monero7 works).  I've done all the appropriate upgrade height changes and the block's major version even changes yet the get_block_longhash function doesn't seem to run the appropriate cn_long_hash variant.  Even if I manually set cn_variant to 1 for ALL heights the miners are STILL able to mine either PoW algo if the pool allows it.  Here is what my get_block_longhash function has to supply the correct variant to the cn_slow_hash function:

const int cn_variant = b.majorVersion >= 5 ? b.majorVersion - 4 : 0;
cn_slow_hash(context, bd.data(), bd.size(), res, cn_variant);

So if the version is 5 or greater the cn_variant should equal 1.  When I print the blocks they show that they are majorVersion 5, yet the old PoW algo is still working to mine blocks!  Unless there is something wrong with my pool setup that is tricking me (https://github.com/dvandal/cryptonote-nodejs-pool/).  Is there another way that I could test this without question to make sure it is swapping over to the new PoW correctly?  I am running out of ideas because, like I said, even if I manually force cn_variant to be 1 without the ternary operator it doesn't fix the issue.  What am I missing here?  Any advice is GREATLY appreciated.  I am so stuck right now.

EDIT: Am I not understanding this correctly?  I just tried the pool with a different coin that is cryptonightv0 only, and it allowed me to mine with "monero7" in xmr-stak-nvidia and accepted the shares?

The solution was that my checkpoints were messing everything up.  Once I got rid of the checkpoints everything worked correctly (this is a hard fork of an existing coin so I need the checkpoints in the final version but for testing I was using a new separate network starting at height 0.  I commented out the checkpoints and it works correctly now).


Error: Problem fetching info -- Error checking for updates I am all synched up, When I try to mine it says "v6 update needed". When I try monerod.exe  and use the command "update check" it says Error: Problem fetching info -- Error checking for updates"
 When I try "update download" I always get "Error: Problem fetching info -- Error checking for updates"

The "v6 update needed" is probably a mangling of the status line, right ? If so, it's telling you it's been a while without an update. It turns out there's none available right now, but it is expected to be very soon.

As for the "Error: Problem fetching info -- Error checking for updates", it's possibly because you build monero yourself. If this is the reason, I believe current master handles it correctly.

It could also be due to DNS problems. You can check that by setting the "DNS_PUBLIC" environment variable to "tcp", which will use Google's DNS server via TCP, as many DNS servers don't support DNSSEC well. In the current code, the Google DNS server is replaced by a selection of non Google servers, and you can select your own preferred server too.


What is the transaction fee? What is the transaction fee for one transaction? What is the dollar equivalent for a transaction? Does the amount of XMR sent affect the fee?

The fees are calculated based on the transaction size in kB, not the transaction amount.
The transaction size depends mainly on the number of inputs you are spending, and the number of outputs you are generating.

A typical transaction would use one or two inputs (which you received from a previous transaction) and two outputs (one is the amount you are willing to spend, and the other is the change back to yourself).
I.e. If you own an output of 10 and spend 5, it will generate a transaction with one input of 10, one output of 5 to your recipient, and one output of 5 - fees (approx. 4.9976, see below) to yourself.

If you are trying to spend more XMR than a single outputs contains, you will use 2, 3, or more outputs as inputs for your transaction.
If you're sending to multiple recipients at a time with the CLI, you will generate one more output per extra recipient.
If you're sweeping a single output, aka sending the whole output to a recipient, fees excluded, you only generate one output.

Before upcoming bulletproofs, the typical 1 input / 2 outputs transaction, the fees should be around 0.0024XMR (with low priority) so $0.276 approximately and depending on the actual rate.


Monero GUI: How do I switch back to my Ledger Nano S wallet from my original wallet I have just created a new wallet using my Ledger Nano S, all went fine.

I then closed the new wallet in order to open my original wallet so I could transfer the funds over to my new wallet. Again, fine.

I now though, cannot seem to work out how to switch back to my new ledger wallet.

On opening the Monero GUI I am asked to provide my password for my old Wallet. If I click cancel, and choose "open a wallet from file" I am only shown the .keys file of my old wallet.

Where can I find the .keys for my new Ledger wallet?

Wow, I'm dumb.

If anyone else out there is having this problem (Switching between Monero Wallets)

Want to unlock a different Wallet? Follow these steps:

Open Monero GUI
Click cancel instead of entering password.
Choose Language
Click "Open a wallet from file"
File Explorer window opens (Windows)
Choose the Destination where keys are saved (Default: This PC> Documents>
Monero> Wallets)
Open desired Wallet folder
Select .keys file
Press Open
Enter Password


wolf xmr miner v0.4 configuration gpu I want to use this miner but don't want it to control anything about the GPU. This will be controlled by MSI Afterburner which I know works just fine with my cards.

So do I need to give the miner all this information like GPU speed and Fan speed?

Also I never got it to work. Even when downloading sample configs which should work fine it tells me:

[15:28:30] Error loading configuration file: '}' expected near end of file on line 24.

Everytime this error ...?
This one was printed out with this configuration:

{
"Algorithms":
[
    {
        "name": "CryptoNight",
        "devices":
        [
            {
                "index": 0,
                "threads": 1,
                "rawintensity": 1040,
                "worksize": 16
            }
        ],
        "pools":
        [
            {
                "url": "xmr-eu1.nanopool.org:14444",
                "user": "-",
                "pass": "x"
            }
        ]
    }
]

Anybody knows whats wr

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


When did Monero convert from a 24 to a 25 mnemonic seed standard? Which release (name and date) of the official monero-wallet-cli wallet changed the Monero mnemonic seed standard from 24 to 25 words?

Without recovering my wallet from cold storage, is there any way to tell from my looking at my mnemonic seed if it was created with the old 24 word standard or if it was created with the new 25 word standard (and I forgot to record one word)?

Which release (name and date) of the official monero-wallet-cli wallet changed the Monero mnemonic seed standard from 24 to 25 words?

Wordlist

Seems like the wordlist was introduced in 2014 (v0.8.8.5) and didn't change until the 2 minor fixes in 2015 (v0.9.0). That is the same one used at the present.

commit c01069f35253586ac2fbc3d507c7ed3ccdd900ce

Author: Riccardo Spagni <ric@spagni.net>
Date:   Wed Mar 4 15:31:24 2015 +0200

    fixed English word list issue: 'launchpad' should be 'ourselves'

commit 10e4132e22ccc0f1a41763adee74699ebedb5ffc

Author: Riccardo Spagni <ric@spagni.net>
Date:   Wed Mar 4 15:29:20 2015 +0200

    fixed English word list issue: 'incline' should have remained 'inline'

commit 010bfcfd18497b5f77cef62d60a56a556dfeadd4

Author: Riccardo Spagni <ric@spagni.net>
Date:   Mon Oct 6 08:47:04 2014 +0200

    minor English wordlist tweaks

Checksum

The 25th checksum word checksum was also introduced even before the above wordlist.

commit 8f587ba1c8044ed6face883d8f50cd43e27484e3

Author: Oran Juice <oranjuices@hotmail.com>
Date:   Sun Sep 28 02:29:25 2014 +0530

    CRC Checksum for word seed. Gives a new 25 word seed with checksum if one without checksum is passed. Doxygen comment fix.

  Without recovering my wallet from cold storage, is there any way to tell from my looking at my mnemonic seed if it was created with the old 24 word standard or if it was created with the new 25 word standard (and I forgot to record one word)?

Check against the dictionaries, should be either english or english-old. The latter one doesn't use the 25th word AFAIK.


Origin of the background image of MyMonero How has the background image of MyMonero been choosen ? Is there a hidden reference ?

According to fluffypony:

  it was just a stock image that looked cool:)


QUESTION : is it safe to use a remote monero demond (monerd) hello everyone i don't know about professional part of monero so my question may sound crazy excuse for that

i've seen some pool and .. provide a remote daemon for their users so they can use official wallet without download and sync of blockchain

my question is if i use these remote daemons is it possible for them to get my spend key or any access to my wallet i know that 's not possible using standard daemon that everyone can download . my question is for a modified monerod ,so technically is there anyway that they can access my moneros only by connecting to their remote daemon considering that i have 10000xmr in my wallet(just for understanding the importance ) and this is their goal
(i'm not talking about trust in any way )

i posted this question both in here and reddit because i feel here for professional after reading questions i nehre and reddit sorry for that

thanks for reading best regards

The only risk that you incur by using a remote node, its that if the remote node goes offline, you have to rely in another remote node.

https://moneroworld.com/ this is the most popular site where remote nodes are. I guess you are using one of the nodes listed there. Feel free to read the entire tutorial over there.

If you feel paranoid about your security, use a remote node and start the daemon from your wallet-gui (or run monerod), this way you can use a remote node connection while your monerod is syncing the blockchain data.

Once your monerod is synced, delete node parameters at monero-gui and save.

If you dont want to get full node, well, use this guide Is there any way to construct a transaction manually?

Im yet to see someone robbed by a remote node. But again, if you worry about your security, use a full node. Kind regards...


Using JSON RPC, how do I check for payments for a particular integrated address? I know how to check for payments using payment IDs as it is documented on the monero website. But it does not say how to check payments using an integrated address. Can someone tell me how to do this?

An integrated address is just your standard address and the payment id you chose, bound together into one string. When you generated this standard address, you'd have written down that payment id. If not, there is a split_integrated_address wallet RPC that will do this for you.

That payment id may be used as input for your original RPC call. If it doesn't work, then it's because there's a bug in the RPC that needs fixing, and the best next step is to report it along with the actual commands you used to https://github.com/monero-project/monero/issues

Note that you get a short (64 bit) payment ids when working with integrated addresses, whereas legacy payment ids are 256 bits. This is expected, and you're not missing anything.


Confused about the RingCT protocol I'm a newcomer.
I'm a bit confused about the current protocol and I don't quite feel like reading the code yet.
I've been reading Shen Noether's paper as well as related work.

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

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

(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

Is there more updated documentation of the current protocol available?

Kurt

(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.


How many transaction versions in Monero? When I get information about transactions in block 1, using the RPC /get_block, I have one format of data. When I get information about transactions in block 2230000, I have a different format of data and I need to use /get_transaction to read more information.
So my question is, how many different formats of transaction does Monero have? What differences do they include? In what blocks these formats are accepted?

How many transaction versions in Monero? ... how many different formats of transaction does Monero have? What differences do they include? In what blocks these formats are accepted?

Two. v1 (pre-RingCT, before block 1220517) and v2 (RingCT, from block 1220517).


Does the reward for mining with a certain amount of hash per second stay the same over time? I'm new around in the crypto world, but fascinated! Want to start mining XMR but wonder if the reward stays the same. Does it maybe, as with BTC, become less because of the bigger blockchain? Or does the reward of let's say 0,03 XMR per day get less when the value of XMR becomes more (compared to USD)?
Thanks for your feedback!

Want to start mining XMR but wonder if the reward stays the same.

No. It's changing according to emission schedule. If you're asking about how much an individual miner could be getting - on average, he'll get a proportional amount of his hashrate. If he's solo mining, this means he could be mining for a long time before he ever receives anything. That's why people pool their efforts together, and split the reward once they win it. That's called pool mining.

  Does it maybe, as with BTC, become less because of the bigger blockchain?

Size of the blockchain has nothing to do with that. Reward is tied only to blockchain age, as per emission schedule. Technically, it's tied to amount of monero currently in circulation, but effectively it's as if it's tied to age.

  Or does the reward of let's say 0,03 XMR per day get less when the value of XMR becomes more (compared to USD)?

Monero reward (in XMR) will keep reducing as per emission schedule. Somewhere in 2023, it will get to 0.6XMR (per 2-min block) and stay like that forever. This is known as "tail emission" (1, 2). Thing is, as more miners enter the space, it will be shared among more and more miners so each individual miner will receive less XMR. However, they'll probably be receiving a more-less constant amount of USD, governed by hardware efficiency and cost of electricity.

Mining works like a scratch-lottery. The stronger CPU you have, the more tickets you're able to purchase per 2-min round. Note that the round is closed only once a winning ticket is found, regardless of time. If winning tickets are found too fast, criteria for winning becomes more strict and if too slow, then it's relaxed. It's called "difficulty adjustment". Tickets cost eletricity. Since alone you have low chance of winning, you pool your efforts with a bunch of people to increase the chance of someone from your group winning. Then, you split the reward according to how much "tickets" each of you contributed.


Is my hot wallet the only view wallet and my cold wallet the one created offline? I am a little confuse and concern about my wallet security. I've created a wallet using moneroaddress.org, I went offline and generated a new wallet I saved all my keys and erased my browser history, then I went online again. I created a monero view-only wallet using the CLI by inputing the previous generated Public Address and View Key and synced it using a node.

Then I saw this post Is there any way to construct a transaction manually? to learn how to check my balance. They mentioned a cold wallet computer and a hot wallet computer to be safe and secure.

My question is, do i need two computers one that never goes online and one that is connected to the node? Is the method of syncing only the only-view wallet safe? Can I say my hot wallet is my view wallet?

Thanks for your help

Yes, your view wallet is hot, but that is safe. Even if someone gains access to your computer, he can not steal any funds because the view wallet doesn't store your secret spend key (which you have written on the paper backup).

Cold wallet with the spend key doesn't have to be a different computer. You could use the same physical computer, and boot from some USB Linux system to act as a safe, clean, cold machine. what's important is that you never expose the secret spend key to a potentially-compromised PC. When you're booting into a fresh Linux system which will be used only for your cold-wallet stuff and never be connected to Internet - any risk is minimized.

You could even use Windows console, but maybe it's not so user-friendly. Here's an exampe how to use monero-wallet-cli with Windows pre-install environment.


What am I doing wrong? I've just started mining on my laptop, I know it isn't much but I wanted to give it a try. I started with Minergate and was getting almost 25 H/s, then I read that this site is a scam because it shows fake H/s numbers so I decided to mine with xmrig, which is recommended in Monero's subreddit.

The problem is that I'm only getting 11.3 H/s max. Am I doing something wrong?

This is hwo I run xmrig:

xmrig.exe -o pool.supportxmr.com:3333 -u <my_address> -p x --donate-level=1 --max-cpu-usage=95 -k

It depends on the specs of your laptop, but that sounds like a plausible hashrate if your laptop is older or running other applications.

I have a desktop that using the xmr-stak miner can just squeeze 86H/s out of an overclocked i7 2600k. Given the restrictions placed on processors in laptops, I would imagine that they can be far lower than that.

Try using different miners if you haven't already, but be aware that CPU mining is not profitable compared to the enegry input. GPUs, particularity AMD GPUs, are much more efficient per watt when mining on Cryptonight (Monero's algorithm) and tend to effect the overall usability of your machine less.


Monero on Tails OS - Connection Errors Download Node I am trying to run the Monero wallet in Tails using the Guide to creating a Monero GUI wallet in Tails.
I run the following iptables command from within the extracted Monero wallet:

sudo iptables -I OUTPUT 2 -p tcp -d 127.0.0.1 -m tcp --dport 18081 -j ACCEPT
[sudo] password for amnesia:

But the command does't return anything. So I'm not sure if the port has been opened through Tails' firewall. I then run command.

DNS_PUBLIC=tcp torsocks ./monerod --p2p-bind-ip 127.0.0.1 --no-igd --rpc-bind-ip 127.0.0.1 --data-dir /media/amnesia/monero

The node begins to download.

2020-04-03 17:14:50.538 I Monero 'Carbon Chamaeleon' (v0.15.0.1-release)
2020-04-03 17:14:50.538 I Initializing cryptonote protocol...
2020-04-03 17:14:50.538 I Cryptonote protocol initialized OK
2020-04-03 17:14:50.538 I Initializing core...
2020-04-03 17:14:50.538 I Loading blockchain from folder /media/amnesia/monero/lmdb ...
2020-04-03 17:14:50.579 I Loading checkpoints

I get a few errors.

2020-04-03 19:19:26.124 I Synced 46512/2068842 (2%, 2022330 left)
1585941567 ERROR torsocks[16670]: General SOCKS server failure (in socks5_recv_connect_reply() at socks5.c:527)
2020-04-03 19:19:28.302 I Synced 46612/2068842 (2%, 2022230 left)

But the node continues to download regardless. It always reaches 18% before I get this error.

2020-04-03 19:52:46.631 I Synced 386060/2068853 (18%, 1682793 left)
2020-04-03 17:48:47.173 W Failed to commit a transaction to the db: Input/output error
2020-04-03 17:48:47.173 E Exception in cleanup_handle_incoming_blocks: Failed to commit a transaction to the db: Input/output error
1585936393 ERROR torsocks[13066]: General SOCKS server failure (in socks5_recv_connect_reply() at socks5.c:527)
1585936460 ERROR torsocks[13066]: Connection timed out (in socks5_recv_connect_reply() at socks5.c:547)
1585936582 ERROR torsocks[13066]: Connection refused to Tor SOCKS (in socks5_recv_connect_reply() at socks5.c:543)
1585936684 ERROR torsocks[13066]: Connection timed out (in socks5_recv_connect_reply() at socks5.c:547)
1585937052 ERROR torsocks[13066]: General SOCKS server failure (in socks5_recv_connect_reply() at socks5.c:527)
1585937937 ERROR torsocks[13066]: General SOCKS server failure (in socks5_recv_connect_reply() at socks5.c:527)
2020-04-03 18:18:57.415 W No incoming connections - check firewalls/routers allow port 18080
1585938270 ERROR torsocks[13066]: Connection timed out (in socks5_recv_connect_reply() at socks5.c:547)

If the problem is indeed this.

2020-04-03 18:18:57.415 W No incoming connections - check firewalls/routers allow port 18080

I dont understand because I have already opened port 18080 on my dlink router.

And I've also tried using a virtual server on the router:

I'm not sure where the problem lies. Using the latest Tails OS and Monero Wallet. Anyhelp would be greatly appreciated.

Thank you in advance.

The problem was, is that I formatted the SD card with FAT32 (same as Tails OS) and the download would max out at 4GBs oops. I used Linux's file system and had no problems. Can someone recommend a Bitcoin to Monero exchange i can use?


Kovri operational security example(s) - file permissions The Kovri User Guide has a Step 2. (Recommended) Operational security. It is currently as follows:

Consider creating a designated kovri user and run kovri only using that user
If using Linux, consider using a hardened kernel (such as grsec with RBAC)
After installing the appropriate resources in your kovri data path, considering setting appropriate access control with setfacl, umask, or whatever your OS uses for ACL
Don't share your port number with anyone as it will effect your anonymity!

I'm mainly curious about the third item.  How might running Kovri put my computer at risk, and how would those named softwares, or similar softwares, be used to mitigate those risks?  What are some specific examples (or even one specific example) of what a user would do to follow the third item in this step? After following that third step, how it my system more safe/hardened?

If this may require a distro-specific response, I'm most familiar with (and therefore most curious about) Debian-based linux distros, and I've got Kovri currently on an Ubuntu 16.04.3 box.

The third point is about general operating system security with regards to which system users have read, write and executable permissions on files and folders in the kovri data path. setfacl (or chmod) can be used to set permissions on existing files / directories and umask is used to set permissions for newly created files in a directory.

Which users / groups you grant what access to is specific to your setup and needs.

As an example, if you only want the korvi user to have any access you could run:
chmod 700 && umask 0077


Radeon Blockchain Drivers not Installing on Vega 64 I was trying to install the AMD Radeon Beta Blockchain Drivers onto my RX Vega 64 Liquid GPUS. The screen flickered, as it always does during a display driver install, but after my screen went black once, it didn't return. I waited for about 8 hours but it still didn't come back. Could someone help me and tell me how to get it properly installed?
My system specs are as below:

Motherboard: MSI X399 GAMING PRO CARBON AC

Processor: AMD RYZEN THREADRIPPER 1950X

CPU Cooler: CORSAIR H80I V2

GPU:  RX VEGA 64 LIQUID EDITION (x4)

Case:  ROSEWILL BLACKHAWK ULTRA

SSD: PNY SSD (Any hard drive that works for laptops also works for desktops)

HDD: Seagate BarraCuda 4TB ST4000DM004

Power Supply: EVGA 1000 G3 GOLD RATED POWER SUPPLY (x2)

OS: WINDOWS 10 HOME

Thanks in advance for all help!

I was following this guide and trying to install the Blockchain Drivers.

I realized that my gpus were overheating. I fixed this problem by pointing an external fan at my gpus.


Monero wallet password - recovery of wallet and XMR I'm in trouble. I don't remember my Monero wallet password. And I don't have the private keys or the 25 word seed. Is it possible to get the password? I'm using the GUI wallet. Does the PC not save something that can help? I mean like a file, cache or something?
I have the .keys file, but not the address, secret spend key, secret view key or password to open it.
I have my public address from a transaction I made when i created the wallet. Is it possible to get my Monero back?

If you don't have your seed or password, you cannot recover your XMR.


Optimal number of threads when mining How can I determine the optimal number of mining threads to start if I know the CPU and the quantity of RAM? Are other parameters relevant?

As a general rule of thumb: Cryptonight, the PoW hash Monero uses, needs a 2 MB scratchpad in fast memory, so you will want to have all your mining threads able to keep their scratchpad in cache. So the optimal number is likely to be your cache size divided by 2 MB (eg, if your cache size is 4 MB, then 2 threads). If that number happens to be higher of equal to the number of cores you have, then keep it to the number of cores minus one.

If you use the machine for other things at the same time, you will need to decrease that number, and by how much will have to be determined by testing.

In any case, you may want to test a number of configurations, testing is quick and easy, and will uncover any deviation your hardware may have from that rule of thumb.


What are the system requirements for an Aeon full node? Recently I was trying to install an Aeon node on a VPS, but people said it hasn't yet implemented LMDB, so it needs a great deal of RAM to properly work, so my 2GB RAM VPS wouldn't be enough. How much RAM or other system requirements are needed to run a fully functional Aeon node?

It looks like it isn't using LMDB yet, because I only have a 3.5 GB blockchain.bin file in the ~/.aeon directory. I brew the software from HEAD, it says aeon v0.9.6.0().

With regard to memory, as far as I can tell, on my macOS system, aeond is using about 9 GB of memory. I have no idea whether this would prevent the daemon from running on a system with only 2 GB.

Update:
I set up a Ubuntu (MATE) virtual machine and synchronized the Aeon blockchain using 6 GB of RAM. Reducing the amount of RAM ended up in the aeond daemon process getting killed. I am now running the VM without issues with 6 GB of RAM and solo-mining on 4 threads.


Determining the private view key by observing the exchange of MultisigV1 strings If someone were to observe the exchange of MultisigV1 strings during multisig wallet creation, can they use these to discover the public address or secret view key of the multisig wallet?

If so, how?

I'll reference part of the scheme as detailed in the commit:

2 of 2

User A (coordinator):
Spendkey b,B
Viewkey a,A (shared)

User B:
Spendkey c,C
Viewkey a,A (shared)

Public Address: C+B, A

Both have their own watch only wallet via C+B, a

The format of the MultisigV1 string is, once base58 decoded:

private view key component (32 byte scalar)
public spend key component (32 byte EC point)
schnorr signature of a hash of the two elements above by the private spend key component
  (pair of 32 byte scalars)

Therefore to determine the overall multisig wallet private view key, add together all of the private view key components. The same calculation applies to determine the overall public spend key. Together, these can be used to recreate the wallet public address and to create a view-only wallet.

If you don't mind others being able to observe the multisig wallet address and private view key, and therefore them being able to observe incoming transactions to the wallet, these strings can be shared publicly. Otherwise, they should be kept private.


Activity of Moneromooo What percentage of Monero pull requests so far have been made by Moneromooo?

Is Moneromooo the most active Monero developer?

How was did Moneromooo choose his name?

I dont know about the pull requests specifically, but here you can see overall activity of participants.

  https://github.com/monero-project/monero/graphs/contributors

Moneromooo is the most active with 710 commits, second being fluffyponny with 285.

Moneromooo's work also looks very steady during last year and half.


When will KeepKey support Monero? I asked this of keepkey about a year ago and I only have gotten a standard response saying they are evaluating the support of alts. Is anyone aware of progress made to support Monero?

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

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

  NoodleDoodle: Sure :P

  fluffypony: yay, take it away

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

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

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

  fluffypony: ok cool

  NoodleDoodle: I should be able to do it.

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

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

  fluffypony: ok cool

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

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

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

  fluffypony: if they'll have us


Using Monero as a C Library I am looking to build an offline wallet for Monero. However, most of my tooling is in Perl and C. If Monero was written in C, I could just call the C functions from my Perl modules. I think it is possible to call C++ functions from Perl relatively painlessly, but to do that I need to know how to access the functions in the Monero code base. Would someone be able to point out how to install Monero as a library instead of just the binary? Or does the docker install also include installing a library?  It looks like it comes down to getting monero_headers.h to get imported into a C file and calling it from my Perl code.

Monero can be built using the DBUILD_SHARED_LIBS flag that triggers building the optional shared libraries.

apt-get install git cmake build-essential libssl-dev pkg-config libboost-all-dev
git clone https://github.com/monero-project/monero.git
cd monero
git checkout tags/v0.11.0.0 -b release-v0.11.0.0
cmake -DBUILD_SHARED_LIBS=1 .
make


What exactly has been changed in PoW algorithms in the v7 fork? I have read the official announcement about the current PoW change and also seen the discussion on GitHub but this is very long and very technical. Could someone summarise what exactly has been changed in comparison to the original CryptoNight algorithm and how it makes currently available ASICs obsolete?

In versions 1 to 6 of the protocol, the CryptoNight  algorithm was very roughly:

state = keccak(block_data)
scratchpad = fill_scratchpad(state)
loop 524,288 times
  address = compute_address(scratchpad, state)
  modification1(scratchpad, address)
  address = compute_address(scratchpad, state)
  modification2(scratchpad, address)
text = reduce(scratchpad, state)
result = extra_hash(keccak(mix(text, state)))

In version 7 of the protocol, it is:

state = keccak(block_data)
tweak = compute_tweak(block_data, state)
scratchpad = fill_scratchpad(state)
loop 524,288 times
  address = compute_address(scratchpad, state)
  modification1(scratchpad, address)
  extra_modification1(scratchpad, address)
  address = compute_address(scratchpad, state)
  modification2(scratchpad, address)
  extra_modification2(scratchpad, address, tweak)
text = reduce(scratchpad, state)
result = extra_hash(keccak(mix(text, state)))

So in version 7, two extra modifications are added to the computationally intensive loop.
The extra_modification1 does some bit shuffling.
The extra_modification2 mixes bits of the tweak into the scratchpad.

The idea of these changes to the CryptoNight algorithm is that to make an ASIC for it (when you already have an ASIC design for the previous version) you would have to rework the main loop because it now requires some extra gates (for bit shuffling) and access to some data that was not necessary before (block data in the tweak).


How can I be notified of important updates/news to the Monero software? Monero forks twice a year at roughly predictable times. However, it is easy to forget about it, and you end up forked off if you don't update your software in time. How can I be notified of these forks and other important announcements such as any emergency fork that might happen ?

There is now a monero-announce mailing list on which such important announcements will be made:

https://lists.getmonero.org/postorius/lists/monero-announce.lists.getmonero.org/


Could something like the Bitcoin Lightning Network be implemented for Monero? Could something like the Bitcoin Lightning Network be implemented for Monero?

What differences make a Monero implementation of the Lightning Network (or equivalent) more or less difficult than the Bitcoin implementation?

Yes most definitely. Much of the infrastructure that LN would require already exists in Monero, although multisig is a key component that is currently missing. Thankfully that is coming in the near future, after RingCT has been implemented, as it builds on the RingCT work.

There are some key improvements we'd likely make to an LN implementation for Monero, mostly focused on retaining as much privacy as possible. This is very early on in the process, however, and there is much discussion and thinking that still has to happen before we can commit to developing any such additional LN functionality.


What privacy issues did Monero have and still has? Has there been any scientific research regarding the promised privacy and security of Monero?

Have there been attacks on the Monero network in the past? If so, what has been done to combat those?

Are there currently any risks for my privacy when using Monero? Is blockchain analysis possible and will this change in the future?

The Monero Research Lab is a team of voluntary researchers, scientists and academics that did analyse Monero and its predecessor CryptoNote in the past, explaining both past attacks and possible privacy issues in the current network. Their research is mostly funded by donations from the Monero community and is publicly available.
In the following segment I will list every security issue they found and their implemented or proposed solution. Elaborations are my comments but are mostly based on the research results.
TL;DR

Seven possible attack vectors
Six solutions have been implemented
One issue is not yet resolved

MRL-0001: A Note on Chain Reactions in Traceability in CryptoNote 2.0

If an attacker owns many transactions and you use solely his outputs
as mixins, he is able to deobfuscate the ring signature. He could spam
the network with transactions to increase the probability of becoming
a mixin.

Solution: Enforced minimum mixin of 2 will reduce the share of evil outputs over time
Status: Implemented
Elaboration

Fees and a possible deflation make this attack rather expensive for the excessive amounts the attacker would need to buy, hold and move: "If Burns controls half of all outputs, then 12.5% of all new transactions will have a ring signature composed entirely of his outputs"
Accidental deobfuscations (mixin = 0) can be prevented by enforcing a protocol level minimum mixin
With a protocol level minimum mixin of 2 and the resulting 12.5% chance of deobfuscating a transaction, the share of the malicious outputs gets reduced with every new transaction on the network, effectively "repairing" itself as long as the attacker does not keep on producing outputs

MRL-0002: Counterfeiting via Merkle Tree Exploits within Virtual Currencies Employing the CryptoNote Protocol

On 4 September 2014, an unusual and novel attack was executed against
the Monero cryptocurrency network. This attack partitioned the network
into two distinct subsets which refused to accept the legitimacy of
the other subset.

Solution

On [...] the same date as the attack, the first solution to the
exploit was publicly announced by Rafal Freeman [...] The Monero
development team released patch 0.8.8.3 on 6 September 2014 to [...]
allow miners to identify the A side of the network [...] and to
identify foreign nodes with the B-side version of block 202612

Status: Implemented
Elaboration

A bug in the fresh fork of the poorly documented Bytecoin implementation caused this issue that was fixed temporarily on the same day and permanently two days later
The attack made different nodes not recognize each other as correctly working, splitting the nodes temporarily into two parallel blockchains and effectively doubling the amount of funds per person

MRL-0004: Improving Obfuscation in the CryptoNote Protocol

One may have reasonably assumed that the original CryptoNote
developers would have implemented a standardized denomination
requirement for all transaction outputs, but [...] the protocol does
not disallow any strange denominations [...] Hence, no mix-ins are
possible

Solution: RingCT hides the amounts of transactions, making denominations useless and removing dust
Status: Implemented

An observer cannot distinguish which transaction output [...] is the
output actually being spent [...] However, [...] an attacker may model
the cumulative probability that the output has already been spent as
an increasing function of time [...] Hence, [...] the youngest output
used to fashion the ring signature is the most likely output to be the
genuine output being spent

Solution: No solution in sight ( discussion for a solution can be found here )
Elaboration

When an exchange rate is experiencing a [...] inflation, rational
users are more likely to spend their transaction outputs [...] When an
exchange rate is experiencing a [...] deflation, rational users are
more likely to hoard [...] Hence, the distribution of transaction
output ages will at least vary over time, and, presuming any
proportion of users are rational will certainly depend sensitively on
the economic performance of the currency. It is unwise to design
security recommendations around the economic performance of our
protocol.

Note: This issue is currently the biggest issue of Monero privacy and was subject to another scientific paper, which can be found here. This research is under criticism for not clarifying the ties to the ZCash Foundation well enough.

an observer may conclude that the outputs stemming from a common root
transaction are more likely to belong to the true signer of the
transaction

Solution: RingCT will prevent denominations and therefore reduce the probability of outputs stemming from the same transaction
Status: Implemented

if a set of distinct transactions has some common data (such as a
common block height) and if all transactions in this set use mix-ins
with some other common data, then it is likely that these transactions
are related by a common user

Solution: RingCT reduces the amount of shared data
Status: Implemented
MRL-005: Ring Confidential Transactions

One possible attack against the original CryptoNote or ring-coin
protocol is blockchain analysis based on the amounts sent in a given
transaction
it requires a given [...] ring signature with other pubkeys having the
same amount. For less common amounts, this means there may be a
smaller number of potential pairs

Solution: RingCT. MRL-0005 is actually all about how it works.
Status: Implemented


Can Ring Confidential Transactions Range Proofs be pruned? RingCT adds a set of range proofs to each transaction. Can these be pruned? Would there be a need for "full nodes" which retain these proofs? If so, why?

Full nodes cannot prune the range proofs entirely in a trustless manner. SPV nodes and those relying on checkpoints could benefit in the manner described by
Monero Research Labs below:

  While the range proofs are large, using a transaction hashing scheme that signs
  the transaction "prefix" (both input indices and outputs) and stores the range
  proof, along with ring signatures, separately enables large amounts of space saving when syncing to a checkpoint or operating as an SPV node. Similar to Sidechains Elements, we would store H(H(pref ix)||H(signatures)) in the merkle tree.Then, nodes syncing to and trusting a checkpoint need only download the prefix and a hash of the signatures, effectively reducing the amount of bandwidth require to sync dramatically. Because the transaction prefix uses a variant for the outputs it references in its ring signatures and outputs funds to single public keys, they are minuscule in comparison to the ring signature data in the inputs and range proofs. Later, the ring signatures may even be pruned from the database by some nodes to further save space, storing instead only the comparatively small UTXO set.


After major coin issuance, what must the minimum XMR price be to incentivize network security? I'm curious about the tail emission and transaction fees after major coin issuance. What is the minimum value that 1 XMR must sustain as an incentive for miners to continue maintaining network security?

This is kind of a subjective question. Currently the block reward is ~ 10.4 XMR per block or 5.2 XMR per minute. When the tail emission kicks in, the block reward will be 0.6 XMR per block (assuming 2 minute blocks) or 0.3 XMR per minute. If we further assume miners are currently mining at an equilibrium then the price should be approximately 17 times as high to sustain the current hashrate. However, hashrate usually lags price and thus it could be that miners are still mining at a significant profit instead of an equilibrium. In addition, it could be that miners are further optimized in the future, which results in an increase in hashrate for the same amount of cost to a miner.


Error with `import_outputs` : `"Failed to decrypt outputs: Failed to authenticate ciphertext"` We are creating our hot and cold wallets from json files.

The cold wallet-json file looks something like this:

{
    "version": 1,
    "address": "5AS4EbTaHoQ35Qyg3FEg9X25inJDsKCCzBWxDbL2ohGg8DHfhpG47mWQT1T6iA9jKMBGLLRgkPJBhR4Q6SDmWZjSEv7btZT",
    "spendkey": "4abc4c0b853444013c1b3ab5a6ba9220976f685305800acbf6c931dfa897bb0c",
    "password": "0b74713a7080027a0247ff811d42530ed7c9401479c73c0f5711a00fc609c51e",
    "scan_from_height": 0,
    "filename": "/var/Cold/XMR.5AS4EbTaHoQ35Qyg3FEg9X25inJDsKCCzBWxDbL2ohGg8DHfhpG47mWQT1T6iA9jKMBGLLRgkPJBhR4Q6SDmWZjSEv7btZT"
}

And the hot wallet file looks something like this:

{
    "version": 1,
    "viewkey": "f10b92787b01648bd5cab14500f36d5db1fb2391f4a5127a94e99dbdacc91c02",
    "address": "5AS4EbTaHoQ35Qyg3FEg9X25inJDsKCCzBWxDbL2ohGg8DHfhpG47mWQT1T6iA9jKMBGLLRgkPJBhR4Q6SDmWZjSEv7btZT",
    "watchonly": true,
    "password": "123",
    "scan_from_height": 165540,
    "filename": "/home/ksingh/Monero/hot/wallets/XMR.5AS4EbTaHoQ35Qyg3FEg9X25inJDsKCCzBWxDbL2ohGg8DHfhpG47mWQT1T6iA9jKMBGLLRgkPJBhR4Q6SDmWZjSEv7btZT"
}

When we export outputs from the hot wallet, and try to import them into the cold wallet with a curl command like so:

curl -u user:password --digest -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"import_outputs","params":{"outputs_data_hex":"4d66e65726f206f7574707574206578706f727403f7b4ddcc53420e76945ab52934a4c39763cb7b46498e270f25c3284def0dd996dd7737e172abd271e22cf3f18cc5a673a0204b2153d33dfa3003367c2d33f55b5b58caa1376a2a98987049101f03a042b69036229c68f08044f877d157216c9bbf2f544c6a82f217cba4bcd6b223c31b1deb80f61945da5147a7e337711076cf44f1adbdb3e793601d3c1108669707646960a96510c1c2fb3cfb1f8b7aefc292823f12dee8b93765fbf76a69f6be755eebdac1ed6a5aa4a736edcb744f1fa3bf20fec3a5fa546a7bd8d052a0ca7bc4c6d992b13eb091a35fcd1859bb29e8f1d26101616f5e1504c720b67ca98c63e024ad7c2e4bb73e27a79be763eb9a3197374403b21ff7b071e6919ae959528aedda8d0c31ef0ff58372ef7287ce2f367db197ed50f62609837d9254045eb007e266ff760a877b912fb96e81e221ec709b3a9db680a18fb6962cfb2354f0f09596cf4a54e43c99d1816ce0714484a6dcaf0d00a42b5838be6565fb9c56912ef03b980ce6fa4e783828cb0c10782412e095835a3b4138ac9a34095af8d1c3c873918e72fbd4e52b160dce38121afc53f2987a5af1be46ef6f1a06c2ee5df7a7888f02e476f8c3e70a2818f80280f23a3b6df075addce2de5c57bc3a41bf9a5ed0a4d8f5a37ebac5d5a3b5e56ba3a4a9b998691def7a028ee9d5c885cb4cfa8dbe077bf7a84241ecf3b0b469d6e04a0f59fd45cc425729c809b3589f72af4c5a45b3a4c5d879362aaad63fafe02e7d8cd59fee795e9d7e2101fba99d4bffdb429357677aaa3f3e54a253ed8767656d26891d1e1ad0c3a18407"}}' -H 'Content-Type: application/json'

Note: the above curl command may not necessarily be for the same wallet files. Just showing this is an example of what is happening

It returns a response :

{
  "error": {
    "code": -1,
    "message": "Failed to decrypt outputs: Failed to authenticate ciphertext"
  },
  "id": "0",
  "jsonrpc": "2.0"
}

Not sure if what I'm missing.

Another thing to note then I try the import_outputs command using the json_rpc, the response back is a 401 Unauthorized Access.

Your JSON data claims the wrong view secret key for the hot wallet.
When you restore the cold wallet using your data, the viewkey command outputs:

secret: a0b8891884d22bd6e5ac514e79e87011964838c98c8ac468e51194ed2c7c560c
public: 3dba4b6f70744a631aba965544ab3a8e04b952775dfb4149003937b7155eceb6

However, your hot wallet JSON uses f10b92787b01648bd5cab14500f36d5db1fb2391f4a5127a94e99dbdacc91c02 as view secret key.

Note how this causes the hot and cold wallets to display different addresses on load.


How to setup own remote Monero node with maximum security / anonymity? I'm interested in setting up my own remote monero node for personal use on a home computer running OSX. According to this guide all I need to do is setup an SSH-connection with a command line which would look somewhat like this:

ssh -N -f -L 18081:127.0.0.1:18081 username@ip-remote-monero-node

Would it be considered safe to leave my laptop open with monerod running in the background at home on the clearnet and the the Monero GUI with the wallet on a public wifi through Tails? If I'm already outside my home, would it be neccessary to use a VPN over Tails?

Thanks!

The major issue here would be that even though you're using Tails, all your connections end up at your home address which itself doesn't hide your IP.

You are correctly hiding your connection to your node but as this one is in your home and only used by you, it will "imply" a connection with yourself. To successfully anonymise the node it should be ran on a remote server which can't be linked to you by at least not "leaking" your private IP to the net.

In this paranoid situation, having a single transaction pushed to the network from a node used by only you and linkable by IP can imply (but not prove) this came from you. With your current setup I would connect from the Tails computer to a public remote node to be fully anonymised.


Monero GUI not recognising my Ledger X anymore...how can I get it to remember? I set up my Ledger X successfully back in May 2020 and decided against setting up a password for simplicity's sake. I recently updated to the new MUI 0.17.1.4 - Oxygen Orion in preparation for the recent upgrade to the network. When I tried again, this error message appeared for which as a crypto novice, I have no idea what to do!
Foolishly, although I have a backup of the keys file I did not note my private or public keys that are needed to restore the device. I have my ledger, the GUI and the keys files. Could anyone offer pointers to what troubleshooting measures I can take to find my way back to wallet heaven? :)

You should not worry for your assets. Those are kept safely on wallet created from private keys kept on your ledger device. So as long as you have access to your ledger and its seed/pin/passphrase it should be all fine. In your case, restoring the wallet should make it work again. Open Monero GUI App and close any wallet which is opened by default. Choose an option to make a new wallet: "Create a new wallet from hardware". Then you should go with option "Restore a wallet from device". After creation and some wallet syncing is done you should be able to access your assets again. Let us know how it went.


Issue with Hardware Wallet after GUI v0.16 upgrade I just upgraded my GUI wallet to the Dandelion version, now I want to make a new wallet with my hardware wallet but it is not letting me, I get this error: "Error writing wallet from Hardware Device. Check application logs". I do not know where the logs are though.

The error log is nowhere to be found.

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.