How to create a wallet from my own seed?

I assume you've created the equivalent of a 256 bit number by throwing dice.

First, you need to ensure your number is less than 2252+27742317777372353535851937790883648493 (which is the group size of the base point G).

This gives you your private spend key.

Then you need to compute a keccak(256) hash of the spend key, interpret the resulting 32 bytes as a number, and determine that number mod 2252+27742317777372353535851937790883648493.

This gives you your private view key.

If you want to generate your seed from your private spend key, you need to convert it to base 1626.


Try this:

Create a view only wallet (settings page)
Open view wallet and create a transfer, save with "Save tx" button
In original wallet, click "Sign tx" on send page and select the file
in view wallet, click "Submit tx" and select the signed tx file


Does moneromooo have a direct donation address?

His donation addresses are:

Monero: 4AfUP827TeRZ1cck3tZThgZbRCEwBrpcJTkA1LCiyFVuMH4b5y59bKMZHGb9y58K3gSjWDCBsB4RkGsGDhsmMG5R2qmbLeW

Aeon: WmtXcFZj5iGY21JxAtFsJVQmQQyo7jgoJP8V4zLWVzDeeTfvbP8Mzb5gbNpQEc6BkeUYUqjGntHDSDyA6LKjdGBQ1w9iEpfVw, as seen in his address generator page.


A pool didn't find a block since 4 days, is it normal?

On typical pools, a miner's pending balance will increase about 4 hours (60 blocks at 2 minutes a block) after the pool finds a block, assuming it is not orphaned in the meantime. When the miner's pending balance reaches the payout threshold (displayed on the payments page on most pools), a chain transfer will occur.

If a pool is unlucky and does not find a block for a while, then the miner's pending balance will obviously not increase, since there is no new monero found. Conversely, a lucky pool finding several blocks quickly will cause the miner's pending balance to increase often.

Pools usually display their estimated time between blocks, near the top center of the main page. This can be calculated by: 2/(H/h) minutes, with H being the network hash rate, and h being the pool's hash rate. This is of course an estimation only. Divide this by 1440 (minutes in a day) to get estimated days between blocks, rather than minutes.


Windows users, do you want to prepare your OS to use full node wallet, solve some sync issues and make your chaindata less likely to be corrupted?

After seeing this as a common issue, im gonna try to give you a way to "prepare" Windows for using your full monero node. The post its from my authory and its the result of my own research.

Im gonna try to guide you about a common issue related to Windows. First of all, make sure you have set Windows to synchronize the hour automatically from internet:

https://image.ibb.co/jcQcsw/synchour.png

It doesnt matter if it doesnt sync at the first try. Just make sure you have auto sync enabled. This apply for the hour and time zone, just set them both to auto. Open a cmd window as admin (shift+right click on windows start logo on windows 10), or search for cmd and right click the icon-run as admin. Once you get on cmd as admin use this commands:

net stop w32time

w32tm /config /syncfromflags:manual /manualpeerlist:0.pool.ntp.org

w32tm /config /reliable:yes

net start w32time

w32tm /resync /rediscover

Each line is a command (press enter after each command ofc).

If you feel like some old Window users, you can restart your PC after fixing the hour. At this point, its fixed already.

Those commands are intented to synchronize your local host hour from ntp public servers (you can use 0,1,2 or 3.pool.ntp.org).

There is a common issue with Windows time not being synchronized in a precise way, making some apps to malfunction (Some real time software like monero daemon is one of them). This is not Wallet-Gui-related, instead is a common issue with Windows.

After that, you can use your wallet-gui and synchronize your monero node the usual way, waiting for it to sync the blckchain (if its the case that you actually have problems with your blockchain sync). If the blockchain doesnt sync after a while, close gui and follow this guide I am using the GUI and my daemon doesn't start anymore After you have done that, open wallet-gui again, and this time it will sync the proper way. Note that if you fail when using the guide above and decide to delete "data.mdb" you will have to wait for it to download the entire blockchain data again.

If you read this before using wallet-gui for the first time, you dont have to delete anything. Just fix the hour issue before running your node.

Remember that your wallet its saved in the directory you pointed it when ran wallet-gui the first time. The content of that folder its your wallet data, make a backup of it, the seed and pasword too.

I have done this before using full nodes (ETH-mist and UBIQ-Fusion) and have been able to avoid some issues with blockchain sync. If you follow the steps above, you will have less issues when connecting to peers, hence the blockchain data will be less susceptible to get corrupted.

wallet-cli users: remember to close the daemon properly (in the cli write "exit" when you finish using it) to help avoid issues too.

That's it. I hope this helps the ppl having issues with blockchain data and/or wallet-node sync.

P.S. This is a monero-adapted guide of a post made by myself about UBQ-Fusion wallet in the UBQ reddit.

This works on any Windows version, not just Windows 10. Kind regards...


Different MLSAG implementations across papers

On Zero to Monero page 43, each key vector in the ring signed by RCTTypeFull consists of public keys for each input, followed by a public key which is the sum of output commitments minus the sum of input commitments.

MRL0005 on page 9 describes almost the same thing, except the public keys for each input are followed by the sum of public keys for those inputs plus the sum of output commitments minus the sum of input commitments.

Since Monero has implemented the Zero to Monero version and not the MRL0005 version, it has been deemed overkill to include the input public keys twice.

This is because the way that challenges (the c-value hashes) work in the MLSAG ring signature forces it to be the case that for one ring key vector, all private keys for all public keys are known.

Thus it could not be the case that the signer has knowledge of the private keys for the inputs but not also the private keys (a.k.a masks a.k.a blinding factors) corresponding to the commitments of those same inputs.


How much larger are Monero transactions compared to the average Bitcoin transaction?

Most non coinbase Monero transactions are currently around 2,000 bytes (but with significant variation) which is somewhere in the neighborhood of 8 times larger than most Bitcoin non coinbase transactions.

The reason why RingCT should help eliminate the need for extremely large Monero transactions is that RIngCT no longer will require the use of outputs of many different denominations.


Monero GUI connected to remote node takes long time to sync

You first described connecting to a remote node, and your description sounds correct enough.  But the output you provided indicates (a) that you're connecting through your loopback IP, meaning you're not using a remote node, and (b) the daemon is downloading the blockchain, which definitely may take a while (a few hours if you're extremely lucky, to a few days if you're unlucky).


When receiving funds, does the recipient know the address of the sender?

No. Ring signatures provide sender privacy, stealth addresses provide receiver privacy and Confidential Transactions hide the amount being sent. Nobody's wallet address appears on-chain.


The Monero team recently added a tool that makes it easy to integrate Monero RPC with Python. It can connect to running daemon and wallet and exposes their RPC interfaces:

The following command will connect to a monerod running on mainnet on default settings:

utils/python-rpc/console 18081

You'll get this output:

Variable 'daemon' connected to daemon RPC on 127.0.0.1:18081
>>>

You're now in a python interpreter, and the daemon variable is set to an object which can call daemon RPC directly, eg:

>>> daemon.get_version()
{u'status': u'OK', u'untrusted': False, u'version': 131078}
>>>

For the use case above (retrieving 21 nonce values from the blockchain from height 1000):

>>> [x.nonce for x in daemon.getblockheadersrange(1000, 1020).headers]
[3419004817, 3320605335, 295465941, 3696734864, 2221411748, 2201153093, 148086550, 524920481, 1766174771, 1831485859, 2409397405, 804573540, 535538542, 1487558207, 3340140970, 4029873826, 3890252333, 586366003, 1681558754, 1323530723, 240084243]
>>>

You can also connect the console to several processes, daemon and wallet, so you can interact with both from the same interpreter. The console will detect whether it's connecting to a node or a wallet, and will create the RPC proxy objects as daemon or wallet accordingly. If you connect to more than one demon or more than one wallet, the RPC objects will be daemons and/or wallets arrays instead of single variables. For instance, if you have a wallet running on port 8080:

$ utils/python-rpc/console 18081 8080
Variable 'daemon' connected to daemon RPC on 127.0.0.1:18081
Variable 'wallet' connected to wallet RPC on 127.0.0.1:8080
>>>

The console tool accepts full URLs if the daemon/wallet does not run on 127.0.0.1.

To use that framework in other Python programs, you should import the module(s) you need:

from framework.daemon import Daemon
from framework.wallet import Wallet


Two functions in Mininero to derive Monero address from hexadecimal seed?

MM is probably an abbreviation for MyMonero. Note that, in comparison with the standard private view key, the private view key of MyMonero accounts are derived differently. That is:

  MyMonero Style – This is similar to 2., but uses a 13 word seed instead of a 25 word seed. The 13 words convert to a 128-bit integer that is used for both spend and view key derivation, in the following form: the 128-bit integer is hashed with Keccak-256 to produce a 256-bit integer, a. a is sent to sc_reduce32, which returns the Private Spend Key. a is hashed once more with Keccak-256 to produce a second 256-bit integer, b. b is then sent to sc_reduce32, which returns the Private View Key. You may have noticed a critical difference between this style and the Electrum Style: MyMonero's Private View Key derivation is done by hashing random integer a, while Electrum Style derivation is done by hashing the Private Spend Key. This means that 13 and 25 word seeds are not compatible – it is not possible to create an Electrum Style seed (and account) that matches a MyMonero Style seed (and account) or vice versa; the view keypair will always be different. You can test out this style above with the "Random MyMonero" button. To backup MyMonero accounts, save the 13 word seed; you can currently "restore" using MyMonero only (you're really just logging in) – Simplewallet does not currently support 13-word seeds.

Hence, MiniNero uses two different functions to derive Monero addresses. Lastly, note that simplewallet was renamed to monero-wallet-cli.

Additional reading:

Why are Monero addresses so long?


Failed to import outputs: Transaction extra has unsupported format at index 17

It should be fixed one this PR is merged: https://github.com/monero-project/monero/pull/3065


Where and how to start to understand Monero?

I think that, at this time, the best starting point to learn all about Monero is Mastering Monero: The future of private transactions. The book covers all the aspects behind Monero and gives you all the useful things to understand Monero.

As stated:

  This book contains everything you need to know to start using Monero
  in your business or day-to-day life, even if you've never understood
  or interacted with cryptocurrencies before.

Apart from that, you can find a lot of useful resources on the web and you can start reading the resources section on the official getmonero.org website.


Pregenerate 1000 subaddresses from your monero private key?

