If you define a replay attack as sending a tx to two different forks, and the tx being mined on both, then it is necessarily allowed, otherwise deep reorgs would not be possible, and they are possible, and have happened.

Network wide, one way to prevent this would be to tag a tx with the hash of a block which must be in the history of the block containing that tx. This way, you could tag your tx with a block which is on the fork you're spending on. The other fork could not mine that tx (assuming the miners there don't decide to start ignoring that rule). Such tagged hash information looks like it'd be prunable after a while.

If the network doesn't have any particular replay protection, and as a user you want to ensure your coins aren't replayed on another fork, I think moving your coins may not be enough for 100% certainty, as the other fork might also replay the tx which moved those coins, leaving your coins in the same state on both forks. However, it seems safe to assume the two chains will be different in their output set: in that case, it looks like moving your coins while referencing one fake output which does not exist on the other chain would work: the tx will not be valid on the other chain. I speculate that once the output set diverges, most transactions become automatically invalid on the other chain as they become more and more likely to include this-chain-only outputs as their fake outs.


Monero wallet password - recovery of wallet and XMR

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


Format of QR code URI scheme to add a Payment ID and do monero mobile wallets read it?

The URI format is described in https://github.com/monero-project/monero/wiki/URI-Formatting.

In particular, a monero payment URI with a payment ID would use the tx_payment_id parameter, like this:

monero:4xxxxxx?tx_payment_id=1234567812345678123456781234567812345678123456781234567812345678

If you want to try things, out, the Monero GUI wallet allows you to autoamtically generate QR codes based on the payment ID and amount you give.

The Monero GUI wallet supports reading those, but I don't have information on which other wallets currently support them. I suspect most do. monero-wallet-cli, while not a mobile wallet, has a patch to handle them which is soon to be merged.

Note that Monero now supports subaddresses, which allow you to have an address per customer without having to deal with separate payment IDs (however, not all wallets support sending to these yet).


I'm guessing this refers to the "mass social engineering" attack where people are "paid" to use their Monero keys against the network. If you can get enough people to "de-anonymize" their transactions, the remaining anonymity pool decreases.

It works like this:

someone forks monero, and sets their starting chain to be a copy of the existing monero chain
that person tells others that they are now the owners of coins on that new chain (due to copying the original monero chain)
the only way to use these coins is by using your monero keys (again, due to copying the original monero chain)

The clever part is that the fork is worth nothing, but psychology will likely make people think it is worth something, so some fraction of Monero users will then use it, most likely to dump on an exchange, assuming anyone wants to buy it.

So far, so good. The trick is that if you send an existing monero output on both chains after the fork, it will create two rings for that output. These rings can either be different (if each software selects a random one), or the same (if each software reuses the first ring to be made). In the first case, you end up with two different things with one output in common, which means this is the real spent output. In the second case, no extra info can be deduced and you're safe.

So this will expose the real spent output in your transaction. If enough people do this, then this exposes more outouts as being spent. In turn, an observer can make deductions to decrease the effective ring size of other transactions using this output in rings. If enough people do this, this can have an effect on overall ring signature strength in the network.

The other two protection mechanisms (stealth addressing and ring confidential transactions) are unaffected by this.

Current Monero includes a shared ring database where it stores used rings, so you should always end up in the second case and be safe. However, if you use the same keys on two different computers/VMs, then you'll need to tell Monero (or the other fork) about used rings so they can be reused (see How can individuals safeguard themselves and the community against a key reusing fork? for details).

So this was a problem till recently, but the Monero team added this shared ring database to counter that attack. Someone forking Monero and trying this again might remove this safety protocol, but then it'd be pretty obvious they're attacking the network, and not just being dumb.

Now, this all relies on people thinking the fork created money and they can claim it by reusing their keys this way. However, the forkers will never pay you any money. Where does this "new" money come from then ? It just comes from others who think that fork might have value and buy these coins. It's just smoke and mirrors.

So, in short, this "airdrop attack" is a clever social manipulation to make people think they can get money by sabotaging themselves, and the Monero network as a result, and Monero now has automated defenses against it. If succesful at scale, this can decrease the strength of ring signatures on the whole network, but does not impact stealth addressing nor confidential transactions, the other two privacy layers in Monero.


What is the total supply of Monero and when will it be finished mining?

From Wiki it says around 18.4 Million at the end of May 2022. However,  tail emission will kick in after that which is 0.6 XMR, so it has no fixed limit.

  Its main emission curve will issue about 18.4 million coins to be mined in approximately 8 years.  (more precisely 18.132 Million coins by ca. end of May 2022[) After that, a constant "tail emission" of 0.6 XMR per 2-minutes block (modified from initially equivalent 0.3 XMR per 1-minute block) will create a sub-1% perpetual inflatio starting with 0.87% yearly inflation around May 2022) to prevent the lack of incentives for miners once a currency is not mineable anymore

From https://moneroblocks.info/, current emisssion is

14,445,846


yes that will work. if you have the source code still, you can try

  make uninstall

or

  sudo make uninstall

from inside the source code directory. check out https://askubuntu.com/a/87112/610029


Can someone show an actual example of a Monero transaction that uses two distinct private keys?

In Monero, every output has a one-time (unique) public key. No output on the blockchain can be associated with any particular wallet address because these output public keys are not the same as your wallet's public keys.

Outputs can be spent if there is knowledge of the one-time private key that corresponds to the output's one-time public key.

Therefore, a transaction that spends two outputs that were sent to the same wallet address is indistinguishable from a transaction that spends two outputs that were sent to two different wallet addresses, because all that needs to be known are the one-time private keys corresponding to the outputs you want to spend.

The code for scanning for incoming outputs and for constructing a transaction is very long and complicated. The summary is that an output is detected as being yours by calculating P' = Hs(aR)G + B where a is your private view key, B is your public spend key, R is the transaction public key published with each transaction and G is the Elliptic Curve base point. You check P' against each output P on the blockchain and if there is a match, then that output is destined for you. The private key that allows you to spend this output is x = Hs(aR) + b where b is your private spend key.

Once you have the private keys for both of the outputs, you can spend them as usual in a transaction as if both of them were your own outputs. This involves constructing a transaction data structure with its own transaction public key, creating new outputs for the recipient based on the recipient's wallet address, creating a ring signature to obscure the source inputs, using Pedersen commitments to prove no Monero were created or destroyed in the transaction (because the amounts are encrypted and not publicly observable), and creating a range proof that demonstrates that no cheating is going on with the Pedersen commitments.

If you want to learn more, the best place to start is the Cryptonote white paper which will introduce you to how Monero transactions work https://cryptonote.org/whitepaper.pdf and the Monero Research Lab papers which detail how ring signatures and confidential transactions work https://lab.getmonero.org/


What is the difference between Monero (XMR) and Verge (XVG)?

Despite both being advertised as privacy-focused cryptocurrencies, they are very different.
Summary
Monero uses ring signatures, RingCT, and stealth addresses to hide information on the blockchain. For every transaction, there is no way for an outside observer to determine the sending address, the amount sent, or the receiving address. Optional transparency can be provided off-chain by giving the desired person(s) the view key. Monero can be used with Tor or I2P manually, and Kovri is being worked on to provide native anonymous routing functionality.
Verge began under the original name DogecoinDark. It uses the same exact technology as Bitcoin and Dogecoin on the blockchain. For every single transaction, the sending address, amount, and receiving address are all visible. Verge users can optionally use Tor to send transactions.
It is disputed whether DogecoinDark began as a fork of Dogecoin or of NovaCoin/Peercoin.
Impact
Let's walk through a few use-case situations to compare how these coins protect the privacy and security of users.
Situation 1: Bob buys cryptocurrency on an exchange. Suppose this exchange complies with all local legal regulations and collects significant information about its users, including their address, IP address, name, and social security number.
With Monero, you can send coins off the exchange. The exchange knows what address you send the funds to, but it does not know how much money is in the address, and it does not know where the money will be spent in the future. Once it leaves their possession, the exchange doesn't know anything about it.
With Verge, the exchange knows what wallet you withdraw the money to, and it knows the balance of the account. It knows every other transaction involving this address in the past and in the future. It can track the funds sent throughout every address the funds touch forever.
Situation 2: Alice deposits cryptocurrency on an exchange. Suppose this exchange collects information as mentioned before.
With Monero, the exchange does not know what address the funds came from, and it does not know what this money was previously used for. It does not know the balance of this address.
With Verge, the exchange knows the address the money is coming from, the address's balance, and every transaction this address is associated with in the past and in the future. It can track the funds sent to the exchange throughout their past to learn exactly how they were transferred between different addresses.
Situation 3: Charlie buys coffee with cryptocurrency at a local shop.
With Monero, the shop owner does not know what address the funds came from, and it does not know what this money was previously used for. It does not know the balance of this address.
With Verge, the shop owner knows the balance of the address, and it knows how this money was previously used. The shop can audit the incoming funds to determine if they are "clean" or "tainted"; they can refuse payment of "tainted" funds or charge a higher rate. The shop owner can attempt to charge a wealthy customer more and threaten to steal their funds. It knows if this address is used in the future.
Situation 4: Dan receives payment from a stranger.
With Monero, Dan does not know the address of the stranger. The stranger knows Dan's address. Dan and the stranger do not know anything about their transaction history.
With Verge, Dan knows the address and balance of the stranger. The stranger knows the address and balance of Dan. They each know all transactions made with these accounts, including any possible transactions in the future.
A Note About IP Address Obfuscation
Tor and I2P can be used by pretty much any cryptocurrency, including Bitcoin and Monero. You do not need to use a separate coin to receive the benefits of routing traffic through Tor. These are separate things.
The IP address of a transaction is never stored on the blockchain. It is only leaked as metadata to nodes that you are connected to. For instance, suppose Alice runs a full node and sends a transaction. Suppose she is connected to 8 of 1000 nodes on the network. Only these 8 nodes receive her IP address, and they do not know for certain that they were the first to receive the transaction request. There is still a level of uncertainty.
Hiding an IP address is not nearly enough to have privacy. It must be combined with an obfuscated blockchain. If a user had to choose one over the other, they should prefer an obfuscated blockchain, since the blockchain information is shown to the entire network and stored forever.
A Note About the "Wraith Protocol"
Verge has been advertising the including of the "wraith protocol" in their coin for some time now. The "wraith protocol" is a rebrand of stealth addresses used in Monero and other CryptoNote coins. It has not yet been implemented.
Monero and other CryptoNote coins have had mandatory stealth addresses for their entire histories. Verge plans to make this feature optional, and NOT include other features such as ring signatures or confidential transactions.
This feature only really works if everyone uses it. It offers little to no protection if only a small fraction of people actually use it. The majority of the blockchain will still be completely transparent, which means there will be little or no privacy protection for those using the "wraith protocol."


