Anonymity networks make sense for remote nodes, not local. The monerod runs in the data center and wallets @home or mobile phone. Here & here you can find some public .onion nodes.
Your linked README is out of date and contains the link to ANONYMITY_NETWORKS. Hint: monerod includes now addresses of I2P and Tor seed nodes. See: add support for i2p and tor seed nodes
therefore --add-peer or --add-exclusive-node is no longer absolutely necessary.
monerod RPC & P2P can be set up as a hidden service and you can connect your Monero (GUI|CLI|RPC) wallet over Tor to it.
The monerod P2P and blockchain synchronization will continue to be done via Clearnet as well. If any anonymity network is enabled, (inbound connections --anonymous-inbound and outbound connections --tx-proxy) transactions being broadcast that lack a valid "context" (i.e. the transaction did not come from a p2p connection), will only be sent to peers on anonymity networks.
Simplified:
P2P blockchain download & sync only over IPv4 because of sybil resistance and security.
RPC & transactions can be done via IP, IPv6, Tor and I2P. Excellent monerod-reference


What other coins have similar implementations of Kovri to hide IP addresses from the sender?

The network layer is different from the blockchain layer. This feature is provided by the wallet, not consensus.

The Bitcoin Core wallet includes a mechanism to connect through Tor. Several other forks of Bitcoin offer this feature.

I2P is less-frequently used, since it requires more network participants to use the service. This was first used by Anoncoin.


Is it possible to trace an output in the Monero blockchain?

An output's public key uniquely identifies an output [1].
A ring signature takes N outputs, one of them being the one that's actually spent, and makes a signature that can be verified, such that:

one of the outputs in this ring is spent
all the outputs in this ring have equal probability of being the one being spent

Now, the scenario in MRL-0004 is more complex than just looking at which outputs are spent, because (assuming N > 1) we can't tell which are spent with certainty just by looking at the ring.
The scenario considers that a transaction contains two rings, one for 0.7, and one for 0.05. Each of these two rings will contain the real output (Alice's), plus N-1 others from the blockchain. However, you'll note that Alice received those two real outputs from the same transaction, so a blockchain observer can see that one of the inputs in the first ring and one of the inputs in the second ring were created in the same transaction. While this could be chance, it is more likely that those two outputs belong to the same address.
This is a probabilistic inference, and not a certainty.

This is adressed in the RingCT branch, which has code to prefer spending unrelated outputs, if possible: https://github.com/moneromooo-monero/bitmonero/commit/f478336e68995ebd65a96ba249a3fc8e0f159fca. This code will first select outputs which do not share a transaction, or similar block height.

Cases where it might not be possible to spend unrelated outputs are typically if you're trying to spend a large part of your balance at once, and you do not have enough unrelated outputs.

[1] in the vast majority of cases, unless a bad RNG is used, or someone deliberately burns coins in this way


First off, the node does not do anything about addresses, the wallet does. The node never gets your secret keys.

Next, the Monero wallet will always cache/calculate the next 200 addresses for the next 50 accounts. Every time you receive monero in one of these, the Monero wallet will cache/calculate more of these to always keep a buffer of 200/50 beyond the "furthest" you've used.

For this reason, if you decide to use a subaddress more than 200 away from the highest you've currently precached, it will not be seen. To prevent this, either use a larger lookahead (that option you've found already), or generate them manually in monero-wallet-cli by creating new addresses until you get in range.

Those addresses are deterministic, so you don't need to back them up. They can always be restored in the same way from your seed.


Same like mymonero: How does mymonero web wallet work?

Instead of your wallet getting blockchain data and scanning it yourself, you give the service your viewkey and address and it does the scanning for you.

It has privacy drawbacks. The service can see your incoming transfers and amounts. It can not see the destination. However, it could make good guesses when you send to someone else registered on the same service (because it could cross-reference his list of received with yours). That's why the objective is to have people run their own micro-service which they will be ale to do soon when work on open-source back-end will be finished.

However, I imagine mass surveillance of those services and data analysis would require massive amounts of computing power :)


What is the structure of the .raw exported blockchain file like?

It's just a binary (raw) version of the blockchain that can be imported using monero-blockchain-import. To my knowledge the only tool that can read this file is monero-blockchain-import.

The file extension is immaterial.


Correlation between transaction vout key and an address

... actual amount was it received from a block's reward

getblock's response has the reward for the block in the responses block_header->reward field.

Pools tend to just keep track of submitted block at height and its hash. So when new blocks appear on the chain, and after 60 blocks have passed, you check to see if the block you submitted is still on the chain at the submitted height with same hash. If it is, you will have have the unlocked block reward. If it is not, some other miner/pool will have received the reward. This can happen because of a reorg (consensus leaning towards some other submitted block).


Why is AEON wallet not working on Bittrex?

There were some large reorgs/forks in June 2017, like on the order of 50 or 100 blocks, the cause of which was not clear. Prior to that there was a bug that required a chain rollback, which resulted in delisting from cryptopia exchange. After these incidents the maintainer of aeon GitHub repo, smooth, requested bittrex to take the wallet offline until aeon could be updated to a more recent monero codebase. That process still hasn't been completed, so the wallet is still offline.


Error: send que size more than ABSTRACT_SERVER_SEND_QUE_MAX_COUNT

It means communication with that particular peer is stuck. It can be ignored, and is likely fixed in master (hard to be 100% sure).


Sent Monero to Atomic Swap Wallet using GUI Wallet - Slow Transaction

Just got an email from Atomic Swap support and they said the following.
"XMR is under maintenance in Atomic Wallet due to the incompatibility with the new update. You won't be able to send, exchange, and possibly see your balance. Our team is working on the issue, but there is no ETA."
Issues has been resolved.


How to set up xmr-stak-nvidia to solo mining

You can use monero-stratum for solo mining:

https://github.com/sammy007/monero-stratum


Seeking to port XMR to PPC64 - PlayStation 3

Just so all you testers know. I finally got my PS3's to mine crypto besides litecoin and bitcoin.
Unfortunately the hashrate through put isn't impressive like we all already knew. But I am confirming that I get an average of 80 H/S or so per system for Monero. Just in case any one was wondering.

How I did this: One must load NFS and SSH on the clusters nodes of PS3's with Fedora 9. Then one must have a linux capable laptop or desktop as their Master Node to compile and run OpenMPI. Which is open source cluster software. The PS3 can not compile alt-coin miners but will mine through OpenMPI and one's master node as a node on a cluster. So IT IS still possible to mine with them but the hash rate isn't remarkable. Any ways good night. I hope this help some body and good luck!


Cryptonight (the PoW hash used by Monero and most Cryptonote coins) does not lend itself well to ASIC development, for the following reasons:

Cryptonight requires 2 MB of fast memory to work. This means that parallelizing hashes is limited by how much memory can be crammed in a chip while keeping cheap enough to be worth it. 2 MB of memory takes a lot more silicon than the SHA256 circuitry, for instance.
Cryptonight was designed to take advantage of the AES-NI instruction set, which uses existing hardware circuitry on modern x86_64 CPUs to speed up AES operations (Cryptonight is based on AES, a modern symmetric cipher). This means that at least some of the work done by Cryptonight is already being done in hardware when run on modern consumer machines.
There has been some talk of replacing the PoW algorithm with Cuckoo Cycle (an alternative PoW hash designed to be ASIC resistant too, see details about it at https://github.com/tromp/cuckoo). If such a switch happened, the R&D cost of developing a Cryptonight ASIC would be lost in large part, since they could not be used for Monero anymore.

So, no, there are no ASICs for mining Monero as of now, and probably will not in the near future either.


The behavior in the transaction you linked is a new one. It did not exist at the time MRL-0004 was written.

Now, if you make a transaction now including your 0.00111111 output, it will appear as is as an input to that transaction (and you may have to send it with mixin 0, unless there are two other outputs of that size on the blockchain already). However, should this transaction pay out some dusty amount like 3.32111111, this amount will be decomposed. This behavior has been current since last fork in march 2016.

So if you have dust, you can either spend it with mixin 0 (current simplewallet has a sweep_unmixable command for this), or wait to spend it later. Note that dusty amounts might be mixable. For instance, if several people send an integer amount of monero, and the transfer had to be split into 3 different transactions, all would generate a 0.003333333333 monero output, so that particular amount is likely to have been created several times before that fork.


Is there a way to know how many people are using my public remote node?

The only metric that the daemon is giving me is the number of incoming/outgoing connections, without differentiating between wallet connections and P2P connections.

That's not correct, the daemon does differentiate: those are all P2P connections.

Recent daemons do report the number of RPC connections in the getinfo RPC, in the rpc_connections_count field. This includes nodes syncing, but also nodes using the RPC for other business, such as sending a one off transaction.


Fundamental question for monero: how to mine myself

When Alice finds a block, she will send it to the Monero nodes she's connected to. In turn, these nodes will (assuming the block is valid when they verify it) will send it to the nodes they're connected to, etc.

When Bob finds a block two seconds later, the same will happen, but Bob and Alice are likely connected to a different set of nodes.

What will then happen is that Alice's block will propagate through the network of nodes, and Bob's will too, a little bit later. Alice will have some head start, and will reach more nodes quicker than Bob's.

If a block receives Bob's block, but already has received Alice's, that node will reject Bob's block (assuming it does not have a higher cumulative difficulty than Alice's, which is the usual case). That node will then not send Bob's block any further.

You then end up with some part of the network having a blockchain with Alice's block at its tip, and another part of the network having Bob's. The network is forked. Alice had a head start of two seconds, so most of the network probably has Alice's block, and is now mining for a block over it. The other part of the network is now mining a block on top of Bob's block.

The next miner to find a block (either on top of Alice's or Bob's) will send it to the nodes it's connected to, again. Let's assuming it's Alice's. Miners who are still mining on top of Bob's block will get see a valid incoming block with a higher cumulative difficulty than their current tip, and will remove Bob's block from their blockchain and replace it with Alice's and the new one.

