What type of security audits has Monero received?

As well as the informal review of CryptoNote provided to the Monero team by SURAE NOETHER here, the source code is available on monero-project's github here.

These slides also review the protocol.
A possibly important note from those slides about the spec that isn't found anywhere else is given after slide 28, saying:

  apparently 2 bad random r in monero same user, make the attacker who has 2 view keys v also, able to compute a linear relation between their e
  keys used to spend...
  nc, 07/10/2016

Edit: I think I know the relation nicolas is referring to -- if we simplify the stealth formula to A + H(S_1)G, A + H(S_2)G, so the private keys are
a + H(S_1) and a + H(S_2), the linear relation between the spend keys is equal to the linear relation between the public keys. something not mentioned is that this also would mean the master spend key can be computed from any leaked spendkey. So don't share your spendkeys, even after use!

Also this paper deanonymising rings with small size: monerolink, and this one tooo: A Traceability Analysis of Monero’s Blockchain. Community response to the monerolink paper can be found here.


What is the current supply of wownero as of 2018-08-01

As of 2018-08-01, circulating supply is around 6 million out of a total of about 184 million, which will be emitted over the course of 50 years with no tail emission after depletion.

The block reward is about 170 WOW.


The multiple accounts feature is currently only available in monero-wallet-cli. The GUI does allow for a user to generate and subsequently use multiple subaddresses though (confined to the same account for now). Furthermore, the GUI contributors have stated intention of adding the multiple accounts feature. In fact, there's already a preliminary pull request open that would add support for this particular feature:

https://github.com/monero-project/monero-gui/pull/793

The pull request has to be optimized for the current user interface though before it will be merged / implemented. I personally think we'll see an implementation later this year.

As a side note, in case you are using monero-wallet-cli, you can create a new account by running the account new command. Subsequently, you can switch between accounts by utilizing the account switch <index #> command (note that the first account has an index of 0).


How GPU gets its mining work and nonce range?

I would study the most up-to-date code for xmr-stak: https://github.com/fireice-uk/xmr-stak

With that codebase, every thread, whether that be a CPU or GPU thread, mines with it's own blob/nonce. The first thread to calculate a valid hash (one who's hash value is below the target) causes the result to be submitted to the pool.


The "24-Core" supported by the motherboard you linked to is per-CPU, (e.g., E7-8890 v4 has 24 cores), so per quad-socket motherboard that would be 96 cores. However, these CPUs cost >$7K each yet you won't benefit much from the n-way architecture when mining. Compare that with less than half that price for a 20-Core, 2-way CPU. Those n-way motherboards are very expensive too, you pay a premium for the ability to to have 4 CPUs in the same machine. In addition, if at some point you'll want to use the rig with Windows after all, take into account that for anything above 2-way you must use a Windows Server, another premium-priced component. Bottom line, although you "waste" a core per rig for the miner, several 1 or 2-way rigs will likely yield better mining power per $$$ than a single 4- or 8- way rig.

The above discussion doesn't take into account the cost of hosting, if you intend to host the rigs in a data center then the form factor can have a significant impact on the overall cost.

As for GPU mining, for that you don't need much CPU power, you can use your current machine and just add a strong graphics card. Before you invest in multiple graphics cards make sure the mining software you intend to use can support your configuration.


What is Kovri and which other cryptocurrencies are implementing this feature?

Kovri is a C++ implementation of I2P which is Java based.
Kovri is no more than an I2P router. If another coin has wanted to use I2P they could have just bundled it into their node. To my knowledge, none actually has this level of security.
Kovri is open source, and could therefore be used or forked by anyone.

Read more on kovri website


Percentage of pre-tail Monero that has been mined compared to Bitcoin

At what approximate block height/date will the percentage of mined pre-tail Monero emission equal the same percentage percentage as Bitcoin?

This will happen at approximately February 11, 2017. At this date approximately 75.72% of the pre-tail Monero will be mined. In the spreadsheet it is marked as "Total Emission Crossover".

  Is there a spreadsheet or calculator that can easily help answer identify the percentage of pre-tail coin supply that will be mined as of a specific blockheight/date?

Yes there is.
For clarity, I have used this spreadsheet to answer your first question as well. Credits for the spreadsheet go to core-team member luigi1111.


Questions about calculating a transaction ID

Where are you getting your information about the structure of a transaction?

You forgot to include the hex 0001020005, which consists of the unlock time 00, the number of real inputs in the transaction 01, the input type of the first real input 02, the input amount 00 (0 to indicate it's an encrypted amount), and 05 indicating the number of key offsets that are listed.

You also forgot the hex 020002 which is the number of outputs 02, the amount of the first output 00, the type of the first output 02. Then you're missing the hex 0002 prior to the second output public key, which again indicates the output amount and type.

Then, you've not specified the size of the tx_extra field as 44. I'm sure there is much more.

Please cross check your work with the C source code, then you'll have a definitive list of things you need to include. At the very least, you should know something is wrong if you're missing out things which you can obviously observe are part of the raw hex of the transaction. The JSON summary of a transaction is not the same as the raw bytes of the transaction, as it excludes things such as the hex of the field lengths and input counts etc.


A private spend key is a positive integer lesser than l = 7237005577332262213973186563042994240857116359379907606001950938285454250989 (which is a 253-bit integer). The usual process to make a private spend key is to generate a random 256-bit integer and then reduce it modulo l.

The private spend keys are usually represented in one of the following ways:

32 bytes (little-endian order)
64 hexadecimal characters
25 words (mnemonic seed with 1 checksum word)

You can generate the 256-bit number with coin flips, but then you have to compute its remainder modulo l. Also, instead of using a simple coin flip to determine each bit (e.g. 0 for head, 1 for tail), it is better to use double flips to have better randomness in case the coin has a bias (e.g. 0 for head-tail, 1 for tail-head, ignore head-head and tail-tail).


Are there VPN providers accepting monero?

Cryptostorm accepts Monero directly. Some community feedback for the VPN can be found on Reddit.

Any Bitcoin accepting VPN can be paid with xmr.to or shapeshift


Whonix has added Monero to its APT repository (you can see that here) so the process is now pretty straightforward:

Download and add the Whonix signing key:

wget https://www.whonix.org/patrick.asc
sudo apt-key --keyring /etc/apt/trusted.gpg.d/whonix.gpg add ~/patrick.asc

Add Whonix's APT repository:

echo "deb https://deb.whonix.org buster main contrib non-free" | sudo tee /etc/apt/sources.list.d/whonix.list

Update your package lists:

sudo apt-get update

Install the Monero GUI:

sudo apt-get install monero-gui


How to run xmr-stak-nvidia on Ubuntu 17.10

You have to use CUDA 9.
Get it via: wget https://developer.nvidia.com/compute/cuda/9.0/Prod/local_installers/cuda_9.0.176_384.81_linux-run and then run sudo sh cuda_9.0.176_384.81_linux.run. Make sure it is correctly installed. You have to run the script multiple times!

The error seems like you haven't installed cuda 9. Run the install script and read the output. If it's not installed it's likely because you have cuda 8 installed. Therefore remove all cuda files/installs with sudo apt remove --purge nvidia* Then check /usr/local/cuda* and remove it if necessary. After this try to install cuda 9 with the steps from above.

The only way to compile and run it with Ubuntu 17.10 for me was using clang 3.8 and cuda 9.


The input comes from a non-RingCT transaction.  The outputs are RingCT outputs, and are therefore reflected as 0.


Are criticisms of Monero's blockchain bloat substantiated?

To some extent, it is, but it is also a common canard that  FUDsters like to cling to.

Monero transactions are indeed larger than Bitcoin's, and RingCT transactions will be even larger. However, most of the data (signatures) can be dropped by a node after verification (there are drawbacks, though: this node can't serve a blockchain to another node later).

Besides, Ethereum's blockchain is now a lot larger than Monero's, despite being younger. The fact that there isn't such an outcry about the Ethereum blockchain size tells you a little about how real this "bloat problem" is.


Same question, same answer

Yes. Remote nodes can track your IP address, in which case your privacy could be lessened.
If you feel, if someone might knowing your IP address, as a security issue, don't use remote nodes, or use VPN.
Yes. MyMonero is using a remote node. Anything not connecting to a local node, is using a remote node.
Note that communication between a local wallet and a remote node is encrypted, and nobody will know what you are doing.
When connecting your wallet to a local node, that traffic is, well, local.
Your local node will connect to remote nodes, and they will know that a node is running on that IP address.
Using TOR/VPN will mask that.
If you want to buy something, using Monero, why not just get XMR from an exchange?
As soon as those XMR leaves the exchange, they are gone.
The exchange will know that you got some XMR, but that's where the the trail ends.
If you go The Bitcoin route, your your trail will lead all the way to the No KYC exchange.
Using a remote XMR wallet, onion or not, will not give you more privacy, than using your local wallet.
Your transactions can not be tracked on a local wallet. They might be, on a remote web-wallet.
So, instead of all that bouncing around, you could just:
VPN=>KYC Exchange=>(clearnet) XMR => Your wallet=>(Onion) XMR=>XMR.to=>Bitcoin=>Vendor


Transactions Bitfinex  Wallet not going through since 24 hours

So for me, it was that I used a local CLI wallet and my monerod daemon was out of sync. After syncing the wallet (by starting ./monerod) I saw my balance. The best is probably to use some shared online daemons instead of a local one.


Should Monero start using MIPs(Monero Implementation Protocol) similar to Bitcoin(BIPs)?

Once a project starts to gain significant traction, like having its own research lab papers, it's ready to have a formal improvement process.

The BIP ("Bitcoin Improvement Process") was introduced by Amir Taaki back in the early days of Bitcoin and was inspired by the PIP ("Python Improvement Process"). Consequently having the MIP ("Monero Improvement Process") is a great step towards a structured approach to improving the protocol that each Monero client would implement.

Clearly the MRL (Monero Research Labs) papers are just one (very strong) initiator for a MIP. An MRL paper would provide deep technical analysis and requirements that the MIP would then implement. However other initiators could come about through community feedback.