Is there a way to pre-generate 1000 subaddresses from your monero private key?

Generating subaddresses from a private view key explained in this answer and on the monerodocs site here.

  And then say I sent some xmr to the 979th subaddress, would the wallet see it or do I need to do something first?

The default wallet lookahead indices are set to 50:200 (50 accounts, 200 subaddresses). So if you are creating the subaddresses outside of the wallet (so manually constructing them from the wallet private view key), you will need to tell the wallet about them. You can do this in the monero-wallet-cli via the set command: set subaddress-lookahead 50:1000


Is there any documentation for json rpc methods for supportxmr pool?

I believe that all API methods/calls for that pool (and all Monero pools based on nodejs-pool) are documented here: https://cryptonote-pool-api.restlet.io.


How was the generator H for the RingCT scheme chosen?

H can be verified by seeing how it's computed in the unit tests:

key G = scalarmultBase(d2h(1));
key H = hashToPointSimple(G);

When conducting the Bulletproof audit, the QuarksLab team dug into the verification of H also and documented this in section 4.3.4 (pages 15 and 16) of their report.


It might work. Edit: As per hyc's comment, it will work fine.

You can safely try as it would properly trigger an error.

Here is a detailled answer.


Questions regarding Monero wallet keys file, RPC transfer method, fee estimate and account index

The keys file is binary data. It's actually a json string that is encrypted with your wallet password.
Whenever you create a new wallet, it always starts with a single account (account index 0), with a single main address (subaddress index 0).
The wallet RPC only operates with one wallet at a time, so once you have opened a wallet, the keys are loaded and you do not need to specify any key to perform a transfer. query_key is used for other purposes, not transfers.
Call transfer with do_not_relay:true and get_tx_metadata:true. This will respond with the fee in the result object and the tx data you can then use with the relay_tx method.
The wallet that gets used is the one you started the monero-wallet-rpc with or the wallet
file you opened with open_wallet. Specifying account_index:0 when doing a transfer, instructs the transfer to send from the first (main) account of the currently opened wallet.


I suspect that node-cryptonote-pool, that moneropool.com and other mining pools run on, averages your hash rate over too short a time window. If I'm reading the source code correctly, the default is 600 seconds (10 minutes).

(The reason can also be your shares are not accepted. However, that is easy to check in the output of most mining software.)

I calculate my own average of submitted work every hour instead. That produces a number that fluctuates some ±20% compared to the numbers my workers report. I run on 50 cores, + 1 GPU.

These sites have an API where you can poll your own stats. The raw numbers for your own wallet can be extracted via:

https://api.moneropool.com/stats_address?longpool=false&address=[WalletID]

It returns something like:

{
    "stats":{
        "hashes":"841291891",
        "lastShare":"1495972253",
        "balance":"2499455408",
        "paid":"500000000000"
    },
    "payments":[]
}

If you poll every hour, subtract the numbers for accepted hashes compared to last time, and divide by the difference in time, you can calculate your own numbers with a simple python script.


How to set up Monero GUI wallet + Trezor on Tails

You shouldn't need the Bridge as that is for browser <=> USB communication.
It is supposed to work out of the box. If it doesn't, you probably need udev rules setup so the OS can see the device: https://wiki.trezor.io/Udev_rules -- note, if you want these to persist, you need to specially configure that (or copy them each reboot)
Tails sends all traffic over Tor, so I believe (may be wrong) no port config should be needed.  You will probably need to run with torsocks however. This might be helpful: https://garlicgambit.wordpress.com/2017/01/15/monero-how-to-connect-wallet-to-tor-onion-service-node/


Does the network benefit more from a local full node than through a VPS?

A VPS would likely have more uptime than a personal computer.  Also, if you were running a business to accept Monero, you could scale up your capabilities.
You would also not use any local bandwidth with a VPS.

As to node efficiency, there would be no difference between a VPS and a local installation.


Why does mining generate new coins on a fresh testnet?

the miner, who found the block, will be rewarded with some Moneros, in the expenses of the sender.

That also happens, and it is called a transaction fee. Transaction fees are small: 0.002 XMR (per output, or Kb, I am not sure).

On the other hand, what you are observing is the block reward of about 10 XMR per block found which seems wasteful at first glance, but that is what is known as proof of work, and it is what allows decentralization to happen. The point being: the network wants to maintain the integrity of the record of transactions known as blockchain, but if people can edit it at will that is not possible. So the solution, which was Satoshi's real stroke of genius was to create this block reward which works as a lottery in which your chances of winning are proportional to the resources you have invested (hardware plus electricity). The end effect is that it is hard for any agent to get the privilege of editing the blockchain, while at the same time aligning their interests with that of the network, since they only get the reward if they edit the blockchain according to the rules, and also the very coins they get in return derive their value from the integrity of the blockchain, which therefore they should work to protect. It is circular, I know, but it works for bootstrapping currencies.

It is worth noting that those moneros that the miner gets therefore are not "free" since they have to win the lottery, but yes, that is the cost we pay to secure the network. It might seem wasteful, until one notices that physical security of a bank, for example, also cost a lot: building the vault, paying the guards, setting up alarm systems, securing their own networks and databases etc. So when talking about costs it is important to ask: "compared to what?"


Typically when you 'join' an exchange, everyone's coin is in a single address/wallet run/owned by the exchange.  The payment ID is a way to keep records of who owns what.  Kinda like a sub wallet. Or your account number.
The exchange should give you a payment ID to use for the transfer.


Are there any test input and output vectors for the variant 4 PoW of Monero out there?

There are test vectors for CNv4 in https://github.com/monero-project/monero/blob/release-v0.13/tests/hash/tests-slow-4.txt


How to synchronize the GUI wallet using the blockchain bootstrap

I have a working Monero (internal) node running on a 2010 Mac mini with 8 GB RAM and a slow 5400 rpm disk (which is the bottleneck I have read), so probably quite similar specs as your 2008 MacBook.

If you've installed the GUI in the Applications folder, then you should be able to import that raw blockchain into the daemon's LMDB database with the commands below.

However, you'll need to open the Terminal for that. Once in there, I suggest you first remove any failed earlier attempt, and then start the import:

# Clean-up first.
rm -r ~/.bitmonero

# Import the file.
/Applications/monero-wallet-gui.app/Contents/MacOS/monero-blockchain-import --input-file ~/Downloads/blockchain.raw --verify 0 --database lmdb#fastest

Note that this import took about 10 hours on my system. You'll end up with a ± 11 GB data.mdb file in the directory ~/.bitmonero/data.

Once that is complete, you can restart the GUI and the daemon. Hopefully, it should be able to continue for the last few blocks since the blockchain snapshot was made, and stay up-to-date.


Help needed after best friends death to retrieve wallet

You can recover a wallet with just the mnemonic seed. This should help: How can I recover a wallet using the mnemonic seed?


After bulletproofs upgrade, is scanning of the blocks faster for a balance update?

It greatly speeds up scanning of newer blocks that use bulletproofs. It does not speed up the scanning of the existing blocks if you're refreshing your wallet from scratch.


What is the rationale behind keeping transactions in the mempool longer after they were in an orphaned block?