So there is no central registration authority. Every node keeps its own version of the blockchain, and uses cumulative difficulty to decide which to keep. Cumulative difficulty is based on the difficulty of all blocks in the chain.


Commitment to zero vs one-time public key signature

It seems as if they are saying that we use the commitment to zero to sign the ring with the inputs as message.

Not quite, it does use it, but it is not the actual signing key.

It says:

  Signing m with ko proves  you  are  the owner/recipient of the amount committed to in Ca. Verifiers can be confident that transaction authors are spending their own funds.

And further up says:

  With this observation made we can see the utility of zG.  All commitment terms in R return some EC point, and the πth such term is zG.  This allows us to create an MLSAG signature (Section3.3) on R.

Moving to your next question:

  Each input needs the private key associated with it's one-time-pubkey/address in order to unlock it. So does each input have a ring signature with the private key corresponding to the one-time-public key needed to unlock our input?

Yes. Or to put it more accurately, the receiver of the outputs now being used as inputs (to spend), has derived the private keys (using the tx shared secret from the tx they received these outputs from, and their own wallet private keys).

  Then maybe the commitment to zero is used to sign the whole transaction?

No. I think where you are getting lost is the distinction between proving ownership of inputs being spent and proving that the output amounts balance out the input amounts. The former is the job of the MLSAG signature(s), the latter is the job of the Pedersen commitments and the Range proofs (the commitments hide the amounts and prove the inputs minus outputs balance out, the range proof proves that each amount in an output commitment is within a range, in this case positive, which prevents creating money out of thin air).

The commitment to zero is used in the construction of the MLSAG signature, it is not the signing key itself.


Can a CryptoNote coin be merge mined with a non-CryptoNote coin?

If the cryptonight algorithm was replaced with say, sha256, could it be merge mined with bitcoin, for example?

That would certainly be possible. The requirements for merged mining basically boil down to (i) having the same PoW algorithm and (ii) miners of both chains agreeing to merge mine.

More information about the specifics of merged mining can be found here.


Number of outputs included in a given ring size

Ring size refers to the complete ring signature, which includes the signer's output. They're all equal participants in the signature, thus the ring size is the total number of outputs used, including signer's. So while it still refers to the same thing as 'mixin' did, it doesn't exclude the one belonging to you, thus:

Ring size = 'mixin' (number of foreign outputs) + 1 (your output)

I use the term "foreign output" because it's the one found in CN whitepaper.
Someone linked to this paper as well, which uses some nice language:

To produce a ring signature, the actual signer declares an arbitrary set of possible signers that includes himself, and computes the signature entirely by himself using only his secret key and the others’ public keys.
...
We call a set of possible signers a ring. We call the ring member who produces the actual signature the signer and each of the other ring members a non-signer.


Problems with daemon syncing past block 1341326

Sounds like you're on an old release. The current version (v0.10.3.1) doesn't bounce around like that on reporting sync state any more.


Does monero v12.2 work on a raspberry pi zero wireless?

I got 12.0 to work, but not running monerod, just the wallet.  Did test monerod, and it started syncing, but didn't want to wait 3 weeks, and didn't have the space.

Now I do have an Orange Pi Zero running monerod (12.0) pretty much fine  (it occasionally just quits)  But the OPi is an ARM7.

When I get a chance, I'll give 12.2 a go.


How are coinbase transactions masked so that they fit the ringCT protocol?

You are correct to point out that if you send exactly 3.5999749793 XMR (3.6 XMR - e.g. 0.000025020730 XMR tx fee) to your recipient, by referencing 11 outputs in your ring signature, one of which is exactly 3.6 XMR, they will have a high chance of guessing that you are spending the mined output.

This, however, is a somewhat contrived example. Most of the time, you're not spending the exact amount of a particular output (minus the fee) you have in your wallet. If you'd sent someone 3.5 XMR, then they would be oblivious. Only when the amount you send is the exact amount of the output (minus the fee) can they make a decent guess.

In practice the only time that this scenario would happen is if you're sweeping your entire wallet contents to a third party. In that scenario, for there to be a threat, you'd need to have only ever received coinbase outputs to your wallet, and never have made a single transaction from that wallet that spent any fraction of those coinbase outputs. If this scenario is applicable to you, you can easily solve this problem by sweeping the contents of your wallet to yourself before transferring funds to a third party.

Also note that even if the above scenario applies, coinbase outputs can be some of the most anonymous outputs to own in the first place. This is because when you mine the output, if you conceal your IP address when submitting the successfully mined block to the network, then there is no record with e.g. an exchange that will associate that output with your real world identity. Therefore knowledge of that one-time output address being spent will reveal nothing of any value.


The best way to do so is to use:

monero-utils-deserialize --input <hex dump goes here>

This will parse and tell you what it is.

This tool is only built in debug mode as it is a debugging helper.

Note that Bulletproof format changed on testnet, and the network was reorganized from the start of v7, so you might have an old style proof, which will fail to parse.

To see if a given transaction is in the current chain (from its transaction ID), run this in monerod:

print_tx TXID +json

You can also checkout a testnet explorer at testnet.xmrchain.net.


Are payment id's publicly viewable on the block explorers?

There are two types of payment ID. The first is the older style 32 byte unencrypted payment ID. This will appear on the blockchain for anyone to see.

The second type is the newer style 8 byte encrypted payment ID. That gets encrypted with the transaction shared secret before hitting the blockchain, so that would not be suitable.

Monero has a tx_extra field that can be of any length, so you could even create specially formed transactions that could put much more than 32 bytes unencrypted onto the blockchain. The structure of the tx_extra field is described here: https://cryptonote.org/cns/cns005.txt

Here is an example transaction on the blockchain:
https://xmrchain.net/tx/91be5c4bf7afa2a80bdb82db4eacefa8a212aefed41cca75f06e83f16ebef742

The tx_extra field is:

0221005d5ef173175a81d7e82ee3627fb7ef578f2f5803c552c93967d3caa36a920934019aeca56f3e9e0b6b849993ec27cf2eae0bb157e85ee2e4249afb03683eccc879

The first byte 02 means the first field is of type "tx_extra_nonce", which means either an encrypted or unencrypted payment id will follow. The second byte is a varint 21 which means that the field we're about to read is 33 bytes long (21 in hex is 33 in decimal).

Therefore the "tx_extra_nonce" field is the following 33 bytes:

005d5ef173175a81d7e82ee3627fb7ef578f2f5803c552c93967d3caa36a920934

The first byte of the field is 00 which means the rest of the field is a 32 byte unencrypted payment id:

5d5ef173175a81d7e82ee3627fb7ef578f2f5803c552c93967d3caa36a920934

If the first byte of the tx_extra_nonce field was 01, then an 8 byte encrypted payment id would have followed.

For completeness, note that the next field in the tx_extra is marked as type 01. This means that the 32 byte transaction public key follows.

The transaction public key is:

9aeca56f3e9e0b6b849993ec27cf2eae0bb157e85ee2e4249afb03683eccc879


In your 1st and 2nd examples, where the difference is tiny, you're talking about a few bytes difference between estimated and actual size. I'd expect to see this due to things like varints. Also, weight and size estimates for these match because the bulletproof clawback isn't being calculated/applied due to there only being 2 outputs on those txs.
In your 3rd example, you're seeing a big difference between estimated weight and real size because this tx has 16 outputs, hence you're seeing the bulletproof clawback come into play on the weight estimate. Also, you're seeing the several hundred bytes difference between real and estimate size because that tx has a tx_extra field which is 547 bytes in size and the estimation only uses the common case of tx_extra being 44 bytes in size.


How to get the r value for commitment in mlsag sign

#Thanks for the reminder from @Koe.
Refer to ZtM2 chp 5.4...
The kπ here for "commitment-ring" should be xj-xj'
So that the challenge is
cπ+1 = Hn(m, Kπ, [α1G], [α1*Hp(K)], commitment_to_zero, [α2G])

Where commitment_to_zero can be derived fromxj-xj'.


Monerod constantly in sync by lagging behind 2 blocks

I was having exactly the same issue. But you pointed me in the right direction :)
There is a ban-list which you can use, by adding the following argument to the daemons command line:
--ban-list <path to block.txt>


What is the minimum length of a payment ID?

There are two kinds of Payment IDs:

the original kind is 32 bytes long, and are plaintext on the blockchain.
the new kind of 8 bytes long, and are encrypted on the blockchain.

The new kind are normally embedded in the address, forming an integrated address. The old kind is not, and is specified manually.

They're usually input as hexadecimal, so indeed only [0-9a-fA-F] are allowed (and a byte is represented by two hexadecimal characters, so 32 bytes -> 64 hexadecimal characters, and 8 bytes -> 16 hexadecimal characters).

Note that since payment IDs' purpose is to convey some information to the recipient (hey, this payment is from me, Alice), if you're receiving your own monero to your own wallet, you don't need one.


Why does it take about 5 minutes for a transaction to register on the network?

Transactions that are not yet included in a block are stored in the memory pool. When you submit a transaction to the network, you'll almost immediately see your transaction stored in the memory pool on a blockchain explorer, e.g. http://explore.moneroworld.com . Average block time is 2 minutes, so the newly created outputs will be unlocked roughly after 22 minutes (for 10 confirmations).


Wolfram Warptangent, Point Release 10.2.1 performance improvements

There were several changes:

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

This patch splits block and transaction data getters in two: one which retrieves the data, and the other also doing some parsing and reconstruction of the block or transaction. This allows skipping all the parsing (and reserializing) where it is not needed, which is mainly when serving blocks to other peers, but there are various other places where this helps.

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

This patch ensures that the "pre block add" lookups for inputs used in incoming transactions aren't performed for blocks which were already added recently. Since Monero download blocks concurrently from several peers, the first one to send a chunk of blocks will have those blocks added. Subsequent ones will then be able to early out if they determine that their work (or some of it) is now unneeded. This avoidance of extra lookups is particularly helpful on spinning disks, where someone reported a roughly 4 times speedup in sync (or a sample of 20k blocks).

