How to Use Monero Multisignature Wallets (2/2 & 2/3) Disclaimer: this is written for the pre-release version and for testing purposes only (at the present moment). Use at your own responsibility and don't play with big amounts. To test yourself, you must build the linked multisig branch. I will remove this disclaimer once the multisig functionality will be in the release version.

I want to use 2/2 or 2/3 multisig. How do I set-up the multisig wallet? How do I monitor the balance? How do I spend from it?

Note: one answer for 2/2, other for 2/3. scroll down =)

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.


How can I change gui wallet display locale/language It switched from English to Dutch

When starting monero-wallet-gui, cancel where it ask for wallet password and you can select the language and regional format. selected english, then restart monero-wallet-gui and login.


How does the payment id appear in a transaction? I'm having troubles finding the payment ID in a transaction info. I'm using the daemon RPC API to get the transaction info. According to the official documentation the extra field is used for the payment ID. However, It seems like this byte array is not even the size of a valid payment ID (8 or 32 bytes).
Here are two examples:

tx hash: c748fedd286bdd5a34e223316593625cd4482d7666b262cef51f8bc0e1694b26
'extra' field (in hex): 012772e8e0893433644b93401067a804415d86ddde4c91154a95c84a365111fb86022100fb7ef3f11937667a9242ed4d252ed97c4401079bc11d87a17a581032bcb02769 (68 bytes)
tx hash: b9678d96071be7d31484c324d2009848872744e79ddd85eb94b71fb867b543cb
'extra' field (in hex): 01ed37fc961021099a74c227fa414c29a7213e6678215abf5f37a1c25ed4bd26a2 (33 bytes)

I have another transaction without payment ID (shows 0000000000000000 in the cli wallet) but the extra field in this transaction is not filled with 0's, but actually looks random (I'm not posting its details for privacy reasons).

So what exactly is in the extra field, and how do I find the payment ID in the transaction info?

The txextra field can contain several subfields.

Start by reading a single byte. This is the subfield tag.

Tags:
0 = padding
1 = the next 32 bytes is the transaction public key
2 = a nonce. Read a VarInt[1] to determine the nonce length. Then read a byte to determine the nonce type

Nonce types:
0 = 32 byte unencrypted payment id
1 = 8 byte encrypted payment id

If there is an encrypted payment id, you need to compute the shared secret for the transaction in order to decrypt it.

To decrypt an encrypted payment id, you need to XOR it with the payment id key. Start with the shared secret, by doing scalar multiplication of your private view key with the transaction public key located in the txextra and then multiplying that by 8. Concatenate the byte representation of the shared secret elliptic curve point with the hex "8d". Take a keccak(256) hash of this, and you have the XOR decryption key for the encrypted payment id.

[1] The VarInt integer representation is defined in section 1.2 of https://tukaani.org/xz/xz-file-format.txt

Also see https://cryptonote.org/cns/cns005.txt and https://github.com/monero-project/monero/blob/1a4298685aa9e694bc555ae69be59d14d3790465/src/cryptonote_basic/tx_extra.h


Is a transaction from Exchange to Wallet to Exchange traceable? Here is an example:

Exchange1 --> Adr1;
Adr1 --> Exchange2

Where Adr1 is a one-time subaddress.

Now suppose that Exchange1 and 2 are corrupt and cooperate with a government to leak my information.

As far as I understand it, I would still be anonymous. Since the real receiver is concealed by a Stealth-Address (Adr1*). Whereas the second transaction is protected by RingSig.

So - is there anyway to link these transactions with 2 corrupt parties?

Exchange1 would know the output (call it Out1) that it has given to Adr1. When Out1 is spent, Exchange2 (if sharing knowledge through backchannels with Exchange1) will see that there is a 1 in N chance that Out1 has been spent in a transaction with Exchange2, where N is the ring size that was used.

Exchange1 knows the exact amount of Out1, since it gave it to Adr1. So if it was an uncommon amount, and that exact amount was cashed out with Exchange2 (minus the transaction fee), then it'd be a pretty good guess that Out1 was being spent at Exchange2 if it was referenced in the ring.

Your question does not make clear whether Exchange1 or Exchange2 know about your real world identity. If they do, you've already lost your privacy. If they don't, depending on the scenario then perhaps it wouldn't even matter if you'd used a cryptocurrency without ring signatures at all. What good is it to see funds move on the blockchain, if neither the source nor the destination know your identity?


What do I need to change/add in order to add a field to the block struct? I'm trying to add a field to the block struct, and want it to be serialized just like the miner_tx and the tx_hashes (like FIELD(new_field)), because the block parsing is failing for me with my code ("Failed to parse block from blob" occurs when I start monerod and then it exits).
What should I change in the code that can solve this problem?

You would edit the block struct in https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_basic.h by adding the extra variable and specifying the serialization field correct to the type of your variable.


Can anyone explain the working of CryptoNight? I went through this. And I could not comprehend well.

For example, in SHA-256, it takes any type of input and gives a 256-bit output. And if we add a random number as a tail in the input, the output generates a certain number of zeros in the beginning.

In case of CryptoNight, how does this work?

And what nodes verify as proof of work to accept a block?

Your understanding is nearly correct regarding SHA-256 PoW.

