Does Monero offer an equivalent of Check Lock Time Verify transactions?

There is a command to lock coins when you make a transaction by RPC in simplewallet. I don't think it's implemented in the command line interface. It's the unlock_time parameter in the JSON RPC transfer, described in the source code here:
https://github.com/monero-project/bitmonero/blob/eb1b87d2393f34caa9698bec23a4b78fa57da752/src/cryptonote_core/cryptonote_basic.h#L169

uint64_t unlock_time;  //number of block (or time), used as a limitation like: spend this tx not early then block/time

I think if you pass it an integer smaller then the current unix time in seconds, then it will interpret it as a number of blocks, and if it is larger than the unix time then it is interpreted as a time when the coins can be spent, or if it is zero then the funds can be spent immediately.

You can find a description of the JSON format for making RPC transfers and an example of one here:
https://wiki.bytecoin.org/wiki/Simplewallet_JSON_RPC_API


Format of numbers decoded from ECDH amount

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.


Troubleshooting GUI After April 6 2018 Upgrade (Still Popping Blocks)

If you have let the daemon sync for 12hours on 0.11, a lot of blocks needs to be popped on 0.12 so you could start syncing again.
According to your description, I'll recommend you let it pop what's needed to be popped, and let it sync after that.
Obviously it will take time, but still less than starting over.


How to get the balance of an integrated address?

An integrated address is just a normal address with an embedded payment ID. Thus you use the usual get_balance RPC method, or balance detail CLI command.

As they have a payment ID, you can also make use of get_payments (RPC) and payments <PID> (CLI), which will show you any incoming payments made to the address using the provided payment ID.

It's worth pointing out you should not use integrated addresses / payment IDs, as these are deprecated in favor of using subaddresses.


compiled executables not working on the server

The Illegal instruction error usually happens when trying to run a program that was compiled for another CPU architecture.

I guess the architecture of the computer on which you compiled the binary and the architecture of the computer on which you are trying run it are different.
If that's the case, instead of a regular compilation, you will have to either cross-compile for the second machine's architecture or compile directly on the second machine.


Doing both CPU and GPU mining on a machine?

Yes this is totally doable. Just make sure to leave some CPU breathing room for the GPU miner application to feed the GPU with data by limiting the maximum threads used by the CPU miner.


Can i receive payment from bittrex without payment id?

You don't have to use a payment ID when you're sending to your own wallet. Thus, simply put your wallet's address in the Base Address box, specify a Quantity, and leave the Payment_ID box blank. More information about use cases of the payment ID:

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

https://monero.stackexchange.com/questions/tagged/payment-id

P.S. If you want to verify that your transaction correctly arrived, use this guide:

How do I, as a recipient, verify that my transaction actually arrived?


Why does the SHA512 code include numbers ending in ULL?

Found the answer by googling in order to formulate a somewhat intelligent question: ULL means Unsigned Long Long integer.


How long does it take for the coins to go from cold storage into a hot wallet?

Making a paper wallet "hot" by restoring your mnemonic seed in the GUI or CLI it needs scan all blocks for outputs that match your keys. You can speed up this process if you know approximately when you first created your wallet / sent the first transaction to it and check Monero's block height at that date, so your wallet doesn't have to scan the entire blockchain any more but only from that date on.

However, the scanning process is computationally intensive and it may take several hours depending on your hardware. A fast SSD with the synced blockchain and a modern CPU will speed it up. You only have to do this once when importing your seed, next time your hot wallet will know up to which block height it already scanned the blockchain and will only scan new blocks for your outputs.


Monero GUI Beta 2 Window Covering Entire Screen (Linux, Arch x64)

It's already fixed in the code and you could re-build the GUI with that fix. Next release shouldn't have this problem.

In the meantime, and if you want to avoid re-building, you can edit the start-gui.sh script which came with the package and add the line export QT_AUTO_SCREEN_SCALE_FACTOR=0. Then, open the GUI by running ./start-gui.sh from the console.

After modification, the start-gui.sh file should look like this:

#!/bin/bash
export QT_AUTO_SCREEN_SCALE_FACTOR=0
export LD_LIBRARY_PATH=`pwd`/libs
export QT_PLUGIN_PATH=`pwd`/plugins
export QML2_IMPORT_PATH=`pwd`/qml
./monero-wallet-gui


I've spoken to Robby Dermody from Counterparty about this exact thing. Shoving the data into tx_extra is the trivial part, and in my opinion the best way to handle it would be to encrypt the data with the viewkey. You could reveal the tx key or the viewkey to reveal your asset movement, but it would otherwise stay private. Since transfers of an asset to another person would be encrypted with their viewkey (as with regular transactions, via DHKE) they would be able to decrypt the data and act accordingly.


There's no official web miner for Monero. Some developers wrote code for that purpose but that has nothing to do with the Monero project itself.

There are services where one may register, paste code to their website, and make visitors mine for them (and for miner authors, as they charge quite high fees).

Regardless of the origin of the code, this way of mining is highly inefficient. The mining algorithm is designed to run as machine code on bare CPU/GPU chips, not as high-level language in virtualized environment of a browser. Of course, WebAssembly optimizations may drive the overhead lower but don't expect it to be profitable unless you have HUGE traffic on your website.

And when you deal with huge traffic, the last thing you want is to scare people off by running some shady code on their computers, which spins up fans, eats batteries and usually generates anti-virus warnings. Having many visitors, you'll certainly find a better way to monetize that traffic.


How can I check if a key image has been imported into a view wallet?

The easiest thing to do, in my view (due to it being the most thorough), is to set up a normal wallet and daemon on an air-gapped computer (one not connected to the internet).  Your air-gapped wallet will contain both the private viewkey and the private spendkey.