https://github.com/monero-project/monero/pull/1576 and https://github.com/monero-project/monero/pull/1615

This splits checks between those that are inherent to the transaction itself, and those that are dependent upon the blockchain (which can change over time). This removes some duplicate checks. Failing transactions (for the inherent checks) are also remembered, so they can be ignored when we see them again, without having to check them anew.

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

This caches some frequent RPC calls between wallet and daemon, speeding up transfer operations, and lessening the load on the daemon as a side effect.

Additionally, and this is not merged, there is a patch which decreases CPU load a lot on pools by caching block template: https://github.com/moneromooo-monero/bitmonero/tree/cache-block-template. This is used by several pools in production as far as I know, but was judged too risky to merge for now.


The hash rate dropping to 0 is as measured by the pool, not your miner. The pool hash rate can and usually is different from what your miner will display, because the hashrate on the pool side is estimated based on the hashes you have submitted.

Because the difficulty of the port you are on is a bit high for your CPU hash rate (I estimate from the graph your actual hash rate is between 30-40 hashes per second), this causes your CPU to not find a valid share for a while, which makes the pool believe that you are hashing at 0. This is also what is causing the timeout in your connection.

The solution for this would be to move to a lower difficulty port, then your hashrate graph will be more consistent and closer (but still not 100% accurate) to the hashrate displayed in your miner.


How to speed up balance scanning of addresses?

Yes, CPU performance does affect scanning time, but so too does Disk I/O speed, and having a sufficient amount of RAM. By the sounds of it you want to set up your own remote node to connect to from your phone?

And yes, my understanding is that when you connect to a remote node, the scanning happens server side, so this should work in theory.

My question to you is, why wouldn't you just use an existing remote node? Unless you are very concerned about your IP address being logged by a remote node operator, using a remote daemon does not compromise the security of your funds. I am unsure whether remote nodes can see your transaction history or not though. Could someone else clarify that?


What calculation/process is being carried out regarding the syncing process

The main things going on are:

Getting block information from connected peers
Building/Verifying the blockchain starting with the Genesis Block (block 0) and verifying each block and all transactions in the blocks follow consensus (which changes at various block heights based on historical hard forks) and building a block tree.
Storing the verified blockchain in an LMDB database.

So it is doing network connections/downloading, verifying hashes, and writing to disk.


Can't load wallet in CLI v0.13.0.2 or GUI v0.13.0.3 (error: std::bad_alloc | error: basic_string::_M_replace_aux)

First, make sure you're running either CLI v0.13.0.4 or GUI v0.13.0.4.

Both errors imply an incompatible wallet cache, which results in monero-wallet-cli not being able to open it. Fortunately, the fix is quite trivial.

Perform these steps and you should be able to open your wallet again.

Browse to the directory your wallet files are located. By default, this is the same directory as monero-wallet-cli.
Rename <wallet-name> (the file without extension) to <wallet-name>-old.

Note that, because you renamed the wallet cache, <wallet-name>.keys now doesn't have a accompanying wallet cache. Therefore, monero-wallet-cli will create a new wallet cache, which will simultaneously trigger a wallet refresh from scratch. A wallet refresh from scratch, however, shouldn't take that long to complete.

GUI:

If you're using the GUI, you can utilize the following steps:

Exit the GUI.
Browse to the directory your wallet files are located (Documents\Monero\<wallet-name> on Windows | home/<username>/Monero/<wallet-name> on Linux | Users/<username>/Monero/<wallet-name> Mac OS X).
Rename <wallet-name> (the file without extension) to <wallet-name>-old
Restart the GUI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.


Yes, it is possible, and while I can't point at it right now, I know there's at least one in the chain.


What's a quick way to view my Monero Balance without downloading the blockchain?

This similar question explains how you can connect your GUI to a remote node to verify your balance. For a more technical, but more secure method read about how to use view keys and key images to verify a balance without exposing your private keys to the internet.


Scanning of View only wallet with monejuro shows different balance

View wallets only see incoming monero, not outgoing monero. In order to know outgoing ones (and thus see the balance), you need to import key images from the full wallet (the one with the spend keys).

See How can I check the balance of a Monero paper wallet? for instructions.


What is the risk of specifying --verify 0 with blockchain_import?

Basically, by not verifying, you're assuming the download is trusted. But there could be all sorts of bogus data in the blockchain.raw, if you have a man-in-the-middle attack during the download.

Personally, I only ever use blockchain.raw imports when I'm experimenting on very low power ARM devices, syncing up from scratch in nearly every case is significantly faster - and safer!


Generate Monero Private/Public Key using PHP Only?

Line 72 in that file has a variable name that doesn't match the parameter name (notice the lowercase k in spendkey). Just edit that line replacing $spendkey with $spendKey should fix it.


Error when launching (--rpc-bind-ip) monerod with external IP address: Failed to bind server

It looks like you are attempting to bind to your public internet address, which is the address of your router. This will not work, because you need to bind to an IP address that is actually attached to your local network interface (the IP address of your computer on your local network).

If you bind to that, then traffic that hits your router's public internet address will be forwarded to your computer's IP address on your local network, and the daemon will be listening on that IP address to accept the traffic.


What is the command code for Wolfram Warptangent, Point Release 0.10.2.1?

In your browser, go to getmonero.org and look for the announcement of the new release. Click on that announcement. Look for the "Linux, 64-bit" download link. Right-click on that link and copy the URL, which is the compressed .bz2 file. Then, in a terminal, you can paste the link by right-clicking in the terminal and selecting "Paste." Type wget first and then paste:

wget https://downloads.getmonero.org/cli/monero-linux-x64-v0.10.2.1.tar.bz2

This will download the compressed files which are already in their own directory. Before extracting it, it's a good idea to verify the sha256 of the .bz2 file to ensure it wasn't tampered with. Do this with:

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

Check the output with the sha256 listed on the announcement page. Now, you can extract the directory which contains the point release binaries with:

tar -xf monero-linux-x64-v0.10.2.1.tar.bz2

cd into the new directory and start the daemon with:

./monerod

This will download and sync the blockchain, which is stored in /home/yourusername/.bitmonero/lmdb/data.mdb

After the blockchain has downloaded, copy your existing wallet to the new directory, or you can create a new wallet. Open another terminal in the new directory, and if using an older wallet:

./monero-wallet-cli --wallet-file [walletFileName]

Don't include the brackets when you enter your wallet file name. Or, if you want to create a new wallet:

./monero-wallet-cli

From there, it will walk you through the creation of your wallet, which takes at most 1-2 minutes. Enjoy!


Old node that is still on monero v11 - Is this on a fork now? Is this considered Monero Original and Classic?

Yes v11 is not supported anymore. And installing v11 of monero does put your on the old chain which is called classic / original. It will wither and die over time due to the lack of development on it. The only thing has it for them is the ASICs that are mining on it as there is no other use of the asics. Just stick with v12 software.


How do I start the monerod daemon as a remote node with a username and password requirement to connect to it?

When starting your node monerod daemon, use the following start-up flag:

--rpc-login username:password

Answer supplied by @glv


Setting XMR-STAK as startup service in Ubuntu 16.04

You're likely running into the same problem as me.
It seems that xmr-stak.sh only reads the config file if you start it manually.
Apply the following change:

ExecStart=/home/aniket/xmr-stak.sh -c YOURCONFIGFILELOCATION

After that do a systemctl daemon-reload and try it again - should work now with the correct config file.


Socket Error Connecting to Nanopool with xmr-stak

That indeed looks like a DNS error. One thing you can try is swapping the FQDN with the IP address to confirm it's somewhere in the DNS resolution. I've had to do that on a couple large pools.

In other words xxx.xxx.xxx.xxx:14444


Is there a block explorer that shows raw blocks?

https://xmrchain.net (source: https://github.com/moneroexamples/onion-monero-blockchain-explorer).

Open source and has various methods to call. E.g.:

https://xmrchain.net/api/rawblock/1637504

Bonus, yes has testnet to.


This is not a definitive proof but we can note the Review of Cryptonote Whitepaper by Surae Noether have this byline "This paper is dedicated to Emmy Noether, Satoshi Nakamoto, and the Bourbaki Group." As far as I know this is the first publication by one of the Noethers regarding Monero. The Bourbaki Group worked a lot on algebra and therefore rings so your hypothesis seems to be right.

Two minors reasons could be the pun on "No Ether" and the possibility to use the initials SN as a nod to Satoshi Nakamoto.


Technically, I think it's possible to use the range proof scheme (whether using Borromean or Bulletproofs) to prove that the amount committed by a given Pedersen Commitment falls within a certain range. A Pedersen Commitment C committing to an amount a using a mask (aka. blinding factor) x is represented as

C = x*G + a*H

where G and H are protocol-defined independent base points. The range proof scheme proves that the committed amount in C falls between 0 and 2^64-1. To prove that the committed amount falls between a specific range, say 50 and 100 XMR, we could define two more commitments

C1 = C - 50*H
C2 = 100*H - C

and generate a new range proof for each of C1 and C2.

This approach could be generalized to involve multiple outputs and prove that the sum of the committed amounts falls within a specified range. For auditing purposes, however, I think it's more useful to prove "I hold at least this amount in my wallet" rather than proving "My holding falls within this range". Such a proof scheme called "reserve proof" is currently being developed (https://github.com/monero-project/monero/pull/3027).

See also: Using Monero as proof of funds


Bitmonerod was the original name provided by thankful_for_today

The community decided to take over the project from TFT following some disagreements and renamed it Monero. The name bitmonerod is still used to refer to the Monero daemon but bitmonero is no longer a correct name for the project. thankful_for_today disappeared and has not posted on Bitcointalk since June 30, 2014.

In addition to changing the name, the trading symbol was also briefly changed to BMR to MRO before the Monero community settles on XMR. XMR was chosen for a specific reason:

  The official ISO 4217 standard specifies three-letter ("Alpha-3") codes for currencies worldwide. Codes beginning with "X", among others, are reserved for special purposes such as non-currency commodities.