Yes, since Z3735F has x86_64 instruction set.

But there is no AES so you will get a very small hash rate, and considering its design, it will probably overheat, so most probably not worth it.


Use XMRig, connect it to supportxmr

You can use https://xmrig.com/wizard to create your config file.

Good luck


Can I mine with more than one client on a given mining pool?

Nothing special to do if you're pool mining. Most pools just use your address as your "account name" and don't care if one device or 100 are mining to that address. As an example, some miners periodically point their miner to the Dev's donation address as a way to contribute.

A small caveat... it could be best to pick one pool and devote all your resources to that pool. The reason being that you build up your mining shares quicker and thus get your payout quicker (most pools have a 0.3 to 1.0 XMR minimum payout which could take a few days for small miners to achieve). On the flip side, you can probably even out your luck by mining to multiple pools... if one gets lucky and the other unlucky, you will get paid more in proportion to what you probably expected.


CoinHive javascript doesn't seem to work

Your browser might be blocking it, unfortunately some people abused this miner that is a great alternative to ads in my opinion however didn't inform users to this occurring leading to some browsers blocking the miner.

Source: https://www.wired.com/story/cryptojacking-cryptocurrency-mining-browser/

Archived link: https://web.archive.org/web/20171229133832/https://www.wired.com/story/cryptojacking-cryptocurrency-mining-browser/


Why not, on the next Monero fork upgrade, start fresh with balances intact?

Technically, you could create a new snapshot that would be smaller than the current chain, but not necessarily by much.  Remember, there are a few very important qualities of a blockchain (and Monero's, in particular) that you would likely not want to overlook when considering a snapshot.

The only outputs you could remove from the chain would be provably spent outputs. There are some pre-RingCT outputs and very, very few post-RingCT that eventually were proven to be spent. The vast majority of outputs are not provably spent (otherwise Monero would be much less appealing as a "privacy coin").
There is proof of work in every block that goes into creating every subsequent block. The proof of work is the only reason we rely on the chain as a source of proof. As a result, only so much data is able to be pruned.  And even though pruning some data is possible, pruning is something that only safely happens once a lot of POW is stacked on top.

Okay, so you can prune some data and have a "new" - yet still pretty big - snapshot.  Then there are the logistics of the snapshot.  If you shouldn't prune recent data, then what should you prune?  How far back do you go?  People might disagree on that. Due to the disagreement, maybe there would be multiple implementations of the snapshot resulting in multiple forks (perhaps at least two forks, the second being the original chain for folks who didn't want to do a snapshot in the first place). It's a gamble that the miners would follow and the community would remain intact.

Changing gears... It has already been mentioned that the ability to prune the existing chain has recently been coded up and is coming soon.  As a rough, easy-to-remember estimate, the blockchain on a full node could be shrunk from 60 GB to 20 GB.  Note that the pruning is implemented in such a way that the pruned data isn't permanently destroyed.  Rather, each node that enables pruning retains 1/8th of prunable data; and with a robust network of full nodes each holding a random 1/8th, the network will collectively retain all data required to reconstruct a full, "original" blockchain.

The pruning method that is coming soon™ already works.  Aside from the fact that it does not prune provably spent outputs, its pro/con ratio arguably outweighs the pro/con ratio of the snapshot method, not only because it's ready (aside from further testing), but also because it is not inherently contentious like a snapshot of the Monero blockchain might be.


XMR-stack optimization. beginner troubles

Thats about right per: http://monerobenchmarks.info/searchCPU.php

CPU MODEL              HASHRATE         APP         PARAM       OS          TDP         Date
INTEL CORE I7 4720HQ    110 H/s      MINERGATE 7.2  N/A     WINDOWS 10 x64  43 W    Jan, 2018.


Technical questions about addresses and keys

That's almost right. Due to specifics of underlying elliptic cryptography, the biggest private key is l-1, where  l is defined in the CN whitepaper as:

l = 2^252 + 27742317777372353535851937790883648493

Anything bigger than that will get wrapped around by performing mod l operation so you'll always end up with a private key below l.

Also, private view key doesn't have to be deterministic and you could generate it independently. It's more practical to derive it from the private spend key, though.

No limits. You can represent any 256 bit number with the mnemonic and vice versa. The mnemonic scheme is an encoding. It's really the same number but in different base (1626) where each "digit" is represented by a word from the dictionary. The last word is a checksum so the mnemonic also had some error-checking integrated.


How do "Time Locked Proof of Non-ASIC work challenge reward" algorithms work to deter ASIC production?

The idea behind this draft is more like an extension to PoW changes like currently to prevent ASICs overtaking a serious amount of hash rate.

However, it's proposing to time lock all mining rewards during a full period of time where one algorithm is active, between two PoW hard forks and release them only after another challenge period which might be 1-3 months only to miners who keep up their average hash rate after a PoW hard fork to a changed algorithm.

From my knowledge there are no other coins which have implemented a similar solution yet.

ASIC manufacturers would have to prove immediately after a PoW changing hard fork that they can keep up their average hash rate, otherwise they will loose all rewards locked within the last PoW duration which is now considered to be 6 months or maybe will be lowered to 3 months. So an ASIC miner would have just 2-4 weeks between final PoW algorithm code merge until the fork to create a new ASIC or would have to rent large amounts of hash rate to match their previously ASIC based hash rate in order not to loose all mined but time locked coins.

However, there are several draw backs in this proposal.

Every single miner would have to wait to get mining rewards for a whole PoW period plus the challenge period where you already have to pay for your hardware and electricity
Freshly mined coins wouldn't be distributed evenly but only after every PoW plus challenge period and might lead to a lack of coin supply for months and then a huge wave at once being distributed after a finished challenge period
The whole process is pretty complicated, especially the time-locking of funds and the penalty system when someone doesn't meet his previous hash rate in the challenge period and his rewards would have to be distributed among all legit miners
Legit CPU/GPU miners might run their mining software just during idle times and might miss their challenge losing all their already minted rewards. Also failing to upgrade your mining software immediately after a fork brings you at that risk so only somehow professionally operating CPU/GPU miners would survive


How do I make a monerod RPC call in Python? (e.g. /get_transactions)

You are so very close.

Just change params = PARAMS to json = PARAMS and it will work.

From the requests documentation:

  Using the json parameter in the request will change the Content-Type in the header to application/json.

And to get the response text, use:

print(myTransactions.text)

Or to get the response as a json object:

print(myTransactions.json())


Setting up script to decode and check transactions

To answer your specific questions:

The example code you posted is not handling subaddresses. It is not even correctly parsing tx_extra.
xor8(e, keccak("amount"||Hs(8aR||i)) where a is the private view key, R is the tx public key, i is the output index, Hs is hash to scalar and xor8 will XOR the first 8 bytes of each parameter.
I'm unsure what you would want to "sanity" check. If a transaction is on the blockchain, it is valid. Whether or not it's yours or pays the correct amount to you is a different matter.
https://github.com/mymonero

As @knaccc points out in his comment though, "It makes no sense to try and reimplement wallet functionality yourself". You really should just run the monero-wallet-rpc if you need to programmatically check/make transactions - that is precisely what it is built for, it is part of the official releases and therefore will always stay current and work.


Can't get Biostar TB250 motherboard to recognise RX Vega 64 GPU for Monero mining

I'm running Ubuntu

Have you tried with Windows? I haven't checked in a while, but I last heard that mining on Vega 56 and 64 yield better hashrates on Win at the moment, until AMD releases proper (?) blockchain drivers for aforementioned cards in Linux.
I would suggest you try that first, and if it isn't detected in the Device Manager, look into returning it.

Hope this helps!


How can one solo-mine Monero using their laptop?

You can solo-mine with either the command line daemon or wallet (monerod/monero-wallet-cli with the start_mining command) or using the GUI (instructions). The same applies to whichever operating system you use.


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

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

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


Cold wallet - got the 1 and L mixed up in private view key

You can download and use the monero-wallet-cli to recover your wallet (and hence the keys) from your seed. See here

You can also use sites like this to generate the view key using seed or spend key. Although the site performs the operation locally (you can disconnect the internet when doing it) i still recommend against it for security reasons


List of transaction hashes in chronological order?

You can use get_block which includes includes the tx hashes (tx_hashes) in that block. You can then use get_transactions if you need further details on the transactions.


Run monero-wallet-rpc in background in Ubuntu?

If you can't find a flag and you run linux, you can use the usual way of sending an application to the background.

Start the application in the background:

./monero-wallet-rpc &

Additionally, don't show output on the terminal:

./monero-wallet-rpc > /dev/null 2>&1 &

If you connect via ssh to launch the application, it will exit when you close the ssh session - you can use nohup to keep the application running after the ssh session is closed (the first command will put the output in nohup.out, the second will ignore the output):

nohup ./monero-wallet-rpc &
nohup ./monero-wallet-rpc > /dev/null 2>&1 &


How does the "--check-updates" parameter of monerod work?

The --check-updates option has four subcommands:

update     subcommands: check (check if an update is available), download (download it if there is), update (not implemented)

check: check for updates, but do nothing beyond printing a notification
download: download any update
update: run the newly updated version

The last one is not implemented yet, only the first three are at the moment.

When you run status, the "up to date" comment does not refer to whether a new version is available: it relies on the timing of last known fork to determine whether there should be an update by the current time. It could be replaced with the new --check-updates method, now that it exists. Feel free to open a bug on https://github.com/monero-project/monero/issues mentioning that fact, and pros and cons may be discussed there.


Why are coinbase transactions locked for 60 blocks?

As far as I understand, this is to make sure that the coins were mined on the longest blockchain, and thus the longer "delay" of 60 blocks is meant as a safeguard against transactions becoming invalid because of blockchain reorganizations. These might change several dozens of blocks sometimes.

While 60 blocks should typically be enough, I have seen some larger blockchain reorgs on testnet. So, if you were to spend mining rewards of blocks that would later become invalid, that transaction would also be invalidated.


monerov windows wallet gui.exe showing up as Trojan

Because you can mine MoneroV with it and that is considered a malware by antivirus software. Monero has the same problem (MoneroV wallet is a clone of the Monero wallet).

Other mining software have the same issue. For example XMRig shows up also as a malware.


Initial blockchain sync fails with message: [P2P6]Attempt to get hash from height 787402 failed -- hash not in db

The issue ended up being a bad stick of RAM.  I removed the memory and the problem went away.


We could scale to having very large blocks which could lead to it being prohibitively expensive to run a node.  We might be left with a situation of concentration of nodes/ mining.


This annotated whitepaper acknowledges the importance of a thorough review:

Constructing a hash function is difficult; constructing a hash function satisfying these constraints seems to be more difficult. This paper seems to have no explanation of the actual hashing algorithm CryptoNight.
Nic van Saberhagen describes loosely some properties of a proof of work algorithm, without actually describing that algorithm. The CryptoNight algorithm itself will REQUIRE a deep analysis.

According to Monero Core Developer Smooth:

CryptoNight (and the code implementing it) was extensively reviewed, though not as part of a "formal" review process, by Professor David Andersen (known as 'dga' in crypto circles) who also wrote the current implementation of the hashing code. He found nothing wrong with the design and largely praised it, stating that it would likely achieve its goals of resisting extreme optimizations and narrowing (but not eliminating) the performance gap between CPUs, GPUs, and ASICs.
I have seen hints (mostly in the form of offhand comments) that other experts have reviewed without finding problems, or at least no major problems, but that is not a formal review, especially if they don't publish their results.

Monero Research Lab helps to identify problems and find solutions. Currently they have higher priority matters than spending more time focusing on CryptoNight:

As of this writing, the algorithm employed for difficulty adjustment in the CryptoNote reference code is known by the Monero Research Lab to be flawed. We describe and illustrate the nature of the flaw and recommend a solution. By dishonestly reporting timestamps, attackers can gain disproportionate control over network difficulty.  We verify this route of attack by auditing the CryptoNote reference difficulty adjustment code, which, we reimplement in the Python programming language.  We use a stochastic model of blockchain growth to test the CryptoNote reference difficulty formula against the more traditional Bitcoin difficulty formula. This allows us to test our difficulty formula against various hash rate scenarios.


How to send a raw transaction directly without sanity checks

Look into /sendrawtransaction API call. Dev Guide


What are hardware requirements to run a small mining pool?

I use a server at home and it is an old Power Edge 2950 (2 x duel quad core Xeons and 32gb RAM).  I am running UBUNTU 14.04 LTS and it seems to run the daemon, wallet, and front end via Apache2 pretty well. I haven't had a bunch of traffic on it yet because it is still in the testing phase and it is like pulling teeth finding miners to connect and hash to test everything out but it seems stable.  I would think a quad core or better processor and at least 8 gb of RAM would be a pretty minimum requirement.  Anything else would be a bonus unless you are planning on having hundreds/thousands connect in which case a VPS or upgrading to a newer hardware setip (perhaps with a Gb switch) would be warranted.


Is transaction malleability an issue with Monero?

At section 4.3.3 of One-Time Ring Signatures in the MRL-003 it is specified how the Monero network protect itself from transaction malleability (invalidating attempts of forcing invalid data in the key set).

I don't think Monero is completely immune since someone could create a bad client exploiting the protocol and with enough users using it the network could become vulnerable, this is a plausible scenario but very unlikely, hence why its important users download binaries and/or compile the source code only from the official getmonero.org website or the github.


Changing IP tables for Monero on Tails returns error

You are missing a newline character between ACCEPT and DNS_PUBLIC.

The iptables rule addition is the command:

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

And the subsequent command:

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


What takes the most computing time in a monero wallet?

The two main operations in terms of CPU usage are determining if an output is sent to you (is_out_to_acc_precomp, defined in src/cryptonote_basic/cryptonote_format_utils.cpp) and generating the key derivations that is_out_to_acc_precomp acts on (generate_key_derivation, defined in src/crypto/crypto.cpp). There is some threading there, but it could still be sped up.

Both of those end up calling low level crypto functions, such that a profile looks like this:

  18.00%  monero-wallet-cli          [.] fe_sq
  17.54%  monero-wallet-cli          [.] fe_cmov
   3.21%  monero-wallet-cli          [.] fe_invert
   3.08%  monero-wallet-cli          [.] fe_divpowm1
   2.86%  monero-wallet-cli          [.] fe_sq2
   2.35%  monero-wallet-cli          [.] fe_add
   1.75%  monero-wallet-cli          [.] select
   1.62%  monero-wallet-cli          [.] keccakf
   1.16%  monero-wallet-cli          [.] ge_p2_dbl
   0.97%  monero-wallet-cli          [.] ge_scalarmult_base
   0.80%  monero-wallet-cli          [.] ge_scalarmult

There are a couple asm versions of those, which proved to give some substantial speedup too, see https://github.com/monero-project/monero/pull/2317


This was fixed by restarting the machine.


The instructions, simplified go like this (brackets indicate optional arguments):

transfer [<priority>] [<ring_size>] <address> <amount> [<payment_id>]

Your transfer command attempts a ring_size of 1. The default (and minimum) ring_size is 5.

If you want a priority of 1, it would be:

transfer unimportant <address> <amount> <payment_id>

Or, you would first set priority 1 to make all transfers unimportant (low fee),

then transfer <address> <amount> <payment_id>


Can you choose the mnemonic seed to create a wallet?

I was wondering if you can create a wallet by selecting these 25 words yourself and going from there.

Yes. But you actually select 24 words and compute the last one (25th is the checksum, and it will always be one of the 24 words of your seed mnemonic).

Your wallet is really defined by those first 24 words, and the last one is an extra which lets you check for errors when recovering or makes recovery easier if you lose a few words somehow.

  This would be cool because then people could pick more easily memorize their seed

It would (note that you'd need the correct dictionary to pick from), but I'd strongly advise against this. Human brain is horrible at producing randomness. You really should roll a random seed first, and then memorize it if you will. The generation should always be truly random.

  and also would allow people to create a wallet completely offline without any software.

You can do this with dice, here's a simple way:

Perform 4 rolls of 6-sided dice and calculate a number between 0 and 1295 like: WordIndex = 6 * 6 * 6 * (roll_1 - 1) + 6 * 6 * (roll_2 - 1) + 6 * (roll_3 - 1) + (roll_4 - 1).
Pick a corresponding word from the dictionary using the number above as index.
Repeat until you have 24 words.
Compute the 25th checksum word.

Note that it will have somewhat reduced entropy (it will be about 248 bits) because we're not using a part of the dictionary but that's not really a big deal. I was playing around with this a while ago and came up with this system to minimize entropy loss.

  Also, is the 25 word seed function specific to certain wallets or could you use those 25 words to recover a wallet on any wallet software...(i know mymonero.com uses only 12 words or at least used to)

It's a wallet convention thing, and any wallet can have its own if you will. The protocol doesn't care about mnemonic or seed. All you need protocol-wise is a private spend key and a private view key, where a private key is just some number smaller than l where l is a prime order of the EC curve basepoint l=2^252 + 27742317777372353535851937790883648493. Anything bigger than that will get wrapped around ie a and a+l are equivalent. There are 2 conventions in use (for now) and the 13-word one will be deprecated AFAIK.

This site, made by one developer from the core team (Luigi1111), has a great explanation on how the whole key derivation process works, and below text is taken from the site and formatted to suit SE:

Cryptonote Public Addresses differ in several ways compared to Bitcoin. First, Cryptonote uses two keypairs, known as the spend keypair and the view keypair. Furthermore, these keys are EdDSA (specifically ed25519) keys, whereas Bitcoin uses ECDSA (specifically secp256k1) keys. Finally, Cryptonote Public Addresses are direct representations of the pair of public keys, whereas Bitcoin (and clones) uses a hash of the single public key. EdDSA keys (both private and public) are 256 bits long, or 64 hexadecimal characters. Not every 256-bit integer is a valid EdDSA scalar (private key); it must be less than the "curve order". The function to do this is labeled sc_reduce32.

To add to the confusion, there are presently at least three different methods of private key derivation in existence for Monero (and other Cryptonotes), though Bitcoin also has many:

Original (non-deterministic) Style – The Private Spend Key and Private View Key are both independently and randomly chosen to form an account. You can simulate this above by pressing the "Random" buttons next to fields 3. and 4., then pressing "Gen 5.", "Gen 6.", and "Gen 7.", in that order. There is no good way to back up a non-deterministic account other than keeping copies of the files; you need to have a copy of both private keys, but presently only MyMonero will accept the two keys as input instead of a seed/wallet file. For these reasons, it is not recommended to use an account of this type.
Mnemonic (Electrum or Deterministic) Style – In this style, the Private View Key is derived from the Private Spend Key, so you only need to remember one thing: the seed, which is actually just a representation of the Private Spend Key itself. This 256-bit scalar can be easily converted to a "24-digit" Base1626 "number" in the form of a mnemonic seed, which is 25 words long with the last word being used as a checksum. Mnemonics convert on a ratio of 4:3 minimum: four bytes creates three words, plus one checksum word; eight bytes creates six words, plus one checksum word; and so on. The "seeds" created by this method will always be valid scalars as they are sent to sc_reduce32 first. The Private View Key is derived by hashing the Private Spend Key with Keccak-256, producing a second 256-bit integer, which is then sent to sc_reduce32. You can test out this style above by pressing the "Random" button on the upper right, or by pressing either of the "Random" buttons next to fields 1. and 2., then the various "Gen x." buttons. You can backup accounts of this type by writing down or otherwise saving the 25 word deterministic seed; you can easily restore using both Simplewallet and MyMonero.
MyMonero Style – This is similar to 2., but uses a 13 word seed instead of a 25 word seed. The 13 words convert to a 128-bit integer that is used for both spend and view key derivation, in the following form: the 128-bit integer is hashed with Keccak-256 to produce a 256-bit integer, a. a is sent to sc_reduce32, which returns the Private Spend Key. a is hashed once more with Keccak-256 to produce a second 256-bit integer, b. b is then sent to sc_reduce32, which returns the Private View Key. You may have noticed a critical difference between this style and the Electrum Style: MyMonero's Private View Key derivation is done by hashing random integer a, while Electrum Style derivation is done by hashing the Private Spend Key. This means that 13 and 25 word seeds are not compatible – it is not possible to create an Electrum Style seed (and account) that matches a MyMonero Style seed (and account) or vice versa; the view keypair will always be different. You can test out this style above with the "Random MyMonero" button. To backup MyMonero accounts, save the 13 word seed; you can currently "restore" using MyMonero only (you're really just logging in) – Simplewallet does not currently support 13-word seeds.

Also, inspecting that site's code will tell you a great deal about how it all works, if you understand JavaScript. For example, if we're interested in how exactly is the checksum derived, we must look at the code as the process is not explained on the site.

The relevant functions for conversions between seed and mnemonic are in the mnemonic.js file. If you're generating the seed by some other means, all you really need to do is compute the checksum to end up with a valid mnemonic.

function mn_get_checksum_index(words, prefix_len) {
    var trimmed_words = "";
    for (var i = 0; i < words.length; i++) {
        trimmed_words += words[i].slice(0, prefix_len);
    }
    var checksum = crc32.run(trimmed_words);
    var index = checksum % words.length;
    return index;
}

What that function does is: assemble a string of prefixes of each of your 24 words, run a CRC32 on that string and use the resulting number to pick a checksum word. The word is picked from one of the words found in your mnemonic.

For example, if we have the mnemonic:

skirting trash phase buckets apology gags sedan coffee vinegar else fifteen pitched idled gorilla siren cucumber urban junk vastness laboratory rift rhino situated taxi

The string which we feed to CRC32 will be:

skitraphabucapogagsedcofvinelsfifpitidlgorsircucurbjunvaslabrifrhisittax

and the result of CRC32 performed on it will be
1790087523.

Performing a mod on that number with the number of words in your checksummed data (24 in this case) will give you an index of the checksum word:

3.

So, the checksum is the 4th (note that index is 0-based) word of your mnemonic:

buckets.


Can my Monero Wallet be accessed from computer if the Wallet file name and password is known?

Your wallet file name is the name of a set of actual files on your PC. Your password is the key to decrypt (and thus use) said wallet files; it is not used as input for some sort of deterministically-generated account. An attacker would need both your wallet files and your password.

Thus, to access your wallet on a different PC, you'll need to copy over the wallet files (or restore the wallet using your seed).

  Without a key logger is there any way that someone could steal my XMR?

Yes. Key logging is only the most obvious way a remote attacker could compromise your wallet. If your question is more like: "Is there any way an attacker could brute-force my password and steal my XMR (without compromising my PC, etc)?", then the answer is no.


MoneroPulse is a DNS based system which regularly checks for a list of blockchain checkpoints stored in the DNS TXT record for a few monero domain names. This system allows emergency checkpoints to be set to mitigate an attack or accidental fork in the chain.

By default, this check is advisory (ie, you will get warnings if you are not on the chain that these records hold). The intent is to leave the choice to node administrators which chain they consider "the" chain, since those servers are under the core team's control. You can elect to have those checkpoints be authoritative by running bitmonerod with --enforce-dns-checkpoining instead. This is encouraged for nodes running unattended.

Several servers are used, and the code checks for both the chain of trust (if available via DNSSEC) and for differences in the records supplied by the DNS servers, to give some degree of resilience against attacks and network reliability issues.


Peers often report unknown top blocks. How can I find more reliable peers?

Having a partially synced chain does not mean unreliability. It might be that these nodes are syncing the chain, as you presumably did at some point too. Banning these nodes would mean noone can start using Monero, and would cause the network to die off from attrition.

In order to get incoming connections (currently none, as the 8+0 shows), you need to allow port 18080 through your router, to connect to the machine running the daemon. Firewalls and such must also allow this port. You will then get more peers (and thus a higher likelihood to get one that's got a full chain).


Monero Wallet GUI daemon version 0.16 stops syncing blockchain at block 2210016 both on Windows and Mac

If you want to actually use Monero you will have to update to v0.17 (which Ledger also supports).


Could proof-of-stake be implemented in a privacy coin, even in principle?

For Proof of Stake in e.g. Ethereum, someone that owns funds can become a "validator" by sending a special type of transaction that locks up their ether into a deposit. The process of creating and agreeing to new blocks is then done through a consensus algorithm that all current validators can participate in.

Monero already has a type of transaction, called a coinbase transaction, which produces an output with an unencrypted amount. This is necessary in order to verify that miners are creating new XMR at the consensus enforced inflation rate.

A new type type of transaction could be devised that did reveal the output amount in a similar way, in order to be eligible as a validator. Let's call such outputs VEOs (validator eligibility outputs). These VEO outputs would be clearly identifiable on the blockchain because they would be the only outputs created in non-coinbase transactions that also have non-encrypted output amounts.

It'd be important that such VEOs cannot be referenced as decoys in other transactions, because it'd be important that funds can be demonstrated to be parked as VEOs and not spent. Therefore a consensus rule would need to be written that required that when VEOs are referenced in a transaction, they can only be referenced by the owner of that VEO (i.e. no ring signature would be allowed for untraceability).

When the VEO is spent in a transaction (which would unpark the funds and remove that output's validator eligibility), a regular Monero output with an encrypted amount would be created, and so this new output could then be spent in the future with Monero's regular transaction value secrecy and untraceability features.

TL;DR: Yes.


unexpected error: Trezor returned failure: code=99, message=Firmware error

According to Trezor's CTO, the issue has been fixed in firmware v2.1.7:

  This is already fixed. Install firmware 2.1.7 from https://beta-wallet.trezor.io

Source: https://www.reddit.com/r/Monero/comments/dm0zqx/trezor_transaction_failure_code99_message/f4wia95/


Get transaction input ring members as public keys


Difference between Wallet Sync and Daemon Sync

Daemon status is how synced it's blockchain is. Wallet status is how many blocks are scanned.

A daemon syncs blocks, a wallet scans blocks for incoming transfers.


Can you determine the change transaction sent back to you?

There is no such thing as a "change transaction". A transaction has inputs and outputs. When a user sends funds to someone, any change is just destined to one of the transaction outputs. Only the sender can derive which output has any change and how much that output has, and yes, they would be using their view key.

Remember though, there may not actually be any "change". A user could spend all the input(s) to one or more destinations (outputs) that are not theirs, and thus no change output needs creating by the wallet.


Should I prune "From Scratch" or should I prune "From going forward", using the GUI version 0.17.1.9, and why?

Pruning is best done on the fly, as pruning an already synced blockchain is a very slow process - a lot slower than setting it to prune from the get go.
About the sync speed, using a spinning hard drive is a major source of slowdown. Monero just doesn't like slow hard drives, so if you have a SSD, it'd sync in hours rather than days. Once synced, the chain can be moved to a HDD where it'll keep up with the network.
As for the chain corrupting on an OS crash, it looks like a bug either in Monero or the OS/filesystem layer. Probably Monero, since there's been a number of such reports, but no known cause yet (and thus no fix).


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

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


The transaction was confirmed in block 1,281,619.  The monero probably remained locked for the typical 10 blocks, which is approximately a 20 minute wait time.  Once the 10 blocks passed, your monero was unlocked and was able to be spent.

If you don't see your monero in your wallet, then the node you're syncing to may not be fully synced.


What is the latest version of GUI: 0.12.2.0?

This reddit thread says it all: Official GUI build is still v0.12.0.0. The one on getmonero.org claims to be 0.12.2.0 but actually is still the old version. CLI build is up to date.

If you need latest GUI, build from source yourself. If you just need the daemon/monero-wallet-cli, official CLI build is (correctly) up to date.


Is the wallet address and generated account address the same?

Yes. A wallet starts life with one account (account index 0), which has one address (your primary wallet address).
A wallet has one or more accounts and accounts have one or more addresses.


If I'm solo mining from the GUI, am I still helping the Monero network even if I don't ever "win" any blocks?

It depends on what you call "helping" here. It will become apparent with an analogy:
Imagine Alice lost her wedding ring on the beach. She's distraught, and isn't sure where she lost it exactly, but wants to find it. She shouts "$100 to who finds my wedding ring", and some of the beachgoers nearby start looking.
Now, it's a small ring, there aren't that many people looking, the ring may have been covered by a layer of sand already, etc. Most people will not find the ring. Only one person will. call him Bob. if the search lasts long enough. But is only the person who finds the ring helping Alice ? If none of the people who don't find the ring had not searched, Bob would still have searched the same area and found the ring, but it was  not known in the first place that the ring was in the area where Bob ended up looking.
Now if Carol also loses her wedding ring on the beach and people start looking again, the same will happen: only one person will find it, but the more people look, the faster the ring will be found. So in that sense, everyone is helping speed up the search, even those who do not actually find any ring.


It really depends on your hardware and its bottlenecks.

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

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

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

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


This is a common issue on first configuration. You need to open any firewall on port 18081, and/or forward this port on your router. Otherwise, the connection attempt is rejected.

If you open your RPC to the external world, you may want to also use --restricted-rpc, which disables some RPC which could give the client too much information.


What does Shares/Diff number represent on pools found blocks

This is a proxy for "did we get lucky or not".

The shares numerator is the total number of weighted shares sent by miners trying to find the block. When you mine, you're asked to solve an easier problem on that block template (and if you solve it with a large enough gap, you find the block). When you find one of those "subblocks", you submit it to the pool, which accumulates the difficulties of the submitted shares. When a block is eventually found, that accumulated number is roughly proportional to the number of hashes the pool's miners have expended trying to find the block. So the shares numerator is a proxy for the total work done by the pool's miners.

The Diff denominator is the block's difficulty, which is proportional to the estimated number of hashes needed to find the block.

So the fraction represents how easily this block was found. If less than 1, you were lucky (it took less shares to find the block than expected). If more than 1, you were not (it took more shares to find the block than expected).


Number of confirmations and node location

Newly received coins can be spent after 10 confirmations.

I case two conflicting transactions are sent to the network by two clients managing the same wallet, the first to arrive at the node that will mine the next block will probably be considered as the valid one, and the other transaction will then be rejected.

Being connected to a faster node with faster connections to the other nodes will help broadcasting a transaction faster, but if the slower node happens to be connected directly to the node that mines the next block, its transaction will probably be confirmed and the faster node's transaction rejected.


What is the Monero Messaging System Used for?

It's a messaging system for nodes to talk to each other which would make multi-sig less burdensome on users. Users would no longer need to transfer transaction files over email for example, they would let their node talk to the other node directly.


According to the bottom of this CoinTelegraph article:

  The Jaxx team clarified that they halted work on Monero due to recent
  protocol changes that caused difficulties, and because the integration
  had gone significantly over time and budget, and was therefore
  hindering development for the 1.2 release.

There was a large divide in the community, and I speculate that Jaxx did not fully understand how to work with Monero. The protocol change they are likely referring to is RingCT, which they probably did not understand the large impact the change would have when they first began development. If you are interested in an approach for a project, c789 listed several resources in their post. Furthermore, I would suggest asking technical questions in the Monero StackExchange, community consenss questions in Reddit, and developer help in the #monero-dev IRC. While people will not write code for you, they can point you in the right direction.


Is the operating system changing the hashrate(when mining with cpu)?

If you are doing CPU and GPU mining you may get a slight hashrate increase running on a non-GUI desktop. The less work your graphics card(s) / CPU(s) are doing should increase hashrate a little, but I wouldn't expect anything drastic.


10.1 has a fix for RingCT. Changes have been made to 10.1 nodes to fork one block before 10.0 in order to avoid letting anyone use the flawed RingCT code, so Miners need to make sure they mine on 10.1 as they need to make sure they include the bugfixed RingCT transactions only, otherwise they will fork themselves off the network. The code changes that result in this is shown here

In short, the wallet software can be used until september 2017, but the node software MUST be upgraded (most importantly miners) otherwise the nodes running 10.0 or earlier will no longer be visible on the fixed chain.


Trying to better understand monero mining

Keccak is nearly SHA-3.

Taken from CryptoNoter

  SHA-3 is based on (a particular instanciation of) Keccak, but with a couple minor differences from the original Keccak. Cryptonote was made before SHA-3 standardization.
  - user36303


How does block time depend on number of transactions and block size?

Right now, it's basically a 1:1 relationship in the long term for a very basic reason. According to moneroblocks.info, there have been roughly 8100 transactions in the past week. Since there are 10080 minutes in a week, that means there have been approximately 8 transactions every 10 minutes.

I'm going to go out on a limb and say this have been a higher-volume week due to the big price spike and news, and use a smaller number of 5 transactions every 10 minutes for the rest of my answer. Why 5 every 10? Because for a two minute block size, that means 1 transaction every block on average.

The on average bit is important. Monero has a two minute block time, but blocks aren't always exactly 2 minutes... they just aim to average to be 2 minutes. Sometimes a block takes 10 seconds, other times it takes 10 minutes. And this is the whole crux of why longer blocks seem to have more transactions.

Basically, if we see a transaction on average every 2 minutes, and we get a number of 10 minute blocks, we should see approximately an average of 5 transactions in those long blocks. Likewise, if we see a number of 1 minute blocks, we should see approximately an average of 0.5 transactions per block.

Disclaimer

This is all based on the assumption that transactions are basically included in blocks right away. At very heavy usage times, we could see a backlog of transactions like Bitcoin has at times experienced, and as a result see a bunch of blocks in a row that all have similar large numbers of transactions regardless of how much time has passed. This gets muddied by the variable block limits in Monero, but is beyond the scope of this question.


Can a copy of the blockchain hold private information?

The blockchain itself will not (beyond its endianness), but some other files might: the logs, in particular, might contain paths specific to your computer (not saying they definitely will). The p2pstate.bin file will contain your node's peer id (though this is now reset on every restart), and may also leak information on the version of boost it was built with. That's all I can think of right now. No wallet information will be there (unless of course you chose to store your wallet there).


Blockchain is usually located in C:\ProgramData\bitmonero.

Wallet will be located wherever you started the CLI, or wherever you saved it with the GUI, if you ever made a wallet.

The wallet program will be in the folder into which you unpacked the .zip. There's no installation, you just start it from there. The only folder automatically created will be the C:\ProgramData\bitmonero one.


Wallet RPC (transfer): Empty Transaction Key (tx_key) received

Tx keys are stored in the wallet you use to make a transaction.

Tx keys cannot, however, be recovered if you restore a wallet from seed. If you have multiple wallets, only the wallet that you used to make the transaction will have a record of the tx key for that transaction (unless you have manually exported and imported those tx keys to the additional wallet).


These were likely bugs which are fixed on the current release-0.12 branch.
There should be a new 0.12.1.0 release in the next few days to a week, which will include these fixes.

See these:

https://github.com/monero-project/monero/pull/3719
https://github.com/monero-project/monero/pull/3776
https://github.com/monero-project/monero/pull/3788


Verifying an AEON transaction sent to cold storage

With stoffu’s rebased Aeon code, you could create a watch-only wallet with the view key, similar to Monero. Unless you also want to track outgoing transaction (which I think is unlikely for cold storage), this is quite a simple setup.


Calculate fee before sending while using RPC calls

Knowing the transaction fee in advance is not possible [1], due to two reasons:

the output selection is randomized, so sending, eg, 100 monero several times will potentially need different fees, for example if one tx needs just one 150 monero input (small tx, small fee), but a second attempt happens to pick many 1 or 2 monero inputs (larger tx, larger fee).
there is no RPC command to create a transaction without relaying it to the daemon.

It would be fairly simple to add a boolean to the transfer RPC to tell the wallet to return the signed transaction to the caller, instead of relaying it. The caller could then decide whether the fee is acceptable, and relay it to the daemon if so. This is a good candidate to add as a github issue on https://github.com/monero-project/bitmonero/issues. All the building blocks are pretty much there already.

[1] you can get a lower/high bound based on the wallet owned outputs, but that probably doesn't help here.


Best practices to keep Monero wallet secure

Here's my paranoid guide for keeping your wallet safe & secure:

  I have printed the seed

That might already have screwed you up depending on how your printer was connected to your PC. Writing down the seed is the preferred way imo; make sure to use a solid desk pad to avoid imprinting / engraving what you write to other materials below your paper wallet :) In addition to that you can create a steel "wallet" containing your seed, see https://cryptosteel.com/

  I'm using a read-only wallet on a computer connected to the Internet

That means this computer holds your private view key making it possible for hackers to see the amounts you're sending and receiving. Not too unlikely given that the computer is connected to the Internet. May I ask what the reason for this Internet-connected computer is? Why does it need to have view access to your wallet?

  I keep on a USB key the full wallet as cold storage

It might be worth creating an encrypted container on the USB stick, e.g. with TrueCrypt 7.1a or VeraCrypt. In addition to that, you can encrypt the wallet with GPG to have another fence in case TrueCrypt or VeraCrypt was backdoored. Make sure to only use these tools from a computer which will never be connected to networks, e.g. the Internet. Also you should have multiple backups of that USB stick at different places, preferably in different countries in a fire and water proof safe.

  a dedicated local server for the Monero node

Just to be sure this node (even if it's downloading the blockchain only) should do so through Tor via torsocks.

When creating your wallet, make sure to use a computer which will never be connected to any networks. Remove its harddrive and WiFi antenna. Make sure to use a good random number generator, how to ensure that? I don't know. Use an open source OS, e.g. Debian or Tails. Only download software from trustworthy sources and verify its integrity.

I recommend to split your balance across multiple wallets; even if you somehow lose access to one (maybe due to hackers, robbers, etc.) you have still access to your other funds.


How would Monero verify transactions on a 2-way pegged sidechain?

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


How does RingCT increase in transaction sizes affect people?

Currently, it only affect fees, which are a little higher. In term of disk space, it is  negligible (current blockchain size is ~10GB).

The little overhead for network traffic should largely be compensated by fluffy blocks.

Blockchain size is only one factor. What affects people who run a full node is CONOP.


Has RingCT been reviewed by the other Monero Research Lab members?

Yes absolutely. It wasn't designed in isolation, it was a group effort with members of the Core Team and the MRL involved. Since Shen did the bulk of the work, and was responsible for much of the innovative cryptography, he is the primary author on the research bulletin. You'll notice, however, that Adam Mackenzie and the Monero Core Team are also listed as authors on the research bulletin:)


Will a large and sustained increase in Monero transactions resolve the current issues of the dynamic block size penalty function?

Maybe it would.

In theory, to smoothly function as "originally intended" would mean the median block size would somehow have to grow to the point where one TX is 1.2% of the median, which translates to a block size of roughly 1250kB (15kB being a safe size to fit a "typical" transactions). The magnitude would then be around 2500TX/hour or 0.7TX/s. It's a long way to reach that level of adoption.

However, one needs to be careful when evaluating such things, because in practice we could see something entirely different.

The 1.2% is a direct consequence of arbitrary constants chosen in the current min. fee formula. If it was chosen such that it's, for example, 2.4% then the tipping point would be at 625kB but the min. fee would be double then what it is now.

I'd say it would happen way sooner because external factors such as market price and user willingness to pay some fee also have an impact on this. For example, currently you need around x20 min. fee multiplier to start the dynamic process. If everyone offered the x20 fee, then it would be viable for the miners to start expanding blocks for 20%, which is just enough to squeeze in one TX at 60kB median, 2 TX-es at 120kB median and so on. Note that with current prices that would mean everyone is willing to offer around 5$ to place a single TX! If it meant 0.3$, then we probably wouldn't be talking about this problem right now :)

For example, if we consider 0.3$ as some fee which everyone is willing to pay by default, and model with a flat market price, the tipping point where 0.3$ gets you 1 TX more is at about 280kB block size, as seen in the chart below:

Note: W_0 = 101.2%, W_T= (15kB) / (median block size) + 1.

But what if the price also grows? Then we could end up having the same problem all over again. Long-term, if the price should raise with block size slower than linear, then it's likely we will never have this problem again in the future. It's just getting out of the trench which seems hard, and this trench shouldn't have been there in the first place!

So it's not just the formulas which could help as dropping the market price 20-fold would also fix the problem. One could argue that if the network gets clogged and the price drops as a consequence the problem would fix itself.

But I digress. If there was a consistent stream of TX-es coming in, then even with the current set-up the block size would be able to creep up slowly until it crosses over some point where the min. fee would drop so the users are willing to use higher multipliers. One could argue that was not the intended way the system should work and that at any given moment some would be willing to use at least some lower multipliers. Problem is that right now anything <20x does nothing of significance, because of the TX size issue. The dynamic block size is really there to accommodate some peak usage times and not have to wait days for backlog to be cleared.

Thing is, the RCT HF introduced bigger TX-es but did nothing to address these dynamics at the same time. I understand that there was the thought that people would still be using non-RCT TX-es which would alleviate the problem but the reality is that more than 99% of TX-es are RCT even though it's not mandatory!

At the end, we see that it's also about the price of min. fee at which miners can do something. The current min. fee gives no incentive to miners to do anything because of the TX size issue and yet it could already be considered pricey. Nobody wants to pay x20 the min. fee and make miners do something because the min. fee is high enough by itself. So really, there are many aspects to this and many possible solutions. We'd want to pick the one which would let us forget about the problem forever :) However, as the project is still in some early stage, these kind of details must be worked out and evaluated as we go on. The only worthwhile data which could be used as a guideline is the one for Bitcoin, and Bitcoin is also in some early stage, having its own problems and trying to work them out.


