Can I enter a password & wallet file name through JsonRPC?

No, you can't.

The Wallets RPC - Interface opens the connection only after opening the wallet and its lifetime is completely dependant on the wallet. If you close a wallet, it will shut down the RPC interface as well. This is caused by the design of a wallet instead of a dynamic daemon.

Your described problem with a visible password when listing the running processes is known and has been discussed already. While it is faster for an attacker to just read the password from the window title, your wallet is compromised anyways as soon as an attacker has access to your computer. This cannot be stopped by encrypting a connection or not having the password in the window title, as he would be able to read the password from your computers memory, trick you into entering it again, running a keylogger etc.

While a possible attacker in your network could sniff your user-agent, this wouldn't be much use to him as he can't modify your browser user agent to perform the CSRF attack the user-agent was established against. Keep in mind that the user-agent is not a password protection and trying to protect a public wallet in RPC mode like this will lead to a compromise by anybody who can take a look at your connection to it. The user-agent is only a temporary solution against CSRF, a more secure solution is worked upon (since some time, the priority is considered very low due to the very limited attack opportunities).


Why not include a README.TXT in the GUI Wallet Beta zip file?

No particular reason. It'd need... someone to write one, someone to PR one, someone to include it in the release. fluffypony can take care of the third. The first one is the most time consuming. I think the release notes that are already published on github could be usefully included. But anyone's free to add a "my first few steps with the GUI" introduction to the GUI and PR it to https://github.com/monero-project/monero-core. If you dream of being a Monero contributor, now's your xhance :) And if not, somebody else will do it eventually. But yes, a good idea :)


How is building the GUI from source different from building monerod/CLI?

The monero GUI source code and installation guide (including Ubuntu 16) can be found here https://github.com/monero-project/monero-core

To answer your questions by referring the guide.

It installs in the directory where you download/cloned the source and build it. So it will not overwrite anything as long as you download it on a an empty folder.
On the sub folder where it is built. Specifically ./build/release/bin/monero-wallet-gui
It's not installing monerod and monero-wallet-cli. Its not in the source code.
I'm not sure but probably not. It may be the same in windows which does not ask to run monerod if there is one already running.
You use git to clone the repository. The installer has a build.sh which does everything for you including the make.


There is no such system in Monero.

Now, miners will mine transactions that have the highest fee/byte ratio first. But once a miner accepted a transaction in its txpool, it will not accept another one that's conflicting. So the only way that can work is if the second one is sent right after the first, to another miner, and manages to be mined first (ie, the part of the network reached by the second miner finds a block first). This is essentially a double spending attack, but that's the only way you can replace a tx in Monero :)


Benefits to starting out mining at a higher difficulty

A high pool difficulty is for high power mining equipment. What this does is lowers the bandwidth amount for both the pool and the miner. Because the difficulty is higher, the miner will find valid shares less frequently, resulting in less data transmitted from the miner to the pool.

Lower difficulties are for lower powered mining equipment, so that the miner has a chance to submit some valid shares before the next network block is found, and it has to start the hashing process over again for the new block. If no shares are submitted by a miner between blocks, that miner will get no credit for the mined block. This is why pools have several different difficulty levels.

Typically pool payouts are weighted on the number of shares per miner, while those shares are weighted on the difficulty setting, so a low difficulty share is worth less than a high difficulty share.


Payment proofs are detailed nicely on the Monero site here: https://www.getmonero.org/resources/user-guides/prove-payment.html

They are used in the case of a dispute so you, as the spender, can prove to the receiver you sent funds to them.


monerod has a get_transaction_pool RPC call:

curl -X POST http://127.0.0.1:18081/get_transaction_pool -d '{}' -H 'Content-Type: application/json'

This will return the current state of the tx pool. Each transaction in the pool has this information:

    std::string id_hash;
    std::string tx_json; // TODO - expose this data directly
    uint64_t blob_size;
    uint64_t fee;
    std::string max_used_block_id_hash;
    uint64_t max_used_block_height;
    bool kept_by_block;
    uint64_t last_failed_height;
    std::string last_failed_id_hash;
    uint64_t receive_time;
    bool relayed;
    uint64_t last_relayed_time;

monero-wallet-cli has a get_transfers RPC call. This can be configured to return transactions in the pool going to the wallet, by setting "pool" to true:

curl -X POST http://127.0.0.1:1234/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_transfers","params":{"in":false,"out":true,"pending":false,"failed":false,"pool":true,"min_height":735000,"max_height":1000000,"filter_by_height":true}}' -H 'Content-Type: application/json'

This will return this information for every transaction:

      std::string txid;
      std::string payment_id;
      uint64_t height;
      uint64_t timestamp;
      uint64_t amount;
      uint64_t fee;
      std::string note;
      std::list<transfer_destination> destinations;

Note that some information may or may not be present. For example, destinations is not known for incoming transactions (sush as those incoming transactions found in the pool).


Building Monero From Source on Windows 10 Pro

To solve this, rename the directory

C:\Users\...\monero\build\release

e.g. to

C:\Users\...\monero\build\zzzrelease


Since OpenAlias supports Namecoin-based identities it has the exact same properties as NameID. The primary advantage to OpenAlias is that it avoids the land-rush issue, where someone grabs the alias WaffleTown and then tries to steal payments destined for WaffleTown. Instead, WaffleTown could provide something like payments.waffletown.com, without needing to care about the blockchain-based / decentralised scheme.


Is it true that a vendor can see my IP address if I send moneros via my GUI wallet without using Tor or I2P?

If the vendor also runs a Monero node, and is currently connected to your own node, then their node will see your transaction being forwarded to their node.