Let's break it down. SHA-256 is a cryptographic hashing algorithm (that happens to be used as a PoW mechanism in some crypto currencies). CryptoNight is also a cryptographic hashing algorithm, although it's specifically used as a PoW mechanism (I don't know of it being used for anything else). They are both hashing algorithms though, they just internally work differently and have different properties. They both take input data and create a unique one way hash of that data.

The PoW mechanism is ultimately the same (which ever hashing algorithm you use). You take a block template, add a nonce (some random number), then hash. The output hash is a number. If that number is smaller than the current network difficulty target, you submit that block data (which has your nonce in it) to the network. If not, you increment the nonce (to simply change your input data) then repeat.

Verification of PoW is taken care of by the nodes receiving the submitted block data. Nodes hash (using the same hashing algorithm) the block data and if the resulting hash is smaller than current difficulty target, PoW is verified. Of course, to be added as the next top-block (and therefore get a reward) it also has to be first-seen (amongst other things).

TL;DR

It's better not to think about generating a certain amount of zero's, but rather finding a number (a hash) that's smaller than the current network difficulty target.

Footnote:

Technically speaking, with Monero, you are looking for a hash value that is greater than the current block difficulty. Imagine the maximum possible difficulty is 100 and the current block difficulty is 30. This means you are looking for a hash greater than 30 and less than or equal to the max possible value of 100 (so a possible range spanning 70, i.e. you have a 7 in 10 chance of finding a valid hash). If the network difficulty increases so the current block difficulty is 80, your range is smaller (20), thus harder to find a number in that range (i.e. a 1 in 5 chance). Note that the actual maximum hash value is 2^256-1, because our hashes are 256-bit numbers.


how does monero schedule an algorithm update? Will the algorithm change affect the blockchains to be generated or saved?
How to deal with the new-generated blockchains and the old blockchains if the formers are changed?

Miners and nodes are updated ahead of time with new software. This software is hard coded to know in advance the block height at which the mining algorithm is agreed to change over. Block height is simply a count of the number of blocks since the very first block ever mined (also known as the genesis block). When the block at the agreed upon changeover block height is mined, it is simply mined using the new algorithm and nodes know to check for an alternate proof of work for that block onwards. It's all the same blockchain, but it's verified using different methods according to which part of the blockchain is being verified.


Writing my own Monero miner So I was trying to make my own Monero miner and I found out that it uses the Cryptonight hash algorithm and I found documentation for it and I can implement it. But then how do I connect my miner to a pool, there doesn't seem to be any API on any of the Monero mining pool websites. Can someone explain how I can connect my miner to a pool?

Pool miners talk to pools using JSON over HTTP. This is a fairly simple protocol, which is different from the one used by Bitcoin miners, but similar.
I don't know of a documentation for it, but you can easily see what it's doing by looking at cpu-miner.c in Wolf's miner (copy found on github, not the original):

https://github.com/okae/cpu_miner_wolf/blob/master/cpu-miner.c

For the other side of the communication, you can look at the pool server:

https://github.com/zone117x/node-cryptonote-pool/blob/master/lib/pool.js


What exactly is the relationship between Monero and I2P I know they both compliment each other but I'm trying to figure exactly how they both work together. Is it used for the anonymity? Sorry for the newb question, I have just really been trying to figure out the relationship these two technologies have with each other.

Monero will use I2P to connect nodes together. The goal of this is twofold:

an adversary spying on your network connection, like so many today, will not be able to see whether you are using Monero or not.
A node receiving a relayed transaction will not be able to tell the IP it came from.

A new I2P router, Kovri (https://github.com/monero-project/kovri/) is being developed for integration with Monero. The canonical I2P router depends on a Java VM, which is not ideal for weaker hardware.

Kovri will be usable by other clients than Monero too. Similarly, Monero will optionally be able to connect via clearnet (either only, or in parallel with I2). This is still a longer term feature.


Proof of payment method comparison How does the method of proofing a Monero payment following this pull request differ from the former process?

Is revealing key derivation easier or more difficult than revealing the tx secret key?

What are the privacy and security benefits of revealing key derivation instead of revealing the tx secret key?

Previously, a method to prove a payment would have been just to reveal the TX secret key r. This worked, because someone knowing the r and the destination address can only unmask destination one-time keys (aka output) in that particular TX and verify that funds sent to some one-time key were indeed sent to a correct address.

Problem is, if you reveal r, it's out in the "public". So while anyone can verify the destination, how can you confirm who the sender is? If now both you and me know your r, I could claim I'm the sender, and you'd have to go through extra hoops to prove me lying. So until now, proving that you're the sender relied on the assumption that you didn't already leak the r to someone else.

With the new method, you can also prove the destination and amount sent, but without ever revealing r. Instead, it uses r to sign a message which can be verified by anyone using the public TX key R. Also, it uses the shared secret rA to prove the amount. Shared secret is not public, but it's not really a problem to reveal it considering the recipient already knows it. Also, if recipient made his view key a public, then ALL of his shared secrets are also shared with the public anyway (because rA == aR). Revealing rA works like a selective view key - it reveals only what's in some particular TX. However, you get to keep the r private and thanks to that you'll still be the only one able to produce the signature.

There's another way to prove who the sender is, but whether it's useful is yet to be seen as it can't prove the destination without support from the recipient: https://github.com/monero-project/monero/issues/2065


Are there other URL parameters when querying a Monero node's get_info method? When querying a Monero node like this: http://node.supportxmr.com:18081/get_info

I get the info of the node, but are there other parameters besides "get_info"? Can I pass in other data? Is there a list of other URLs I can get to via the browser besides "get_info"?

Is there a list of other URLs I can get to via the browser besides "get_info"?

All the daemon RPC methods are documented here.

  I get the info of the node, but are there other parameters ... Can I pass in other data?

get_info has no input parameters.


How do I utilize blockchain pruning in the GUI (monero-wallet-gui)? According to the release notes GUI v0.14.1.0 includes blockchain pruning. How do I utilize this feature with the GUI (monero-wallet-gui)?

Pruning from scratch or enable pruning going forward
Pruning from scratch or enabling pruning going forward is fairly straight forward. It is done as follows:

Go to the Settings page and switch to the Node tab.

Make sure Local node is selected.

Add the --prune-blockchain flag to the Daemon startup flags box.

Restart (by clicking on the x (right top) and making sure to stop the daemon as well) the GUI to ensure the flag goes into effect.

Pruning is now enabled and will significantly reduce the amount of storage required.
Pruning an existing (synced) blockchain file
First, note that this requires approximately 30 GB of additional storage, as, initially, the Monero software will store both the 'old' non-pruned blockchain and the 'new' pruned blockchain. You can, after verifying that your GUI runs properly, delete the old file of course. The following steps are required to use blockchain pruning:
[1] Make sure all Monero related processes are closed.
[2] Browse to the directory v0.17.1.4 monero-wallet-gui is located.
[3] If you are using a custom data directory, skip step 4 and proceed to step 5.
[4] Run the monero-blockchain-prune tool (on MacOS, you will have to right click -> Show package contents -> Contents -> MacOS on monero-wallet-gui.app in order to see the tool). Note that this may take quite some time to complete. Thus, I'd advise to run it overnight.
[5a] Windows - custom data directory:

Open a new command prompt / powershell from the directory of monero-wallet-gui. This is done by first making sure your cursor isn't located on any of the files and subsequently doing SHIFT + right click. It will give you an option to "Open command window here". If you're using Windows 10, it'll, most likely, give you an option to open the Powershell.

Type:

monero-blockchain-prune.exe --data-dir path\to\preferred\data\directory (Win 7 + 8)
.\monero-blockchain-prune.exe --data-dir path\to\preferred\data\directory (Win 10)
[5b] Linux - custom data directory:

Open a new command terminal from the directory of monero-wallet-gui

Type:

./monero-blockchain-prune --data-dir path/to/preferred/data/directory
[5c] MacOS - custom data directory:

Go to your desktop.

Open a new terminal (if don't know how to open a terminal, see here).

Drag monero-blockchain-prune in the terminal. It should add the full path to the terminal. Do not hit enter.

Now type:
--data-dir path/to/preferred/data/directory

Note that aforementioned text will be appended to the path of monero-blockchain-prune. Thus, before you hit enter, your terminal should look like:

/full/path/to/monero-blockchain-prune --data-dir path/to/preferred/data/directory
Where the full path is, intuitively, the actual path on your MacOS.
[6] Note that path/to/preferred/data/directory is a placeholder that should be replaced by the actual path. To reiterate, this may take quite some time to complete. Thus, I'd advise to run it overnight.
[7] After the monero-blockchain-prune tool has finished, open monero-wallet-gui and verify that it is running properly.
[8] You can now delete the 'old' non-pruned blockchain file.


How do you convert the Monero blockchain from Linux to Windows? I know there is a tool that can be used to convert the format but what steps should be taken to do so?

As far as I know, the current blockchain is compatible across different operating system as long as they have the same "amount of bits", i.e., 64 bit to 64 bit systems or 32 bit to 32 bit systems would work, but 32 bit to 64 bit systems wouldn't work.

If this doesn't work there is a second option. That is, you can export on your Linux system using the blockchain_export tool. This will create a blockchain.raw file, which you can subsequently import on Windows with the blockchain_import tool. Given that you use your own blockchain, you could do this with the --verify 0 flag (this skips verification) to improve speed.

There are more specific instructions here under "Updating: Blockchain Conversion".


Anyone have experience with using AMD and NVIDIA GPUs on the same rig? I have just started mining and I have been using a AMD gpu, well I came up on a NIVDIA gpu and I would like to run it beside my AMD gpu. Anyone know How this could be done and with what mining software and settings?

It is definitely possible. You would have to start the AMD and nVidia miners seperately and configure them so that they only used the index of the GPU that they are compatible with. I think in claymore's cryptonight miner it would be
   -di 02 if you wanted to use GPU 1 and 3. (Computer's use arrays that start at zero to count indices)

As far as I'm aware there are not any nVidia and AMD dual miners for cryptonote algorithm.

Please add more about your operating system for clearer instructions.

Edit: Use ccminer-cryptonight https://github.com/tsiv/ccminer-cryptonight/releases for your nVidia GPU

Use claymore's cryptonight miner for AMD.

If your #1 GPU was AMD and your #2 GPU was nVidia:
claymore would have a "-di 0" flag in the command line or config file
ccminer would have a "-d 1" flag in the command line or bat file


Which reasons were discussed for potentially changing the proof-of-work algorithm? Which reasons were discussed for potentially changing the proof-of-work algorithm to something else in the future (Cuckoo cycle in particular)?

One of the main reasons Cuckoo cycle is atractive when compared to Cryptonight is that it is very fast to verify. This is one drawback of Cryptonight: it makes all operations that need to verify Cryptonight hashes slower.

Another reason to want a switch to Cuckoo cycle would be to keep the CPU/GPU/ASIC performance within a reasonable scale. Should ASICs pop up with enough memory allowing them to leave CPUs and/or GPUs behind by too high a margin, this would be undesirable from a decentralization point of view.

A more obscure reason to prefer Cuckoo cycle is that it is difficult to make a similar pool mining setup to bitcoin or monero. What these do is get miners to find a share at a lower difficulty than needed for a block, because a valid block solution will also be a valid share. For Cuckoo cycle, this is not the case, so a miner can't periodically send a "proof of work" to the pool. It is not quite clear whether this particularity is wanted or not. While it will force miners to solo mine (increasing decentralization), many might decide to stop mining instead (decreasing overall network security).


How do I prove that a payment has been sent to a particular address? If I pay someone, and they then claim that the payment has not been received, how can I prove that the payment was in fact sent?

When you send a transaction, a one time random keypair is generated. You can later see it with get_tx_key txid, replacing txid with the transaction id for the transaction in question.

You can then send an auditor/arbitrator three pieces of data: the standard address you sent to, the transaction id, and the tx key for that transaction. The auditor can then use check_tx_key txid txkey address, replacing the three arguments with the information you supplied. The command will return how much monero was transfered to that address in that transaction.

If your transfer was split in multiple transactions, you need to supply the txid/txkey pairs for all of those, and the auditor can sum up the results.

Note that these tx keys are stored in the cache file. If you send a transaction, then kill simplewallet without saving (or simplewallet crashes before saving), the tx keys will be lost, and you will be unable to prove transfer. So make sure you exit simplewallet cleanly, with the exit command.

Last, there is a known problem with the upgrade from 0.9.4 binaries to 0.10.0 binaries, where the wallet cache can't be loaded. If this happens to you, you can load the cache with 0.9.4 to query the tx keys. This will be fixed in 0.10.1, so keep your wallet cache if this applies to you.


What happens to coins that are sent to a public viewkey? As the title states, if I sent moneros to the public viewkey instead of the right one (standard monero address), what will happen to them?

A view key is not a valid address, and thus your transaction should be void.


Monero wallets with native xmr.to integration Are there any Monero wallets with xmr.to native integration making it easy  to spend Monero at any Bitcoin accepting merchant?

There are currently no wallets with native XMR.to integration. This is, however, planned for the official GUI at some point in the future.

EDIT 12/25/2017: Monerujo, a third-party Android wallet, currently has native XMR.to integration1

Sources:

https://www.reddit.com/r/Monero/comments/7lv9d8/update_monerujo_satoshis_dream_beta_now_with_btc/


Hashrate clarification A typical CPU achieves 100 H/s for Monero. According to my calculations, this hash rate is somehow strange!

As we know, the main loop of Monero (Cryptonote) iterates about 500K times and each iteration needs 4 accesses to the memory (2 writes and 2 reads). So, there are 500K*4=2M accesses to the memory for each hash.

100 H/s * 2M = 200 MegaMemoryAccess/seconds

This means that the memory latency of the CPU must be 50 pico seconds which is impossible even for the L1 cache.

So what is the hash rate shown by miner programs?

https://stackoverflow.com/questions/4087280/approximate-cost-to-access-various-caches-and-main-memory reports L2 cache access to about 3 to 5.3 ns. We'll use 5 ns to be conservative. 2 million accesses get you 0.01 seconds, so about 100 times a second. That does not leave much for the rest, granted, but is not obviously wrong.

Second, your calculation is wrong: 200e6 accesses per second yield an access time of 5 nanoseconds (1 / 200e6 = 5e-9). This is in line with the paragraph above.

Last, the hash rate shown by miner programs is the number of hashes done per second (may be a sliding window average).


Windows or Linux for Monero What are the pros and cons of each OS for running a full node and GPU/CPU mining? Also developing for Monero?

I want to be able to make programs for windows, linux, and macos that involve Monero as I want to be more involved in the community.

I have a R7 250 and a intel xeon 4core/8thread 3 ghz

Should I stay on Windows, or go on Linux, because my life is currently revolving around cryptocurrency and developing.

Whats the pros and cons of each system for developing, mining, and running a full node.
Thank you

As someone who runs both Windows and Linux, I'd say that there is no bad choice but there certainly are better ones for specific use cases.

Casual use: Windows - no need to dual boot or learn a new OS. Mining, running a full node work fine.
Competitive mining: Linux for superior performance
Storing funds: Linux for superior security. (Still requires sane best practices like not running a web browser on a machine with >$xx,xxx worth of monero on it)
Storing lots of funds: Neither. Use a paper wallet generated on an offline machine.
Development: Hands down Linux, unless you are a strong C# dev and know your way around the windows development environment.


How many payments can be included in one transfer command? A single transfer command in monero-wallet-cli may include multiple payments to different addresses (or to the same address). Is there a hard limit to the number of payments that can be included? I don't need this option at the moment, and I haven't tested large numbers, but this might be useful for businesses that need to make a lot of payments at the same time.

If this answer to a related question is correct, the transfer will be split into multiple transactions when it's too big to be included in a block, so there shouldn't be a limit on the protocol level.

Regardless of any limit hard-coded in the wallet, there will be a variable limit, depending on the mixin and the total amount paid relative to the balance. What happens if the amount needed for the total transfer is larger than the available balance?

There is no particular limit. If you send to many addresses, then you will get split transactions (assuming you use transfer_split in RPC, this is the default with the command line wallet), since this increases the number of outputs. Large pools probably have a number of txes with a lot of destinations (and even more so before the payout threshold was implemented).

If you're trying to send more than you have, then, unsurprisingly, the transfer will fail.

The new transfer algorithm (transfer in monero-wallet-cli, new_algorithm: true in RPC) is a lot better at sending large-compared-to-balance amounts at once.


How do I get the weight of a transaction from the RPC daemon I'm trying to look at the distribution of fees per kb of weight, but all I can find in the RPC connection to the daemon is the fees of a transaction. Note that I want the weight of a transaction, not the actual size. That means  including the effects of the clawback.
I guess I could get size from the hex representation of the TX, but that doesn't take into account the weight-clawback for Txes with more than 2 inputs or outputs.
To be clear, I want to do this for almost all transactions on the blockchain, not just my own transactions.

How do I get the weight of a transaction from the RPC daemon ... Not the weight of a transaction

Due to the contradiction, I'm going to assume you want the size.

I guess I could get size from the hex representation of the TX

Yes. Like:
curl -sd '{"txs_hashes":["329c12515493165e5580cf5541d429ca3f59d7ac949ba918c0f84af9450f13a8"],"decode_as_json":false}' http://localhost:18081/get_transactions \
  | jq .txs[].as_hex --raw-output \
  | wc -c \
  | xargs -I N expr N / 2

to get size of any transaction(s).
Or to also include fee related data:
curl -s http://localhost:18081/get_transaction_pool_stats

to get the size and fees of transactions in the tx pool. No use for historical, but useful for data gathering moving forwards.

but that doesn't take into account the weight-penalty

Note the penalty function applies to miners and block size. A user simply pays fees to cover the size of the tx they are sending. Want to send more data, pay more in fees. So if you're wanting data around the penalty imposition, you want to be looking at the block size and history.


Formal Verification of Monero code This answer mentions a plan to eventually formally verify Monero code. Which approach will be used for that verification process? The cited wikipedia page mentions model checking, deductive verification and program derivation as possibilities.

If the core Monero daemon gets to a point where it's particularly secure and particularly stable (eg. the code has been formally verified).

Sounds like an idea rather than a particular plan with dates and methods intended for verification. When Monero is particularly secure and particularly stable, then they will probably start discussing methods of verification.


How to automatically start XMRig on Ubuntu 18.04? I am running xmrig-5.8.1 on Ubuntu 18.04  by executing this cmd ./xmrig --donate-level 1 -o pool.supportxmr.com:xyz -u MY-XMR-ADDRES -p Rig1 -k --tls. Now I want it to start automatically in background whenever I start my system. I found some way like adding a script file inside init  or init.d folder but I don't know how to add the script file inside these folder and what to add inside these script file?

There are many ways to do this. One simple way is via cron:

In a shell execute crontab -e then add and edit the line:

@reboot /path/to/xmrig -B [--syslog | --log-file=/some/file.log] [your other options]

Save and exit.

The -B option runs it in the background and you add either the --syslog or --log-file option so you can get at its output.

Many other Ubuntu examples of running things at startup here: https://askubuntu.com/questions/814/how-to-run-scripts-on-start-up


How do I build Kovri from source for OpenBSD? Is it possible to compile Kovri on OpenBSD from source? If so, what is the process?

Kovri build instructions are on the main Kovri repository here:

https://github.com/monero-project/kovri/blob/master/doc/BUILDING.md

This document will always be the most up-to-date location for build information, so I will not go into the process here.


How to autosave blockchain? I am running a Monero node on one of my Windows computers (bitmonero.exe) and it is fully synchronized with the network. Occasionally, I need to restart this computer without warning and do not get a chance to save the blockchain. Is there any way for me to configure a setting to autosave the Monero blockchain every hour or so?

Run bitmonerod with the option "--db-sync-mode safe" and it will persist every change immediately. Then if your system crashes or restarts suddenly, there will be no data lost and bitmonerod will pick up wherever it left off the next time it starts.


Format of numbers decoded from ECDH amount After decoding the amount from ecdh amount, we get the numbers which is obvious not in decimal, e.g. "0010a5d4e8000000".

Then we can transfer them into integer with the following python code and get "1000000000000" which means 1.0 xmr:

def hexToInt(h):
    s = binascii.unhexlify(h) #does hex to bytes
    bb = len(h) * 4 #I guess 8 bits / b
    return sum(2**i * ed25519.bit(s,i) for i in range(0,bb)) #does to int

Therefore, I am curious about what the standard it follows?

It's just the hex of a little-endian byte-order encoded number (i.e. when swapped around you get 0xE8D4A51000).

Perhaps this will help you see:

import struct
import binascii
bin = binascii.unhexlify('0010a5d4e8000000')
print(struct.unpack('<Q', bin)[0])
print(0xE8D4A51000)

unhexlify converts the hex to binary and the format specifier <Q used by unpack means unpack a 64 bit number which is stored little-endian byte-order.

MiniNero's hexToInt is just doing the same thing in a different way.


Are there any disadvantages to using a mining pool with I2P? Recently, MoneroWorld added a mining port for I2P. Are there any disadvantages to mining with I2P instead of connecting to the pool directly? Eg: will it be sgnificantly harder to submit shares? Is the connection less reliable?

There is significant (and variable) lag in the i2p network - try visiting any i2p website. As mentioned on MoneroWorld.com, this could cause an increase in stale shares (you submit a solution for a block that already has been solved).

i2p lag will only decrease if more and more people run i2p nodes. (and by i2p nodes I mean running the i2p server).


Why are Monero fees visible? I was checking in moneroblocks.info some random transaction just to see how they are composed, and I noticed that while the amounts are confidential, the fees are on clear and not obfuscated.

Isn't there any method to make an estimate of the amount concealed by its fee?
Was it too much complex making the fees confidential too?

Sorry if the question is trivial but I'm a newbie.

The minimum transaction fee is proportional to the size of the transaction data. Assuming you are making a typical transaction and are not using custom privacy levels, then the minimum transaction fee depends on the number of inputs being spent. The number of inputs being spent is a consequence of the size of the stray change outputs and the size of the typical transaction amounts you receive relative to the amount you're sending. It's not easy therefore to correlate the number of inputs being spent to the amount being spent in a transaction.

The fee can be increased to give the transaction higher priority. You could argue that high value transactions are more likely to be given an expensive fee because the transaction is more important. This is a weak correlation though.

The main thing to note is that there is no rule that requires the fee to be proportional to the amount being spent, so disclosure of the fee does not give away much. Disclosure of the fee is necessary, because miners need to know what fee is being offered in order to decide whether the fee is enough to allow the transaction to compete for inclusion in the next block being mined.


Using the rpc_access_data method Daemon RPC Monerod command:

monerod --rpc-bind-ip 0.0.0.0 --restricted-rpc --confirm-external-bind --public-node --rpc-payment-address xxxxx --rpc-payment-credits 250 --rpc-payment-difficulty 1000

Curl request:

curl -X POST 127.0.0.1:18081/json_rpc -H 'Content-Type:application/json' --data "{"jsonrpc":"2.0","id":"0","method":"rpc_access_data"}"

Response:

{
  "error": {
    "code": -32700,
    "message": "Parse error"
  },
  "id": 0,
  "jsonrpc": "2.0"

How can I successful retrieve rpc payment information from monerod rpc?

This method is not accessible via the json rpc yet.
https://github.com/monero-project/monero/issues/7178


How to backup the blockchain file? How can I periodically backup the blockchain file, without copying the entire file (just the new data that was added since the last backup)?

I tried copying only the amount of bytes by which the blockchain is larger than the backup ("filling the gap"), but that didn't seem to work - the daemon failed to load the blockchain from this backup.

rsync copies what's changed:

rsync ~/.bitmonero/lmdb/data.mdb /mnt/wherever/monero-blockchain/data.mdb

This should be done when nothing is writing to the blockchain database file. If you need to copy while it is being written to, use mdb_copy:

mdb_copy ~/.bitmonero/lmdb /mnt/wherever/monero-blockchain/

Note how mdb_copy wants the directory, and not the file.


Transaction Unlock Time in Monero GUI? i would like to use the unlock time feature to send Monero and make sure the receiver cannot spend them before a certain date. is there a way to use that feature in Moneros GUI wallet?

The unlock time feature is currently not implemented in the GUI. One would thus have to use the CLI to utilize the feature.


What is transaction malleability, does Monero suffer this problem like Bitcoin? does this effect monero in anyway and if it does would something like flexible transactions or segwit fix it? thanks

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

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


Is the wallet address and generated account address the same? I have already looked at these questions / answers:
Question1, Question2, Answer, and now have the following understanding about Monero wallets, accounts and addresses:

We can create wallet which generates a .keys file and has a wallet address, wallet password, wallet menmonic.
We can create account with/without a label which generates one address for that account and account_index.
We can create subaddresses using create address, which requires account_index and it will generate an address and address_index.

I still have some confusion about:

Is the account index automatically generated with wallet generation?
How is the wallet related to an account and how is an account related to address/subaddress?

I have already read all the documents regarding this I can find.

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


How do I change the language of the 25 word mnemonic seed in the GUI or CLI? How can I change the wallet variant (language) of the monero GUI wallet? The real question behind this is that I have a seed in a different language than English. I will have a problem if I want to use that seed in future to restore in a different wallet which might only support English. As a consequence I would like to change my wallet language to English before using it.

The GUI languages work as follows. On the first page of the wizard you can select a language. If that particular language also has a corresponding mnemonic seed word list, your mnemonic seed will be in the same language when you create a new wallet. Thus, you'll get a 25 word mnemonic seed in your local language. Conversely, if it doesn't have a corresponding mnemonic seed word list, your mnemonic seed will be in English when you create a new wallet. Thus, you'll get an English 25 word mnemonic seed.

The code for this described behavior can be found here. As you can see from the code, the list of available languages for the mnemonic seed is:

<!--
List of available languages for your wallet's seed:
0 : Deutsch         (German)
1 : English
2 : Español         (Spanish)
3 : Français        (French)
4 : Italiano        (Italian)
5 : Nederlands      (Dutch)
6 : Português       (Portuguese)
7 : русский язык    (Russian)
8 : 日本語          (Japanese)
9 : 简体中文 (中国) (Simplified Chinese (Mainland))
-->

Thus, as can be seen from this list, if you select Deutsch as language, it will also give you a corresponding Deutsch (German) 25 word mnemonic seed. The code for this behavior is as follows:

<language display_name="Deutsch" locale="de_DE" wallet_language="Deutsch" flag="/lang/flags/german.png" qs="none"/>`

To clarify, wallet_language determines the language of the 25 word mnemonic seed, which is Deutsch in this example.

Now if you, for instance, select Swedish as language, it'll give you an English 25 word mnemonic seed, because it doesn't have a corresponding Swedish mnemonic seed word list. The code for this behavior is as follows:

<language display_name="Swedish" locale="sv_SE" wallet_language="English" flag="/lang/flags/sweden.png" qs="none"/>

As you can see, the wallet_language is now English.

  As a consequence I would like to change my wallet language to English before using it.

Now, unfortunately, closing an existing wallet, selecting a new language (in your case English) on the first page of the wizard and lastly reopening this particular wallet (using the Open a wallet from file option on the second page of the wizard) will not change the language of the 25 word mnemonic seed. Therefore, we have to use the CLI as workaround. This is done as follows:

Exit the GUI and make sure to stop the daemon as well.
Browse to the directory your wallet files are located (Documents\Monero\<wallet-name> on Windows | ~/Monero/<wallet-name> on Linux and Mac OS X).
Copy <wallet-name>.keys to the same directory as monero-wallet-cli. On Linux and Windows, monero-wallet-cli will be in the same directory as monero-wallet-gui. By contrast, on Mac OS X, monero-wallet-cli will be in ~/Applications/monero-wallet-gui.app/Contents/MacOS
In the directory your wallet files are located, rename <wallet-name>.keys to <wallet-name>-backup.keys
You should now have <wallet-name>-backup.keys in the directory your wallet files are located and <wallet-name>.keys in the same directory as monero-wallet-cli
Open monero-wallet-cli by double clicking on it (Windows and Mac OS X) or with ./monero-wallet-cli from the terminal (Linux)
Enter your wallet name and password. The wallet doesn't have to be connected to a daemon to change the mnemonic seed language.
Now type set seed language
This will show you a list of available seed languages and their corresponding numbers. For example, English is 1
Enter the number of your preferred seed language and hit enter.
Type exit
Copy <wallet-name>.keys back to the directory your wallet files are located.
You should now have both <wallet-name>-backup.keys and <wallet-name>.keys. Note that the former still contains your old mnemonic seed language (kind of as backup), whereas the latter contains your new mnemonic seed language.
Restart the GUI. You should now have your "old" wallet with a new mnemonic seed language.
On the Settings page, press Show seed & keys to verify the mnemonic seed language.

Lastly, if you want to change the mnemonic seed language of your CLI wallet, simply start from step 6.


Following coding progress between dev meetings Monero biweekly development meeting summaries and logs and  are published by hellomonero. How can a non developer without the desire to compile from source or idle in IRC stay up to date with recent Monero pull requests in between tagged releases and developer meetings?

Visit the GitHub and sign in, creating a new account first if necessary. Select the specific repositories you would like to watch.

  When you watch a repository, you get notifications for any new pull requests and issues that are created, including those not mentioning you.

For example Monero source code can be found in this repository. Monero GUI and Kovri code each have their own repo. You can control what type of notifications you would like to receive and how you receive them.

As a non developer, doing the above will make more sense if you read the GitHub discussions of Monero contributors about recent pull requests. Important and complicated pull requests generally receive multiple comments before being merged. Based on developer feedback pull requests can be canceled or modified or merged to master. If you are not willing to compile from source then following this activity is the best you can do to stay up to date on code changes between tagged releases.


How many hashes are needed to solve a Monero block of difficulty 1? For example, for ZCash, it takes, on average, 8192 hashes (aka "solutions") to solve a block of difficulty 1. That number is determined in the source code by a 256-bit target threshold (0x0007ffff00000000000000000000000000000000000000000000000000000000). To find a solution, a hash result must be beneath the target threshold. Since hash results in Zcash are evenly distributed between 0 and 2^32 - 1, the odds of finding a hash result that is beneath the target threshold is equal to the target threshold divided by 2^32, which is approximately 1/8192. Reference

Does anyone know the target threshold for Monero? Or, more simply, the average number of hashes (total, across the whole network) required to solve a Monero block of difficulty 1?

Also, is difficulty linear? i.e. does solving a block of difficulty 9 require three times as many hashes as solving a block of difficulty 3?

One Monero block is (1 << 21) / 16  [Source (Lines 40, 43 and 90): https://github.com/monero-project/monero/blob/master/src/crypto/slow-hash.c#L40 ].

The Monero block reward = (M - A) * 2-20 * 10-12, where A = current circulation. Source: https://monero.stackexchange.com/a/4254/2828 .

With Monero the difficulty is dynamically adjusted so that Blocks are completed in 2 minutes.

"Difficulty is a numerical representation of how long on average it will take to create a valid block that satisfies the Proof-of-Work algorithm being used, it does not represent minutes or time per se. but instead is an integer number that makes the PoW calculation take longer to perform, this is adjusted by the nodes and miners so that on average it ensures the network creates blocks at a generally consistent rate.

This is calculated among all the nodes and miners in accordance with the globally agreed rules in the network, AKA consensus rules.

Miners that do not include this number in their difficulty calculations will not have their block validated and included by the rest of the network." - Source: https://monero.stackexchange.com/a/1494/2828 .

ZCash and Monero use different POW algorithms, comparing blocks solved or chances of success between the two isn't a good means to determine which is more profitable/difficult.

Try https://whattomine.com/ where you can say what equipment you have available and it will estimate your earnings for dozens of Cryptocurrency types simultaneously, including Monero and ZCash.

Example Mining Profitability Calculations:

Source: https://minergate.com/calculator/zcash .

For Ethereum:

Reward = ((hashrate * block_reward) / current_difficulty) * (1 - pool_fee) * 3600

For CryptoNote-based currencies (Bytecoin, Monero, Quazarcoin, DigitalNote, etc.):

Reward = ((hashrate * block_reward) / current_difficulty) * (1 - pool_fee) * 3600

For Bitcoin-like currencies (Bitcoin, Litecoin):

Reward = ((hashrate * block_reward) / (current_difficulty * 2^32)) * (1 - pool_fee) * 3600

Source: https://bitcointalk.org/index.php?topic=1732808.0 .

"<YOUR HASHRATE> / (<YOUR HASHRATE> + <NETWORK HASHRATE>) x <BLOCKS PER 24H> x <BLOCK REWARD>"

Bitcoin : userHash/(difficulty*(2^32))*blockReward*3600*1000000000(hashFactor)

ETH: (userHash/difficulty)*blockReward*3600*hashFactor

Zcash:  userHash/((difficulty)*solsPerDiff)*blockReward*3600*hashFactor (sollsPerDiff = 8192)

Monero: userHash/(difficulty*1e9)*blockReward*3600


xmr-stak-amd and Ubuntu I'm only able to make xmr-stak-amd working with AMDGPU-PRO proprietary driver, so I must remain on Ubuntu 16.04.

Is there a way to make xmr-stak-amd working with the amdgpu opensource driver? I mean the default driver in Ubuntu 17.04 or 17.10.

Thanks in advance for answers.

At this time, no way to make xmr-stak (xmr-stak-amd is legacy) with the open-source AMD Linux driver.

Apart from that, the latest xmr-stak works like a charm with new Ubuntu 18.04 LTS version and the AMD Linux proprietary driver.


Remote node IP is always changing in Monero Gui wallet I want to use Monero Gui wallet 0.14.1.0 with remote node.
I trying to set daemon address opennode.xmr-tw.org:18089 or node.moneroworld.com:18089.
But it always changes to some unknown for me IP addresses...

So why remote node address always changes?
Is it safe to use those random daemon IP addresses instead of trusted opennode.xmr-tw.org:18089 or node.moneroworld.com:18089?

In both Simple mode and Simple mode (bootstrap) the GUI will automatically connect to a random remote node. This configuration was preset by developers in order to improve user experience for the less technically inclined. This further means that, in both these modes, users cannot set a custom remote node. Whilst this may change in the future, users currently have to resort to Advanced mode in order to set their custom node. In Advanced mode, you can set the custom node on the Settings page. Switching to a different mode can be done as follows:

Go to the Settings page.
Close the current wallet.
In the wizard, select your desired mode.
Reopen the wallet via the Open a wallet from file option.


Daemon terminates when trying to load lmdb from new location I'm a beginner to Monero. I managed to create a ledger wallet using the monero GUI and fully sync the daemon. I also succeeded in funding my wallet.

When i later wanted to try the CLI version, i used the --data-dir command to point to the same location on my D: drive, to avoid having to wait for the syncing process.

This fails however, every time the daemon is started it terminates before starting sync.

This is the log output:

\monerod.exe --limit-rate 128 --data-dir "D:\Full node\Monero\Blockchain"

2018-08-21 19:40:33.209 4788 INFO logging contrib/epee/src/mlog.cpp:186 New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO,logging:INFO,msgwriter:INFO

2018-08-21 19:40:33.210 4788 INFO global src/daemon/main.cpp:282 Monero 'Lithium Luna' (v0.12.3.0-release)

2018-08-21 19:40:33.210 4788 INFO global src/daemon/protocol.h:53 Initializing cryptonote protocol...

2018-08-21 19:40:33.210 4788 INFO global src/daemon/protocol.h:58 Cryptonote protocol initialized OK

2018-08-21 19:40:33.211 4788 INFO global src/daemon/p2p.h:63 Initializing p2p server...

2018-08-21 19:40:37.305 4788 INFO global src/daemon/p2p.h:68 p2p server initialized OK

2018-08-21 19:40:37.616 4788 INFO global src/daemon/rpc.h:63 Initializing core RPC server...

2018-08-21 19:40:37.617 4788 INFO global contrib/epee/include/net/http_server_impl_base.h:76 Binding on 127.0.0.1:18081

2018-08-21 19:40:37.617 4788 INFO global src/daemon/rpc.h:69 core RPC server initialized OK on port: 18081

2018-08-21 19:40:37.618 4788 INFO global src/daemon/core.h:86 Initializing core...

2018-08-21 19:40:37.619 4788 INFO global src/cryptonote_core/cryptonote_core.cpp:427 Loading blockchain from folder D:\Full node\Monero\Blockchain\lmdb ...

Later. I tried to remove the spaces in the path, making it: "d:/FullNode/Monero/Blockchain. It didnt help.

Finally, when trying to go back to using the GUI, i get the same problem. The daemon starts and terminates after the same line, making me unable to access my funds.

Has my blockchain data become corrupted somehow? I tried removing the lock files but that didnt help either.

I hope anyone has some good ideas. I will try to resync into a new directory, but that might take a few days..

Thank you.

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.


How to properly transfer XMR in monero-wallet-cli? Usually I use the following command to transfer XMR:
transfer normal 11 <address> <amount>

But now I see people are using just:
transfer <address> <amount>

They don't specify fee and ring size.
What is the default ring size and priority for the second command? And what command should I use?

How to properly transfer XMR in monero-wallet-cli?

help transfer
Command usage:
  transfer [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] (<URI> | <address> <amount>) [<payment_id>]

Command description:
  Transfer <amount> to <address>. If the parameter "index=<N1>[,<N2>,...]" is specified, the wallet uses outputs received by addresses of those indices. If omitted, the wallet randomly chooses address indices to be used. In any case, it tries its best not to combine outputs across multiple addresses. <priority> is the priority of the transaction. The higher the priority, the higher the transaction fee. Valid values in priority order (from lowest to highest) are: unimportant, normal, elevated, priority. If omitted, the default value (see the command "set priority") is used. <ring_size> is the number of inputs to include for untraceability. Multiple payments can be made at once by adding URI_2 or <address_2> <amount_2> etcetera (before the payment ID, if it's included)

Usually I use the following command to transfer XMR...

You do not need to specify the optional parameters (the ones enclosed in [] from the help).

What is the default ring size and priority for the second command?

Ring size is currently 11. You actually can't use anything other than 11 as all Monero transactions now use the same fixed ring size.
Priority is normal unless you changed the default wallet setting or specify explicitly in transfer ...

And what command should I use?

transfer <address> <amount> is the simplest and uses sensible defaults.


Is there any reason not to upgrade Ubuntu when new updates are available? Last month, 16.10 was released.  I guess this would be considered a "point release."  Is there anything about point releases to watch out for, or is it generally safe to upgrade for them?

It almost seems like I'm asking a dumb question, where the answer would be the generic "back up your wallet and keys files first, etc.," but maybe there is more to it.

I'm also curious about whether there were issues with Monero when Ubuntu went from 14.xx to 16.xx, if it is relevant to the title.

I see no correlation or problem with upgrading your OS as related to Monero and I can think of no reason why the upgrade would create any problems for your Monero. As you have your mnemonic backed up, you are safe either way.

However, I hope you have taken time to set your "privacy" settings on Ubuntu. Contrary to other Linux distros, there is a little bit of anti privacy behavior. Nowhere near the massive privacy invasions of Microsoft and Apple, but there is some in Ubuntu also.


Monero cpu mining handling huge number of machines I am going to cpu farm Monero with hundreds of computers. And they are the computers of our workers in our company. I want to see whenever their machine is on and working for me. Which pool provides this? I want to see a list of machines that are online at the moment and their hashrate exc..

You could setup your own mining pool using node-cryptonote-pool or something similar. Then each computer could mine for the pool


Does running 2 Monero nodes behind the same LAN help the Monero network? I've got two machines running seeds/nodes for other projects, and one of them runs a Monero node as well. If I put a Monero node on the other machine, and it's behind the same IP, does it help the Monero network?
Thanks!

does it help the Monero network?

Not really. What helps is full nodes and bandwidth, if you have >1 node sharing the same pipe so to speak, you are still offering the same bandwidth, just split between daemons. If the goal is to help as much as possible, make sure you allow lots of peers and as much bandwidth as you can share. See options:
  --out-peers arg (=-1)                 set max number of out peers
  --in-peers arg (=-1)                  set max number of in peers
  --limit-rate-up arg (=2048)           set limit-rate-up [kB/s]
  --limit-rate-down arg (=8192)         set limit-rate-down [kB/s]
  --limit-rate arg (=-1)                set limit-rate [kB/s]
  --public-node                         Allow other users to use the node as a
                                        remote (restricted RPC mode, view-only
                                        commands) and advertise it over P2P

And (as per last option above), consider allowing your daemon to be used as a remote node (so make sure you port forward the RPC port also).


What is actually happening when you pool mine? What is a share? When I connect to a miner, I recieve a 'job', process that 'job', and send back 'shares'. Somehow this means that I earn Monero for my investment in GPUs and electricity.

What is actually happening here?

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 features allowed Monero to rise to the top and overcome Bytecoin? Being the fork of Bytecoin, it is surprising for me to see that Monero was able to achieve a way higher popularity and adoption (Litecoin is doing great, but still far far away from Bitcoin).

So what kind of features allowed Monero to rise to the top or where Bytecoin screwed up and lost the advantage of being first (this looks like a reason) ?

I'd say ...

A hard-working team of dedicated and skilled developers delivering working software while others just talk
Developers who actively support the community on social media (here, reddit and github)
Advanced privacy and confidentiality features (RingCT)
Low inflation


Do checkpoints make initial blockchain sync faster? Do the checkpoint hashes in checkpoints.cpp make the syncing go faster? Why or why not?

Yes. The daemon doesn't check transaction signatures when under a checkpoint.

There are other possible optimizations, but I think that's the only one active right now.


Is it viable to attack Monero by artificially bloating blocks and make it harder to run a full node due to the increased blockchain burden? A lot of small block proponents defend their stance by reasoning that an artificial cap is necessary to prevent spamming, and thus bloating the blockchain. How effective is Monero's mechanisms at making any kind of spammy bloat attack to costly or difficult to pull off.

Say for example, a malicious user had 200,000 XMR (approx 420,000 USD, or 1.5% of all XMR) and their sole intention was to bloat the blockchain to use as propaganda that small blocksize caps were necessary in the Bitcoin debate over the blocksize, the user in question is motivated to drive home the point by making poor Monero an example because they dare question static blocksizes. Given that miners can't discern where coins are coming from so will have difficulty filtering out the spam, how much damage could a user like that do? How long could they keep it up and how big would the bloat fallout be? Could someone bloat the blockchain hundreds of gigs in a couple of months for example?

I ask this because the flex blocksize is a huge selling point WRT scaling the Monero system in a decentralized manner, and I often wonder whether it is vulnerable to this kind of exploitation, and if it is, how much harm could they conceivably do? It was also pulled off in the past to a limited extent by another hacker trying to exploit a bug, but I'm not sure if they did much harm, if any.

The largest size of the next block is limited to 2x the median size of last 100 blocks. Creating a block this large imposes a penalty equal to the block subsidy, so the miners entire revenue would have to come from transactions, thus the transaction fees would have to be at least as large as the block reward to entice the miner.

Realistically, a miner would only mine the larger blocks for more money, not just the block reward, so let's assume that you'd need to pay 2 x the block reward in fees to incentivize miners.

The current block reward stands @ ~5.5 XMR per minute, or ~11 XMR per block. Under our assumption, the attacker would need to pay 11 XMR every 2 minutes (block time) to get his ever increasing blocks. With 200k XMR, he could keep this up for about 18,000 blocks, or 25 days.

Based on a spam attack in 2014, a day is enough for that limit to double, so we're looking at blocks that would be about 25x as large by the end of the attack.

In my opinion, 25x is purely theoretical because we would never approach that since there are multiple costs/incentives at play that change as the blocks grow ever larger and the block reward gets pushed off.

First you have the storage of the penalty XMRs waiting to be paid out to a miner that mines a smaller block (I'm not super fluent on the penalty payout, so someone please correct me if I have this wrong). Then you have the increasing CONOP that comes with larger blocks, which will incentivize miners to require even more then 2x the block reward to mine another larger block. All of this acts to effectively reduce the time of the attack. I'm not sure how the numbers all break down, but I'm relatively certain that the incentives are such for all involved that there wouldn't be this death spiral to infinity GB blocks.

Edit: if the penalty is cumulative then the attack time shrinks significantly since the attacker would need to pay more than the accumulating reward every block to keep up the attack.

Also, once the attacker runs out of money, the block size would come back down (adaptive block sizes are awesome).


How to mine Monero on Ubuntu 18.04? I tried to mine on Ubuntu but it didn't work. please tell me the right way to mine on Ubuntu. Also I got a problem while registering on https://supportxmr.com/: its home page is not like same which I have seen on a Youtube video,
now it looks more like this:

I don't know what to do from here and how to register myself.

Use XMRig, connect it to supportxmr

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

Good luck


What is the minimum length of Payment ID? On the official web site it says that Payment ID

  consists of 32 bytes (64 hexadecimal characters) or 8 bytes (in the case of integrated addresses).

Can it be less? If no, why?

I'm pretty sure the payment id can be shorter, and it is simply padded if it's too short. That said it shouldn't matter too much as it is encrypted so only the sender and receiver knows the contents.


How to transfer synced blockchain along with another OS on a USB So, I am considering switching my current OS to Qubes and I am currently running Lubuntu 14.04 LTS.  I figured since Qubes is a lot more secure of an OS, I wanted to install it on my laptop as my main OS I use to have a "fresh" install feeling, and to feel a little more secure with my funds being on there.

I would prefer not to re download the entire blockchain from scratch; so how can I save the already synced blockchain I have onto a USB along with Qubes so I can use it right after installation?

I assume you will use the environment based on Debian or Fedora. In that case, you can copy the current .bitmonero to the equivalent location on Qubes.
When you re-run bitmonerod, it will continue as it would have on your Lunbuntu system.

There is no need for a specific verification of the chain since you trust the provide of the file (yourself).


Is it possible to set the GUI to run over Torsocks? Hopefully this will be possible and made easy for the user, perhaps with the click of a button?

There is no way to directly configure Torsocks in the GUI at the time of writing. However, you can run monerod and connect the GUI to your local daemon.

Set the daemon to connect to Tor. Use the guide here.


sc_reduce32 ... is it really supposed to be that complicated? sc_reduce32 in crypto-ops.c looks super involved, but according to MRL-0003.pdf, its just:

  4.1.11 sc_reduce
  Takes a 64-byte integer and outputs the lowest 32 bytes modulo the prime q . This is not a CryptoNote-specific function, but comes from the standard ed25519 library.
  4.1.12 sc_reduce32
  Takes a 32-byte integer and outputs the integer modulo q. Same code as above, except skipping the 64→32 byte step

Also according to this question(sorry I don't have enough rep to ask as a comment):

import ed25519
import binascii
spendkey_hex = b'77fadbe52830d30438ff68036374c0e3fb755d0d983743bcbfb6a45962f50a09'
sk = binascii.unhexlify(spendkey_hex)

def sc_reduce32(n):
    n = int.from_bytes(n, byteorder='little')
    l = (2**252 + 27742317777372353535851937790883648493)
    reduced = n % l
    newbytes = reduced.to_bytes(32, 'little')
    return newbytes

reduced_sk = sc_reduce32(sk)

which in turn doesn't match MiniNero code:

q = 2**255 - 19
l = 2**252 + 27742317777372353535851937790883648493
def sc_reduce_key(a):
   return intToHex(hexToInt(a) % l)

I realise MiniNero is hugely outdated and ShenNoether's replacement never materialized. His version/profiles have disappeared from GitHub/Reddit(Noblesir), but I noticed that Ryan started work on replicating sc_reduce32 in Python(note he's also the guy who asked Q2290), but it seems incomplete.

I wonder if someone could clarify for me what exactly sc_reduce32 is currently supposed to be doing, so I can continue/complete replicating it in python(unless someone already has? link please?).

I experimented with this using javacsript biginteger library and it is what it says - just a mod l operation. Endianness and encoding could make some confusion, though.

From your code it looks like the difference is just in the input/output format. One uses a string with base16 encoding, and the other one uses a byte array. They should both represent the same number, though.


I made up a payment ID when sending, will it go through? First time using monero. I sent a payment to an address. There was no mention of a payment ID from the receiver, but I decided to include an 8-digit payment ID anyway and sent to their address with my made-up payment ID. Will my payment go through, or did I just send it to the void?  I told the recipient the payment ID, but I'm afraid that by including the payment ID in the first place, I modified the address. This was from coinex.  Shouldn't the page have stopped me if I entered an invalid payment ID (8-digit)? I have since read that payment ID must be 16 or 64 digits.

If your exchange allows you to input a payment ID somewhere, they should be dealing with it appropriately. This means they should ensure it is the correct length / format and they should set it on the transaction correctly. When you executed the transfer, the exchange should also have given you a transaction ID which you can search for on a blockchain explorer such as xmrchain.net. Lastly, including a payment ID does not affect the destination. Whether you included a payment ID or not, your recipient should still receive the funds.


How do I know if I am mining in a pool? So I started mining from monero-wallet-cli using "start_mining 2".  When I enter "status", the output is as follows; "Refreshed 1254269/1254269, synced, daemon RPC v1.0".  Am I actually in a pool?  I have seen references to stale blocks if you are not mining in a pool, which leads me to believe that I may be.

You are mining in a pool when you are running a pool miner. If you mine directly from the daemon or wallet, you are solo mining, not pool mining.

Solo mining, which is your case, means you will take a long time to find a block. However, when you do find one, you will get to keep the entire block reward (currently about 8 monero, I believe) instead of it being distributed among all pool miners and getting a pittance.

Note that solo mining is done by the deamon. Starting mining in the wallet merely instructs the daemon to do so. If you want to double check you are actually mining, run status in the daemon itself. If you restart the daemon, mining will be automatically off on restart, for instance, though you would not have told the wallet to stop mining.


What is the CLI command to make use of tx_extra field in a transaction? And how does one retrieve this data back on the receiver's end? Say I wanted to attach a bitcoin address to a monero transaction in the tx_extra. How can I do this using the CLI wallet? And how does the receiver see this tx_extra  data?

The wallets only add specific data to tx extra (e.g. tx public key, payment ID etc) and do not offer options to embed arbitrary data. If you need to add your own arbitrary data, such as your example of embedding a Bitcoin address, you will need to manually construct and broadcast the tx. Of course, embedding something like this will make your tx stick out, which kind of defeats the purpose of using Monero in the first place.


print_tx TXID doesn't print ring Using the cli wallet, I swept my (pre-MoneroV fork) xmr to a new address using segregate-pre-fork-outputs appended to the command.
Then in the daemon I typed print_tx xxxxxxx where xxxxxx is the txid of the transaction.
The daemon only prints the block height.  Not the ring.  Is segregate-pre-fork-outputs only set up to work with the transfer command and not the sweep_all command?  If so, I can't use the print_tx command to show the ring.
However, I copied and saved all the text printed out during the sweep_all command in the wallet.  It shows 8 inputs, each with 6 block heights, and an asterisk next to one of the blocks for each input.  Is there some way to use that information to determine the ring for a MoneroV transaction?

The syntax changed recently, and you have to add "+json" to get what you need:

print_tx TXID +json

The reason was that this could be pretty spammy, so is not disabled by default.


Mining on an old Radeon 5830 with xmr-stak As the title suggests, I am attempting to run xmr-stak on Ubuntu 16.04.0.

Currently I am following a hodge-podge of instructions found here, here, and here.  I'm noticing an issue with dkm during the installation of amdgpu-pro.  Also, for whatever reason, clinfo will not locate my GPU.

Compiling is fine, but I believe my issue is finding a driver for the 5830.  However, I have noticed that amdgpu-pro does suppport my card.

For Ubuntu 16.04 LTS and above, the AMD Catalyst or fglrx driver (compatible with your card) is no longer supported by AMD, or in Ubuntu. The AMDGPU-PRO and AMD Blockchain BETA driver aren´t compatible with your card, finally, the opensource ones can´t be used for mining due to OpenCL.

So, one solution could be to try installing the fglrx driver on your system. Here the reference from Ubuntu WIKI.


Are transaction fees hardcoded? And if they are, why not be user defined like Bitcoin. Here we go again. My question does not have enough words in it so I am just typing.

They are hardcoded in the wallet software, not the protocol. That said, the protocol expects a non-zero fee for each transaction. The Monero protocol does not do fee free transactions so that it can prevent node, and blockchain spamming. Nodes also have the option of deciding which fee paying transactions they will relay of not, and if an enterprising users wishes to recompile the wallet client to send lower fees they can do so and take their chances on the transaction propagating and being mined.

The code in question, can be found here


What is sc_check function checking? In crypto-ops.c there is a function called sc_check. It is called with the secret key as a parameter. What exactly is this function checking for? That the key is not too small? But how? What re all these magic numbers?

int sc_check(const unsigned char *s) {
  int64_t s0 = load_4(s);
  int64_t s1 = load_4(s + 4);
  int64_t s2 = load_4(s + 8);
  int64_t s3 = load_4(s + 12);
  int64_t s4 = load_4(s + 16);
  int64_t s5 = load_4(s + 20);
  int64_t s6 = load_4(s + 24);
  int64_t s7 = load_4(s + 28);
  return (signum(1559614444 - s0) + (signum(1477600026 - s1) << 1) + (signum(2734136534 - s2) << 2) + (signum(350157278 - s3) << 3) + (signum(-s4) << 4) + (signum(-s5) << 5) + (signum(-s6) << 6) + (signum(268435456 - s7) << 7)) >> 8;
}

Elliptic curve encryption uses numbers called scalars (which are used as private keys). Valid scalars should be less than the group size of Monero's base point, i.e. the maximum allowable value of a scalar is 2^252 + 27742317777372353535851937790883648492

The sc_check method therefore verifies that the number is not too big. It does so in a strange way so that it runs in constant time. This prevents timing attacks that could leak information about the size of the scalar.

Math.pow(2,252) + 27742317777372353535851937790883648492 ==
1559614444 * Math.pow(2,8*4*0) +
1477600026 * Math.pow(2,8*4*1) +
2734136534 * Math.pow(2,8*4*2)  +
350157278 * Math.pow(2,8*4*3)  +
0 * Math.pow(2,8*4*4)  +
0 * Math.pow(2,8*4*5)  +
0 * Math.pow(2,8*4*6)  +
268435456 * Math.pow(2,8*4*7)


Advantages of using monerod over Tor According to the README, it seems like only the transactions sent from local RPC to the daemon get propagated through Tor. I am unable to understand why this choice was made/what its advantages may be. One advantage I can think of is that it would prevent a MITM in the circuit established between the sender and the receiver.
Also does the daemon relay the transaction only to other Tor nodes or do they relay information to all nodes in the Monero network?

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


Monero address validation using Java I wonder if there is a Java implementation of Monero addresses validation code somewhere?

I've found this JS implementation which seems to work well:

https://github.com/ognus/wallet-address-validator/blob/master/src/monero_validator.js

and, an online version:

https://xmr.llcoins.net/addresstests.html

But I've been unable to make a Java port of this code. As soon as I try ot decode the address to a byte[], using tools such as this one, I get a different array than the one from the JS lib.

For example, this Monero test address: "46oTQPpoxoxQ6XGWwPqEK1YvADH8X91rFC6brLWRHokoAC5qwbYKA2e9jzQyapENw4V2w5Tz1d4LiMSuDhhFCCf77mQgLRA"

The JS lib decodes it to (as an Hex string):

1288a647369f2eff8a13c3b9bc9d1448bed1046d431ec4a842578fcee2d49ec436f3310b57e0b12334429fb90e70304ba799a9ee799536a37a3df25dfd3e96c63bf7c2c4ad

When I try to do the samething in Java using:

byte[] decoded = Base58.decode(address);
String decodedStr = org.apache.commons.codec.binary.Hex.encodeHexString(decoded);

I get:

01375ee6692c3cc848c015498b3ae7660520580d15f8fc6c18ab92b68776e06658820d977b26913464b48a6d2961e95bb366d14fa19775482b7accecdb2f6b0c3c2565c1a3ad

Any idea?

Please refer to the following as to why your Base58 decoding mismatches:

Base58 does not strictly specify the format. This results in some implementations being incompatible with others, for example with regard to alphabet order.
...
Monero has its own variant of Base58.
In Monero the Base58 encoding is performed in 8-byte blocks, except the last block which is the remaining (8 or less) bytes .

[src]
I'm not aware of an existing Java implementation that encodes/decodes in the specific way Monero does (as described above), so you will likely need to roll your own, which should be an easy task.
Please also note, the Base58 decoding does not validate an address, it simply decodes the human readable string representation to binary. Depending on your needs, you could perform a very minimal verification of just the length and valid Base58 characters, a slightly fuller verification where you also check the network byte (which doesn't require a full Base58 decode), or you can go all the way doing a full decode, checking the network byte, verifying the checksum and checking the public view and spend keys are valid curve points.
I'd also like to draw your attention to an ecosystem project: monero-java. It currently has very little in the way of address validation (lots of "TODO" comments in the relevant file MoneroUtils.java), so if you do end up writing the relevant code, please consider contributing back to that project.


Is there a reason moneroblocks.info is several days behind on the blockchain? This might not be the right place to ask this and I guess the question isn't even that important. I just became really confused when the height the site showed didn't match the height of my local copy and was wondering if anyone had any insight  into why.

It appears as if the daemon relied upon by that block-explorer is currently down. Only the operator of moneroblocks can answer why it is down or when it will be working again.

For now you can rely on one of several other options such as on Monero Explorer.


I am missing (not seeing) a transaction to (in) the GUI (zero balance) I withdrew from Kraken / Poloniex / Bitfinex / Poloniex / any other exchange or service (e.g. Shapeshift) and I am not seeing the transaction in the GUI. How do I resolve this issue?

First and foremost, to put your mind and ease and to verify that your transaction was correctly sent to your address, use this guide to verify your transaction:
How do I, as a recipient, verify that my transaction actually arrived?
It should show that you have one output with output match? = True for the amount you expect to receive. If this checks out, you can proceed with the rest of the guide.

It's important to make sure you're running the latest version (v0.17.1.9 at the time of writing). You can check the version # on the Settings page of the GUI (under Debug info). If you're not running v0.17.1.9, please upgrade first:
How do I upgrade my software to the newest version?

The following assumes you're using a local node
First, you can check whether you are using a local node by going to the Settings page and looking at the daemon address. It should state localhost (or 127.0.0.1) with port 18081.
Now, the most common "problem" is that people are not fully synced yet or their GUI wallet is erroneously stating that it's fully synced. If you're not fully synced yet, the GUI will not be able to "see" your transaction. To confirm your fully synced, perform these steps:
[1] Go to the Settings page of the GUI.
[2] Go to the Log tab.
[3] Type status into the command + enter (e.g. 'help' or 'status') box.
[4] An output will be displayed that looks like:
Height: 1456425/1456425 (100.0%) on mainnet, not mining, net hash 290.20 MH/s, v6, up to date, x(out)+x(in) connections, uptime xd xh xm xs

Where x is simply an integer. For example, you could have 8 outgoing connections and 2 incoming connections. The Height can be explained as follows. The first number is the height you (personally) are currently on, whereas the second number is the top height (most recent block on the blockchain). The first number can be lower than the second number if you haven't completed the initial sync yet.
[5] Now to verify that you're actually fully synced, compare the first number to the height displayed on a blockchain explorer like, for instance, XMRchain. You're fully synced if your height matches the height displayed on a block explorer.
[6] If the GUI is stating that you're fully synced (100.0%), but your height doesn't match the height displayed on a block explorer (and is off by a large number), it is erroneously reporting that you're fully synced. This is, fortunately, easily resolved as follows. First, exit the GUI and make sure to stop the daemon as well. Second, restart the GUI + daemon. Third, use the status command to verify that it's now correctly displaying the top height.
[7] If the GUI is correctly stating the top block height, but is stuck on a particular block, perform these steps. First, exit the GUI and make sure to stop the daemon as well. Second, restart the GUI + daemon. Third, use Show status to verify that it's now syncing past the block it was stuck on.
[8] On the 9th of March (block 1788000) a scheduled network upgrade occurred. If you are still running a v0.13 version, you can be reasonably certain that you're on the wrong (alternative) chain. Intuitively, the GUI will not be able to see a transaction sent to your wallet if it's on the wrong (alternative) chain. Fortunately, this is easily resolved by following this guide
Note that after the daemon is fully synced, the wallet will start refreshing. In addition, in Monero, there's two "syncs". First, the blockchain sync, which is basically downloading the blockchain from other nodes / peers. Second, the wallet sync, which is the wallet "refreshing" / scanning blocks looking for transactions belonging to your address / wallet. You should see your funds once both syncs have been fully completed.
Now, if you're fully synced, the wallet fully refreshed and you don't see your funds yet, perform these steps:

Exit the GUI, but keep the daemon running.

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.

Once it states Connected (in the left bottom) you should see your funds.

Still not seeing your funds? Your wallet may, for some reason, have an erroneous Wallet creation height. You can resolve this as follows:

Go to the Settings page of the GUI.

Go to the Info tab.

Change the Wallet creation height to 1940000

This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.

You should see your balance once it completes.

Still not seeing your funds? It might be that a small part of your blockchain is corrupted and it's, coincidentally, the part that contained your transaction. Perform these steps:

Go to the Settings page of the GUI.

Go to the Node tab.

Switch the wallet mode to Remote node

In the address box enter node.moneroworld.com

In the port box enter 18089

Click in another empty box on the page to ensure your settings are properly saved.

Again 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>-old2

Restart the GUI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.

Once it states Connected (in the left bottom) you should see your funds.

The following assumes you're using a remote node
If you're using a remote node, you're basically using someone else's public node / blockchain. Therefore, it's unlikely that an uncompleted sync is the issue. Thus, perform these 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.

Once it states Connected (in the left bottom) you should see your funds.

Still not seeing your funds? Your wallet may, for some reason, have an erroneous Wallet creation height. You can resolve this as follows:

Go to the Settings page of the GUI.

Go to the Info tab.

Change the Wallet creation height to 1940000

This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.

You should see your balance once it completes.

If you, after all these steps, still don't see your funds (but verified with this guide that they were correctly sent to your address), it'd be best to either open a new issue the GUI repository or contact me on Reddit.


Which keccak algorithm does Monero use in its initial has function? The Monero algorithm says

    First, the input is hashed using Keccak [KECCAK] with parameters b =
   1600 and c = 512

I'm trying to re-create teh algorithm using JS and I found this keccak library -- https://github.com/emn178/js-sha3 , but my question is which keccak algorithm is the documentation referring to -- keccak512, keccak384, keccak256?  Still struggling to figure out all this stuff.

Monero uses keccak-256, where 256 refers to the bit length of the hash produced.

Note that SHA-3-256 is slightly different, and so will not produce the same result as keccak-256.

This library will produce the correct hash: https://www.npmjs.com/package/keccak


How does ShadowCash compare to Monero? Both these cryptocurrencies are meant for anonymous transactions.  What are the major technical differences between ShadowCash and Monero?

Monero is built on Cryptonote, which uses ring signatures (which it created in the context of cryptocurrencies) and stealth addresses. ShadowCash is built on Bitcoin, and reimplemented ring signatures (in a way that broke anonymity, see https://shnoe.wordpress.com/2016/02/11/de-anonymizing-shadowcash-and-oz-coin/). I have seen claims that they have stealth addresses, however you can see an address' balance, so it seems contradictory. That's also a difference with Monero, where you can't tell an address' balance.

Monero uses a single token. ShadowCash uses two, an anonymous one and a non-anonymous one, and can transfer between the two. This causes the anonymity set to be a fraction of what it'd otherwise be.

Monero has by all accounts had a fair launch. ShadowCash is said to have a very skewed distribution (though probably less bad than the winners of such schemes, Dash and Bytecoin).

Monero is PoW. ShadowCash is PoS (after a short period of PoW). This probably explains the previous point in large part.


What determines who gets the block reward I am trying to understand the monero code and was unsure how the code decides which address to the block reward to and how it is done. I have been able to follow the proccess up until we decide how much the block reward is but after that I havent been able to follow the code to see how it actually creates the transaction and sends it.

In the miner code, there is a request_block_template function, which requests a new block template to the daemon using the miner's address.

If and when the miner finds a block, she will create it from the block template that contains her address. If the block is accepted by the network, her address will be credited with the block reward.


Warptangent and simple wallet If I'm not running a node and all I want to do is open simple wallet to check my balance, do I need to download the latest version of Monero?

Because of the wording of your question it is not clear if you sometimes run your own node (when checking your balance) or if you never run a node and check your balance with another method (connecting to a remote node or using a view key tool available online).

If you are running 0.9.4 and all you want to do is check your balance then there is no urgency to update to 0.10.0.

If you are running a Monero version prior to 0.9.4 you should update now.


How is m calculated when generating subaddresses In Kenshi's notes in the subaddresses PR it says that when generating subaddresses m = Hs(a || i) and i is just the index of the subaddress. so if a is the secret view key "c8904212e0fc51ceecc7113937861c27948c8fef6f555d6b67f53f3a373dbf37" for the subaddress at index 1 m would equal hash_to_scalar("c8904212e0fc51ceecc7113937861c27948c8fef6f555d6b67f53f3a373dbf371") which is just the secret view key with a '1' tacked on at the end? I had asked on #monero-dev and moneromooo quickly responded, but I still don't quite understand.

moneromooo: Plus a common salt IIRC.
moneromooo: It's a constant that's concatenated to the key and index too. Just to ensure we can't (usual disclaimer applies) get collisions.

Can anybody shed some light on what this salt actually is/how it is generated?

After digging through the code and asking some more on IRC, it looks like the salt is "SubAddr" https://github.com/kenshi84/monero/blob/53ad5a0f42174bca57e24485ef3d40e4b9cf5599/src/cryptonote_basic/cryptonote_format_utils.cpp#L134 so it is really more like Hs(prefix || a || i). thank you to the people who helped me on #monero-dev


How do I figure out what nodes I'm connected to and who is sending what to who? When I type print_cn into the daemon, I see a lot of OUT and IN entries.

Does OUT mean that I am sending information OUT to that peer, or is that peer sending information to me? Or is it a two-way connection? If I see an IN connection, is that connection connecting to me?

It's a two way connection, the IN refers to connections initiated by the peer, and OUT refers to connections initiated by your node, but communication is duplex.

In that status command, the X+Y part is X OUT connections and Y in connections. You're connected to all of these nodes, the only difference is which side initiated the connection.