Based on current transaction volume (and a small reorg) there does not appear to be a need for a 7 day period for such transaction (because they can be confirmed much faster.

However if transaction volumes suddenly much higher (before the dynamic block size limit can fully adjust) and if the reorg was substantial (very large pools of transactions being moved to the mempool) then more than one day might be needed for confirmation.


Your daemon may have crash or been out of sync.
Considering the two month you mention, you should download the last 0.12.2 GUI from the website which solves a bunch of problems with the daemon.


What is OpenAlias and what is its relation to Monero?

OpenAlias is an alasing system designed to map a domain name to a cryptocurrency address, so that it becomes possible to use those user friendly domain names as addresses.

The basic idea is that domain names are easy for people to remember and map to a particular person/entity. A DNS TXT record (a particular type of data attached to the registration data for a domain) is used to advertise a set of cryptocurrency addresses. A wallet implementing OpenAlias (eg, Monero's simplewallet) will lookup that domain name, find the TXT record, and see the Monero address in it.

The advantages of the DNS route are:
- more user friendly than raw addresses
- registration does not need a blockchain transaction like, for instance, Boolberry's alias system
- prevents "spammy" registration (ie, someone goes and register every single first name)
- support for DNSSEC for authentication and privacy
- an alias can be discontinued or changed
- cross blockchain (ie, you can set up a TXT record with both monero and bitcoin addresses)

Currently, OpenAlias is implemented for Monero (it was originally designed by the Monero team) and Bitcoin (in Electrum). However, it is not intrisically limited to those and could be easily implemented by other currencies.

If you do not have a domain, and cannot add a TXT record to a domain directly, you can apply to an OA service, which allocate you a hostname and associated TXT record. There were two in the past (xmr.link and another I can't recall), but I think they're both inoperative. Maybe a business opportunity ?

See http://openalias.org/ for details.


add_address_book does not save after closing wallet

Okay, so I found the problem. It was because when I close the wallet, I need to issue the stop wallet command before I close the wallet, otherwise the cache is not saved. https://getmonero.org/resources/developer-guides/wallet-rpc.html#stop_wallet


Can someone suggest a better way to test transfers for development testing?

You need to run a private testnet. Instructions can be found here: https://github.com/moneroexamples/private-testnet

Without it being private, your mined blocks wont make it onto the real testnet chain because you are mining with a lowered difficulty due to you using the --fixed-difficulty 10 option, and they wont get broadcast due to you using the --offline flag.

Follow the instructions linked above and you'll have a private testnet to play/test with.


MyMonero wallet compatible with CPUminer/MinerGate

So I think your username (-u) will be your MyMonero wallet address instead of your minergate registered email address. As far as im aware thats how it works with XMRig and Castxmr, don't see why it would be different for CPUminer


Is there a tool that tells me if my transfer has been used by others in a ring signature?

You can search the blockchain for your outputs with a given address and view key, but I'm not sure if you can actually determine if a given output has been used in other transactions.

Here are some useful tools.

lmdbcpp-monero
transactions-export


How can I validate a cryptonight algorithm implementation?

The Monero blockchain is full of test cases: for every block, you can assemble the hashing blob for that block, hash it with your new implementation, and check the resulting hash is below the target for that block. This will be done automatically if you replace monerod's Cryptonight implementation with your own, and try to sync the chain from scratch.

Another way is to replace a pool miner's Cryptonight code with your own, and try to mine. For example, https://github.com/OhGodAPet/cpuminer-multi/


COMMAND_TIMED_SYNC invoke failed - Not Syncing, how to fix it?

I exported the blockchain from another node I have and imported to the failing node. Seems to have fixed the issue and it is now syncing and up to date.


How to configure my computer to mine when not in use in Windows?

That's easy on a windows machine by adding it as a windows-service and the solution can be tailored for different systems.


Why can't a pool find block after the hard fork

Check your pool logs for "Error submitting block". That's in logs/pool-info.log. If one of those shows up, then a miner found a share matching network difficulty, but the block was rejected.

Then check the same log file for "found at height". If you find any, but your pool did not get the block, then the block got orphaned. This may be due to bad luck (someone else found a block at about the same time), or because your block was invalid, and the network rejected it.

If you find none of those messages, it means you (as in, the miners mining on that pool) were just unlucky.


How do the Monero nodes find each other?

There is a default set of nodes in the monero source code that it will attempt to use. These default nodes are used to bootstrap the list of peers your node will connect to initially. Nodes are able to request a list of peers from the other nodes they are connected to, which produces a large set pretty quickly. This is helpful to let you get a node up and running very quickly without the daemon having to scan all IP addresses.

However, once the peerlist has been pulled from the default list it can connect to any other known node. In this sense, the initial node list is actually centralized in the monero daemon, but only at first. To see this in action use the print_pl command in the daemon. It will print out a big list of all the peers your node knows about.

For those who are paranoid about the origin of the list, you can use the monero daemon --add-peer (or --add-exclusive-node during your first sync) to add some nodes to your local peerlist manually. You can also try out the --seed-node parameter, which just connects to a node and pulls its peer addresses.


Can someone show me how to hash with CryptoNight in Python?

I'm assuming this is a follow-up question to your previous question.

Here is an example that shows how to hash a block hashing blob with a supplied nonce:

import binascii
import pycryptonight
import struct

bhb = binascii.unhexlify("070786a498d705f8dc58791266179087907a2ff4cd883615216749b97d2f12173171c725a6f84a00000000fc751ea4a94c2f840751eaa36138eee66dda15ef554e7d6594395827994e31da10")
nonce = 1234
bin = struct.pack('39B', *bytearray(bhb[:39]))
bin += struct.pack('I', nonce)
bin += struct.pack('{}B'.format(len(bhb)-43), *bytearray(bhb[43:]))
hash = pycryptonight.cn_slow_hash(bin, 2)
print(binascii.hexlify(hash))

Where bhb is the binary of a blockhashing_blob as returned from a call to get_block_template, and nonce is your nonce for this particular hash.

To create a miner, follow the steps in my answer to your other question.


Is my hot wallet the only view wallet and my cold wallet the one created offline?

Yes, your view wallet is hot, but that is safe. Even if someone gains access to your computer, he can not steal any funds because the view wallet doesn't store your secret spend key (which you have written on the paper backup).

Cold wallet with the spend key doesn't have to be a different computer. You could use the same physical computer, and boot from some USB Linux system to act as a safe, clean, cold machine. what's important is that you never expose the secret spend key to a potentially-compromised PC. When you're booting into a fresh Linux system which will be used only for your cold-wallet stuff and never be connected to Internet - any risk is minimized.

You could even use Windows console, but maybe it's not so user-friendly. Here's an exampe how to use monero-wallet-cli with Windows pre-install environment.


Why would you need multiple daemons using one LMDB database?

The use case I had in mind when I wrote this code is to run daemons on different network interfaces, or on different network protocols, using the same database. E.g., if you want to use different bandwidth limits on one interface vs another, or if you want to run a daemon on TOR simultaneously with a daemon on clearnet. Or, you want to run a public node (with --restricted-rpc) and also want to run a daemon that mines at the same time.

You can run as many daemons as you want on the same database without the DB taking up any additional memory.


Why does Monero use epee in the crypto module?

It may help to first understand that CryptoNote is a protocol and that the crypto module contains cryptographic primitives.

public_key, secret_key, key_derivation, key_image, signature... these are all cryptographic primitives, hence they are all correctly in the crypto module, as are the hashing functions.

The reason for the output stream functions being in the crypto module and not CryptoNote is that they are not CryptoNote specific. They provide a way to output the primitives to a stream (encoded as hex).


It could be two things.

Your firewall is blocking the daemon from working. Try allowing a new firewall for monerod.exe

There is something that is using port 18080. If you know what program uses this port, close it before starting monerod.exe


Is the Monero blockchain database portable between 32 and 64 bit architectures, and little/big endian architectures?

In general, LMDB files are architecture-dependent and cannot be moved between different architectures.

In Monero, all LMDB structures are 64-bit clean, so the files are portable between 32 and 64 bit architectures. But they are still endian-dependent, and are not portable across endianness. This hasn't been a concern since the two dominant architectures today, x86 and ARM, both use little-endian integers.

Note that, while LMDB also supports concurrent access across multiple processes, Linux glibc has a design flaw such that interprocess mutexes are different sizes in 32 bit processes vs 64 bit processes. So LMDB files on Linux cannot be concurrently shared between processes of different sizes. This flaw does not exist on other platforms (like e.g. BSD or Windows).


Your wallet restore height (2271489) is above the height of your transaction (2270830). You therefore need to change the restore height to force a rescan from before the height the transaction occurred. See this answer.


How hard is it to find the originating IP of a monero transaction (pre Kovri)?

It's the same as in Bitcoin. You have to connect to a large amount of nodes, and see which node you first heat about that tx first. Then this node is either the originator, or "closer" to the originator than the ohter nodes you're connected to. "closer" here means closer in relay time, wihch depends on internet connection speeds, etc.


If you create a coin, people will mine it. Once they mine it, they will get coins as a reward. You then have to negotiate with exchanges to list your coin or in a best case scenario they will list the coin for free.

After they list the coin, people can buy / sell them.


What is a "[P2P0]WARNING: no two valid MoneroPulse DNS checkpoint records were received" warning?

This was explained by Fluffypony on Reddit:

It says "warning", so it's not an error, it's just a notice:)
MoneroPulse is informational only, unless you're running an unmanaged node and you've thus set the flag to explicitly follow MoneroPulse checkpoints. Currently there are three things to note with MoneroPulse:

moneropulse.co is having issues, it's in the process of being moved to a different registrar. BUT moneropulse.org, moneropulse.net, and moneropulse.se are all fine and pass DNSSEC validation, so finding 2 working ones is not that hard.

We're having issues with our baked-in root trust anchor for systems that don't have trust anchors. You may have noticed a message on startup complaining about "unsupported algorithm for trust anchor . DNSKEY IN" - we have a new format for the baked-in anchor that should fix this, but it's not part of 0.9 or 0.9.1.

Even if 1 and 2 are perfect and resolved there are some ISPs that run DNS servers that don't acknowledge the +dnssec flag when making requests, so there are some environments where you're never going to get a valid MoneroPulse response. That's why MoneroPulse is just informational only:)


How significant is the number of threads when mining? (I7-4790K)

The correct answer is a combination of what you've read. The maximum number of threads you should ever try to use is the number of CPU cores. Each thread uses 2MB of RAM, so your best performance per-thread will be if you only use your cache size divided by 2MB. In your case, it appears that you get the same answer, 4 threads, either way.

Yes, the monerod will occasionally need to crunch thru 2MB as well when it validates incoming blocks. And it will consume bandwidth when relaying transactions and blocks to other nodes. So that will have some impact on your performance.


In addition to the Cryptonote whitepaper jtgrassie linked, there is a paper explaining Monero at https://github.com/UkoeHB/Monero-RCT-report


goxed from bitcointalk  has a fork of that repo that fixed the clang issues and works for me on macOS10.12. Here's what I did to use it without the formula:

brew install automake autoconf libtool curl jansson
brew link curl --force
git clone git://github.com/goxed/cpuminer-multi;cd cpuminer-multi
./autogen.sh
perl ./nomacro.pl
./configure CFLAGS="-march=native -mtune=native -maes"
make

Edit: since the wolf9466 repo has seen a few changes since the goxed version was forked, I just tried making the same Makefile.am changes that goxed did to the current wolf9466 repo, and that also works.


Dual (merged) mining (no additional hashpower) by guessing?

Tari university has a great explanation about what merge mining is here. I strongly recommend you to read it.


Why did Monero choose LMDB over alternative database types?

I wasn't around when the decision to use LMDB was made, but I can present some obvious reasons why such a decision makes sense:

1) at the time they made their decision, there were only 2 embedded key value stores out there with ACID transaction support: BerkeleyDB and LMDB. (RocksDB has recently added it. I haven't tested it to see if it's actually usable. Given that LevelDB has been plagued with bugs even in their snapshot isolation, I wouldn't expect much from RocksDB.)

2) for something with real monetary value, you really don't want a DB that can irrecoverably lose your data. This is something all the LevelDB-using cryptos still don't seem to understand. If it doesn't do real ACID then it's a non-starter.

3) between the only viable choices of BerkeleyDB and LMDB, LMDB is obviously smaller/faster/more reliable. Faced with a lack of 32bit LMDB support, the Monero team adopted both.

4) As key/value stores go, and ignoring ACID for the moment, LMDB offers a number of features that other k/v stores lack, which boosts its efficiency in a cryptocurrency use case. E.g. support for native integer keys, keys with multiple values, fast bulk loading/importing, etc.

Here are some IRC transcripts from the time the choice of DB was being made. It gives you insight into the range of solutions and what factors were considered:

[2014-06-02T16:40:55+0200] <@fluffyp> tacotime: have you ever played with
  hamsterdb?
[2014-06-02T16:41:19+0200] <@tacotime> nope
[2014-06-02T16:41:46+0200] <@tacotime> but i don't wanna mess with any java
  db systems
[2014-06-02T16:42:02+0200] <@fluffyp> tacotime: not java
[2014-06-02T16:42:06+0200] <@fluffyp> c/c++ embedded db
[2014-06-02T16:42:09+0200] <@tacotime> ah okay
[2014-06-02T16:42:13+0200] <@fluffyp> looks like it outperforms leveldb
[2014-06-02T16:42:19+0200] <@fluffyp> has an open source community edition
[2014-06-02T16:42:22+0200] <@tacotime> i wouldn't be surprised
[2014-06-02T16:42:28+0200] <@tacotime> how mature is the software though?
[2014-06-02T16:42:49+0200] <@tacotime> something slow and bugfree is
  better than something fast and buggy when it comes to financial software