In each case I'd see the MIP as being the second (more developer accessible) layer so that the community can provide further discussion and acceptance.


Windows vs Linux vs. OS X Monero user distribution

We don't log download stats from downloads.getmonero.org on purpose, but even if we did the stats would be skewed. Windows users, for instance, will almost unilaterally download a binary. A large portion of Linux users, on the other hand, will compile from source.

The only way to get this sort of breakdown would be to capture stats on all possible sources, and then we risk leaking user metadata that we'd rather not have.


Is mining monero to a subaddress supported?

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


removing some of the last blocks using

./monero-blockchain-import --pop-blocks 1000

fixed the problem


You need to run:

monero-wallet-cli --restore-deterministic-wallet

You will be asked for the seed you created earlier.

You will need a running daemon (monerod), which may be one of the public ones or your own, in order to download the blocks to see your transactions. When asked for a refresh height or date, make sure you put one that's when you created your wallet originally.


I agree with the answer of Jolly Mort with regard to answers 1, 3 and 5. I will add an answer for # 2 and 4 and provide some additional evidence to support the answers Jolly Mort provided.

More in the origination of Is it true?

  One last thing: without doing too much language analysis (which is mostly supposition and bullshit), it's easy to see common grammar and spelling fuck ups. My personal favorite is the "Is it true?" question. You can see it in the Bytecoin thread asking if it's Satoshi's second project, in the Monero thread asking if the Monero devs use a botnet to fake demand, and in the Dashcoin thread confirming the donation address (for a coin whose only claim is that they copy Bytecoin perfectly, what the fuck do they need donations for??).

Monero developers are mostly volunteers and have never provided firm deadlines. Since 2014 people frequently asked when an official GUI would arrive. Although a formal explanation is available, saying "soon" became a common response to questions about specific Monero release dates for the GUI or anything else. Those that want a more precise answer than soon, are encouraged to look at progress in Github
Monero speculation has never been encouraged by Monero developers. Instead research, development and buying only for an actual (non speculative) use case has been the standard recommendation to newcomers. Although the "Don't buy Monero phrase" or its equivalent has been used by many Monero community members, this is perhaps the most high profile example from core develer Riccardo Spagni.
On April 1st 2016 (known as April Fool's day in some countries) the operators of Bitcointalk temporarily replaced the name Monero with Darkflarb. Many people found this funny and still occosionally use the name
Nyancoin in 2014 was the first "Full Pegasus" cryptocurrency moment and led to a nearly complete loss of invested capital. AmericanPegasus did take out a loan to buy some Monero for about 40 cents in 2015, but subsequently sold some Monero to pay off some loans and diversify. Reportedly he now owns large quantities of Aeon and has recently expressed varying levels of interest in ETC, SIA, IOC and BCY. "Going Full Pegasus" may also reference the use of large market orders instead of patiently placing small limit orders over time to open new positions. In the case of Aeon (which far less liquidity than Monero) this led  to a large spike in price when he opened his position. Related to this practice is the phrase "Pegasus pump". American Pegasus is quite transparent and often discloses his position. In the case of Aeon his holding remains visible on the Bittrex exchange distribution chart where he has self identified as the largest holder.


If you already sent it, you should just wait it out. As long as it's not lost. For faster transactions, you can raise the priority for a higher fee.


What are some reliable public monero nodes one can connect to using their Monerujo app?

https://node.pwned.systems/ has a listing of nodes you could use, updated every 20 minutes.

If you like to use DNS: node.moneroworld.com:18089

To understand the risks, read this reddit thread and this link.


Is a 50-60 H/s hashing speed normal for an Intel Core i5 4200?

Seems normal. You can play with number of threads to try and get some more. Amount of CPU cache is very important as you need 2MB of it for 1 thread.

If comparing with other cryptocurrencies, note that it's a different mining algorithm (CryptoNight) and that's the reason why you're not getting similar to others like Bitcoin.


How do I compile monero with debugging symbols?

"make debug" will build monero with debugging symbols. You will need to debug the binary from build/debug/bin/monerod though, not the one from build/release/bin/monerod.


Helper functions for ECC operations in Monero

https://github.com/monero-project/monero/blob/master/src/crypto/crypto-ops-data.c
There are 2 places these ops are found, firstly https://github.com/monero-project/monero/blob/master/src/crypto/crypto-ops.c which has the lower level c code and https://github.com/monero-project/monero/tree/master/src/ringct which has some c++ wrappers.


Why isn't safe sync mode enabled by default?

Mostly because it's a lot slower, which could cause users to abandon Monero out of frustration if they can't sync in a few days.

There are recent improvements to a "sweet spot", however. See https://github.com/monero-project/monero/commit/65e33b1bc51d6540f23c8de0dbf4826a56549373


Solo mining requires running a full node, pool mining does not. Also, when solo mining, it will usually take much longer to find a block when compared to a pool. Pools do charge a fee, normally 1-2% of the block reward.

When pool mining on a Windows PC, I use less than 20 Mb/day download and less than 5 Mb/day upload. Solo mining will be more bandwidth intensive due to running a full node.


The source for the Monero tools is on http://github.com/monero-project/monero.
Compiling's done with "make". See the README.md file for the necessary dependencies, and detailed build steps for various platforms.

Note that the GUI is on http://github.com/monero-project/monero-core.


You can copy nearly every field in the GUI with an double-click or the copy symbol and you can paste in any field with strg+v.


Explanation of how exactly the pederson commitments in monero work?

Blinding factors are random numbers that are only used once per commitment. No two commitments should ever share the same blinding factor, even if they're for the same amount. The blinding factor is generated by the sender and communicated to the receiver in encrypted form using the DH shared secret (as you've pointed out).

If the existing commitments for inputs were used in transactions spending multiple inputs (known as RCTTypeSimple transactions), if one real input ring position was revealed, this would reveal all real input ring positions in the transaction.

Therefore for transactions spending multiple inputs, you avoid this problem by creating new commitments for the inputs you're spending, and these are called "PseudoOuts" in the transaction structure. See Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT


Monero inception - how did bitmonero become monero?

Was the project re-started with new genesis block but with the same name?

No, the project was never restarted with a new genesis block. The project simply continued with a new set of stewards of the project. These stewards replaced, or more bluntly put kicked out, the old team, which was led by thankful_for_today. That is, after some discussion on IRC, the "move" / "takeover", in conjunction with a name change, was announced by David Latapie on the Bitcointalk forum. The stewards, better known as the core-team, that replaced thankful_for_today were fluffypony, tacotime, NoodleDoodle, smooth, othe, David Latapie, and eizh. At the end of 2015, the latter two core-team members resigned from the core-team due to time constraints and were replaced by luigi1111 and ArticMine.

  Was the code just forked?

As far as I can see from the Github commit history, the stewards indeed forked the code over to a new Github repository and continued with that. The old repository of thankful_for_today can be found here.

  What was the difference and disagreement?

This basically boils down to thankful_for_today playing the benevolent dictator and pushing changes which the community largely disagreed with. He also pushed changes without conferring with, or simply ignoring, the community. There are more extensive examples in the formal write up, under "the second renaissance".

  What exactly happened at this point in history?

There's a more elaborate and formal write up here. This write up also includes some kind of timeline.


Release binaries (including Linux 32-bit) are available here: https://github.com/monero-project/monero/releases

There are also 32-bit Linux binaries linked here: https://web.getmonero.org/downloads/#cli


Did the Silk Road coins of 110,000 Bitcoins actually moved into Monero XMR during 2018 Sept?

This did not happen. The FBI confiscated the BTC and later sold it to Tim Draper. Here is the source: https://www.coindesk.com/tim-draper-revealed-silk-road-bitcoin-auction-winner


Can an ISP swap out Monero's default peers? Would this be detectable?

Since those peers are hardcoded into the Monero software, could a malicious ISP intercept initial communications by redirecting traffic to those peers?

Sure, to another valid Monero node.  Traffic NAT'ing happens all the time.

  Would this be detectable?

I don't see anything in the codebase that reaches out to STUN, etc. to determine its outside IP (and then include it encrypted), so it looks possible to spoof a peer by IP.  That said, the codebase has the genesis transaction hard-coded in it, and every block in a blockchain depends on the previous block, so if an ISP or the spooks want to run an extra Monero node, then - great!

Never trust any Monero node on the Internet.  Assume BadGuys are doing all the traffic analysis they can.  The protocol exists so you don't have to trust anybody.  Improvements with noisy Tor (and I2P) make it less likely that you have to trust your ISP to not be your adversary.


Firstly, your G and H are the wrong way round. Each Pedersen commitment is actually xG + aH where x is the blinding factor and a is the amount. So where you are writing P1 = a1 * G + r1 * H, I would write: C1 = x1G + a1H.

  If the amounts do not balance out, for example, let's say the sender decides to not include P4.

A transaction is invalid if it has more outputs than there are commitments for. It will get rejected.

  What if the sender decides to cancel out the blinding factors part of the commitment instead by cleverly choosing the blinding factor?

This makes no sense without defining how they "cancel out the blinding factors". You are suggesting a way the underlying math could be broken without defining how / a way.

Update now you have tried to explain

You cannot arbitrarily change the blinding factors. Quoting from Zero to Monero, 5.6.2:

  Indeed, z follows from the blinding factors if and only if input
  amounts equal output amounts (recalling Section 4.1, we don’t know γ
  in H = γG).

Given you cannot change the input commitments, the only thing you can do to create a valid commitment to zero, is by having your output commitment balance against the input commitments. In simple terms, if the input commitment is 5, only an output of 5 gives a commitment to 0.

Update based on question edited again

Your new edit just shows Bob burn 2 XMR. He spends input amounts 8 and 2, but only has one output, 8. Thus 2 burnt.

Further,

  C1 + C2 - C3 = 0G + 2H

  Bob then signs with his key as "2"

No, Bob would be signing with 0. Recall the number next to H is an amount, not a blinding factor.

With respect to the title question:

  How does commitment to zero work?

