Base58 prefix, network id and wallet address prefix

NETWORK_ID is a 16 byte identifier that allows Monero nodes to identify themselves to other nodes, in order to prevent different Monero networks (e.g. mainnet vs stagenet) from accidentally talking to each other. It has nothing directly to do with wallet addresses, although there are different wallet address prefixes designed for use on different networks.

The web site you've linked to uses the the separate term "Network Byte", and shows the hex representations of what src/cryptonote_config.h defines using decimal numbers instead.

E.g. a network byte of 0x12 in hex is the number 18 in decimal, which is why the web site you've linked defaults to the value 12 and the cryptonote_config.h defines the value as CRYPTONOTE_PUBLIC_ADDRESS_BASE58_PREFIX = 18;


How can I get outgoing connections with pfSense as my router?

If uPNP won't cooperate, you can create a port forwarding rule (in Firewall > NAT > Port Forward) for the WAN interface that directs a destination of port 18080 to port 18080 of the internal IP of your node.  This will have the effect of also creating a firewall rule on the WAN interface that allows the traffic arriving at port 18080 to pass through to the internal host/IP of the node.


transaction verification failed on monero-blockchain-import

This is a known bug, thought fixed in master, and restarting the import will continue just fine. If it does not, then it's time to report the bug to https://github.com/monero-project/monero


Try the forknote generator, you can find it at this address: https://github.com/forknote/monero-generator.


I just downloaded the Monerujo wallet and trying to figure it out. Is there an instructions page?

Yes. Read the README, FAQ. As this app is still in APK form and not released to the app store, use caution and read the disclaimer:

You may lose all your Moneroj if you use this App. Be cautious when spending on the mainnet.

For maximum privacy, connect to a daemon that you run yourself. You can also choose to use a remote node such as those listed by MoneroWorld:

node.moneroworld.com at port 18089
node.xmrbackb.one at port 18081
node.xmr.be at port 18081

In order to fit the format required by the Monerujo app use (example from above list): node.moneroworld.com:18089


How to communicate programmatically with the Monero CLI wallet using php?

In order to communicate via php with a Monero wallet you have to run Monero Wallet RPC.

monero-wallet-rpc --rpc-bind-port 18082 --disable-rpc-login --wallet-file /path/walletfile

If you are using a remote node, simply add to command the --daemon-host node.moneroworld.com:18089 flag.

That command will build a JSON API avaiable on the 18082 port. You can check if that works by typing http://127.0.0.1:18082/json_rpc in your browser.

Let's use the Monero PHP library in order to call some functions in your wallet.

<?php
// Example of Monero RPC Connection
require_once('src/jsonRPCClient.php');
require_once('src/Monero_Payments.php');

// Edit it with your ip and your port of Monero RPC
$monero_rpc = new Monero_Payments('127.0.0.1','18082');

In this way, you created the instance of Monero PHP library.
All the calls are in details on this page.

For each call of Monero Wallet RPC, there is one function in the Monero PHP library.

Example:

Calling getaddress function

// Get address from Monero RPC
$address = $monero_rpc->getaddress();
// Print the RPC Response
$monero_rpc->print($address);

The RPC response will be printed as JSON. For getaddress call, it's

{
    "id": 0,
    "jsonrpc": "2.0",
    "result": {
        "address": "42uMGYwvLuUGJzqdWZvr47CGCBz1qNNExZeegcjLPMbaFkBb3XGg6Y1bUwaMbovzGWDXtaASxSBYtaiBB4wuDmrAMCygexH",
        "addresses": [
            {
                "address": "42uMGYwvLuUGJzqdWZvr47CGCBz1qNNExZeegcjLPMbaFkBb3XGg6Y1bUwaMbovzGWDXtaASxSBYtaiBB4wuDmrAMCygexH",
                "address_index": 0,
                "label": "Primary account",
                "used": false
            },
            {
                "address": "82qL8g5h9jvQGroSuDxZASAERKZPf7DQC8784YGmUPrdRp4TTo4KdruDfWUZkmWwWtCzP6buA9yYaWRmXXH7JkAPFXDtwuQ",
                "address_index": 1,
                "label": "",
                "used": false
            }
        ]
    }
}

If you don't understand PHP library, you can try to call getaddress by curl.

$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getaddress"}' -H 'Content-Type: application/json'


What happens to pool server if redis data is lost?

The Redis database constains all the memory of miners' work and balances, found blocks, etc. So losing it would be a bad thing, though not extra bad.

Assuming everything got wiped at once, it'd be functionally identical to starting a new pool from scratch, except you already have miners connected and mining.

This means mainly three things:

the work history for the current block will be wiped, and only work submitted between the wipeout time and the next block found will be used (same as what happens when a block is found and work history resets)
miners' current balances get lost.
info on who to pay for any blocks found that are not yet unlocked is lost

Now, if you have a recent backup, the first one's probably not a big deal (unless you find a block just after that event, where submitted shares don't have time to re-approximate miners' real hash rates), and the second one's a bit annoying, but these are small amounts, typically below 0.2 monero. The third one is pretty bad though, as miners lose (their part of) the entire block.

Now, if the wipeout is not total, then other things can happen. For instance, if the wallet paid something, but this is not recorded, it will be paid again. This time, it's an error to the miners' benefit.


It's a placeholder, since they're unused (or, at least, I am not aware of any mining software which uses that password), even though they're part of the JSON communication between miner and pool. You can put whatever you like, x or otherwise.


If you don't want to have the target Aeon wallet open all the time (for security reasons, or you prefer to start mining at system startup non-interactively), you can also start solo CPU mining using the daemon itself. Example syntax (replace the placeholders with actual values obviously):

aeond --start-mining <target-aeon-wallet-address> --mining-threads <number-of-CPU-threads>

Finding the number of available CPU threads:

On macOS, you can show the number of available threads with sysctl -n hw.ncpu.
On Windows, you can see the number of available threads with the msinfo32.exe utility. In there, go to the "Processors" line, and note the number of "Logical Processors".

Once the daemon is active, you can enable and disable displaying the hash-rate with the show_hr and hide_hr commands. This is optional, mining still works if you don't show the hash rate.

When you're lucky to mine a block, you'll see something like this in the daemon logging:

2017-Jan-20 12:58:36.932824 [miner 0]Found block for difficulty: 224668625


How will the range proof size reduction be accomplished?

This is a bit speculative, as I do not know exactly what is planned.

1024+ bytes is quite a reduction, so my guess is that the range will be reduced. Currently the spender must prove the output is in the range [0, 2^64), and if the upper limit were reduced it would reduce the size of the signature. This would not alter security, but would decrease the amount that could be sent in a single output. Amounts larger than the upper range could still be sent to a single address in one transaction, but would require multiple outputs to do so.


RPC throwing "method not found" error when I'm trying to call from curl

For wallet operations over RPC, you need to have the monero-wallet-rpc running. An example command to run the wallet RPC server:

monero-wallet-rpc --wallet-file /some/wallet --rpc-bind-port 12345 \
    --prompt-for-password

(replacing the wallet file path and port number above to your choosing).

Other options can be specified also, seen via running monero-wallet-rpc --help.

All of the wallet RPC methods are documented here and daemon RPC methods here.


Error: Couldn't connect to daemon: 127.0.0.1:18081


Monero mining uses the AES-NI instructions from the Intel processor, as well as memory, and raw processor speed. Therefore, adding VMs will just add unnecessary overhead. The best way to mine is to run on the physical machine, with a number of threads that's optimal (determined by both the number of AES-NI capable cores and the amount of cache, as each mining thread needs 2 MB of fast memory).

Now, if your virtualization system can add additional hardware, then it might be worth it for convenience alone, as the overhead might not be too significant if the VM layer can offer access to the underlying AES-NI hardware.


It seems that blockchain code written in C++ is prone to obscure but serious bugs

Well, anything coded in anything can be "prone to obscure but serious bugs", it's not the language used that's at fault.

  what tools for improving code reliability - such as static code analysis or undefined behavior sanitisation - are (or should be) incorporated into the development process

Actually, a number of tools are already being used. Valgrind, ASAN and Coverity for example. These are just some tools, this is aside from the, arguably more important, many developers that review and test others contributions also. Code is not just rushed into releases.

In addition to this, for major newer cryptography, such as the recent Bulletproofs code, the community funded two independent audits before the code was included in a release.


There's a bug present in the Trezor code that causes the GUI to crash occasionally whilst trying to send. This will be fixed in the upcoming release. See:
https://github.com/monero-project/monero/pull/7330
In the meantime, please try sending a smaller amount of the balance.


As a miner finds shares, each share's difficulty accumulates on that miner's "account". When the pool finds a block, all miners' accumulated shares are reset to 0, and the cycle restarts till the pool finds a block again.

Upon finding a block, the block reward (minus the pool fee) is distributed to miners in proportion to their accumulated share difficulties.

So a miner finding two shares at difficulties 2000 and a miner finding one share at difficulty 4000 will be allocated the same percentage of the block reward. Finding a share at difficulty X happens twice as often as finding a share at difficulty 2X, on average.


Where can I exchange GBP to Monero (XMR)?

You could try localmonero: https://localmonero.co

But there aren't many GBP sellers there with very high sell records or reputations, so you may be better off buying bitcoin first, as suggested already, then send those to an exchange (such as Poloniex, Kraken, Bitfinex, or one of many others) and then exchange them for Monero there.


How much of the Monero code has been changed since the Bytecoin fork?

This is of course a coarse method, but we can do the following:

Get git to work out who authored a given line for all the lines in src:

$ find src/ -name \*.cpp -o -name \*.c -o -name \*.inl -o -name \*.h | while read f; do git blame -CC "$f";done > full-files

Then check how many of those lines were authored by the pre-Monero authors (anjuarez for the Cryptonote team, and thankful_for_today for the original fork):

$ grep -iE juarez\|thankful full-files | wc -l
22332

And do the same for those lines not authored by them:

$ grep -ivE juarez\|thankful full-files | wc -l
83706

So most of the code was rewritten or modified.

Note that git sees a modification of the line as rewritten, so this may be an overestimate.

You can redo the selection to include other authors, in case there's a significant amount of code written (as reported by git) by another person than amjuarez.

If we include the epee support library:

$ find contrib/epee/ src/ -name \*.cpp -o -name \*.c -o -name \*.inl -o -name \*.h | while read f; do git blame -CC "$f";done > full-files