[2014-06-02T16:43:09+0200] <@fluffyp> this has been around for years
[2014-06-02T16:43:12+0200] <@fluffyp> since 2010 or so
[2014-06-02T16:44:45+0200] <@tacotime> yeah
[2014-06-02T16:44:54+0200] <@tacotime> a lot of people are using mongodb
  now i feel like
[2014-06-02T16:45:03+0200] <@tacotime> i'm kinda curious about tokumx too
[2014-06-02T16:45:14+0200] <@fluffyp> there's no embeddable version of mongo
  is there?
[2014-06-02T16:45:25+0200] <@tacotime> i don't think so :/
[2014-06-02T16:45:32+0200] <@tacotime> i'm going through the btcdb stuff right
  now and seeing how a db is implemented too
[2014-06-02T16:45:51+0200] <@tacotime> https://github.com/conformal/btcdb
[2014-06-02T16:46:01+0200] <@tacotime> that's a good example of how to do it
  the quick and easy way in go
[2014-06-02T16:47:12+0200] <@tacotime> if you want a fast db you still need to
  keep a lot of the most recent blocks in memory, though
[2014-06-02T16:47:14+0200] <@fluffyp> tacotime: I'm talking about the embedded
  blockchain keyvalue store - one of the devs I was talking to suggested
  hamsterdb over leveldb because it's faster whilst remaining significantly
  robust
[2014-06-02T16:47:26+0200] <@tacotime> and have to be careful with atomicity
[2014-06-02T16:47:28+0200] <@tacotime> ah, ok
[2014-06-02T16:47:37+0200] <@fluffyp> sorry should've clarified that :-P
[2014-06-02T16:47:49+0200] <@tacotime> I think we're talking about the
  same thing
[2014-06-02T16:47:56+0200] <@tacotime> https://github.com/conformal/btcdb/blob/
  master/ldb/leveldb.go
[2014-06-02T16:48:19+0200] <@tacotime> writing an easy keystore like that
  isn't too cluttered and timeconsuming
[2014-06-02T16:48:52+0200] <@tacotime> but regardless of whether you use
  hamsterdb or leveldb, it'll get slow fast if you aren't on an ssd for monero
[2014-06-02T16:48:58+0200] <@fluffyp> yep

And following up a week later:

[2014-06-09T15:55:19+0200] <pen> What is the selected embedded database for
  Monero? I pointed crypto_zoidberg to Sophia. Just wondered about Monero's
  dev choice
[2014-06-09T15:55:44+0200] <@fluffypony> pen: we're still deciding
[2014-06-09T15:57:09+0200] <@fluffypony> if we abstract it properly then embedded
  database choice becomes an academic exercise (i.e.. which one is best for our
  workloads)
[2014-06-09T15:58:25+0200] <pen> leveldb may be a safe choice. However, leveldb
  is not the fast one out there. Let see if BBR dev choice is. I expect that it
  would be LMDB or Sophia
[2014-06-09T15:58:25+0200] <@fluffypony> so many options between kyotocabinet /
  sparkey / tokutek / hamsterdb / hyperdex / symas lmdb / sophia / and tons of
  leveldb forks
[2014-06-09T15:59:40+0200] <pen> hyperdex is not an embeded one. Actually
  hyperdex devs improve leveldb in term of write scalability in a fork
[2014-06-09T15:59:57+0200] <pen> sophia and lmdb are not leveldb forks
[2014-06-09T16:00:17+0200] <pen> sophia is the db that powers Tarantool
[2014-06-09T16:00:25+0200] <othe> mongodb has the best name, i vote for that
[2014-06-09T16:00:44+0200] <@fluffypony> pen: I wasn't implying those are all
  leveldb forks :)
[2014-06-09T16:01:44+0200] <@fluffypony> hyperdex has an embedded db -
  HyperLevelDB (unsurprisingly a leveldb fork)
[2014-06-09T16:02:26+0200] <pen> @othe mongodb is so hyped. And it is not
  designed for an embedded one
[2014-06-09T16:02:34+0200] <@fluffypony> pen: he was just trolling you

My first contact with the Monero project came two months later:

[2014-08-07T11:34:25] fluffypony: heya
[2014-08-07T11:34:32] fluffypony: plz ping me when you're around
[2014-08-07T11:34:48] hyc: what's up?
[2014-08-07T11:34:54] fluffypony: lol that was fast
[2014-08-07T11:35:00] fluffypony: hokay so
[2014-08-07T11:35:04] fluffypony: LMDB
[2014-08-07T11:35:28] fluffypony: how often do you push from the main openldap
  branch to the lmdb gitorious branch?
[2014-08-07T11:35:47] fluffypony: ie. should I be pulling it from the openldb mdb
  branch instead of there?
[2014-08-07T11:36:31] hyc: we normally push simultaneously
[2014-08-07T11:36:55] fluffypony: ok great
[2014-08-07T11:37:06] fluffypony: I'm one of the core team members on Monero, a
  cryptocurrency (not based on Bitcoin)
[2014-08-07T11:37:16] hyc: you can pull from whichever you like. some folks
  complained that they had to pull the entire openldap git repo just to get LMDB,
  so we set up gitorious
[2014-08-07T11:37:19] fluffypony: and we're in the process of moving from a flat
  file in RAM for the blockchain to an embedded DB
[2014-08-07T11:37:27] fluffypony: and I'm DEAD keen on lmdb
[2014-08-07T11:37:35] fluffypony: as it appears it will be most performant for
  our workload
[2014-08-07T11:37:38] hyc: sounds good
[2014-08-07T11:37:48] fluffypony: and it will provide scalability for larger
  instances
[2014-08-07T11:39:06] hyc: yep
[2014-08-07T11:39:29] hyc: and unlike other embedded DBs, it will never corrupt
  or lose your data...
[2014-08-07T11:39:38] fluffypony: yeah and that's the appeal
[2014-08-07T11:39:49] fluffypony: in a distributed consensus system you really
  want to have solid data on-disk
[2014-08-07T11:39:55] fluffypony: because peers are reliant on that
[2014-08-07T11:40:00] hyc: absolutely


What sort of deanonimization attack could someone controlling the majority of nodes pull off?

In the era of Docker containers and how easy it is to spin up potentially thousands of nodes in a minute,

I wouldn't agree it's as easy as you allude to. Each node needs to use a blockchain (storage) and sync (bandwidth). Thus costs and effort are not as negligible as may seem.

  what kind of attack could some malicious actor pull off if they performed this?

Transaction censoring, linking transactions to IP addresses, selfish mining, forking the network... all sorts of mischief becomes possible if one controls a majority of the network. In practice it's far from simple however.

  Would Dandelion fail, assuming a single entity could temporarily be the link between the majority of nodes?

That's getting a bit specific to a generalized problem. If a single entity controls a majority of the network, Dandelion or not, linkage is going to be one of the possible attacks we'd face.

  Would remote nodes become very risky, as these nodes could all serve malicious blockchain info?

Using a public (which is what I assume you are referring to) remote node is always "risky". You are trusting that the remote node operator is not logging your IP and times you are transacting. You are trusting their view of the blockchain they serve you. So if you're inclined to use (and trust) random unknown nodes now, of course it becomes more risky if there are more malicious nodes.

  Would different attacks be possible depending on the % of malicious nodes run, i.e. 50%, 75%, or 90%?

Without you defining a specific attack, in general, any eclipse style attack becomes more effective the more of the network is controlled.


The GUI uses all my bandwidth and I can't browse anymore or use another application that requires internet connection

monerod 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:

Go to the Settings page of the GUI.
Look for the daemon startup flags box.
Add this line -> --limit-rate 500
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 --limit-rate 500 will limit the bandwidth to 500 kB/s. Note that you can tweak the parameter / flag yourself by adjusting the value.


You cannot view amounts, and thus check your balance, with just a transaction hash. Amounts on the Monero blockchain are encrypted.

What you will need to do is take your paper wallet and restore either a full or view-only wallet using the seed words printed on your paper wallet. Then using the restored wallet you can scan the blockchain for incoming payments.

Refer to the guides: How to make a view-only wallet and Securely purchasing and storing Monero.


Can any CryptoNote coins be merge mined?

The Monero community almost unanimously voted against merged mining choosing instead to stand on its own and avoid indirectly supporting another CryptoNote coin, BCN that was 80% premined..

Actually voting is closed now as soon as nearly nobody wants merge mining in BMR

In hindsight measured by network hashrate, the Monero community made a wise decision. No other CryptoNote coin has close to the hashrate of Monero today.
The first CryptoNote coin to heavily advertise merged mining was FantomCoin. It is now largely abandoned with no major exchange listings.
FantomCoin can be merged mined with  Bytecoin's/QuazarCoin's with no hit to network has rate. Its creation appears to have been inspired by the Monero rejection of merged mining:

FCN thread comment: "I think there was no need of another fork just for MM"
TFT: "Community around BitMonero was completely against MM this time and we could not include it in BMR. Amphibian decided to deploy his work this way. MM at least doesn't consume additional energy"


Curve used in Monero - A Subgroup of Ed25519?

Building on Knaccc's answer.

Curve25519

The first step to build an Elliptic curve library is to define a field of prime characteristic. In this case, the field is 2^255 - 19, I denote this with K. In most eprints it is denoted as F_p.

We then define a curve over this field of prime characteristics. The curve that we define in this case is a Montgomery curve called Curve25519. Where the points on the curve are in K. Not every point is on the Montgomery curve, just like regular curves. It is only the set of points whose x and y value satisfy the curve equation. The set of points which are on the curve is defined as M(K). These points form a Group.

Comparing Curve25519 and Ed25519

First, they are both defined over the same prime field K. But Ed25519 has a different curve equation. We know that there is a Group of points which are on the Montgomery curve denoted M(K). So the question is whether, the Group of points on Ed25519 are the same points?

Lets denote the group of points on Ed25519 as E(K). There is a relationship between Curve25519 and Ed25519, it's called a birational equivalence: https://crypto.stackexchange.com/questions/43013/what-does-birational-equivalence-mean-in-a-cryptographic-context

The link above explains it very well, in short, there is a way to transform Curve25519 to look like Ed25519 except for a few points. These are called the exceptional points.