I just sent 6.9 Monero from MyMonero, but it showed up as taking 10xmr out of my account instead of 6.9.

What you described was not a mistake. It is related to how ring signatures are created and how you as the sender also are a recipient of some of the outputs.

This related question explains why your issue resolved itself:

  Once the transaction is confirmed the change is returned to your wallet. Change like all incoming transactions is unlocked after 10 blocks.

This change issue is not specific to MyMonero.com. It applies to simplewallet the same way.


What is the difference between CryptoNote and CryptoNight?

CryptoNote is the name of the cryptocurrency technology that Monero (and Aeon, and various others) is based on. CryptoNight is the name of the hash function that is used in the CryptoNote Proof-of-Work algorithm. CryptoNight-Lite is a modification of CryptoNight that uses half as much memory and fewer hash rounds, used in Aeon.


blockchain_import fails, "Transaction has too many dirty pages - transaction too big"

It appears that you're using a 32bit build. This was a known bug in the 32bit LMDB code, Issue #855, fixed on August 11 in commit 7442dd084acfcef571c51f53277247c050d1c98b.


Minimum and maximun number of mixin right now?

Ring-size is now fixed at 11. So, 10 decoys (mixins) and 1 real.


Claymore Mining (CANNOT ALLOCATE MEMORY)

This sounds like you have not enabled huge pages on Windows 10. You can follow the directions on my website: https://www.cryptocurrencyfreak.com/2017/08/29/monero-mining-xmr-stak-cpu-windows-10/ at the end of the article to enable huge pages.