$ grep -iE juarez\|thankful full-files | wc -l
44115

$ grep -ivE juarez\|thankful full-files | wc -l
87377


What is the importance of 'save' command in monerod?

The blockchain is indeed automatically saved.
This command ask to the underlying OS to write any cache to the disk immediately, when the OS has the ability to store data in cache before writing.
It's a security step you might need in extreme cases (like power loss and short UPS period).


I2P's threat model consists of :

Brute force attacks

  A brute force attack can be mounted by a global passive or active adversary, watching all the messages pass between all of the nodes and attempting to correlate which message follows which path

Timing attacks

  I2P's messages are unidirectional and do not necessarily imply that a reply will be sent. However, applications on top of I2P will most likely have recognizable patterns within the frequency of their messages - for instance, an HTTP request will be a small message with a large sequence of reply messages containing the HTTP response. Using this data as well as a broad view of the network topology, an attacker may be able to disqualify some links as being too slow to have passed the message along

Intersection attacks

  Periodically make contact with the target and keep track of what peers are on the network. Over time, as node churn occurs the attacker will gain significant information about the target by simply intersecting the sets of peers that are online when a message successfully goes throug

Denial of service attacks

Greedy user attack

  people trying to consume significantly more resources than they are willing to contribute

Starvation attack

  harm the network by creating a significant number of peers in the network who [...] then decide not to provide any resources to the network

Flooding attack

  standard IP layer flooding

CPU load attack

  request that a peer perform some cryptographically expensive operation

Floodfill DOS attack

  becoming a floodfill router [...] and provide bad or no response to lookups, and it may also interfere with inter-floodfill communication

Tagging attacks

  modifying a message so that it can later be identified further along the path

Partitioning attacks

  finding ways to segregate (technically or analytically) the peers in a network

Predecessor attacks

  passively gathering statistics in an attempt to see what peers are 'close' to the destination

Harvesting attacks

  compiling a list of users running I2P

Identification Through Traffic Analysis

  By inspecting the traffic into and out of a router, a malicious ISP or state-level firewall could identify that a computer is running I2P

Sybil attacks

  category of attacks where the adversary creates arbitrarily large numbers of colluding nodes and uses the increased numbers to help mounting other attacks

Buddy Exhaustion attacks

  By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure that a tunnel is formed wholly from its set of colluding routers

Cryptographic attacks

  I2P was not designed with easy mechanisms to lengthen keys or change shared secret values while maintaining backward compatibility

Floodfill Anonymity attacks

  floodfill routers are uniquely positioned to learn about network participants

Other Network Database attacks

  attempt to harm the network by creating one or more floodfill routers and crafting them to offer bad, slow, or no response

Central Resource Attacks

  centralized resources in the development and operation of the I2P network,

Development attacks

  go after its development team by either introducing legal hurdles on anyone contributing to the development of the software, or by using whatever means are available to get the developers to subvert the software

Implementation attacks (bugs)

  errors in the design or implementation

Source here (also describe defenses against these threats)


Transaction to sub-address missing in GUI wallet

Let's say you own a 4 XMR output that is stored in your wallet. When you send 3 XMR to Bob, you will spend that 4 XMR output, and you are creating a new 3 XMR output for Bob and a new 1 XMR change output for yourself.

This change output is not labelled as "change" in the transaction that is created. It's just an output that the wallet can see originated from you. This change does not get displayed as an incoming transaction of 1 XMR, because that would be confusing.

When you send funds from your wallet to a subaddress in the same wallet, what you're effectively doing is creating two change outputs for yourself. If you send 3 XMR to yourself, what you are doing is spending a 4 XMR output to create a 3 XMR output for yourself and a 1 XMR output for yourself. But since one of those outputs doesn't get labelled as "change" in the transaction structure, they both just look like change. So the wallet has to treat this as a 0 XMR transaction, because it can't determine anything other than that no funds were sent to a third party.


What PoW hashing algorithms did Monero historically use?

Monero's genesis block dates back from April 2014. The first PoW change was in 2018.

The full history is:

| block   | date       | PoW algorithm
|---------|------------|--------------
| 0       | 2014-04-18 | Cryptonight (retroactively CNv0)
| 1546000 | 2018-04-06 | Cryptonight variant 1 (CNv1)
| 1685555 | 2018-10-18 | Cryptonight variant 2 (CNv2)
| 1788000 | 2019-03-09 | Cryptonight variant 4 (CNv4)
| 1978433 | 2019-11-30 | RandomX

Monero switched to RandomX in November 2019, a new PoW algorithm not based on Cryptonight, which is based on the premise of random code execution.


My GUI feels buggy / freezes all the time

First and foremost, it's important to make sure you're running the latest version (v0.11.1.0 at the time of writing). You can check the version # on the Settings page of the GUI (under Debug info). If you're not running v0.11.1.0, please upgrade first:

How do I upgrade my software to v0.11.1.0?

This is typically caused by monerod using all your CPU during the initial sync (you can also apply this guide if it still feels buggy after you've completed the initial sync). monerod requires CPU because it needs to verify blocks. You can limit monerod's CPU usage as follows.

Go to the Settings page of the GUI.
Look for the daemon startup flags box.
Add this line -> --max-concurrency 1
Exit the GUI and make sure to stop the daemon as well.
Restart the GUI + daemon.

Step 4 & 5 are needed for the flag from step 3 to take effect. Note that --max-concurrency 1 will limit your CPU usage to 1 thread.

In addition, if you're syncing the blockchain to an HDD, it'd probably be best to lower the size of the batch of blocks (block-sync-size) as well. This is done as follows.

Again go to the Settings page of the GUI and look for the daemon startup flags box.
Add this line after the --max-concurrency 1 line and make sure there's a space between 1 and - -> --block-sync-size 10
Thus, the "full" line in the daemon startup flags box becomes -> --max-concurrency 1 --block-sync-size 10
Exit the GUI and make sure to stop the daemon as well.
Restart the GUI + daemon.

Step 4 & 5 are again needed for the flag from step 2 to take effect. Note that --block-sync-size 10 will reduce the batch of blocks it syncs to 10 (the default is 20) at a time.

Now, monerod also takes a lot of bandwidth during the initial sync. If you're unable to browse or use any applications that require internet connection, you can limit monerod's bandwidth as follows:

Again go to the Settings page of the GUI and look for the daemon startup flags box.
Add this line after the --block-sync-size 10 line and make sure there's a space between 0 and - -> --limit-rate 500
Thus, the "full" line in the daemon startup flags box becomes -> --max-concurrency 1 --block-sync-size 10 --limit-rate 500
Exit the GUI and make sure to stop the daemon as well.
Restart the GUI + daemon.

Step 4 & 5 are again needed for the flag from step 2 to take effect. Note that --limit-rate 500 will limit the bandwidth to 500 kB/s.

Note that you can tweak the parameters / flags yourself by adjusting the value.

Lastly, the GUI itself also uses some CPU and memory. You can reduce this by running monerod separately from the GUI during the initial sync. This is done as follows:

[1] Exit the GUI and make sure to stop the daemon as well.

[2] Browse to the directory monerod is located (on Windows & Linux it's the same directory as monero-wallet-gui, whereas on Mac OS X it's -> ~/Applications/monero-wallet-gui.app/Contents/MacOS).

[3a] On Windows, open a new command prompt from the same directory as monerod.exe. This is done by first making sure your cursor isn't located on any of the files and subsequently doing SHIFT + right click. It will give you an option to "Open command window here". If you're using Windows 10, it'll, most likely, give you an option to open the Powershell.

[3b] On Linux and Mac OS X, open a new terminal from the same directory as monerod

[4a] On Windows, type the following command in the command prompt:

monerod.exe --max-concurrency 1 --block-sync-size 10 --limit-rate 500

If that doesn't work in the Powershell, type:

.\monerod.exe --max-concurrency 1 --block-sync-size 10 --limit-rate 500

If that doesn't work either in the Powershell, type:

./monerod.exe --max-concurrency 1 --block-sync-size 10 --limit-rate 500

[4b] On Linux and Mac OS X, type the following command in the terminal:

./monerod --max-concurrency 1 --block-sync-size 10 --limit-rate 500

[5] If you were using a non-default directory for the blockchain, you have to add the --data-dir flag too if you start monerod separately. If you already have monerod running, type exit first to gracefully stop the daemon. This is done as follows:

On Windows, type the following command in the command prompt:

monerod.exe --max-concurrency 1 --block-sync-size 10 --limit-rate 500 --data-dir path\to\your\blockchain

If that doesn't work in the Powershell, type:

.\monerod.exe --max-concurrency 1 --block-sync-size 10 --limit-rate 500 --data-dir path\to\your\blockchain

If that doesn't work either in the Powershell, type:

./monerod.exe --max-concurrency 1 --block-sync-size 10 --limit-rate 500 --data-dir path\to\your\blockchain

On Linux and Mac OS X, type the following command in the terminal:

./monerod --max-concurrency 1 --block-sync-size 10 --limit-rate 500 --data-dir path/to/your/blockchain

[6] Note that, if you're running monerod separately, you have to apply the flags every time you start monerod. Thus, on Windows, probably most convenient to create a shortcut, go to properties, and add the flags after the Target. On Linux and Mac OS X, it's probably most convenient to create a little script.

[7] As a general piece of advice, if you need to shut down your PC, first shut down monerod gracefully by typing exit. Otherwise, you might corrupt the blockchain again and you'd have to start all over again.

[8] You can use status in monerod to verify whether it's fully synced. It's fully synced if your height matches the height displayed on a block explorer like, for instance, XMRchain.net.

[9] Once it's fully synced, open monero-wallet-gui. It'll automatically connect to the monerod that is already running. Note, however, that monero-wallet-gui still has to refresh the wallet, for which it currently uses the same status bar.


What is necessary to implement monero into Bitcoin trezor?

From what I know, NoodleDoodle is still currently working on improving the firmware to be able to work with RingCT transactions.  It is still "technically" in a testing phase though; and you can see progress being made.  You can test out the firmware by downloading from either here on the official forum, or getting it from here on github.

As for the first part of your question, I believe you meant to ask what is the current status with Monero's integration into the official trezor firmware.  As for that, that's still up in the air.  There are no more links to the actual conversation that took place (I think?); but from how I understood it, there was a disagreement of some sort between NoodleDoodle and one of the head guys at Trezor who was working on integrating Monero.

Anyway, long story short, the upstream merge of NoodleDoodle's firmware has been halted.  On the bright side, there are other hardware wallet companies such as Ledger willing to help out.  You can read more of what went on recently here on the current thread about the situation on /r/Monero.


There was a "hard" upgrade at that height, older clients will not sync.

Get the latest version at: https://getmonero.org/downloads/

and run it, it will find the old blockchain and simply continue.

If you're still stuck, you can delete last few blocks from your database and try from there. Close your node, run monero-blockchain-import --pop-blocks 5 (it's a separate executable in the package) and restart the node. It will then continue from 1399996 and hopefully go past the upgrade block.