This means that M(K) and E(K) have roughly the same amount of points. The exceptional point, only comes up in the affine mapping, so can be avoided if we use projective.

In short, we can think of there being a mapping from M(K) to E(K). We are actually interested in E(K), but I mentioned Curve25519 first because Ed25519 came from it, in the relationship mentioned above.

Order of E(K)

The next question is "How many points are in the Group E(K)?"

There is paper by Craig Costello which says that the order must be even for both Edwards and Montgomery Curves.* In our case, the order is 8q. Where q is prime.

By lagranges theorem, E(K) can be decomposed into smaller groups which are multiples of its order. One group has has q points E_1(K) and the other group has 8 points E_2(K). This has been slightly simplified, see the link that knaccc posted above.

We are now looking at three groups E(K), E_1(K) and E_2(K).

Notice that the points in E_1(K) and E_2(K) are in E(K) since E_1(K) and E_2(K) are just decompositions of EK(). This means that E_1(K) and E_2(K) are subsets of E(K). We can go further and show that they are both subgroups.

Small subgroup

The points in E_2(K) have order 8. This means that if I take any point in E_2(K) and add it to itself 8 times, then I will arrive at a special point called the identity point. You can think of it as the zero point.

For example; if P \in E_2(K) then P + P + P + P + P + P + P + P = 0 . Instead of manually writing out the additions I could have equivalently written 8P = 0. This is known as scalar multiplication. In the case of 8P , 8 is the scalar.

The points in E_1(K) have order q. This means that in order to arrive at 0. You need to add the point to itself q times. ie if P \in E_1(K) then qP = 0.

The number 8 is small and all points in E_2(K) have an order of 8. We call this subgroup the small-order subgroup.

Contrasting, q is a prime and is large and all points in E_1(K) have an order of q. We call the subgroup E_1(K) the prime order subgroup.

E_1(K) and E_2(K)

So what's the problem? The problem is a mixture of two things:

We cannot force the user to use either E_1(K) or E_2(K). We have to assume that they have taken points from E(K).
You can mix points in E_1(K) and E_2(K) together.

Constructing the attack

Context: You are only allowed to use a point once. Using the point twice is analogous to double spending.

Goal: The attacker will attempt to use a point twice.

Pick a point in E_1(K). Lets call it P.
Pick 2 points in E_2(K). lets call them R_1 and R_2.
Compute T_1 = P + R_1 and compute T_2 = P + R_2.

The attacker tells Alice "T_1 is his point, you can use it to check on the blockchain when I make a payment."

The attacker tells Bob "T_2 is my point, you can use it to check on the blockchain when I make a payment".

These two points look different. But when we multiply it by a number that is a multiple of 8. We see that R_1 and R_2 disappear and the points become equivalent.

8 * T_1 = 8 (P + R_1) = 8 * P + 8 * R_1 = 8P + 0 = 8P.

As knaccc said above, whenever the scalar is a multiple of 8, the part that comes from E_2(K) disappears. So it looks like we have different points, but when multiplied by a multiple of 8, we can make the point be equivalent. This means that the attacker does not need to know the private key to T_1 or T_2. He just needs to sign with the private key for P.

This has lead to attacks as seen in this link : How does the recent patched key image exploit work in practice?

If I have not explained it well so far, essentially E_2(K) is bad and E_1(K) good!

Getting rid of E_2(K)

The way that Monero uses is called a subgroup check, and we essentially check if T_1 is in the prime subgroup, in our case this is E_1(K). To check if a point is in a specific subgroup, you multiply that point by the subgroup order and check if you get the identity (zero) point.

Let's take T_1 again and multiply it by the order of the prime subgroup.

q * T_1 = q (P + R_1) = q * P + q * R_1 = 0 + q*R_1 = qR_1.

If our point T_1 was in E_1(K), then it would have produced the identity. Since we did not arrive at the identity point, we know that this point has components in E_2(K).

This check is great and does what we want but it is also expensive to multiply by that large prime q. We must do this to every point we receive before running any verification procedure.

This check guarantees that a point is always in E_1(K). You can think of it as mapping E(K) -> E_1(K), where the order of E_1(K) is q.

What if we could build a group of order q from E(K)? This would also solve our problem. This is essentially what Ristretto does. You can think of it as E(K) -> 2E(K)/E[4] . Notice that it does not map to E_1(K). E_1(K) and 2E(K)/E[4] are groups of prime order, but they do not contain the same points. E_1(K) contains points which are in the prime order subgroup of E(K) while 2E(K)/E[4] contains points which form a prime order subgroup from E(K).

Ristretto

Ristretto is an extension on Decaf: https://www.shiftleft.org/papers/decaf/decaf.pdf

Above we alluded to the relationship between Curve25519 and Ed25519. There is another type of relationship that curves can have which we call an isogeny. In the Decaf paper, it cites a paper which shows that there is a family of curves whom are all isogenous to each other.

Furthermore, when we transform one curve to another curve, it can pick up a factor. For example, given two curves E' and E'' which are 2-isogenous, we have functions which maps points between E' and E'' and each map will double the corresponding point on the other curve. Here is a link to a test case for a 2-isogeny: https://github.com/cloudflare/circl/blob/master/ecc/goldilocks/isogeny_test.go#L21

The test in the link maps a point from E' to E'', then immediately maps the point back to E' . This means that the resulting point on E' will be 4 times the original point.

Decaf does not work outright for Ed25519, but it does for Curve25519, however since Curve25519 and Ed25519 are birationally equivalent. The formulas can be modified to map to Ed25519 through Curve25519. This is what Ristretto does along with  few other modifications: https://ristretto.group/details/isogenies.html#from-montgomery-to-edwards-via-isomorphism

So far, we have a family of curves, one of which is a Montgomery curve in our case Curve25519 and we have Ed25519 which can be mapped to, by any one of the family of curves through Curve25519. The only important curve in the family of curves worth mentioning is the Jacobi quartic curve. The Jacob curve is 2-isogenous to the Curve25519.

Encoding the point

Let's say I have a point P in E(K). Recap that E(K) is the group of points on the Ed25519 curve. First we use our birational map the point to Curve25519. So the point is now a point in M(K).

From the decaf paper, we know that there is a 2-isogeny from the Montgomery Curve to the Jacobi quartic. We apply this isogeny and our point is mapped to a point on the Jacobi quartic, but since it is a 2-isogeny it also picks up a factor of 2. If P was in the small-order subgroup E_2(K) then when we map it to the Jacobi quartic we would only need to double the corresponding Jacobi point twice in order to get the identity element.

What is the importance?

Instead of checking if our point is in the correct subgroup, our strategy will be to now group all points which differ by a point of order 4 and force an algorithm to output a specific point. All of the points which differ by a point of order 4 are exactly all of the points which were equivalent when we multiplied by a scalar which was a multiple of 8 in E_1(K).

To see this, let P \in E_1(K) and let R_1, R_2 \in E_2(K)

Compute T_1 = P + R_1 . When T is mapped to the Jacobi quartic, it picks up a factor of 2.

2 * T_1 = 2 * P + 2* R_1
2 * T_2 = 2 * P + 2* R_2

Notice that because R_1 was doubled, it is now an order of 4 away from the identity point. So T_1 and T_2 differ by a point of order 4, when we apply the isogeny to map it to the Jacobi quartic. Notice also that P + 0 also differs by a point of order 4 and is also in this group of point which differ by a point of order 4.

Why is this important?

The Jacobi quartic has a really succinct representation for all of it's points which differ by a point of order 2. But for this explanation, lets pretend it is by an order of 4, the logic still follows through. :https://ristretto.group/details/isogeny_encoding.html#encoding-mathcal-j--mathcal-j2

As the link mentions, it is possible to consistently pick one of the points in the set of points which differ by an order of 2(again lets pretend it says 4), by enforcing two sign checks. These two can be easily programmed into an algorithm.

Another example of a sign check, is when you are sending a point to another user. You take the Y co-ordinate and use a bit to denote the sign of the X co-ordinate. In this case, you are distinguishing between the negative and positive-ness if the X co-ordinate. This check is usually done on the Edwards curve Ed25519.

Contrasting, this check is computed on the Jacobi quartic curve, which is not the curve that we are doing arithmetic on. It is Ed25519. Fortunately, the encoding can be transported to Ed25519 https://ristretto.group/details/isogeny_encoding.html#transporting-an-encoding-along-an-isogeny

So we make our sign choices in the Jacobi quartic, then we transport these sign choices to the correct curve.

Summary

When you compress a point, you use a 2-isogeny to transport the point to the Jacobi quartic, picking up a factor of 2, you then make two sign choices which picks a specific point. When you decompress a point you check that these two checks are satisfied on the Jacobi quartic curve, which means that this point is the specific point out of all of the points which differ by a point of order 4. Then you transport the point to the Ed25519 curve.

Important Details

In the above sentence, I said specific point , I did not say a point that is in E_1(K). The point that we pick as a representative can be in E_2(K) , we just need to consistently pick the same point, which our sign check allows.

_Question: So If we can pick a point in E_2(K) , how does Ristretto solve the prime group problem?_

Ristretto does not force a point to be in E_1(K). It builds a prime order group from E(K). And it does this by always picking the same point out of the possible 8 equivalent points. This new Ristretto group will have prime order, because it is always picking 1 out of the 8 possible points.

Does this really solve the problem?

We can formulate the problem another way. Each Point in E(K) had 8 different equivalent points. No matter which one of these 8 equivalent points you give the Ristretto algorithm, it will give you exactly the same one. The other 7 points are no longer representable.
Caveat

There is are two security caveats. We are assuming that all points are passed through the Ristretto ENCODING algorithm.

If the points are modified at a later point, after going through the encoding algorithm. Then it is possible to simply change the representative point that was chosen.

This is why you must only add Ristretto points with Ristretto points. Ie only the representatives of the set of points should be used. You should never mix a RistrettoPoint with an EdwardsPoint, because the EdwardsPoint you are mixing with, may not be the representative for the set of possible points. This is mentioned in the IETF you linked, at the end I think.

Thing I have omitted or lied about

The Jacobi quartic actually has a succinct representation for points which differ by an order of 2, and Ristretto applies an extra step to transform the points which differ by an order of 4 to points which differ by an order of 2. This is explained in the torquing section, but is not important to understand most of Ristretto.

Hope that helps. If any mistakes are found, please feel free to correct them.


How can I recover XMR sent to my Reddit account with Tippero?