If they set things up to keep track of IPs through which they seem transactions come in, they can determine which IP forwarded each transaction to them. This may or may not be the originating node (they'd have to be connected to every single node in order to determine which node is the originating one). But if they somehow were connected to the whole set of nodes, they could determine the originating node.

Now, most merchants aren't running a node. Most, in fact, accept Bitcoin, and accept Monero only due to paymene systems, shapeshift, xmr.to, or similar services.

Using mymonero would sidestep this, as the merchant's node would see the mymonero node's IP (or one of them, if mymonero uses several).

Using Tor or I2P negates this problem altogether.

Note: the above assumes you're using your own node. If you're using a public node, then the usual privacy guidelines matter: use Tor between your wallet and the public node, instead of between nodes.


Monero on Tails OS - Connection Errors Download Node

The problem was, is that I formatted the SD card with FAT32 (same as Tails OS) and the download would max out at 4GBs oops. I used Linux's file system and had no problems. Can someone recommend a Bitcoin to Monero exchange i can use?


There is a diagram on page 6 and 7 here which labels the last (tail) hash as "Chosen hash".

And described:

Then, the 2 low-order bits of the first byte of the state are used to
select a hash function: 0=BLAKE-256 [BLAKE], 1=Groestl-256 [GROESTL],
2=JH-256 [JH], and 3=Skein-256 [SKEIN]. The chosen hash function is
then applied to the Keccak state, and the resulting hash is the
output of CryptoNight.


In your wallet folder* you have three wallet files.

<walletname>.keys
<walletname>.address.txt
<walletname>

The wallet cache is the file without an extension. If you delete or move that file to another folder the cache will be rebuilt when opening the wallet.

Note. It is advised to properly backup your wallet files before you perform this action. Also note that deleting the wallet cache results in losing some of the transaction history, namely recipient addresses and private tx keys. Thus, if you want to use an existing wallet with the GUI, it is advisable to backup your wallet cache in case you need transaction history info in the future.

*The wallet folders are as follows:

Windows: Documents\Monero

Linux: ~/Monero

Mac OS X: ~/Monero


Is there a tutorial how to compile my own monero cli wallet software from source?

Compiling from source instructions are in the project README.

Though changing the Monero source code just to deviate from a sensible default value, which can be easily changed as soon as the wallet has been created in any case, seems a pointless exercise to me.


How to determine the software version of an RPC node?

So long as the node is not running with the restricted RPC (i.e. --restricted-rpc),
 you can check its version by calling get_info. E.g.

curl http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_info"}'

The result object has a version field like: "version": "0.15.0.1-release"


Scanning and updating Monero balance with private key using only monerod rpc?

First, I'd suggest thinking harder about your design choice of holding users private keys. If you're going to have full custody of users wallets, it begs the question why have per-user wallets in the first place. It's your wallet if you hold the keys, so you could just just assign accounts/subaddress to customers for example.

Second, if you're going to ignore my first point... You cannot use the monerod RPC as it's the node daemon, it doesn't offer wallet level functionality. You also cannot use the monero-wallet-rpc with raw private keys - it operates on a wallet file. Therefore, you would need to restore each wallet file from the supplied keys using monero-wallet-cli, then you can use the monero-wallet-rpc on each wallet file - either use multiple processes, so you have each wallet permanently opened/running, or use one process and the open/close methods to open/close each wallet file as needed.


Check balance of an address by Monero RPC

The per_subaddress field of the result returned by the get_balance method contains the balances of the addresses.
There is also the get_accounts method that gives the balance for each account.

Documentation:

get_balance
get_accounts


Outputs are only ever created as part of transactions. There are two types of transaction:

Coinbase transactions, a special type of transaction created with every block that is mined, which rewards the miner according to the emission schedule and any transaction fees paid.
Regular transactions, which spend existing outputs and create new ones.

So just keep mining more blocks and more outputs will be created.


What happens to coins that are sent to a public viewkey?

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


What is the normal rate of failing to submit a block from pool mining Electroneum

I'm not sure what the normal rate is but since i started mining a week ago, i rarely get a rejected-messages. Not sure if that has todo with your mining software, your hardware or the pool but to at least exclude the pool, see if another pool works better for you.

Currently i mine at Coinfoundry which is a really new pool that supports also Electroneum and has a fee of 0.15% (it will never have a higher fee then 0.6%) and no other costs. Try it. If that doesn't help you, then you at least know that that's not the problem.


What is the future potential of MoneroChat?

Monero/Aeon developer smooth, quoted below explains the encrypted messaging system he is currently researching:

  There are many ways one could implement messaging, but I don't favor storing p2p messages on the blockchain itself. Encrypted is even worse, in a way, since that can't possibly be of any benefit to anyone other than the specific recipient. (At least if you store bible verses or dick pics, there might be a few people who are interested in that.)

  I would propose something like:
  Create and submit a small transaction that pays a fee and includes a hash.

  After the transaction is successfully mined, you may submit a message packet up to some maximum size (for example 32 KB) that matches the hash (assume the message is encrypted, but it wouldn't necessarily need to be) into the mempool, where it will be stored and relayed to peers. Once the transaction reaches a given depth in the chain (for example seven days; 5040 blocks), the hash expires and the message may no longer be submitted or relayed.

  It is true that it is extremely difficult if not impossible to prevent use of the blockchain for storage of arbitrary data that does not benefit most of the people incurring the cost of the system, but providing a useful mechanism that does much the same thing in a less harmful manner is a good way to discourage it.

  Possibly the lifetime and allowable size of the message could be a function of the fee paid, but there is no good way to set the fee, nor a good way to compensate the node operators for storing and forwarding it, so the suggestion of a fixed life and size is intended to limit the cost to something reasonably negligible.


How the receiver knows the amount that he received from the sender?

The amount is encrypted by the sender and then communicated as part of the transaction (it's a field called amount in the ecdhInfos part of the transaction).

To decrypt the encrypted amount, you need to know your private view key a. The transaction already includes the transaction public key R.

Decrypted amount = encrypted amount - Hs(Hs(8aR || i)) where i is the index of the output whose amount you want to decrypt, || means byte concatenation, and Hs() is a hashing function that returns a kind of number called a scalar.

Update:

In order to reduce the storage required for the encrypted amount from 32 bytes to 8 bytes, the scheme is now:

decrypted_amount = 64-bit encrypted amount XOR first 8 bytes of keccak("amount" || Hs(8aR || i))


What is the height used for when creating a View only wallet in monerujo android app?

To determine the starting height, you can use a block explorer to get an idea of what block was mined on what date.

For example, if you know you created your portfolio in July 2017:

Go to a blockchain explorer, such as Monero Blocks
Check the current height (~ 1,470,000 as I write this answer)
Calculate roughly the number of days since you created your portfolio: we are in December 17, so approximately 6 months x 30 days = 180 days.
Multiply by 720 (see note*) to calculate the number of blocks since that date: 180 x 720 ~ 130,000
Subtract from the current height: 1,470,000 - 130,000 ~ 1,340,000
Check the timestamp of that block on the same website: 25th of June 2017

So you can use 1,340,000 as a starting height and not miss any transactions.

*Note: I'm using 720 for the daily block emission - it was different before April 2016 so if your wallet was created before that date the calculation won't work. But for such an old wallet you may as well start from height 0.


What is the transaction id and how its calculated?

The 'tx id' is also known as the transaction hash. It is a keccak hash of the transaction data.

This hash is used to uniquely identify the transaction, which is why it's also referred to as the 'tx id'.

The tx id is actually a hash of 3 hashes:

A hash of the 'transaction prefix', which contains information such as the inputs, outputs, and the 'extra' field which contains any payment id associated with the transaction.
A hash of the 'base ringct' data, which includes the encrypted output amounts and the output Pedersen commitments.
A hash of the 'prunable ringct' data, which includes the output amount range proofs and ring signatures for the inputs.

The payment id that you can specify for a transaction is known in advance of creating the transaction. This means you can tell someone to use a certain payment id when sending you a transaction. If a payment is being sent to an integrated address, the payment id is also encrypted so that only the recipient can decrypt it.

The tx id, in contrast, is only determined after you create the transaction. By "create the transaction", I mean select the specific outputs that are going to be spent, choose decoy outputs, and construct the entire transaction payload that is ready to be submitted for mining. You do not have to actually publish or submit your transaction to be mined to determine the tx id.

Since the tx id is simply a hash of the transaction, anyone observing the public blockchain will be aware of the tx id of any transaction on the blockchain.


Well, it depends on what you're asking.

I run my node on Ubuntu Linux.  I have connected wallets from Linux, Mac, and Windows to the node running on Linux.  Connecting at the same time shouldn't matter.

If you're asking about having some network drive that is just connected to your router, and you want to run monerod from various computers around the house by using the --data-dir flag, and the computers will basically take turns at syncing the blockchain, that would probably work, as long as you don't mix chip architectures (x86 vs ARM).  It may or may not work across 32 vs 64 bit computers.  In general, I'm sure there are reasons why this is not a good idea, like how LMDB would behave, so hopefully someone can provide a more technical response to address that aspect.


Generate a wallet file from a spend key in the command line using the CLI wallet in a "non-interactive" way for scripting purpose

You should use --generate-from-json for this.
The input fields in the JSON file are:

      version: integer, should be 1
      filename: string, path/filename for the newly created wallet
      scan_from_height: 64 bit unsigned integer, optional
      password: string, optional
      viewkey: string, hex representation
      spendkey: string, hex representation
      seed: string, optional, list of words separated by spaces


What is the best mining card with hash to power consumption ratio for monero mining as of 2017-10?

You might expect some 150w-200w per card plus 300 w from the rest of your PC. For safety, you should try with a larger breaker. 2500 w should be fine.

Edit: there are motherboards designed with several PCIx1 and PCI x16 ports and even several power ports so you can plug up to three Power Supply Units to said motherboard and up to 19 GPUs.

You need to protect this investment. May I suggest buying an additional UPS to protect it from power surges and voltage variations. Also you'll need HVAC equipment. If you're plugging all this from one breaker, you need to consider the higher demands.


When someone uses a rct transaction, the outputs are necessarily rct. From hard fork 4 (expected in or around march 2017), both rct and non rct transactions will be permitted. From hard fork 5 (expected in or around september 2017), non rct transasctions will be permitted only if they are spending unmixable outputs (ie, the rules for allowing mixin 0 now).

If you want to make all your outputs rct, you should be able to use sweep_unmixable first, then sweep_all. Assuming you do not have a large amount of tiny inputs, that should make your whole balance only in rct outputs.


No. Bulletproofs currently use used to use openssl's BN API for this, and now use an optimized algorithm for computing the inverse of a set of scalars.


What does "rings used by outputs spent on Monero on a key reusing chain" mean?

Yes, here is a fuller explanation:

The Monero GUI has a Shared RingDB. This means that when you spend one of your outputs using the Monero GUI, a record will be kept of the ring members that were used for that transaction in the Shared RingDB.

The "Shared" in Shared RingDB means that this database is shared between all wallets on your computer, regardless of which fork they are transacting on. Therefore if you spend an output using your Monero wallet, then when you spend the output again using the MoneroFork wallet, the same ring will automatically be reused because both wallets are using the same Shared RingDB database.

  This records rings used by outputs spent on Monero on a key reusing
  chain, so that the same ring may be reused to avoid privacy issues.

This section is necessary in case the wallet that you used on the other Monero fork does not support Shared RingDB functionality. This section therefore lets you manually record a ring into your Shared RingDB, because it would not have happened automatically.

It is necessary for untraceability reasons to use the same rings on every Monero fork when spending an output that exists on multiple forks.


DNS for the seed node lists are managed by the core team. Last I was aware, at minimum, fluffypony has access. The nodes themselves are contributed/managed by various individuals, organizations, developers/core-team members that have nodes with good uptime, bandwidth and fixed IP addresses.


What is PayBee and how is it related to Monero?

PayBee is a BitPay like payment processor. It will use Monero and Bitcoin as "default" currencies as far as I know. Fluffypony explanation of "what is Paybee" is as follows:

  It's a payment gateway I've been developing along with a few partners. We had to deal with a few false starts and issues along the way, but it's (finally) getting close-ish to release.

Source: https://www.reddit.com/r/Monero/comments/40gkul/what_is_paybee_does_it_have_something_to_do_with/

  Is it being worked on is a private repository?

As far as I know, yes. In addition, it has been in private beta for a few months now and merchants were, and are still, able to sign up to participate in it.


Relation between monero jobs (blob) and new blocks

Pools send a new job when they see a new blockchain height, in response to a getjob request, in response to a login request or sending a job to a miner with a new difficulty. prev_id will stay the same so long as the blockchain height is the same.
Almost exactly the same job. Each miners job is identical except for the jobs extra field in the blob which makes each job unique for each miner. The pool updates this field for each miner before sending.
This is up to the miner implementation. A miner should ideally stop mining a previous job when they are notified of a new job, but there's no harm in finishing the existing one before starting the new one as most pools will still accept shares from recent jobs.


There is no support for MoneroV in Freewallet. Unless they support the fork, you will not be able to claim MoneroV.

As a reminder, Freewallet controls your private keys. If you used a different application such as Monerujo, Cake Wallet, or X Wallet, you could restore your Monero (including possibly claiming coins) on another device.


How is the G constant calculated in the cryptonote protocol?

G is defined in the definition of the signature scheme, Edwards-curve Digital Signature Algorithm (EdDSA)in the case of Cryptonote and Monero.

As explained in this answer in crypo.SE :

  the base point is chosen pretty arbitrarily. As described in the Ed25519 paper, it arises from the choice u=9 in the original Curve25519 paper

The details of this choice are probably out of the scope of Monero.SE and more suited to crypto.SE.


There is no such thing yet, but is a a long wanted goal.

Progress along those lines was made in the last few months, with an automated build system based on Travis, maintained by a contributor under the username 'pigeons'.

I do not know of a timeline for future steps towards deterministic builds, though.


How to create a transaction offline using javascript?

mymonero has javascript code to create transactions which you can reuse (some surgery needed). Some of it runs binary blobs compiled from C++ though, which may not be what you want. See https://mymonero.com/.


Recommended configuration for wolf-xmr-miner xmr.conf with R9 290

With rawintensity, you're really looking for an optimum. So when changing it a little in either direction gives you less hashpower, you will know you found the right setting. I don't think it will affect heating much, especially if you're running the clocks at stock settings.


How can I set monero-wallet-rpc default password

You can start the wallet RPC with either of these flags:
--password arg                    Wallet password (escape/quote as needed)
--password-file arg               Wallet password file

You then won't be prompted to enter a password.


How to get decimal number out of a decrypted ecdhInfo field?

It is a 64 bit little endian unsigned integer.

If you're asking "how do I get a human amount out of an atomic unit number", divide by 1e12. cryptonote::print_money in the Monero source does this without using floating point operations (print the number, then manipulate the string).


The blob is the serialized block.

See: https://github.com/monero-project/monero/blob/9da6d2969bc50e028e59c4e9cd637ebe408294b7/src/cryptonote_basic/cryptonote_basic.h#L349 and https://github.com/monero-project/monero/blob/9da6d2969bc50e028e59c4e9cd637ebe408294b7/src/cryptonote_basic/cryptonote_basic.h#L366

It's essentially just binary data as a hex encoded string.

You also ask how the timestamp is encoded: it's a varint. See: https://developers.google.com/protocol-buffers/docs/encoding which describes varint encoding well.

UPDATE:

Given the long comment thread, here is the OP blob broken down.

Block blob for block at height 912345:

major version (varint): 01
minor version (varint): 02
timestamp (varint): f4bedfb405
prev ID: b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78
nonce (4 bytes): 6e060000
miner TX version (varint): 01
unlock time (varint): 95d837
vin count: 01
vin[0]:
  type (txin_gen): ff
  height (varint): d9d737
vout count: 04
vout[0]:
  amount (varint): ee84ddb421
  type (txin_to_key): 02
  key: 378b043c1724c92c69d923d266fe86477d3a5ddd21145062e148c64c57677008
vout[1]:
  amount (varint): 80c0fc82aa02
  type (txin_to_key): 02
  key: 73733cbd6e6218bda671596462a4b062f95cfe5e1dbb5b990dacb30e827d02f2
vout[2]:
  amount (varint): 80f092cbdd08
  type (txin_to_key): 02
  key: 47a5dab669770da69a860acde21616a119818e1a489bb3c4b1b6b3c50547bc0c
vout[3]:
  amount (varint): 80e08d84ddcb01
  type (txin_to_key): 02
  key: 1f7e4762b8b755e3e3c72b8610cc87b9bc25d1f0a87c0c816ebb952e4f8aff3d
extra size: 2b
extra: 01fd0a778957f4f3103a838afda488c3cdadf2697b3d34ad71234282b2fad9100e02080000000bdfc2c16c
end: 00

NB amounts are in atomic units, encoded as varints.


Do you experience much more crashes/restarts of xmr-stak with the latest 2.3.0 version (Vega 64 rig)?

At this time, with cryptonight_v7 you're not mining Monero. You should use the cryptonight_v8 algorithm with the latest xmr-stak 2.7.1 to mine Monero, but when the question was posted probably there was no v8.

Anyway, the new algo (before the v7 and now the v8) is more hungry with power consumption and you must use different settings to find a good sweet spot.

The new xmr-stak version provides you an autoconfig function pretty useful with double thread enabled. So, you can use it to find the best settings for your hardware.

Apart from that, the AMD blockchain driver (Aug 2017) is a BETA software and it can cause many issues. The latest Adrenalin is more stable and, enabling compute mode, it can give you same hashrate as blockchain driver.

Last, but not least, soft and hard restarts (or crashes) in the most part of cases are due to overclocking, undervolting or power issue. A VEGA card can require a lot of power during mining, so check if your PSU can handle all that hardware and try to set less aggressive settings for overclocking and undervolting.


How do ringct transactions use previous non-ringct outputs in a ring signature with ringct?

I'd say it's pretty straightforward. In the normal situation where input and output are both Pedersen Commitments, i.e.,

C_i = x_i G + a_i H
D_j = y_j G + b_j H

, the network confirms the consistency of the CT by checking

\sum_i C_i = \sum_j D_j + f H

where f is the fee. When converting non-RingCT outputs to RingCT outputs, you simply treat non-RingCT outputs just like the fee; i.e., the masks x_i are omitted and the network checks the following:

\sum_i a_i H = \sum_j D_j + f H

Put differently, the sender randomly picks the new masks y_j such that

\sum_j y_j = 0


XMR.to has slightly lower exchange rates (usally around 1%) than the big exchanges, but even for small payments they cover all Bitcoin onchain transaction fees and their transactions usually will be included in the next Bitcoin block so they have a pretty good fee estimator and/or are well connected with Bitcoin miners.

When creating a new payment on xmr.to you will get a "secret key" in form "xmrto-xxxxxx" which you should write down and you will be able to track your order here: https://xmr.to/track

Orders up to 0.1 BTC will be processed immediately and your Bitcoin transaction will land in the Mempool usually within seconds, you will receive a transaction ID which you will be able to track in every Bitcoin block explorer.


Opening Ledger with wallet v0.14.1.0 Boron Butterfly

As the error message says, you need to upgrade your Ledger Monero app to v1.3.1. Thereafter, you should be able to properly use your wallet.


When mining in a pool what does current effort actually mean?

Mining effort is just the number of submitted hashes divided by the actual difficulty. This calculation then provides how much "effort" the pool should provide to statistically find a block.

When a pool finds a block with a 500% effort, it means it took 5 times more hashes than it was "statistically" needed to find it. When a pool finds a block with a 50% effort, it means it took 2 times less hashes to find it.

As far as I know the only impact this information really has is for the PPLNS pools, this reward system is determined by proportion of your hashes in the PPLNS window of time before the moment block is found. Window of time equals to time required to reach usually 200% block effort.


What is the 'bootstrap node' when creating a monero wallet via the GUI?

In the GUI, bootstrap node is a remote node to use whilst also syncing the blockchain. This is different to a straight up remote node in that using a remote node will not also sync the blockchain to local.

With regards to dEBRUYNE_1's reddit post, what is described is to default to using a bootstrap node and then automatically switch to local node when the blockchain has fully synced.


Yes. Anyone who gains control of the TXT records would be able to change the address they reference. To answer your second question, you are correct that this would not affect any Monero received prior to the TXT record change, so your received funds would remain safe. This is why it is best to think of it as an alias to your address and not as the address itself.

One other security consideration with OpenAlias is that DNS lookups can leak information. Each time your computer does a DNS lookup, it is possible that the lookup is leaked and collected by a third party. The OpenAlias website recommends that you use DNSCrypt for lookups (https://dnscrypt.org/), and also suggests that is is ready to work with alternative DNS systems such as namecoin.

From their website (https://openalias.org/#implement):

  In order to ensure that lookups do not betray the user's privacy it is best to implement DNSCrypt from OpenDNS, and force resolution via a DNSCrypt-compatible resolver. Dependent on your use-case, you may choose to bake DNSCrypt into your software, or bundle dnscrypt-proxy along with your application.

At some point the Monero simplewallet may be updated to use DNSCrypt lookups, but right now it doesn't seem to. Until then, using OpenAlias would potentially leak information that your IP address intends to interact with that Monero address.


If I have a vanity address does it decrease my wallets security?

In terms of cryptography: no, unless the vanity generator is badly implemented, without a proper source of entropy.

Although, if you use an untrusted vanity generator, they could record your private key and send it somewhere. Good old trick.


Implementation of monero on other curves

There are two birationally equivalent variants of X25519, which are Curve25519 and Ed25519. Monero uses only Ed25519.

There might be performance reasons for using Curve25519 vs Ed25519 depending on whether you're doing variable base or double base scalar multiplication, but I can't think of a reason that Ed25519 would limit you functionally. Curves provide a trapdoor function, and you should be able to functionally achieve the same result with any curve.


Implementing Cryptonightv1 PoW algo change but miners are able to mine with both Cryptonightv0 or Cryptonightv1 now

The solution was that my checkpoints were messing everything up.  Once I got rid of the checkpoints everything worked correctly (this is a hard fork of an existing coin so I need the checkpoints in the final version but for testing I was using a new separate network starting at height 0.  I commented out the checkpoints and it works correctly now).


Which fork version is the py-cryptonight hash library using?

As of right now, it's using the latest version of CryptoNight (CNv2, as used in Monero hard-fork v9). CryptoNight lite is not used by Monero, neither is heavy. CN lite first appeared in Aeon IIRC and is (as is heavy) a different algorithm altogether.


First one to get in a block wins, there can be no other way as far as I understand. I mean, who has the authority to say which one came first?
For this, we have PoW and the blockchain - to avoid having to rely on "someone said this came first". Until it's mined, it's undefined.


CLI wallet on Mac unable to connect to local node on RPi

By default, monerod binds to localhost. So no external connetion will reach it. You need to launch monerod with the flag --rpc-bind-ip=xxx.xxx.xxx.xxx to allow external connections. If you want to open to the outside world, that would be --rpc-bind-ip=0.0.0.0. Of course, you'd also need to ensure your firewall alowed incoming connections on port 18081 (unless you chaned the port via --rpc-bind-port, in which case your firewall should use the port you specified).


How private is this transaction sequence?

If "someone" doesn't have access to any of the services, there's no way he can tell that the final TX is connected to you.

If "someone" had access to only ShapeShift data, he'd know to which Monero address you withdrew, and how much. He could suspect when you move those funds elsewhere but never be sure if it was you or it just so happened that someone else used your output as "decoy". Even if he assumed that you moved the coins, he'd have no way of telling to which address or how much. He'd just see that you maybe moved those (or part of, he can't tell) coins somewhere.

If "someone" had access to only MyMonero data (or forced MyMonero to collect whatever data it can), they wouldn't know from where your balance came. They wouldn't know who "you" are. The source and your ID would remain hidden. When sending, MyMonero could know the amount. If sending to a non-MyMonero user, they wouldn't know the destination address. If sending to a wallet also registered at MyMonero, they could also know the destination address.

If "someone" had access to both MyMonero and ShapeShift, they'd know who you are, how much you received and how much you sent. If sending to a non-MyMonero user, they wouldn't know the destination address. If sending to a wallet also registered at MyMonero, they could also know the destination address.

If "someone" got access to only recipient data, they wouldn't be able to trace it back to you. If they got the recipient data and ShapeShift data, they'd have a loose link but wouldn't be able to prove anything.

If "someone" got access to recipient, MyMonero and Shapeshift data, they could establish the link.

The only way to protect against someone coercing all involved services is to use an independent wallet instead of MyMonero and do some "churning" before sending to final destination. That way, even if someone had the recipient and ShapeShift data, you'd have fuzzed the trail enough to erase any suspicion.


Minimum recommended user knowledge requirements

Every user has a different background and intended use case for Monero. There is no officially defined knowledge set that is recommended to all users.

Instead, there are basic user guides and tutorials to help new users choose an appropriate wallet for their needs and get started mining Monero.

Generally, the Monero community advises against the use of exchanges and web wallets for storage of large amounts of Monero. Security and education are emphasized in importance to new users. Usage over investment is highly emphasized by members of the development team. It is not uncommon for newcomers to be advised not to buy Monero if their primary objective is speculation.

It is impossible to anticipate every possible question that Monero users and developers may have. One of the primary goals of this StackExchange site is to create an easily searchable database of common questions and useful answers for the Monero community.

Since Monero development is ongoing, the education effort must continually evolve with the changing technology.


What is elliptic curve cryptography and why is it important to Monero?

Elliptic curve cryptography (ECC) is a form of public-key cryptography where mathematical properties of elliptic curves are used to ensure security of cryptographic methods used. This allows to perform the following in a secure way:

Public key encryption, where the sender can encrypt a message using the recipient's public key, and the recipient can decrypt it using his private key.
Signature, where the signer can sign a message using his private key, and anyone can verify the signature using the signer's public key.
Shared secret key, where any 2 parties can securely agree upon a shared secret key, which is then normally used as the key for symetric encryption to encrypt any further messages between the 2 parties.

It is important to Monero, because it facilitates important operations such as key-pair creation (used for generating Monero addresses), Elliptic curve Diffie-Hellman (used in the Monero stealth-address scheme), and signing and verifying transactions. The curve used by Monero is one of the SafeCurves, and is the Curve25519, widely used for many other secure applications.

For further reading on ECC, here's my go-to link.


Can we practically compensate full nodes

The short answer is no, at least not safely.

Something we've discussed before is for full nodes to (completely optionally) include a donation address in their handshake, with separate addresses on clearnet and i2p (to prevent fingerprinting). Then when a wallet is building a transaction it can ask the daemon for a random donation address from the list of outbound nodes it is connected to, and include a tiny fee (say 1/2 or 1/4 of the transaction fee) paid to that address.

Because this is opt-in approach where not everyone lists an address and not every wallet participates in donating, such a scheme doesn't run the risk of over-incentivisation. The reason that over-incentivisation is bad is that it will lead to abuse of the system - an attacker will run thousands of pseudo-nodes on a VPS just for profit. This donation-driven, opt-in system, on the other hand, should allow full node users to cover their electricity and bandwidth costs as the cost in running a full node scales to Bitcoin levels.

The other nice thing about this is that we can always just nuke the functionality on the wallet side if it starts getting abused.


What are the best parameters for W0lf miner with a R9 380 GPU?

the only parameters that actually change anything are rawintensity and worksize. try increasing rawintensity a little bit at a time until it the miner crashes, then back off. you could also change worksize down to 8 and then repeat increasing the rawintensity.


Do sub-addresses and disposable addresses have their own private viewkeys and spendkeys?

No.

Given an output pubkey P in a new transaction with its tx pubkey being R, you can recognize it as your incoming transfer by using your private viewkey a, looking for P - Hs(a*R)*G in your hashtable and finding an entry recoding the sub-address's index j. Its private key P=x*G is obtained as x = Hs(a*R) + b + Hs(a || j). So you need both of the original private view and spend keys for receiving funds transferred to sub-addresses and disposable addresses.


Multisig wallets cannot spend non rct outputs

This was not implemented. Multisig came after rct, so there should not be pre-rct outputs in multisig wallets. It is possible to have code that spends those, it's just that there is no such code currently.


Is there a service to enter in Monero private view keys to see current balance?

No. You cannot get a balance using a private view key because you can only see incoming transactions with your private view key, not outgoing spends, which would be needed to calculate a balance.


Are there any games which use Monero as money?

Not explicitly, no.

The closest example would be CryptoKingdom.  They use their own in-game currency, but I believe it's directly proportional to Monero supply and/or is easy to cash out with and transform into Monero.


Are multiple base points or generator points used for the ed25519 curve in monero / CN?

Yes. There is nothing special about the base point G that you mention. It's just an arbitrary point agreed upon by convention to be used to transform private keys (scalars) into public keys via scalar multiplication. Scalar multiplication with points other than G happens during the Diffie Hellman exchange which is part of the generation of stealth addresses. There is also another base point H which is used for creating Pedersen Commitments. H is specifically chosen such that the discrete logarithm with respect to G is unknown (i.e. H = nG, but H was chosen such that n will never be known).
Because of (1.), you now know that scalar multiplication is done with arbitrary points and not just with G.
EC points exist in a 2D finite field, so can be represented with two coordinates. However, because the Ed25519 curve is symmetrical across the y-axis, it's possible to represent a point simply with the y-coordinate and a sign bit that indicates which of the two possible x-coordinates is the correct one. This is called compressed representation, and is how Monero EC points are stored on the blockchain.

5866666666666666666666666666666666666666666666666666666666666666 is a little endian hex representation (i.e. the byte order is reversed) of the decimal number 46316835694926478169428394003475163141307993866256225615783033603165251855960, which is the y-coordinate stated in the link you've mentioned.


What exactly happened in the 2019 Nov Monero CLI hack?

Please see:

https://web.getmonero.org/2019/11/19/warning-compromised-binaries.html

And:

https://www.reddit.com/r/Monero/comments/dyfozs/security_warning_cli_binaries_available_on/

  What exactly happened and how can it be prevented in the future?

Further information will become available once the full investigation is complete. Until then, there is no point in speculation.


Coming from bitcoin, are there change address with monero?

No.

Well, kind of. There will be a "change output" but it's not your address. In fact, Monero address works as an instruction to create many unique one-time public keys which actually holds the funds. Your wallet address never appears on the blockchain.

Each of those unique one-time public keys has a corresponding unique private key (which you can recover using your wallet's private spend key). THOSE work similar to Bitcoin address. So, when comparing with Bitcoin, it would be as if someone followed some instruction to generate a new Bitcoin address for you, sent the funds there, and you can auto-magically recover the private key and the sender can't :)

When spending, you're actually spending those one-time public keys. If, for example you have one of 10 XMR and one of 2 XMR, and want to send 11 XMR, the TX would create 2 brand-new one-time keys, one of 11 XMR for your recipient, and one of 1 XMR back to your wallet. Without some secret key, nobody is able to tell to which address those newly-created one-time keys belong.


The pool sends the job to the proxy.

The jobs blob already has extra space reserved which the proxy adds a worker id to so that each worker (miner) connected to the proxy has their own unique blob to hash.

The target of the job is adjusted by the proxy for each of its connected miners based on how quickly each miner is hashing jobs.

When miners send results to the proxy, they are forwarded onto the pool (after some basic checks).


Does a CPU or GPU mine better on the RandomX algorithm for Monero mining?

RandomX is designed to run efficiently on general purpose hardware, e.g. CPUs and to some extent, GPUs.

Quoting the project README:

  RandomX is a proof-of-work (PoW) algorithm that is optimized for general-purpose CPUs. RandomX uses random code execution (hence the name) together with several memory-hard techniques to minimize the efficiency advantage of specialized hardware.

And quoting the section on GPUs:

  Note that GPUs are at a disadvantage when running RandomX since the algorithm was designed to be efficient on CPUs.

Note that whilst GPU mining wont be as efficient as CPU mining, GPU mining is still effective on RandomX, it just wont have the same advantage it currently has over CPU mining with the current algorithm, CryptonightR.


The exception unknown software exception (0x40000015) occurred in Monero Wallet

Firstly use the latest release 0.12.3: https://github.com/monero-project/monero-gui/releases

Also, as dEBRUYNE mentioned in a comment, try running as administrator.


I'm using a Mac OS right now and looks like it will be saved in /Users/[Your-User] when you just type the wallet without adding any path.

There should be a filename their with the name of your wallet.


Getting balance of my address connecting to a remote node via RPC API?

You'll want to use the monero-wallet-rpc. Documentation for the API methods are here.

Note, this is a different application than the main Monero daemon monerod.

UPDATE based on comments:

If you don't want to work with wallet files you will need to implement something like this. You'll see it invokes a daemon RPC method /get_address_info with parameters address and view_key.


What is known about Nicolas van Saberhagen?

Reasonably, we have no real idea. This person or group is currently unknown just like Satoshi Nakamoto. The text in this Wikipedia article sums up some thoughts in the community about the creator(s) of CryptoNote:

  The author of the white paper went by the name Nicolas van Saberhagen,
  although like Satoshi Nakamoto (the author of the bitcoin white paper)
  that name is likely a pseudonym. Saberhagen's true identity and
  location remains unknown. Some have claimed that the real creator is
  someone in the bitcoin community. Adam Back, Nick Szabo and even
  Satoshi Nakamoto himself have been floated as possible
  suspects, but there is little to no evidence actually supporting
  those claims.

  Stanford Bitcoin Group’s possible involvement in creation of the
  CryptoNote protocol has also been discussed. Prior to CryptoNote
  cryptocurrency protocol, the domain cryptonote.org hosted an encrypted
  message application also named CryptoNote. This application was
  developed by the members of the Stanford Bitcoin Group but had not
  received wide recognition. This website currently hosts the CryptoNote
  technology.

Further reading:

http://web.archive.org/web/20141205173019/http://thebitcoinnews.com/2014/11/24/bytecoin-satoshis-new-project/

http://bytecoiner.org/bytecoin-source-of-origin/

https://medium.com/@AckermanRonald/stanford-wide-gate-steep-steps-ad95cfccca21


Which is the unit of the global difficulty?

The Monero network targets blocks to be mined at 120 seconds, using the difficulty so that hash_rate = difficulty / block_time, ie difficulty = hash_rate * block_time.

Unit analysis gives the difficulty unit to be hashes (H/s times s).

It is the expected number of hashes spent looking for a block.


Are AMD cards easier to mine with than NVidia?

Yes. The AMD miner has been crowdfunded whereas the NVIDIA proposal didn't get through.

You can see here how to set up AMD miner for ubuntu.


How do I connect the GUI wallet to a TLS remote node?

Neither the CLI or GUI have support for SSL RPC connections. Therefore you have to proxy both server and client over SSL. You can setup a client stunnel proxy to point to the node that is fronted by an SSL proxy and then in the GUI, specify the remote node as localhost and your stunnel client port.


Permission denied error for monero-blockchain-blackball

monero-blockchain-blackball is seeing that the monero v6 blockchain has incorrect block, and is trying to fix it, but the blockchain is opened read only, so it's failing.
This is a bug, since it's expected that the v6 blockchain is borked since people continued mining on it with obsolete software.
Please file this on github.com for the developers to fix it.


What is the optimal configure.json setting for mining Random XL using xmrig on Loki?

Your fallback rx object only specifies 2 threads with no affinity. Add the following into the cpu object to yield 16 threads with no affinity:

"rx/loki": [
       -1,-1,-1,-1,-1,-1,-1,-1,
       -1,-1,-1,-1,-1,-1,-1,-1
    ],

Replace the -1's with CPU IDs to affine the threads to specific CPUs.

Documentation here.


How to build and run xmr-stak-amd on linux

Please check if there is a folder called "bin" in the same folder that your compiled the miner. If there is, cd to it and see if the binary is there.


How to get the base transaction hash from the blocktemplate_blob

"prefix", "base" and "prunable" just refer to parts in the transaction.

Given the transaction hash is:

H(H(prefix) || H(base) || H(prunable))

"prefix" refers to these fields.

"base" refers to the signatures that follow the prefix.

"prunable" refers to any prunable parts of a transaction.

Here is the source that calculates transaction hashes in Monero.

Important to note that "base" referenced above and "RingCTBase" as referenced in your linked answer, do not mean the coinbase/miner transaction. They just refer to a specific part in a transaction.

Now, to edit the miner transaction returned in get_block_template, you would need to deserialize the blocktemplate_blob to a block structure, edit the transaction in question, serialize back to a template blob and construct a new hashing blob.


Can you use the same 24 word seed from other wallets like ledger nano s to generate a monero address?

The list of English words available to create a bitcoin seed is not the same as the list of English words available to create a monero seed.

For example, the first few words of the former are "abandon ability able about" whereas the first few words of the latter are  "abbey abducts ability ablaze".

Monero only considers the first three letters of each seed word (for English, four for other languages) - in this case abandon, for example, would result in aba which is not the beginning of any valid monero seed word. That is not going to work well...

And the number of words in each list is not the same either so you could not even convert the words into indices and back.


How is Poloniex keeping track of their user's Monero balances when they do not use any Payment ID's?

Last I was aware, Poloniex issues users with a Monero integrated address, which embeds a payment ID in the address. You can easily verify this by the address length - integrated addresses are 106 hex digits long.

As the Monero community has already signalled that payment IDs are being deprecated, subaddresses should be used instead moving forwards.


Your funds are not stored on your laptop, they're stored on the blockchain. Copies of the blockchain are stored on perhaps hundreds of thousands of computers all over the world.

What you need to keep safe is your Monero seed. This is the credential that you use to scan the blockchain to see what funds have been sent to you, and to prove you have the right to spend those funds.

If you keep your seed (the 25 word phrase) safe, then even if your laptop breaks, you can at any point in the future download and install a fresh copy of the Monero wallet software on another computer and have full access to view and spend your funds.

If you are using your wallet to send funds to people, your wallet file on the computer you are using will build up a log of your outgoing transactions. Because of Monero's privacy mechanisms, if you lose access to the wallet file, then you can't later figure out the Monero wallet addresses of people you've paid. All that will be remembered is that you did make outgoing payments on particular dates.

On Windows, your wallets are typically stored in your Documents\Monero\wallets folder.

On Mac, your wallets are typically stored in the monero\wallets folder.

Therefore for full access to view and spend your funds, you only need to keep a safe copy of your 25 word seed. But to also remember your outgoing transaction history, you'll also want to keep regular backups of the wallet file on the computer you use to make those transactions.


How to download latest builds from the Monero Buildbot?

You can download the files for the build you would like to examine under the "Steps and Logfiles" section. For Windows, you will often find a .zip file. The file you can download is underlined in red.

Not all builds will have files you can download and run.

Finally, since these are not official releases, they may not be stable or as safe as official releases. Use these only for testing purposes with care, not for storing any Monero.


Whonix problem: Wallet Address Changed, Coins Lost

A Monero mnemonic seed is a word based representation of a secret spend key. It is essentially the secret spend key. If you use the same set of words, you will end up with the same secret spend key, which deterministically yields the same public spend key. Since you have a seed in the first place, your secret view key is also deterministically derived from that seed (it is possible to have independent view and spend keys, but you don't get a seed for those). In turn, this deterministically yields the public view key. Both public view and spend keys deterministically yield your standard address. So from a seed, you get an address.

Note that some software (mostly trezor and ledger I believe) don't do this, but you did not mention you use those so I'll assume you don't.

So the most likely explanation is that you did not restore the same seed. Make really sure you copied the seed correctly from the first machine to the restoring machine. If you're really sure you used the same seed and the addresses are still different, then you could copy the keys file (if you name your wallet BLAH, then the keys file will be named BLAH.keys) to the new machine and open it without restoring from seed. Then file a bug on https://github.com/monero-project/monero and includes details like your monero software version, whether both machines are 32 bit, their architecture, and anything else that seems relevant.

If you keep the keys file, you should be able to see and use your monero whenever your p2p connection gets fixed. The keys file contains the secret keys (which are another representation of the seed).


In layman's terms, cryptonote, which is used by monero, is unable to find or create the file .daemon_lock1 and the directory C:\ProgramData\bitmonero2. You can browse to C:\ProgramData to see if the bitmonero directory currently exists.

If it does exist from previously running the CLI version of bitmonero, this problem is likely caused by some lack of permissions where the GUI wallet is not seen as a user that's allowed write access to this folder in the ProgramData directory. From what I understand, only the user who creates the directory has write access3 by default, although I don't fully understand the restrictions set by Windows and monero. I would expect the GUI wallet is supposed have access.

While I don't know exactly where the conflict is, here are a couple of ways you can troubleshoot. Shutdown any monero programs currently running. Check the Windows Task Manager (ctrl + shit + esc) to make sure nothing like monerod.exe is currently running. You can try launching the GUI again and see if it is recognized as a user that has access this time. If it works, then stop here. If not, continue.

If it is still closing with the same error messages, make sure everything monero related is shutdown again. Rename the directory C:\ProgramData\bitmonero to something else like C:\ProgramData\bitmonero-backup. Now launch the GUI wallet which should be able to create this directory itself and you can test whether it launches okay.

Important: If you had previously synced the blockchain and want to restore it, the directory C:\ProgramData\bitmonero\lmdb contains any blockchain data you had previously downloaded and synchronized. Particularly the file data.mdb contains your blockchain data. Shutdown any bitmonero related software first. You should be able to move the old data.mdb from your C:\ProgramData\bitmonero-backup\lmdb directory into the newly created C:\ProgramData\bitmonero\lmdb directory. If the new C:\ProgramData\bitmonero\lmdb contains data.mdb you can delete that before replacing it with your backup data.mdb. Then, delete lock.mdb  and run the GUI wallet. It will create a new lock.mdb file.


You can set up a private testnet according to these instructions

Change the folder names according to your preference, and remove the --testnet flag to use mainnet network parameters.


Ubuntu 16.04 : Monero wallet stopped working

After restarting my laptop this issue has gone away.
I suppose it was a driver that didn't boot up correctly or something.

I'm glad it works again
I'll download and use the new wallet when my blockchain has synced


How can i retrieve XMR sent to my Monero wallet without a payment ID?

You do it the same way you do with a payment ID, since payment ID has no relevance to receiving monero to your wallet.

If you don't see the incoming monero, then your wallet or daemon are probably not fully synced yet. Run "status" in monerod, and make sure it has synced to 100%. Then make sure the wallet has connected to the daemon and finished scanning.

In any case, make sure you use the latest version of the Monero software. If you're using a version prior to 0.11.0.0, it will not be able to fully sync. 0.11.1.0 is the recommended version, as it fixes a couple sync bugs with 0.11.0.0.

You'll have to be clearer as to what requires a payment ID in your second to last paragraph, but I suspect there is no requirement, just an option.


What is a scenario when the other members of the ring signature would have multiple keys?

There is only ever one public key per ring member. Transactions are never referenced by ring signatures.

There is one ring per real output being spent. However, it is not the case that there is a separate ring signature per ring. There is a single MLSAG ring signature that signs all rings as part of the same signature.

Therefore, when the MRL-0005 document says "Suppose that each signer of a (generalized) ring containing n members has exactly m keys", "n members" refers to public keys and "m keys" refers to private keys. So if you were spending 3 inputs at a ring size of 7, you'd have n=21 and m=3.


Difference between subaddresses and integrated_addresses

Integrated addresses are just standard addresses but with an embedded payment ID. Anyone can decode the integrated address and determine the standard address it is associated with. However, when a transaction is sent to that integrated address, the payment ID is encrypted on the blockchain. Therefore no one (other than the private view key holder that issued the integrated address) can tell that the integrated address was used in a transaction.

Subaddresses are deterministically derived wallet addresses that are grouped by wallet accounts.

They are both useful, though subaddresses are newer and preferable in most use cases.


How do I generate a Trezor Monero wallet with the CLI (monero-wallet-cli)?

Note that Monero support is currently only available for the model T.
Windows / Linux / Mac OS X
We first have to ensure that we're sufficiently prepared. This entails the following:

This guide assumes you have already initialized your Trezor device and thus generated a 12 or 24 word mnemonic seed.

You need to run / use CLI v0.17.1.3, which can be found here, on the downloads page of the official website, or on Github.

Make sure your firmware is up to date.

Your Trezor needs to be plugged in.

Either your daemon (monerod.exe (Windows) or monerod (Linux and Mac OS X)) should be running and preferably be fully synced or you should connect to a remote node.

Now that we're sufficiently prepared, let's start!
Windows

Go to the directory / folder v0.17.1.3 monerod.exe and monero-wallet-cli.exe are located.

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

Now type:
monero-wallet-cli.exe --hw-device Trezor --generate-from-device <new-wallet-name>
(Win 7 + 8)
.\monero-wallet-cli.exe --hw-device Trezor --generate-from-device <new-wallet-name> (Win 10)

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
monero-wallet-cli.exe --hw-device Trezor --generate-from-device MoneroWallet (Win 7 + 8)
.\monero-wallet-cli.exe --hw-device Trezor --generate-from-device MoneroWallet (Win 10)

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

If you enabled the passphrase feature on the Trezor device (skip this step if not), a Device requires attention will now be displayed. The device will ask you whether you want to enter your password on the host (your system) or the Trezor device. Choose your desired option.

A Device requires attention will now be displayed. The device will ask you whether to export the watch-only credentials. Proceed with Yes.

Your Trezor Monero wallet will now be generated. This should be almost instantly and definitely not take longer than a minute.

The CLI will now display a No restore height is specified. message. Use Y or Yes to proceed.

The CLI may now display a Restore height x is not yet reached message. Use Y or Yes to proceed.

The CLI will, if using your own (local) node, display a message about background mining. Proceed with your desired answer (i.e. Yes or No).

The Trezor device will now ask you to confirm the start of the wallet refresh. After confirmation, monero-wallet-cli.exe will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Trezor Monero wallet in conjunction with the CLI.

Mac OS X

Use Finder to browse to the directory / folder monero-wallet-cli (CLI v0.17.1.3) is located.

Go to your desktop.

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

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

Now type:
--hw-device Trezor --generate-from-device <new-wallet-name>

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
--hw-device Trezor --generate-from-device MoneroWallet
Note that aforementioned text will be appended to the path of monero-wallet-cli. Thus, before you hit enter, your terminal should look like:
/full/path/to/monero-wallet-cli --hw-device Trezor --generate-from-device <new-wallet-name>
Where the full path is, intuitively, the actual path on your Mac OS X.

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

If you enabled the passphrase feature on the Trezor device (skip this step if not), a Device requires attention will now be displayed. The device will ask you whether you want to enter your password on the host (your system) or the Trezor device. Choose your desired option.

A Device requires attention will now be displayed. The device will ask you whether to export the watch-only credentials. Proceed with Yes.

Your Trezor Monero wallet will now be generated. This should be almost instantly and definitely not take longer than a minute.

The CLI will now display a No restore height is specified. message. Use Y or Yes to proceed.

The CLI may now display a Restore height x is not yet reached message. Use Y or Yes to proceed.

The CLI will, if using your own (local) node, display a message about background mining. Proceed with your desired answer (i.e. Yes or No).

The Trezor device will now ask you to confirm the start of the wallet refresh. After confirmation, monero-wallet-cli will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Trezor Monero wallet in conjunction with the CLI.

Linux

Go to the directory / folder v0.17.1.3 monero-wallet-cli and monerod are located.

Open a new terminal

Now type:
./monero-wallet-cli --hw-device Trezor --generate-from-device <new-wallet-name>

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
./monero-wallet-cli --hw-device Trezor --generate-from-device MoneroWallet

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

If you enabled the passphrase feature on the Trezor device (skip this step if not), a Device requires attention will now be displayed. The device will ask you whether you want to enter your password on the host (your system) or the Trezor device. Choose your desired option.

A Device requires attention will now be displayed. The device will ask you whether to export the watch-only credentials. Proceed with Yes.

Your Trezor Monero wallet will now be generated. This should be almost instantly and definitely not take longer than a minute.

The CLI will now display a No restore height is specified. message. Use Y or Yes to proceed.

The CLI may now display a Restore height x is not yet reached message. Use Y or Yes to proceed.

The CLI will, if using your own (local) node, display a message about background mining. Proceed with your desired answer (i.e. Yes or No).

The Trezor device will now ask you to confirm the start of the wallet refresh. After confirmation, monero-wallet-cli will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Trezor Monero wallet in conjunction with the CLI.

A few final notes:

I'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet. Note that, upon recreating / restoring the wallet, you ought to append the --restore-height flag (with a block height before the height of your first transaction to the wallet) to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux). More information about the restore height and how to approximate it can be found here.

If you use a remote node, append the --daemon-address host:port flag to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux).

You only have to use the --generate-from-device flag once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the CLI. That is:

[1] Make sure your Trezor device is plugged in.
[2] Open monero-wallet-cli
[3] Enter the wallet name of your Trezor Monero wallet.
[4] Enter the password to open the wallet.
If the Trezor Monero wallet files are not in the same directory as monero-wallet-cli, you ought to open monero-wallet-cli with the --wallet-file /path/to/wallet.keys/file flag. Alternatively, you can copy the Trezor Monero wallet files to the same directory as monero-wallet-cli.

Upon closing the wallet, make sure to exit monero-wallet-cli first by typing exit. You can, thereafter, remove / unplug the Trezor device.

If you have any further questions or need assistance, please leave a comment in this thread.


Imagine a government wants to ban XMR. Is it possible for them to do so?

Yes a government could pass a law banning the use (mining, running a node, participating in a transaction, etc) of Monero.

Even assuming perfect compliance with the law in countries where Monero is banned the blockchain will continue on so long as miners somewhere in the world support it and nodes relay the transactions.

Miners and nodes exist in many different jurisdictions so even a coordinated effort between multiple governments to shut them down would miss many countries. Nodes can be easily set up at remote data centers and efforts such as Kovri will make it much harder to identify the locations of Monero nodes in the future.

  Is it possible for an adversary to shut Monero down?

From a practical standpoint, forced shutdown at the direction of a central actor would be almost impossible. Every Monero user has the ability to control their own private keys, mine and run their own node.

Because Monero is used worldwide, in the short term 51% attacks are likely a more legitimate adversarial threat to the Monero blockchain than regulation. The cost of such an attack would be more expensive today than it was two months ago and will vary over time based on the hash rate of the attacker compared to the rest of the network.

Other adversarial threats include the and exploitation (prior to any fix) of flaws in the cryptography or implementation of Monero or in the long run quantum computing. In the case of Monero cryptography and implementation issues the Monero Research Lab and the growing list of Monero contributors continually search for and attempt to solve vulnerabilities. Quantum computing is not a threat in the short term, nor is it unique to Monero. Monero Research Labs plans on spending time identifying and finding solutions to quantum computing problems before they arise.


monero-wallet-cli and monerod has different block height

...monerod lists height as 1273180/2365980

Your daemon is not fully synchronized.
When fully sync'ed, you won't get the wallet message mentioned.


What is the block header's minor_version for?

It's used to mark which consensus version the mining node supports. It used to be there was a voting mechanism so that consensus changes would happen when enough nodes would claim the new version, but that was not working well, and deemed too complex, so it's now just indicative.


What's the difference between ring signatures and RingCT

...what is the difference between ring signatures and RingCT?

RingCT is really just an umbrella term that encompasses Ring signatures and Confidential Transactions, which they themselves are then are made up of other components, such as MLSAG/CLSAG signatures, Bulletproof range-proofs and Pedersen commitments etc etc, which in turn are made from other things such as curve points.

Do ring signatures exist only inside RingCT

In Monero, yes. As mentioned above, RingCT is the umbrella term used here for which ring signatures fall under.

...some of the documentation about Monero no longer applies in its current version

The most up-to-date documentation is the code, closely followed by Zero to Monero [pdf] and papers published by the MRL (Monero Research Lab).


How were Monero elliptic curve constants chosen?

Although it wasn't clear to the reviewers at the time, the constants are standard ed25519 constants from DJB et al. You can read about it here, especially section "Choice of curve" starting on the bottom of page 7.


After major coin issuance, what must the minimum XMR price be to incentivize network security?

This is kind of a subjective question. Currently the block reward is ~ 10.4 XMR per block or 5.2 XMR per minute. When the tail emission kicks in, the block reward will be 0.6 XMR per block (assuming 2 minute blocks) or 0.3 XMR per minute. If we further assume miners are currently mining at an equilibrium then the price should be approximately 17 times as high to sustain the current hashrate. However, hashrate usually lags price and thus it could be that miners are still mining at a significant profit instead of an equilibrium. In addition, it could be that miners are further optimized in the future, which results in an increase in hashrate for the same amount of cost to a miner.


the link to the original code base is maintained

Depends what you mean by "link". There is a link to the original code that is maintained whether you fork publicly on GitHub or whether you clone to a private repository.

However, it would make it harder to do things like issue pull requests if you have a clone instead of a fork. See https://stackoverflow.com/questions/6286571/are-git-forks-actually-git-clones

I assume you are just experimenting, which is why you don't want the world to know the IP addresses of your personal test nodes. Obviously if you ever release your cryptocurrency to the public for them to use, you will necessarily leak information about the genesis block and seed nodes whether they have the source code or not.

There is only a security risk associated with disclosing the IP addresses of your personal test nodes if you aren't securing your OS properly, if you fail to launch publicly accessible nodes in "--restricted-rpc" mode, or if it turns out that there exists or that you introduce a bug into the node code that allows an exploit. If these are test nodes, then you should just firewall them off so that only you can access them.

There is no risk to people knowing your genesis block, unless perhaps you are scared that someone else is going to start competing with you to mine your cryptocurrency. But you can mitigate that by just creating a fresh genesis block when you're ready to launch your cryptocurrency to the public.


Why are web miners mostly mining monero?

Monero is one of the coins which use an ASIC resistant PoW algorithm (Cryptonight), which means ASICs for it are expensive to make, so CPU have a good shot at mining it, contrary to most other coins, where ASICs and/or GPUs leave CPUs with pretty much no chance.


How does one compare Monero's hashrate with the hash generating power of the world's supercomputers?

Two months ago, Monero core developer smooth said:

  Monero's mining network is comparable to a low top-10 supercomputer. It's not invulnerable to all attackers but it is a significant amount of security relative to the value of the coin and what could be achieved by attacking it.

Over the past two months Monero hashrate has grown about 50%. The worlds top 100 supercomputers would have the ability to capture a very large majority of the Monero network hashrate. It would be expensive to attack Monero (relative to its current marketcap) but far from impossible at this time.


Is there a way to view and/or calculate the value of all utxo's?

I don't think a utxo method is possible, because the blockchain is opaque.  There are no unspent transaction outputs on the Monero blockchain, in other words.

  There are no unspent transaction outputs on the Monero blockchain, in other words.

The above is a generalization, that isn't true in all cases.  There are certain instances where an output can be shown to be provably spent.  Nevertheless, the vast majority of outputs on the blockchain are not able to be provably spent.

Additionally, since RingCT, amounts in each new RingCT output are masked.


How do I know I'm on the main blockchain?

The "main" blockchain is the blockchain that follows consensus protocol with the most amount of work behind it, which almost universally means the blockchain with the highest height.

Here we have the chain your node is on and 5 alternate chains, each of which are 1 block long and at some depth. Depth refers to how many blocks behind that chain is from the main chain. If we add the heights to the depths for each alternate chain, we'll get the same answer: 1270499. That's the height of the main chain, which is higher than all the alternates.

In this case, even the closest alternate is 72 blocks behind, meaning it would need to catch up by 72 alternate blocks in order to surpass the main chain. Once an alternate chain gets to a certain depth, the daemon will forget about it, as it becomes precipitously less likely that the blockchain could ever reorganize around that alternate chain due to the amount of work that would be required to do so.


Firstly it looks like the job you have is for a mining proxy, not a miner.

A miner hashes a blockhashing_blob. To get a block hashing blob (which answers point #1) you have to update the blocktemplate_blob (after converting the hex to binary) with the data you want in the reserved space (at offset reserved_offset), then get a hashing blob (which in the monero codebase you can use get_block_hashing_blob - which is what the pool uses in one of it's node modules). Hash the hashing blob by incrementing the nonce in the hashhing blob until your hash is below the target difficulty (note also the target difficulty needs a conversion like target = 0xFFFFFFFFFFFFFFFFULL / (0xFFFFFFFFULL / ((uint64_t)target)). This is all a little redundant though because a pool will give you a hashing blob when the client is a miner, not a proxy.

Point #2 height is the blocks height, target_diff is the target difficulty. The miner is expected to find a hash to this target.

Point #3 just connect to any pool with an existing miner whilst doing a network trace.


Can you add a payment ID to a subaddress during an exchange withdrawal?

A payment ID is part of a transaction, not an address. Therefore, yes, if the exchange supports adding a payment ID field, it will be added to the transaction and you can view the payment ID in your wallet incoming transfers.


Because I couldn't find anything and didn't receive any help here, I wanted to share what I ended up doing to help others in the future. This is what I did to mine on NiceHash on OSX Sierra:

Install Docker
Open Terminal
Run docker run hmage/cpuminer-opt -a cryptonight -o stratum+tcp://cryptonight.usa.nicehash.com:3355 -O [YOURMONEROADDRESS].[YOURWORKERNAME]:x


How do I generate a Ledger Monero wallet with the GUI (monero-wallet-gui)?

Before we start, first two notes:

The Ledger Monero App is available for both the Ledger Nano S and the Ledger Nano X.

If you are using Windows or Mac OS X and run active AV (AntiVirus) software, the AV software will likely quarantine the binaries (i.e. the .zip file (Windows) or .tar.bz2 file (Mac OS X)) you download from the downloads page of the official website. To resolve this issue, I'd advise to use this guide.

In addition, we have to ensure that we're sufficiently prepared. This entails the following:
Windows

This guide assumes you have already initialized your Ledger device and thus generated a 24 word mnemonic seed.

You need to run / use GUI v0.17.2.1, which can be found here, on the downloads page of the official website, or on Github.

You need to install the Ledger Monero app.

Your Ledger needs to be plugged in and the Ledger Monero app should be running.

Ledger Live (the desktop application) should be closed.

Mac OS X

This guide assumes you have already initialized your Ledger device and thus generated a 24 word mnemonic seed.

You need to run / use GUI v0.17.2.1, which can be found here, on the downloads page of the official website, or on Github.

You need to install the Ledger Monero app.

Your Ledger needs to be plugged in and the Ledger Monero app should be running.

Ledger Live (the desktop application) should be closed.

Linux

This guide assumes you have already initialized your Ledger device and thus generated a 24 word mnemonic seed.

You need to run / use GUI v0.17.2.1, which can be found here, on the downloads page of the official website, or on Github.

You need to install the Ledger Monero app.

You may have to add some udev-rules. A script can be found here.

Your Ledger needs to be plugged in and the Ledger Monero app should be running.

Ledger Live (the desktop application) should be closed.

Now that we're sufficiently prepared, let's start! Note that the following instructions are general. If anything is OS specific I'll mention it explicitly.

Browse to the directory / folder GUI v0.17.2.1 is located.

Open v0.17.2.1 monero-wallet-gui.app (Mac OS X) or monero-wallet-gui.exe (Windows) or monero-wallet-gui (Linux).

If it tries to open an existing wallet, click on the Cancel button. This will bring you back to the wizard.

On the first page of the wizard, select your desired language.

On the second page of the wizard, you will have to select a mode. There are three modes, namely Simple mode, Simple mode (bootstrap) and Advanced.

In Simple mode mode, the GUI wallet will automatically connect to a remote node and have a simple interface. This mode excludes the need for the blockchain sync and ensures you can immediately use the wallet. However, it weakens your privacy insofar as the remote node will be able to see your IP address as well as associate any of your transactions with your IP address. Besides, using a remote node does not contribute to the strength and decentralization of the network.
In Simple mode (bootstrap) mode, the wallet automatically connects to a remote node whilst syncing your own (local) node in the background. The wallet will subsequently switch to your own (local) node once it is fully synced. This allows you to immediately use the wallet while still eventually using your own (local) node (which is optimal for privacy and contributes to the strength and decentralization of the network). Additionally, this mode has a simple interface as well. This mode is the default and is thus recommended by the developers for new users.
In Advanced mode, you will perform the blockchain sync from scratch (which may take from 10-14 hours (with an SSD) to several days to complete (with an HDD) and requires approximately 75 GB of free disk space) without connecting to a remote node. Advanced mode also contains all features that were deemed as advanced by the developers (and thus were left out of the simple mode). Note that you won't be able to properly use your wallet until the blockchain sync from scratch has been completed. Lastly, Advanced mode allows you to customly set a remote node (in case you, for instance, want to connect to your own remote node).

On the third page of the wizard, choose Create a new wallet from hardware device

Enter a new Wallet name

Make sure the Create a new wallet from device option is selected.

Make sure the Device name is set to Ledger

Go to the next page.

The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.17.2.1) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one caveat. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.

You may have to hit confirm twice before it proceeds.

Your Ledger Monero wallet will now be generated. Note that this may take up to a few minutes. Furthermore, there will be no immediate feedback in the GUI nor on the Ledger.

Enter a password for your wallet. Note: this password is not required / needed to recover the Ledger Monero wallet.

Proceed to the next page, which will provide an overview (note: there will be an additional setup page in case you chose Advanced mode, please see the Addendum).

Press Use Monero.

Congratulations, you can now use your Ledger Monero wallet in conjunction with the GUI.

Addendum: (in case Advanced mode was chosen)
On the Daemon settings page you basically have three options. First, you can simply run a local node. This entails performing the full blockchain sync, which may take from 10-14 hours (with an SSD) to several days to complete (with an HDD). Second, you can run a local node and make use of a bootstrap node. This also entails performing the full blockchain sync. However, this option allows you to immediately use the wallet whilst your local node performs the initial blockchain sync in the background. Third, you can use a remote node, which allows you to immediately use the wallet. Using your own (local) node is most advantageous with respect to privacy and security plus it contributes to the strength and decentralization of the network. It, however, requires approximately 60 GB of free space. Furthermore, performing the initial blockchain sync is quite resource intensive and may cause the GUI to feel laggy / buggy. Although, this can be mitigated by applying this guide. Now, practically speaking, you can choose option 1 by leaving all boxes blank and, optionally, specifying a custom Blockchain location. Option 2 is chosen by entering a remote node (a list of remote nodes can be found here in the Bootstrap node box. Option 3 is chosen by first ticking the Connect to a remote node box and subsequently entering a remote node (to reiterate, a list of remote nodes can be found here.

A few final notes:

I'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet.

The wallet files are, by default, stored in /Users/<username>/Monero/<wallet-name> (Mac OS X) or Documents\Monero\<wallet-name> (Windows) or /home/<username>/Monero/<wallet-name> (Linux).

The .keys wallet file stored on your system contains some settings related to the wallet, your public keys, and your private view key in case you exported it. It does not contain your private spend key. Put differently, the private spend key remains on the Ledger device.

You only have to use this guide once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the GUI. That is:

[1] Make sure your Ledger is plugged in and the Monero app is running.
[2] Open GUI v0.17.2.1
[3] Enter the password to open the wallet.
[4] Optionally export the private view key on the Ledger device.

It's imperative that the closing process of your Ledger Monero wallet is done in this specific consecutive order:

[1] Exit the GUI by clicking on the x (right top).
[2] Exit the Ledger Monero app.
[3] Unplug the Ledger device.

If you have any further questions or need assistance, please leave a comment in this thread.


How do I "background mine" on CLI for Helium Hydra v.0.11.0.0?

Background mining is done by adding "true" at the end of the start_mining command in monero-wallet-cli, after the number of threads. This means the number of threads is not optionalk in that case:

start_mining 4 true

This will start background mining on 4 threads.


What Android wallet options are there for Monero?

Existing: Monerujo and the source can be found on Github.

Upcoming: official GUI, mymonero, Coinomi (not open-source) - not necessarily in that order

Available for testing: mymonero, official GUI (build yourself, pre-built apk)

Suspicious: Freewallet, which is custodial (they have your keys) and not to be trusted.


Why can I not choose my own custom transaction fee? Does this affect privacy in anyway?

You can choose a multiplier. Choosing a custom fee could give away certain pattern and enable clustering of transactions matching the pattern.

When choosing a multiplier, you can still give priority to the TX, but your TX wouldn't stand out as 'special', since everyone is using multipliers.

Choosing some other fee smaller than the minimum fee would be pointless as it wouldn't get mined and it would get stuck in the mempool.

The minimum fee has been designed to keep the 'status quo' of the blocksize. Using the minimum is ok for 'normal' times, as miners wouldn't earn more if they should increase the block size. In case of increased use, users would use a multiplier to 'bribe' the miners to bump the block size. After the new median has been established, miners would stop losing part of block reward and users could go back to minimum fee (which would be lower than what we started with!), but the blocksize cap will remain as long as there's actual network use to sustain it.

Some ideal cycle would be like this:

Steady state, block size cap sufficient to let everyone get in the first block
Increased use, some delays experienced, impatient users paying more fee and making it economically viable for miners to increase the block size cap
Bigger blocks make the median larger
After 100 blocks, a new median is set and miners stop losing block reward, but increased cap is 'won'.
If the cap is enough and blocks are again not getting full, everyone can go back to the minimum fee and continue to use the network as usual, but now with smaller minimum fee and more capacity!
If there's no use, we go back to bigger min. fee and smaller blocks
If there comes more use, we repeat the cycle to get bigger blocks and smaller min. fee!

At the new steady state, users get cheaper TX-es and it's all the same for the miners (they're not penalized anymore, but the fees go back to min.). However, if they would drop some TX-es, they would lose out fee revenue so there's always incentive to keep the status-quo, until some fee pressure builds up...


Possible to mine XMR on Nvidia P500 Pascal Mobile?

It should be possible, but whether your miner supports it is another question.

I'll also point out there has been lots of people very sceptical of minergate. Just search Reddit and draw your own conclusions.

My recommendation is to use either xmrig or xmr-stack and one of the pools the community deem as honest.


Obtaining coinbase transaction signature

Why would you remove extra ? It's in there.
See cn_deserialize.cpp, to which you can give the hex dump of that tx:

cn_deserialize --input aaaaaaaaaaaaaaaaaaaa

This will show you the tx key.


Does Mimblewimble have any relevance to new pruning ideas for Monero?

The paper is interesting and Monero was mentioned at one point:

  OWAS had the good idea to combine the transactions in blocks. Imagine that we
  can combine across blocks (perhaps with some glue data) so that when the outputs
  are created and destroyed, it is the same as if they never existed. Then, to
  validate the entire chain, users only need to know when money is entered into
  the system (new money in each block as in Bitcoin or Monero or peg-ins for
  sidechains [6]) and final unspent outputs, the rest can be removed and forgotten.

However, the paper does not appear particularly useful to Monero. It says nothing about Monero key images (which prevent double spending and cannot be pruned).  Monero is much different than Bitcoin in that it is much harder to determine which outputs (included in a ring signature) are spent or not. This distinction relates directly to what can and cannot be easily pruned.


With ring CT, the amounts will be obfuscated. Inputs are already obfuscated by using ring signatures.

The destination is already obfuscated by using stealth addresses. Only by having the private view key that belongs to the address (and knowing the address), you're able to tell that the output was sent to that address, which is exactly what your wallet does when it's syncing with the blockchain. It checks every output and attempts to decrypt it with your private view key - if successful, the output is for you. If not, it's for someone else, and you don't know for who.

For example, let's have a look at a random transaction. There, you will see two inputs, and for each input, 3 public keys. This is a 2-mixin transaction, meaning there are 2 fake keys and 1 real. You're not able to tell which one, so you can't tell who spent the key image.

It's been split into 7 outputs, and you can't tell to whom the outputs belong to, unless you're able to "decode" them. Note that any of those outputs can be used as a "fake" key in someone else's transaction.


Why are do some addresses on the Monero testnet begin with '9' and others with 'A'?

Prefix is fixed in that the first (AKA network) byte is fixed to 0x35 for testnet. When encoding to base58 to get the actual address, the first 2 characters will vary depending on what follows after the network byte.

Those 2 addresses decode to:

353e39ae5e839ff8f46141a37551e6bae627575a6d8da8be269dae6f3410e188c32d446e4e687c749d7d165250f740b58d885ec452f317d8ce5a35de40ef08679d428d4a16

and

35e280bafa4b88c077c3b05ad67691acc268b5feb93c02e973e88a7a78b86a228cbdcf062b8776a201fc46bdd3fc1bda80749a241d0df4eafe1e1f17bb067ec6d5a0213a66

so you can see they both start with 0x35, which is followed by the spend public key, view public key and the checksum.


What is the bandwidth cost of running a full node?

Bandwidth utilization greatly depends upon whether or not inbound ports are opened up or not.

On a fast 10gbit+ VPS with inbound ports opened up, I see 280 GB inbound and 250 GB outbound used.

On a residential connection with 8 outbound connections and zero inbound, I see less than 10GB inbound / outbound used in 30 days.


What are the potential attack vectors of doing a kind of "quick sync" by just asking for/validating the last X blocks?

So, the quick sync you describe would be susceptible to a fake chain attack. Basically, when your node would do a quick-sync, it would select a random peer that has a proper blockheight (longest chain rule), get the latest 200 blocks, and then move forward like everything was normal. A malicious peer could instead provide a fake chain that is "valid" for 200 blocks, and here validity is a poor word, because there's no way to actually validate the last 200 blocks. You need the rest of the blockchain to check that each transaction in those 200 blocks is referencing real outputs somewhere else on the chain. So the best you could do is a check of the hash chain.

So anyhoo, you are served up this fake minichain, and you proceed to make a transaction. Your transaction now exists on the minichain but not on the real chain. What the attacker can do with this depends on how complex the attacker is, i guess. If the situation is reversed, and the attacker is sending you monero for some goods, he could send you monero on the fake chain and then receive the goods, and still have his monero on the main chain.

So the question becomes how to make sure the minichain you are using is valid. This, i think, can be addressed by using the headers-first synchronization. With this approach, you download the headers from multiple peers - so just a list of hashes of the full chain. In monero's case, we can also download the transaction hashes to increase our ability to check the validity. You can then either compare that the hash-chains from the multiple peers agree with each other, or perform a quick hash validation (because you could grab the transaction IDs, which are used in the block hash via a merkle root.. well, maybe not. This depends on whether you can reconstruct the tree).

Anyway, once you've got an agreement amongst your peers that you have the valid hash chain, you can then download the last 200 blocks and see that the downloaded blocks match the hash chain.

I did some research into this by diving into an extensive issue conversation on bitcoins github. I can't find the link right now.

Basically, this is akin to a SPV approach, where the user is trusting the hashes of other peoples blockchains.

This approach is not used in bitcoin, for instance, because it violates the security model that the core software needs to implement in order to maintain trustlnessness. (this is what I took away from the github issue discussion).

The idea with a true blockchain sync is that you do not need to trust the validation of another node. Your node creates the genesis block, and then you receive the next n blocks from some other node. Your node then performs full validation. For block 1, your node checks that the transactions in that block are valid. It then checks that the header PoW is valid. Then it moves onto the next block.

In this way, you truly re-create the blockchain using data from other nodes. You independently validate that the blockchain you have follows consensus.

By using what you are proposing (headers first, SPV style), the only attack I can think of is an isolation attack, but this is no different than a full sync IMO. Even a full-on complete validation sync is susceptible to an isolation attack.