When a block is received while the node is not syncing through backlog, it is validated on the spot. If the node is doing backlog syncing, the block is placed in a queue, and blocks in the queue will be validated in height order.

Since miners are typically always up to date, the former will apply, and blocks will be verified as soon as they are received. "Received" here means the block is complete: it is possible that a block is received which refers to a transaction the receiving node does not know about. In that case, the node will ask for that (or those) transactions(s). Once received, the new block will be complete, and will be validated. Usually, all transaction in a new block are already known, since transactions are propagated before the block.


Is it possible to connect to multiple remote nodes?

No, connecting to multiple remote nodes would increase your risk as you are then having to trust more remote nodes.

Remote nodes are not a centralization risk in any case (you can use any remote node that is open and you can always use your own node). Using a remote node, your risk is hoping they are not a bad actor (e.g. they could be logging your usage/IP, not on the correct chain, not broadcasting your transactions). If these risks are unacceptable for you, run your own node, local or remote.


How do ring signatures work when there are multiple UTXOs from which you have to collect monero coin?

First, in Monero, each output has a unique corresponding key image. Therefore, if a transaction includes three (or multiple for that matter) outputs (that are used as inputs), there will be three (multiple) corresponding unique key images included in the transaction. This ensures none of the outputs can be spent twice. In addition, for each output that is used as input in the transaction, there will be a "ring" with decoy outputs to obfuscate the real input. Put differently, the ring is created to not reveal which output is being spent.

Practically speaking this works as follows. Alice has received, say, two outputs of 3 XMR and one output of 4 XMR. She subsequently creates a transaction for 10 XMR. Now, all three outputs and their corresponding key images will be included in the transaction. If she chose a ring size of 7, each input will be "surrounded" by six decoy outputs to create a ring of seven inputs.

Note that an example of a ring size 7 transaction with three inputs can be found here. As you can see, there are three key images included:

d215c7c214b5cf6e3d2ee5ddf10275054356081f278419801cd711ebe3ba37b7
8c7c48a9ee209f5da3542ee27e70451f9673731b876b6168adc67ca78ae844ad
795b529ca0625f2a045b99ccd404bb9e3c8811ef30b63dd1a1acac7ad0b74593

In addition, each input has a ring of seven inputs.

Sources / Notes:

More information about the key image can be found here.
Technically Monero does not have UTXOs. All outputs are TXOs, because a blockchain observer is technically not able to determine whether an output has been spent or not.


What is the base 58 monero alphabet used to create an address?

Monero has its own variant of Base58.
In Monero the Base58 encoding is performed in 8-byte blocks, except the last block which is the remaining (8 or less) bytes .

The 8-byte block converts to 11 or less Base58 characters. If the block converted to less then 11 characters, the output is padded with "1"s (0 in Base58). The final block is padded as well to whatever would be the maximum size of this number of bytes encoded in Base58.

The advantage of Monero implementation is that output is of a fixed size which is not the case with plain Base58. The disadvantage is that default libraries won't work.

The alphabet for the variant of Base58 is

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

For details, see  https://github.com/monero-project/monero/blob/master/src/common/base58.cpp


Are there any Monero devs involved with the LOKI project?

Not to my knowledge. However, tewinget is a former Monero contributor, and a current (or recent past) contributor to Loki.


How can online store embed some context or product-id in a Monero payment?

There are several different ways to accomplish merchant needs, which one use is up to you.
Payment ID's are just any 8 bytes. You can assign whatever 8 bytes you wish to each product/shop/user then generate an integrated address and resulting QR code for each. Then use get_payments/get_bulk_payments to filter/track.
You could even get smarter and automatically generating payment IDs (and QR codes) based on a combination of customer ID and product ID (i.e. 4 bytes for a customer ID and 4 bytes for product ID), thats two 4 byte integers. Use make_integrated_address to create them in advance or on the fly with random 8 bytes and pair those to an order table row in your orders database.
Then of course there are subaddresses (thus making use of incoming_transfers to track), you could create/assign those by customer/shop/product. These can also be created in advance or on the fly (using create_address).
All the tools are there, just there's no single right or wrong way to organize things, that part is up to you. Research the different approaches and pick one that works best for you.


Standard Address from Integrated Address

As you have learnt, an integrated address is just a standard address with a payment ID, and yes, you can use tools like xmr.llcoins.net to extract the standard address (box 15) and payment ID (box 10.3) from an integrated address entered in box 8.

  Can I simply send funds to the Standard Address (generated in Box 15), and expect those funds to appear in the wallet associated with my Integrated Address?

This depends. If the wallet associated with your integrated address is an exchange wallet (or any other type of 3rd party custodial wallet), this means the exchange expects the payment ID. Therefore, it is fine to send to the standard address so long as you also provide the payment ID. Almost all wallets provide the option to specify a standard address and separate payment ID. However, in this example, sending to the standard address without supplying the payment ID, is probably not a good idea, as the exchange clearly needs the payment ID for however they have implemented their accounting.

This is why there is a clear warning on that tool:

    Note: box 15 is for informational purposes only! Do NOT use the address in 15 unless you know what you're doing!!

In any case, you should think long and hard about what exchanges or services you are using when they are custodial wallets. The phrase "Not your keys, not your coins", comes to mind. If you have the wallet keys, you can safely receive funds to the standard address without a payment ID.

  I also understand that an Integrated Address can be generated algorithmically by combining a standard address with a payment ID.

Correct. See this answer.


How would sharding work in Monero to help with scaling?

Currently it's still an open question but I believe it's the inevitable path if Monero adoption increases. The optimal way for a sharded distributed DB to operate is to have encoded rules for mapping from a key to a shard node. E.g., to look up a key image, use the first byte of the key as a map to one of 256 possible branches of shared containing the record. Some distributed systems use a central directory to redirect lookups to their respective nodes - these scale poorly since the central directory becomes a bottleneck itself.


There appears to be a community consensus for an AEON tail emission based on what I have seen on Bitcointalk, Reddit and IRC. I think most AEON users consider tail emission to be part of the AEON roadmap. Other users at various times have had the false impression that it has already been implemented. However its implementation has not yet formalized or codified.

One proposal being considered by AEON core developer Smooth is described as follows:

  Once the base reward declines below 0.3/minute, then reward will switch to inflationary at a target rate of 0.8888888....%/year (actual rate may deviate slightly in practice due to variations in block rate, block reward penalty, rounding, etc.)

The above proposal is similar but not identical to the system used by Monero where the reward is set to a pace of 0.3 XMR per minute (.6XMR per block with an average block time of 2 minutes).


Running CPUminer Solo mining without client dependencies


Started monerod on the command line in ubuntu, how to connect to it via the gui?

I have not used the GUI because I could not get my wallet to sync correctly.  This was the first GUI released - I have not tried another GUI release since.

However, from what I remember you only need to launch the GUI and a daemon starts automatically for you.

Hope this helps!


My wallet rpc server's balance doesn't update

Waiting 10 more mins until it reached ~60 block maturity allowed me to access my coins. The problem wasn't to do with the server, but to do with the fact that the mined coins must wait much longer than normal transactions before they can be unlocked and spent.


You can't.

Spam because you can't post with so few characters even though it is a correct answer.


If I download a monero client for windows - am I running a full node?

a. I'll be running a full node ?

Yes.  You won't necessarily be acting in the same capacity as other nodes though.  At first, you'll only have outgoing connections, meaning your node is reaching out to others for its data.  You generally must port-forward port 18080 in your router in order to enable incoming connections, where you would then be feeding blockchain and mempool data to other nodes.

  b. Will it be actively mining ?

Negative.  It will not automatically start to mine, but you can mine.  Mining is a function of either the wallet or a mining software.  If you would like to solo-mine, once the blockchain is synced, and the wallet has fully refreshed, you can tell the wallet to start mining.

However, most people who mine will mine on a dedicated machine, using mining software, and they mine to a pool, since a pool has a greater collective hash rate and therefore a better overall chance of winning a block. You don't need to have a local copy of the blockchain to pool-mine.

  c. If it will be mining - can I choose which transactions to pickup for mining ?

The transactions chosen will automatically be the most profitable ones.  You likely won't have to "worry" about this, however, since you're very, very unlikely to ever solo-mine a block at this point in the Monero ecosystem's evolution.


Transactions appearing out of nowhere when running monero in local network

Blocks get mined every 2 minutes on average regardless if there are transactions or not. Your node is the one mining them. You are getting the mining reward.


Understanding the structure of Monero's LMDB and how explore its contents using mdb_stat

Firstly, mdb_stat is a tool to get status information about the database environment, not to explore its contents. Quoting the description directly from the mdb_stat manual:

The mdb_stat utility displays the status of an LMDB environment.

  I am assuming querying it directly (i.e. via mdb_stat) for information should be a lot faster and easier than doing so through the wallet, daemon or RPC. Is that the case?

You cannot perform queries against the data using mdb_stat, as explained above. To actually query the data, you have to use either the LMDB library (as documented here), or use one of it's higher level wrapper libraries for your preferred programing language, or use the wallet/daemon RPC interfaces.

As for the structure, it is documented in the source code here (quoting):