I think the only way would be to contact fluffypony or moneromooo on IRC and somehow prove that you were the owner of the reddit account holding the coins. I'm not sure how exactly you could do that if reddit was down at the time, but maybe they would be able to think of something. If they accepted that you were the reddit account owner, then shifting the coins to your IRC account would just be a matter of modifying a couple of database entries.


Will I/O speed or swap space effect the hashrate?

Your miner will ask the daemon for the next block blob and start hashing it until it finds a result that satisfies the difficulty.

In that process, only the daemon preparing the blob may use some hard drive and/or swap space.

But the mining process in itself is just a repeated computation that uses the CPU/GPU - your speed will mostly depend on the type of CPU/GPU, on the drivers and on the miner's configuration.

So improving I/O and/or swap space is unlikely to make any significant improvement, everything else being equal.

As to the Linux vs. Windows performance, it depends on your hardware, the distribution and the drivers you use. For CPU mining, I've sometimes noticed that Linux is marginally faster but for GPU mining Windows tends to fare better because of better GPU drivers.


As predicted by Clement and TEV in question comments, it turns out I already had another daemon running in the background that I was not aware of. The issue disappeared once I restarted my system and ran aeond again


Monero wallet stuck synchronising at 39680 using windows

If you're stuck on height 1400001, it's very likely you're using an old version which doesn't know about the new fork consensus rules, so fails to see the new blocks as valid. You need to update your wallet to 0.11.1.0 (0.11.0.0 would also work, but has a few sync bugs, so switching to 0.11.1.0 directly is best). Just replace the binaries with the new ones, or pull from git and build, that's all you need to do. After restarting monerod and wallet to use the new code, it should start syncing again till the end.


I just found the problem. Turns out the application tries to connect to the API on port 8443. And I was behind a firewall. Maybe it would be good if that info was on the site. Thanks anyway


What is the `~/log/dr-monero/net` directory?

Dr. Monero was a logging scheme that Rafal "rfree" Freeman created. It was meant to provide statistics and data useful for improving the wire protocol. Unfortunately it was never really completed, and just ended up creating a third logging sub-system.

We're in the process of removing all three logging sub-systems and replacing them with a single known-good library (instead of rolling our own), so this will eventually go away. In the meantime you can either ignore it, or remove it, but it'll be re-created.


Unrecognized TXN format, incorrect balance v0.13.0.4

I have a theory that I'm posting as an answer.

I think you clone and build monero yourself.  And I think you're using the same startup sequence to launch monero-wallet-gui as you did previously.  And I think what happened is you didn't realize that new builds are being put in a different directory hierarchy in the /build directory.  So when you launch monero-wallet-gui, your computer is using the PATH you previously set (build/release/bin), meaning you keep launching the old software.


chainradar doesn't show RingCT transaction fees (they are explicitly defined rather than sum(inputs) - sum(outputs), and they clearly haven't added support for that). Try http://moneroblocks.info/search/1233057


What is RingCT and how does it make Monero private?

Yes, that is true, but that is not the only thing. The main privacy enhancing features of Monero are:

Ring signatures: make transactions harder to trace by obscuring the output of the true sender in a set of n other outputs on the blockchain, indistinguishable with respect to their amounts, which are all the same (currently), or all hidden (under ringCT, see below). This is already working, with minimum n = 2 enforced on the protocol level, and soon to be raised to 4;

Stealth addresses: obscure the destination of funds (already working);

RingCT: hides transaction amounts as well. This feature is already implemented on the testnet, and will be deployed on the mainnet on January 2017.

Kovri: will be a reimplementation of the I2P protocol which will allow nodes to connect to each other and broadcast transactions without revealing their IP addresses. Currently in the making, and is expected to be ready in about 1 year. (In the mean time, the individual user can protect their IP address using TORSOCKS, although this solution doesn't work for the network as a whole, since nodes behind Tor cannot be found by other nodes but only find them.)


There's an additional step performed, called "normalization". It's just a modulo operation with l. See sc_reduce32 ... is it really supposed to be that complicated?

Oh and note that mnemonic is decoded to seed and then:

spendkey = sc_reduce(seed)

viewkey = sc_reduce(keccak(spendkey))

New versions of wallets roll a random 256bits, normalize it and use that as seed so the below holds true:

seed == sc_reduce(seed)

See Why did monero-wallet-cli restore the same wallet with different mnemonic seeds?


Why was the block time changed from 1 to 2 minutes?

If Monero usage increases so will orphan blocks and chain-reorganization. Bitcoin forks with much shorter average block times (compared to the 10/min per block BTC average) have far more many orphans. CryptoNote based coins like Monero are more susceptible to the effect of chain reorganizations than Bitcoin forks so it was decided that 1 minute blocks were too short. Longer confirmation times make chain reorganizations less common.

  Perhaps the strongest reason to make this change is to guard against an increase in popularity (and the size of the network) causing the chain to become unstable. This has been seen on Bitcoin forks with 30 second blocks, where long chain (10 blocks or more) reorgs become extremely common and the network may fail to converge at all for long periods of time (or in theory permanently). Similar effects are seen to a lesser extent on BTC forks with 60 second blocks, and CryptoNote is somewhat more sensitive to the effects of reorgs, so staying at 60 seconds puts us in (or at best close to) a potential danger zone. The coins with the fastest block times that don't seem to commonly run into this trouble are the LTC-style 2.5 minute blocks.

2 minute block times will also cause the Monero blockchain to grow in size at much a slower rate (particularly now when many blocks are still empty) thereby improving scalability.

The above benefits were balanced against the impact slower confirmation times may have on merchant and user convenience. In the future if network latency and/or transaction volume changes dramatically the block time decision can be revisited.


Method 1)  A one-time start of monerod

You can use 'screen' to keep it running when you log out.

Ubuntu: apt-get install screen

CentOS: yum install screen

screen monerod --rpc-bind-ip <your external IP address> --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind

Replace  with the IP address of your VPS.

When monerod is running inside of screen, you can press Control-a-d to detach from the screen session and return to the command line.  You use screen -r to reattach to the session.

Method 2) Keep monerod running perpetually

Create a new blank file called monerod-cron and add the following line.  Be sure to enter the full path to your monerod binary and your external IP address.

0 * * * * <full/path/to/monerod> --detach --rpc-bind-ip <your_ip> --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind

Example:

0 * * * * /usr/local/bin/monerod --detach --rpc-bind-ip 100.22.33.44 --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind

Save the file and load it into your crontab by running crontab monerod-cron.  This will start monerod automatically every hour.  If monerod is already running, it will not start a second copy.

To view the monerod logfile:
tail -f ~/.bitmonero/bitmonero.log

To view the crontab logfile:
tail -f /var/log/cron

Notes

Your firewall will need to accept incoming connections to TCP port 18089.

There's some more info at https://moneroworld.com/#nodes


Does the reward for mining with a certain amount of hash per second stay the same over time?

Want to start mining XMR but wonder if the reward stays the same.

No. It's changing according to emission schedule. If you're asking about how much an individual miner could be getting - on average, he'll get a proportional amount of his hashrate. If he's solo mining, this means he could be mining for a long time before he ever receives anything. That's why people pool their efforts together, and split the reward once they win it. That's called pool mining.

  Does it maybe, as with BTC, become less because of the bigger blockchain?

Size of the blockchain has nothing to do with that. Reward is tied only to blockchain age, as per emission schedule. Technically, it's tied to amount of monero currently in circulation, but effectively it's as if it's tied to age.

  Or does the reward of let's say 0,03 XMR per day get less when the value of XMR becomes more (compared to USD)?

Monero reward (in XMR) will keep reducing as per emission schedule. Somewhere in 2023, it will get to 0.6XMR (per 2-min block) and stay like that forever. This is known as "tail emission" (1, 2). Thing is, as more miners enter the space, it will be shared among more and more miners so each individual miner will receive less XMR. However, they'll probably be receiving a more-less constant amount of USD, governed by hardware efficiency and cost of electricity.

Mining works like a scratch-lottery. The stronger CPU you have, the more tickets you're able to purchase per 2-min round. Note that the round is closed only once a winning ticket is found, regardless of time. If winning tickets are found too fast, criteria for winning becomes more strict and if too slow, then it's relaxed. It's called "difficulty adjustment". Tickets cost eletricity. Since alone you have low chance of winning, you pool your efforts with a bunch of people to increase the chance of someone from your group winning. Then, you split the reward according to how much "tickets" each of you contributed.


Boost version 1.54 is unsupported, more details are available here
  http://goo.gl/RrCFmA

What do you get when you run this: sudo apt install libboost-all-dev


Monero GUI self-hosted node issue with Ledger - it keeps requesting password

Quoting selsta:

  You can disable this in Settings -> Layout -> Lock wallet on inactivity.


Security differences between using Monero on PureOS and QubesOS

In general, QubesOS offers greater security than PureOS. With QubesOS, programs are run in their own virtualized environment. This could offer greater protection if the computer was infected by a malicious program. Here's a good summary comment.

Note that you can install QubesOS on a Librem device with any USB. You do not necessarily need to buy the USB stick from Librem directly.


As of August 2017, how much monero has been mined out of the total supply?

Actually just https://moneroblocks.info/ shows "Emission" in top right corner, so looks like it is about 14.9M


How can I be notified of important updates/news to the Monero software?

There is now a monero-announce mailing list on which such important announcements will be made:

https://lists.getmonero.org/postorius/lists/monero-announce.lists.getmonero.org/


Would a long-time block target be annoying?

To target a block time of a day, difficulty would be adjusted to make the likelihood of finding a block require a days worth of hashing (work). The big drawback to such a large block time would be slow confirmation of transactions.


You can see the total daily volume on non-p2p exchanges and broken down market here:

http://coinmarketcap.com/currencies/monero/#markets

Over the last 24 hours the total volume was about 316 BTC or 207k USD, with most of that concentrated at poloniex.

There is one p2p trading service that you can check the volume on - bitsquare, but I don't think they're doing more than $100 per day at the moment.

As far as I know there is no way to know how much OTC trading is occurring on any given day, except maybe trying to estimate by lurking in #monero-otc channel in freenode.


What privacy issues did Monero have and still has?

The Monero Research Lab is a team of voluntary researchers, scientists and academics that did analyse Monero and its predecessor CryptoNote in the past, explaining both past attacks and possible privacy issues in the current network. Their research is mostly funded by donations from the Monero community and is publicly available.
In the following segment I will list every security issue they found and their implemented or proposed solution. Elaborations are my comments but are mostly based on the research results.
TL;DR