The commitment to zero is a point, zG. This is the sum of all the input commitments blinding factors x, minus the sum of all the output commitments blinding factors y, multiplied by G.

See section: 5.6.2 Commitments to zero.

All of the details are covered extremely well in the Zero to Monero paper. Refer to sections 4.1, 4.2, 5.6.1 and 5.6.2.


There is currently no way to mine with multiple threads in monero-wallet-cli for the mine-for-RPC system.


Byte reversing (nonce and resulted hash)

Computers are byte based, and can store numbers in little endian and big endian (and other more esoteric variants). The Intel architecture uses little endian, so 257 will be represented as 02 ff. Monero hashes are stored in little endian format. Python reads numbers in big endian format. Endianess in this case is the ordering of bytes when interpreting them as a number.


What is the regex for a Monero address or Payment ID?

A Monero address:

4[0-9AB][123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz]{93}

A payment ID:

([0-9a-fA-F]{16}|[0-9a-fA-F]{64})


In the beta GUI wallet, what levels of mixin are offered by the sliding Privacy bar?

Yes, the "Privacy" sliding bar allows you to choose the level of mixin.

Mixin levels are: 4,5,6,7,8,9,10,11,12,13,14,15,20,25

The GUI wallet presets represent the following mixin values:
Low = 4, Medium = 8, High = 25.

At the time of writing, the minimum enforced mixin is 2, but the GUI wallet uses 4 as its minimum.


Can a new platform / cryptocurrency be built on top of Monero?

The Monero blockchain can be used to send any information, as long as it's part of a transaction.  There is a field (tx_extra) where you can effectively put whatever you want in there.  It's really a matter of size as the limiting factor.  As with the bitcoin blockchain, tx fees need to be paid (based on the size of the transaction).  So, yeah, it would work in sort of the same way.


Monero mining equipments can mine Zcash as well and have the same hashpower?

No. Monero uses Cryptonight whereas Zcash uses Equihash. They are different algorithms and most devices will compute them at different speeds, though for some devices they may happen to be close.


Theoretically, is it possible to send a value of 0 to someone?

Yes it is possible. You still need to consume an existing output in order to send a zero output to someone else. This existing output will need to have non-zero value, because you'll need some of it to pay the transaction fee. You'll create a zero output for the recipient, and a change output which will go back to yourself.

All output amounts are encrypted using the "transaction shared secret", which is something only the sender and recipient will have knowledge of. It's also encrypted in a second way as a "Pedersen commitment". The first method of encryption is to pass the real value to the recipient. The Pedersen commitment is part of the proof that no Monero is being created out of thin air.

The encryption applies even if the amount is zero. Your anonymity is therefore definitely not compromised or weakened in the slightest.

If you're interested in the mathematical details, see https://people.xiph.org/~greg/confidential_values.txt

Specifically, your amount is encrypted as a Pedersen commitment using a "blinding factor", which prevents any particular amount (like zero) from standing out in any way. The application of Greg Maxwell's paper, which I linked above, is also known as "confidential transactions", which is the CT in Monero's "RingCT" scheme.


Configuration is done  in the file "xmr.conf".

Index "-1" is used for the CPU.

You can disable CPU mining by setting  "threads": 0 in the section with "index": -1


What is the 'base point' (G) from the whitepaper and how is it represented as a single hex value?

G is the base point of the Ed25519 elliptic curve. The x coordinate is not written explicitly because it can be found back using the y coordinate, the sign of x and the equation of the curve (x is positive for G).

Points on the Ed25519 curve are represented by 32 bytes. These 32 bytes are in fact the little-endian representation of a 256-bit number.

bits 0 to 254 for the y coordinate
bit 255 indicates the sign of the x coordinate

Therefore the hex string representing G is 5866666666666666666666666666666666666666666666666666666666666666.

There are more info about this base point in https://crypto.stackexchange.com/questions/27392/base-point-in-ed25519


What's are the details of the Monero burning bug?