/* DB schema:
 *
 * Table            Key          Data
 * -----            ---          ----
 * blocks           block ID     block blob
 * block_heights    block hash   block height
 * block_info       block ID     {block metadata}
 *
 * txs_pruned       txn ID       pruned txn blob
 * txs_prunable     txn ID       prunable txn blob
 * txs_prunable_hash txn ID      prunable txn hash
 * txs_prunable_tip txn ID       height
 * tx_indices       txn hash     {txn ID, metadata}
 * tx_outputs       txn ID       [txn amount output indices]
 *
 * output_txs       output ID    {txn hash, local index}
 * output_amounts   amount       [{amount output index, metadata}...]
 *
 * spent_keys       input hash   -
 *
 * txpool_meta      txn hash     txn metadata
 * txpool_blob      txn hash     txn blob
 *
 * Note: where the data items are of uniform size, DUPFIXED tables have
 * been used to save space. In most of these cases, a dummy "zerokval"
 * key is used when accessing the table; the Key listed above will be
 * attached as a prefix on the Data to serve as the DUPSORT key.
 * (DUPFIXED saves 8 bytes per record.)
 *
 * The output_amounts table doesn't use a dummy key, but uses DUPSORT.
 */

  For instance, I was hoping to be able to extract information about blocks, transactions, outputs, rings, Pedersen commitments, range proofs, number of rings that use a given output etc,

The data can only be accessed as described above. It's also worth noting the data is binary. The C/C++ objects are written to the database. For this reason, even if you used a higher level language (e.g. Python or Javascript for example) LMDB wrapper, you are still going to need to convert that data to objects in your other language. For this reason, if you are going to directly query the database, you will almost certainly want to use C/C++, the native LMDB library and make use of the definitions in cryptonote_basic.h.

  Does that mean that I am doing a badly formed search, or is it that txs is not yet populated with transaction data?

If I recall correctly, txs is from an older version of the database and it's data has been migrated into the other tx tables as detailed above. You can verify what tables have data in them by running:

mdb_stat -a ~/.bitmonero/lmdb

  ...when I tried to adapt them to queries about the number of transactions it didn't seem to work

The number of transactions can be seen by looking at the entries count of the txs_pruned, tx_outputs or tx_indices tables.


How can I submit a transaction created in --do-not-relay mode?

The content of raw_monero_tx is a raw byte array of a complete tx that is meant to be passed to the daemon RPC /sendrawtransaction. Here's an example on testnet (you need to have your testnet daemon running by doing monerod --testnet):

~$ cat raw_monero_tx
[encoded data, 4098 characters]

~$ curl -X POST http://127.0.0.1:28081/sendrawtransaction -d '{"do_not_relay": false, "tx_as_hex":"[encoded data, 4098 characters]"}' -H 'Content-Type: application/json'
{
  "double_spend": false,
  "fee_too_low": false,
  "invalid_input": false,
  "invalid_output": false,
  "low_mixin": false,
  "not_rct": false,
  "not_relayed": false,
  "overspend": false,
  "reason": "",
  "status": "OK",
  "too_big": false
}

Note that you need to set do_not_relay to false in order to make the daemon relay the transaction.


monero-wallet-cli Remote Mining Intermittently works

Public remote nodes should not be used for mining. Remember the mining happens on the remote node, not your local machine, so you would be using precious resources of the remote public node. If it is your own private remote node, fine.

  Why is it so intermittent?

Probably because the remote node is stopping you, as it should, from leeching it's resources.


Can someone send monero to my subaddress that starts with "8"?

Yes, a subaddress is a valid public address and can be used the same as a "normal" account address.

Here and here are more information on subaddresses.


Monero will be built only if GCC 5 and G++ 5 are installed in your system.


Where can I find the transaction amount checking logic in the source code?

You already found the place for v1 transactions.
For v2 (RingCT) transactions, since in/out amounts are masked, the check is done in src/ringct/rctSigs.cpp, in either verRctSemanticsSimple or verRct (depending on the signature type):

          //check pseudoOuts vs Outs..
          if (!equalKeys(sumPseudoOuts, sumOutpks)) {
            LOG_PRINT_L1("Sum check failed");
            return false;
          }

This compares the sum of (masked) inputs to the sum of (masked) outputs plus the masked fee (the fee is not masked in the actual transaction, so the verification code masks it at that time). The dozen lines above perform these sums.


How do I reduce the apparent memory usage of Monero?

As per comments, Monero memory usage is not an issue here, it's about understanding Linux memory. The usage is not "high" and there is no reason to change anything for those that simply do not understand Linux memory.


Does monerod generates new block template on a repeat call of get_block_template?