Deposit before multisig setup is complete?

You can deposit funds into a multisig wallet as soon as 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).


Block reward penalties and dynamic block size

This limit is based on the median of the last 100 blocks' size, after removing outliers, with a 60 kB lower limit (so blocks can't get TOO small, or you could have a hard time "restarting"). This allows the block size to grow and contract based on transaction volume. The size at which the block reward penalty kicks in is between 100% and 200% of the block size for this coinbase. It follows a continuous function, which I think is quadratic.

See get_block_reward in src/cryptonote_core/cryptonote_basic_impl.cpp for the details of the code.


Kovri network analysis - Monero vs non Monero usage

The kovri traffic is hidden by i2p protocol.
This protocol hide the final destination to each node in the path to this destination.
So there is technically no way to tell if the traffic is monero traffic or anything else.
That's the beauty of i2p.

To be more technical: garlic routing and garlic encryption take care of encrypting your message in the same layered-deepness than the nodes you should go through within the tunnel to your destination.
You will use successively each node public key to encrypt the message layer by layer so that each node on the path will use its private key to decrypt the outer layer and know the next node to pass inner message to, and so on until the final destination.

There is no way to measure the non-monero usage of kovri.


I did exactly this recently. Take a look at:

https://github.com/jtgrassie/xmr-wasm


If I send money with Simplewallet, it'll show that I've both sent and received funds. Why?

This is change coming back to your wallet. For instance, if you send 5 XMR, simplewallet might send that using a 10 XMR input, which it will then split and send 5 XMR to the person you are sending to, and send another 5 XMR output back to your wallet.

See section A, bullet 2 here for a bit more explanation in context:
https://getmonero.org/knowledge-base/protocol_explanation.html


Is there any message in Monero's genesis block like there is in Bitcoin's?

None afaik, Monero (then Bitmonero) was launched as a fork of Bytecoin. Not thats impossible as the Bytecoin blockchain is full of messages and cryptic data:

http://bytecoiner.org/bytecoin-early-adopters-and-secret-messages

https://bitcointalk.org/index.php?topic=512747.msg7126913#msg7126913

obs: there is large suspicion that the bytecoin blockchain was faked: https://bitcointalk.org/index.php?topic=740112.0


Daemon terminates when trying to load lmdb from new location

I deleted the data and did a full resync. It took a few days but everything is working fine now. I must have corrupted it somehow, possibly by terminating the daeamon or GUI in the wrong way.

So if anyone has the same problem (monerod.exe terminating on startup), probably the best solution is to resync.


What is the difference between tx version 1 and RingCT version 2?

Pre-RingCT (tx version 1), the main difference is the amounts were not hidden. They still had a form of ring-signature, but no, there were no signature types like the RCTType... ones as found in RingCT transactions - because they were not RingCT transactions.

RingCT (tx version 2), generalized a new type of ring signature, LSAG, into an MLSAG signature and incorporated Confidential Transactions to hide the amounts. The original RingCT paper can be found here which describes the changes and background.


What is the checksum at the end of a mnemonic seed?

General

The purpose of a checksum is exactly what the word means - to "check" something, and the simplest form of it is to check the sum.

In general, checksum is a way to let you know if you got the right sequence of numbers. Let's say you have to write down 4 numbers, and use an extra 5th digit as a checksum where the 5th number is calculated by summing the first 4 number and taking the last digit of the result.

Example:
63841
(6+3+8+4 = 21)

Now, if I mistype one digit:
63941, the checksum would be invalid (6+3+9+4 = 22) and the mistake would be detected before, for example, sending funds to wrong acct. number or whatever you use the number for.

Monero Mnemonic Seed Checksum

The checksum is well described on https://xmr.llcoins.net/addresstests.html, and it's insightful to download the javascript code and inspect it to find answers.

  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.

So, yes - last word is the checksum, and current implementation won't accept 24-word seed. In theory, one could recover his wallet from 24-word seed, but would need to tweak the code himself to skip the checksum check, or recompute the 25th word before restoring the account.

Looking into the code, we find that the checksum is calculated by concatenating first 3 letters (if English dictionary is used) of each word, calculating CRC32 checksum of the string, and picking the word from the list, corresponding to the checksum result (divide CRC32 by number of words being checksummed, and the result is a 0-based index of the checksum word).

So, checksum word can be unique (i.e. not found earlier in mnemonic), but it will always repeat one of the words found in your mnemonic. And yes, you could, with some tweaking, create a mnemonic without the checksum, but it's not advised to do so.

Monero Mnemonic Seed Checksum Calculation Example

Inspecting the mnemonic.js file found on this site, made by one developer from the core team (Luigi1111), we find the relevant function:

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.

Why is it good to have?

The main purpose is the error-check. If you're restoring a wallet from backup and make a mistake somewhere, the checksum would tell you that you made a mistake. Of course, you could also check yourself that the resultant address is matching, but this is a lighter check done automatically so that you don't have to compare all those letters.

In addition, it helps with recovery if you lose one or two words. If you know the matching address and have the checksum, it takes about 40 minutes to recover the 2 missing words using one tool written in javascript. Without the checksum it would take roughly 24 times that - 16 hours!


What changes are in the Monero 0.11.0.0 release?

Major improvements

minimum ringsize increased from 3 to 5
mandatory RingCT for all transactions
major synchronisation speed-up
massively improved the blockchain import function
changed terminology from "mixin" to "ring size"
add a --fluffy-blocks option to relay blocks as fluffy blocks if possible
allow for password verification without loading the subsequently unencrypted - - - wallet into RAM
reduced privacy leak risks when using untrusted remote nodes

Full release notes can be found on Github as usual.


Tutorial on how to make a trade on the Bisq Decentralized Exchange using Monero to Bitcoin?

Check out this guide to understand how it all works.

BTW: Not only has the computer to be turned on, but the trader also has to be online


How to use a remote node on a very bandwitdh restricted connection?

If you update to the coming release, and if the remote node you're using is using a recent daemon (the one that'll come with that release), the bandwidth will be much less when refreshing the wallet.

For current blocks (ie, after the ringct change), the bandwidth should be less than 5% what it was.


Can someone help me read a block explorer?

I'm not sure if you understand the CryptoNote protocol sufficiently. If not, the whitepaper should probably be the first resource for you to consult with.

RingCT was first published in MRL-0005, but some of the details are different in the current implementation.

I have made several posts trying to understand (and explain) how RingCT works:

Questions regarding the cryptography behind RingCT
Does the key vector approach in RingCT represent linkability among transactions? Can it be exploited by blockchain analysis?
Can I manually check consistency of Pedersen Commitments in RingCT?

I hope these posts are helpful to you. Anyway, I try to answer your questions below. Let's take the following transaction as an example:

947433d235244bf323fd33b8a1da3cca3d77f55b08e062049f7eae35eb5d77d1

  I see first of all 2 outputs with amounts of 0.

These are 2 new outputs created in this transaction. Their amounts are 0 because they are in the RingCT format.

  Then below I see 2 inputs that are broken down into groups of "stealth" addresses. Each of the 2 groups have an amount incidated.

This example transaction has 4 inputs, and their amounts are indicated (0.7, 0.02, 0.005, 30.0) since they are in the pre-RingCT format.

  I am trying to figure out what input and output actually mean and why input has amounts and output does not (I thought amounts would not show anywhere now).

The reason why the inputs have nonzero amounts and the outputs have zero amounts is because this transaction is converting pre-RingCT outputs to RingCT outputs. Another example below is a RingCT-to-RingCT transaction, so all the amounts are zero on both inputs and outputs:

2b39c3f9e6d65fd9b2e59be412bcfd9fb234951ab7bcb28639ffbaa7a4579108

  Also, it seems that mixin level cannot be determined on a blockexplorer. It seems that whatever mixin I use, it shows 2 outputs.

The mixin level is indicated by the number of keys in each of the groups. In the above two examples, the mixin are 3 and 2, respectively. Typical RingCT transactions have two outputs, one going to the payment destination and the other going to yourself as the change.


How to Use Monero Multisignature Wallets (2/2 & 2/3)

Monero 2/2 Multisig

First, the wallet to be converted to multisig must be empty. It is best to use a brand-new walllet for the purpose, although not required. It is strongly advised to make a copy of the wallet files first, just in case something goes wrong.

Set-up

Step 1 Initiate Creation of Multisig Wallet and Exchange Data

Person A commands:

[wallet 47HSuD]: prepare_multisig

The output will be something like:

    MultisigV1WHyBiEPV5rv3jgU59QUv2ZYTvmN3pwzCL8mp5jTDxkkhRzDjL1T8A2dHTYLmprbUsiLzvPLqRc1GkFHp3mq7dFq6BiE98Ur5cD6P46YYLd5QwD4diqe4VRSiS7GYHATbL4cLGidyNUbWha4EU7ET2jfJ7UKUVZRhNb5prZxfsJddbzaw
Send this multisig info to all other participants, then use make_multisig <info1> [<info2>...] with others' multisig info
This includes the PRIVATE view key, so needs to be disclosed only to that multisig wallet's participants

Copy the entire line Multisig...bzaw be sure to capture the whole thing when copying. Send this line to person B.

Person B does the same and sends his output to person A. Person B commands:

[wallet 48e86K]: prepare_multisig

Person B gets the output

MultisigV1ZST26VmNuozbbHL9PeDuqiLDuMLCmaCRxBBLoK7yuxsHXyUiMr2SjxXgnsWrbmVRpghFTtcHEDLDnbPcqdoSuum1bLCFvmoFGrK7z3AtizKPTG96ukb4mzzqPcCD55ZCb1Y8cUL4RipVtcB4YbzZyK5eZdRLxAKi8TvyTD9h3QjVraXs
Send this multisig info to all other participants, then use make_multisig <info1> [<info2>...] with others' multisig info
This includes the PRIVATE view key, so needs to be disclosed only to that multisig wallet's participants

and sends it to person A.

Step 2 Create Multisig Wallets