Comprehensively detailed here: https://src.getmonero.org/2018/09/25/a-post-mortum-of-the-burning-bug.html

  Practically speaking this bug is exploited as follows. An attacker first generates a random private transaction key. Thereafter, they modify the code to merely use this particular private transaction key, which ensures multiple transactions to the same public address (e.g. an exchange's hot wallet) are sent to the same stealth address. Subsequently, they send, say, a thousand transactions of 1 XMR to an exchange. Because the exchange's wallet does not warn for this particular abnormality (i.e. funds being received on the same stealth address), the exchange will, as usual, credit the attacker with 1000 XMR. The attacker then sells his XMR for BTC and lastly withdraws this BTC. The result of the hacker's action(s) is that the exchange is left with 999 unspendable / burnt outputs of 1 XMR

To answer your comments:

  I want to know how to generate a random private transaction key

Key generation happens here.

  Also insert the key into the detailed source code? I want to reproduce it.

It cannot be reproduced as the bug was patched.


As you have started the nodes (monerod) with --stagenet, you also need to start the wallet (monero-wallet-cli) with --stagenet.

UPDATE (question edited)

It looks like both your nodes are on the same machine (192.168.1.23) so just run them like:

./monerod --stagenet --no-igd --hide-my-port --data-dir node1 \
  --p2p-bind-ip 127.0.0.1 --p2p-bind-port 48080 \
  --add-exclusive-node 127.0.0.1:38080 \
  --rpc-bind-ip 0.0.0.0 --rpc-bind-port 48081 --confirm-external-bind

./monerod --stagenet --no-igd --hide-my-port --data-dir node2 \
  --p2p-bind-ip 127.0.0.1  --p2p-bind-port 38080 \
  --add-exclusive-node 127.0.0.1:48080

Then on you wallet machine:

monero-wallet-cli.exe --stagenet --daemon-address 192.168.1.23:48081 \
  --log-level 0 --wallet-file test


Blockchain synchronization fails, bus error

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

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

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

gdb monerod core*

Then, in gdb:

bt

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


How to generate integrated addresses without a node?

You do not need a node to generate an integrated address.
You only need the monero-wallet-rpc and call the appropriate method.

Edit: but you should also look at the subaddresses which are designed for the same purpose and will be available for a longer time.

Btw, how do you expect to confirm payment without a node?
A remote node does not seems trustworthy for such use case.


Yes, you can certainly backup the blockchain and restore from the copy if it becomes corrupted. You'd then have to sync only what's been added to it since the last copy.

However, you can't do this without precautions, since monerod will be writing to the database regularly. You need to either exit monerod first, or copy the blockchain using mdb_copy.

You can also use a single backup for multiple machines, though the blockchain will not work on a machine with a different endianness (though it is otherwise compatible with different architecture differences such as word size).


How to identify sender when they send monero?

You could do that, if you want something way more cumbersome than giving a different address to everyone. Another, more secure way is to get the sender to generate a proof of sending a transaction (see get_tx_proof and check_tx_proof), but that is also more cumbersome than using a subaddress per sender.


Your pending balance will start showing once the blocks you have worked on have matured. ~60 new blocks found on the network.


I am running blockchain 0.9.4. Why is it not syncing?

"I know that you can send coins from 0.9.4 to 0.10.0" - I'm not sure what you mean by that? They aren't separate chains like Ethereum and Ethereum Classic, it's the same chain but a newer version of the software.

You can't use 0.9.4 as it's an old, deprecated version of the software. You need to update to 0.10.0, and you may want to sync up from scratch instead of waiting for the database to be converted to the newer format (database changes aren't common, so this won't occur with every upgrade).


If you send two transactions to the same one-time address, will they both be accepted by the blockchain?

First, to clarify again, the question is about one-time addresses, i.e. stealth addresses, which are different than the public addresses. The public addresses can be reused freely, whereas the stealth addresses cannot. For consistency, I'll only use the term stealth address (one-time address) in this answer.
To answer your question, we first need a bit of background. In Monero, key images prevent double spending in the blockchain. Key images are generated by the receiver (Bob) of a transaction, to see if the outputs that belong to him are spendable. Or to put differently, if they aren't already spent. The receiver wants to verify this, because he will most likely want to spend his funds somewhere in the future. From core-team member luigi1111's article:

To check if P is spent, Bob computes its "key image" and queries the blockchain to see if it is marked as spent. Key image I = xHp(P).

Note that P is Bob's stealth address, with P = Hs(rA)G + B.
Where:

P -- the final stealth address (one-time output key, the destination where funds will actually be sent);
Hs* -- a hashing algorithm that returns a scalar (i.e., the hash output is interpreted as an integer and reduced modulo l);
r -- the new random scalar Alice chose for this transaction;
A -- Bob's public view key;
G -- the standard Ed25519 base point;
B -- Bob's public spend key.

From the formulas we can infer that, if the sender (Alice) uses the same stealth address of the receiver (Bob) for two transactions, Bob's outputs of one of the transactions will be burned. That is, both transactions will generate the same key image for Bob. Therefore, only Bob's outputs of one of the transactions are subsequently spendable. Now back to your question, given that stealth addresses are randomly generated, is it highly unlikely that Alice received the funds she has subsequently sent to Bob on a reused stealth address as well. Therefore, the key images generated by Alice are unique and she would be able to send two different transactions to the same stealth address of Bob, which thus will both be accepted into the blockchain.
I previously mentioned that stealth addresses are randomly generated and therefore should not be able to collide, or put differently, reused. One may ask themselves, how would a stealth address appear twice? To answer this, I'll use the comment of reddit user TheKing01:

Technically, stealth address reuse is already possible if you're dumb. A sender can use a one time address more than once if they aren't careful. (It does help though that it is happening all inside simplewallet, so their is no chance for human error in this regard. Either using third party buggy clients or using a bad random number generator could be a problem though).
There is a good way to prevent this type of failure though; simply check if the one time address you are using is already on the block chain (this can be done automatically). If it is, you know there is a problem.


How does the code for scalar reduction work?


What is the difference between i2pd and Kovri?

Kovri is an alternative implementation in C++ of the I2P protocol which original daemon i2p is written in Java, is bloated and quite difficult to use. Kovri is a fork of the C++ implementation i2pd.

You'll find a quite good answer in Kovri's FAQ

Why should I use Kovri instead of i2pd?

Security: our focus is on securing our software; not rushing to get things done for the sake of having a release
Quality: you're supporting efforts to ensure a quality codebase that will stand the test of time. This includes all aspects of code maintainability
Monero: you will be supporting a crypto-currency that prides itself on privacy-preservation and anonymity while increasing both your privacy and anonymity

What are the biggest differences between Kovri and i2pd?

We provide a Forum Funding System for features/development.
We focus on creating a "secure by default", easily maintainable, more-likely-to-be-reviewed I2P router. This will come with the cost of dropping lesser-used features found in the other routers, but core functionality and an API will be fully intact. By creating a smaller, efficient, "bare-bones" router, we will provide developers and researchers more time for security auditing and more time to question the I2P design and specifications.
We focus on implementing an intuitive, developer-friendly API for any application to connect to and use the I2P network; this includes Monero.
We provide both end-users and developers a quality assurance and development model in order to provide better software for everyone.
We will implement alternative reseeding options so users can use Pluggable Transports instead of HTTPS for reseed.
We will implement extended functionality (hidden mode + disabled inbound) to provide anonymity for those who live in countries with extreme conditions or those firewalled by carrier-grade NAT or DS-Lite.
We will always create a welcome environment for collaboration.
We will always listen to your feedback and do our best to improve Kovri!

Why did you fork from i2pd?

We forked for at least several reasons:

We wanted a robust, secure, and viable C++ implementation of the I2P network; and i2pd was not delivering
We wanted a positive community that encouraged collaboration for the betterment of the software; not negative, narcissist glory
We wanted a lead developer who could lead; not someone who could ignore requests for responsible disclosure or tuck-tail-and-run when faced with collaborator conflict

What were the turning points that lead to forking from i2pd (and why are there two i2pd repositories: one on Bitbucket and one on GitHub)?

So began the drama of i2pd.

In early/mid 2015, one of the developers with push privileges on GitHub pushed a commit(s) that i2pd's first author did not like. Instead of working together to resolve the issue, said author took i2pd to Bitbucket, deleted all existing git history, and made himself sole 'contributor' of the software. He then vowed to never return to Irc2P.

These actions offended many in the I2P community, including the developers, and nearly ended the C++ project.

In the fall of 2015, along came anonimal who, not wanting to see everyone's work to go to waste, revived the project through contributions of their own and by reigning-in development. An open invitation for all remaining active developers to meet and discuss i2pd's future was then given. i2pd's first author never showed but the act of meeting apparently rustled i2pd's feathers to the point where he retaliated and began to work on GitHub again - but this time within an openssl branch (which turned out to be the Bitbucket repository) instead of the community-driven master branch.

Seeing that this sort of erratic behavior would only hurt the I2P network and the project as a whole, the remaining developers continued to have several important meetings and set the foundation for what is now Kovri.


worked with the following
 ./configure CFLAGS="-march=native" --with-crypto --with-curl


Is it possible to check which of the last blocks is mined by me?

Using the monero-wallet-cli this is a breeze.

Start the wallet with your miner wallet:

monero-wallet-cli --wallet-file miner-wallet

Then execute:

show_transfers coinbase

Which will list all coinbase (i.e. block reward) transfers. The first column in the output has the block height.


How can block size grow over time when miners are incentivised to keep size small?

TL;DR Actually, with the current minimum fee, there's an incentive for 0.6% growth as long as there's enough transactions coming in. Problem is not in the formulas themselves, but in the typical transaction size / min. block size ratio.

The penalty formula has an optimum block size increase for a set of transactions offering any given fee, see figure below.

The formula works well in the ideal case, where miner would be able to build a block targeting any % increase. If that was the case, for everyone paying the current dynamic minimum fee, the optimum would be 0.6% increase above median. A 1.2% increase would be neutral to the miner, ie he'd get the same total reward as if he just mined a full block without increase.

Problem is, the minimum feasible block size increase is around 20% (adding just 1 typical RCT TX above median). It would be rather hard for a miner to combine such transactions to consistently give an increase of 0.6% above median. He is then left with a simple choice: to add 1 TX above median, or not to. And with the minimum fee, the economical choice will always be not to add. The problem would go away by itself if the blocks would somehow expand above some threshold, as seen in the figure below. Problem is in getting there in the first place.

Currently, to make it neutral for the miner to add just one TX it would mean almost everyone would have to offer around 5$/TX with the current prices. One could argue an user would rather give up transacting then to pay such a fee, unless we're talking about very important transactions.

However, it is planned to fix this with the next HF. There are a few options:

Increase the minimum block size to such that the ratio of typical TX size and min. block size becomes irrelevant, ie to about 1.1MB (to make 1 TX = 1.2% increase). With this, the current formulas would be allowed to work smoothly, but this would make the network vulnerable if someone would want to abuse the free ride to 1MB.
Make the increase for size of 1 TX free. This would mean free increase of 20%, but ever reducing as the blocks grow. This would limit the rate at which the blocks can expand for free, but it would still be free.
Something else. One idea is to tweak the penalty formula such that the current minimum fee will always be sufficient to make it neutral to add 1 TX above the median. This is what I'm currently researching, and the draft is in some readable format at the moment. This would give us a kind of discount with the penalty until we grow up :) It would keep the cost of expansion nearly the same as in the ideal case, but remove this wall made by typical transaction size.


What is the best way to mine Monero on Macbook Pro?

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


help show_transfers documents all the fields.

help show_transfers
Command usage:
  show_transfers [in|out|pending|failed|pool|coinbase] [index=[,,...]] [ []]

Command description:
  Show the incoming/outgoing transfers within an optional height range.

Output format:
  In or Coinbase:    Block Number, "block"|"in",              Time, Amount,  Transaction Hash, Payment ID, Subaddress Index,                     "-", Note
  Out:               Block Number, "out",                     Time, Amount*, Transaction Hash, Payment ID, Fee, Destinations, Input addresses**, "-", Note
  Pool:                            "pool", "in",              Time, Amount,  Transaction Hash, Payment Id, Subaddress Index,                     "-", Note, Double Spend Note
  Pending or Failed:               "failed"|"pending", "out", Time, Amount*, Transaction Hash, Payment ID, Fee, Input addresses**,               "-", Note

  * Excluding change and fee.
  ** Set of address indices used as inputs in this transfer.

As you are showing the output for an "out", the fields are:

Block Number, "out", Time, Amount, Transaction Hash, Payment ID, Fee, Destinations, Input addresses, "-", Note

Also note, sending from a primary address, a subaddress  or an integrated address are all equally anonymous.


How do I split my wallet into smaller denominations?

You can do this by using the transfer_original command. The default transfer command will not split, but seems to be aggregating all the amounts going to the same address in a single denomination. This is based on a few tests I did just now.

So, to split 100XMR to 10 denominations of 10XMR, you'd do:

transfer_original <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10

Of course, you need to have a little more than 100XMR to be able to pay the fee.

One problem with this was pointed out, though. All of these 10 denominations would be in the same TX. If using more than one of them for some payment of >10XMR, it would stick out on the blockchain and these 2 (or more) outputs could be linked together because they come from the same TX. This is unlikely to happen by pure chance when picking decoy outputs to mix with so one could say there's a high likelihood that those 2 outputs belong to the same sender. Not only does this reveal that those 2 outputs were spent by the same person, but it could also reveal that they were likely spent. Then, any ring signature which uses one of those as decoy outputs would be weakened as well.

I'm not sure if it would have a significant impact to privacy if done once per wallet, but I'm inclined to think that it's not such a good idea, after all.


Would another node client be valuable to Monero environment?

The propensity for Eth's multiple implementations to fork unexpectedly is a double edged sword. That said I think once Monero is largely feature complete (probably after multisig is rolled out) there's great value in embracing alternative implementations.

So, I guess to answer your question, yes, there are benefits, but it's better for various reasons to focus on making one client as complete and robust as possible before working on new implementations.


Transaction from GUI wallet to bittrex account never arrived. PLEASE HELP

Monero had a hard fork on the 6th you sent a transaction on the 11th after the hardfork had occurred. You have sent Monero Original to your Bittrex account and not Monero. Try using this guide to re-sync to the correct chain with your old balance.


Which wallet is accurate? The one with 5 or 6 transactions? I would likely delete the GUI and the wallets. Reinstall the GUI and then recover the wallet from the seed but I'm not expert.


RingCt Is It Less Safe to Send the Whole Amount

Monero output amounts are encrypted. You cannot tell anything at all about the value of the inputs or outputs to a transaction (with the exception of freshly created coinbase outputs which have public amounts so that inflation can be tracked).

The validation that the sum of outputs+fee perfectly balances the sum of inputs is achieved using zero knowledge proofs.


Running monero in its own virtualbox, performance issues?

Running any program inside a VM comes with a slight-to-moderate hit in performance. It really depends on how you set things up both on the host computer and inside the client OS. You say you want to use VirtualBox so I am going to assume you're going to run and configure the VM via the GUI and not do anything special with it.

If you're going to run Ubuntu (Desktop I'm assuming again) you're going to need at least 2 CPU cores and 2GBs of RAM for a decent user experience. On top of that you will need to have a big virtual hard drive to contain the blockchain. As of 20 september 2017 my chain is 28.5GB and still growing (I was a bit late with updating the daemon). You would need at least another 10GB for Ubuntu itself. That number includes spare space for future updates/patches and a small swap space). I would recommend to make a virtual disk file of at least a 100GB so that you won't have to do anything complicated to grow your disk file soon. I know from personal experience that writing and reading to this disk file is pretty much on par with that of a real drive.

As far as performance goes you won't really notice the two shared CPU cores. You will notice the 2GBs of always allocated RAM, or rather the lack thereof, as that's a big chunk of RAM for most computers. It will cause more swap usage on the host as less RAM is available for buffering files and such. The disk space is gone either way, whether the chain is stored inside the VM or on the host it does not matter: 28GB is 28GB. Ubuntu itself pales in comparison to the size of the blockchain so I just leave that out of the equation. The disk IO for the blockchain is small enough that you won't really notice it. Especially not if you're using an SSD. You probably would notice some delays in the host if you use a regular hard drive and if the host itself also does a lot of disk IO.