monerod caches the block template across calls. but will regenerate one either when a new block is added, one is removed or the txpool has changed. So one should be regenerated when a new transaction is received.
See the relevant code in blockchain.cpp:
  if (m_btc_valid && !from_block) {
    [...]
    if (!memcmp(&miner_address, &m_btc_address, sizeof(cryptonote::account_public_address)) && m_btc_nonce == ex_nonce
      && m_btc_pool_cookie == m_tx_pool.cookie() && m_btc.prev_id == get_tail_id()) {
      MDEBUG("Using cached template");

If you were to remove "&& m_btc_pool_cookie == m_tx_pool.cookie()", it would ensure receiving new transactions does not cause a new block template to be regenerated.


No. Unless they have some kind of access to your local machine of course.
No.

The issue main issue with using a remote node is the operator can log (and associate), your IP address to your transaction(s). That and you're trusting they serve up valid blockchain data.


In Loki, Can you stake more than the requirement in a service node?

No you cannot stake more than the maximum amount of 20,000 loki currently as of 2019-OCT-24. The staking requirement gets lowered everyday until it reaches 15,000 loki after 1-2 years. You must stake exactly the required amount of 20,000 loki, if you don't have enough you can open up your staking node as a pool and others can contribute to it to claim a % share of your staking rewards.


To what extent does my potential level of privacy change by hosting a public node?

The only way your privacy level is affected by running a public node and then using that public node as the remote node your wallet connects to is the extent to which your internet traffic is being monitored, which is really only possible by an ISP, except in more extenuating circumstances. Your internet traffic is generally already loosely monitored/logged, so there's not much of a change then.

The main privacy leak that results from connecting to a remote node is the fact that the remote node operator now has associated your IP with whatever lookups you made on the blockchain.  If you're merely syncing your wallet, then this is nothing much to worry about anyway; but if you're making a transaction, then you must querying the blockchain to pull ring members, which is effectively a metadata leak.  It's a similar leak of metadata to send the transaction through that remote node.

In the case of accessing your own remote node from an external location, you're only leaking that metadata to yourself, so your level of privacy arguably does not change.


Why is the monero GUI synchronization starting from zero every time the daemon boots up?

The current GUI looks like its synchronizing twice. This may be what you are seeing.

Basically, your client first needs to synchronize with the network. This is the downloading and verification of the blockchain.

Then, your client needs to scan the blockchain with your private keys. This is probably what you are seeing.


Can you spend a portion of the balance of a cold storage wallet?

In Monero the change is sent back to the same (public) address. Therefore, it would, in theory, be possible to spend a portion of the balance of a cold storage wallet. However, currently the binaries have no feature available to sign your transaction offline. A possible solution to this is compiling yourself and using this patch. From the patch:

  This change adds the ability to create a new unsigned transaction from a watch only wallet, and save it to a file. This file can then be moved to another computer/VM where a cold wallet may load it, sign it, and save it. That cold wallet does not need to have a blockchain nor daemon. The signed transaction file can then be moved back to the watch only wallet, which can load it and send
  it to the daemon.

  Two new simplewallet commands to use it:
  sign_transfer (on the cold wallet)
  submit_transfer (on the watch only wallet)

  The transfer command used on a watch only wallet now writes an unsigned transaction set in a file called 'unsigned_monero_tx' instead of submitting the tx to the daemon as a normal wallet does. The signed tx file is called 'signed_monero_tx'.

It should be noted that merging the patch results in merge conflicts, which you'd have to go through one by one.

The patch is currently being ported to Ring CT and therefore will likely be merged into master in conjunction with Ring CT.


Running a Monero node over TOR from external SSD hard drive with wallet

Yes. Both the CLI and GUI allow you to set a location for storing the blockchain.
No, they do not have to be on different computers.
You just start up the daemon and it syncs from the network. There is a URL for info on downloading the blockchain and importing it, but honestly, syncing from the network is almost always faster these days.
If you are comfortable on the command line, use that, if not, use the GUI. The CLI is more feature rich but the GUI has everything that most people need.
Up to you. There are no particular drawbacks to running a pruned node though, and it means your drive will take considerably longer to fill up.
You already have good anonymity using Monero. Using Tor helps further because it makes it harder to even know you are using Monero.


There are two ways you can do that:

check your node is at most one or two blocks behind the highest height known in its peers
check whether a new release is available

The first one can by done by running sync_info in monerod, which reports your height as well as that of your peers. The RPC to get that information is sync_info.

The second one can be done by running "update check" in monerod. The RPC to do this is update.


How can one merge mine Townforge with Monero?

Merge mining can only be done if two chains use the same PoW algorithm. In this case, both Townforge and Monero use RandomX, and merge mining can be done using a standard pool miner such as xmrig, which can either be used with a pool or with the monero daemon.
Townforge includes a merge mining proxy which will sit between the miner and the monerod daemon, and will transparently alter the RPC communications between monerod and xmrig to allow merge mining Townforge too.
Note that for the following to work, monerod must first be patched with https://github.com/monero-project/monero/pull/6810 (once this PR is merged, this will not be needed anymore).
Consider a straightforward setup where a user is mining with xmrig to the monerod daemon:
monerod --rpc-bind-port 18081
xmrig --coin monero --url 127.0.0.1:18081 --daemon --user 4....

We will need to run the townforged daemon and the merge mining proxy, such that the proxy stands between monerod and xmrig:
monerod --rpc-bind-port 18083
townforged --rpc-bind-port 18881
townforge-merge-mining-proxy --rpc-bind-port 18081 --monero-daemon-address 127.0.0.1:18083 --aux-daemon-address 127.0.0.1:18881 --aux-wallet-address TF1....
xmrig --coin monero --url 127.0.0.1:18081 --daemon --user 4....

The proxy will connect to townforged too, and is set up with the Townforge address any block coinbase should be sent to. The xmrig command line does not change: while it was previously talking to monerod, it is now talking with the merge mining proxy, and does not see the difference.


Export the blockchain from database format to raw vs just moving the files

Pros:

Fallback method which is sure to always work, as it is virtually the same as getting all the blockchain data you'd get from another node, but in one single file.
It's lighter because it doesn't have any overhead for indexing etc.
It can be appended to easily when new data is available.

Cons:

Slower, because the daemon needs to verify all the data, the same as it would do when getting blocks one by one from the connected nodes.
Also, if you keep both LMDB and the .raw on the same drive, the performance impact will be amplified as the same drive will be used for read/write and it can't do both operations at the same time.

In the past, the LMDB database format was not compatible across platforms. This is an optimized storage built with performance and robustness in mind, to allow the wallet to quickly access and use the data it needs.

On the other hand, the .raw file is "raw" as the name implies, meaning it should be platform-agnostic, ie, the data inside is the bare minimum, unoptimized, blockchain data, as it flies over the network, and nothing else. Think of it as just copying and pasting block data one on top of another and saving this into a file. The .raw file, then, is just a collection of all the blocks in the correct sequence.

When importing, the wallet needs to check it for consistency, by validating each block in the .raw file against concensus rules, because it can't know whether it had been constructed in the correct way, so it needs to check the signatures, PoW etc., unless you exported the .raw yourself or got it from a trusted source.


Ephemeral cryptocurrency with hard limit of blocks

Yes, that's possible to implement. Some blockchain bloat would be avoided. However:

People will be upset, because they forgot/didn't realize their outputs would expire.
People will remember, and will create a transaction to spend the output back to themselves before it expires. Seeing an output being used in a transaction soon prior to expiry is a good sign that the real owner is the one spending it. Therefore this is a possible privacy leak for anyone that had previously used that output as a decoy in their own transaction, because it could be successfully guessed that their transaction would now have one fewer possible source input.


Estimated mining profits are overestimated

On the "Pool blocks" page, you can see in the last column the luck indicator, which is essentially the number of hashes produced by the pool to mine that block vs. the difficulty of the block.

They seem to just have gone through an unlucky sequence with fewer blocks found than expected.

A few notes on this:

there will always be an element of luck in finding the next block, but over time the frequency of blocks should be close to the estimated value
for example, at 2 MH/s vs network hashrate of 50 MH/s, they would find a block every 50 minutes on average, with a ca. 2% probability to find no block for 4h or more, and 15% for 2h
the longer you mine, the closer you should get to your 0.12 a day
the "faster" the pool, the quicker you will get close to your average thanks to the pool "smoothing" of large random events - but the pool you mention looks reasonably large at the moment so shouldn't be a problem
it can never be completely ruled out that the pool is cheating: they may have changed the code of the pool to skip blocks from time to time (I'm not saying it's the case here), they could also change the luck indicator; you can (and should) look at block history and compare the average frequency over time vs their speed to get a feeling of their honesty.


Help to Setup a Monero mining farm $4000 Budget

With that budget I'd probably build a rig around the following components:

AsRock H110 Pro BTC+ (~140€)
6xMSI GTX 1060 GAMING X6G (~360€ each = 2160€ total)

One GTX 1060 overclocked using the following settings will be able to sustain about 540 H/s resulting in 3.2 kH/s with very moderate power consumption:

Core Clock +200 MHz
Memory Clock +800 MHz
Power Limit 65%

Update:

Out of curiosity I've ran XMRig on the AMD Ryzen Threadripper 1950X hosting my beta pool and achieved approx. 1 KH/s using just the CPU. So in theory you could also build three CPU only rigs using that CPU at slightly higher cost but with reduced power consumption (Ryzen 1950X TDP is 180W) and the added benefit of sparing you the hassle of wiring and cooling all those GPUs.


It's up to personal preference, really.  On average, block reward is generally evenly distributed according to hashing power.  If you're okay with mining for months at a time without receiving a payout, then perhaps you're better off.  If you win a block while solo mining, you don't have to share the block reward with anyone, nor do you have to pay the fee to the mining pool.


Size requirements for different "pieces" of a Monero transaction

The transaction structure is:

Transaction version: 1 VarInt

Unlock time: 1 VarInt

Per Input: 1 byte (type: either coinbase or regular spend) + 1 VarInt (pre-ringct amount) + 1 VarInt (the ring size) + Ring_Size VarInts (input offsets) + 32 bytes (key image)

Per Output: 1 VarInt (pre-ringct amount) + 1 byte (type: only regular spend type currently implemented) + 32 bytes (output one-time public key)

Tx extra: Includes 32 bytes for the txpubkey, may contain an encrypted or unencrypted payment id, a nonce if a coinbase tx, and can contain other arbitrary user defined information

Tx type: 1 byte (Version 2 transactions only)

Tx fee: VarInt

Version 1 transactions only: 1 LSAG ring signature per input, each ring signature is 32 bytes * Ring_Size

Version 1 transactions end here. The remainder of the transaction structure applies to Version 2 (RingCT) transactions only:

PsuedoOuts (newly generated commitments for the real input amounts, so that if one real input ring position is revealed, all real input ring positions in the transaction are not also revealed): Per input: 32 bytes (PseudoOuts are present for tx type 2 RCTType2Simple transactions only)

EcdhInfos (encrypted output amounts and OutPk commitment masks): 64 bytes per output

OutPks (output amount commitments): 32 bytes per output

Range proofs: 6176 bytes per output (Dec 2018 update: range proofs have now been replaced with bulletproofs, which are smaller).

MLSAG ring signatures: Per Input: (64 bytes * Ring_Size) + 32 bytes

Therefore, transaction size is most sensitive to increasing the number of outputs, because of the large range proof size requirements. The transaction is also sensitive to increasing the ring size and increasing the number of inputs.

It is expected that later in 2018, a new bulletproof scheme will replace Monero's existing range proofs. This will significantly lower the size of transactions.

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


What pool miners exist that can mine RandomX?

XMRig is the miner with the most actively developed RandomX implementation. It can also seamlessly switch from CN/R to RandomX when the network updates if in your pool config you set the property coin to "coin": "monero". Aside from mining to a pool with XMRig, you can also solo mine against your Monero daemon. This offers a performance improvement over simply mining directly with the daemon's built-in miner.

There is also a version of xmr-stak for RandomX mining, though it should be noted, they simply copied the RandomX code directly from XMRig. Whether this miner supports automatic switching from CN/R or whether the developers plan any unique features w.r.t. RandomX, I cannot answer.


Is there any way to mine using an integrated GPU?

Wolf's GPU miner works with AMD integrated GPUs too. I tested it several months ago. https://twitter.com/hyc_symas/status/695730032291917825

On the A10-4600M each CPU thread got about 50H/s. In my laptop, the dGPU gets about 90H/s. The iGPU gets around 40H/s. These numbers are from memory and I may be misremembering.

With the current AMD driver on Linux, you can only have one GPU active at a time, so you can't enable one for driving the display and use the other for number crunching. It's quite inconvenient. (The open source driver lets you run both GPUs at once, but it lacks support for OpenCL 2.0.)

Correction: not sure if due to an update, but the current AMD driver now allows both GPUs to be active at once. (2016-10-14)

I've just tested with 2 out of 4 CPU threads, plus both the dGPU and iGPU active at the same time. Overall hash rate is slower than just using the CPU + dGPU without the iGPU. This is because the iGPU competes with the CPU for RAM access. With just 2 CPU threads and dGPU, the dGPU gets 89.5H/s and the CPU threads get 50H/s each. Adding the iGPU to the mix, the iGPU gets only 13H/s, the dGPU drops to 87.5H/s, and the CPU threads drop to 23.6H/s.

This is in an Asus N56DP laptop with A10-4600M APU and Radeon HD 7730M dGPU.


Help I forgot to enter a payment ID help

Are you using wallet/exchange service from a company like poloniex?
If so, you need to contact them about your transaction

As I know...
If you use your own wallet, you don't need to worry about payment id.


What do these two lines in electrum-words.cpp do?

Each 3 words gets converted to 4 bytes of the secret key.

This particular line is calculating those 4 bytes (the unsigned integer at w[0]) in the loop which is taking 3 words at a time. It's essentially the reverse of the 4 bytes to 3 words in the function bytes_to_words.


How do I sync 'monero.exe' and my wallet?

1) Make sure that monerod is completely synced with the network. You will know when monerod.exe prints something on the screen along the lines of "Monerod is now synchronized with the network. You may now start monero-wallet-cli."

2) Start monero wallet. After it loads up, type in "refresh." It should then show you something like "Height xxxxxx/xxxxxxx". Once it is done syncing with monerod, it will show you your balance.

Please post if this helped you and if it didn't what happened.


How do I get the TX Key from the GUI Wallet?

First note that you can only obtain the private tx key for outgoing transactions, because it's randomly generated by the sender. In the GUI, first go to History tab. Subsequently, you can obtain the private tx key by clicking on Details of the relevant outgoing transaction.

Lastly, bear in mind that if you have to rebuild your wallet cache (after you, for instance, deleted it) you'll lose your private tx keys.


A thread problem and a query for solo mining

First and foremost, note that CryptoNight uses 2 MB per cache. Thus, the optimal number of threads is total amount (in MB) of cache divided by 2. If you want to start solo mining and specify the number of threads it can be done as follows:

start_mining [<number_of_threads>]

Note that if this command is entered in simplewallet, it will mine to the address of that particular wallet. If you want to mine to a different address, the command is as follows:

start_mining <address> [<number_of_threads>]

If you enter the command the brackets should be removed from the number_of_threads. Thus, a valid command would be:

start_mining 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A 2

  Is it normal?

This is the difference between pool mining and solomining. With pool mining, you represent a share of the total hashrate of the pool. If the pool hashrate is relatively large, in case of MinerGate, it will find blocks relatively often. That is, if MinerGate has about 20% of the total hashrate, every one in five blocks, on average, should be found by the pool. Given that you contributed to this hashrate with your share (i.e. your own hashrate), you should expect small "balance updates" every one in five blocks. By contrast, with solomining your balance will only update if you find the block yourself. Given that your hashrate when solomining is much smaller than the total hashrate of a pool, it could take a while before you find a block and thus see your balance updated. If you possess 0.1% of the total hashrate and solomine, you should, on average, find a block once every thousand blocks.

In the end the rewards will probably be the same, but solomining with a lower hashrate will obviously have a lot more variance. However, with solomining you probably incur fewer fees.


Why don't GPU miners work with open source drivers?

GPU miners use the GPU programming framework, which is usually proprietary (like CUDA for Nvidia cards).

Therefore to use the GPU programming capabilities with the open source drivers (probably with the OpenCL framework), the people working on the drivers have to reverse engineer how the card works internally. And so far the open source drivers' support for OpenCL is too immature/slow to be usable for GPU mining.