Both person A and person B now have the Multisig... text from the other one. With that, each of them can create their part of the multisig wallet. Before you proceed, note that the wallet will lose access to the underlying account when converted to multisig. This is not really a problem, since we started with an empty one, and if all goes ok with this step, you won't ever need it unless you want to go through the process again for whatever reason (like HDD died, but you have the seed mnemonic of the underlying account and want to reconstruct the multisig wallet).

Person A commands:

[wallet 47HSuD]: make_multisig 2 MultisigV1ZST26VmNuozbbHL9PeDuqiLDuMLCmaCRxBBLoK7yuxsHXyUiMr2SjxXgnsWrbmVRpghFTtcHEDLDnbPcqdoSuum1bLCFvmoFGrK7z3AtizKPTG96ukb4mzzqPcCD55ZCb1Y8cUL4RipVtcB4YbzZyK5eZdRLxAKi8TvyTD9h3QjVraXs

and the output will be something like:

2/2 multisig address: 47RGRFeLPT51qvDWuw7SGf57JK7AziAVqYucct8z5yEDQ1XqU8zKEjidWjqPXk7PuHP3MJDN2AJATKy9PH7zaGV7MB8X6CH

Person B commands:

[wallet 48e86K]: make_multisig 2 MultisigV1WHyBiEPV5rv3jgU59QUv2ZYTvmN3pwzCL8mp5jTDxkkhRzDjL1T8A2dHTYLmprbUsiLzvPLqRc1GkFHp3mq7dFq6BiE98Ur5cD6P46YYLd5QwD4diqe4VRSiS7GYHATbL4cLGidyNUbWha4EU7ET2jfJ7UKUVZRhNb5prZxfsJddbzaw

and the output should be something like:

2/2 multisig address: 47RGRFeLPT51qvDWuw7SGf57JK7AziAVqYucct8z5yEDQ1XqU8zKEjidWjqPXk7PuHP3MJDN2AJATKy9PH7zaGV7MB8X6CH

Now exchange addresses and compare, they must be the same.

Receiving

Step 1 Fund The Multisig Account

This is simple. Just send to the shared address. You can send multiple times, same like normal wallet. You can use payment ID as well, or generate an integrated address to receive funds.

Best part, whomever is sending the funds won't be able to tell that the address belongs to a multisig wallet since it looks as any other.

Step 2 Check Multisig Account Balance

Just open the wallet and command refresh. Once completed, both persons can verrify that the funds arrived.

Person A commands:

[wallet 47HSuD]: show_transfers and can see all incoming transfers.

 1357156     in      07:50:35 PM       0.100000000000 88ba687dc79a0b39e6de6d0763eda8363d33d9f58ec9a096171bd9a7f1dae873 0000000000000000 -
 1357161     in      08:00:18 PM       0.100000000000 d6ac845b9400759525519cdc5d514eb8f5b1d265b24d1c016e75b20ed3b4b7da 0000000000000000 -

Person B can do the same:

[wallet 48e86K]: show_transfers and will see the same:

 1357156     in      07:50:35 PM       0.100000000000 88ba687dc79a0b39e6de6d0763eda8363d33d9f58ec9a096171bd9a7f1dae873 0000000000000000 -
 1357161     in      08:00:18 PM       0.100000000000 d6ac845b9400759525519cdc5d514eb8f5b1d265b24d1c016e75b20ed3b4b7da 0000000000000000 -

Spending

Step 1 Syncronizing Key Images

Without this step, it will not be possible to create a spending transaction.

Person A commands:

[wallet 47HSuD]: export_multisig_info testmp1 where testmp1 can be any filename. The output will be:

Multisig info exported to testmp1

The file testmp1 will be located in the shell working folder*

Person A sends that file to Person B.

Person B does the same and commands:

[wallet 48e86K]: export_multisig_info testmp2 and the output will be:

Multisig info exported to testmp2

The file testmp2 will be located in the shell working folder*

Person B sends that file to person A.

Now, they must both import each other's file.

Person A commands:

[wallet 47HSuD]: import_multisig_info testmp2 (the wallet will look for it in the shell working folder*) and the output will look like:

2 outputs found in testmp2
Height 1357156, transaction <88ba687dc79a0b39e6de6d0763eda8363d33d9f58ec9a096171bd9a7f1dae873>, received 0.100000000000
Height 1357161, transaction <d6ac845b9400759525519cdc5d514eb8f5b1d265b24d1c016e75b20ed3b4b7da>, received 0.100000000000

Person B commands:

[wallet 48e86K]: import_multisig_info testmp1 (the wallet will look for it in the shell working folder*) and the output will look like:

2 outputs found in testmp1
Height 1357156, transaction <88ba687dc79a0b39e6de6d0763eda8363d33d9f58ec9a096171bd9a7f1dae873>, received 0.100000000000
Height 1357161, transaction <d6ac845b9400759525519cdc5d514eb8f5b1d265b24d1c016e75b20ed3b4b7da>, received 0.100000000000
Multisig info imported

Step 2 Preparing Spending Transaction

Either person A or person B can do this, it doesn't matter. To avoid weird things from happening only do it for 1 transaction at a time.

Person A performs the usual transfer command:

[wallet 47HSuD]: transfer 47wbKEXBGnyHohezMGpD6y2SFNczrSpeSfQgFW5cMxMziFuHpBWM9yjBLJ1iTv31AwN6daPg1QXfRKBJGq2XZDekNqv8gsP 0.15

The output will look like:

Unsigned transaction(s) successfully written to file: multisig_monero_tx*

Check in the folder where you started monero-wallet-cli from*. There should be a file named multisig_monero_tx.

Send the file multisig_monero_tx to the person B.

Person B must finish the signature. Person B copies the file to the same folder from where he started (or will start) monero-wallet-cli*.

Then, Person B commands:

[wallet 48e86K]: sign_multisig multisig_monero_tx and a prompt will be displayed to allow person B to check the transaction before signing:

Loaded 1 transactions, for 0.200000000000, fee 0.015570240000, sending 0.150000000000 to 47wbKEXBGnyHohezMGpD6y2SFNczrSpeSfQgFW5cMxMziFuHpBWM9yjBLJ1iTv31AwN6daPg1QXfRKBJGq2XZDekNqv8gsP, 0.034429760000 change to 47RGRFeLPT51qvDWuw7SGf57JK7AziAVqYucct8z5yEDQ1XqU8zKEjidWjqPXk7PuHP3MJDN2AJATKy9PH7zaGV7MB8X6CH, with min mixin 4. Is this okay? (Y/Yes/N/No):

If ok, answer Y, and the output will look like:

Transaction successfully signed to file multisig_monero_tx, txid bb998b00dad0c245b45b975277d9b685592b412fd5fb58b2c1805091418c8b49.

Finally, person B submits the transaction to the network by commanding:

[wallet 48e86K]: submit_multisig multisig_monero_tx and there will be a confirmation prompt:

Loaded 1 transactions, for 0.200000000000, fee 0.015570240000, sending 0.150000000000 to 47wbKEXBGnyHohezMGpD6y2SFNczrSpeSfQgFW5cMxMziFuHpBWM9yjBLJ1iTv31AwN6daPg1QXfRKBJGq2XZDekNqv8gsP, 0.034429760000 change to 47RGRFeLPT51qvDWuw7SGf57JK7AziAVqYucct8z5yEDQ1XqU8zKEjidWjqPXk7PuHP3MJDN2AJATKy9PH7zaGV7MB8X6CH, with min mixin 4. Is this okay? (Y/Yes/N/No):

If ok, answer Y, and the transaction will be sent. The output will look like:

Money successfully sent, transaction:
<bb998b00dad0c245b45b975277d9b685592b412fd5fb58b2c1805091418c8b49>

The person B could also send the signed TX to person A, who could then submit it to the network himself.

If you want to make another one, you have to go back to step 1 of spending (sync the key images again).

*Note on folders and file locations, as it could create some confusions. The wallet will look for the files and export them to the folder from where it was started, ie where your command prompt / shell was when you called monero-wallet-cli. It may or may not be the same folder as your actual wallet files or monero-wallet-cli, depending on how you go about it.

For example, your wallet could be on some USB drive like f:\temp\, and your wallet software on c:\monero\ and your shell working folder could be c:\.

If you remain in c:\ with the shell, you could start the wallet by its full path and specify the wallet file location: c:\monero\monero-wallet-cli.exe --wallet-file f:\temp\mywallet. In this case, all the import/export stuff would be read/written to c:\ because that's still your shell's working folder.

It would be probably feel more natural to cd into the wallet folder. Do f: to change drive and then cd f:\temp\. Then, simply start the wallet from that location by its full path again: c:\monero\monero-wallet-cli.exe --wallet-file mywallet. Notice how you don't have to write the full wallet path now as you're already there with your shell. In this case, all the files mentioned above would be written or read from the same folder as the wallet files.


1) Edit the config.txt file by changing the "pool_address" field in the "pool_list" section. You could also have a list of additional pools and adjust the weights as you wish (e.g. mentioning some backup options).

OR

2) Delete the config.txt file. Next time you run the executable it will ask you to set the target pool as it did on the first run (it will also ask for the rest of configs as it did then).


Here's the curl command I use:

curl -X POST http://127.0.0.1:5000/json_rpc -d '{"jsonrpc":"2.0","method":"getbalance","id":"test"}' -H "Content-Type: application/json"

Your JSON seems to be formatted entirely incorrectly, as name=value pairs, so check the library you're using to produce the JSON.


You use the get_outs.bin RPC. You give it the indices of the outputs you want.

If you don't know which outputs you want, then you can't ask the daemon anymore. This RPC had three problems: (1) the daemon had control over the outputs (an obvious attack vector), (2) the wallet could ask particular setups which would cause the daemon to spend a LOT of time carrying these out (a DoS attack vector), (3) the algorithm the daemon implemented was old and picked outputs with less quality than the wallet already did. Thus, the call was removed.