Seven possible attack vectors
Six solutions have been implemented
One issue is not yet resolved

MRL-0001: A Note on Chain Reactions in Traceability in CryptoNote 2.0

If an attacker owns many transactions and you use solely his outputs
as mixins, he is able to deobfuscate the ring signature. He could spam
the network with transactions to increase the probability of becoming
a mixin.

Solution: Enforced minimum mixin of 2 will reduce the share of evil outputs over time
Status: Implemented
Elaboration

Fees and a possible deflation make this attack rather expensive for the excessive amounts the attacker would need to buy, hold and move: "If Burns controls half of all outputs, then 12.5% of all new transactions will have a ring signature composed entirely of his outputs"
Accidental deobfuscations (mixin = 0) can be prevented by enforcing a protocol level minimum mixin
With a protocol level minimum mixin of 2 and the resulting 12.5% chance of deobfuscating a transaction, the share of the malicious outputs gets reduced with every new transaction on the network, effectively "repairing" itself as long as the attacker does not keep on producing outputs

MRL-0002: Counterfeiting via Merkle Tree Exploits within Virtual Currencies Employing the CryptoNote Protocol

On 4 September 2014, an unusual and novel attack was executed against
the Monero cryptocurrency network. This attack partitioned the network
into two distinct subsets which refused to accept the legitimacy of
the other subset.

Solution

On [...] the same date as the attack, the first solution to the
exploit was publicly announced by Rafal Freeman [...] The Monero
development team released patch 0.8.8.3 on 6 September 2014 to [...]
allow miners to identify the A side of the network [...] and to
identify foreign nodes with the B-side version of block 202612

Status: Implemented
Elaboration

A bug in the fresh fork of the poorly documented Bytecoin implementation caused this issue that was fixed temporarily on the same day and permanently two days later
The attack made different nodes not recognize each other as correctly working, splitting the nodes temporarily into two parallel blockchains and effectively doubling the amount of funds per person

MRL-0004: Improving Obfuscation in the CryptoNote Protocol

One may have reasonably assumed that the original CryptoNote
developers would have implemented a standardized denomination
requirement for all transaction outputs, but [...] the protocol does
not disallow any strange denominations [...] Hence, no mix-ins are
possible

Solution: RingCT hides the amounts of transactions, making denominations useless and removing dust
Status: Implemented

An observer cannot distinguish which transaction output [...] is the
output actually being spent [...] However, [...] an attacker may model
the cumulative probability that the output has already been spent as
an increasing function of time [...] Hence, [...] the youngest output
used to fashion the ring signature is the most likely output to be the
genuine output being spent

Solution: No solution in sight ( discussion for a solution can be found here )
Elaboration

When an exchange rate is experiencing a [...] inflation, rational
users are more likely to spend their transaction outputs [...] When an
exchange rate is experiencing a [...] deflation, rational users are
more likely to hoard [...] Hence, the distribution of transaction
output ages will at least vary over time, and, presuming any
proportion of users are rational will certainly depend sensitively on
the economic performance of the currency. It is unwise to design
security recommendations around the economic performance of our
protocol.

Note: This issue is currently the biggest issue of Monero privacy and was subject to another scientific paper, which can be found here. This research is under criticism for not clarifying the ties to the ZCash Foundation well enough.

an observer may conclude that the outputs stemming from a common root
transaction are more likely to belong to the true signer of the
transaction

Solution: RingCT will prevent denominations and therefore reduce the probability of outputs stemming from the same transaction
Status: Implemented

if a set of distinct transactions has some common data (such as a
common block height) and if all transactions in this set use mix-ins
with some other common data, then it is likely that these transactions
are related by a common user

Solution: RingCT reduces the amount of shared data
Status: Implemented
MRL-005: Ring Confidential Transactions

One possible attack against the original CryptoNote or ring-coin
protocol is blockchain analysis based on the amounts sent in a given
transaction
it requires a given [...] ring signature with other pubkeys having the
same amount. For less common amounts, this means there may be a
smaller number of potential pairs

Solution: RingCT. MRL-0005 is actually all about how it works.
Status: Implemented


How can I build a specific branch of Monero?

Start by opening a terminal and installing all the dependencies:

sudo apt-get install libgtest-dev && cd /usr/src/gtest && sudo cmake . && sudo make && sudo mv libg* /usr/lib/

sudo apt-get install build-essential cmake pkg-config libboost-all-dev libssl-dev  libzmq3-dev libunbound-dev libsodium-dev

cd to the directory you want to download the files to. For example, if you want to go to the home directory (recommended for beginners), use cd ~.

Clone the repository:

git clone --recursive https://github.com/monero-project/monero

^ if you are using a branch from another contributor, then the URL will be different. Adjust accordingly.

cd monero && git submodule init && git submodule update