What are the current staking and mining rewards for the Loki Network as of 2019-May?

Per the Loki docs, the LSR calculation is:

15000 + (25007/2^((h-101250)/129600))

Where h is the block height.

E.g. using current height 281798:

$ perl -e 'print 15000 + (25007/2**((281798-101250)/129600));'
24521.1959709724

You can calculate the future LSR by simply increasing the block height.


Monero original giving me this strange line saying upgrade

Monero has updated its consensus rules a couple months ago. What some call "Monero original" is just an old Monero version on which some people continued to mine. You need to update your software so it can parse the new blocks/transactions or it will stay on the old chain. Until you do, it will not be able to understand those "new version" blocks, and warn about them.


Error trying to compile Monero on Fedora 25 - makefile:62: recipe for target 'release-all' failed

You are missing cmake, one of the prerequisites for building Monero. cmake is a build tool, which can be installed on Fedora this way:

sudo dnf install cmake

Once cmake is installed, try make again.

Since you say cmake is installed, then it is either manually installed somewhere not in your PATH, or some of it is corrupted, or it is not actually installed. If you think it's installed, install it again. Or remove it, then install again. To check if cmake is installed:

which cmake

It might be that a non default version of cmake might be installed, then it might be called something like cmake-x.y. Try typing just cmake then TAB twice to attempt to autocomplete to a command in your PATH.


Using old HDD laptop for storing blockchain - slow synchronization - would an external SSD help?

The speed of synchronizing multiple-days' worth of Monero blocks is primarily bottlenecked by 1) internet speed, 2) CPU (for verification), and 3) drive speed. It's likely that an older laptop might just be very slow when it comes to the CPU speed. However Monero uses the LMDB database, where the developers state here that an SSD is considered essential for performance: https://symas.com/anticipating-future-lmdb/  It's likely that a fast external SSD will improve your synchronization speed modestly, though a better computer would lead to a better result. (Of course, the simple strategy of synchronizing more often would be the easiest overall.)


How can individuals safeguard themselves and the community against a key reusing fork?

First, there is no stealing possible, so your funds are safe ASSUMING THE MONEROV (OR OTHER KEY REUSING FORK) SOFTWARE IS NOT A TROJAN. If it is not, then the key reuse only affects one of the privacy layers Monero offers, and does not allow either double spending nor stealing. Of course, since monerov is currently closed source, it may be that the binaries are a trojan to steal keys.

The main danger by far is the unravelling of ring signatures caused by using the same pre-fork output on two different chains with different rings: since the key image on both rings is the same, an attacker can deduce the real input is on both rings, and using random rings means only one input will usually match. This can be prevented by reusing the same ring on all chains, in order for the intersection to be the whole set. This will be done automatically if both forks use the shared ring database which Monero included in response to this threat. The shared ring database ("ringdb") will store the rings used for your outputs, so they can be reused when spending the same output again. It will be included in Monero 0.12, which will be released in the next few days. Hopefully the monerov people will include this feature too. If they do, then its use will be automatic.

If they do not include it, or include a broken version of it, then it's only half automatic (on the Monero side), and you will have to be more careful:

spend on the key reusing fork
check the rings used by your key reusing fork transaction by running print_tx TXID on that fork's node dameon (the rings are near the top of the transaction printout)
use the set_ring command in Monero's monero-wallet-cli to save those rings to the ringdb, eg:

set_ring KEY_IMAGE_HERE relative A B C D E F

A B C D E F should be the ring printed by print_tx TXID. Those are encoded as relative offsets. If you obtain the rings as absolute instead (maybe from a block explorer), then replace "relative" with "absolute" in the command above.

then spend monero, and any ring will be reused as required.

Now, some people may not use this, and thus will strip themselves of privacy in the process. For these cases, Monero includes a second line of defense, to allow your rings to avoid using outputs which are known spent (since using one of those decreases the privacy ring signatures offer). This is the blackball database. This can be created locally if you have both chains using the monero-blockchain-blackball tool, eg: monero-blockchain-blackball ~/.bitmonero/lmdb /path/to/monerov/database. This will take a while to scan the databases. Once this is done, the wallet will automatically avoid the inputs which were found to be unsuitable.

Note that since this process takes time, the blacklist database will be made available on the getmonero.org website, and can be imported (using blackball FILENAME in monero-wallet-cli, or from the "Shared ringdb" page in monero-wallet-gui). It will be updated on the site from time to time, so can be imported regularly.

Last, a third line of defense is to alter the fake output selection algorithm:

The first one, called either segregate-pre-fork-outputs in monero-wallet-cli or "I will spend on a key reusing fork" in monero-wallet-gui, ensures that spending a pre-fork output only uses pre-fork fake outputs, since spending on both blockchains will moot post-fork outputs.

The second one, called either key-reuse-mitigation2 in monero-wallet-cli or "I might spend on a key reusing fork" in monero-wallet-gui, uses a selection of pre and post fork fake outputs to avoid special degenerate cases.

In any case, a key reusing fork will only affect ring signatures, and will not do anything against stealth addresses nor confidential transactions, the other two layers of protection in Monero.

As a last warning, be very wary of using your secret keys with other software, especially closed source. These are called secret for a reason.


Minimum amount of keys needed to recover funds?

Is it possible to recover all your xmr funds from providing only your private spend key?

That depends on whether the private spend key is deterministic or not.

First, a bit of history. In Monero's early days (before 24 (and later on 25) word mnemonic seeds), Monero's private spend key was non-deterministic. In other words, the private spend key and private view key were both independently and randomly generated. As a result, losing access to either of those would result in you not being able to retrieve your funds (note that the .keys wallet file would still contain all your keys). Nowadays, however, the private spend key is deterministic and the private view key is derived from the private spend key by hashing the private spend key with Keccak-256 (hash_to_scalar). Subsequently, the private view key is reduced modulo l (sc_reduce32).

  Or do you need the private view key too?

Thus, in sum, you need the private view key too if the private spend key is non-deterministic. If, however, the private spend key is deterministic, you can simply derive it.

  And how can this be done in the cli if you only had the private spend key?

For "spend" wallets, the CLI will currently only accept full key pairs, i.e., it requires both the private view key and the private spend key in addition to the public address. Thus, the CLI will not derive the private key for you if your spend key is deterministic.

Fortunately, there are tools out there to derive the private view key from a deterministic private spend key. You can, for instance, use this tool from luigi1111 (a Monero core-team member). It is used as follows (in case of merely possessing the deterministic private spend key):

You can either browse to this link or download the ZIP file from here (in case you want to use it locally and/or offline).
Enter your deterministic private spend key in box 2. Hexadecimal Seed:
Click Gen 3. & 4.
Click Gen 5.
Click Gen 6.
Click Gen 7.

You can now take the private spend key from box 2. Hexadecimal Seed:, the private view key from box 4. Private View Key:, and the public address from box 7. Public Address:. Subsequently, you can proceed to restore / recreate the wallet --restore-from-keys <arg> flag from the CLI. This is done as follows:

Windows:

Go to the folder monero-wallet-cli is located and make sure your cursor isn't located on any of the files. Subsequently do SHIFT + right click and it will give you an option to "Open command window here". Note that, if you're using Windows 10, it'll, most likely, give you an option to open the Powershell. Lastly, type the following command:

monero-wallet-cli.exe --generate-from-keys <new-wallet-name>

If that doesn't work in the Powershell, type:

.\monero-wallet-cli.exe --generate-from-keys <new-wallet-name>

If that doesn't work either in the Powershell, type:

./monero-wallet-cli.exe --generate-from-keys <new-wallet-name>

Linux and Mac OS X:

Open a new terminal from the same directory as monero-wallet-cli and subsequently type:

./monero-wallet-cli --generate-from-keys <new-wallet-name>

In the GUI you can simply select Restore a wallet from keys or mnemonic seed on the second page of the wizard (first page is language selection). If you currently have a wallet open, you ought to go to the Settings page and press Close wallet first.

To end, a few notes:

In general, when restoring a wallet, one has to add a Restore height. It's relevance can be found here: What is the relevance of the restore height?
You can currently still generate a non-deterministic private spend key (using the CLI) with the --non-deterministic flag.
A relevant SE question for visibility: Can you sweep a wallet if you only have the private spend key?
Luigi111's tool also has a great informational part (at the bottom under How Cryptonote Addresses Are Created).


monerod crashes after several minutes with no errors

So I figured out what was going on.

My environment was a VPS and the virtualization environment was from OpenVZ, for which all users share a kernel. So access to these kernel logs were disabled for any individual users. I had to contact the VPS administrators and inside the kernel logs monerod was exceeding the limits of kmemsize, so they changed it to unlimited.

It also turned out that the file /proc/user_beancounters had information that would have revealed this. it contains information for container limits, one of which was kmemsize. There's a column showing the number of times a program was killed due to exceeding these limits. Anyway, that number was pretty high, suggesting kmemsize was the problem as well.

Now monerod works fine.


Running monero service on WIN10 with custom --data-dir

You can do this on Windows using NTSF symlinks:

Open an elevated CMD window. Then:

mklink /D "C:\ProgramData\bitmonero" "x:\mydir\monerodir"

Then you don't need to specify any other command line options when starting the monero daemon.


Why are there transactions in the Mempool that are invalid or over 50 hours old?

how is that even possible?
  ...
  What is wrong with the other TX that don't get confirmed (over 50 hours old)?

Transactions can stay in the mempool for 7 days if they are found in an orphaned  block:

#define CRYPTONOTE_MEMPOOL_TX_LIVETIME                    (86400*3) //seconds, three days
#define CRYPTONOTE_MEMPOOL_TX_FROM_ALT_BLOCK_LIVETIME     604800 //seconds, one week

  Are transactions not validated before they enter the mempool?

Well a tx is broadcasted into the mempool and nodes validate it. The older transactions you reference are almost certainly in orphaned blocks and will drop out of the mempool when they are older than 7 days. If it failed any other verifications (such as double spend or inputs not fully spent) it would drop out faster.


How much CPU power to mine 1 coin a day?

This answer will attempt to answer the question at multiple levels, as follows:

Section I explains the basics of how to calculate this yourself.
Section II provides updated calculations based on Section I.
Section III provides an abstracted way to determine this based only on the total network hashrate and the total number of coins in circulation.

Enjoy :)