I also recommend giving xmr-stak-cpu a try. I have always had better luck with it than Claymore.


Is it possible to add coins to a wallet that were never mined?

It must be impossible. The underlying math is such that it is provably impossible. So no, it's not theoretically possible. Theoretical possibility would mean a broken coin.

I could imagine 2 ways to create coins in a TX:

Successfully double-spend the same output. However, this is not possible because of the key images mechanism.
Cheat the sum(in) == sum(out) equation, and make an output of greater amount than you have the 'right' to. However, this is not possible because of Pedersen commitment and range proofs.


What is the reason why its so hard to implement Monero into current wallets?

Monero has a completely different code-base than Bitcoin. It was not inherited from Bitcoin, and it was written from scratch (Bytecoin was the first CryptoNote cryptocurrency, and Monero inherited that codebase, not Bitcoin's - it's a fork of Bytecoin)

Thing is, all Bitcoin clones can simply copy what's already been done and maybe do some small tweaks. On the other hand, people working to implement Monero are pioneers. It doesn't mean that it's harder, but just that it requires work whereas for Bitcoin most of the work has already been done and can be re-used.

Also, due to mechanics of CryptoNote coins, any light-wallet implementation requires more resources on the back-end. Where Bitcoin can simply look-up the balance, Monero has to scan the entire blockchain.