You can periodically save a copy of the blockchain from an internet-facing computer, transfer it via USB or whatever to the air-gapped computer, and have the wallet sync to that.  During the sync process, this method will create key images for all outputs owned by that wallet (and, of course, it'll also check whether the key images have been spent).

This is the most thorough way of knowing that all key images are accounted for, since the wallet will create any that are missing.  In fact, this is arguably the only way for a cold wallet to "know" it reflects an accurate balance, because it has the private spendkey to do the key image work.

If you have an internet-facing wallet which only contains a private viewkey, but does not contain a private spendkey, then this task may be more of a manual process. If you know the key image of a particular deposit, and you think you've imported the key image but you're not sure, you can run incoming_transfers_verbose to see the list of key images currently in the wallet.  See this thread for more details on looking up key images.


Logic behind selecting even square root for fe_sqrtm1 = sqrt(-1)

I believe you'll find that it's the positive (as opposed to "even"), that's chosen (by convention). The positive one has the sign-bit set as 0.


The genesis block is not predicted. The genesis block is decided upon in advance, and then hard coded as the first block that must appear in the blockchain.

You can see it hard coded in the codebase here:

std::string const GENESIS_TX = "013c01ff0001ffffffffffff03029b2e4c0281c0b02e7c53291a94d1d0cbff8883f8024f5142ee494ffbbd08807121017767aafcde9be00dcfd098715ebcf7f410daebc582fda69d24a28e9d0bc890d1";

(See https://github.com/monero-project/monero/blob/8361d60aef6e17908658128284899e3a11d808d4/src/cryptonote_config.h#L162)

What that hardcoded transaction means is: Create 17.592186044415 XMR out of thin air (that is the base 10 representation of the amount ffffffffffff03 in hex) as a mining reward, and let the recipient of the amount be whoever knows the private key corresponding to the output public key 9b2e4c0281c0b02e7c53291a94d1d0cbff8883f8024f5142ee494ffbbd088071.

There is a transaction public key included in the transaction which would help the recipient's wallet automatically determine that this output was destined for the wallet via the usual Monero mechanisms (the tx public key is combined with the recipient's wallet's private view key and public spend key, and this is cross referenced with the output public key to check if that output is destined for the wallet).

  At first, we don't have any wallet. So, how can you make a transaction to the wallet "9b2e4c0281c0b02e7c53291a94d1d0cbff8883f8024f5142ee494ffbbd088071" ?

Firstly, 9b2e4c0281c0b02e7c53291a94d1d0cbff8883f8024f5142ee494ffbbd088071 is not the destination wallet. It's something called the transaction public key, which is an elliptic curve point which the destination wallet uses to figure out whether the transaction is destined for that destination wallet, and helps the destination wallet figure out how to construct the necessary keys to later spend the funds.

To be able to receive funds, all you need is two private/public key pairs (your private/public spend and view keys), and these can be generated independently. It's just math. To generate the tx public key, you just create a random number r and then determine the tx public key by multiplying r with the ed25519 elliptic curve base point G. To generate the output public key, you combine the recipient's public view and spend keys with r (the specific algebra is Hs(rA)G+B).

  How can you get the transaction id ?

The transaction id is just a hash of the transaction, which can be determined after you manually create the genesis transaction. It can be determined by simply performing a Keccak hash on the hard coded transaction.

  How can you predict the wallet address ?

As mentioned above, you manually create it by creating two public/private key pairs.

  Are you supposed to create a wallet before you start the blockchain ?

You just need to create the two public/private key pairs. As side note, technically you don't actually need to even create wallet private/public key pairs to receive funds. If you know the specific output that is yours, you can spend it directly if you know the output private key (which you could know if you manually created the transaction yourself, but not if someone else created it for you). But wallet addresses and tx public keys are there so that the wallet can detect the incoming funds and mathematically determine the correct output private key without having to be told this information outside of the blockchain.

  Or maybe this wallet is fake and "locked", and the amount inside is "lost" ?

The genesis block was created by thankful_for_today, see https://bitcointalk.org/index.php?topic=563821.0

If thankful_for_today wanted to, they could certainly spend the funds created in that block (as long as thankful_for_today didn't intentionally mangle the output public key so that there is no known key to spend the funds - we can't tell from looking at the blockchain). Perhaps thankful_for_today did spend it - Monero's ring signatures make it impossible to know.


Monero hard fork - cant mine new transactions

You could try this:

In file...: monero-${VERSION}/CMakeLists.txt

Change....: set(PER_BLOCK_CHECKPOINT 1)
To........: set(PER_BLOCK_CHECKPOINT 0)


How much memory does monerod take on a Ubuntu server?

Looks like 1.75 GB.

$ docker stats

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
59cba0501edf        monerod             1.61%               1.751GiB / 15.54GiB   11.27%              81.2GB / 421GB      136GB / 224MB       25

This particular invocation has been up for about 4 weeks, since I last needed to reboot the kernel. (I've set Docker up to restart the process on boot)


Install the necessary prerequisites (on top of a default Ubuntu MATE image):

sudo apt-get install cmake g++ libboost-all-dev

Create a git directory:

mkdir git
cd git

Clone the GitHub repository:

git clone https://github.com/aeonix/aeon.git
cd aeon

Compile the sources:

make

After about 30 minutes, you'll end up with the following binaries in the build/release/src subdirectory:

-rwxrwxr-x 1 user user 3600096 Jan 26 14:44 aeond
-rwxrwxr-x 1 user user  829136 Jan 26 14:44 connectivity_tool
-rwxrwxr-x 1 user user  789768 Jan 26 14:46 simpleminer
-rwxrwxr-x 1 user user 2768864 Jan 26 14:47 simplewallet

When synching up the blockchain, if you have a nearby node available, use the --add-priority-node option to speed up the process, e.g.:

./aeond --add-priority-node <IP address>:11180


Monero is based on Cryptonote, which has a forking guide. This guide will show you the places in Monero's codebase that you'll want to examine and modify: https://github.com/cryptonotefoundation/cryptonote#cryptonote-forking-how-to

The main things you'll want to do are:

Name the fork
Decide on the total money supply, emission curve and time between blocks
Have a unique value for the daemon Network identifier so that your fork doesn't clash with existing Monero nodes
Set up seed nodes where new nodes will connect to discover the blockchain to sync to
Set a wallet address prefix that is different to Monero's, to prevent confusion
Create the genesis block
Build the code to create executables


Monero transactions have a multi-layered ring signature.

This multi-layered ring signature has one or more rings.

There is a ring for every real output being spent. Each of these rings will have the same number of ring members, known as the ring size. These ring members are references to public keys of outputs on the blockchain (sometimes referred to as one-time output public keys or stealth addresses). Ring members which are not the real output being spent are known as decoys. An older term for the number of decoys per ring is "mixin", and therefore mixin = ring size - 1.

For every ring, there is a key image. Therefore the number of key images per transaction is the same as the number of real outputs being spent in the transaction. Each key image anonymously identifies the real output being spent in each ring, and prevents double-spends. There is only one real output being spent per ring.


Why is the emission curve of Monero so steep?

It's steeper than bitcoin's because thankful-for-today made it that way. Indeed, if you dig into the bitcointalk forum history, you can find that not many early monero community members were supporting this curve and there was actually discussions about changing the curve.

While this is outside the scope of this particular question, no one actually knows the characteristics of an ideal emission curve. Take for instance Cryptonite (the bitcoin-based coin that uses an innovative accounting system as opposed to straightforward ledgering). This coin has an extremely shallow emission curve - if you mine it now you will get very similar rewards compared to if you mine it in 4 years (or something). This provides no incentive to start mining now - you could wait a couple of years. Thus, there's no incentive to "bootstrap" the network in a speedy fashion. As a result (or its just coincidence), the coin languishes, albeit its obvious advancement of blockchain technology that would completely eliminate any concerns of blockchain scaling, at least regarding the blockchain database.


Transactions have a version field (see here and here, which is currently 2, RingCT). However RingCT signatures also specify a type in rct_signatures.type. RCTTypeSimple etc, are the type of RingCT signature used and are defined here.

Therefore it depends what you intend on changing (transaction / signatures), that would determine which field(s) you should change to ensure backwards compatibility.

If you intend on doing away with RingCT altogether, you would of course change the transaction version field.

If you intend on creating a new type of RingCT signature, you would create a new signature type.


How to simulate (or set up) localhost as a mining pool for XMRig miner?

Your best bet is to install one of the XMRRig supported pools if you are wanting to test localhost.

For large page support, I believe you just need to run the app as an administrator. Information on the XMRRig project page https://github.com/xmrig/xmrig#huge-pages-unavailable


How do I upgrade my software to the newest version?

First and foremost, we encourage users to check the integrity of the binaries and verify that they were signed by Fluffypony's GPG key. A guide that walks you through this process can be found here for Windows and here for Linux and Mac OS X.
CLI: (most recent version: v0.17.1.9)
If you are using the CLI you ought to perform the following steps:

Download the new binaries (the .zip file (Windows) or the tar.bz2 file (Mac OS X and Linux)) from the official website or Github.

Extract the new binaries to a new directory of your liking.

Copy over the wallet files from the old directory (the one that contains the v0.15.X.X, v0.16.X.X, or v0.17.X.X binaries).

Note that a blockchain resync is not needed. Thus, if you open monerod-v.0.17.1.3, it will simply pick up where it left off.

GUI: (most recent version: v0.17.1.9)
If you are using the GUI you ought to perform the following steps:

Download the new binaries (the .zip file (Windows) or the tar.bz2 file (Mac OS X and Linux)) from the official website or Github.

Extract the new binaries to a new directory of your liking. This is the easiest and recommended way. Alternatively, however, you can overwrite the old binaries.

Open monero-wallet-gui¹. It should automatically load your "old" wallet and you should be set for the upcoming scheduled network upgrade.

If you're running a local node, the integrated daemon (monerod) will first have to convert your database to a new version. This may take a 5-10 minutes and the GUI will show that it's Disconnected. I'd advise to simply let it run and after the database conversion has completed the GUI will connect back to the daemon (monerod).

(1) On Linux you ought to start the GUI with the start-gui.sh script, i.e., ./start-gui.sh.
(2) If, for some reason, the GUI doesn't automatically load your old wallet, you can open it as follows:
[1] On the second page of the wizard (first page is language selection) choose Open a wallet from file
[2] Now select your initial / original wallet. Note that, by default, the wallet files are located in Documents\Monero\<wallet-name> (Windows), Users/<username>/Monero/<wallet-name> (Mac OS X), or home/<username>/Monero/<wallet-name> (Linux).
Lastly, note that a blockchain resync is not needed, i.e., it will simply pick up where it left off.


Using exponentiations instead of ECC multiplication in computing Stealth address

The reason we use ECC multiplication (which I'm sure you know is not just regular integer multiplication) is that it is a homomorphic trapdoor function.

You could potentially use unpadded RSA to achieve the same objective https://en.wikipedia.org/wiki/Homomorphic_encryption

However, the reason that all cryptocurrencies use ECC and not RSA is that RSA public keys in particular are enormous compared to the size of ECC public keys. RSA would make for an unnecessarily bloated blockchain.

There is another way of interpreting your question though. Sometimes people use the term exponentiation to describe the exact same operation that Monero usually describes as scalar multiplication. In which case, you could use the alternate notation. Just note that the equivalent of rA is written as A^r and not r^A.


How to start Wolf's AMD miner on boot with Ubuntu?

sudo nano /etc/systemd/system/runminer.service

In there, paste this (everything between the lines):

[Unit]
Description=Monero GPU miner
After=network.target

[Service]
User=YOUR_USER_NAME_HERE
Group=YOUR_USER_NAME_HERE
WorkingDirectory=~

Type=simple
ExecStart=PUT_LAUNCH_COMMAND_HERE_USING_FULL_PATHS

[Install]
WantedBy=multi-user.target

After that, do

sudo systemctl enable runminer.service

Then, to launch right now.

sudo service runminer start

Or just reboot it. To see if its running, run

sudo service runminer status

to see the full logs, try

sudo journalctl -u runminer.service

(caveat - I think that should all work. Haven't tried it yet)


Can a 3 letter agency see if I am running Kovri?

It depends on where they're listening, but yes in the sense you probably mean.

The I2P protocol underlying Kovri has a signature like any other protocol, and anybody who can see all of your traffic can see that you're using I2P. I don't think I2P even tries to make that hard at all... and if it did there would still be limits to what it could do against a sophisticated adversary.

Corporate firewalls, ISP traffic statistics and quality of service equipment, and the like can also detect that you're using I2P if they care to look for it.

Like Tor, I2P mostly tries to hide what you're doing, rather than hiding that you're doing anything.


Stagenet mirrors mainnet's features. Stagenet was part of the Monero Lithium Luna release on March 29th 2018 https://getmonero.org/2018/03/29/monero-0.12.0.0-released.html

Stagenet does not use the same blockchain as mainnet, but it shares the same features and consensus algorithm. It is therefore perfect for testing transactions without having to spend real XMR. The mining difficulty for stagenet and testnet is very low, so it is easy to solo mine your own stagenet or testnet coins yourself using the Monero GUI.

To solo mine with monerod, enter the command: start_mining <address> <number-of-threads>

There is a block explorer for stagenet available here: http://162.210.173.150:8083/

Testnet is for testing new Monero features which are not yet available on stagenet or mainnet.

There is a block explorer for testnet available here:
https://testnet.xmrchain.net/


Monerod not syncing past ~1200700 in TAILS - Segmentation fault

Please update your monerod to the latest version 0.10.1.0 Wolfram Warptangent.

There has been a hard fork to introduce RingCT transactions at block 1220517 and if you are running an old version, it will not be able to sync with the network.


Pass data from sender to receiver in a transaction

I've tried to create an old style payment ID (32 chars), but the new style payment ID accepts only 16 chars.

Old style payment IDs were removed several versions ago as they were unencrypted and made transactions stick out like sore thumbs, which is precisely something we want to avoid.
Hence they were removed.
So now, every tx has an encrypted 8 byte payment ID; which if the sender doesn't set, a dummy/random one is attached instead. This means every tx has an encrypted payment ID now, so they are effectively indistinguishable.

I want to pass data from sender to receiver in a transaction.

Monero is not some general purpose blockchain or messaging protocol, it's private digital cash. Thus if you want something to transfer arbitrary data, I suggest you use one of the myriad of other technologies to do so.
If you just need to privately tag a tx, use the 8 byte encrypted payment ID and keep track of that externally. For example, you could place an external database table's row primary key in the payment ID. Or alternatively use a subaddress.


The best place to understand Monero mining is to start at https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/miner.cpp

This is the in-built miner which implements the threads for fetching block templates, hashing and if a valid nonce is found, submitting to the network.

From this file, you can grep various other methods it uses to delve deeper.

Understanding the overall project structure requires studying it. Get comfortable with searching the source files with grep or whatever search tool you are used to.


In theory, yes. In practice, this might be a bit harder, depending on how the data is laid out in the on-disk blockchain database. Typically, for access speed, data is laid out in a fixed size vector, like this:

A B C D

Now if you want to prune C, you end up with

A B _ D

The space used by C is now unused, but you may not necessarily be able to reclaim that space easily. It is a similar problem to memory fragmentation. Somtimes you can compress this to

A B D

But if you have fast index based access to elements, you have to keep D at offset 4. So it depends on how the database is structured.

Nevertheless, some of that data can be pruned without such problems. You do lose the ability to query the database for those outputs, though.

In any case, you do not want to delete their key images, or they'd be spendable again.


How to programatically validate Monero address

To do a rough check on a Monero standard wallet address (not an integrated address), verify that it is 95 characters long, check it starts with a 4 (standard wallet address) or an 8 (subaddress) and that it only contains valid Base58 characters. The definition of Base58 allowed characters is "mixed-case alphanumeric, except the following similar-looking letters are omitted: 0 (zero), O (capital o), I (capital i) and l (lower case L)".

To do a rough check on a Monero integrated address, the procedure is the same as above except you'd verify that it is 106 characters long instead of 95 characters. It will still start with a 4.

To fully validate a Monero standard address or subaddress, you need to split it apart and verify the checksum. To split it apart, you need to perform a base58 decoding, taking care to note that Monero's base58 implementation is different to that of Bitcoin. Let's call that decoded result W. The first byte of W is the address type, which you should make sure is either 0x12 (standard) or 0x2A (subaddress). Then you need to check that the first 4 bytes of the keccak-256 hash of the first 65 bytes of W match the last 4 bytes of W. The technical details are here: What are the "public" viewkeys and spendkeys?

To fully validate a Monero integrated address, the procedure is the same as above except when you base58 decode it to get W, check that the first byte is 0x13. Then you'll check that the first 4 bytes of the keccak-256 hash of the first 73 bytes of W is equal to the last 4 bytes of W.

You'll see a javascript implementation of these methods (including keccak-256 and base58 decoding) here: https://xmr.llcoins.net/

There is a 1 in 4.3 billion chance that the address will pass the checksum test if it is corrupted. If you want to be insanely thorough (perhaps because you'd written your own code to generate addresses and wanted to check you were generating them correctly), you could check that the compressed EC points in the address are valid. To do this, after reading the first byte of W, you'd then read two groups of 32 bytes as EC points. Then you'd attempt to decode each point using a library that would alert you to badly formed points. Random bytes would be valid Ed25519 points 50% of the time. After that, you'd verify that the curve points are in the group of the Ed25519 base point G. To do this, you'd scalar multiply each EC point by 2^252 + 27742317777372353535851937790883648493 and verify that the resulting EC point hex is the identity point 0100000000000000000000000000000000000000000000000000000000000000. There would only be a 1 in 16 chance that random bytes would pass this test (i.e. 1 in 2 chance it would be an Ed25519 point at all, and then only a 1 in 8 chance it'd be in the base point group).


Is it a bad idea to use CpuLimit with Monero software?

It should be fine, unless the programs stay stopped for a long time, in which cases timeouts may occur. If you're local, timeouts with a single client is more than 3 minutes IIRC, so it should be just fine. I've done this a few times before with a loop and kill pidof monerod and there was no problem.


Monero GUI goes from connected to still downloading?

Part of the problem is the size of the blockchain. As each new block is solved and added to the chain, it grows in size. You are caught in somewhat of a (winnable) race condition: The Monero blockchain is set to dynamically adjust difficulty such that a new block is minted approximately once per minute. Each minute that goes by while you're downloading the blockchain, another block has been added to the chain. In essence the finish line is moving slowly and steadily away from your computer, as it runs to catch up. The biggest factors in how long it takes to catch up is your download speed, and the upload speed of the node you're syncing your wallet or daemon with. One thing you can do to speed up the process is to download a copy of the blockchain, and import it, giving your wallet client a "head start" in essence.


The scheme from the site is a good one and it won't be lost if you don't lose it :)

But anyways, it's fairly simple to remember: hash the passphrase with CryptoNight and EC add it to the original seed. Even if lost, knowing the scheme, it could be reimplemented.

This method has the benefit you seek -  encrypted seed looking like any other. You could roll a random seed, and then make multiple other seeds from it by applying different passphrases. Store only the "main" one, and put some pocket change on it to fool a potential thief into thinking that's all there is.

There's acutally already a PR to implement the same method into "official" software: https://github.com/monero-project/monero/pull/2257


Problems with creating name and regularly accessing view-only wallet for cold storage

I just looked into this, and it seems the method for generating from an address and view key has changed. I am using simplewallet from v0.9.4 and can create a view-only wallet, save it, and then open it again using the following command  (I am showing the Monero Developer's donation address and view key here):

simplewallet --generate-from-view-key monerodevaddr.bin --password xxxx

Simplewallet then prompts you for the address

Standard address: 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A

followed by the view key

View key: f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501

I then can save and exit

exit

and reopen the wallet

simplewallet --wallet-file monerodevaddr.bin --password xxxx

Note: I did not test this method with refresh after creating the wallet because 1) I don't think that should matter as to whether things are working and 2) the Monero Developer's donation address has a ton of inputs and refreshing would take a long time.

Note 2: This change in creation method seems to have been made sometime between v0.9.1 and v0.9.4, and it is possible that it will change again in the next version (v0.10). As far as I am aware, I do not think the simple command you said above works anymore...


There isn't one yet, since mobile devices that run Android are notoriously inefficient at large-scale numerical processing (mining). It's simply not worth the trade-off of electricity.

However, there were some attempts to create proof-of-concept, just for the sake of learning mining programming. I haven't heard back from the people announcing their attempts, though. (Honestly, I'd be interested in seeing the results of this myself.)


There are in-depth ways to answer your concerns, but it seems like you probably already understand most of it already, and it's just a matter of stepping back and seeing the whole picture.

There are very, very few instances now where outputs can be shown to be provably spent. For this reason, it's not fair to assert that traceability will increase over time.

It is true that there are cases where outputs can be shown to be provably spent.  One such example would be when ring members were all outputs from a prior ring with only one ring member.  This type of situation did happen prior to the enforcement of a mandatory minimum ring size.

Since the hard fork / protocol upgrade in September 2017, there has been a manadatory minimum ring size of 5.  Though through mere chance the occasional output in a post-Septemer 2017 transaction may be shown to have been provably spent, a series of events allowing for that would be exceedingly (though, for me, unquantifiably) rare.


XMR deposit from Monero GUI wallet is not showing up on Poloniex

Whenever this happens it is probably an issue on Poloniex' end. That is, your deposit has arrived, but isn't credited properly. If you want to check whether the deposit has actually arrived, but is simply not credited yet, you can use the following steps:

In the GUI, go to the history page and click on details of the transaction that was sent to Poloniex. | For the CLI, enter the following command: get_tx_key <transaction_hash>.
A window should pop up that shows the private tx key. Copy it. | For the CLI, copy the outcome of the get_tx_key command.
Go to this block explorer.
Enter your transaction ID / hash.
Now search the page for Prove sending.
Enter the private transaction key you obtained in step 2 into the first box. In addition, enter the integrated address Poloniex provided in the second box.
Press on prove sending.
If it shows "output true" it proves you correctly sent your XMR to Poloniex, but they haven't credited it yet. It could be that their wallet is temporarily stuck.


When setting up Monero wallet with Ledger nano S, what are the options 'restore height' and 'subaddress lookahead' for?

When you restore a wallet from seed, you scan the blockchain to attempt to decrypt the destination of each transaction, to see if any of those transactions were destined for you. This process will discover which amounts of Monero (a.k.a. outputs) are owned by your wallet.

If you know you had not received any funds prior to a certain date, you can save time by only scanning the blockchain from a more recent point in time. Block 1720000 was created on 2018-12-05 (see https://xmrchain.net/block/1720000), so if you restored from this height you would not see any funds in your wallet that arrived prior to that date.

The default subaddress lookahead is 50:200, which means creating a lookup table of 50 accounts with 200 subaddresses each, totalling 50*200=10000 subaddresses to scan for initially. Generating this lookup table requires computation, so by reducing the number you initially scan for, you can reduce the Ledger setup time. This is mentioned here: https://github.com/LedgerHQ/ledger-app-monero/blob/master/doc/user/bolos-app-monero.rst

By reducing the lookahead to 3:100, this means that if you'd created 4 accounts and received funds to the 4th account but not to the first 3, the Ledger would not notice any of the funds received to account 4 when scanning. Similarly, if you'd created 101 subaddresses in the first account, received funds to subaddress 101 but not to any of the first 100, then the Ledger would not notice the funds that arrived at subaddress 101. But if you had received funds at subaddresses 90 and 101, then when Ledger saw the incoming funds at subaddress 90 it would then automatically start scanning further ahead by another 100 subaddresses in the future, so that it doesn't miss incoming funds. For more information, see Funds received from subwallet are not showing

TL;DR: By specifying a restore height and smaller lookahead range, you decrease the computation required by the Ledger and can therefore restore your wallet faster. This comes at the risk of the Ledger missing incoming funds if you are restoring a very old wallet or if your subaddress usage pattern is such that you issue lots of unused subaddresses.


Is more cores or more RAM better for mining?

Neither. Mining on a VPS is worthless because the CPU(s) are shared. Use a dedicated server.


maximum number of transactions in memory pool

It really depends on the amount of RAM/swap you have.

There is no code to stop accepting transactions at any point at the moment, and if you eat up all you can in a spam attack, your kernel will kill bitmonerod. If that happens, you get to restart it, with more swap. If your node was the one the transaction was sent by the wallet, that transasction is nowhere else. If you were sent that transasction by another node, that node still has it, and it presumably got relayed to other nodes as well.

A transaction should not take much more RAM than its binary representation, but it's a bit hard to give an exact figure, since we're talking about std::map overhead, etc. So if you can afford half a gigabyte for the txpool, then, at an average tx size of 4 kB, you get...125k txes ?


Is it safe to share my key images with other people?

Every fund is associated with its output public key P = x G and the secret key x is ultimately the only thing needed for spending the fund (i.e., for generating a valid signature), just like Bitcoin.

A key image I = x Hash(P) where Hash(.) is a hash function that maps arbitrary data to a curve point, is merely needed to prevent double spending while maintaining the sender's anonymity. If you publish your view key, people can know those public keys P belonging to you, but cannot tell if the outputs are spent or not because key images I cannot be known from P alone. Publishing key images (that are signed with P) allows people to see if the relevant outputs are spent or not, i.e., to know the correct balance. However, it's impossible to know the secret key x from P or I.

So the answer is yes, it's absolutely safe to publish your key images. It just has the intended effect of letting people know the current balance of your wallet, and no one can steal your fund.


Trouble compiling Wolf's cpuminer-multi on Mac OS X

I've had the same trouble as you. Thankfully there is an OSX fork by correcthorse that's worked for me:

https://github.com/correcthorse/cpuminer-multi

It has the build instructions for OSX in the readme:

  install Xcode from app store
  install Xcode command line tools xcode-select --install
  accept Xcode license sudo xcodebuild -license
  install Homebrew /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
  brew install autoconf automake pkg-config
  continue with Basic *nix instructions

Basic *nix build instructions:

  ./autogen.sh # only needed if building from git repo
  Optimal GCC flags are built in - you only need to use -march=native if you want it
  CFLAGS="-march=native" ./configurec (Use -march=native if building for a single machine)
  make


While I don't know positively that mymonero.com is or is not compromised (I don't have any indication that it is), any web-based wallet is inherently unsafe compared with an official CLI or GUI based wallet. There are gradations of safeness one could say and a web-based wallet is on the very insecure end of the spectrum. On the top end would be a disconnected (cold) dedicated hardware wallet.

The good (and trusted) gentleman who runs mymonero.com advises not to store large amounts in the wallet. Basically, a good rule of thumb is: Only store as much money in a web wallet as you are willing to pay for the comfort of having a web wallet. Basically, only store as much money there as you are prepared to lose and don't come crying if your money is gone if you stored it in a web wallet.

As stated on the sign-up page of mymonero.com:

  Understand the Risks in Using MyMonero MyMonero is a web-based
  interface that allows you to use Monero without running a full Monero
  node. However, because this convenience comes at a cost: it is
  extremely difficult for MyMonero to securely deliver its code to your
  browser. This means that there is considerable risk in using MyMonero
  for large amounts!

  It is recommended that you treat MyMonero as you would treat your
  actual wallet, and not store very large amounts in it. For long-term
  storage of Monero you should create a cold wallet using MoneroAddress
  or similar.

A sobering and very enlightening reddit is here:
https://www.reddit.com/r/Monero/comments/52sw9r/9830_xmr_stolen_from_my_mymonerocom_wallet_be/

The upshot is that the number of potential exploits that can be used to exploit a web wallet are tremendous and out of the control of the web service providing the service. This is in addition to the possibility of the web service itself being compromised and delivering faulty code.

Edit:
There is a communication from fluffyponyza here about recent thefts from mymonero.com: https://www.reddit.com/r/Monero/comments/7kmzkv/psa_regarding_recent_reports_of_mymonero_thefts/

Also forgot to answer your second question:

  If MyMonero.com goes down can I use my private key in the GUI or CLI
  clients?

Yes you can. You need your viewkey and spendkey and your address which you can get from the mymonero.com under Account => Account Details. You have to do this obviously while the site is alive.

Just start the Monero GUI, and after you have choosen your language click on "Restore wallet from key or mnemonic seed". Then click the "Restore from Keys" tab.

Put in your address and viewkey and spendkey keys and you are away.


Which is the best way to integrate Monero in a e-commerce website?

This really depends on your level of technical expertise and website requirements.

If you can run your own node on the host, running that and the monero-wallet-rpc yields an easy to use JSON RPC interface you can make use of to process Monero payments.

If not, there are payment providers like GloBee, which help accepting multiple currencies and offer support etc.


Does monero have a dedicated marketing team or continuous marketing contributors?

Not yet. However, we have probably the best community in cryptocurrencies, what you can see on Reddit, the official forum or here at Stack Exchange.

In my opinion, marketing makes only sense after we have a GUI, so the average user can test Monero and compare to other coins.

So join the community and spread the word about the most advanced cryptocurrency out there!


Moneroaddress.org balance verification, wallet restoration, and usage precautions

If I wish to see my wallet balance later and restore it, should I use simplewallet?

Yes simplewallet is your best choice for restoring your wallet. Instructions to restore from mnemonic-seed can be found here. You can can also restore from keys but that is slightly more difficult.

Before restoration, the xmr tests site you mentioned is the easiest way to verify your balance (assuming your mnemonic seed and keys were kept safe and no outgoing transactions occurred) with the use of your view key to see the incoming transactions.

  Do any precautions need to be taken?

You did the right thing by creating your wallet offline

Store your mnemonic-seed in a safe place offline. When restoring, ensure your system is free from keyloggers and you use a strong password.


How to get the time at which a transaction was added to the pool?

The get_transaction_pool daemon RPC returns the current state of the txpool. The transactions field in the reply is an array of data for each transaction currently in the pool, and includes a id_hash field (the txid) and a receive_time field (the time it was received). Reminder that since the txpool is a local thing, different clients will receive transactions at different times.

The time a transaction was mined into a block is that block's timestamp. Daemon RPCs like get_block_header_by_height and others give you data which includes a timestamp field, which is that time. Note that this timestamp is miner controlled, and thus can deviate about two hours from the real time.

Both of these times are UNIX timestamps, which means they're seconds since the epoch (1970/01/01).


What's the relationship between the pool's advertised difficulty and the target of the jobs it sends out?

The port used defines the starting difficulty.

From the pool doc you referenced:

The Port is used in conjunciton with the url and is used to specify the starting difficulty.

As soon as you submit a result, the pool updates your difficulty for the next job it sends you based on how long it took you to hash the last (or to be more accurate, it averages your previously submitted job/hash times and adjusts based on block time). This is to ensure the server sends you jobs with a difficulty that can be expected to be hashed within the block time window and not overload the server sending lots of small difficulty jobs to miners that can be expected to hash higher difficulty per job.

Most pools allow you to specify a fixed difficulty. With your pool, if you wanted a fixed difficulty of 3500, this is done by appending +3500 to your wallet address (username). Example (again from the doc you referenced):

Username : 43To46Y9AxNFkY5rsMQaLwbRNaxLZVvc4LJZt7Cx9Dt23frL6aut2uC3PsMiwGY5C5fKLSn6sWyoxRQTK1dhdBpKAX8bsUW+3500


Is there a rich list of addresses of who owns how much of the Monero supply?

There is one: http://moneroblocks.info/richlist
Spoiler: it's empty. Quoting the site:

C'mon man. Really?
I thought you knew...
Monero is fundamentally
private
Really. It is.
It is based in the Cryptonote protocol. It uses unique one-time
addresses for each transaction so that only the receiver knows where
the money went. This is good, believe me.
And, as if that wasn't enough, it signs the inputs with ring
signatures. And this is great because that signature only proves that
someone in that group created it. That means only the sender knows
where the money came from.


Is there a way to connect the Monero Core (GUI wallet) to a remote testnet node?

You can create your own testnet by running two local nodes, and run a miner locally that mines on the local node blockchain. It has been covered in a reddit thread here: https://www.reddit.com/r/Monero/comments/3x5qwo/how_do_i_make_my_own_testnet_network_with_eg_two/

Demon:

/opt/bitmonero/bitmonerod --testnet --testnet-p2p-bind-port 38080 --no-igd --hide-my-port --testnet-data-dir ~/.bitmonero-node2 --p2p-bind-ip 127.0.0.1 --add-exclusive-node 127.0.0.1:38080

Wallet:

/opt/bitmonero/simplewallet --testnet --daemon-port 28081

Then go into the bitmonero node and start mining with the command:

start_mining <your_testnet_address>

I tested them out myself, and the above commands work no problem on a a low powered machine, you'll have your own testnet in less than a minute.

There is also another set of instructions here, https://moneroexamples.github.io/private-testnet/ , they are far more comprehensive, and a bit much to include here, but the above commands work and establishes the absolute basics.


Most of the information below is taken from this post on the GetMonero website.

To understand bulletproofs, you need to first understand what a range proof is. According to the post:

  A range proof allows anyone to verify that a commitment represents an amount within a specified range, without revealing anything else about its value.

Monero uses the range proof in RingCT to secure the amount being sent in a transaction. Without range proofs, the amount sent could be hidden, but a sender could cheat by making coins out of thin air. Thankfully, range proofs prevent this from happening.

Bulletproofs are a more efficient type of range proofs. You can view a copy of the research paper for free here. The research paper defines Bulletproofs as follows:

  ...a new non-interactive zero-knowledge proof protocol with very short proofs and without a trusted setup; the proof size is only logarithmic in the witness size. Bulletproofs are especially well suited for efficient range proofs on committed values...

Bulletproofs offer substantial improvements when using multiple outputs. With current Monero range proof technology, transaction sizes scale mostly linearly depending on the number of outputs (eg: 1 output = 7kB, 2 outputs = 13kB). With bulletproofs, these scale logarithmically instead (eg: 1 output = 2kB, 2 outputs = 2.5kB).

As the post notes, there are two ways bulletproofs can be implemented in Monero:

  This gives us two related types of bulletproofs: single-output and multiple-output. A transaction with multiple outputs can either include several single-output proofs or one multiple-output proof (which is smaller than the separate proofs).

The former brings substantial improvements, and the latter brings a little more than the former. The post estimates the following performance improvements:

  With our current range proofs, the transaction is around 13.2 kB in size. If I used single-output bulletproofs, the transaction reduces in size to only around 2.5 kB! This is, approximately, an 80% reduction in transaction size, which then translates to an 80% reduction in fees as well. The space savings are even better with multiple-output proofs. This represents a significant decrease in transaction sizes. Further, our initial testing shows that the time to verify a bulletproof is lower than for the existing range proofs, meaning speedier blockchain validation.

Bulletproofs will be deployed in the October scheduled protocol upgrade. It has been live in testnet since the beginning of 2018.


You can use any miner which supports cryptonight algorithm.
ccminer, cpuminer comes to mind, both supports cryptonight.
Minergate's miner is actually a moded cgminer, and their blog is actually quite helpful, but there are suspicions that their software is skimming hash rates, I personally don't use any closed source miners.
The ultimate solution would be running Linux, just wait a couple of months till the proper firmware from AMD and new kernels get released then you can try again.


I can't reproduce a hash sent from a miner [javascript]

Recall from this answer, the pool adds various data to the reserved space and it stores/caches the block template it used to create the hashing blob it sends to the miner.

Therefore, your lines:

 let template = new Buffer(blockTemplateBlob,'hex');
 let poolNonce = new Buffer(_poolNonce,'hex');
 poolNonce.copy(template,reservedOffset);

Look rather suspect.

First, blockTemplateBlob, where are you getting this from?? This would need to be the pools cached template, and I suspect you have not obtained this. Ref.

Second, in nodejs-pool, the variable they call "poolNonce" is only used for proxy jobs, not standard miner jobs. Ref.

Third, you are writing "poolNonce" to the start of the reserved space, which is not where this pool adds the "poolNonce" - they add it at job.clientPoolLocation. Ref.

Forth, you are not adding the miner specific nonce (what they call "extraNonce") into the reserved space (which should be at the beginning of the reserved space). Ref.

Given all this, I'm not surprised at all your hashes don't match.

UPDATE (for completeness):

Through the comments below, it turns out you were not supplying the correct height parameter to the hash function and job. The height has to match exactly the height of the block template and that which is supplied to the miner (and in your case, it turns out you never actually supplied the height to the miner). The pool has to of course use the same height it told the miner to use when hashing. If the heights mismatch, the hashes won't match. If you don't provide a height to the miner but do in the pool, the hashes won't match.


Can you see which addresses sent you money using your viewkey?

Monero does not allow a receiver to determine the address of who sent the received money, whether using the receiver's secret view or spend keys. This information is private to the sender only. The sender may supply an offline proof that they are the one who sent the money, however, but that's an extra, optional step for them.

Voting is usually an anonymous affair anyway, so knowing who cast a vote for a particular outcome is typically not needed.


I did not receive 0.37 Monero sent from FreeWallet on my iPhone to Monero-wallet-GUI (on MacBookAir)

Freewallet is not a trustworthy wallet service. Please use the monero wallet binaries at getmonero.org


Transaction fee using RPC for non ringct transactions

The fee is the sum of inputs minus the sum of outputs.
For ringct transactions, those are unknown, so the fee is stored separately, and added to the commitment check when verifying the transaction to ensure the fee is what was really used.


I seemed to have found where I was confused, as the subaddress code was moved the the device directory

https://github.com/monero-project/monero/commit/27a196b1268718dbc41e308c93b35c58f2da2eb4#diff-202edf76a605025eecb843af6b25fe80L114

This seems like a confusing change to me.


How could Monero enable instant transactions?

Daughter chains are one of the development goals for Monero. One of these daughter chains could theoretically be used to allow for instant/micro/etc transactions. The idea would be to allow super-fast transactions (or whatever other feature) on the daughter chain, and then settle back to main-chain once a day (or some other interval).


Implications and remedies of fixed 'H' in Pedersen commitment

The commitment is actually xG + aH where both G and H are pre-defined generators. The
hardness of the discrete logarithm problem ensures calculating a from H (or x from G) is infeasible. Put another way, both G and H are points, and because of ECC point multiplication, you can't deduce x or a.

Further, you'll see described in Maxwell's Confidential Transactions paper:

The Pedersen commitment is created by picking an additional generator
for the group (which we'll call H) such that no one knows the discrete
log for H with respect to G (or vice versa), meaning no one knows an
x such that xG = H. We can accomplish this by using the cryptographic
hash of G to pick H:

    H = to_point(SHA256(ENCODE(G)))

Which is precisely how H is constructed in Monero: H = Hp(G), which is H = to_point(Keccak(G)).

Further:

  However, if someone was to figure out the x above doesen't this become a single, centralized point-of-failure for the entire currency?

No. x is a binding factor in a single commitment. A centralized point of failure would be if someone knew the discrete log for H with respect to G (or vice versa). If one miraculously calculated an x in one commitment, this wouldn't compromise other commitments. Think about it like this: just because you know your x for a commitment, doesn't mean you can work out other x's.

Also:

  As a follow up: would it be possible for the sender to pick a fresh H for every transaction?

That's essentially what happens because of the point multiplication using a. E.g. aH.


At what stage is the Monero mining race at right now?

Right now Wolf's OpenCL XMR Miner for AMD GPUs (open source) and Claymore CryptoNote GPU Miner (proprietary) are probably the most efficient.

It is believed that Monero is still quite far away from ASIC mining largely because of the memory requirement and that CryptoNight takes advantage of the AES-NI instruction set on modern PCs. The relative advantage for ASICs would be lower for CryptoNight than other algorithms and the cost would be higher.

There are about 20 pools currently with crypto-pool.fr, minergate and unknown collectively occupying a large percentage of the hash rate.

Smart mining should help decentralize mining further upon release as it will use resources of many computers, whenever they are available.


How does signing the hash of the public key show that the signer knew the private key?

That's what signatures do. They prove that a private key must have been known for a particular public key that the verifier checks there has been a successful signature for. You can sign the message "hello" and that'd still prove you knew the private key for the public key that the recipient is expecting the message to have been signed for.

It explains it a little better further down in that document. It says:

  A pedersen commitment can be proven to be a commitment to a zero by
  just signing a hash of the commitment with the commitment as the
  public key. Using the public key in the signature is required to
  prevent setting the signature to arbitrary values and solving for the
  commitment. The private key used for the signature is just the
  blinding factor.

So your commitment to zero will be P = xG + aH, and since a=0, that simplifies to P = xG. Therefore the public key is P and the private key is x.

So you sign the message H(P) using the private key x. The recipient will know P, and will check the signature, which will prove x was known. Proving x was known proves that the commitment must have been a commitment to zero, because the private keys for Pedersen Commitments to non-zero values can never be known (because H=yG where y is unknowable).

Using H(P) as the message prevents attacks.


What is the function of decompose_amount_into_digits and its components?

That function splits a number into it decimal components, except for the lower significance ones, which are grouped.
For example, the number 84938394 will be split into 80000000, 4000000, 900000, 30000, and 8394 (if the dust threshold is 10000).

This was used by the ring signature process to pick outputs from the blockchain with the same amount as the one that's being spent, since otherwise there would be too many different amounts, and thus poor selection.
chunk_handler and dust_handlers are just two functions called with each of the split amounts above. Amounts below the dust threshold are called dust, and typically "complex" numbers which have few, or no, other potential ring members on the blockchain.

This is not used with RingCT anymore, since output amounts are hidden, and every rct output can be used in a ring signature with any other, doing away with the need for splitting amounts into those "canonical" ones.


Where can I find Monero public RPC nodes I can connect to?

Since Monero 0.15.0.0, you can use the public_nodes command in monero-wallet-cli. It will query your daemon, as the list is now shared over the P2P network. This can be used in tandem with the bootstrap daemon mode, so you can use RPC services before your node has finished syncing.

Similarly, the print_pl daemon command now accepts a publicrpc parameter to filter nodes by whether they offer publicly accessible RPC.

Yes, you do need a daemon in order to use those, and this is intended. If you really cannot spare the space for a blockchain (currently around 25 GB if pruned), then you can use the daemon on no-sync bootstrap mode, with the --no-sync daemon parameter. This will avoid syncing the blockchain while still allowing you access to the P2P public RPC nodes list without having to go through a central repository.


Is there a monero pruned blockchain mode like how bitcoin core has a pruned blockchain?

No there isn't. Pruning is currently being implemented though, with chances to be in the next hard fork.


Since Monero is based on the CryptoNote protocol, you should take a look at this resource and the standards here


Are any of the exchanges posted on site checked by anyone

Please take notice of the disclaimer:

"Please note: these links are being provided as a convenience and for informational purposes only; they do not constitute an endorsement by the Monero community of any products, services or opinions of the corporations or organizations or individuals listed. The Monero community bears no responsibility for the accuracy, legality, or content of these external sites. Contact the external site for answers to questions regarding its content. As always, caveat emptor ('buyer beware'); you are responsible for doing your own research. Always use judgement when making online purchases."


anonymity set (size) for stealth address (receiver)

S1 sends fund to R1 using a stealth addresses.

"stealth address" is an unfortunate moniker. When a user sends funds to another users address, they create new, special, outputs that the receiver now owns and only the receiver can spend; the receivers address never gets stored on the blockchain, only these newly generated outputs, which have no observable linkage to the receivers actual address. "stealth outputs" probably better describes them. Anyway, I digress...

The anonymity set (size) for the receiver (R1) is the size of all possible receivers in the blockchain.

Yes.

Once R1 spends the funds, the anonymity set (size) for the R1 is 11 (size of Monero ring signature).

Sort of. It's not so much the spenders anonymity set is 11 (the ring size), rather the true output being spent has an anonymity set size of 11. For each input (an output) being spent, is one of 11 possibles.


The initial number of moneroj in existence will be approximately 18.4 million.  However, once that number is reached, a perpetual tail emission of 0.6 XMR per 2 minute block (same rate as the original 0.3 XMR per minute tail subsidy plan) will go into effect.

The block subsidy constants are as follows (modified for clarity):

MONEY_SUPPLY = 2^64 - 1 // The max number of Tacoshis created before tail emission begins
FINAL_SUBSIDY_PER_MINUTE = 0.3 // Tail emission
const int target = version < 2 ? DIFFICULTY_TARGET_V1 : DIFFICULTY_TARGET_V2;
const int target_minutes = target / 60;
const int emission_speed_factor = EMISSION_SPEED_FACTOR_PER_MINUTE - (target_minutes-1);

The 'target' code was implemented when we switched from 1 minute per block to 2 minutes per block.

The tail emission and block subsidy are defined here:

uint64_t base_reward = (MONEY_SUPPLY - already_generated_coins) >> emission_speed_factor;
if (base_reward < FINAL_SUBSIDY_PER_MINUTE*target_minutes)
{
    base_reward = FINAL_SUBSIDY_PER_MINUTE*target_minutes;
}

The tail emission kicks in when the number of Tacoshi in existence (the smallest unit, there are one trillion in each Monero) is between (2^64 - 1) and (2^64 - 1 - .6*1000000000000), or .6XMR worth of Tacoshis away.


Key-image generation: What does p signify in I = xHp(P)?

There are two hash functions you'll see referenced often with Monero - there is Hs and Hp.

Hs means "hash to scalar", meaning take a keccak(256) hash and then ensure the result is a "scalar" (a positive integer less than 2252 + 27742317777372353535851937790883648493).

Hp means "hash to point", meaning take a keccak(256) hash, interpret the resulting bytes as an elliptic curve point, and then multiply that curve point by 8 to force the resulting point to be in the base point group - i.e. to force it to be the case that there must exist an value x (even though x will be unknown) such that Hp(..data..) == xG.


GUI pull request to build and install monerod

GUI daemon manager is recently merged into monero-core. I.e you can start/stop local daemon from GUI. This PR basically means that monerod is getting built when you build the GUI. Unfortunately win32 still requires some manual work.


Running monerod with --block-sync-size 10 syncs a lot faster, why?

A large block sync size is supposed to make things faster, as some lookups can be made once and reused. However, this uses more memory, and will be slower if it makes the OS start swapping monerod.

I don't know how 200 was chosen, but it was likely a good value for Tacotime, who added the code.

The upcoming release has the block sync size set to 100 prior to fork version 4, and 20 afterwards. This is based on circumstancial evidence, as there is a lack of systematic testing to determine which block sync sizes are better for which (CPU speed, internet speed, memory) confgurations.


Why does `monerod` on Raspberry Pi 3 with a copied LMDB not catch up with new blocks?

There was a bug in the ARMv7-specific source code, which was triggered when using newer versions of GCC to compile the code.

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

It has recently been fixed.


Mining with xmrig on monero.hashvault - I want to understand what I see on the command line

The "new job" line means the pool just sent your miner some work. Your miner will then repeatedly hash this data to find hashes below the requested target (which comes as part of that job). The last number of that line is the difficulty for that job. The higher it is, the harder it is to find a qualifying hash, but the more any solution counts towards your share of the block reward when the pool finds a block next.

The "accepted" line means the pool acknowledged receipt of a hash your miner found. 3/0 means this is the third accepted hash, and none were rejected (which can happen for various reasons, such as being for a previous job, below the requested difficulty, or otherwise invalid).

The "speed" line tells you your miner's hash rate. As far as I can tell, this shows three hash rates over three different rolling windows of 2.5 seconds, a minute, and 15 minutes. The hash rate stays fairly constant at close to 1200 H/s. Your miner hasn't been running for 15 minutes yet.

Huge pages are larger than default pages (usually 2 MB, while pages are normally 4 kB). Using huge pages for mining decreases TLB overhead, and gives a good hash rate boost. In your case, the hardware supports huge pages, but they're disabled. Enable by writing the number of huge pages you want in /proc/sys/vm/nr_hugepages. I think a good default is three per mining thread. With 32 MB L3 cache, you can run 16 threads (a thread needs 2 MB cache to be efficient), so 48 huge pages seems like a good one to try.

Lastly, your hash rate more or less matches the low end of the recommendation. You're fine there. Difficulty is variable anyway, so the pool will decrease it a bit once it works out you're near the low end of that range.


Examples of real stealth address from the blockchain

Here's one example: 47c99dab149170154cf1cdfb7e6a5993e1683e9d952aa0502b7b9f27f4129735

This is the public key for the first output in tx http://moneroblocks.info/tx/e706b52d74f74da37f0c016b976ede566fabf106c344a0fe1fb18cdb3751b0f6, the last tx made as of now.

I won't give the private key to it, both because I don't know it, and because it'd allow you to spend it :) But it'd look like a private key, which is, very much like the above (but modulo l).


The mixin count refers to the number of other signatures (aside from yours) in the ring signature that authorizes the transaction. A default mixin of 4 means that there are 5 total signatures. Someone looking at a transaction with a mixin of 4 has no way of knowing which of the five signers is the true sender (source).

"Mixin" as a term used in Monero is different than how the term may be used for Bitcoin or DASH mixing services. In Monero, new transactions "mix" with other previous transactions in the blockchain in the way the protocol itself dictates. In other services, you "mix" your coins with other users' coins to make one transaction with many inputs and outputs. The verb used here is the same, but they are referring to two very different things.

To try and reduce confusion, some community members have advocated changing the name "mixin" to something that will differentiate it from traditional mixing services. You can see some discussions here on StackExchange, on Reddit, and on the Monero forum.

A higher mixin number will typically provide more privacy than a lower mixin number because it will provide a greater amount of plausible deniability. However, reusing an odd, recognizable mixin for your transactions will make your transactions stand out. To see more about what mixins provide the greatest level of privacy, see this post.

The GUI allows users to select a mixin between 4 and 25. The CLI allows users to select any value permitted by the network.


Why does a node try all grey peers to create a connection?

This does not try all entries in the set, it picks one entry in that set.


Ok, I figured this out for myself. The built in microhttp server runs when the port number is set in the config.txt file. Had I read all the way through the config file the first time I would have seen the comment at the end.


Once you are in the wallet you can simple run exit, however it sounds like you want to stop monerod (the background daemon). In this case you would run monerod exit.

see How do I gracefully stop the monerod daemon process? for more info.


What's the easiest way to look up a transaction on the blockchain?

The best general tool for this is http://moneroblocks.info/.  It is somewhat comparable to the Bitcoin site https://blockchain.info/, and you can conduct searches using a number of different identifiers.

However, if you are focusing on a specific transaction, I think your best bet might actually be a very useful tool developed by one of our community members: http://xmrtests.llcoins.net/checktx.html

By using the transaction hash, viewkey or private transaction key, and the recipient's public address you can prove that a transaction made it to its intended destination.


How do I figure out how much a share is worth in the PPLNS world?

Shares are not equal. One persons "share" may have X difficulty and anthers has Y difficulty. Each share is associated the difficulty of an accepted hash. PPLNS favors miners that stay on one pool (as opposed to pool hopping) because the percentage of a found block payout is not just splitting on the hashes submitted for that particular block.

A good explanation of a specific implementation of PPLNS can be found here.


Why the syncing of the wallet is very very slow?

The Blockchain is huge. If you don't have a very high speed internet connexion, it's usual do need a week and a half to download the 55G Blockchain in a peer-to-peer manner with monerod.
Mine took that time to download.


keys file is opened by another wallet program

In the end it turned out the the keys file owner was root setting this to the correct owner with chown solved the problem.
sudo chown $USER:$USER keys /pathto/monero-gui/monero-storage/$USER/$USER.keys
sudo chown $USER:$USER keys /pathto/monero-gui/monero-storage/$USER/$USER

It was caused by me using sudo the first time I run the wallet this created the wallets keys file with root as owner.


Mining at pool: All results are rejected

This problem caused by recent network upgrades and if you are using old miners you will get the reject response which means your shares not accept by the pool. if you are using the minergate pool you have to use their official miner ( I tested 2-3 days ago and the last version of XMRig didn't work )

Try supportxmr pool, It has no problem with the last version of the XMRig miner.


Is a mnemonic seed wallet just as secure (random)

Is the number of possibilties of the 24 words the same as the 256 bits? So: are there 2^255 possible 24 word combinations or is it only a subset of the possibilities?

Actually, it's just a little bit more than needed to encode a 256-bit number. Possible 24 word combinations (=1626^24) > possible 256 bits combinations (=2^256).

  If it is just a subset, it would be less secure I think. It would be more open to brute force attacks.

It depends. I mean, it's like comparing a really huge number with a really huge number - a relatively small number. Both can be secure. Anyways, it's not a subset but there's one other detail. Not every 256 bits is a valid private key. Anything bigger than approx 252 bits gets "wrapped around" so you can have 2 mnemonics resulting in a same wallet, and the brute-force space would be this 252 bits. I believe it's "easier" to break EC crypto by solving discrete log problem, ie derive your private key from the public key instead of brute-forcing it. It's still "impossible", at least until QC :)

  An other way of asking the question would be: is there a unique 24 word seed for every possible 256 bit private key?

Yes.

More info on the subject: Can you choose the mnemonic seed to create a wallet?


How to conduct E-commerce transactions, XMR to GBP and conversion to fiat without KYC registration documents

curl -s 'https://api.coingecko.com/api/v3/coins/markets?vs_currency=gbp&ids=monero'  | jq . | grep current_price | cut -d':' -f2 | cut -d',' -f1

in bash will return the current GBP of Monero.  You can do your math on price from there.


How can I run a node with fluffy blocks enabled?

Simply run monerod with the --fluffy-blocks option.

Windows

Open a command prompt in the folder of monerod.exe, or create a .bat file. Type in the following:

monerod.exe --fluffy-blocks

Press enter (in the command prompt), or run the .bat file.

Linux/Mac

Open a terminal in the folder of monerod. Type the following and press enter:

monerod --fluffy-blocks


Accounts are never "deleted". The wallet does, however, need to precompute some elliptic curve points for all possible accounts and subaddresses that it will search for incoming funds at. By default, the wallet will not look ahead more than 50 accounts at a time, and will not look ahead more than 200 subaddresses at a time, unless it sees activity at those subaddresses.

You can start the monero-cli-wallet with the option --subaddress-lookahead MAJOR:MINOR where MAJOR is the number of accounts to look ahead, and MINOR is the number of subaddresses to look ahead.

I assume that you misspoke when you said that you had 10,000 accounts, and meant that you had 10,000 subaddresses all within the same account. Therefore, use the option --subaddress-lookahead 50:10000 and then type rescan_bc when you're inside the wallet.

Note that looking ahead 50:10000 means precomputing 500,000 elliptic curve points, because 10,000 subaddresses will be precomputed for each of the 50 accounts. Therefore, expect the operation to start the wallet to take a few minutes.


Syncing several wallets in the same ledger with local node. (start again switching)

Your image shows the blockchain is fully synced and up-to-date but the wallet is scanning the blockchain to find any transactions destined for your wallet.

If your wallet is saved on the same external drive, and has been scanned, opening the same wallet on another machine will not try to scan from block 1, it will scan from the last scanned height.


What cryptography primitives/concepts, other than the basic ones, does Monero use?

Pedersen Commitments and Range Proofs

See https://people.xiph.org/~greg/confidential_values.txt


You don't have your wallet ID/payment address after -u .. if that wasn't redacted for this post then that may be your issue.  You can have a look at my pool which has a configuration utility that might help:

Gulf Coast Mining
https://mon.gulfcoastmining.com


I want my money to be private and to use it as needed each month to pay bills etc

I like your intentions.  But that's not really going to happen, for a long time, if ever.
As with all cryptocurrencies, the vendor, shop, utility, landlord, etc need to accept it.
There are ways to convert the cryptocurrencies to your local money, and/or to send that to a payee.  But they will give a bad exchange rate and add fees on top of that.

In a nutshell cryptocurrencies are LONG way away from being ready for everyday use.  It's the fault of the vendors not accepting it, and mostly because of the volatility of the value of the cryptocurrencies (which is why so few do accept it).


What determines who gets the block reward

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.


It probably means you're connected via HTTP, and not HTTPS. Theoretically, it means a malicious ISP or router in the middle of your path to the mining pool could replace your monero address with their own, or change your shares to invalid ones, etc. In practice, the risk is extremely low.


Can the Monero daemon bind to a UNIX socket?

No. Currently only TCP/IP sockets are implemented.


Multiple outputs & expected reward from coinbase transaction

Why does Monero split up the rewards in this instance?

This answer requires a bit of history first to be sufficiently explanatory.

In the first years of Monero's existence amounts were not encrypted yet. In addition, output amounts were "split" into denominations to the power of 10 to ensure they could be used as decoy outputs (i.e. ring partners). Thus, for instance, an amount of 101.1234 was split into denominations of 100, 1, 0.1, 0.02, 0.003, and 0.0004. To reiterate, this was required in order for ring signatures to work properly. That is, if the amount of 101.1234 was not split into denominations, it would be fairly unlikely that one could find two other (decoy) outputs of 101.1234 to create a ring with. By contrast, plenty of decoy outputs (ring partners) can be found for an output amount of 100. In September 2016, RingCT, which, in a nutshell, allows one to encrypt output amounts, was activated on testnet. A few months later, in the beginning of 2017, RingCT was activated on mainnet.

Now, as you can see from here, the hard fork which activated RingCT on testnet was triggered by block 80xxxx. Intuitively, all blocks before the fork block contain transactions with non-RingCT outputs, which are unencrypted and split into denominations to the power of 10. It logically follows that, if you create a private testnet (which starts from block 0), the blocks on your private testnet contain transactions with non-RingCT outputs until RingCT activation is triggered. Basically, you'd need to mine ~800k blocks before RingCT gets activated. You can, however, tweak the fork heights in the code, recompile, and set up a new private testnet.

  Also, a follow-up question: I'm having a bit of trouble calculating expected rewards from the coinbase transaction.

The slight discrepancy between the expected reward and actual reward is, if I recall correctly, caused by the penalty (i.e. miners incur a penalty if they mine a block bigger than the minimum block size limit of 300 kB) being deferred to future miners.


Downloaded monero v12 GUI How do I verify the hash of the download on Ubuntu command line?

Do it against the downloaded file.

I used the command:

sha256sum <my_file_here>

It will then spit out a hash string. Copy this string and then do a find on that same webpage to see if it matches.

It was pretty easy. Took less than 30 seconds to figure out.


Did you follow the instructions noted in the answer to this question?

How do I use a computer with a wallet to access a headless node at my home?

I notice you mentioned --daemon-address as opposed to --daemon-host.  I'm not sure if both those addresses work and are interchangeable.


How CryptoNote protocol protects Monero users?

There are two main protections from Cryptonote: Untraceability ( provided by Ring Signatures ) and Unlinkability ( provided by Stealth addresses ).

Detailed information in the Cryptonote website.

Monero went further following researchers recommendation and added a forced minimum of 2 mixing for a transaction ( to be bumped to 4 ) and is going to implement Confidential Transactions in the near future further obfuscating the already hard to guess exact amount of coins in a determined transaction.


I happened to have read Greg Maxwell's paper recently, so here I try to lay down my interpretation in a bit abstract manner:

Before talking about the Borromean scheme, let us recapitulate the current ring signature scheme described in MRL-0005.
The signature data looks like:

R = (M, {P_1,...,P_n}, c_1, {r_1,...,r_n})

where M is some message's hash, each P_i is a pubkey in the ring, and c_1 and r_i are scalars (the key image part is omitted here for brevity).
Any participant in the network verifies this signature as follows:

L_1 = c_1 P + r_1 G
c_2 = H(M, L_1)               // H(...) is a hash function
...
L_i = c_i P + r_i G
c_{i+1} = H(M, L_i)
...
L_n = c_n P + r_n G

Finally, the signature is confirmed as valid if c_1 = H(M, L_n).
I skip explaining how such a signature can be generated only by a true signer knowing the secret key x of one of the pubkeys P_s = xG for some secret index 1<=s<=n.

A transaction generally has multiple inputs, say m inputs, so you create a ring signature for each input:

R^j = (M, {P_1^j,...,P_n^j}, c_1^j, {r_1^j,...,r_n^j})

for j=1,...,m.
Note that the signature contains m*(n+1) scalars of c's and r's.
Note also that such a concatenation of multiple ring signatures is needed for RingCT when proving that a given committed amount is within a certain range (called range proof).

The goal of the Borromean ring signature scheme is to reduce the signature size by making all c_1^j's identical:

c_1^1 = c_1^2 = ... = c_1^m
      = c_1

so that the number of scalars stored in the signature becomes m*n+1.

To achieve this goal, the scheme modifies the verification rule a little bit.
As before, the verifier computes for each j=1,...,m:

c_1 -> L_1^j -> c_2^j -> ... -> c_n^j -> L_n^j

and the signature is confirmed valid if the following holds:

c_1 = H(M, L_n^1, ..., L_n^m)

The signature generation can be implemented by adding some small modifications to the original scheme (I believe).


Why is it necessary to have such long addresses?

First note that in Monero there are two sets of keypairs, namely the private view key (a) (which is the private spend key hashed with Keccak-256 and subsequently reduced modulo l) with the corresponding public view key (aG (G = the base point) = A) and the private spend key (b) with the corresponding public spend key (bG (G = the base point) = B). The public address is then created as follows:

  The pair of public keys are prepended with one network byte (the number 18, 0x12, for Monero). It looks like this: (network byte) + (32-byte public spend key) + (32-byte public view key).
  These 65 bytes are hashed with Keccak-256.
  The first four bytes of the hash from 2. are appended to 1., creating a 69-byte Public Address.
  As a last step, this 69-byte string is converted to Base58. However, it's not done all at once like a Bitcoin address, but rather in 8-byte blocks. This gives us eight full-sized blocks and one 5-byte block. Eight bytes converts to 11 or less Base58 characters; if a particular block converts to <11 characters, the conversion pads it with "1"s (1 is 0 in Base58). Likewise, the final 5-byte block can convert to 7 or less Base58 digits; the conversion will ensure the result is 7 digits. Due to the conditional padding, the 69-byte string will always convert to 95 Base58 characters (8 * 11 + 7).
  This 95-character result is the (obscenely long) Cryptonote Public Address!
  If you're creating an integrated address, simply append the 64-bit payment ID to step 1 and continue; everything else is the same except for the lengths (77 bytes total, 106 Base58 digits) and the prepended byte (19, 0x13).

It logically follows that the addition of B to the creation of a one-time public address (stealth address) is required in order for a user to be able to optionally disclose his public address + private view key. This allows a third-party (e.g. an auditor) to view all incoming transactions to the user's wallet without knowledge of their private spend key.

Lastly, a note from luigi1111 (a Monero core-team member) on single-key / non-dual key stealth addresses:

  It is possible to do a non-dual-key stealth addressing scheme, but you must make one of two trade-offs. You can either: (1). use the concept in the whitepaper called a truncated address, which means the view key pair is publicly known and all incoming transactions can be linked (a = Hs(B)); or (2). forego a view key pair entirely, which means scanning requires spending ability (P = Hs(rB)G + B).

Sources:

https://xmr.llcoins.net/addresstests.html
https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-introduction
https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-part-2-stealth-addresses


What is the difference between a "cold storage" wallet and a "hot" wallet?

Cold storages are wallets created offline and maintained offline until you want to make a definitive move with the coins, they are kept safe from hacks or unauthorized access from the Internet since they should never reside on a computer that is or will be connected to the Internet (perfect method for storing coins).

Hot wallets are easily accessible with the Internet like mymonero.com since the seeds are created online you can't ever be 100% sure they can't be compromised.


The GUI just offers an alternative way of trading on Poloniex. There are no additional features.

The password files are stores in plaintext in the same directory of the executable.

The code has not been audited by any core member and is not affiliated with the Monero project in any direct way.


Is a mnemonic for view only wallet possible?

Monero's existing mnemonic scheme simply translates back and forth between a 32 byte scalar and a 25-word checksummed mnemonic.

At the moment, that's used to store the 32 byte seed. There is no reason it can't be used to produce a mnemonic from the 32 byte private view key.

However, you need to know both your private view key and your public spend key in order to create a view-only wallet.

Therefore you'd have to store both the mnemonic and your public spend key (or your wallet address, which contains your public spend key). If stored separately, your public spend key could be represented as base-58, hex, or as a second 25-word mnemonic.


Outputs are where amounts of Monero are "stored".

The blockchain consists of a set of transactions. Each transaction spends existing outputs and creates new outputs (typically one new output for the recipient and another new output to send change back to yourself). Each output has an amount of Monero associated with it. The output also has a unique public key, and only the recipient is able to determine the private key that is required to spend it.

In the blockchain explorer, it's marked as "?" because the amounts of Monero outputs (since the introduction of RingCT in January 2017) are encrypted and opaque to everyone except the sender and recipient. Pre-RingCT outputs had unencrypted output amounts, e.g. https://xmrchain.net/block/45eca0b6c1845c073d365fedb78ab14e4313d6392a2fde217a46882875428463


Confused about the monero hardforks that spawned xmc monero classic and xmo monero original?

As far as I know, they're all the same. There's no actual maintained fork, just the ASICs which didn't switch to another coin continuing mining on their own chain. Three (four I think ?) different people tried to "put a flag" on that in case it amounted to anything, but as far as I know, none of the Monero devs have any interest in maintaining an old version of Monero.

As far as I know, none of those repos merged the key reuse mitigations from Monero, so that tells you a lot about whether anyone is actually spending any time on those forks.


Is the new data being stored there secured the same way as wallet
  cache data was stored before?

Yes, all the stored data is encrypted using the wallet password. For details on the encryption scheme, see here.

  Besides the GUI address book example, what additional data will now be
  stored in the wallet cache?

Anything you can think of that needs secure & private persistent storage on the user end. For example (not necessarily newly added): record of outputs belonging to the wallet, record of signed key images for each output and their spent status, custom transaction notes, transaction keys, address book records, etc.

See also: What data do the wallet files contain?


If your DNS provider does not support DNSSEC, then your wallet cannot be sure that there is not a man-in-the-middle attack, DNS poisoning or other type of attack giving your wallet an incorrect Monero address.

The only way to resolve this is to move to an alternate DNS nameserver provider that supports DNSSEC.


Track all rewards issued to a Monero mining pool

Is there a way to track blocks generated by a pool?

The pool implementation you are using includes an API endpoint which reports blocks mined. It's registered at /api/pool/blocks by default. E.g. https://supportxmr.com/api/pool/blocks

  What are the possible explanations of such behavior?

At 15 kh/s, finding a block in 48 hours at current network hashrate is just good luck. With 50 kh/s on current network hashrate (~300 mh/s) you're expecting to mine a block in 8 days. Ref: 300000000/50000*120/(24*60*60). Note this is no guarantee, luck plays a part still, so 10 days should not be unexpected.


cryptonote-universal-pool Stratum authentication failed

The first error (failure to parse blocks) is pretty likely to be due to the lack of ringct support in the C++ lib part of the pool code. You seem to have fixed it by using another version.

The second error is most likely due to an address being passed which doesn't match the expected format. This can be due to two reasons: either the address is really wrong (Monero addresses are 95 characters long, and start with a 4), or the pool's address being wrongly set (the pool will compare the first character of the miner address with the pool address' first character and expect the same).

The address validation code is at the end of lib/utils.js (isValidAddress). You can add traces to see which part of it fails.


Is there a service for recurring buying of Monero every 2 weeks?

There are two possibilities:

You find an exchange where you can set up buying an order every week. Not really sure but i think that at Kraken this could work.
You create an account on an exchange, get API keys from them and execute the API call to create a buy order every week. If you really want to automate this, you could set up a python script (or any other programming language) on Heroku (which you don't have to pay) and let that execute periodically.


Was there evidence of any ASICS after the new POW upgrade in october 2018?

No hard evidence I'm aware of. The changes this time were made to thwart any ASICs that may have been under development since the last fork. By changing the algorithm every 6 months, this severely impacts the time to develop and ship any new ASICs to market, making it an unprofitable venture. Until we come up with an alternative algorithm (such as the discussed RandomJS), it looks like we'll be changing the algorithm every 6 months to retain the egalitarian nature of mining Monero.


What is the technical definition of "dust" that is allowed to be sent with a mixin of 0?

Dust is not a very well defined term in general. However, in the context of your question ("allowed to be sent with a mixin of 0"), this is about which outputs have enough other outputs of the same amount on the blockchain. If there are enough such outputs, then the output is not considered dust for the purposes of mixin 0 rules. If there are not enough, then it is. "Enough" here is defined as two within the current monero rules: the minimum mixin is 2 (except when dealing with that dust), so you need two other outputs with the same amount as the output you are considering.

Dust used to be created all the time, but is now less so. The main offender was the mining pool software, which would send small amounts at every block, with "complex" amounts such as 0.000026483653. Unlikely to find a lot of outputs of that particular amount on the blockchain. The block reward was also dusty till the first hard fork. Now, dust creation is much more rare, for the following reasons:

the mining pool software sends quantized amounts when a threshold is reached
the block reward is quantized by default
amounts are split by denominations down to the smallest amount

Moreover, once RingCT is included in monero, this problem will disappear altogether since amounts will be encrypted, and all/many new inputs will technically have "weird" amouts, but they will be mixable with any other, regardless of amounts.

The only thing I'd suggest now is, if you are mining, use a pool with a higher threshold. While they won't send dust anymore, you want to avoid small outputs since sending them takes up more in fees.


How high is Multi-Sig on the list of development priorities?

Core contributor moneromooo recently got funding for 450 hours of his work on Monero. However, there is no exact estimation:

  As before, I will not commit to any particular piece of work, but will
  work on whatever needs doing to further Monero. Currently, my target
  is rct verification performance, and then there is multisig, though I
  will need help for someone who understands the crypto well to guide
  me.

Browsing his GitHub commits you can see, he is already working on RingCT Performance, but also on several other things, so I think Fluffypony's estimation of 12 to 18 for multisig to be rolled out is quite real.


Can monerod run stable on a Raspberry Pi 3 with microSD as storage?

After reading some of the instructions over at http://pinode.co.uk, I think I found the culprit. Turned out Ubuntu MATE for Raspberry Pi doesn't install with swap space out-of-the-box. I wasn't aware of this.

I have now added a 1024 MB linux-swap partition on my microSD card with GParted. I won't be very fast, but at least it's there.

Therefore, I also reduced the "swappiness" from the default 60 down to 0, which should reduce the tendency to use swap, unless absolutely required:

$ cat /proc/sys/vm/swappiness
60
$ sudo sysctl vm.swappiness=0
$ cat /proc/sys/vm/swappiness
0

To make the change permanent, edit /etc/sysctl.conf as root:

sudo vi /etc/sysctl.conf

And add the following line:

vm.swappiness = 0

Output of the free command when starting up monerod shows free memory takes a nose dive from ± 710 KB:

              total        used        free      shared  buff/cache   available
Mem:         949580       40424      710540        6760      198616      841848
Swap:       1048572           0     1048572

to roughly ± 35 KB

              total        used        free      shared  buff/cache   available
Mem:         949580       60428       36532        6760      852620      818640
Swap:       1048572           0     1048572

After monerod was fully synchronized again, it seems my Raspberry Pi 3 system is using just a little bit of swap space:

              total        used        free      shared  buff/cache   available
Mem:         949580      133652       33256        3768      782672      748508
Swap:       1048572        2988     1045584

That's probably why it system crashed previously without that swap ability.

I don't know exactly how to configure these newer Linux systems in "runlevel 3", if that still exists, to even consume less RAM. As a workaround, I have stopped some unnecessary services:

for SERVICE in x11vnc lightdm bluetooth cups
do
    sudo systemctl stop ${SERVICE}.service
done

If anyone has a better suggestion for that, feel free to comment or edit.


How can I give a different address to a sender for each transaction in an easy way?

Creating a new wallet is the only way, yes (assuming you want to give different addresses for the purposes of preventing correlation). An integrated address will allow trivial correlation, as its intent is different.

There is no RPC to create a new wallet. New wallets have to be created with a simplewallet command line (ie, simplewallet --generate-new-wallet).

Newer versions of Monero (ie, 0.10.0) are very much faster in creating new wallets, however, since they know they do not have to scan the blockchain up to the point of creation.

When the GUI is out, it will include a way to create a new wallet, though I do not know how easy/quick the process will be.


An orphaned block refers to a block that was originally accepted by the network (a part of the network, anyway) as a valid block with a valid hash and valid transactions.

Due to the physical constraints of computers and the internet, a block that is solved by a miner and contributed to the network is not instantly propagated to the rest of the network.  At minimum, it could take several seconds for data to transfer around the world.  Due to this potential time lag, two miners may effectively simultaneously solve the same block.  There will be nodes geographically closer to miner A than miner B, and vice versa, so the network will be temporarily split into two very similar but different chains, as the nodes broadcast to one another what they believe to be the most recently mined block.

Eventually, one of the two chains will demonstrably have a greater proof-of-work than the other, and the nodes on the other chain will update/reorganize their blockchain records/database accordingly and begin to only accept transactions on the chain with the greater proof-of-work.

Orphaned blocks are the legitimate blocks from the chain that lost out to the chain with a greater proof-of-work.

If a transaction was reflected on the 'B' chain, in an orphaned block, but not the 'A' chain, then once the network subsequently is fully on the 'A' chain, that transaction from the B chain will revert to being unspent (or will have been subsequently mined on the 'A' chain).  Spent outputs do not get lost on a 'B' chain, since the history of any 'B' chain spends is effectively erased once the network accepts the 'A' chain.

(Note, I used 'A' and 'B' for example purposes only, with 'A' as the chain that ends up being the "true" chain, as demonstrated by its greater proof-of-work.)


The base transaction fee is 0.002 monero per kB. However, change below 0.01 is not retrieved, but kept in the fee, to avoid generating unreasonably small outputs spamming the blockchain, so you may get up to 0.01 extra as the fee in those cases. This threshold is going to decrease soon too (see https://github.com/monero-project/monero/issues/1199).

In your case, both the fees are within 0.01 of 0.002/kB.