I. Explaining how to determine this on your own:

Some basics:

Monero has an average block time of 2 minutes, meaning that there are approximately 720 blocks per day.
Your expected reward is proportional to your share of the network hashrate. The current hashrate is ~23.3 MH/s (http://moneroblocks.info/), or 23300000 H/s.
Monero's block reward is decreasing slightly every block. Right now it is a little less than 11 XMR, but I'm going to just use 11.0 in my calculations.
To find out the exact reward at any given time, you could go to a block explorer (http://moneroblocks.info/) and click on the most recent block. It will tell you the reward for that block.
Disclaimer: The reward changes based on how many transactions are included in a block. For instance, block 1124279 was empty and had a reward of 10.826400000000, while block 1124278 had 4 transactions and a higher reward of 11.078600000000. Nonetheless, you can get a rough idea using this method...

Okay, putting it all together, where your share of the hashrate is "n":

daily reward ≈ (720 * Avg Block Reward * n)/(Network Hashrate)

Since the question was for a reward of 1 XMR per day, using the numbers above:

1 XMR ≈ (720 * 11.0 * n)/(23300000)

and solving for n:

n ≈ 23300000 / (720 * 11.0)
n ≈ 2942 H/s

which is pretty close to @villabacho's answer.

  I just want to get a general idea.

Generally speaking, the formula to determine the hashrate needed to mine 1 XMR per day is:

n = (Network Hashrate) / (720 * Avg Block Reward)

  What CPU / GPU would be required to solo mine 1 coin a day?

The most energy efficient GPU that I know of for mining XMR is the GTX 750 Ti, which gets approximately 250 H/s for a little more than $100/GPU. 12 of these GPUs would give you 3000 H/s, or a little more than 1 XMR per day at the current mining and reward levels.

II. 20 June 2017 Update to Section 1:

Hashrate: ~87.4 MH/s
Reward: ~7.22 XMR/block (including fees)

Using our formula n = (Network Hashrate) / (720 * Avg Block Reward):

n = 87400000 / (720 * 7.2)

n = 16812 H/s, or 16.81 kH/s to mine 1 XMR per day.

You would need approximately 67 GTX 750 Ti's at 250 H/s each, OR approximately 28 RX 470's at 600 H/s each, OR approximately 22 RX 480's at 750 H/s each.

III. 20 June 2017 addition abstracting calculation further:

A more general formula can be developed that calculates the Average Block Reward used above from the total coins in circulation.

The base block reward is calculated by

Reward = (M - A) * 2^(-19) * 10^(-12)

where M = 2^64 and A is the current amount of XMR in circulation (in terms of atomic units, where 1 XMR = 10^12 atomic units). We can reduce this for ease of use to be as follows:

Reward = (18446744.073709551616 - a) * 2^(-19)

where a = A * 10^(-12) and represents XMR "coins" in circulation as we traditionally think of them.

From this formula, it should be clear that the base reward for each block is progressively decreasing. However, we can consider it roughly constant in the short term for our purposes here, as over a 720 block period (one day) the reward drops ~0.01 XMR at today's rate. Therefore, we can substitute this Reward value as an approximation of the Avg Block Reward over a relatively short period with an error of much less than 1%. Combining our two formulas:

n = (Network Hashrate) / (720 * Avg Block Reward)

and

Reward = (18446744.073709551616 - Coins in Circulation) * 2^(-19)

and reducing gives

n = (Network Hashrate * 2^19) / (720 * (18446744.073709551616 - Coins in Circulation))

or more simply

n = (728 * Network Hashrate) / (18446744.073709551616 - Coins in Circulation)

According to https://www.monero.how/ at the current block height of 1336863,

The network hashrate is 87.4 MH/s or 87400 kH/s
There are 14658448 total coins in circulation

Substituting these values into our formula

n = (728 * 87400) / (18446744.073709551616 - 14658448) [kH/s]

and noting that n is in kH/s, we would need 16.796 kH/s of hashing power to mine 1 XMR today.

Note: This calculation does not include fees, so you should actually mine slightly more than 1 XMR today with that hashrate. But you will have to pay pool fees, account for variance, etc, so it's a fairly good approximation still.

TL;DR - Use one of these formulas:

n = (Network Hashrate) / (720 * Avg Block Reward)

or

n = (728 * Network Hashrate) / (18446744.073709551616 - Coins in Circulation)


How does one register a Loki Network Name on the Loki name service?

You can register using the command:

lns_buy_mapping namehere 0000...1111

You link the name to a session chat id or a loki address.

To check if you own it do:

lns_print_owners_to_names

Cost is currently 20 loki.


Is there a way to make a public message where anyone can see on the monero blockchain using payment ID?

Old style 256-bit payment ids are not encrypted. New style 64-bit payment ids are encrypted such that only the recipient can view it.

Monero transactions also have a tx_extra field that you can put whatever extra information you want into, so you are not limited to a message length of 256 bits. Doing this would require you to modify the Monero wallet software unless someone else has already implemented this functionality in their own wallet software for you to use.

Since all blockchain viewers I know of will only display hex and not ascii representations of the tx_extra field, you will have to ask the recipients of messages to use a site such as this to view the hex as ascii characters https://www.rapidtables.com/convert/number/hex-to-ascii.html

Edit: as pointed out in the other answer in this thread, xmrchain.net will display the ASCII representation of the unencrypted 256-bit payment id field. However it will not display the ASCII representation of the entire tx_extra field, so if you create a custom tx_extra field then the recipient will still need to use a hex to ascii converter.

Putting messages into Monero transactions is not something that should be encouraged, since it makes certain transactions stand out on the blockchain as different to other transactions. If too many people start doing this, there would be a good argument for either preventing this functionality (via a consensus algorithm change) or for creating a special new transaction type purely for publishing messages where those special transactions would not ever be referenced by other regular transactions.


How to restore a Monero wallet from Private Keys

Importing a wallet from MyMonero into monero-wallet-gui is easy.

Follow these Steps:

Go to mymonero.com, access your account and navigate to Account Details. it will look like this:

Open Monero-wallet-gui and choose the 2nd Option:

Now Enter you Account Details from mymonero.com. As Restore height, use the height of the first transaction to your wallet minus 20k. Thus, if the first transaction to your wallet was included in block 1350000, use 1330000 as restore height. You can check the height of the first transaction to your wallet by entering the transaction ID / hash in a block explorer like, for instance, XMRchain.

Now you can click the Next Button and set a password for your wallet.
On the next page, click "use monero" and you are ready to go.

Please Note:

If you only use your Private View Key, a View-only wallet will be created.
This Feature is only available in monero-wallet-gui beta 2 and higher.
You need to sync up with the network so you can see your transactions and balance.
If you want to use a remote node, use this guide.


How do I figure out what nodes I'm connected to and who is sending what to who?

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

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


How to check Monero balance via address and view key?

You can restore a wallet (e.g. create a new one) with your existing address and keys. See the guide: https://www.getmonero.org/resources/user-guides/restore_from_keys.html
Once you've restored your wallet you'll be able to scan the blockchain to check your balance.
If you really want to do this via the wallet RPC, see: generate_from_keys.


How to calculate Monero addresses for different account numbers?

Each account is simply another subaddress. Therefore the math is identical to the usual subaddresses calculation - it is still represented by an i index in:

PSi = Hs(pV0 || i) G + PS0

(using Mastering Monero's notation).

However, it's worth noting that the calculation for the subaddress secret key is actually m = Hs(a || index_major || index_minor), and for its public key, M = mG, where index_major is the account index and index_minor is the subaddress index. Thus i is the concatenation of index_major || index_minor.

Therefore the Master Monero example is a little misleading. The subaddress, regardless of which account it is in, is actually calculated like:

PSij = Hs(pV0 || j || i) G + PS0

Or in the common notation used in the code and elsewhere:

m = Hs(a || index_major || index_minor)
M = mG
D = M + B

D being your public view and spend keys for account # subaddress #.

Sources: device_default.cpp#L144 and device_default.cpp#L198


How do I change input selection after my wallet provides an unfavorable choice?

For your particular case: use the latest version of monero-wallet-cli, and set min-outputs-count 1000. This will tell the wallet to not include a second unneeded input. However, your transaction will look different from the majority of other transactions, which tend to have 2 inputs. As this new code gets used more and more though, there will be a good mix of 1 and 2 input transactions.

In the general case, though, it is more complicated, and depends on the amount sent and your particular owned output set (and I won't go into details because it's complicated, not really relevant, and subject to change). Sometimes there will be a random selection, and sometimes not.


It concerns block 202612. There's a good explanation from Fluffy in this similar question: What happened at block 202612? You can find the references to block 202612 in the code on GitHub.


How to use my 13 word MyMonero mnemonic seed with the GUI/CLI without accessing MyMonero?

This is done as follows:

Go to this page: https://github.com/luigi1111/xmr.llcoins.net/
Click on Clone or download and download the ZIP file. This ZIP file can be used offline if needed.
In addition, you can verify the files by following the steps in the README: https://github.com/luigi1111/xmr.llcoins.net/#xmrllcoinsnet
Open addresstests.html
Put the 13 word MyMonero seed in box 1. Mnemonic Seed
Click on Gen 2.
Click on Gen 3 & 4.
Click on Gen 5.
Click on Gen 6.
Click on Gen 7.
Now that you have your private view key + private spend key + public address, proceed with this guide:

How to restore a Monero wallet from Private Keys

For the CLI, first perform step 1 to 10 as well. Thereafter, perform the following steps:

[1] Browse to the directory monero-wallet-cli is located.

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

[2b] On Linux and Mac OS X, open a new terminal from the same directory as monero-wallet-cli

[3a] On Windows, type the following command in the command prompt:

monero-wallet-cli.exe --generate-from-keys <wallet-name>

If that doesn't work in the Powershell, type:

.\monero-wallet-cli.exe --generate-from-keys <wallet-name>

If that doesn't work either in the Powershell, type:

./monero-wallet-cli.exe --generate-from-keys <wallet-name>

[3b] On Linux and Mac OS X, type the following command in the terminal:

./monero-wallet-cli --generate-from-keys <wallet-name>

[4] Enter your private spend key, private view key, and public address, and it will "recreate" your MyMonero wallet.

P.S. Luigi1111 is a core-team member of Monero.


Is it possible to solo mine Monero (XMR) using AMD and Nvidia GPUs in the same rig?

Yes, you can solo mine using both cards if you use a miner like xmr-stak and point it to a pool that supports solo mining.


What is the relationship between view key and random r value for pedersen commitment?

The transaction amount is encrypted using Pedersen commitment with a random value r.

The amount is encrypted using the shared secret rA and committed to in a Pederson commitment.
Amount encryption:
b = n xor8 Hs(“amount”|Hs(rA|i))

Where n here denotes the unencrypted amount, rA is the shared secret, i is the output index, | is concatenation, Hs is hash to scalar and b is the final encrypted amount.
Then the Pedersen commitment C:
y = Hs(“commitment mask”|Hs(rA|i))
C = yG + bH

So one either needs r or a (private terms of the shared secret) and either R or A respectively, the public terms. R is rG, the tx public key and A is the receivers public view key. Thus with a (the receivers private key) and the tx public key R, one can decode the amount. As can the sender as they have r and A. This is because rA == aR.

Can I see the transaction amount if I only have the public view key?

No. You need some secret information, either r or a.

What is the relationship between view key and the random r value in Pedersen commitment?

See above.


How much "Earned uptime credit" do I get when staking Loki on a Service Node?

you should find your answer here https://lokidocs.com/ServiceNodes/DeregistrationRules/#decommission-and-credits


Minergate CLI mines only XMC but not Monero XMR

Don't use Minergate, it's a scam.
Try XMrig https://xmrig.com/ or xmr-stak https://github.com/fireice-uk/xmr-stak/.
They are both good, if you still need assistance post here.


Is Hybrid mobile wallet is as just secure than native

If you run a full node and use the wallet that comes with it, you have complete privacy.  The odds of being robbed go down to practically zero because no one can see what your doing.

When you use any type of a wallet that connects to a remote node, your privacy is gone.  The host of the remote node can see what you are doing.

If you only have a few moneros, no big deal if someone ends up stealing them from the block chain using the keys in your light wallet.  If you have a serious amount of moneros, you would be foolish to use a mobile device and/or a remote node for them to see your keys to the block chain.


What happened at Monero difficulty from Nov 2017 to Jan 2018?

It means that the network is used by more powerful miners. Difficulty adjusts to the network hashrate (after every block, unlike Bitcoin which adjusts difficulty only every 2016 blocks, around two weeks for 1 block / 10 minutes), meaning it will be more difficult to mine a block the more miners will join the network (if the overall hashrate goes up).

I expect the hashrate to rise over time, as I believe Monero to be more profitable to mine in the future. The more profitabel Monero will be to mine in the future, the more miners will join, causing the hashrate and difficulty to rise. This is so new blocks are still mined roughly every 2 minutes, even if computational power increases.

The reason for the increase lately could be (but doesn't have to be) because of a botnet mining Monero. But that alone wouldn't increase difficulty so much.

This is not financial advice and only reflects my own opinions.


The "status" command in monerod tells you your hash rate.

The number of hashes submitted is pretty close to your hash rate multiplied by the amount of time you've been mining (give or take a few). The number of blocks attempted is... that same number. Unless you're defining number of blocks attempted differently.


Credit to @JollyMort

the python base64 module can encode/decode the unsigned_tx file into ascii for transmission via QR code:

import base64
...
...
with open(args.infile, "rb") as source:
    with open(bitPath, 'wb') as dest:
        dest.write(base64.b64encode(source.read()))
<transmit sliced up bitpath file via qr codes as is now ASCII>

<on receive side, concatenate ascii qr codes to one file>
with open(asciiPath, "rb") as source:
    with open(stitchPath, 'wb') as dest:
        dest.write(base64.b64decode(source.read()))

file stitchPath should match original unsiged_monero_tx file


My blockchain is stuck, how do I "unstuck" it?

Note that, if you are stuck on block 1288639 (or block 1400001) or a few blocks later, you are using a wrong, outdated, version and you should upgrade to the latest version, which can be found here. In addition, this won't require a resync from scratch, as the "new" monerod will automatically use the blockchain that was used with the previous version and pick up syncing where it left off.

The first step in getting your blockchain unstuck is making sure that no Monero related process is running anymore. Thus, close the GUI by clicking on the x and make sure to stop the daemon as well. If you're using the CLI, type exit into both monero-wallet-cli and monerod. Thereafter, use your task manager to check whether all Monero related processes are closed. Alternatively, you could simply reboot.

Now that no Monero related processes are running anymore, delete p2pstate.bin. On Windows it can be found in the following directory:

C:\ProgramData\bitmonero

Note that, by default, the ProgramData directory is hidden. Therefore, use the explorer to manually navigate to aforementioned directory.

On Linux and Mac OS X:

$HOME/.bitmonero

This directory is hidden by default too. On Linux you can use CTRL + H to unhide directories (note that this might not work on all Linux distributions), whereas on Mac OS X you can use cmd-shift-dot unhide directories.

After you've deleted p2pstate.bin you can restart monerod / the GUI. If this didn't resolve your issue, please read further and make sure monerod / the GUI is closed again.

We're going to add the following flag:

--block-sync-size 10

This will change the batch of fetched blocks from 20 to 10.

You can add the flag as follows:

If you are using the GUI, simply add --block-sync-size 10 as daemon startup flag. You can do this on the Settings page of the GUI. Note that you'll have to restart the GUI + daemon for the flag to take effect. Thus, add the flag, exit the GUI and stop the daemon as well, and lastly restart the GUI + daemon.

If you are using the CLI, please see below.

On Windows make sure to launch it from the command line. Go to the folder monerod is located and make sure your cursor isn't located on any of the files. Subsequently do SHIFT + right click and it will give you an option to "Open command window here". Lastly, type the following command:

monerod --block-sync-size 10

On Linux and Mac OS X you should use the terminal to launch monerod. Note that this has to be done from the directory monerod is located in. The command is as follows:

./monerod --block-sync-size 10

If your blockchain is still stuck after adding this flag, please browse again to C:\ProgramData\bitmonero (Windows) or $HOME/.bitmonero (Linux and Mac OS X), open bitmonero.log and check it for any errors. If you see any of these errors (or similar to them), your blockchain is most likely corrupted and you need to resync from scratch.

Error opening database: Failed to query m_blocks: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid

Failed to parse and validate tx from blob (per MoneroMooo: This can be a corrupt blockchain, if this comes from a block inside the db. However, it's much more likely to be an old version not knowing about a new fork)

This is done by deleting data.mdb from C:\ProgramData\bitmonero\lmdb (Windows) or $HOME/.bitmonero/lmdb (Linux and Mac OS X), which will trigger the resync.


When syncing Monero's blockchain from scratch, why does it begin fast and end slow?

The speed of transaction validation was reduced with the activation of RingCT at block height 1220517 in early January.

Although RingCT transactions still take longer to validate than pre RingCT transactions, the difference in performance was significantly reduced with the  10.2.1 release that went live this week. Further improvements are expected, the extent of which are yet to be determined.


Vcash privacy and scaling compared with Monero?

Unlike Monero which has many developers, Vcash arguably has a bus factor of 1. After recently being doxxed, its developer is alleged to have made harmful changes to the code before abandoning the project:

  Zero day flaw that allows miners to opt-out of paying incentive rewards to nodes

The operator of the suprnova mining pool had this to say:

  I've thought about this, but it would be necessary to fork away from "his" code into a trusted coinbase setup as he simply could have coded too many "backdoors" into his code.. It was him obviously very easy possible to fork off pools and bigger miners from "his" chain and make "his" chain the valid one, even if the "bad pool" had much more power than him, this should never be possible for any coin.. not with > 51% of the power of the net and of course not with less.. I see lots of problems with the current code.

The security of any coin with that level of centralization of development and control is dangerous:

  Obviously he was able to fork off pools/miners from "his" chain without even having more than 51% of the network, if that is not evidence enough.. Well..
  And no, it wasn't only my pool Smiley

  I'm running pools for years and I know very well how to "protect" them, or was anything hacked ? He forked off and banned the node(s) of my pool three times, invalidating blocks on the pool even while the pool had a lot more than 50 % of the network.

Regarding scaling, Monero developer "smooth" said:

  I'll start with this deleted post that was removed by one of their scam promoters claiming that Bitcoin is going "copy Vcash" by adding an adaptive blocksize. I pointed out that Monero (and previously Bytecoin) had such an adaptive blocksize almost a year before Vcash launched.

Well known Bitcoin developer Greg Maxwell posting a warning about Vcash on Bitcointalk and after the failure of "John Connor" to remedy a clear copyright violation:

  FWIW, I politely reported the copyright violation (the code being a copy of Bitcoin Core run through an auto-formatter with all the attribution removed) as an issue on the github for the project and john-connor accused me of stalking him and then hid the issue tracker on that github from public view. :-/

  I suppose I shouldn't be surprised as it's consistent with the rest of the concerns that resulted in creating this thread-- that there is some ongoing effort to keep that work out of the sunlight.

As a result of these warning signed, other developers avoided the project. With a bus factor of one a thorough review of the Vcash privacy system was never completed. It appears to use some sort of a CoinJoin based mixing system similar to DASH meaning it does not offer privacy by a default like Monero. It also means that the privacy provided is far inferior to Monero with ring signatures and stealth addresses today and RingCT in January.


Your errors indicate that your blockchain is most likely corrupted. To resolve this issue you need to resync from scratch. This is done by deleting data.mdb from C:\ProgramData\bitmonero\lmdb (Windows) or $HOME/.bitmonero/lmdb (Linux and Mac OS X), which will trigger the resync.

To avoid corruptions make sure to always gracefully exit monerod.


The way blocks are currently propagated, every transaction is sent even though a node might have many, if not all transactions already.

The idea is to just send the block header and transaction IDs, and if necessary, any missing transactions.

The ultimate achievement is a reduction in data sent over the wire, which translates to lower bandwidth requirements to run your own full-node.


Twisted Edwards curve and stealth addresses

Stealth addresses require an agreed upon eliptic curve and hash function. For use with Monero, this is Ed25519 and Keccak (as used in Hs - hash to scalar), respectively.
I have no knowledge of "Sage". Perhaps someone else can answer this for you.
See https://crypto.stackexchange.com/questions/53154/how-is-the-precomputed-table-for-25519-elliptic-curve-generated
Possible, yes. Useful, doubtful.