(Replace monero with bitmonero if this doesn't work)

Check out the desired branch. Replace <branch> with the name of the branch:

git checkout <branch>

You can finally build the binaries. Replace <t> with the number of cores your CPU has.

make -j <t> (eg: make -j 2)


My guess would be:

set ask-password 0
set always-confirm-transfers 0


Q: What are stealth addresses?

Stealth addresses are what ensure the unlinkability of Monero transactions. Someone can publish a Monero address and be assured that all incoming payments will be sent to unique one-time-use addresses that cannot be linked to either the published address or any other address connected to the transaction.

Q: How they are generated and used?

According to the CryptoNote white paper

  A sender generates a one-time public key based on the recipient’s address and some random data. In this sense, an incoming transaction for the same recipient is sent to a one-time public key (not directly to a unique address) and only the recipient can recover the corresponding private part to redeem his funds (using his unique private key).

Q:What are the differences between integrated and stealth addresses?

Integrated address serve a different purpose than stealth addresses. Integrated address contain data from a normal Monero address (public view key and public spend key) plus a payment ID serialized into the address.

Integrated address perform the same task as regular addresses used with separate payment IDs except they are encrypted (which separate payment IDs are not) and easier to use since senders can just use one address (instead of needing to use an address plus a separate payment ID).

Stealth addresses are automatic with Monero, so any payment sent to an integrated address will automatically make use of stealth addressing. They are fully compatible.


Why are there many Monero addresses starting with 4JUdGzv...QvVCjZb?

They're all Poloniex's deposit address. The bit at the end is the payment ID used to identify the depositor's Poloniex account. You can read more about integrated addresses here: What is an integrated address?


Why do the current mobile MyMonero builds use Cordova 6.5.0?

As mentioned in the repo Read Me,

  Note about Cordova version Apache has recently released Cordova 7.0.0.
  It was tested, but because it now places plugins into package.json,
  npm cannot update, as a handful of those plugins do not have
  package.json files, and npm and yarn (based on current info) cannot
  install them as deps. So 6.5.0 is the Cordova version that MyMonero
  currently supports for mobile builds, and it can be selected for use
  with [sudo] npm install -g cordova@6.5.0.

The moment this changes, or if someone patches up the install process to make it so that all the plugins which don't have package.json files can still be installed with Cordova 7, we'll remove this warning.


Migrating Monero Fork from Test to Production

The only reason you don't have to worry about "--restricted-rpc" in testing is if the test servers are firewalled off from the world so that no external machines can connect.

In production, you need to worry about general operational security and availability/uptime issues. Your nodes should be running on servers that are properly firewalled so that only access to the Monero node ports is possible, and not to other services running on the server.

You'd check you have two factor authentication with your domain host and with your server hosting, so that people don't break into your accounts there and take over your machines. You'd do a standard server hardening, including things such as installing the latest OS updates and only allowing passwordless (public/private key based) access to SSH on the machine.

You'd need to ensure your server had enough bandwidth to serve potentially huge numbers of people that wanted to download from your node, and ensure that you have DDoS mitigation just in case someone wants to take your server down to mess up your big launch.

You'd also want multiple seed nodes in entirely different datacenters so there's no single point of failure. You'd want the datacenters to be in different jurisdictions so that no one country could shut them down. You'd probably reference the IP addresses of these machines by domain name, so you'd want domains from multiple TLDs so that no one domain authority can take over all of your domains.


Creating Monero payment buttons which convert USD to Monero, customers pays and monero sent to my wallet

I don't know how Globee works but you can certainly build a payment gateway for monero as you described.

If you're planning to do everything yourself php is a bad programming language for this. Because php is only executed when someone visits a page and is not constantly running so you're going have to run cron jobs that check for new incomming transactions every 2 minutes ( monero's block time ) and it's going to get messy.

On the other hand if you want to get things done as quick as possible check out https://coinpayments.net. They have plugins for popular e-commerce platforms which you can check out at https://www.coinpayments.net/merchant-tools-plugins. They also have REST api if you need. CoinPayments is something I know exists I'm sure you can find other services like this one if this one doesn't suit your needs.


Command for returning transactions in json format to external code

https://getmonero.org/resources/developer-guides/daemon-rpc.html

Documents all the API methods you would need.

You would first use get_block_count then iterate calling get_block, then calling get_transactions with the returned tx_hashes from get_block.


Are there other URL parameters when querying a Monero node's get_info method?

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

All the daemon RPC methods are documented here.

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

get_info has no input parameters.


How/when does the --db-salvage flag get used? What's it do?

If your daemon was interrupted by a power failure or OS crash, and it was still trying to catch up to the network (as opposed to already being synchronized), there's a chance the DB got corrupted. If you get a DB error after starting after a crash, you should try using this flag. You should only use this flag after you've already seen a DB error that causes monerod to fail. You don't have to exit and rerun or do anything else unusual in combination with this flag.

LMDB always maintains two snapshots of the database. This flag attempts to use the older snapshot instead of the newer one when it first opens the database, on the assumption that the newer one is the only one that got corrupted by a crash. It may not always be successful. Once the database has been opened and operated on successfully, the flag has no further effect.

Using this flag when there hasn't been any crash will erase the last transaction committed to the database, and make the daemon need to catch up to the network again.


Are mnemonic seeds available in multiple languages?

Monero does support arbitrary language seeds.

Currently, several languages are implemented in terms of seed: English, Italian, German, Spanish, Portuguese, Japanese, Russian. More may be added by people familiar with other languages, as the main task is to find a set of 1626 words in a language which obey a few simple rules:

the words should be common enough for most speakers to know them
synonyms and similar words should be eschewed where possible
any two words should not share a prefix between them

That last requirement bears some explanations: the intent is that a mnemonic seed only needs the first few letters to be unambiguously recognized as a word for that language's list. For instance, the English word list has a 3 letter unique prefix, which means that if a word starts with "pig", there is no other word in the list which starts with that same 3 letters prefix. Here, the only word starting with "pig" is pigment. Pig would also work, since only the prefix matters. This allows one to change words in order to remember better, as well as potentially disguise a mnemonic seed by using words that do not appear in the list, but which share a prefix with one of those words.

As far as I know, there are no new languages currently slated for inclusion, but those simple rules are there for anyone who wants to have their own language included.


Who created the Monero ASICs during 2019-Jan to 2019-Mar?

Do we know who exactly created these asics during the big hash run up
  during 2019-Jan to 2019-Mar?

It's hard to say, but the names are the usual known.

  And why would they create these asics, when they know for a fact that
  the monero community would easily fork the algo to brick all of their
  asics. It just doesn't make sense why they would spend so much money
  to make these ASICS and have them bricked.

Because in the time of a few months they pay back their expenses and earn enough money. Furthermore, it is very likely that this time is about FPGA rather than ASIC. In this case, they will be reprogrammed after the fork to run the new algorithm and to be operative again.


Who controls the servers behind the IP addresses used for bootstrapping nodes for (initial) peer discovery?

As a partial answer, here is a list of reverse DNS lookups followed by their respective WHOIS owners:

107.152.130.98 > monero.cc > Riccardo Spagni
212.83.175.67 > poneytelecom.eu > Unknown
5.9.100.248 > your-server.de > Martin Hetzner
163.172.182.165 > scaleway.com > Unknown
161.67.132.39 > Unknown
198.74.231.92 > Unknown
195.154.123.123 > poneytelecom.eu > Unknown
212.83.172.165 > getmonero.org > Riccardo Spagni

However it looks like these are fallback IPs. Initial seeds are fetched from these addresses:

seeds.moneroseeds.se > Unknown
seeds.moneroseeds.ae.org > Riccardo Spagni
seeds.moneroseeds.ch > Riccardo Spagni
seeds.moneroseeds.li > Riccardo Spagni

  Who controls them?

These core peers are hardcoded and thus only managed by several trusted persons by the core members, as Riccardo Spagni (among his 83+ DNS addresses). You'll see that at least 5 peers are owned by Riccardo Spagni and another one by Martin Hetzner (unknown to me, it is possible that this reverse DNS lookup is wrong). I don't think that someone will come forward and give a full list of names as the anonymity related to some IPs prevents a social engineered attack.

  Who decides which IPs are added?

The core team. Any added IP would however be reviewed through the GitHub PR process preventing any unwanted ones from being inserted.

  What would it take to get my node added to the list?

This won't be allowed as far as I know. These core peers are the backbone of Monero and must be managed by known people to the core team. These 8 IPs and 4 addresses guarantee a sane network and must be running 24/7. Allowing anyone to add their IP would make the network vulnerable to a hostile take-over.

  To how many of them does my node connect (and when)?

Your node seems to try to have 12 connections.
For as far as I know the IPs are used as a fallback if you didn't reached the 12 seeds.
The connection is made upon initialisation. But here again, I might have mis-read the code.

  How does Monero deal with BGP or similar attacks? Is the communication with these nodes authenticated?

Although I don't have a certain answer here, All these IPs and addresses are public as well as Monero's source code. I haven't been able to find any code specifying a special check which would mean that these kind of attacks are possible.
However, I don't see which effect they could have. All they would be able to do is block your transactions or fake your balance without having any definitive actions on your wallet. The signing process on Monero's transactions will prevent them form redirecting your funds. A more productive attack would be that an attacker fakes a website donation page and forces you to make a donation to his fraudulent address.


Different symbols in monero full node map

A blue reverse drop indicates the approximate location of the node as per geolocation of the IP address. A green circle indicates that the approximate location of more than 1, but less than 10 nodes is the same. A yellow circle indicates that the approximate location of more than 10 nodes is the same. For both the green and yellow circle it probably means that multiple people are hosting a node on a VPS hosting provider that is located there.


What is the impact of having perfectly hidden but only computationally bound commitments?

There seems to be a fair amount of misunderstanding amongst a few people of what is meant by the phrase "perfectly hiding and computationally binding" when discussing Monero security. In Monero, we use Pedersen commitments to hide the values in transactions and to help ensure there is no hidden inflation. Without an understanding of the context of the words "perfectly" and "computationally", this can lead to unnecessary fears.

To better understand, I find it helps to first grasp the concept of input and output spaces.

In the case of the input space for a Pedersen commitment, this is the set of all integers in a 506 bit range (a tuple x,a, two 253 bit scalars), and in the case of the output space, is the set of all points on the curve (Ed25519) used, a 253 bit range. Here you can see the input space is far larger than the output space. What this means in practice is that different inputs can map to the same output, or to put it another way, it works like a many-to-one relationship. Reference the Pigeonhole principle. Therefore, being in possession of the "one" part in a many-to-one relationship, you have no way (computationally at least) to determine specifically which of the "many" is the real input. Therefore, if an input space is larger than an output space, you can achieve perfect hiding.

Now, for the computationally binding. For a Pedersen commitment C, we have C = xG + aH, where x is the binding factor and a is the amount of Monero. What's important to understand here is that the generator point H must be chosen in such a way that no one knows an h such that hG = H (and it's regarded as safe to simply hash G for H here). Importantly, there is only one h that could possibly yield H (technically there could be others, but only one is actually needed for what follows), or to put it another way, the relationship is one-to-one. The input space is practically the same size as the output space. Now, to calculate this h would require knowing the discrete log of H w.r.t. G. This is what gives us the computationally binding aspect. It requires significant computation, but in theory, it's possible with unbounded computational power, to calculate this h.

So, assuming the sky falls any time soon and we have computers which can solve for the discrete logarithm problem, and thus someone is able to compute h such that hG = H, where does that leave us? Well, apart from all of ECC being vulnerable and the consequences of that, what it means w.r.t. Monero and the Pedersen commitments is that someone can publish a commitment using some random y, e.g. C = yG. Later, when asked to verify this commitment, they can pretend to have bound it with any given x. E.g. to calculate an a which will work for a given x:

xG + aH = C
xG + ahG = yG
thus
a = h^-1(y-x)

Or conversely, to obtain a binding factor x for any chosen amount b, that verifies the published commitment C = yG:

xG + bH = C
xG + bhG = yG
thus
x = y-bh

The binding property is lost. Whilst the existing amounts on the blockchain stay perfectly hidden, we would succumb to a problem of possible hidden inflation (we could no longer trust the amounts in commitments are accurate). And recall, this is a one-to-one mapping, you only need to find h once to be able to use it again for any given x.

Some people ask why we couldn't switch to having computationally hidden and perfectly bound commitments. Of course, we could, there are other commitment schemes that offer exactly this, e.g. ElGamal commitments. The real trade-off here is that ElGamal commitments are significantly larger than Pedersen commitments and also, they suffer the reverse issue e.g. they are perfectly binding but only computationally hiding (so with just one piece of information, all amounts could theoretically be revealed). Some also ask if there are any perfectly hiding and perfectly binding schemes. Not presently is the answer here.

But I'll stress here, just because something is not perfectly binding (or hiding), doesn't present some huge weakness. Being computationally strong is what ECC (and a great deal of other cryptography) is founded on - the discrete logarithm problem. We've got some time yet before computers are powerful enough to solve for this, and when they do, we've got a lot of bigger problems to deal with if we haven't come up with something else by then!

If it's not abundantly clear from all of the above, breaking the binding property does not break the hiding property. You simply cannot brute-force, no matter how unbounded your computational power is, e.g. even in the presence of quantum computing, to unhide the amount of Monero. You could at best calculate an amount that could be valid (recall there are many amounts that could be valid, you just have absolutely no way of knowing which is the one used). And breaking the binding has far more significant ramifications than just Monero's inflation security.


Does having a separated daemon add security risks to Monero?

The disconnected architecture that Monero employs allows you to host the daemon and wallet separately. My own opinion is that this is an improvement over the bundled design of Bitcoin-QT.

If you connect your wallet to a remote daemon, or don't host your own node, there are security and performance implications.

If you run the daemon locally, there's a chance that a local process is intercepting the packets. However, if you have that level of malware on your machine, you're probably no better off with the unified architecture since your transaction will be picked up and logged when you send it out to the network anyway.


5-party Ring Signatures still being implicatory for sender?

Privacy concerns related to ring size are most significant in cases where an exchange or person that gave you the output you are spending knows you control it and is aware of your identity. Significantly reducing the statistical likelihood of a TX being connected to you in the above situation is not difficult using the current default ring size:

  Can you tell that those funds actually came from the TX you sent to me 5 hops ago? Probability would be (1/N)^5 that it came from me. For ringsize 5, that's 0.0000032% chance. Just one of many possibilities, without any way of knowing which one is the real trail.

Monero Research Lab continues to evaluate the ring size issue. Minimum ring size will be increased in the future. However, because of the way ring size currently impacts tx size, it is likely that bulletproofs will be implemented before or in conjunction with any major adjustment to the minimum ring size:

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


Wallet Balance Incorrectly Displays 0, missing Transaction Keys?

Downloading the chain is pointless.
Restoring the wallet from seed will wipe the transaction keys.
A double spend like this after a restore from seed/keys can be caused by an outgoing transaction being stuck in the daemon, waiting to be spent. The outputs spent in that tx are not spent on chain, but the daemon will still reject reuse of them since it's already got a tx waiting to be mined. You can fix this by running "rescan_spent" in monero-wallet-cli. I believe there's a button for this in the options somewhere in the GUI,
I don't know about the "unknown amount" thing, that seems odd, but it seems GUI specific. See what monero-wallet-cli reports.


How does it affect my node when I get the message: "No incoming connections - check firewalls/routers"

What does this impact on my node?

By not forwarding ports, you are preventing access for external nodes. Note however, nodes that you initiate a connection with can still sync from your node.

  Can I still connect to my node locally and use its RPC interface?

Yes.


Hardware for Monero mining hash rate of 1 MH/s

No, I don't think so. Someone achieved 100kH/s https://xmrig.com/benchmark/4nmg1G and that really is the highest we know so far.