There is an offline wallet generator for Aeon here: https://bitcointalk.org/index.php?topic=641696.msg17660358#msg17660358

This is the same as the Monero one, but adapted for Aeon. The post above says it's new and you should make sure you can restore your address before trusting an address/keys set made with the generator, just in case, but the Monero version has been working well.


I assume you mean 0.14.0.x. If so, it will continue syncing part of the chain only. To sync the entirety of the chain, you need at least 0.16.x.y, but 0.17.x.y is strongly recommended, since in about a month (mid october 2020), 0.16.x.y will stop syncing too.
The 0.17.x.y daemon is available on getmonero.org as binaries for Mac if needed.


Origin of the background image of MyMonero

According to fluffypony:

  it was just a stock image that looked cool:)


Not in the US or EU jurisdictions. We're not bound by the name in any event:)


Number of private keys that have been used on the Monero network

No, or it'd be a break of the crypto.
Poloniex can probably get a lower bound (probably much lower than the real number), since it's the main Monero exchange and has been for a long time. But from the blockchain, no. Every single output on the blockchain is on its own one time address, and can't be attached to a standard address without that standard address' private view key.


You can use the sweep_all command. It will send the full balance, minus the fee needed for that transaction. For example:

sweep_all 4aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

See help in monero-wallet-cli for full command syntax.


Can a message be encrypted with a Monero address and then decrypted by the address's owner?

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


Is Monero's wallet creation truly random?

Monero uses a Keccak based PRNG. I believe this is one that was proposed by the team behind Keccak, though I am not 100% certain. The seeding is done from /dev/urandom (or, for Windows, some Windows specific API). There is no reseeding, but the Keccak construction is rated for LOTS of random numbers before reseeding is needed.

See "Sponge-based pseudo-random number generators" by Bertoni et al. I can't recall where I got it from, but it might be keccak.noekeon.org, though I can't see it there at first glance.

It would be nice if someone reviewed that code to make sure it really is the same construction.


If you get this error, then you probably altered the default daemon settings to point to a different daemon. If you did not, then this appears to be a bug. If you did, then you need to undo those changes. Then, starting the GUI will ask you whether to start the daemon, and you can then accept. After some time spent  syncing the blockchain, you will then be able to start mining.

Note that solo mining in this way, while you get an equivalent long term expected gain, means you get a LOT of time with nothing, and get a whole block reward very infrequently. It does however help the network more than pool mining.

If you've not yet synced a local daemon, I recommend upgrading to the latest version (0.11.0.0), which has substantial improvement on the sync time and download size. Replacing your binaries with the updated ones is the only thing that's needed to upgrade.


How can I get my hashrate and stats from my mining pool?

Go to your pools config file ../config.js
i.e. moneropool.com/config.js
Get the your pools api variable:  var api="https://api.moneropool.com"
i.e. api.moneropool.com
to get pool stats add "/stats" to the api url
i.e. api.moneropool.com/stats
to get your stats add "/stats_address" and send parameters longpool and address
i.e. https://api.moneropool.com/stats_address?longpool=false&address=YOURADDRESS


Where does the actual decryption of the recipient stealth address occur?

wallet2::scan_output is probably what you're looking for as this checks if any of the tx outs are for this wallet. Then you can see here where it stores to wallet.


Message "Ours and foreign blockchain have only genesis block in common... o.O"

Nothing to worry, when you are starting to sync and theres a node trying to sync with you, it sends the list of blocks it has for catching up but since you have nothing but the genesis block you see this message.