Note that this is only needed if you go really low level. In normal usage, you'd use the wallet's transfer_split RPC which handles all this transparently.


What does it mean when the Monero daemon says "LMDB Mapsize increased"?

For performance reasons, LMDB asks the OS to preallocate its storage space in large chunks, instead of growing incrementally as new records are added. Periodically this space must be increased as the actual usage increases.


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

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

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


Error Message When Running Monero Core GUI

Using Wolfram Warptangent v0.10.0 release fixed this problem.

https://github.com/monero-project/monero/releases/tag/v0.10.0

However, I found just using the regular public testnet works better than a private testnet . It is difficult to find enough mixins in private testnet.  The minimum mixin is 4.

https://github.com/mbg033/monero-core/issues/53


How to create and sign a monero transaction by hand

The wallet RPC has a method transfer which you can call with parameters do_not_relay:true and get_tx_metadata:true which will allow you to create a transaction but not relay to the network immediately. When you are ready to send, you can call the method relay_tx.


Is there a monerod config file to change certain settings when you run monerod in linux?

You can create one in any directory you have permissions to access and name it anything (such as monero.conf). Add any of the options used on daemon startup, but leave off the leading double-dash (--). The examples I have seen separate key from value with an equal sign (=) instead of a space. (The space separator is used on the command line.)

Here's an example I found:

# /etc/monero/monerod.conf

# Data directory (blockchain db and indices)
data-dir=/nocow/blockchain/monero

# Log file
log-file=/var/log/monero/monerod.log
max-log-file-size=0            # Prevent monerod from managing the log files; we want logrotate to take care of that

# P2P full node
p2p-bind-ip=0.0.0.0            # Bind to all interfaces (the default)
p2p-bind-port=18080            # Bind to default port

# RPC open node
rpc-bind-ip=0.0.0.0            # Bind to all interfaces
rpc-bind-port=18081            # Bind on default port
confirm-external-bind=1        # Open node (confirm)
restricted-rpc=1               # Prevent unsafe RPC calls
no-igd=1                       # Disable UPnP port mapping

# Slow but reliable db writes
db-sync-mode=safe

# Emergency checkpoints set by MoneroPulse operators will be enforced to workaround potential consensus bugs
# Check https://monerodocs.org/infrastructure/monero-pulse/ for explanation and trade-offs
enforce-dns-checkpointing=1

out-peers=64              # This will enable much faster sync and tx awareness; the default 8 is suboptimal nowadays
in-peers=1024             # The default is unlimited; we prefer to put a cap on this

limit-rate-up=1048576     # 1048576 kB/s == 1GB/s; a raise from default 2048 kB/s; contribute more to p2p network
limit-rate-down=1048576   # 1048576 kB/s == 1GB/s; a raise from default 8192 kB/s; allow for faster initial sync


Error when trying to reach own remote node

status uses a few RPC to the daemon, and one of them (asking for mining status) is restricted. Calling it errors out since you used --restricted-rpc, and you see it tells you "mining info unavailable".

If you want to get access to the server's mining info, remove --restricted-rpc (but then anyone else can get that info from your server). In that case you probably want to connect through a ssh tunnel, or set a password.


Time from the block added to the pool to time it gets executed

Firstly, blocks don't get "added to the pool". A wallet instructs a daemon to broadcast a transaction which gets added to the transaction pool. A miner constructs a block template by bunching transactions that are in the transaction pool, then mining that block template. When a miner successfully mines a block, it is broadcast to the network, and if valid, get's added to each peers blockchain.

If you need an external notification when your node adds a block to your blockchain, you can use the parameter --block-notify when starting your node, which will instruct it to execute a program every time a block is added:

monerod --help
  ...
  --block-notify arg                    Run a program for each new block, '%s'
                                        will be replaced by the block hash
  ...

You can also call the daemon's RPC method get_last_block_header, which includes a timestamp field in the response. Note that this timestamp however is a miner created timestamp, not the time your node added the block to your local blockchain.


Why must each input have a separate set of decoys?

Mixin 6 means a ring size of 7.

Having 2 real inputs and 5 decoys for an overall ring size of 7 is a lower level of privacy than the current implementation, which would be 2 real inputs and 12 decoys as part of two rings of size 7.

It would be worse if you were spending 6 inputs. You'd have only 1 decoy, so your privacy level would drop enormously.

Providing a consistent level of privacy no matter how many inputs are being spent is therefore an important design goal.


What are the reasons for running a full node on a VPS? How can I do this?

What are the reasons for doing this

First, a full node hosted on a VPS ensures high uptime. If you run a node on a personal computer, you will likely only run it partially, because you turn your computer off from time to time. Higher uptime is better for the network. However, ideally, such a node would run off a personal computer instead of a VPS. There's always an aspect of centralization with respect to VPS providers which people have to keep in mind when making such a decision.

Additionally, people might find it more convenient to run their node on a VPS.

  and how might I do it too?

There's a guide on the official website:

  monerod

  monerod is the daemon software that ships with the Monero tree. It is a console program, and manages the blockchain. While a bitcoin wallet manages both an account and the blockchain, Monero separates these: monerod handles the blockchain, and simplewallet handles the account.

  This guide assumes you have already set up your VPS account and are using SSH to tunnel into the server console.

  Linux, 64-bit (Ubuntu 14.04)

  Make sure that port 18080 is open

  monerod uses this port to communicate with other nodes on the Monero network.

  Example if using ufw: sudo ufw allow 18080

  Example if using iptables: sudo iptables -A INPUT -p tcp --dport 18080 -j ACCEPT

  Download the current Monero Core binaries

  wget https://downloads.getmonero.org/linux64

  Make a directory and extract the files.

  mkdir monero
     tar -xjvf linux64 -C monero

  Launch the daemon

  cd monero
     ./monerod

  Options:

  Show list of all options and settings:

  ./monerod --help

  Launch the daemon as a background process:

  ./monerod --detach

  Monitor the output of monerod if running as daemon:

  tail -f ~/.bitmonero/bitmonero.log


What's the appropriate place to add additional validity checks for transactions?

This is a good place, yes. This is called before a (non coinbase) transaction is accepted, except when running monero-blockchain-import with verifiction turned off (which you should not do unless you exported the file yourself). It will be called also when reorgs happen.


monero-wallet-cli Error message: refresh failed

See comment above. This is a bug. Coins are not at risk.


Do Monero and other Cryptonotes compile and sync on big endian CPUs?

Yes, it should compile and sync.

Endianess is relevant is several parts of the Monero source code:

SHA256 (hash function)
Skein (also a hash function)
int-util.h (various small utily functions acting on integers)
LMDB (blockchain database)

The definition of BYTE_ORDER varies from one operating system to an other.
Some of these libraries (SHA512 and LMDB) are external and other files come from Cryptonote so they use various ways to determine the BYTE_ORDER.

In case of Big Endian, it may be needed to edit src/platform/msc/sys/param.h, external/db_drivers/liblmdb/mdb.c and/or external/unbound/compat/sha512.c if the symbol can't be determined otherwise.


Problem starting mining using Monero GUI wallet? ("Couldn't start mining")

You seem to be set-up ok but if you're going to solo-mine you need to be fully synced with the network. This is because mining a block requires info from the latest block.

This line tells you that you're not synced:

stacktrace:INFO Height: 105797/1358660 (7.8%) on mainnet


The crypto_ops::generate_signature function is using the Schnorr signature scheme.


For people with spare Raspberry Pis what is the easiest way to get a full node running?

For your pi 3, just grab the ARMv7 binaries. https://getmonero.org/downloads/
They'll work for pi 2 as well. If anyone is trying to run a node on pi 1 or pi zero, I can upload ARMv6 binaries but I believe the plan is to drop support for these ARMv6 devices soon.

ARMv6 binaries now available: https://www.reddit.com/r/Monero/comments/543euo/monero_unofficial_arm_builds/

Also ARMv8 binaries for boxes running 64bit OS. This excludes raspberry pi 3, which only ships with a 32bit OS, and doesn't support ARMv8 crypto instructions.


Can I mine with an Intel Celeron R 1820?

You can, but don't expect to mine a block any time soon with such a low powered CPU.


Is it okay to host a node that connects on the clearnet?

This is related to your local juridiction.
In most countries, running an application, as long as it does not break any existing laws, is totally legal.

If something change in the future, it might just be on the taxation of cryptocurrencies themselves.
Nodes owner may not be targeted by this taxation, or may be depending on your juridiction.