Now monerod itself uses (very) roughly around 20% of the Athlon X4 620 I'm using to power my miner. This will be much less on more modern CPUs. It also uses around a 100MB of RAM and the combined reads/writes are less than 2MB per second from/to the drive. That's nowhere near breaking point for any recent hardware.

So, running a monero node inside a VM is perfectly possible. The VM itself is absolute overkill though and you could save a lot of CPU power and RAM by using a container solution like LXC. If you do want to stick to VirtualBox use Ubuntu Server to ditch the heavy GUI and strip out any unneeded parts. You could probably get away with using a single core and 512MB of RAM then.

And lastly. Don't forget to turn on Intel-VTx/VTd or AMD-V (hardware virtualization) in the BIOS/UEFI. This is the single biggest performance booster for any kind of virtualization. Some computers (like the laptop I'm typing this answer on did) might need a BIOS update for the option to show up. Consult the manual of your motherboard for more information regarding this option.


These are the usual suspects for slow sync:

CPU speed (for block verification). Nothing you can do here other than upgrade CPU or wait for some software optimization but I don't believe there can be any major improvements anymore.
HDD/SSD speed (big slowdown for HDDs, as you have to read / write the blockchain somewhere). Same "solution" as above.
Network bandwidth. If your connection is sucky, you might get better results reducing sync size or importing from .raw file.
Outdated software (sometimes optimizations are rolled out into latest versions). It's good practice in general to have updated software, and sometimes they'll come with a performance boost, too!

From your comments, it seems that network bandwidth is the culprit. Try the .raw method :)


How to Connect a a Monero Wallet to a Monero-Based Website and How to Keep it Safe?

I'm assuming the monero-wallet-rpc is on the same host as the website.

In init.php, define a username and password for the rpc wallet:

// RPC login credentials for monero-wallet-rpc. Use --rpc-login user:pass when starting the rpc wallet.
// Example: monero-wallet-rpc --rpc-login user:pass --wallet-file wallet.bin --rpc-bind-ip 127.0.0.1 --rpc-bind-port 18082
define('RPC_CRED','user:pass');`

Your username and password can be anything. In these examples they're user:pass but change them in your code.

I like to use tmux on my server. In one pane I'll run

./monerod --rpc-bind-ip 127.0.0.1 --rpc-bind-port 18081

...and in another tmux pane I'll run:

monero-wallet-rpc --rpc-login user:pass --wallet-file wallet.bin --rpc-bind-ip 127.0.0.1 --rpc-bind-port 18082

Another tmux pane runs cron.php with php ./cron.php

At this point your web pages should be interacting with the database, monerod, and monero-wallet-rpc.

As for security, that's the never-ending job. At a minimum, rename init.php, cron.php, and config.php. I've seen where people have tried to access those pages on my server, but I renamed those files with completely random names.

Also, in init.php where it has the line:

define('APP',true);

...change APP to something else...whatever you want. You'll need to do this on every page that references APP, which I believe is almost every page.

Make sure to block the wallet port (18082 unless you've changed it) on your firewall, log php error messages instead of displaying them, and keep your server patched.


Is it ok to use same wallet on multiple devices

Yes, this is perfectly fine. The only thing to note is that certain information is stored in your local wallet file that will only be available to the device which has access to that wallet file.

In particular, your address book, the "tx keys" which allow you to prove payment, records of the Monero wallet addresses you've sent payment to and the notes you may have written as descriptions of each transaction you've made. These will only be available to the device with the specific wallet file from which those address book entries were created or those transactions were sent. For this reason some people will want to back up their wallet file on each device.

The most important thing is that you will always be able to see your entire balance and have full access to all of your funds from any device, even if you lose all wallet files and have to restore your wallet from seed.


Where can I find the random public key R=rG in a Tx?

The transaction public key, R, is in the tx_extra part of the transaction data structure. If you look at a block explorer, you'll see the transaction public key listed, e.g. it is e90bea66d774232033ef86684f17e756641dc7ba11bd23b7c3605d8387f2cf3c
 for this transaction: https://xmrchain.net/tx/a1ebbf1c50665e8ccf26d920b1df9e81ab7ffd8edec52c83709b4582656daa2b

The tx_extra data structure is defined here: https://cryptonote.org/cns/cns005.txt

The payment ID also happens to be communicated in the tx_extra, but is entirely unrelated and is optional for each transaction.


It is impossible for XMR to become XMO during a blockchain transaction. What actually happened is that XMR was sent to an "XMO address" which was interpreted as an XMR address. Therefore you sent XMR to an XMR address, and it's still XMR. You sent the funds to an XMR address they were not expecting you to send funds to.

Since they know the private keys to their XMO wallet, they should be able to use those private keys on the XMR blockchain to set up a wallet to get access to the the XMR funds that you sent. There is nothing you can do to reverse the transaction, because cryptocurrency transactions are irreversible.

If they are not willing to bother to do this for you, then please document the situation and notify the Monero community. There have been other reports of problems with freewallet.org documented here: https://www.reddit.com/r/Monero/wiki/avoid


Why is it I2P (garlic routing) well suited for Monero (compared to possible alternatives)?

As compared to Tor which is the most popular now:

i2pd serves the same efforts as Tor, but on a more p2p level, rather than relying on servers.
i2p lends itself more towards our workload.
Monero i2p nodes will also act as general i2p routers, which increases the size of the i2p mixnet and thus has an upshot for both.
Tor is optimised for low-bandwidth clients and high-bandwidth exit nodes, whereas i2p is optimised for internal hidden services. Thus, i2p is significantly faster when routing internal traffic.
i2p's floodfill routers (roughly analogous to Tor's directory servers) aren't hardcoded
i2p is a packet-switched network (as opposed to circuit-switched) which makes it more robust
no client-only peers, all peers route traffic and assist in building and running short-lived tunnels
TCP and UDP are supported, which means that things like OpenAlias can still work over i2p


What infrastructure still needs to be built for Monero that Bitcoin already has?

SPV / Light clients with high level of trustlessness.
Fiat <-> xmr gateways. (sort of encompasses all of the below)
ATM machines.
Billpay-type services
Bitwage type services
Payment processors (so amazon can accept Monero)
Merchant infrastructure (so my local coffee shop can accept monero, kind of similar to payment processors).


What is the safest method to create a Monero wallet for cold storage?

Ok, here is another version. It's not perfect or detailed and it will probably need some additional research.

Preparation:

Get an old computer (and seal its Ethernet port with duct tape – this computer will not touch the Internet again)
Get several fresh USB sticks
Wipe the old computer and the USB sticks (you can use something like DBAN to wipe everything together)
Remove Wi-Fi/Bluetooth cards of your old computer if possible. If not possible, deactivate them in the BIOS.
Get some bootable live OS. You can use Ubuntu, but more or less anything goes. (Check the PGP signature, so you know what you downloaded is correct.)
Download Monero. All you need is monero-wallet-cli. Put that on a stick, too. (Check the PGP signature, so you know what you downloaded is correct.)

Creating the Wallet:

Now boot your old computer with the live OS (only with monitor, keyboard and mouse attached). You can also install the OS, depends on your level of paranoia/convenience.
Copy monero-wallet-cli to your old computer. If you run a live OS, the locations you have to copy the executable to might differ (Google is your friend). Also how to mount the USB stick might need some research.
In case it doesn't work, install the OS. Since it won't "phone home", this is ok too.
Now run monero-wallet-cli. It will create you a fresh wallet. If you intend to save it digitally too (as a .keys file), give it a proper password when asked.

Voilà, you have created your complete secure cold wallet. But wait, it's not done yet.

Data to save:

Now these steps are very important. You have different data to save now. Since most of the data is not allowed to ever touch a computer connected to the Internet again, I would use at least two different USB sticks here.

Check your address in monero-wallet-cli (use command address). This is your public address and it is allowed to touch the internet. Copy it to a textfile on USB 1.
Now check your seed with command seed. You should save it as a text file on USB 2, but also have to note it down by hand several times. This is all you need to restore your account after all. Make sure the words are correct and that the number/sequence is right, too.
In the folder where you ran monero-wallet-cli, three files got created. Copy the .keys file to USB 2.
Optionally, you can also save your view key (maybe put it on another USB, so you can decide later how and when it touches another computer)
It is also wise to note down the seed together with the monero-wallet-cli version. You can check it with ./monero-wallet-cli --version.

The process is now basically finished. Of course there is lots of variance. You can go with a paper wallet only, by just not doing USB 2 and just keeping the handwritten seed as the only backup. USB 2 should only touch offline computers.
Turn off your computer, wipe it again if it was not a live OS, and keep your seed and USB 2 safe.

Please do practice the creating and restoring process before sending any meaningful amount to such a cold wallet


Does the daemon that mines a block see the transactions in clear text?

Pending transactions are in a transaction pool, which is publicly available. See for example this page.

Each daemon has a copy of that transaction pool and, when finding a block, will include some of the transactions in the block before pushing it to the network. The details of the transaction, (a) as created by a wallet client, (b) in the transaction pool and (c) in the blockchain once it's included in a block are the same.

So your question essentially asks if Monero transactions can be decrypted, which has been answered in other places, such as: What privacy issues did Monero have and still has?


How to determine number of used subaddresses after restoring from seed?

When restoring a wallet from the seed, the wallet automatically expands the internal subaddress table such that it can recognize incoming transfers to new subaddresses. If you type address all, the wallet displays a list of subaddresses in use so far:

[wallet 9xLMUj]: address all
0  9xLMUjRpNfEQLoYwogkmiBg9H6XP18mJ3UJphkvhWo9SB3vwbJFSryNfVz6vJFigYwLadki17xHQG7qsxQnnZPuPC1XvpHq  Primary address (used)
1  Bh7S7kAEQmdQ8eGjnySzb7XShEZdYVScQ8FXtbXgfoQF5NkuNH5FnTSXzfehhbnrypWuwUqtbi28YFKy2aVcqy68FGUfAwk   (used)
2  BfSTksPWaf1iJLJGHtyg6DRzWERXQA1coJTJULcwh8BBZuNgvyYcG2NYaJBQnf1d9yDAXExZaJH46AGMehGJiZCv3MsR1vg   (used)
3  BYTWmE5EXGwB2HHfN2vXvkY5U8Aj5bQgQBqyk33Hf9akfN3cFTpumyNh3kFkYLtvfjgxGgwvhDDPSBy6oR8Jh4bXSrYMaMi   (used)

The (used) flag indicates that the subaddress has ever received any funds so far. You can use address new to generate a new address.

If you generated a new subaddress and gave it to someone else, but that person didn't send money to that address, then the information about you giving the address to that person doesn't get recorded in the blockchain, so it's impossible for you to recover that information from the blockchain when you restore the wallet from seed.

I don't think it's practical to make a special transaction every time you issue a new subaddress just for the sake of recording the information about your new address in the blockchain.


scoobybejesus recommended I make sure the server time was correct.
I am on Arch Linux, so I ran timedatectl set-ntp true to sync my clock and the Monero server synced within a minute.

Looks like I forgot to run that when I installed the OS a few days ago.


Based on your comment, mining from a python script, your best bet is to build a python c extension.

You can include the relevant crypto hashing functions and take it from there. An example, albite a JS WASM module, is here. Essentially rework the main.cpp as your python extension api.


Possible to turn off CLI Wallet logging?

OK, so I originally asked this question (and previously commented) as a "guest", but now that I've finished setting up this account fully, the account is no longer tied to this question. So I can't comment on it anymore, and will have to respond to you guys with an answer.

@user36303 - Yes, you are right about the default logging. Apparently I had somehow carried over an old log file from previous versions of Monero without realizing it until now. Currently, the default logging is just the startup message (which is what I was trying to eliminate with this question anyway).

@dEBRUYNE - No, your suggestion did not work; the arg was right, but the option was wrong. To completely prevent logging, you need to put that arg (or the arg @jtgrassie submitted in his answer) on the --log-file option. So, two options work to prevent logging:

--log-file ""

or

--log-file /dev/null


Will it be possible to see the mixin number with ringct on?

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

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

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


How could Monero profit from TumbleMoneroWimble?

The whitepaper is fake, never meant to be taken seriously.

Quoting @fluffypony's followup tweet:

  Don't take the 3 papers I tweeted as serious, I used the Koinster whitepaper generator for altcoin-quality papers: https://whitepaper.koinster.com/


What is Monero's release naming convention?

Monero's naming convention of a chemical element + a star or constellation is the result of a discussion on the official forum: "Now for some fun: naming Monero releases"

Regarding alliteration:

  "using alliteration / assonance for maximum awesomeness." (fluffypony)

First release with this scheme is 0.9.0 ("Hydrogen Helix") and has been chosen in thread Name the Next Monero Release!

For v0.10.0 ("Wolfram Warptangent"), the scheme has been partially ignored to honor contributor Warptangent who passed away and had done a lot of work on the project among other on RingCT.

Note: Wolfram is an other name for Tungsten.

(Wikipedia, By Alchemist-hp (talk) (www.pse-mendelejew.de) - Own work, FAL, https://commons.wikimedia.org/w/index.php?curid=10424635)


Why is mymonero.com blocked when using the Tor Browser?

According to site operator fluffyponyza there should be an error message that explains this:

  The site you are visiting is NOT the real MyMonero! Please make sure that in future you type mymonero.com into your address bar, and don't click on links to visit the site. Note that you may also see this message when trying to access MyMonero on Tor, as impersonator sites try and use Tor to reverse-proxy to MyMonero.

Eventually Mymonero will offer 2 solutions that will work with tor:

An onion site
A downloadable client based on MyMonero code

Until then the error is provided for your protection against hackers:

  that use attacks like POODLE. That's not even counting things like sslstrip + a lock favicon, or URI Unicode hacks, or a sophisticated attacker leveraging a compromised or malleable CA. TLS over Tor is safe only if you verify the fingerprint, or use something that secures it such as DANE (which is largely unsupported and hardly deployed).


When using the android and iOS monero wallets. How does it not send the private spend key to the node to scan the blockchain?

Monero has two private keys, the private spend key and the private view key.

The private spend key is needed for determining whether an output that you own has been spent, creating a key image for when it will be spent, and for signing the transaction.

The private view key is needed for determining whether any outputs on the blockchain were sent to your public address.  In cases where your wallet's blockchain-scanning is delegated to a remote node, the remote node will use your private view key to do the blockchain scanning.

Once the remote node has scanned and provided your wallet with a list of outputs, the remainder of the work happens locally on the device, so the private spend key never leaves the device.


Does entropy vary depending on the language of my mnemonic seeds?

I will answer your second question first:
Yes, a longer word list would lead to increased entropy and a shorter list would lead to decreased entropy.
Monero avoids this problem by relying on an Electrum word list that is exactly 1626 words for each language. Because of this, the entropy of mnemonic seeds created with simplewallet for each language below will be the same.

0 : English
1 : Spanish
2 : German
3 : Italian
4 : Portuguese
5 : Russian
6 : Japanese


How to implement a java script version of monero CPU miner

The site itself says they've used WebAssembly to compile C code to Javascript. This means you'd need to be competent in C in order to attempt this feat.

If you work through the numbers though, the revenue you'd get from asking your visitors to mine Monero will be tiny compared to the advertising revenue you could get instead. I'd also imagine Google will soon start blacklisting sites that do this.


Do all Monero private spend keys start with a 3? What other patterns are there?

No. Private keys are created from 32 random bytes.


Same reward for solo and pool mining in the long term?

Solo and pool mining should give out similar reward in the long term, with a few notable differences:

pools typically have a fee, varying from 0% to 2%.
working with a pool incurs some small delays (ie, the pool has to send miners a message telling them about a new block, etc), which can waste some small amount of hashrate
pools have a payout threshold to avoid spamming the blcockchain, so you always end up with small amounts due still on the pool

Note that if you get your monero with small amounts (ie, 0.3 is typical from a pool), you will end up with a lot more outputs than if you get them from solo mining, so spending pool income will cost you more in fees.


Can a node I am connected to with monerod cause any damage to me if it is malicious?

This may be worth a read:

https://bitcoin.stackexchange.com/questions/40383/what-is-the-protection-against-a-malicious-node-with-a-bad-block-chain

This would mean that a node cannot simply make a blockchain up as it is compared with peers so it must generate an equally as valid one so thus in order to perform a malicious attack with a bad blockchain must contain 51% of the hashing power.


What is the the difference from spendkey vs the viewkey in Monero?

Do you give the public view and spend key to the person that is paying you?

Yes. Both are conveniently packed inside your address. Think of them as "instruction to sender".

  I'm using the monero cli and was wondering what is the difference from the spendkey and the view key.

Here's a quick overview of what each key is used for.

The sender reads the public spend key and public view key from your address, and uses them to construct a special one-time "container" which will hold the funds intended for you.

On the receiving end you check each TX against your secret view key (technically, you also need the public spend key) and when there's a match, your wallet takes note of that, adds it to the balance and saves the details into wallet cache.

When you want to spend, your wallet uses both the secret view key and secret spend key to reconstruct a key to the particular "container", and a key image of the container. With that you can spend, or just check if it was spent.


Just mined with an old version v0.13.0.4 and upgraded to v0.14.0.2. Reward now missing

0.13.0.4 can not understand the current consensus rules, so it's essentially playing in its own abandoned playpen. You never found any Monero. It's a bit similar to participating in a bike race, taking a wrong turn and somehow ending up on last week's bike race's circuit and going over that finish line that's still chalked on the ground. You did not win that race either.


What happens to a transaction inside an orphan block

An orphan block means that a block was found but in the end isn't relevant (will not be part) on the main blockchain, because another valid block was found and accepted. This is possible since there is not only one possible solution.

But this situation doesn't influence any transaction since you are searching for a block that represents a set of transactions. As explained previously, orphan blocks are not integrated in the (main) blockchain because another valid block was previously found. So that means that the transactions are already part (or "inside") of the previously found block.


When compiling from source, do we git checkout release-v0.17 or latest (currently v0.17.1.9)?

Figured it out... release-v0.17 for sure (last commit was 13 days ago).
Latest release (currently v0.17.1.9) was released on Jan 8 (months ago).


Where can I get information on network congestion?

There's been no noticeable congestion in the last few days. One way to see this is to use the bc_dyn_stats command, which takes the number of blocks to consider for the stats. Here, we see the stats over the last 5000 blocks (with 720 blocks a day target, this is about a week):

bc_dyn_stats 5000
Height: 1407694, diff 30128085264, cum. diff 3696203931783216, target 120 sec, dyn fee 0.000252520000/kB
Last 5000: avg. diff 29701519077, 119 avg sec/block, avg num txes 5.3806, avg. reward 6.451334569868, median block size 54240
Block versions: 5000 v6
Voting for: 5000 v6

We see the median block size is just 54240 bytes, and the minimum block size limit is 300000 bytes, so there is plenty of space to spare. Of course, this does not mean there can't have been a massive glut at some point, and little traffic for the rest of the week, but that seems unlikely.

About the "mining reward sitting at 1/60 confirmations for 5 days", two things are important to note: First, transaction traffic (ie, congestion) has no real influence on the speed at which blocks are mined. Whether or not there is heavy use or light use, block time will continue to target 120 second (you can see the actual average was 119 second per block over the last week's worth of blocks, pretty close to target). Second, if a block you mined 5 days ago is still not seeing any further block, then either you're most likely disconnected from the network. This could happen if you're not finding any peer, or because you and the peers you find don't agree on the consensus rules. Note a fork happened a few days ago, on the 16th. I think you might be running Monero 0.10.3.1 ? If this is the case, you're out of date, and you may be mining on your own lone fork, and you need to switch to 0.11.0.0 to be able to follow the network again.

About transaction priority, it's very unlikely that a higher than default priority (and thus fee) will not be mined quick. The vast majority of transactions use the default fee, even in a glut, so a higher fee will be mined pretty fast - again, assuming you're on the correct fork, where miners are working.


Approximate cost of developing Cryptonight ASICs

Even FPGA would be expensive for CryptoNight because most standard FPGA have close to zero memory. Your second point will, therefore, not only decrease the relative advantage of ASICs or FPGA over GPUs and CPUs but greatly increase their cost.

Even a basic FPGA mining board would be an expensive custom job because of this memory requirement.

I would estimate a minimum of $100,000 for the most basic FPGA board with minimum order requirements that will unlikely allow it to be profitable over GPUs and CPUs unless Monero prices rise dramatically.

ASICs creation might cost anywhere from a few hundred thousand to several million dollars depending on the specs. Again, there would be no guarantee of profitability.

ASICs for CryptoNight remains pretty unlikely until/unless XMR prices rise dramatically. There is also always a threat that Monero could eventually change its PoW to Cuckoo PoW or something else. Eventually a more Quantum resistant PoW might become attractive. If Monero changes PoW all previously produced CryptoNight ASICs would become close to worthless because there are not any other CryptoNight coins with the market cap to justify their expense.


Hiding transaction values using pederson commitments and range proofs in accounts model

I'll describe conceptually how they work in Monero, since this is the Monero stackexchange. I'd assume they would work similarly when implemented elsewhere.

Output amounts are encrypted by the sender using the transaction shared secret, and bundled with the transaction. The transaction shared secret is the result of a Diffie Hellman exchange between the sender and the recipient. The recipient decrypts the amount in order to figure out the value of the funds that have been sent.

It is also necessary to provide a Pedersen commitment for each output amount, so that the network can verify that no funds have been created out of thin air. The Pedersen commitment does not reveal the amount of the output and does not allow for values to be compared to one another, but does provide a mathematical mechanism to allow it to be proven that a set of Pedersen commitments sum to zero. This allows the network to verify that no Monero is being created out of thin air. The same mechanism described in the paragraph above for encrypting and sending the output amounts is used to additionally encrypt and bundle the Pederson commitment blinding factors to the recipient. Knowledge of these blinding factors is necessary for the recipient to construct a transaction in the future that can spend the outputs that are received in a past transaction.

Ring signatures prove that in at least one combination of the sum of possible inputs and outputs, one of those combinations does sum to zero. Since the sum of Pedersen commitments is a public key, and since the proof of a Pedersen commitment summing to zero is effectively a signature that demonstrates knowledge of the Pedersen commitment's private key, Pedersen commitments are easy to combine with ring signatures (since ring signatures prove knowledge of one private key for a given set of public keys).


Problem with Ledger Nano S and Monero GUI: Invalid password

There is a known problem with Ledger v1.5.5.


How do I use my MyMonero wallet via the Monero Core GUI?

The MyMonero wallets use a different type of mnemonic: 13 words instead of 25 words. The Monero Core GUI (or the CLI) doesn't support restoring a wallet from a 13 word mnemonic seed. Therefore, you'll need to go via the keys.

In MyMonero, once logged in, click on the Accounts drop-down menu, and choose Account Details:

Next, the "Review Account Details" page will be shown, containing the following 3 items (copy the text values from your browser):

Once you have the above information, you can move on and import them into a new wallet using the CLI utility monero-wallet-cli, which is shipped as part of the Monero Core GUI software. Locate the CLI utility on your system. Depending on your platform, it will be in a different location. For example, on macOS, assuming you've installed the software in the Applications folder, the CLI utility will be at /Applications/monero-wallet-gui.app/Contents/MacOS/monero-wallet-cli.
Once you know where the CLI utility resides, open a Terminal (macOS) or Command Prompt (Windows). Create a suitable directory for the wallet, and start the import process with /Applications/monero-wallet-gui.app/Contents/MacOS/monero-wallet-cli --generate-from-keys mymonero.wallet:

If you don't have a daemon active yet, ignore those errors for now. Start up the Monero Core GUI, and choose the option "Open a wallet from file". Navigate to the directory (e.g. mymonero) where you performed the above step. Select the file monero.wallet.keys and click Open. After you've entered the password and clicked on OK, your MyMonero wallet will now start synchronizing against the daemon (assuming it is running, or if you pointed to an external node at the Welcome screen). Once completed, check your address on the Receive page:

Note that on the Settings page of the GUI, clicking on the Show seed button won't do anything, because the format of your wallet's seed is imcompatible with the 25-word style mmemonic used in the official CLI and GUI.


What is a quick and easy way to convert a Monero private key into a 24 word mnemonic seed?

https://github.com/moneromooo-monero/monero-wallet-generator includes Javascript code to create a 25 word seed from a secret key. You can then chop off the last word to get a 24 word seed, since the last word is the checksum and is optional.
Specifically, you want the mn_encode function:
function mn_encode(str, wordset_name) {
    'use strict';
    wordset_name = wordset_name || mn_default_wordset;
    var wordset = mn_words[wordset_name];
    var out = [];
    var n = wordset.words.length;
    for (var j = 0; j < str.length; j += 8) {
        str = str.slice(0, j) + mn_swap_endian_4byte(str.slice(j, j + 8)) + str.slice(j + 8);
    }
    for (var i = 0; i < str.length; i += 8) {
        var x = parseInt(str.substr(i, 8), 16);
        var w1 = (x % n);
        var w2 = (Math.floor(x / n) + w1) % n;
        var w3 = (Math.floor(Math.floor(x / n) / n) + w2) % n;
        out = out.concat([wordset.words[w1], wordset.words[w2], wordset.words[w3]]);
    }
    if (wordset.prefix_len > 0) {
        out.push(out[mn_get_checksum_index(out, wordset.prefix_len)]);
    }
    return out.join(' ');
}

The words list and the helper functions it calls are in the same file.


Let's first start with what's needed to compute which outputs are destined for you:

The tx public key (R)
Each one-time output destination destination key in the tx (P)
Your wallets private view key (a)

Therefore, a wallet either needs to offload (trust) sending their private view key to some other node which can perform the scan, or they have to have all the above locally. The remote node (in your example) cannot steal coins, as it doesn't have your private spend key, but it leaks privacy because the remote node can see how much money is sent to you (you have divulged your private view key). This latter point is the problem.


Yes, change this line and recompile. It's a wallet thing, not consensus.

There are caveats:

You'll probably be the only one with changed config so someone could use it to fingerprint your TXes
If a reorg happens, there's the risk of your transaction becoming invalid because inputs are referenced by offset


How are outputs chosen on the blockchain for ring signatures in a transaction?

You must choose mix inputs of the same amount as the one you are spending. Other than that there are no restrictions, though it's not a good idea to choose a really recent output (less than 10 blocks old -- you'd also have to modify the daemon and/or wallet to do so).

The wallet currently chooses outputs as follows: 25% are chosen randomly from "recent outs", presently the last five days; the remaining 75% are chosen from older outputs using a triangular distribution. You can see the math starting here.

More research is needed to find a better method/better parameters (there is some doubt an ideal method actually exists).


Can't connect to my full node outside my local network

--rpc-bind-ip [IP ADDRESS] Binds the daemon to an IP address. You need to use your External IP if you plan to access this daemon from outside your local network, or an Internal IP if you only want it to work for devices in the same local network.

--rpc-bind-ip 0.0.0.0 In the context of a local network, 0.0.0.0 means 'all the IP addresses inside the local network'. So the daemon bonded to internal IPs can be reachable only by internal addresses and not from outside the local network.

You should use --rpc-bind-ip [YOUR EXTERNAL IP ADDRESS] to make the daemon reachable from outside your LAN. Additionally, you must set firewall rules and forward ports depending on your particular local network and router configuration.


If I remember well there was a minor bug in displaying the new one. Try using the command seed to show it again, it should be different. Note that both old and new seed will encode to the same private key.

The difference is that old one was just a random number which would have to be 'normalized' to a valid private key. Now, your seed is your private key. More in-depth explanation here: Why did monero-wallet-cli restore the same wallet with different mnemonic seeds?


Gui wallet seed imported into mymonero web wallet.Any possible security risks?

Not really a security risk unless some powerful criminal organization has specifically targeted you.

You don't need to delete anything. Simply create a new wallet with your GUI and send the balance of the mistaken GUI wallet entered into myMonero, to your new GUI wallet. To make a new wallet just press "cancel" when the GUI asks for wallet password. That way the mistaken wallet's balance will be zero and you simply don't use it anymore. Once you are sure the balance is zero, delete your mnemonic seed so you don't get confused.

Your new GUI wallet will now have the funds you wanted in your GUI and will have no connection to myMonero.


What are field elements and group elements used for?

The ref10 folder contains code for operations on curve25519. This code comes from NaCL, and is not specific to monero. Reading material on ECC will be more helpful in understanding this code than the monero whitepaper.

The group refers to the finite set of points that are solutions to the equation defined by curve25519. Each point has an x and y coordinate integer value, and each value is in the finite set of integers defined by the field. These points are the "public" keys used within monero. The public keys are "found" by repeatedly adding the curve25519 base point to itself. The number of times the base point is added to itself is determined by the randomly generated private key (a large integer value).

The tricky part is understanding that the addition operations are defined in terms of the points on the curve itself, and not on integers. But solving for points on the curve is done with integers, but only those defined by the field.


Using the wallet RPC on your view only (hot) wallet, you can call transfer with get_tx_metadata: true and do_not_relay: true which will yield an unsigned_txset in the response.

Then on the spend wallet RPC (your cold wallet), call sign_transfer, passing in the unsigned_txset from above, which will yield a signed_txset in the response.

Back on the view only (hot) wallet RPC, call submit_transfer, passing the data from signed_txset above in the tx_data_hex parameter.

The linked methods all have examples of these steps using curl. The calls are just simple HTTP POST requests, so libraries are not really needed.


Money not received in Exchange from Wallet

Exchanges will provide you with a payment ID, so they know how to credit the deposit.  Perhaps you didn't use one.  Whether or not you used one, you can prove you sent the transaction with the transaction private key, so either way you should reach out to the exchange support and request that they credit your account.


Ring signature with sublinear size increase

This was answered by core-team member smooth on Reddit:

  First one has a trusted setup. I don't know what issues there might be with the other one. I remember the MRL guys look at some sublinear ring sig at one point a year or two ago and it had high minimum size, such that it would only be useful for very large mix sets. That could still be an improvement overall but not necessarily a huge one so it wasn't highly prioritized.


What are factors to consider to choose the best mining pool?

If the pool has variable difficulty like most pools do mining with high end hardware should not be a problem as the difficulty will adjust based off the shares your hardware submits.
If the pool has a high payment threshold for those with low end mining hardware may not be feasible.
It should not matter how many miners a pool. It is more to do with hashrate which would increase often a block is found by the pool. The higher the hashrate of the pool the more consistent your payments will be however overall earning should not be affected when averaged out.
Your ping to the pool will count as you may submit outdated shares leading to penalties on your earnings so best to stick to pools that are geographically close to you.

That being said the fee which the pool takes is also important to consider as well as trying to keep the network decentralised. My method would be finding a set of pools with low pings as well as fees and then deciding how often you are willing to go without payment, If it is multiple days try to stick with smaller pools to decentralise the network, else you could stick to slightly bigger pools that pay out more often. Finally if your hardware has a low hashrate avoid pools with high payment thresholds.


Using downloaded raw blockchain Setting up XMRig CPU miner (Monero)

With xmrig alone, you can't. You can set up monero-stratum if you would like a really simple solo mining pool.

This also requires a daemon, so you won't be mining 'fake' coins unless you joined the testnet or the stagenet.


At what dates did the Monero blockchain version update?

You can find the fork heights and approximate dates in blockchain.cpp:

mainnet_hard_forks[] = {
  // version 1 from the start of the blockchain
  { 1, 1, 0, 1341378000 },

  // version 2 starts from block 1009827, which is on or around the 20th of March, 2016. Fork time finalised on 2015-09-20. No fork voting occurs for the v2 fork.
  { 2, 1009827, 0, 1442763710 },

  // version 3 starts from block 1141317, which is on or around the 24th of September, 2016. Fork time finalised on 2016-03-21.
  { 3, 1141317, 0, 1458558528 },

  // version 4 starts from block 1220516, which is on or around the 5th of January, 2017. Fork time finalised on 2016-09-18.
  { 4, 1220516, 0, 1483574400 },

  // version 5 starts from block 1288616, which is on or around the 15th of April, 2017. Fork time finalised on 2017-03-14.
  { 5, 1288616, 0, 1489520158 },

  // version 6 starts from block 1400000, which is on or around the 16th of September, 2017. Fork time finalised on 2017-08-18.
  { 6, 1400000, 0, 1503046577 },

  // version 7 starts from block 1546000, which is on or around the 6th of April, 2018. Fork time finalised on 2018-03-17.
  { 7, 1546000, 0, 1521303150 },

  // version 8 starts from block 1685555, which is on or around the 18th of October, 2018. Fork time finalised on 2018-09-02.
  { 8, 1685555, 0, 1535889547 },

  // version 9 starts from block 1686275, which is on or around the 19th of October, 2018. Fork time finalised on 2018-09-02.
  { 9, 1686275, 0, 1535889548 },
};


If you're on a UNIX-like OS such as Linux or macOS, and have jq installed, you can do this:

curl -s -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblock","params":{"height":1}}' -H 'Content-Type: application/json' | jq '.result.block_header.timestamp' | gawk '{print strftime("%c", $0)}'

Fri 18 Apr 2014 12:49:53

The first part displays the genesis block in JSON format. The jq-filter, selects the "UNIX" timestamp (1397818193), which gets converted to a readable date and time with gawk.

Obviously, instead of 127.0.0.1, you could point to any node, such as node.moneroworld.com. The RPC-call is described in the Daemon RPC Documentation.

Update: I just realized you don't want the date, but the number of days since. The following one-liner, using bc, gives you the number of days:

echo "scale = 1; ($(date +%s) - $(curl -s -X POST http://node.moneroworld.com:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getblock","params":{"height":1}}' -H 'Content-Type: application/json' | jq '.result.block_header.timestamp')) / 86400" | bc

993.4


How can I spend coins if other people can't see my balance?

When you have 5 monero it actually means that you have some unspent outputs with the total value being 5 monero. Those outputs are actually one-time use containers and you always empty them completely to make new ones.

So, if you had 5 monero in a single container, when sending 3 monero to someone, you'd empty your original container and create new ones of 3+2; one for the recipient and one for you. The recipient's wallet is then able to recognize (using private view key) and access the corresponding one-time private key (using private spend key) to the corresponding container(s).

Spending actually means using the one-time private key to sign to empty some container, which gives you the right to create new containers of the same value. The network doesn't check that it's full because it doesn't know which container you're emptying (it's hidden among other containers in the ring signature - the network can't know from which one you "took"). Instead, the network does check that you don't take from the same one 2 times, which effectively prevents double-spends but still keeps the "real" container hidden among other ones used in the ring signature. The mechanism for this is called a key image, and it's described here: What is a key image?


How can I buy 'Mastering Monero' via XMR?

Until an option to buy it directly through Monero will be available (you can check it on https://masteringmonero.com/), you can buy 'Mastering Monero: The future of private transactions' with XMR in this way:

use https://xmr.to/ to convert Monero in Bitcoin
use converted coins to buy a gift card for Amazon at https://www.bitrefill.com/ or with another similar service
use that gift card to buy 'Mastering Monero' on Amazon at https://www.amazon.com/dp/1731079966/


Side chains are blockchains that Monero can be moved to and from with a form of pegging.

Decentralized sidechains will need miners to secure the network for the same reason miners are needed to secure Monero. For this reason adding sidechains only make sense once the main chain has achieved a high enough hashrate to be very secure.

Federated sidechains have the potential potential to eliminate the need for a P2P mining network but at the expense of decentralization. Some level of trust would need to be put into 3rd parties with some sort of multi-signature setup.

Sidechains are often discussed as potential ways to allow additional features (but sometimes at the expense of security or centralization). Since Monero has an adaptive blocksize and privacy as a core focus there appears to be no immediate need to create a sidechain.

Monero research goals include sidechains that could bring many additional features to Monero in the future.


How does someone become a contributor to Monero code?

A good way to get started it to use Monero, and improve something small which you think can be improved. This allows you to start on a change that's simple enough to start with, while having a goal to achieve. Then do it again :)

Monero's git repository is at https://github.com/monero-project/bitmonero/. There, you can find a list of issues (https://github.com/monero-project/bitmonero/issues), some of which are fairly self contained and simple for a new contributor.

To talk with other contributors, join Freenode IRC, in #monero-dev. There is also #monero for monero talk that's not about developing monero. It is a good idea to idle in those channels.

There aren't really prerequisites, but some of the Monero/Cryptonote code is fairly complex. Some is less so (eg, the wallet code).

There are also other things you might want to contribute to, which are helpful to Monero: Kovri (https://github.com/monero-project/kovri/), the I2P router which will allow Monero to connect to the network via I2P, or the pool software (https://github.com/zone117x/node-cryptonote-pool), written in Javascript, or the GUI (https://github.com/mbg033/monero-core), in C++/QML.


Is Monero in I2P secure now, and how do I do it?

This question [After Kovri arrives will some full nodes need to remain on clearnet? ] deals with peer discovery through Kovri. How about peer discovery right now if I wanna run a full node in I2P? Will the current client know to connect to only I2P nodes?

Kovri does not yet integrate with Monero. In the future when integrated, there will be three modes: IP only, bridged, and I2P-only. If you use the extreme I2P-only option, then it will only connect to other nodes that use I2P. These nodes can be ones run in either bridged mode (most likely) or also in I2P-only mode.

  If my client is gonna connect with clear net nodes also, does it know to send my transactions only to the known I2P nodes? Again I'm asking about functionality right now, not what is planned with Kovri. If not then is there any security and anonymity benefit to using I2P right now?

If you are connected only with I2P, all your connections to other nodes will occur through I2P. These can be to nodes who are running only I2P connections or both I2P and clearnet connections.

  When I broadcast a transaction txid in I2P, the only info the I2P nodes know is, 'Somebody over I2P has broadcasted transaction txid'. True or false?

Mostly true. There is some slight metadata leak such as time, but this is as little information leaked as reasonably possible. It's not 100% perfect, but it's the best tool available and would make attacks incredibly difficult.

  (*) If the answer to #3 is true, then is there any anonymity or security benefit to running a full I2P node VERSUS connecting to a remote I2P node over I2P? This is a big question so I'll tip some fraction of Monero or maybe whole Monero for the first expert who gives the comprehensive list of current attacks (including 'combined with other info' type stuff), and bonus for simple ways to avoid and eta of plug. I appreciate considering likely or known current conditions like, there probably aren't many I2P nodes, and probably even fewer bridge nodes. Even better if you also consider attacks to I2P itself ([https://geti2p.net/en/docs/how/threat-model] - note I understand almost none of this page, write out the details of the attack for others to see and argue, but please include a tldr...ty)

Yes, there is a major security difference between using your own node compared to using someone else's node, including over I2P. This remote node will get certain metadata information: the time, what blocks you are requesting, etc. They will not get the most important leak which is your IP address, but the amount of metadata leaked is nontrivial. A local full node over I2P provides more privacy than a remote node, period.

  (*) How can I set a full Monero node in I2P? I already did the I2P part, and I know how to google standard stuff that a million other people ask. I can google and copy-paste, basically.

Until Kovri supports Monero directly, it is unreasonable for most people to run full nodes exclusively through I2P, since it will be difficult or perhaps impossible for you to find other nodes to sync to. If you want better privacy than what is currently available, I suggest instead running a node through Tor, since Tor has significantly better connections to the clearnet than I2P.