Is there a way to see the total supply of coins?

The untraceability of the monero blockchain is achieved by the use of ring signatures to sign transactions. The block reward does not have the ambiguity of where those coins came from. They came to existence as the reward for finding that block.

Therefore, it is possible to know how many monero are in existence simply by adding all the block reward (or coinbase) transactions in the monero blockchain.


Monero is not some entity
Welcome to the world of domain name ownership

I'm sure there are many people involved with Monero that would host a site at that domain name, getting control of the domain name is another matter entirely.


How can I verify the SHA256 hash of 0.10.3 "Wolfram Warptangent" on Ubuntu?

Find the correct download on the official Monero website and go to your downloads folder. Open the terminal and use this command:

sha256sum monero-linux-x64-v0.10.3.0.tar.bz2

If you receive the following output you will know that the hash matches the GPG signed message listing the correct SHA256 sums

  f164112bea75dfd3eaaa905d21129820a996bbe6e5d65cb194609c672a71c3fe  monero-linux-x64-v0.10.3.0.tar.bz2


There are two main reasons a program can not bind to a socket:

the port is already used: typically, for the Monero daemon, this means another monerod is already running. You can check whether monerod is running by looking at the process list (ps, top, or other tool), or whether monerod or another program is already bound on that socket using netstat -ntpa (flags may vary based on netstat variant used). The fix for this is to stop the program currently using that port, and try again (or, if it's already monerod, do nothing, since it's already running)
the kernel or other software controls binding and denies the attempt: this happens on Windows, where firewall and/or antivirus software can be set to prevent software (or unprivileged users) from setting up a server process on the machine, or on Linux (and maybe Windows) when trying to find to a privileged port (below 1024). monerod's default P2P port is not privileged, however, but Windows might have different rules for this. The fix for this is to configure the kernel/firewall/antivirus to allow such access.


bad balanced CURRENCY_BLOCK_GRANTED_FULL_REWARD_ZONE constant