To summarize: look at your local laws to ensure your not breaking any (it's highly improbable you are) to run a node today, and stay tuned to your juridiction's new law to avoid breaking them.

But in the future, Kovri will be in General Availability release and integrated to Monero so that you shouldn't be seen by any juridiction.
This could help you to continue using the software in case of banishment, if regulators don't manage to apply a taxation model on secure cryptocurrencies.  That said, i would not push you to break any law.


How could you lower the risk of accepting zero confirmation transactions?

Connecting to more nodes increases the speed at which you will see a transaction double spending one you already have in your txpool, and thus mark this transaction as such. However, this is not foolproof since a miner does not have to relay a transaction for it to be mined.

Thus, this is risk based calculation, which should depend on things like the amount involved, whether a double spending tx was seen (since you don't know which one will get mined), how much recourse you have in case of actual double spend, the amount of time you wait for a possible double spend before acting on the tx, etc.


Start 2 nodes of a stagenet which only like talking to each other:

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

Then start cli wallet on the same machine:

monero-wallet-cli --stagenet

and create a wallet. Use your new stagenet address to mine on one of the nodes by typing

start_mining <yourwalletaddress> 1

in the monerod window.

Notes:

This also works on windows
The above statements will create two directories in the working directory named node1 and node2 to hold the blockchain.
The new wallet files will also be in the working directory.


Is seems to be a bug: monero-wallet-rpc should have printed an error message in RED telling you that it could not find curl, because you did not give the path to it. Surely, since you would have obviously read such an error message if one had been present, it must have been missing.


The problem was exactly that - possible forgery. In the RCT paper, there was a proof that you can't forge ASNL range proof which later turned out to have an error. See here for more details.

Why do we need these proofs / signatures? From the RCT paper (emphasis mine):

  ... as -1 is a very large number modulo the curve group order, free
  money has been created. It is therefore necessary to prove that the
  C_out,i are commitments to values which are positive and lie in a
  restricted range [0,2^n] for some n.

These signatures are used to prove that one is not using just anything to hide the amounts, ie to prove what I've highlighted above. It's important because allowing just anything would make it possible to cheat the sum(ins) == sum(outs) part of transaction verification. It's important that the proof be airtight, otherwise you could make a transaction where sum(ins) != sum(outs) but which would be validated as if both sides were equal.

The ASNL proof was not good, so it was replaced with Borromean. With ASNL it would have been possible to create an exploit (as the author of your linked post did) which could create or destroy monero, and bypassing the intended coin supply. A scary thought indeed.


How to check whether monero-wallet-rpc is running?

If you know the port monero-wallet-rpc listens on, you can connect to that port to see whether something is listening. This is what the python RPC layer does.
From utils/python-rpc/console.py in the Monero tree:
  # check for open port
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.settimeout(1)
  if s.connect_ex((host, port)) != 0:
    raise Exception('No wallet or daemon RPC on port ' + str(port))
  s.close()


Transaction stuck as "pending" in monero-wallet-cli

You can first use the show_transfers command in monero-wallet-cli to see if your transaction shows there. It should show as "pending". Subsequently, you can use the flush_txpool command in monerod (the daemon). The wallet will shortly notice this and change the status of the transaction from "pending" to "failed". In order to get the right balance, however, you also need to run the rescan_spent command in monero-wallet-cli. Note that this minor bug (i.e. not showing the correct balance) is fixed in master currently, but not yet present in the binaries (which you are likely using).

If this doesn't work, you will have to use the rescan_bc command in monero-wallet-cli.

  Also, what steps can I take to prevent a transaction from getting stuck as pending in the future?

Make sure your daemon is fully synced before sending out a transaction.

Source: https://bitcointalk.org/index.php?topic=583449.msg16066918#msg16066918

EDIT 11/9/2017: Currently, transactions will drop from the local mempool after 24 hours, which will result in the transaction status changing to Failed in monero-wallet-cli. Therefore, this answer is not applicable anymore. If, however, your transaction is not relayed and your transaction is time sensitive, you can still apply this answer. You can check if your transaction is relayed by checking the mempool on block explorers like, for instance, XMRchain, MoneroBase, or MoneroBlocks.


How does a node maintain its anchor peer list?

Leaving aside exclusive peers, when a node starts for the very first time, it connects to the seed peer(s) to get an initial peer list. It then attempts to maintain at least 2 anchor peers (if it successfully handshakes with an attempted peer and doesn't already have enough anchor peers, it can be added to the anchor list).

If an anchor node goes away, it is removed from the peer list and another white peer is attempted to be added as a new anchor. The node also broadcasts its updated peer list.

All other peers are either in the gray or white peer lists. The gray list contains a list of peers that the node has not attempted to connect to and the white list contains a list of peers the node has successfully performed a handshake with.

Whenever a new peer list is broadcast (so from one of the connected peers), the white and gray peers received get merged into the receiving nodes peer list. The node then broadcasts this list with it's connected peers.

Essentially, each node needs to maintain some connected nodes, some nodes known to be online and some nodes not yet attempted to connect to. connections_maker is called periodically to keep these lists healthy.

Lastly, the nodes peer lists are persisted to ~/.bitmonero/p2pstate.bin. This is saved periodically and on shutdown. Upon startup, it is loaded to initialize the peer lists, which puts less reliance on the seed nodes (e.g. if you connect to enough peers from the saved peers, there is no need to use the seed nodes, they become fallbacks).


Is it possible to create a lighter wallet than simplewallet without giving up a view key?

Most of the space in a block is transactions. Most of the space in transactions is signatures (especially with RingCT). The wallet doesn't actually verify signatures, the daemon does it (you're running your own daemon, right ?) Signatures are an obvious candidate for eliding when transmitting new data from the daemon to the wallet.

Pretty much all of the rest in a transaction is needed if the wallet keeps the keys, but it's not very much. The block data can be skipped, if you must. You lose things like timestamps, but hey, you want light.


Which ASIC manufacturer (if any) made ASICs for XMR in the past?

There may have been others, but at least Baikalminer[archive] and Bitmain[archive] launched Monero ASIC miners in 2018.

It's worth noting Bitmain allowed people to buy the ASICs, but didn't actually ship them until after the Monero hardfork - meaning only Bitmain themselves were able to mine XMR on their own ASICs, and knowingly scammed their customers thereafter.


Is the connection over Tor between client and remote node safe?

Your wallet password is local to the wallet. It's not sent to the daemon, which never gets hold of that, nor the wallet keys. Using Tor, information is encrypted between your own tor daemon (though if you're going to use a third party Monero daemon, you might be using a third party Tor daemon, which is even worse) and the destination hidden service, so any snooper in the middle is not going to see anything unencrypted.


Problem with compile part of monero sources to create python bindings

This is not specific to Monero, rather a C/C++ linking question, nevertheless...

The order you add the libraries matters. In your example:

...
/usr/bin/c++ _build/pymonero.cpp.o -o pymonero \
-L$MONERO_DIR/src -lversion \
-L$MONERO_DIR/src/cryptonote_basic -lcryptonote_basic \
-L$MONERO_DIR/src/device -ldevice \
...

Linking CXX executable pymonero
./monero//src/device/libdevice.a(device_ledger.cpp.o): In function `hw::ledger::device_ledger::reset()':
device_ledger.cpp:(.text+0x4a52): undefined reference to `MONERO_VERSION'
collect2: error: ld returned 1 exit status

You have specified version before device, which is why you are getting a linking error. All your libraries need to be in the correct order based on their dependencies. Linking searches forwards for symbols, not backwards.


Transaction Hash with only a Confirmation

Confirmations are number of blocks since the tx was mined. From that number, you can deduce the block the tx is in. There will likely be several transactions though, so yours will be one of them.
A typical reason for monero not appearing in a wallet is that wallet having an incorrect setting for "refresh-from-block-height". This causes the wallet to skip transactions it thinks are too old to be yours. To fix this, run monero-wallet-cli on the wallet, and type:

set refresh-from-block-height 0
rescan_bc

Then quit monero-wallet-cli.


Simple explanation of Monero mechanics - how does Monero work?

First of all, there are no addresses on the blockchain. Imagine the blockchain as a bunch of lockers which all look the same. The blockchain holds only the records from which to which locker funds get transferred. Now, how does it work?

Think of your address as containing a special blueprint (public spend key) and a special recipe (public view key). Sender picks a random locker, puts his funds inside, and uses your blueprint to produce a special lock, one which only you can open. Also, he uses your recipe to produce a transparent paint and writes some random number with this. Only you have a special flashlight (private view key) to light up the lock and see that there's a mark. So you recognize the lock as yours because the paint lights up, you read the random number written (shared secret) and use a special forge only you have (private spend key) to create a unique key which can open only that particular lock (one-time key).

To find a locker locked with a lock for you, you need to approach each one of them and light them up with your flashlight. If the sender didn't write down on which one he put your lock, even him won't be able to find it anymore!

So we have all this lockers (outputs), some of them contain monero and some have been emptied already. Thing is, everyone can see 'you' walking to a locker. If you only approached one locker (case of mixin=0, not possible with Monero anymore), anyone could tell that monero was moved from exactly that one to another one. This would allow someone to trace any monero back to the first locker (coinbase transaction). Here's where ring signatures come to play. Instead of just walking to one locker, you visit a few of them and use a blanket to hide what you're doing with it. You visit 5 lockers (mixin=4) in total. At the end, you show to everybody that you now have some monero in your hands. You have it because you were able to open one of the lockers visited (the one which was actually yours). Thing is, nobody knows from which one you took it! You go on and put it into another one and craft a special lock and mark it with special paint ...

The blockchain records which 5 lockers were visited when sourcing monero to put in the new one. Every time someone moves monero, he must visit a few lockers. You obviously must visit your one, and you can pick from any other lockers to hide which one was yours. The more transactions you make, the more complex the trail becomes. The more lockers you visit on each transaction, the better you hide your activity. Further back you try to trace the source, the more possibilities there are, so both number of lockers and number of transactions increase overall privacy. Also, since other people can visit your locker and pretend to have taken from it, they improve privacy for not just them, but for you as well.

Why do we usually visit 4 decoy lockers? See MRL-0004 for some insights.

  We recommend a network-wide minimum mix-in of n = 2 to address zero mix chain reaction problems, and we discuss how a mix-in of n = 4 is likely to be larger than necessary for most practical purposes. We recommend a nonuniform transaction output selection method for ring generation to mitigate age-based association problems. We recommend partitioning all transactions into many smaller sub-transactions such that they occur over an interval of time, as in a
  torrent, and such that each sub-transaction has one and only one output, in order to mitigate the combinatorial analysis problem.


How many confirmations to be sure a transaction does not end up in an orphaned block?

Leaving aside the fact that "sure" is a subjective concept...

The network uses 10 blocks and 60 blocks to unlock monero coming from a user transaction, and a coinbase transaction, respectively. These provide guidelines as to what the Cryptonote creators thought to be reasonably safe values.

You could also look at what number of confirmations exchanges require. Kraken uses 15 confirmations, for example (http://blog.kraken.com/post/155126375697/kraken-launches-monero-trading).

For clarity, there is no such thing as 100% sure. All you can do is estimate a probability and error bars.


Monero CLI show_transfers coming in that are less than X amount

One of many possible ways:

monero-wallet-cli --wallet-file yourwallet --password 'yourpass' show_transfers in \
    | sed 1,11d | perl -ane 'print if $F[5] < 10'

Prints all incoming transfers less than 10 XMR.

You can omit the sed 1,11d if you also want the header lines.


Just shooting from the hip, but

Average time: time between good results

Pool side hashes: all the hashes you sent (Depends on your diff and H/s)

Top 10: results with the highest difficulty

(could be, and probably, off base)


How is the Monero wallet picking outputs for transactions to spend?

There is a lot of code indeed.

Since you mention temporal alignment, I assume you mean selection of the real outputs (as opposed to fake ones). The code is in src/wallet/wallet2.cpp, and the interesting functions are:

get_output_relatedness: this returns a score for how much two outputs are thought to be related (ie, same tx, from similar heights...)
pop_best_value_from: this will pick a new output, trying to keep to outputs which aren't related to ones we already picked
create_transactions_2: this is the main function, and it creates the transaction(s)

There's an attempt to build a tx with one or two outputs. If this fails, random outputs (unrelated, if possible) will be selected until enough monero is gathered. If a single input is enough, a second one will be used too, if an unrelated one is available, and it will be the smallest (in terms of monero).

That's the general idea. See the code mentioned above for all the details.


Is the blockchain size on disk smaller with v0.10.0?

User /u/blasium reports on Reddit that:

  FYI: The blockchain went from 17 GB to 8 GB for me

The exact decrease may vary depending on your setup (such as OS and filesystem).


What's the easiest way to create a unique job for every worker of monero mining pool?

Every Monero pool I know of (including the pool you linked), reserves 32 bytes in the block template for the purposes of dealing with job uniqueness, which is laid out something like:

job_nonce | instance_nonce | pool_nonce | worker_nonce

Here, job_nonce would be unique to the job, instance_nonce unique to the server and lastly pool_nonce and worker_nonce is space a mining proxy can use.

Thus each server, as you correctly observe, needs to use a unique instance_nonce (per the example above). It doesn't matter what it is, but it needs to be unique. The simplest way of achieving this is to read 4 random bytes. This can be read from /dev/random or /dev/urandom, or anything which sources random data (such as a UUID). Alternatively you could set an instance ID via a pool config file, removing the need to create a random ID, but you'd have to make sure each pool was configured with it's own unique ID.

If you don't need to support proxies, you don't need to reserve the space for the proxy related nonces.

  What is the simplest to do this?

Simplest is probably reading 4 bytes from /dev/random.


Which Monero release should be used on Asus Tinker Board?

The Tinker Board uses a Rockchip RK3288, which uses an ARM Cortex-A17. According to Wikipedia, that chip implements the ARMv7-A architecture.


The public view key doesn't allow seeing the incoming transactions. The private view key does that.

In fact, the public view key and public spend key are contained in the Monero address you give to people so that they can send you funds.

The public spend key is used (together with the public view key) to generate the public key of an output.

To generate the private key of an output (to spend it or to generate its key image to check if it has been spent), you need the private view key and the private spend key of the wallet.

Check What significance does the wallet public spendkey and public viewkey have in a transaction? for more details on how the public and private keys of an output are generated.


How to receive balance change notifications?

With latest monero-wallet-rpc you can have an application run on each incoming tx to the wallet.

From the --help:

  --tx-notify arg         Run a program for each new incoming
                          transaction, '%s' will be replaced by
                          the transaction hash

Another simple solution is polling incoming_transfers.


Suspicious connections - Having issues with the GUI under Debian by connection to a public remote node - PC hangs

node.moneroworld.com (in your case, the eu regional) connect to random nodes registered by gentle users on monerowold.com.
Looking at your capture, it seems the node you are forwarded to is based in Russia (which could be correct for eu location if west Russia).
Is it a legitimate node with a small bandwidth, or a scamy node you should not trust, no one could say.
Nevertheless, i do not know any security flaws in daemon RPC which could compromise your wallet using it.
You are just requesting block headers, parse them, and then requests full transactions when your wallet find your addresses while parsing the tx_keys in headers.

My guess is your computer freeze because the node is slow and the bandwidth tiny. If you look at a top while syncing, you should see if your cpu is stuck with I/O waits.

But, as you have a full node on your windows computer, why don't you connect your debian wallet to this windows node? Aren't they available at the same time?


Ledger and Monero GUI v0.14 transaction problem

This appears to be a bug with v1.1.3 of the Ledger code.  It should just be a parsing bug.  You just can't see your funds for the moment.  You'll want to download v1.2 when Ledger releases it (maybe today), and then rescan the wallet.

If you have trouble getting it to rescan, you can rename the wallet file and open it again, and that will trigger a rescan.


Mining pool found a block after three days but didn't pay me

You will not be paid by the pool until you have reached the minimum payout threshold. Furthermore, pools usually only run payouts once a day, so you have to mine till 1) you have reached the minimum threshold and 2) wait for the next payout run.


How can someone run all blockchain and check if certain block has tx belonging to viewkey

A certain account will always scan all blocks to look if any transactions belong to it, i.e., if P' = P* (note that P is a stealth address). As you may have already noticed, this will be quite resource intensive. Therefore, services like MyMonero usually use high end servers to do this. In addition, they charge a fee (such as the import fee in case of MyMonero) to cover some of the costs.

*A more extensive explanation can be found below and is taken from luigi1111's article:

  Now let's look at Bob's perspective:

  Bob receives a transaction; he wants to check if it belongs to him.
  Bob retrieves R, which Alice has helpfully attached to the transaction.
  Bob computes D'. Note Bob doesn't (yet) know if D' is equal to D. D' = aR.
  Bob computes f' = Hs(D').
  Bob computes F' = f'G.
  Bob computes P' = F' + B.

  Bob checks if P' is equal to P, which was included in the transaction as the destination. If yes, Bob realizes he's been paid and does some additional steps (below). If no, Bob ignores the transaction.

To add, I'll clarify some of the letters used in the quote above. In addition, the view key that we can publish is known as the tracking key (a,B) in the CryptoNote whitepaper.

R = Public transaction key

D = Shared secret that is only known to Alice (sender) and Bob (receiver)

Note that D = rA (private tx key (r) times public view key (A) from Bob), whereas D' = aR (private view key (a) times public transaction key (R) that was included by Alice)

Hs = Hash to scalar, i.e., a hashing algorithm that returns a scalar (private key).

G = The Ed25519 base point

B = Bob's public spend key

  Is there any avaliable script with this function ?

You can simply type payments <payment_ID> into the wallet to see all transactions belong to that account. If you need to check for payments programmatically, then see below from the "Accepting Monero Payments" page:

  Checking for a Payment Programatically

  In order to check for a payment programatically you can use the
  get_payments or get_bulk_payments JSON RPC API calls.

  get_payments: this requires a payment_id parameter with a single payment ID.

  get_bulk_payments: this is the preferred method, and requires two parameters, payment_ids - a JSON array of payment IDs - and an
  optional min_block_height - the block height to scan from.

  An example of returned data is as follows:

  It is important to note that the amounts returned are in base Monero
  units and not in the display units normally used in end-user
  applications. Also, since a transaction will typically have multiple
  outputs that add up to the total required for the payment, the amounts
  should be grouped by the tx_hash or the payment_id and added together.
  Additionally, as multiple outputs can have the same amount, it is
  imperative not to try and filter out the returned data from a single
  get_bulk_payments call.

  Before scanning for payments it is useful to check against the daemon
  RPC API (the get_info RPC call) to see if additional blocks have been
  received. Typically you would want to then scan only from that
  received block on by specifying it as the min_block_height to
  get_bulk_payments.

  Programatically Scanning for Payments

  Get the current block height from the daemon, only proceed if it has    increased since our last scan
  Call the get_bulk_payments RPC API    call with our last scanned height and the list of all payment IDs in    our system
  Store the current block height as our last scanned height
  Remove duplicates based on transaction hashes we have already    received and processed

Some background information that may come in handy when you are trying to understand this Q&A on a deeper, more technical level:

1     What is a stealth address?

[2]     Constructing a Stealth Monero Address?

[3]     Examples of real stealth address from the blockchain

[4]     Why does the stealth address involve a hash function?

[5]     Mandatory vs optional stealth address use

[6] Why is the viewkey able to track incoming transactions, but not outgoing transactions?

[7] What are the "public" viewkeys and spendkeys?

[8] https://github.com/TheKoziTwo/xmr-integration


What is actually happening when you pool mine? What is a share?

When you mine, you try to solve a puzzle. In a simple description, you choose a number, any number, hash it together with some info for the block you want to include in the blockchain, and then check if the resulting hash conforms to the rules. This puzzle is designed in such a way that a difficulty level can be set for its solution.

When you mine for the pool, you are doing normal POW and comparing it to the pool's difficulty, which is lower than the current blockchain diff.
When the work satisfies the pool's diff you have found a share and you send it to the pool to prove you are working on the job you got.

The pool then checks if your share is valid for your diff AND sees if it satisfies the diff needed to solve a block. Eventually someone will going to submit a share that solves a block and the reward is divided between all the shares.

These shares represent the actual share of work you have contributed for the pool and so you are rewarded accordingly.


What is the difference hashing power when running the JS Monero Miner via a browser vs Running solo Mining with the cli?

They claim "65% of the performance of a native Miner", and this seems to be roughly the case on my PC.

This is definitely a pooled mining setup, and they're running their own pool. Which means if you want to cash out, you need to ask them to let you cash out through their web site.


What are the system requirements for an Aeon full node?

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

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

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


An Aeon web wallet AEON Pocket was recently announced on Reddit.


PM u/needmoney90 or u/SamsungGalaxyPlayer on Reddit with your e-mail address, or ping them on IRC.


How to create a view-only wallet for the GUI?

The GUI can now create view only wallets. I've not used the GUI in a while, so I'm unable to give detailed steps, however. Please someone who knows post an answer :) See JollyMort's answer below, I can't delete an accepted answer.

Original answer is now obsolete, as pointed out below:

The GUI does not support view only wallets yet.

However, if you don't really care about having a correct balance, and just want to see incoming transfers (ie, not see spends), you should be able to load a view only wallet made by monero-wallet-cli into the GUI. There may be glitches.