Instead of running the Monero GUI, just run the monero daemon executable (it's called monerod).

The command line flags you should use are:

monerod.exe --rpc-bind-ip 111.222.333.444 --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind

Replace 111.222.333.444 with the IP address of your externally facing network interface.


When you create an account on mymonero.com, you are given a "Private key login" which is a list of 13 words. You are also given your private spend key (the private view key can be recovered from the private spend key).

In practice, they are the same thing, represented differently. So if you have one of the two you will be able to recover your wallet.

Because Mymonero.com doesn't store your private keys or private key login, if you have lost both you will not be able to access your wallet.

Also note that your public address is something you can share with other people so they can pay you with monero and can not be used to access your funds.


xmr-stak-cpu on Ubuntu 14.04 compilation issue

c++ is the canonical "implementation independent" name for the platform's C++ compiler. gcc is the C compiler. g++ would be the C++ compiler. If you don't have g++ installed, then install it first. GCC supports many languages, but C++ may not be installed by default.

Looking at this repository, it seems to be using cmake and not normal makfiles, so once g++ install is done:

git clean -dfx
  cmake .
  make

should build it.


How much I "deanonymize" transaction when I put my address into "extra" part of a transaction?

If you include your (the sender's) public wallet address unencrypted in the tx_extra field, then for an outside observer, this will not affect untraceability in the sense that it still cannot be known which outputs are really being spent.

However the person that sent you the outputs in the first place could obviously see that when you spend those outputs, you've included your wallet address, and so could infer that it's you that's spending those outputs. Of course they won't know who the recipient of your transaction is, since you'll be sending funds to a one-time stealth address that cannot be correlated with the recipient's wallet address.

It will not affect unlinkability because stealth addresses mean it cannot be known whether you're sending funds to the same person each time or different people each time.

You could encrypt your sender address using the transaction shared secret prior to putting it in the tx_extra field (the transaction shared secret is what is currently used to encrypt payment IDs that appear in tx_extra).

The problem with this, though, is that it's rare to see people place their own custom content into the tx_extra field. Your transactions would therefore stand out.


Can you send Monero from an exchange to an exchange directly?

It depends. Several exchanges have a requirement for a payment ID to be included when depositing, but have no option to add it to withdrawals.

In general it's safer to withdraw to an own wallet and then deposit to another exchange, since you can track all steps and in case handle out view keys to prove you didn't get or you sent coins.


Can someone explain the algorithm to compute Monero transaction fee?

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

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

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

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

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


Which part of the daemon RPC is restricted?

When running monerod with restricted-rpc which of the rpc methods will
  not be allowed?

The following changes occur when Monerod daemon runs in Restricted Mode via restricted-rpc and/or rpc-restricted-bind-port options.

The following RPC methods are not registered:

flush_txpool
generateblocks
get_alternate_chains
get_bans
get_coinbase_tx_sum
get_peer_list
in_peers
mining_status
on_get_connections
on_set_bans
out_peers
relay_tx
save_bc
set_bans
set_limit
set_log_categories
set_log_hash_rate
set_log_level
start_mining
start_save_graph
stop_daemon
stop_mining
stop_save_graph
sync_info
update

  Also, is the daemon RPC documentation on getmonero.org up to date? If
  not, is there an up to date version somewhere?

You can find interesting alternative reference at Monerod Restricted RPC Mode and referenced code at monero-project/monero/rpc.


Is there a network protocol specification or description outside the source code?

No, but it's on the list of things we have to do. At this juncture it would be wasted on Monero, but once / if we switch the wire protocol to something standardised like ZMTP then it will be nearly trivial to do.


How many transactions can fit in a block?

There is no easy answer, since both the block size limit and the transaction sizes are variable.

currently, the block size limit sits at its low limit, which is 60 kB. A transaction size can range from a few hundred bytes to more than 60 kB. With those numbers, you could fit 1 to 100 transactions. With a typical transaction size of 2 kB, you can have 30 in a block, roughly.

Transactions will stay for a day in the pool before being dropped. This increases to seven days for those transactions were once in a block which was reorganized.

If blocks are consistently filled, the block limit will go up. Based on a spam attack in 2014, a day is enough for that limit to double. I'm not sure whether the block time change would make it slower, as I do not think the block size median window changed, but I would think it'd make the changes slower.


An update to the current version 0.13.0.4 Beryllium Bullet of the Monero GUI wallet for Linux should solve your issue.


Multisig requires new wallet or new address?

Each multisig wallet can only have a single address for incoming funds. This address will be different from any of the usual addresses created by a wallet prior to multisig conversion.

You cannot know the multisig address until you have completed the multisig wallet make_multisig process (in the case of N/N wallets) or have completed the make_multisig and finalize_multisig process (in the case of M/N threshold wallets).

Therefore you cannot use create_address method first to create any multisig addresses. You can use the create_address method to create valid addresses for that wallet's original seed (prior to multisig conversion), but the wallet will no longer keep track of or scan for incoming funds from these old addresses after you convert it to a multisig wallet. You should therefore not attempt to use the same wallet file for both multisig and non-multisig use.


There is a growing list of merchants that accept Monero below, although the list may not be comprehensive:
https://getmonero.org/getting-started/merchants

Any business that accepts Bitcoin can be paid with XMR.to which automatically converts Monero from the buyer into Bitcoin that will promptly be sent to the Bitcoin merchant.

Shapeshift.io offers a similar service to xmr.to but with slightly slower payments (they wait for tx confirmations instead of scanning the mem pool like xmr.to) but slightly higher maximum transaction sizes.

Payment processors such as BitPay and and wallets (such as Exodus) are starting to integrate Shapeshift. Riccardo Spagni has a payment processor in development named PayBee.


Is this Monero python implementation complete & trustworthy?

The linked project is not a "Python implementation of Monero". It's a module with a set of tools for interacting with the Monero daemons / wallets amongst other utilities.

From their docs:

  The aim of this project is to offer a set of tools for interacting
  with Monero cryptocurrency in Python. It provides higher level classes
  representing objects from the Monero environment, like wallets,
  accounts, addresses, transactions.

Therefore you cannot use this as a basis to create a "a variant of Monero".


Monero Fork: Transaction hash is not generated from the wallet RPC

If the tx is in the mempool, a tx hash must exist. If the wallet RPC is not returning to you the tx hash in the result of the transfer call, your fork codebase has issues. Blocks not being mined could be related, but could equally be an issue with your miners or pool implementation (which obviously also need to be updated inline with your fork code changes).


Is there a way to record my stats from pool sites?

I don't know of any open source Monero pool software that has an API, so most pools do not have API's. The only way to get the stats from these pools would be to scrape the data using a web parsing tool, or building one yourself.


Monerod crashes on startup - Failed to create SSL certificate

Fixed in PR#5257 https://github.com/monero-project/monero/pull/5257

Skipping extra unnecessary cruft.


Do regular Monero users need to update after hard fork?

Yes, you will need to upgrade.

For the particular HF of 2016-09, maybe not immediately. Note that if you keep the funds in cold storage your funds will still be safe even if you don't do anything now so just holding is safe. However, if you should want to spend them, you would need to use upgraded software.

For example, if you keep them in cold storage for a long time you might skip a few hard forks. Then, to spend, you would just need to install the latest software and import the backup to start spending.

Hard Fork 2016-09 Notes

quoting dEBRUYNE's reddit post:

  Not that much will change with the upcoming hardfork, but I figured
  this thread would be helpful anyway. If you didn't know yet, there
  will be a hardfork on the 21st of September. Currently, we are on
  version v2 blocks and with the hardfork we will switch to version v3
  blocks. The only (minor) change is that this fork will enforce
  coinbase transactions to be split in denominations.

...

  Assuming you are on version 0.9.4, you won't have to upgrade your
  wallet for this fork. That is, no preparation have to be taken for
  this fork. Note, however, that 0.10 is going to be released soon and
  in general it is advised to use the latest binaries, because they
  contain bug fixes and new features. In addition, to prepare for the v4
  fork you will have to update to 0.10, because v4 will allow both
  conventional transactions and Ring CT transactions.


create_account
get_balance
transfer_split
query_key and create_wallet

See https://getmonero.org/resources/developer-guides/wallet-rpc.html for basic documentation.


Why isn't simplewallet relatively safe with a very strong password?

Used correctly simplewallet (named monero-wallet-cli in the new release) is relatively safe compared to an exchange or web wallet, but it will never be as safe as cold storage.

  lets say my password is a huge strong password I keep in a safe spot

As soon as you enter your strong password (or mnemonic seed) on your computer to use your wallet, it could potentially be exposed to a keylogger.

Properly created cold storage wallets by definition never have their passwords or mnemonic keys exposed to an internet connected device.


Trouble connecting to my remote full node

I was able to solve this issue. Testnet wallets connect on port 28081 by default, so seeing this port being closed made me try a few things. The one that worked, though I'm not sure exactly why, was to set --rpc-bind-ip 0.0.0.0. This opened port 28081 and everything works well now.


This isn't available in the wallet software yet, but it is technically possible to set an "unlock_time" on a transaction:

How to use unlock_time?

The idea being that you could pass a future date in UNIX time into this RPC call which would cause funds to be locked until that time has passed. You could then use this to send all of your funds back to your own wallet address. Just test it with a small amount first to make sure you get the date format correct.

If you are looking for more of a deterrent from spending too quickly, you could send it all to a paper wallet and drop it off in a couple secure locations. It is enough of a hassle to retrieve the paper wallet and restore from a seed that you might not go through the trouble.


I don't know of any web-based example but it's pretty easy to use py-cryptonight for testing/validation purposes.

For example:

pip install py-cryptonight

Then in Python:

import pycryptonight
import binascii

height = 123456
data = binascii.unhexlify('DEADBEEF')
prehashed = 0
variant = 5
hash = pycryptonight.cn_slow_hash(data, variant, prehashed, height)
print('Hash: {}'.format(binascii.hexlify(hash)))


More than one real input per transaction?

Yes, transactions can be composed of multiple real inputs. In that case, each input will be mixed with n 'fake' inputs (n is the number of other members in the ring, a.k.a mixin). The mixin level is the same for all inputs.
For instance, the transaction in the link you provided is composed of 43 real inputs, each one of them has been mixed with 5 fake inputs. This means that in the entire transaction 43*5=215 fake inputs were used (43*6=258 counting the real ones).


Is the 10-block lock time a protocol rule? What rules accompany it?

A. Is this a wallet rule or a protocol/daemon rule?

It's a wallet / daemon rule. The number of blocks is defined as a pre-compiler constant CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE.

B. Does the rule only apply to spending one's own output, or are new/locked outputs also excludable from a ring signature even as decoys/mixins?

Generally, it applies to all outputs. So if you change the constant for both the daemon and the wallet, then you could have both the real one and the decoy of the age younger than usual.

In my experiment, I used a normal daemon and modded wallet. Since the daemon was using the usual setting of 10, and the daemon gives fake outputs to the wallet via RPC, it means that only the real one could be younger than 10. If I ran the daemon with the mod, they could (in theory) all be younger than 10.

C. If someone clones the Monero repository and removes the 10-block lock requirement...

I just did that to test and successfully sent 3 TX-es in succession, all using the CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE of 1.
So yeah, it can easily be done by changing that one line of code, and transactions made with the modded wallet will stick unless some reorg happens.

It's the same for both 1. and 2. because the network can't know whether the 1-block-old output is a decoy or the real one.

Note that by making such TX-es you'd stand out from the crowd, and it would probably be easy to tell that the same person did a few TX-es in a row if they're all spaced <10 blocks.

The Why

One could ask, but why isn't it set to 1 then?

Problem is, the input one-time keys are referenced using an offset. If a re-org would swap the order of transactions, then the transaction referencing any one-time key at the wrong offset would become invalid and would never confirm.


How to check if transaction pays to my address?

Extract the tx public key R from the tx extra field, and for each output, it's key
K and index i, then using your private view key a and public spend key B, you own the output if:

Hs(8aR||i)G+B == K

To find out how much you received, take the encrypted amount e for that output index from the transaction's ecdhInfo field and decrypt:

xor8(e, keccak("amount"||Hs(8aR||i))

Note, xor8 is XOR'ing the first parameter with the first 8 bytes of the second parameter, the result is the decrypted amount.


Currently the Ryzen 3000 series CPUs are considered the most cost effective.


Updating Your Loki Service Node using the Loki Launcher

First login to your service node and make sure you are using the user that launches the loki-launcher. Following the guide: https://lokidocs.com/ServiceNodes/UpdateGuide/ -- My user is snode.
For those looking for a one liner, you can do this otherwise skip it:

$ su snode
$ loki-launcher stop; sudo npm install -g loki-launcher; sudo loki-launcher download-binaries; sudo loki-launcher fix-perms snode; loki-launcher start

Then make sure you stop the loki service using:

loki-launcher stop

If that doesn't work you can stop it like this too:

sudo systemctl stop lokid.service

Once stopped, we can proceed to update loki. First update loki-launcher using:

sudo npm install -g loki-launcher

Then update lokid binaries using:

sudo loki-launcher download-binaries

And make sure your permissions are fixed also by:

sudo loki-launcher fix-perms snode

To double check goto your folder:

cd ~/.loki

And see if any of the files or folders have root as the owner. If it does, change it to snode: sudo chown snode:snode < folder/file >

Now lets start your lokid: loki-launcher start
Then do a: loki-launcher client
Let it wait as it will have to scan the blockchain for the new version. My vps took about 10-15 mins to do the scanning. You should see this:

When done, you'll see SYNCHRONIZED OKAY
And check on your SN status with: print_sn_status

Next make sure your STORAGE SERVER is working. Just do a: loki-launcher status -- if it shows OFFLINE, you can try to launch it manually to see if its throwing errors like this: /opt/loki/bin/loki-storage 0.0.0.0 23023 --- I had the issue where it was showing OFFLINE, it was due to my ~/.loki/storage folder was owned by root. A chown to snode fixed it.
Also be aware of:

IP Address: 0.0.0.0
Storage Server Port: 0
Downtime Credits: 720 blocks (about 24.00 hours)

Its suppose to look like that as the fork hasn't happened yet.


Monero cli transfer all funds from my wallet to a new address?

Yes you can just use the sweep_all option in replacement of transfer and it will send out ALL your coins to the new address.

Just do:

sweep_all < address >


Cant't find out where replace the nonce to get a blob hash

You have the correct location for the nonce bytes. However, are you using the same CryptoNight variant? I doubt this.

The current version (CN/R), also requires a height parameter as input. Therefore we can know for sure the version you linked to is not using CN/R (it is not asking for a height parameter as input). So unless you are mining to an old pool / chain, you can also be pretty certain you are mining CN/R, which explains why your result hash sent to the pool differs from the one using the link.


How does Monero help people in developed countries?

Your question is a tricky one to answer, partly because a short answer wouldn't do it justice, and partly because there is a hidden underlying premise that needs to be brought to the surface.  The underlying premise is that this question is oriented in the present.  That point may seem trivial, but it's not.  I'll get back to this, but let me begin to frame my response.

Many reasons can be enumerated for why Bitcoin was created, but the one I want to focus on is that it enables trustless, no intermediary, peer-to-peer payments.  The idea is that you can send money to anyone, anywhere in the world (with internet), and you don't need a bank or credit card company or anyone at all to help you transfer that value.

Well, that may be the idea, but it's still generally easier said than done.

The bitcoin peer-to-peer payment network is still in its infancy.  The coin/protocol itself has undergone plenty of changes along the way, but most of that progress happened behind the scenes, so to speak.  The "real" progress - mass adoption by its potential users as a medium of exchange - is still in its very early stages.  You basically have to have something like the Shift card (using the US as an example) if you want to exclusively spend cryptocurrency everywhere, since you're actually converting your BTC to fiat, rather than sending BTC in a peer-to-peer manner.  I look forward to a time when I can transaction exclusively in cryptocurrency, but that day is not here.

What I'm trying to show is that there isn't a pressing need in the current environment for a fully anonymous, private cryptocurrency.  If there were, Monero would be much more expensive to buy.  Rather, the current time is being devoted to developing the protocol, expanding the ecosystem, and getting users to be familiar with cryptocurrencies in general.

But the future... I'm excited about the future.  I expect that the future will hold a much larger and more frictionless ecosystem facilitating cryptocurrency payments.  In that future, perhaps the vast majority of cryptocurrency transactions will be mundane, and no one will have any reason to want to be anonymous, and there will generally be little need for private transactions.  But what about the 1% (or 5%, or whatever it is) of transactions that require privacy, where true anonymity is desirable, or even necessary for safety?

It's next to impossible to be truly anonymous with Bitcoin; and even if you manage to stay anonymous, the transaction is still visible to all onlookers.  Further, it's easy to demonstrate that you're practicing OPSEC with any cryptocurrency that doesn't have privacy and anonymity baked in at the protocol level.  Many people who put value in Monero do so because they know they won't need to do anything differently when sending transactions they wish to remain private.  Rather, all the transactions Monero users send are private and anonymous, and they don't need to act any differently for transactions they'd rather keep private.

(I feel like I pretty much just scratched the surface here, but the answer is long enough.)


What Ports Does Monero Use? (RPC, P2P, etc.)

On the daemon side (bitmonerod)

P2P Port is the one used to connect with the other nodes on the network (or locally in some cases).

RPC port (Remote Procedure Call) is used to let other applications such as simplewallet or the GUI interact with the daemon, for instance to get information about a block.

Default ports for the daemon are

P2P: 18080 for the mainnet, 28080 for the testnet
RPC: 18081 for the mainnet, 28081 for the testnet

They can be changed with following options

--p2p-bind-port
--testnet-p2p-bind-port
--rpc-bind-port
--testnet-rpc-bind-port

On the wallet side (simplewallet)

RPC port is used to let other applications interact with the wallet for instance to get balance.

The wallet do not act as a RPC server by default. It can be activated with the option --rpc-bind-port.

For daemon and wallet

The RPC data are exchanged using JSON-RPC a protocol based on JSON data format.

This page shows how to use programming language Python to interact with the daemon or the wallet via RPC.

UPDATE: Added 2 information from user36303 for completeness  and because the firewall comment is important

Wallet and daemon may use 53 for DNS, which is optional.

It is recommended to only open the RPC port on your firewall if you need to access RPC from the outside, especially for the wallet.


Results of scalarmultKey in MiniNero and monero-project are different

As @knaccc astutely points out, your keys are not valid.

An example with valid test keys, in Python:

p = '644206dabcd3014180f120c0d3da7fc167701a310ca520467199fcefbd7e0109'
P = 'c2f9d63a7dbfb73fc24dae28df2ecf5b3667eff59124511fa6735ac848938cce'
print MiniNero.scalarmultKey(P, p)

Outputs:

af16f921de9efbf28ec744dbe927e7592de8ee4fb1f5c6112e3458b00369a0a4

And in C:

key r,p,P;
hex_to_pod("644206dabcd3014180f120c0d3da7fc167701a310ca520467199fcefbd7e0109", p);
hex_to_pod("c2f9d63a7dbfb73fc24dae28df2ecf5b3667eff59124511fa6735ac848938cce", P);
scalarmultKey(r, P, p);
for(int i=0; i<32; i++)
    printf("%02x", r[i]);

Outputs the same:

af16f921de9efbf28ec744dbe927e7592de8ee4fb1f5c6112e3458b00369a0a4


Clarification on the Monero Trezor binaries 'passphrase'