The issue sounds like a wallet has a wrong view of what outputs are spent. A fix would be to rescan the wallet (rescan_spent or rescan_bc in Monero's wallet, or delete the cache file).

The "full reward zone" is completely and entirely unrelated to potential wallet sync issues.


Can Monero in its current state handle the amount of daily transactions bitcoin does, and if so how long would a confirmation take?

The reason bitcoin network is struggling is that there are too many transactions trying to get in a block, but the maximum allowed block size is hardcoded into the protocol rules. Nothing that can't be fixed - the amount of transactions is by no means massive. See here for some historical background on the subject.

Monero, on the other hand, never had such a hardcoded limit, but has a dynamic block size limit, where miners are allowed to expand the block size cap to accomodate more transactions. In fact, this was already proven to work in practice when the Monero network was tested during a spam attack (another relevant link) because the attacker needed bigger blocks to execute another attack, which was later analyzed by the MRL. Note that a prolonged spam attack is unsustainable, because the miner inflating blocks with his own transactions doesn't get any transaction fee, and will be penalized by losing the block reward. Idea is that when the network grows organically, miners would be giving up some block reward to get more transaction fees.

So yes, Monero would probably do just fine and no delays should be expected.


What is the bare minimum to mine?

Pretty much any computing device can mine.

What are pools used for

To pool the resources of multiple miners to increase the chance of finding blocks.

and what Linux x86 program could I use to mine Monero?

XMRig for pool or solo mining, the official wallet/daemon for solo.


Can a pool keep blocks for itself without giving out rewards to miners?

Yes. This is one of a few problems with current pool implementations.

Miners are trusting pools to:

give miners their fair share of any blocks the pool mines
payout on all blocks mined
not censor transactions
give miners hashing blobs for the main chain they want to mine
not be performing a 51% attack
display accurate information about the pool (e.g. its hashrate, payouts, etc)


can't access monero wallet or run a node

I just noticed that it was in the .bitmonero directory. i just copied and pasted everything there in that directory to be safe and deleted the directory.  Then i downloaded the latest zip file from moneros site and ran monerod again and it worked. @barrystyle I guess you were correct thank you!

  "There was a hardfork about 2 months ago (hardfork v3); this would be why (more than likely). I'm guessing that your old version has continued past the hardfork blockheight, without it knowing, and you are on an invalid chain." - barrystyle


Wallet transfer/disbursement after death

Even if not implemented on wallet, you could use secret sharing - such as Shamir's secret sharing with, for example, three keys to encrypt your wallet or wordlist. Then you would keep one with yourself and the other two with trusted relatives. Your key alone wouldn't be able to decrypt your wallet. So you could keep it in your Will, so that when you die your relatives could use their keys and your key to decipher your wallet/wordlist.


Which mining of Monero is more cost efficient CPU or GPU?

The NVIDIA 750 Ti returns about 250 H/s with about 60W of energy (hash source, wattage source).

I do not have data on the i3-6300T, but the AMD FX 8350 also returns about 250 H/s (source), and this should be a faster processor than the i3-6300T (I'm guessing 150 H/s). The i3-6300T uses about 30W (source).

Use the Monero mining calculator here to determine which is best for you based on your energy cost.


Can I run monero desktop wallet over Tor?

There are detailed instructions for using Monero over TOR on the project homepage: https://github.com/monero-project/monero#using-tor.

Essentially to use the GUI wallet over TOR, you'd need to have a daemon running on TOR also. Then use torsocks when connecting to the daemon.


Are mining pools shares based on prescribed difficulty or the actual difficulty you hash a block with?

You're are correct in assuming target is the same as difficulty

Question 1: You are just credited for the difficulty nothing more. You are set with a threshold to meet to prove you are mining however these shares hold no value unless they are the solution to the current block so you will not be rewarded extra for mining below the threshold, neither will you be paid extra for finding the block solution.

Question 2: The number of "shares" you receive is relative to your difficulty those with a higher difficulty will receive more shares.


What kind of pruning techniques does AEON use?

These questions are answered by the pruning FAQ, which was posted by core-developer smooth, who is also a core-team member of Monero.

Pruning FAQ
Q: What is pruning?
A: Pruning refers to removing unnecessary information from the blockchain once it is no longer needed.
Q: What are the advantages?
A: Pruning reduces the amount of storage needed for the blockchain. If the blockchain is loaded into RAM (which is the case in the current implementation), then it also reduces RAM usage. Finally, it also reduces the rate that these resources are consumed over time as the blockchain grows. In the current implementation, each time one new block is accepted, one old block is pruned, on average freeing up a large portion of the resources needed for the new block.
Q: How does pruning affect functionality?
A: The only inherent functional limitation of AEON's pruning is the inability to restore (also known as rescan) a wallet which was used for spending transactions. All other functionality including sending and receiving coins, mining, updating a wallet after any period of inactivity, cold storage, mining, etc. remain fully supported. There is a current limitation that after extended period of disconnection (>28 days) a node may have trouble resynchronizing with the network, and would need to be reset. This is not inherent and should be addressed later.
Q: Does pruning reduce the effectiveness of ring signatures for transaction privacy?
A: No, ring signatures and privacy are unaffected.
Q: How is pruning enabled and disabled?
A: Using the --pruning option on the daemon command line. With this option the daemon will prune the blockchain and will also switch from using the blockchain.bin file for storage to blockchain-pruned.bin. To switch an existing node into pruned mode, copy blockchain.bin to blockchain-pruned.bin before starting the daemon with --pruning. To switch pruning off, remove the --pruning option. Do not, however, copy blockchain-pruned.bin to blockchain.bin. This will not work. You will need to have an unpruned blockchain.bin file or resync unpruned from the network.
Q: How does AEON's pruning compare with Boolberry's pruning?
A: AEON prunes slightly more information from the blockchain, so the required storage is slightly smaller (given equivalent usage), though the difference is likely not particularly significant. BBR prunes the blockchain on the entire network while AEON prunes on each node individually (and only if pruning is enabled). This means that new nodes can come online faster with BBR, but those new nodes are unable to independently verify the entire blockchain. It is possible to download an unpruned BBR blockchain from a web site to independently verify it, but in that case the amount of data downloaded would be the same as AEON. It also means that every BBR node is able to serve the chain to new users but in AEON this function falls to nodes that are unpruned, also known as "archive nodes" (or alternately via a trusted bootstrap file).
Q: How does AEON's pruning compare with Bitcoin's pruning?
A: In Bitcoin 0.11, the same model of pruning is implemented as in AEON. That is, nodes prune blocks locally, after syncing from an unpruned chain and verifying the chain independently. Like AEON, Bitcoin pruned nodes can't rescan or reindex wallets. Bitcoin 0.11 does not support wallets on pruned nodes at all, so it currently has more limitations that AEON. Old Bitcoin blocks must be retrieved from unpruned archive nodes, as with AEON.
Q: What other coins implement pruning?
A: Other than Boolberry, Bitcoin, and possibly some coins which have inherited their implementation by being Bitcoin forks, no other coins implement pruning at this time.
Q: What's this about "archive nodes"? How can I run one?
A: When nodes connect to the network, they retrieve blocks from other nodes. If only blocks within the most recent 10 000 (approx.  28 days) are needed for syncing, even pruned nodes can provide them. However, in the case of nodes which are brand new (syncing from the genesis block) or which have been offline for >28 days, pruned nodes will be unable to supply the older blocks. Instead this task falls to unpruned nodes, also known as archive nodes. For the time being the project-run seed nodes will always run in unpruned mode, and others with sufficient RAM and storage space who wish to support the network are also encouraged to do so. To run an archive node, simply start the daemon in the normal manner, without the --pruning option.
Q: What are the numbers? How much does pruning reduce the amount of memory and storage needed?
A: The exact numbers will vary according to OS, compiler, etc. and also depend on the usage of the blockchain in the future. One early report from BoscoMurray stated, "RAM usage down from 4.8GB to 2.4GB and blockchain file size down from 3.2GB to 1.7GB"
Q: That doesn't seem like a big reduction. Why is the benefit not greater?
A: To explain why the reduction is not larger and understand what this means for the future, let's first review some basics of how a blockchain works.
Every time a coin is spent, a digital signature accompanies the transaction in order to show that the owner of that coin authorized spending it. Once this signature is checked, it is no longer needed. This is the largest portion of what is being pruned. In the cryptonote signature scheme (used by AEON), ring signatures used for anonymity, which means while a signature shows the coin owner authorized the transaction, unlike conventional signatures, it does not identify the specific coins being spent, and therefore does not allow tracing and analyzing the blockchain. As a side effect of this functionality, these signatures are much larger than ordinary digital signatures (a fact sometimes described as "cryptonote bloat"). Thus in AEON, pruning offers great benefit and eliminates the "cryptonote bloat".
So why is the savings not larger? Because in the early history of AEON, there was a very large number of very large transactions and many of those transactions did not using ring signatures. This happened for several reasons, including a major flaw in the early versions of cryptonote mining pool software. Thus, while the chain is relatively large, a relatively small amount of storage is saved by pruning the early transactions.
The newer transactions are a different story. The pool software flaw was fixed long ago, and most transactions now do use ring signatures. So the savings from pruning going forward should be much higher (perhaps 75-80%). Of course, since ring signatures are now being routinely used, it means that that actual anonymity of the coin in practice is greatly improved, and with pruning there is no long term storage cost (i.e. no "cryptonote bloat") for most nodes (other than archive nodes). We get the best of both worlds!
Q: What about a database or disk-based block storage? Doesn't that also reduce memory usage?
A: Storing the blockchain out-of-memory in a database or in cache files reduces memory usage but does not reduce storage usage nor reduce the rate of growth of storage usage over time. In AEON, the plan is to later support out-of-memory storage of the blockchain along with pruning, so memory usage will be further reduced, and storage usage will remain low and grow very slowly over time.


Multiprocessing vs multithreading for mining

XMRig is designed to run as a single process with multiple threads – if it were faster the other way round, it would have been changed to run easily that way instead.
In any case, the maximum hashrate possible with either #1 or #2 is likely the same.


(A speculative answer): Yes, it seems that most exchanges have 0.05 XMR withdrawal fee. Monero transaction fees are quite high but not that high. Perhaps the exchanges try to offset the cost of Monero integration. Remember that XMR has no common code with BTC and its' clones, so it must have been more costly to integrate than another BTC fork/spinoff. Hopefully the fees will drop with growing Monero popularity.
You may try Monerujo for Android, or the CLI version which is not resource-demanding. There are also online wallets but I'm not in a position to point you to any of them. Only reminding you to be careful here, because with online wallet you should always assume that someone else has access to your funds.


Is the XMR network vulnerable to Denial-of-Service attacks?

Something like this had already happened, with no impact to the network performance. It was a prelude to the actual attack, the infamous block 202612 attack. Quoting fluffypony in the bitcointalk thread (emphasis mine):

  The fork was the intention and the net-effect. They would have had to
  mine two of those blocks in parallel and dump them both on the
  network. It's such a bizarre, unknown, unidentified edge-case that I
  can't imagine someone stumbling across this AND figuring out how to
  exploit it (and to what end??). There's no monetary gain to the
  attacker, and with the hike in fees to mitigate the previous attack I
  can only imagine that this would've cost them a pretty penny.

The attacker had to first raise the max. block size limit to be able to carry out the attack. On the positive side, this served as a test of Monero dynamic block size which performed well. As said above, it had probably cost the attacker a significant amount in transaction fees, and it would likely cost more today.

Yes, it's possible to flood the network, but it would adapt by dynamically increasing the block size so there would be still be enough room for all the transactions.

The attack would have an insignificant and ever-increasing cost to sustain (tx-fees), making it impossible to sustain the attack.


How is there no key image for the commitment to zero in MLSAG?

An MLSAG is a generalized version of the bLSAG ring signature, that says:

Build a ring, where each ring 'member' is a key vector.

A key vector is a list of public keys.

To build a ring that successfully verifies, you must know the private keys corresponding to each of the public keys in a certain key vector.

As a matter of agreement between the signers and verifiers, it is decided which base points apply to each of the public keys in the key vector.

As a matter of agreement between the signers and verifiers, it is decided whether any particular public keys are also required to have key images proven.

If it is agreed that any particular public keys require key images, then this will prevent anyone from signing with the private keys for those particular public keys twice.

  I was under the impression that there is a keyImage for each key in
  the ring.

The Monero agreement is that you need a key image only for certain public keys listed in the key vector. The input public keys require a key image, but not the commitment public keys. This is because it would be unnecessary and more demanding both in terms of computation and storage to enforce that a certain commitment is never signed for twice.

  It seems it is done by not including that section in the calculation
  of the challenge. So to sign for an input(CommToZero, OneTimePubKey)
  we will have one keyImage, two private keys and two public keys.

Yes, that is how it's done.

  I was under the impression that there is a keyImage for each key in
  the ring. So if the ring has 10 users and each user has 4 keys, then
  the MLSAG will output 4 key images, 1 challenge value, 40 response
  values and 40 public keys

I'm interpreting this as a ring size of 10, where someone is attempting to spend 4 inputs.

This is done using the RCTTypeSimple method in Monero, which creates 4 MLSAGs, one for each input being spent. Each of those MLSAGs would declare a key image for the input, there will be 10 key vectors, each with 2 public keys (the input public key and the commitment subtraction).

Therefore there would be a total of 4 key images, 40 key vectors, 80 public keys being signed for, and 80 response values.

You can double check this from the calculation in the answer here: What would the space saving difference be if MLSAG was applied over all inputs?

The space requirement for an RCTTypeSimple MLSAG signature is:  32*m*(2*n+3) bytes of storage. In your example, m=4 and n=1, therefore 2944 bytes of storage is required, which is a total of 2944/32=92 EC points and scalars that need to be stored (both EC points and scalars are represented using 32 bytes each). 92 = 4 key images + 4 challenges + 80 responses + 4 pseudo outs.


How do I start the GUI for a testnet wallet?

There's a bug in the gui beta preventing the testnet setting to be saved when opening wallet from file. As a workaround you can create a new testnet wallet and then close and reopen your old one. When you switch back to main net you need to repeat the same procedure: Create a new main net wallet before opening from file.


Can Monero transactions contain scripts?

There is no scripting language in Monero at the moment (the Cryptonote paper describes a simple one, though, if memory serves).


This post should help you a lot. It discusses how to set bandwidth limits.

You can change them, either when starting monerod:

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

or at runtime (while monerod is already running):

limit                   limit <kB/s> - Set download and upload limit
limit_down              limit <kB/s> - Set download limit
limit_up                limit <kB/s> - Set upload limit

I would suggest setting your upload limit to something slow like 10 KB/s. Setting it to 0 would make it hard (maybe even impossible!) for you to find other peers to download from.


Figured it out.  The issue was because of the new version of GCC.  There is a fix for the issue in the newest CMake file but I was building the latest release so I just needed to manually apply the fix.  https://github.com/monero-project/monero/pull/4290/commits/2bc977bab9b9a2fa97e034357606270804a3e0df


Are there test executables that Monero does not run?

There are a few. core_proxy is one. The clt and srv in net_load_tests are others. The C++ functional tests is another. I think that's the whole list.


Payment processor for DigitalNote (Cryptonote coin)?

I am not aware of a payment process for XDN.

One thing you could do is look at, say, https://github.com/TheKoziTwo/xmr-integration and modify it to support XDN. This might involve porting some Monero specific RPC calls, but most of it ought to be fine, since both Monero and XDN are Cryptonotes.

I would be wary of using a "pay for support" site, as some of them are scams, and others may drop you without further warning if they stop getting payments.


Pedersen Commitments of Monero output amounts are published, instead of publishing the actual amounts in the clear. Borromean Ring Signatures are used for range proofs on those Pedersen Commitments, which prove the amounts are not negative.

Monero signs transactions with MLSAG signatures. See https://lab.getmonero.org/pubs/MRL-0005.pdf


Monero comparison wiki states zcash is not "decentralized": why?

The monero comparison wiki states zcash is not decentralized. Why?

The link you posted in your question, if you scroll down the page, has a pretty thorough answer to the question.

Most common criticisms of Zcash are the "Trusted Setup" and the "Founders Reward".


Disclaimer: I can only compare with my own mining experience.

Assuming this subquestion is about solo-mining. Short answer: Yes. Long answer: When you issue monerod status, you'll see both the network hash rate, as your own hash rate. E.g. if you're mining at 250 H/s and the network hash rate is 25.00 MH/s, you'll (on average) find 1 block out of every 100.000 blocks. Since there's a block about every 2 minutes, that'll occur (on average) every ± 139 days. Currently, coinbase reward is ± 9.74 XMR. Nobody knows what the network hash rate (and difficulty) will be in 139 days, so it's a bit of gamble to do solo-mining (if the network hash rate would ramp up dramatically).
Since the official miner is a solo-miner, I suspect it isn't used that widely. There are a number of pool-mining alternatives, both proprietary and open-source. Most mining pools provide an overview of compatible software on their "Getting Started" page, e.g. minexmr.com. It's almost impossible to tell which miner would give you the best bang for the buck, as performance is heavily depending on your specific hardware setup. However, your connectivity to the mining pool and its stability play also significant role. It's best to experiment with the available options. Unfortunately, mining software isn't very macOS-friendly (especially when you want to do GPU-mining).
With regard to mining pools, I would recommend to visit this monerohash.com page. You'll see an overview of Monero mining pools, along with a nice chart that depicts their respective share in the network. Thinking about decentralization, it is generally recommended to join one of the smaller pools. Pay-outs should still be relatively frequent and predictable.

P.S.: I agree with some comments that I would be easier if questions were split up.


What is key64 data type supposed to represent?

typedef key key64[64]; [ref]

So it's an array of 64 key's.

And a key is a struct that holds 32 bytes [ref].

Quoting the comment for the key struct:

// Can contain a secret or public key


Yes.

The intent of mixin is to make it ambiguous which output in a ring is being spent. This still applies, whether the amount of the output is visible or not.

As an example of a case where this matters:

Alice sends Bob output P in a transaction. Alice knows the size of that output (she created it). Alice can then track on the blockchain to see when that output gets included in a transaction. With mixin 0, Alice knows Bob respent that output (though does not know where to). With mixin > 0, Alice does not know, since it could be either Bob, or someone else using that output as a fake out for their own ring signature.


Is it possible to avoid Monero address re-use without having to create a new wallet for each transaction?

Update May-2017: there has been some novel research into this, and it will be possible to tweak the sending wallet to allow sending to a special address acting as an "alias". The funds would go to the same wallet regardless of the number of these "alias" addresses used. The scheme makes it so that given an "alias" address, you can't work out the regular address or other aliases. Again, the actual records on the blockchain would never store any public address (be it regular, integrated, or alias), but the sender would generate a seemingly-random one-time destination address, as usual.

Read up on Github: https://github.com/monero-project/monero/pull/1753

I will attempt to answer the question while considering what had been discussed through other channels: Reddit, IRC/Slack Pt.1 & Pt.2

First of all, let's get the terminology straight to avoid confusing the similar terms.

Address / stealth-address: any Monero address is also a stealth address. This is because it never appears on the blockchain and is used only to calculate the one-time public key which is the destination of an output. Will be referred to as (A,B) where A is the public view key and B is the public spend key. Small-caps are the corresponding private keys.
One-time public key, referred to as P is the one time destination of an output. Generated from the stealth addres public keys and sender's random data.
Sub-address: I propose this term for the addresses created using the proposed scheme. It's another normal Monero address but generated in a special way so it can be derived from (a,b,k). It will be referred to as (C,D). It's worth highliting that any of them could be used as a stand-alone monero wallet if the keys (c,d) were to be imported.

  What would be the benefit over a HD wallet scheme?

The proposal boils down to having the recipient give to sender his (C,D,k) and the sender is expected to include the k in the transaction data when paying to (C,D). This way, the receiving wallet has to scan every one-time publick key on the blockchain only twice:

first time with the assumption that the payment was done to (A,B), using a
second time with the assumption that the tx data contains k, so it attempts to check if it belongs to a matching (C,D) by using c derived from (a,k)

Now, let's compare this against a HD wallet. It would have to check each output against every address belonging to it, so the refresh time would grow linearly with the number of addresses used. From this point of view, there is a clear benefit of the proposed sub-address sheme.

  Would it affect the blockchain size if implemented?

Yes, as it is required to store the k on the blockchain. It could be in the range between 1-32 bytes, depending on the details of implementation.

  Would there be any loss in privacy if such a scheme was to be used?

It depends. Let's consider some options:

Have k randomly generated and limit the size of it in a way that collisions are expected often. This would mean that there would be many transactions with the same k, but not neccessarrily belonging to the same user. Also, if it's generated randomly, distribution should be uniform. This allows for accidential or intentional re-use of the (C,D,k), which is not neccessarily a bad thing.

Consider we limit size of k to 1-byte. This would give each wallet 256 sub-addresses to work with. Once exausted, the user could start to re-use some old ones or archive the wallet and start using a new one. This way we have linear growth again, but slowed down 256 times, which may be just enough to preserve reasonable refresh time. Remember, the only reason HD wallets are inconvenient is the long refresh time it would take them.
Privacy would be preserved, but some loss of it would occur as we could assert that some transaction belongs to the group of users who decided to use the proposed scheme. In fact, we have the same kind of situation with payment ID now as some transactions have it and some don't.
If the protocol would enforce the k to be non-empty, then some random data could always be written in place of k when it would not be used, and it would completely preserve privacy while increasing the size of blockchain for a fixed amount / each tx. This way, every transaction would have a number 0-255 associated with it which would hint to the recipient which (c,d) to use.

Have the k randomly generated and of size big enough to avoid collisons. Also, re-use should be prohibited by the protocol.

In this case, collisions should be avoided entirely because if size of k is big enough. This is because it would be unlikely that 2 different users would happen to "roll" the same k, so one could assert that its more likely that any 2 transactions found on the blockchain belong to the same user because the (C,D,k) could have been re-used, accidentially or intentionally.
If we would enforce k to be unique, then any accidental collision would make the 2nd transaction fail to send if another one with the same k would get in a block first. The chance of this happening would be reduced with increasing the size of k.
Again, we have the potential loss of privacy if they're not enforced. Here, we'd increase the blockchain size more just because k has to be bigger for this option to work.

Also note that it may be better to opt for some deterministic scheme to generate k on the receiver end, like k=H(a,0..n). This way, the k would appear as random to the world, but the user would have a way to restore the list of (C,D)s issued in case he would lose the wallet file.

  Would there be any risk to user funds?

It would depend on the implementation adapted. Imagine that the sender, for whatever reason, just sends to (C,D) and omits the k in the transaction data or puts a wrong one. If size of k is small enough, the receiver could attempt a fall-back method to try every k for each one-time public key. This way, his refresh time would be 128 times longer than usual, but he'd have a chance at recovering the funds. If allowed size of k was too big, the funds would probably be irrecoverable in some cases. In case deterministic ks were to be used, I guess it would mitigate this risk as well.

  Is a protocol change required for this to work or could it be done entirely wallet-side?

Not required but it could be desired for some cases. If it was to be implemented using TX_EXTRA, then all it would need is to be supported by the sending and receiving wallets. Some new address scheme could be used to pass all the data (C,D,k) in one string to avoid accidents with omitting the k. Compatible wallets would be able to read this address, while others would just report an error.

  Are there any other points to consider?

There was talk about using payment ID as k and also consideration of using integratted addresses. Later it was realized that integrated addresses can't really work with this scheme as there is a chicken-egg problem involved in those :)
There are surely different ways to go about generating (c,d) from (a,b,k) so this could use some further examination.
There was a suggestion to look into bi-linear groups, but I can only mention it as I know nothing about this.
Further consideration would be needed to see how this would fit together with payment IDs. Also, k should be protected from pruning, if it's ever implemented.
Some other clumsy scenario with handling these kind of addresses?
Some neat crypto-magic which could help in solving this in the most elegant way?
What happens if we make a transaction sending to multiple addresses in the same tx?


How to create an integrated address with a payment id on Monero v12 GUI?

The payment ids and integrated addresses are supposed to be phased out and replaced by subaddresses, which is why the integrated address generation was removed from monero-wallet-gui 0.12 and replaced by the subaddress generation.

For example, if you have some customers who have to pay you, instead of giving your main address and a payment id or an integrated address to each of them, you give a subaddress to each of them.


How can I increase the database cache size?

No.

If you mean disk cache, assuming your OS isn't too dire, it should cache what's needed, and take it back when needed.

If you mean another type of cache, then the answer is still no, but with no extra comment :)


Can the Monero block chain be used for anonymous communication/ data storage/ private records for small to big entity?

You can put potentially any data into tx_extra and it will be stored on the blockchain with your transaction, only accessible with your keys.

This however, will bloat your transaction size and your transaction will be more expensive as you have to pay per kb. For now, beside the elastic blocksize limit (median of last 100 blocks * 2) there is no maximum how much data tx_extra can contain, so if you can afford, you can store almost anything you want.


EXCEPTION FOR BLOCK 202612 , from what's it bassed and where it was fixed?

There was a bug in the tree_hash function used to compute the transaction Merkle tree that caused the hash of block 202612 to be bbd604d2ba11ba27935e006ed39c9bfdd99b76bf4a50654bc1e1e61217962698 instead of the correct value 3a8a2b3a29b50fc86ff73dd087ea43c6f0d6b8f936c849194d5c84c737903966.

There is a comment in the file src/crypto/tree-hash.c about this:

// The blockchain block at height 202612 http://monerochain.info/block/bbd604d2ba11ba27935e006ed39c9bfdd99b76bf4a50654bc1e1e61217962698
// contained 514 transactions, that triggered bad calculation of variable "cnt" in the original version of this function
// as from CryptoNote code.
//
// This bug applies to all CN altcoins.
//
// Mathematical bug here was first published on 14:45:34 (GMT+2) 2014-09-04 by Rafal Freeman <rfree>
// https://github.com/rfree2monero/bitmonero/commit/b417abfb7a297d09f1bbb6de29030f8de9952ac8
// and soon also applied to CryptoNote (15:10 GMT+2), and BoolBerry used not fully correct work around:
// the work around of sizeof(size_t)*8 or <<3 as used before in 2 coins and in BBL later was blocking
// exploitation on normal platforms, how ever we strongly recommend the following fix because it removes
// mistake in mathematical formula.

As block 202612 has been accepted in the blockchain with the bad hash, this bad hash is now hard coded as the "official" one instead of the mathematically correct hash.


Monero does not require that "mixing" happens at the same time that other spenders want to "mix" their coins.  Rather, the sender constructs the complete transaction prior to broadcasting it to the network.

The sender's wallet chooses one or more of its own outputs to spend, and then it picks other actual outputs from the blockchain to mix with its own output(s), all of which are included in a ring*.  By attaching a key image and signing the transaction, the sender has (a) proven that it has ownership of an output from the ring, (b) proven that the output has not been previously spent, while (c) not revealing which output is being spent.

*There is one spent output per ring.  If you spend two outputs, that means there will be two rings, each with its own ring members and key image.


What is to stop an adversary from inserting malicious code through Monero's compiling software?

It depends on how you got make/gcc/etc. in the first place. I'm going to assume that you got an "official" copy and verified its signature (which is automatically done if you use a package managemement system, like apt for example).

So someone would have to push a malicious change to the compiler codebase and have that change go through the 100s of pairs of eyes that monitor the code without anybody noticing. That's very unlikely and, to be honest, less probable than having a bug (malicious or not) in the monero codebase.

In the end, you could have malicious code running on your hardware, in your OS, in the compiler etc.: you always have to trust someone...


Possible to mine on nvidia Pascal (10xx) GPUs?

My EVGA 1070 Founders Edition maxes at 470 h/s with Tsiv's CCMiner pool software, though its possible I'm missing some settings that could help it hash higher. Pretty stinky scores. This is worse than many older cards. Basically, there is not yet good public mining software for the newer cards.

Source code found here: https://github.com/tsiv/ccminer-cryptonight/
Compiled Windows binaries are under "releases".

Instructions for compiling on Ubuntu 16.04 here: https://steemit.com/monero/@mobidick/how-to-mine-monero-on-ubuntu-16-04-using-ccminer-cryptonight


Why does Monero have 12 decimal places compared to Bitcoin's 8?

The answer is both fascinating and altogether boring, in that it makes you look back to the very beginning of Monero (then "Bitmonero") and the period right after the clear-net debut of the supposedly two-years-old, dark-net-only Bytecoin.

Basically, for reasons beyond this answer's scope, Bitmonero was created as a fork of Bytecoin, the original Cryptonote implementation, shortly after people first heard of Bytecoin in 2014. It's goal was to have a fair launch of a cryptonote currency, and the original creator "thankful_for_today" decided to change up a few of the parameters of Bytecoin so it would not be a carbon copy.

One of those parameters that was changed was that the decimal point was moved: Bytecoin shared Bitcoin's definition of 1 coin = 10^8 atomic units, but had a much larger money supply of ~184 billion coins (2^64 - 1 to be exact). Because of this, block rewards were 4 orders of magnitude higher for Bytecoin than Bitcoin, which thankful_for_today did not like. So he changed it. BUT, note that he did not change the approximate money supply, 2^64 - 1 atomic units.  He simply moved the "coin" decimal place 4 places, to where Monero has an approximate money supply (before tail emission) of 18.4 million, instead of 184 billion.

We can speculate all we want about what the main motivation here was... one that comes to mind is a desire to have a money supply similar to Bitcoin's 21 million coins... but the simplest explanation is probably the best: thankful_for_today wanted to less coins and small block rewards because smaller coin quantities "is much easier for practical use" [1]. In other words, why pay 100,000 coins when you could pay 10? As for why he moved the decimal instead of changing the maximum number of coins? Most likely because it was the simpler change, and probably also because he liked the idea of having 12 decimal places because that helped make Monero more unique.

References:

Original Bitmonero Announcement Thread on bitcointalk.org
https://bitcointalk.org/index.php?topic=563821.0


How long would it take to get the monero blockchain size to over 100 GB and 200 GB at today's usage rate?

Looking at https://moneroblocks.info/stats, the current growth rate looks to be about 400 MB per month, average over the past last half year. This is about 5 GB per year. This means reaching 100 GB (+30 GB) in 6 years, and 200 GB (+130 GB) in 26 years. This is assuming no increase nor decrease in usage, nor in software improvements (transactions are likely to get 25% smaller in the next fork).

Monero will support pruning in the coming release. a 70 GB database prunes to about 25 GB. The effect is smaller on current bulletproof transactions than previous Borromean proof based transactions though. I'm not quite clear what the practical growth will be for a pruned blockchain compared to 400 MB, but it should be significantly lower, increasing the times above.

To your last point, blocks do not get smaller with more usage. They will get larger, since they'll have to store more transactions.


The instructions linked here will get the non-official build up and going on Ubuntu i386.

https://www.reddit.com/r/Monero/comments/4yp52w/super_simple_build_instructions_for_the_monero/

# Early Monero-GUI setup and build instructions:

# For best results, I used Oracle's VirtualBox to make a virtual machine and loaded a fresh install with the latest Ubuntu 16.04 i386 iso. **NOTE** Be sure to have at least 15-20gb allocated for space on the virtual drive, and no more than 3gig of RAM for the VM (as for me it crashed with more than 3 gig of RAM).

# Ubuntu 16.04 i386 Monero GUI Install instructions (these are the exact instructions and links I used. The VM was set up on a Windows 7 installation)

# grab a copy of virtual box and follow the install instructions here http://www.psychocats.net/ubuntu/virtualbox , and
# grab a copy of Ubuntu's latest iso if you don't have it yet, http://releases.ubuntu.com/16.04.1/ubuntu-16.04.1-desktop-i386.iso.torrent

# after Ubuntu is installed and running, go into the command line and run these commands...
# update Ubuntu's repository
sudo apt update

#install git to download latest Monero source code from github
sudo apt install git

# install bitmonero dependencies to be able to compile Monero, taken from here: https://moneroexamples.github.io/compile-monero-09-on-ubuntu-16-04/
sudo apt install build-essential cmake libboost-all-dev miniupnpc libunbound-dev graphviz doxygen libunwind8-dev pkg-config libssl-dev

# go to Ilya's repository where the most recent version is (you can run this while the previous command is running)
git clone https://github.com/mbg033/monero-core.git

# go into the repository
cd monero-core

# use the script to make sure everything is in order and compile the bitmonero libs necessary to run the GUI
./get_libwallet_api.sh

# install the GUI dependencies (this can be run while bitmonero is being compiled with the previous command)
sudo apt-get install qtbase5-dev qt5-default qtdeclarative5-dev qml-module-qtquick-controls qml-module-qtquick-xmllistmodel qttools5-dev-tools qml-module-qtquick-dialogs

# build the GUI
qmake
make

# To run the GUI, don't forget to have a bbitmonero client running in the background for the GUI to talk to, it's probably not necessary to have an updated blockchain, but if you have one on hand you can load into the machine it certainly won't hurt. The GUI should run without the node, but you still must follow all the steps listed, so this command is optional.
./bitmonerod --rpc-bind-port 38081

# go to the directory where the compiled client is
cd /release/bin

# run the GUI client
./monero-core


My questions are: can this be considered an encryption/decryption scheme and is it already known or is it original to Monero?

Pedersen commitments (which are a commitment scheme not "an encryption/decryption scheme"), have been around since the early nineties. The encryption bit of what you refer to is simply the XOR of the amount and a key, the latter of which is a hash of a piece of data only the sender or receiver can construct (as it makes use of the shared secret). Using XOR to encrypt data is extremely common and certainly predates even Pedersen commitments.
What's original to Monero is how these elements (and others) are brought together and what they are applied to (i.e. a cryptocurrency, private digital cash). The security properties of all these elements is already well researched and understood.


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.


Since StackExchange prefers content to be on the site rather than through links, I've transcribed and annotated the information from luigi1111 on PasteBin to make it more accessible for readers.

Stealth Short Payment IDs

This is a proposal for shortening both "user" and "blockchain" payment IDs from 256 bit (32 bytes) to 64 bit (8 bytes), incorporating a stealth feature to improve anonymity, and adding a new shorter v2 integrated address.

We are basically discussing three different aspects here, which aren't strictly related:

Stealth IDs which change every TX similar to addresses
Shortened IDs have less characters since the current 256 bit requirement is absurdly large and unnecessary. See examples below

  Standard (95):
  45BEPXEXAN6YrvHgP3owF8GCzBZ2vCZNb9sMxZG6D7iuSvjVret5ciY2GfqVMHZiPoTEEcmSmVhcyaReTjJafrSqV26ZoYE

  64-bit ID integrated (106):
  4TZ76dT4mbsizsTtJzy7kYBo9f8xduc8wTsWb86pCmx5Cmh43CDxNS1FRcMrE3CNQ2ZT17vzCudc5TbNYBzizwqZFah5K1Js7VpL88qPSi

  Full 256-bit ID integrated (139):
  4LRv6jJYxh5Ba1Z4UfCZYmTzP7g1mP5uUC32KgWcMtBi2QV6xGjHpqs5ZeEnpAwaWVNgF7b7xtumQGoL9posmQMfRvFupJBXkZyWGdcDizfMUAiEgrG7cA98yf6vcqJzZT1EPg8A69e

Integrated addresses to become v2 addresses and replace/deprecate v1, which isn't in use yet.

The objective is to get the payment ID scheme to a point where it is ready for years of use with no further changes. To maintain backward compatibility with the current payment ID scheme during the transition  stealth payment IDs will only be generated by default through the use of integrated addresses. Thus, when recipients are ready to accept the new stealth version, they would use integrated addresses.

This new 64 bit ID will be given a new tx_extra nonce tag: 0x01 (current payment ID is 0x00).

A note on collisions

With 64 bit IDs, there is a non-negligible chance of a collision if they are randomly generated. It is up to recipients generating them to sanity check for uniqueness.

  1 million IDs at 64-bit (simplified):
  1,000,000^2 / (2^64 * 2) = ~1/36,893,488
  so there is a 50% chance a collision happens around 5.06 billion IDs generated.

Current integrated address

At present the integrated address looks like:

netbyte (0x13 [standard Monero is 0x12])
+ 32 byte public spend key
+ 32 byte public view key
+ 32 byte payment ID (8 byte proposed for v2)
+ 4 byte checksum of all previous data

JavaScript implementation

Note that JavaScript is only to ease expressing the method.
Import cn_util.js from mymonero.com for methods.

For the stealth key, a derivation of the shared secret used for public key generation is required. The varint encoding used by output indices gives us 128 1-byte options to use as part of our key: 0x80 - 0xFF

Choosing entirely arbitrarily: charcode(I) + charcode(D) = 0x49 + 0x44 = 0x8d

Therefore

encryption key = H(sharedSecret + 0x8d)

Note that "+" means "append" above.

//---------------------------------------------------------
//proposal 1.5 (older ideas discarded as subpar and/or unscalable)
//xor payment ID with one-time key
var receiverKeys = create_address(rand_32()); //for example only
var payId = "0123456789abcdef"; //64-bit example
var txkey = random_keypair();
var der = generate_key_derivation(receiverKeys.view.pub, txkey.sec);
var stealthKey = cn_fast_hash(der + "8d").slice(0,16);
var encPayId = hexXor(stealthKey, PayId); //JS can only xor numbers, made up function to xor hex strings

//receiver would:
var der = generate_key_derivation(txkey.pub, receiverKeys.view.sec); //txkey.pub from tx_extra
var stealthKey = cn_fast_hash(der + "8d").slice(0,16);
var payId = hexXor(stealthKey, encPayId); //encPayId from tx_extra
//*compare payID with known set*
//---------------------------------------------------------


When sending monero to an address. Does my wallet keep track of the history of where it was sent to?

The wallet cache stores the metadata of outgoing transactions (destination address, secret transaction key, transaction note), which is not stored in the blockchain (see also What data do the wallet files contain? for a list of what else is in the wallet cache file).

To have access to these informations, an attacker would need to get the wallet cache file and its password.

If the attacker only gets the private spend key or mnemonic seed, he will have access to the funds in the wallet, but he won't be able to recover the addresses where the wallet sent transactions to in the past.


Why does monero have higher transaction fees than bitcoin?

This information is based on the last 100 transactions. That particular screenshot is an anomaly and unrepresentative of the norm.

If you refresh right now, for example, you'll see the median Bitcoin transaction fee is $4.76 vs $0.86 for Monero.

Note that there is work being done on reducing the Monero "range proof" size, which will result in smaller transaction sizes (measured in bytes) that will significantly reduce Monero transaction fees in the future.


How many characters can be missing or mis-typed in a Monero address to still be valid?

The odds of getting a 4-byte cryptographic checksum to match is roughly 1 in 4 billion, 2^32 = (2^8)^4. A Monero address provides a 4 byte cryptograph checksum for detecting errors (parity). No Hamming error correction services are provided. Monero addresses without payment addresses and multisig abilities are always 95 characters in length.

The last 5-bytes of the hex encoded representation of a Monero address are base58-encoded.  The lower 4-bytes of hex characters represent the checksum  while the last byte of public view key bleeds into the top portion of the ninth base58-encoded segment that contains the checksum.

For details on how a Monero address is constructed see the working example at the bottom of Constructing a Stealth Monero Address?. For this working example, the 9th base58-encoding of ffADD56816 (hex) is Vr5GCd (base58).  The ff comes from the lower portion of the public view key 3c450f27cd6849d9130addb2c566d910c5ef9bf4cecaed547004496fda52a4ff, and the ADD56816 comes from top four bytes of a Keccak-256 bit hash the Monero Cryptonote prefix in hex (12) + public spend key in hex + public view key in hex.


Longest block time and standard deviation

Yes an an exponential distribution can be used but it will require some assumptions:

No propagation delays of block discoveries
Constant difficulty
Accurate time stamps

With those assumptions and an exponential distribution the standard deviation equal to the expected block time (expectancy value) which is currently 120 seconds (2 minute blocks).

Assumptions #1 and #2 above will never be completely true. Monero Research Labs is now researching Difficulty Adjustment Algorithms in Cryptocurrency Protocols and is considering such factors as dishonestly reporting time stamps.

I am not sure about the longest time between blocks, but here is my best guess which occurred about 28 and a half minutes after this block. This was the time period just following the hard fork that moved Monero from 1 minute to 2 minute blocks.


Is there some way to prove how long my Monero have been in my wallet?

By using simplewallet, and running show_transfers command, you will get a list of all transactions, with their corresponding block height and transaction IDs. Block height is like a timestamp, and by using a block explorer, we can easily find when was that block found (example). You could also fetch the details yourself by running bitmonerod and using the command print_block <n>, which would give you details of the block with block height n. This way, you don't have to trust a centralized service. The resulting timestamp will be printed as epoch Unix time, which can be converted to human-readable DateTime.

However, the above doesn't really prove it to anyone except yourself because you if you just c&p the simplewallet log to some auditor as "proof", there's nothing preventing you from fabricating the result.

To really prove when you received certain funds, you'd have to give up your view key to the auditor. He could then create a watch-only wallet by using simplewallet and by using the show_transfers command, see only the incoming transactions. However, this doesn't tell him if you spent those funds in the meantime.
To prove that you still have the funds, or to show when you've spent them, you'd then need to export the key images and hand them over to the auditor who would then import them into his watch-only wallet created with your viewkey. This was described here, but the function to import/export key images has not yet made it to the official release. It could be made available by compiling latest repo from source, though.


What significance does the wallet public spendkey and public viewkey have in a transaction?

You have a public and private spend key, and a public and private view key.

The public spend and view keys are used to create an output that only you can see that exists, and that only you can spend.

You use your private view key and public spend key to detect the existence of that output.

You use your private view key and private spend key to spend the output.

In algebra, your public view and spend keys are A and B.

Your private view and spend keys are a and b.

The output created for you is P = Hs(rA)G+B, where r is a random value known only to the sender.

You detect it by calculating P' = Hs(aR)G+B, and checking if P'==P. (Where R is a value published with the transaction, and is calculated as rG. Note that just as R=rG, A=aG and B=bG. Hs() is a hashing function that returns a type of number called a scalar).

The reason that P'==P is because rA==arG==aR, and this is called an Elliptic Curve Diffie Hellman Exchange.

The output P is actually a public key, for which you need the corresponding output private key to spend.

The corresponding output private key is x = Hs(aR) + b, according to the laws of Elliptic Curve Cryptography algebra.

Note: P is also known as a stealth address, because it is a one-time value written into the blockchain instead of your wallet address being written into the blockchain (as it would be in Bitcoin). An observer cannot determine that P is linked to your public view or spend keys, because this can only be determined if your private view key a is known.


What should I check if Kovri can't connect to peers?

Your best bet is to open an issue on Kovri's GitHub repository. Stack Exchange isn't the best location to do back-and-forth troubleshooting.

https://github.com/monero-project/kovri/issues


How to manage a large number of low-powered miners?

What I'd like to do is have all these devices mine to a single address, without joining a pool. Is this possible?

You can use the start_mining <addr> monerod command for each miner and direct all mined XMR to a single address under your control.


Assuming you are trying to send a new transaction using cold signing (from the "clicked on "sign transaction"" comment, because you omit all the details of what you're doing), this is likely what happened:

you create an unsigned transaction (at this point, the wallet marks your outputs as spent, since it's sending them, but the wallet still owns those outputs until the transaction ends up on the blockchain)
you sign the transaction
you don't send it to the blockchain, or it gets rejected

If this is indeed the case, the first wallet still has the coins, it's just marked them as spent. They should show up again if you do two things:
- flush_txpool TXID   (in monerod, and replace TXID with the actual transaction ID for that transaction)
- refresh    (in monero-wallet-cli, might need to do it twice)

Since you're using the GUI, you'll have to exit the GUI to do these things. I think it may be possible to do them from within the GUI, but I'm not sure how exactly.


What makes monero different from other anonymous coins?

If by others anonymous cryptocurrencies you mean Zcash and Dash,  you can check out this article: Monero vs Dash vs Zcash


Before scrapping those wallets, change one (or, maybe better, both) of their names to something different.  Once they have different names, try to open again.


What would be reasons to further increase block time?

If orphan levels increased or were above some tolerable threshold, an increase in block time would help alleviate the situation. This answer to a question about unlocked balances explains Monero's greater sensitivity to reorganizations.


Yes, you can define individual difficulty for miners connected to xmrig-proxy. However this only tells the miners which results to submit to the proxy. Another difficulty is set between the proxy and pool and this difficulty says which results (shares) will be submitted by the proxy to the pool.

So if your pool diff will be 100.000 and diff for miners (either by proxy config or individually as part of username) will be 10.000, proxy will receive all shares with diff >10.000, but will forward to the pool only those having diff >100.000.

At the end it doesn't matter if you submit diff X share every 10 seconds or diff X*2 share every 20 seconds.


Watch wallet can not show outgoing transfers unless some steps are made (import key images from cold wallet).

If you restore with spend and view key, and you see outgoing TX which you did not make, I'm sorry but then someone somehow found your secret spend key or mnemonic and took your funds.


Error with `import_outputs` : `"Failed to decrypt outputs: Failed to authenticate ciphertext"`

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.


Please wait 20 minutes for your entire balance to become spendable

Any transaction (XMR) received has to be 10 blocks old before becoming spendable.

New blocks are mined roughly every 2 minutes, so roughly 20 minutes.

If the monerod/node you are connected to is not fully synced, your balance will not become spendable until the node is synced past your transactions block + 10.

Same problem, if your wallet is having problems syncing from whatever node you are connected to.


Ledger Nano S Transaction Error: unexpected error: Wrong Device Status : SW=6911 (EXPECT=9000, MASK=ffff)

so I've been using the monero-wallet-cli.exe from the Lithium Luna v0.12.3.0

You cannot mix and match the GUI and daemon versions. The latest GUI (with daemon) can be downloaded from here.


How can i get current fee from monero-wallet-rpc

The fee depends (in part) on the exact size of your transaction, and your transaction size depends (in part) on how many outputs you are spending. Therefore to determine the fee, you first need to construct the transaction to determine its size. You can do this using the transfer method with do_not_relay set to true.

If you are happy with the fee, you can then submit the transaction to the network using the relay_tx method.


How to create a Payment ID with the Monero RPC Wallet?

Nevermind i found the answer, it's 'make_integrated_address'.
See: https://ww.getmonero.org/resources/developer-guides/wallet-rpc.html#make_integrated_address


Can I obtain Monero testnet coins without mining?

If you pop into /r/monero on reddit, or on Slack/IRC #monero, you will find people who would be happy to send you testnet coins.

Alternatively, it is rather satisfying to mine your own.  The difficulty on the testnet is quite low, so odds are high that you will see returns in the first day or two.  I highly recommend it.


Your tests are not the same.

If you look at the source for hashToPointCN, you will see:

def hashToPointCN(hexVal):
    u= hexToInt(cn_fast_hash(hexVal)) % q
    ...

It hashes the input.

So in your Python test, you are outputting the result of cn_fast_hash, which is being used as input to hashToPointCN, which is hashing again and then returning a result point.

Your C test is correct in that you are only hashing the input once.

Thus, if you amended your Python to:

HR = MiniNero.hashToPointCN(public_join)
print(HR)

You'd get the same result as the C version:

4543c4d7a442df56119ea1fa97eee1d0b8a2e485b48b3741f498bb63d2d593b3

As an FYI, you can see exactly how a key image is generated in the source code of Monero here: src/crypto/crypto.cpp#L481-L498


What is the smallest unit of Monero called?

The common usage is SI prefixes, with the first "mo" removed for ease of use (I forget the name of this speech concept).
This was proposed by David Latapie, an early Monero core team member, though the blog post explaining those is now 404.

Here's an overview of all common Monero units taken from the official MoneroPedia:

So 1 monero is 1000 millinero, 1e6 micronero, 1e9 nanonero, 1e12 piconero.

If you're rich, you'd also have kilonero, meganero..


Why did the Monero GUI fail to generate a new wallet with the Ledger?

It seems a problem related to Windows USB controller, you can try using the Hardware and Devices troubleshooter to fix the problem. It checks for common issues and makes sure that any new device or hardware attached to your computer was installed correctly.

Also, if you are using your Ledger connected to a USB 3.0 port, you can try to use it in USB 2.0 port, or vice-versa.


Is the median blocksize measured over the last 100 or 720 blocks?

It is 100 blocks (CRYPYONOTE_REWARD_BLOCKS_WINDOW in src/cryptonote_config.h). I think I've confused this with the difficulty window before, which is 720. I don't remember it changing.


GUI adress and Integrated adress are 79 Characters

A regular Monero address is 95 characters long.
An integrated address is 106 characters long.

As far as I know there is no Monero address format having 79 characters.

When withdrawing from an exchange to your own wallet, you don't even need to use a payment ID. But if you want to use one, or if your exchange requires one, you can use any hexadecimal string you want (either 16 hexadecimal characters for a short payment ID, or 64 hexadecimal characters for a long payment id).


Help me with digest authentication using java

I took a look over here: https://en.wikipedia.org/wiki/Digest_access_authentication and from how I understand it you must do the following

Get the nonce and realm from that first message:

  algorithm=MD5,realm="monero-wallet-rpc",nonce="hHQVNuEdyZszjmEPwS/jkQ=="

Then use the following flow:

HA1=MD5(MD5(username:realm:password):nonce:cnonce) //cnonce is a client nonce
HA2=MD5(method:digestURI)
response=MD5(HA1:nonce:HA2)

Your response would look something like:

import java.security.*;

..

java.security.SecureRandom random = java.security.SecureRandom.getInstance("SHA1PRNG");
random.setSeed(System.currentTimeMillis());
byte[] nonceBytes = new byte[16];
random.nextBytes(nonceBytes);

String clientNonce = new String(org.apache.commons.codec.binary.Base64.encodeBase64(nonceBytes), "UTF-8");
String serverNonce = "hHQVNuEdyZszjmEPwS/jkQ==";

String HA1String = "aladdin:monero-wallet-rpc:open sesame";
String HA2String = "GET:<your-uri>";
byte[] ha1Bytes = HA1String.getBytes("UTF-8");
byte[] ha2Bytes = HA2String.getBytes("UTF-8");

MessageDigest md = MessageDigest.getInstance("MD5");
String HA1_1 = new String(md.digest(ha1Bytes)) + ":" + serverNonce + ":" + clientNonce;
byte[] ha1_1 = HA1_1.getBytes("UTF-8");

String HA1 = new String(md.digest(ha1_1);
String HA2 = new String(md.digest(ha2Bytes));

String HA1nonceHA2 = HA1+ "hHQVNuEdyZszjmEPwS/jkQ==" + HA2;
byte[] ha1nonceha2bytes = HA1nonceHA2.getBytes("UTF-8");

String responseVal = new String(md.digest(ha1nonceha2bytes));

String response = "Digest "+
                 "username=\"aladdin\",\r\n"+
                 "realm=\"monero-wallet-rpc\",\r\n"+
                 "nonce=\"" + serverNonce + "\",\r\n"+
                 "uri=\"" + <your-uri> + "\",\r\n"+
                 "qop=auth,\r\n"+
                 "nc=00000001,\r\n"+ //Increment this each time.
                 "cnonce=\"" + clientNonce + "\",\r\n"+
                 "response=\"" + responseVal + "\""

connection.addRequestProperty("Authorization", response);

That should at least get you close. Remember null checks etc.


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

This post from a while back on Reddit documents what a payment ID is and how it is used quite nicely. Note that an integrated address includes a payment ID and is a preferable way to send and receive Monero.

Payment IDs are needed when sending to an exchange, such as Poloniex or to a merchant. It allows Poloniex to confirm the transaction is yours, because Poloniex probably gets a lot of incoming transactions on the same address they won't be able to differentiate otherwise without a payment ID.
Hopefully Poloniex will implement "integrated addresses" in the future, which incorporate the payment ID into the receiving address. This improves user convenience and also mitigates the risk that a user forgets to include payment ID when sending his Monero to an exchange.
...
How/why to generate a payment ID
Poloniex will provide you with a payment ID, you can include this when sending a transaction from [monero-wallet-cli or monero-wallet-gui]. Conversely, one can generate a payment ID in [monero-wallet-cli or monero-wallet-gui] and include this in the transaction. MyMonero has such an option too.
[When should you not use a payment ID?]
You don't need to include a payment ID when you are sending to another person. For example, if Alice has to send Bob 1000 XMR it is kind of unnecessary to include a payment ID.
The main reason we need payment IDs in XMR is because it isn't convenient to make a new wallet for every new user. By contrast, in Bitcoin one can easily generate another address in a wallet. Therefore, you don't need something like paymentIDs in Bitcoin because the exchange can easily generate a new address for every new user.

For more information, see the page on payment ID's on the official Monero website.


Lacking a direct answer, the fastest 2 step option is to buy bitcoin and then use https://shapeshift.io to trade bitcoin for monero.

http://poloniex.com might give you a better price than shapeshift and you can buy much more as shapeshift's limits are small. You still have to have bitcoin first and send it to poloniex.


What is the block height from which RingCT was implemented?

Ring CT was implemented in block #1220516 in January 2017. After September 2017, this feature became mandatory for all transactions on the network.

https://ww.getmonero.org/resources/moneropedia/ringCT.html

It's worth noting that RingCT is an improvement which added the Confidential Transactions part to the transaction format. Ring signatures existed before RingCT was implemented.


Forwarding cold signed transactions from a non matching hot wallet

Only the matching hot wallet may do submit_transfer.

Actually, that's not quite true. You could submit a transaction from another one, but this will wreck that hot wallet's idea of what's spent and what's not spent (and might error out, but only after the transaction's been relayed).

This would not be hard to change, however, and seems a useful change. Feel free to open a bug asking for this on https://github.com/monero-project/monero/issues.


Is the Monero genesis block reward spendable?

It is spendable. There are a lot of clones which use the genesis block reward as premined coins


I think you mean connecting to a remote node. Syncing monero sometimes can be slow for some users so just keep it running and it should synchronize and may take days.

Edit: To give you an idea, today, I just tried to synchronized starting at 98% and took me 3 hours. I'm using an SSD which is faster.

However, you can connect  to a remote node if you are really having problems. To connect to a remote node follow this guide How can I use Monero without syncing the blockchain?.


What is the difference between simplewallet, wallet and wallet2?

simplewallet.[cpp|h] is the source code for the command-line wallet monero-wallet-cli.

wallet2.[cpp|h] is the source code for the core wallet functionality. simplewallet therefore makes heavy use of this.

  There seems to be 3 variations of wallets in the Monero code.

No, there are only two wallets in the source tree. There is the command-line wallet, monero-wallet-cli, as detailed above and the wallet RPC server, monero-wallet-rpc. Both of these are simply wrappers around the core wallet functionality as implemented in wallet2.

There is also an optional wallet API library that can be built (source in the wallet/api directory) which is designed to allow for a simpler interface to the core wallet code), and there is also some old "light" wallet library code, but consensus seems to be that this is unused by anything and is therefore redundant now.


Error using monero-wallet-rpc: No wallet file

I was running the command with the wrong parameters. I should have used --wallet-file instead of --wallet-dir when running monero-wallet-rpc.

My corrected command:

./monero-wallet-rpc --rpc-bind-port 28083 --wallet-file monerowallet \
    --password mycoolpassword --disable-rpc-login


What Linux flavour to use for AMD GPU mining?

Arch Linux has an AUR that you could use (link) that allows you to install the proprietary OpenCL component you need for mining without the need for the closed-source AMDGPU PRO binary blob.


Is there a way to remotely access simplewallet securely?

In Monero 'Wolfram Warptangent' (v0.10.0.0-release), use this flag

--user-agent arg

It is used to Restrict RPC to clients using this user agent. Make sure to set the user agent to something that cannot be guessed. i.e. a random UUID.

That way only RPC clients that set the User-Agent in the HTTP header can access the wallet.

However, this requires that all RPC clients and RPC server share the same secret. If at least one of them leaks said secret, all the monero in your wallet will be gone. Also, all the User-Agent values sent to your servers will be visible.

A better option is to use something like this or this, to keep your RPC behind a proxy which needs authentication. I will write a tutorial on how to do this when I find some time.


How does the daemon determine the recipient address of the mining reward?

When solo mining, the block reward is given to the address which was set in the coinbase transaction. Technically, I think there is no reason why the coinbase transaction could not contain several outputs to different addresses, but there is no support for creating those at this time.

You supply the address as an argument to the start_mining command, eg:

start_mining 4xxxxxxxxxxxxxx 2

will start mining on two threads to the given address.


Blockchain database file size variance by Operating System

You are probably looking at a database file with the blockchain in it. The main variation cause is that the database library Monero uses, LMDB, preallocates some space for writing. Every so often, when that space falls too low, LMDB will resize the file to get more breathing space.

Some OSes do not support sparse files - that is, files with "holes without data" in them. So these will actually have allocated space with data there, instead of just nothing, which makes the file larger than it'd be on an OS which supports sparse files.

It also depends on the version of Monero that is running. Recent versions have made optimizations which shrink the size of the database without impacting performance.

Last, it should be noted that this database is a few times larger than the actual blockchain data. This is because a database is geared towards reading the data back in an efficient matter, so data is stored denormalized (ie, with some duplicated parts, etc).


Pi 3 is still not a decent system, even with a 64bit OS. Their chip lacks AES instructions. Will be slow at verifying blocks.


What cryptographic assumptions is Monero based on?

Firstly, Monero relies on the safety of Ed25519 (as opposed to secp256k1 for Bitcoin) and EdDSA. Note that if EdDSA/Ed25519 breaks, a lot more than Monero will be impacted, including SSH, Tor, I2P, OpenBSD, GnuPG and many more

From the Surae Noether CryptoNote white paper review

Implementation and use key images to prevent double spending

  The CN protocol implements a piece of cryptography unseen in cryptocurrencies before, in particular, the idea of using key images to protect against double spending. This is boldly treading on dangerous ground; no matter how deeply I, or any mathematician scrutinizes an algorithm in any white paper, it’s possible some 16 year old in South Africa will figure out a way to crack the encryption.

New PoW (CryptoNight)

  Implementing an entirely new Proof-of-Work algorithm could be just as vulnerable to exploitation as implementing any new piece of software. To be frank, without any sort of explicit, clear explanation of how it’s been done, it can’t necessarily be trusted. With Bitcoin,the task was clear: find the nonce so that the SHA hash is small. With this algorithm? I have no idea

Elliptic curve contants

  My single biggest question after reading the entire paper
  is the “how did they choose their elliptic curve constants?” The protocol appears sound; who chose the constants? Will there be a plan for choosing new constants in the future if needed? How can I choose other constants if I decide to fork it? Did the NSA come up with CryptoNote and choose these constants so any CryptoNote network has 10% the entropy of any other coin? Who knows. It’s probably not a big deal, and every coin has this as a critical point. Indeed, it’s a centralization point. If we all go happily forking the CryptoNote code left and right, we are trusting those developers to have made good decisions on the constants.

  However, having said all that, CryptoNote is absolutely spectacular. If you have a problem with the constants, and if you can figure out how to generate new ones, I say go for it. The protocol looks secure and tight.


Mac OSX Monero GUI link on Getmonero seems to not work

Yes, you can download it from the official Monero Github account


The difficulty number isn't helpful to your calculation.  Let's try this way:
The total network hash rate is 1.78GH according to https://monerohash.com/# on Jan 14th 2021.  Let's say your Ryzen is getting 21,000 hashes per second at 200 watts.  The network runs on a much more diverse set of CPUs than this fancy chip, but just to arrive at a number... that's 1,780,000,000 hashes/sec / 21,000 = 84,761 Ryzens.  At 200 watts each, that's 16,952,200 watts.  At 0.10 USD per kWh, the network burns $1,695.22 per hour just to secure itself.  With blocks at the regular 2 minute frequency, 30 blocks per hour, that's 1,695.22/30 = $56.50 per block in electricity.
At our current transaction rate of about 900 transactions per hour, that's a nice round 30 transactions per block, so about $56.50/30 or $1.88 in electricity to do a single transaction.  Of course, blocks can get much bigger, and we could scale up to many more transactions for the same amount of energy.  It's probably best to just stick with the high level total hash rate divided by hashes per second of a reasonably efficient chip.
This estimate is probably low because the network is surely not using Ryzen 5950x's by and large.


How can I verify the SHA256 hash of 0.10.3 “Wolfram Warptangent” on macOS?

On macOS:

Downloading the tar.bz file. I will assume it is located in the normal "Downloads" directory, and it's name is monero-mac-x64-v0.10.3.1.tar.bz2. Other names/locations are fine but you'll have to adjust the process accordingly.
Open Terminal. Easiest way is ⌘+spacebar and type "Terminal", then hit enter.
Change to the Downloads directory. Type cd ~/Downloads and hit enter.
Get the Sha-256 Checksum. Type shasum -a 256 monero-mac-x64-v0.10.3.1.tar.bz2 and hit enter.
Compare it with the checksum on the Monero page.

On Linux (tested on Ubuntu 16.04) the command is sha256sum rather than shasum -a 256.

On Windows, the command is pinch nose, scrunch eyes, and hope everything is good as you unzip the file. Just kidding. I don't know the Windows command though.


I have the impression blockchain reorgs are more prevalent on testnet?

In theory, yes, fewer nodes should make things easier to agree upon, but in practice, that's not always the case. A few things might contribute to a big reorg on testnet that wouldn't usually happen on mainnet:

The testnet's hashrate is massively lower than the mainnet. As in, I could attack the network with my personal computers alone and have way more than 51% most of the time.
As a result of 1., new person joining the network might bring enough hashrate to accidentally "attack" the chain, meaning they might start mining on a different top block than the rest of the chain and cause confusion on the network for a while.
Alternatively, someone might intentionally attack the testnet just to try out things or test for robustness.
Most likely, nodes on testnet are not optimized for connectivity, etc. I doubt there are many nodes running on cloud services like AWS for instance. As a result, the latency problem described in the linked post is likely exacerbated, and so the few miners on the testnet are probably more likely to end up on different chains.
Building on 5, lets say there are basically 2-3 people mining on testnet with roughly the same hashrate. If they end up on different chains, it's decently likely that they will occasionally diverge on what they think is the longest chain and continue to disagree for some time, as both chains might keep up with each other within the latency lag window described. More miners would actually help to mitigate that issue, as blocks would be propagated from more locations around the world, and thus have more variance in latency between miners.

There are probably some other reasons as well, but these are the ones that come to mind right away.


Is the payment ID the equivalent of the op_return in bitcoin?

Arbitrary data can be stored in the extra field in a Monero transaction. The payment ID uses the extra field, and is often used as a container for arbitrary data, because it is easy to use. However, it is (1) limited in size and (2) sometimes required by the recipient. For more flexible use, having a custom field in extra seems best. However, this will require the sender and recipient (or sender and the target population at large) to agree on the semantics of that extra data in the first place, so that it can be parsed and understood. The amount of data which can be placed in the extra field is limited by the maximum block size.


Is there a benchmark results for mining with monero using different cpu and gpu's?

maybe this will help you
https://www.servethehome.com/monero-mining-benchmarks-select-dual-intel-xeon-e5-systems/

And I can tell you on my hardware
2 x Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz I got ~ 430 H/s


What all information we can gather from a Monero wallet address?

No.
No. Naturally, you can only know about what you sent to that address. You can't know whether that address ever received anything else from the side. When the target spends what you sent to them, you won't be able to tell if it was your target who did the spending or someone else who just happened to include output of your TX as his "decoy" input (look up how ring signatures work) - you can only make a guess, with no way of telling if it's right. However, if the target combined what you sent to it together with something which came from someone else in the same TX, you could make a following guess: maybe your target spent what you sent it and if so maybe he combined it with something he received from elsewhere.
No. Sending back to the same wallet or to another wallet looks exactly the same and can't be linked to any address (look up how stealth addresses work)

Here's a simple explanation of the mechanics: Simple explanation of Monero mechanics - how does Monero work?


When using Globee as an online merchant accepting Monero into fiat, is it private and safe? over Tor?

Whether something is "safe" or not is subjective. If you use Globee to handle transactions for you, of course you will be sharing information with them. See their privacy policy for the types of information and how it is handled.
Globee is a payments provider. It is designed to make it easier for an online merchant to accept Monero and handle converting to other currencies etc. If you use a third party to handle your payment processing, of course you lose some privacy, as you have to essentially partner with them. If you need your store to have complete anonymity, you will need to develop your own payment processing.
It is more private not to use any third parties. See above point.
Monero doesn't have Tor "built-in" like Whonix or Tails; Monero is not an operating system. It can run fine on computers that do restrict all traffic through Tor (like Tails or your own computed configured as such). It also has configuration options to allow sending transactions over tor/i2p and sync blocks over clearnet. All of this is covered in the README and ANONYMITY_NETWORKS documents.
The Monero GUI is a desktop wallet. The Monero RPC interfaces are for programmatically working with a Monero wallet or daemon. For accepting payments on a website, you more than likely want to make this programatic, thus would code your website to interact with the monero-wallet-rpc. And this is where Globee eases things - it does the heavy lifting - you don't need to run a node or the wallet RPC. You still need some web development skills, but significantly less than doing all your own payments processing.


knacc is right - there's no way no just multiply to ec-points. I solved my problem by making key exchange:

b = b0b1B2


Is it better to mine Monero on solo mining or joining a mining pool?

It's for sure the best thing to join a pool - unless you have a really high hash-power. If you own a data center you can go on and solo mine but in nearly any other case, it's more profitable to use a mining pool.

Apart from profitability, for the Monero network it doesn't make a big difference if you solo-mine or not.

In general, you of course need "good" hardware to get a high hash-rate. A really fast CPU or GPU is what you need. Everything else isn't significantly important. GPU mining is more profitable than CPU mining.


Is the purpose of the Kovri C++ project solely to benefit Monero?

While developed under the monero project umbrella, Kovri will be usable for general I2P usage, not only for monero. Even when used for monero, it will also be usable for other uses, if the user chooses so. Indeed, the advantage of being usable for general I2P traffic means that an observer seeing you using Kovri (which I assume may be possible via fingerprinting) will not know you are using monero, rather than something else (at least, from looking at the I2P traffic).

I believe the intent of building a separate I2P router was to avoid depending on Java and its libraries, which would have constrained the platforms which could run monero via I2P.


What is the loki wallet cli command to join a staking pool service node?

it is actually described here: https://docs.loki.network/ServiceNodes/SNFullGuide/#622-pool-contributor

stake <Service Node Pubkey> <contribution amount>


When ugrading from 0.9.x to 0.10.x it's highly recommended to delete the database and re-sync from scratch. You almost got it, but the default location of the database is in the c:\programdata\bitmonero directory not c:\bitmonero. Instructions below.

Make sure that monerod isn't running. Go to %programdata% and delete the "bitmonero" folder in that directory. Then try re-launching either monerod and use monero-wallet-cli if you prefer the CLI or launch monero-wallet-gui if you are a GUI user.

It'll take approximately an hour on a fast computer w/ SSD to download the entire blockchain, longer for a regular HDD, slow network, slower computer.


If a business or REIT wanted to purchase Real Estate and keep the owners anonymous could it use Monero to do so?

Well, the answer is more an answer about law rather than Monero.

Part of any real estate transaction is the recording of the transaction in public records.  The parties to the transaction must be known.  The seller must be known, since they must be proven to be the lawful owner of the land.  The buyer must be known, since they must be able to be proven as the lawful owner in the future.  More than likely, the government will impose real estate taxes, so the government needs to know who to tax.

In short, this particular use case doesn't seem like a good one for Monero (generally), since exchanging real estate isn't really a peer-to-peer transaction.

As far as setting up an address, any wallet software will create an address for you.  Be sure to write down the 25-word seed and store it in a safe place, since the seed can be used to restore your wallet and recover your funds in case the wallet file is corrupted/lost/deleted/etc.


Do ring signatures sometimes leak "X definitely did not pay Y" info?

The dancing analogy is that you'll see "me" dancing with many people, but most of what you see isn't really me, so you can't prove that I danced with any one of them.

The "dancing" analogy is poor.
Monero has:

Sender privacy: Ring signatures
Receiver privacy: Stealth addresses
Amount privacy: Confidential Transactions

Observers don't know who the sender is (or more specifically which outputs are being spent), due to the ring signatures.
Observers don't know who the receiver is (or more specifically who owns the destination outputs), because they are uniquely created for the destination, with no way of attributing them to specific addresses.
Observers don't know how much was transacted because the amount is encrypted with a shared secret (only the sender or receiver can decrypt).

can an observer prove that I didn't pay (or dance with) some recipient X?

No they cannot. Only you (as the sender), can prove whether or not you actually sent funds.

Does that not then prove that I did not pay X?

No, it does not. Only you (as the sender), can prove whether or not you actually sent funds.


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

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

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

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

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

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

Go to the directory / folder monero-wallet-gui (GUI v0.12.2.0) is located (note that monero-wallet-cli will be in the same directory / folder as monero-wallet-gui).
Open a new terminal
Now type:

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

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

./monero-wallet-cli --generate-from-device MoneroWallet --restore-height 1585000 --subaddress-lookahead 3:200

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

A few final notes:

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

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

[2] Open monero-wallet-gui

[3] Enter the password to open the wallet.

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


The poolstate.bin file used to contain the set of transactions which were not yet mined, known as the txpool. Monero 0.11.0.0 moved those transactions into the database, stored in ~/.bitmonero/lmdb, so the poolstate.bin file is now obsolete, and will thus not be created. A lack of poolstate.bin does not indicate anything wrong with monerod.

An old Monero install may still have this file, but it will only contain old transactions from before the change, and it may be safely deleted.


Cheapest motherboard and RAM for AMD Ryzen 3-gen CPU?

There are a multitude of places to acquire a motherboard. Any AM4 motherboard is "compatible" so search the internet for AM4 socket motherboards and purchase one within your budget.


What would be good metrics to measure impact on miners when tweaking hardware/system?

The hash rate is of course the main metric to consider, since it determines how fast the miner can go through nonces in order to find a hash that meets the difficulty. Whether the difficulty is static or not is not really important, since it only determines when a found hash will be submitted to the pool. This does add some overhead if you're submitting too often, of course, but I think it is minimal.

Another thing to consider is energy expenditure. If you run on a laptop, a tool like powertop can help you see power usage. If you're on a machine without a battery that can report such things, I'm not sure there's a good tool for this, though.

A less interesting metric might be network latency between the miner and the pool. However, this is likely to have only minimal impact.

If you want to go lower level, the tool perf can show you what a process is busy doing, so you know what parts of the code is the current bottleneck.

/proc/$PID/ has a number of interesting things you could check:
/proc/$PID/status gives you number of context switches. Other files may have other interesting statistics on a running program.

Last, Wolf's miner has a --benchmark option. It may or may not be in working order in your version, but IIRC the changes needed to revive it were minimal (it was a long time ago, I don't remember what they were off the top of my head).


What is transaction malleability, does Monero suffer this problem like Bitcoin?

Monero has a simple transaction format and doesn't suffer from transaction malleability in the same way as Bitcoin does.

See here and here for more details on malleability, and here for flexible transactions / SW.


How did it happen that there is a monerod process started by root on my laptop?

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.


How do I manually generate a base58 private key from my secret spendkey?

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


You cannot “fund a physical coin” with Monero, because Monero exists only as data on a distributed ledger. These so-called “physical coins” are just arbitrary objects on which seed-phrases can be stuck or engraved (and in this case apparently hidden behind a sticker).

A physical coin could function as a back-up of your seed phrase, but it has no real advantages over a seed-phrase written on any other object. A sticker might not even be waterproof, let alone fireproof. An engraved seed-phrase would be tougher, but brass has to be protected from corrosion, and it melts at 900–940°C. As a transferable bearer-bond, it's useless, because the bearer has no way of knowing whether or not a previous bearer wrote down the seed-phrase before handing over the coin.

If you really want to use one of these things to store your seed phrase, and you have nimble fingers, then perhaps you could engrave it. Or you could convert your seed-phrase into a tiny QR-code, print it on sticky paper and stick it to the coin. Your question specified “securely”, which would mean using a non-networked computer to generate the seed-phrase (& convert it to QR code) and a directly connected printer (a low-tech printer so your funds can't be compromised by printer malware). But why would you want to?


Monero Not connecting to Daemon after upgrading to v0.13.0.3 on Windows 10

A.  Yes, at first, you must let the database do its upgrades.  It actually could take an hour or two (hopefully nor more than that, but it depends).

B.  Make sure you're not only using a v0.13 daemon, but also a v0.13 wallet as well.  It sounds like you are, but just making sure.


How to put username and password to connect to remote node in the Monero v0.12.3?

You need to press the advanced arrow button (if I recall correctly) below the node address field to display those fields in the settings page.


What does CONOP mean and how does it relate to block sizes and scaling?

[C]ost [O]f [N]ode [OP]eration is (theoretically) a way to measure to the cost of running a full node.

If we peg a blockchain with a 1 MB blocksize as having a CONOP of 1, then doubling the blocksize to 2 MB, would double the CONOP to 2, thus reducing decentralization since increasing CONOP would result in less people running full nodes (higher the price of something, less demand).

Of course, things don't only go up. As the cost of memory, hard drive space, internet speeds, etc. improve, the CONOP can also move down. So if you double the block size, but the cost of internet and hard drive space reduces, you can theoretically get an even lower CONOP than the original.

Monero can't really do much to affect the hardware aspects of CONOP, but it's adaptive blocksize algorithm attempts to keep blocks from becoming overly large, thus keeping the space component of CONOP within some reasonable range.