How do you calculate the size of a Monero transaction before it is sent?

I have this, which may be wrong as I've not tested it a whole lot. The constants at start are "close enough", I did not try to be 100% precise:

47 + inputs * (39+(mixin+1)*2) + outputs*38 + 64 * inputs * (mixin+1)

If you want to know whether a fee is acceptable before it is actually sent, you can use set always-confirm-transfers 1 in simplewallet, and you'll always be prompted with the transaction before it is sent to the daemon.

For RingCT, the calculation is more complicated, see https://github.com/moneromooo-monero/bitmonero/blob/rct/src/wallet/wallet2.cpp, estimate_rct_tx_size (which is also a good approximation only, not exact).

The main reason for "not exact" is that integers tend to be stored as variable length, depending on their value.

In both cases, a tx_extra of 40 bytes is assumed (typically, a payment id). You can remove 34 bytes if there's none.


Will the dynamic fee algorithm under development be a wallet side calculation or it will be a consensus rule?

Since the 2014 attack the fee where forced by miners. The calculation for the dynamic fee will be made on the wallet side, and then verified by the miners and if it is on the miners default it will be acepted by the network

Note by tewinget: "the network doesn't care about fees for a block, but miners do care about tx fees when deciding which to include in a block"


Monero never arrived (Poloniex->GUI wallet)

I believe this has been a Poloniex issue for quite some time. If you did not use a Payment ID, you may be screwed.

Try to find your payment on the blockchain:
https://monerohash.com/explorer/

There are other sites for exploring the chain https://getmonero.org/community/merchants/ (Look under Block Explorers). I do not know which is nicest or best.

You may want to get in contact with Poloniex. Another option may be to load your wallet from seed on the wallet-cli or perhaps mymonero, to verify that it is in fact in or not in your wallet.


The daily variance appears to be limited to about 10% of the hashrate. Two possible explanations:

A system administrator mines Monero at night when computers would otherwise be idle
A system administrator mines Monero during the day while having physical control of the computers.

Replace system administrator for anyone with control over a large group of computers and adjust day/night to match the idle computer or working hours in that particular time zone.


Output selection is random, which accounts for the prevalance of outcomes such as the one you mention. Outputs are picked, until the accumulated sum reaches the amount to send plus the fee, and this target is a lot more likely to happen when adding a large output.

The unique amounts you speak of are the dusty complex amounts such as 0.000468709491, which are very specific (not split below 0.01), and are unlikely to have other amounts of the same value to mix with on the blockchain. Monero does not produce those anymore, but if you have any in an existing wallet, your best bet is to run sweep_unmixable, which will consolidate them into nicer outputs which can mix.

There is no way to manually select outputs, so you can't change this without writing your own selection code, which is not recommended.


How to pay the import fee from MyMonero.com for a paper wallet?

The fee must be paid to that address but the originating address does not matter. Doing this from an exchange is a valid alternative.


Missing functionality / screen controls in Monero GUI app v0.14.0

The discrepancy in your posted screenshots is based on what mode the wallet is being run in. The GUI wallet supports both "Simple" and "Advanced" modes. When in advanced mode, you have the extra tabs and menu items.

You can switch modes by clicking the "Close wallet" button, restarting the GUI and when in the opening wizard, open the existing wallet and change the mode to advanced mode (after language). You will then have all the advanced options available to you.

Per your comment above:

  my intent is not mainly to be able to use a remote node, but rather not to download the blockchain

Unfortunately it is a little confusing for new users understanding the various options/modes.

There are two different "simple" modes, one with bootstrap and one without. The key difference is that when using the bootstrap variety, the blockchain is downloaded to your computer at the same times as connecting you to a remote node, so you can use your wallet immediately, without needing to wait for the full blockchain to download.

Advanced mode allows for the fullest flexibility. Here you can specify if you want to download the full blockchain, use only a remote node, use a specific remote node, or use a mixture (e.g. bootstrap).

As your intent is to use a remote node and not store the whole blockchain, you can safely just use simple mode (without the bootstrap option). However, you cannot specify which remote node is used while in this mode. Therefore, if you want to specify a remote node yourself, you will need to have started your wallet in the advanced mode.

I'll end with pointing out one other thing. Although using a remote node, with no bootstrap, wont actually store the blockchain, it still needs to scan for outputs, which takes time and bandwidth. Depending on how long since you last scanned, this can take some time. This is why there are two progress bars. Wallet sync is the scan progress, daemon sync is the daemons download progress. If you are using a remote node (daemon), it shows how much the remote node has downloaded. If you are using a local node, it shows your local daemon download progress.

Hope this helps clarify.


The design and development goals are on the website: https://getmonero.org/design-goals/

RingCT still needs performance and efficiency improvements, but more than that it opens up a way to do multisignature transactions, so that has to be built.

Beyond that, there are loads of critical features and improvements, and lots more that will have to fleshed out on the research side of things before we could even attempt to write code.


How to calculate how much GPU power to mine 1 coin a day for any cryptocurrency?

Simplest would be the following:

Daily mining estimate = ((your hashrate) / (network hashrate)) * (current block reward) * (number of blocks in a day)


Error: not enough outputs for specified ring size = 7 in monero 0.12.0.0 Lithium Luna

This seems to be a bug in sweep_unmixable, as evidenced from this recent PR:

https://github.com/monero-project/monero/pull/3794

I think you should be able to use the latest release-0.12 code, and it should then work.


What does "Error: Failed to find a way to create transactions" in simplewallet mean?

This means exacly:
"not enough money to transfer, available only xx.xx0000000000, transaction amount xx.xx0000000000 = xx.xx0000000000 + 0.040000000000 (fee)"

You trying send everything? If you have 10xmr and want to send everything you must send 9.6 to cover the fee.

Check wallet log file to find out first what the fee is, because it depends on mixings and amount being sent.


Why do I have to export the private view key every time I use my Ledger?

The Ledger wallet device does not have the ability to scan the entire blockchain, as it's small and limited in computation and memory. Instead, it authorizes the computer/smartphone it's connected to to act as a proxy and process the blockchain and send the relevant information on new transactions to the device. Without the view key the proxy would not know which transactions to send to the device and so the device will just assume that it never has any transaction history at all, and thus no value.

An air-gaped computer with a downloaded copy of the blockchain would work more securely, but at the cost of being non-transportable, and thus unusable. Ledger allows for a compromise of this security while retaining usability.

Everything has a trade-off.

Edit: Upon reviewing the linked document, I've learned that the exposure of the view key is optional. You can have the improved privacy but at the cost of taking more time to synchronize your balance. (The device is rather short on computation and memory so I suspect that this would take a significant amount of time. I don't have the specifics at hand and so will only leave this as suspicion.)

So I think the device is likely a good option in that you have selective security models available and can choose between the trade-offs.


How can I verify that a Monero Block explorer is not under a MITM attack?

You can use MoneroPulse in your own node, start enforcing checkpoints with the --enforce-dns-checkpoining flag in bitmonerod, this means even in the event of a network attack you are following consensus and won't fall in a wrong fork, to compare the Block Explorer height and difficulty with yours in the clearnet or TOR, use the commands status and diff in the bitmonerod window.


Can I look for incoming transactions with only my private view key?

Running ./monero-wallet-cli --generate-from-view-key <private view key>, you can generate a view only wallet file.

Then you can run ./monero-wallet-rpc --wallet-file view-only-wallet --rpc-bind-port 18084 to launch the RPC wallet using your view only wallet file.

Then you can poll the wallet RPC method get_transfers with the field in:true to fetch incoming transactions.


Energy consumed to protect the Monero network

Generally you can simply look at the value of the current block reward as an indication of how much electricity it takes to secure the network. At 8.7 XMR per block it costs about 78k USD in electricity to secure the network each day.

Based on this, lets roughly say it is 0.15 USD / Kwh, so 78k/0.15 = 514,800 Kwh each day.


I had the same error on a 64 bit system and could get rid of them via:

sudo apt install libxcb1:i386 libx11-xcb1:i386 libxcb1:i386 libxcb-glx0:i386 libfontconfig:i386 libx11-data:i386 libx11-xcb1:i386 libx11-6:i386 libxext6:i386

But afterwards still a segfault happens - seems that the monero wallet gui is not (yet?) compatible with 64 bit systems.


Method not found using Monero JSON-RPC in PHP

getblockcount is a daemon RPC, but you mention monero-wallet-rpc mostly. It is likely you are trying to call this RPC on the wallet, not on the daemon, and the wallet rightfully errors out.


How can I check my solo mining hash rate?

The daemon mines, the wallet does not. The command to start mining from the wallet is a convenience function, which merely asks the daemon to start mining, and there is no convenience function to ask for hash rate reporting.

In the daemon, you can check hash rate either with show_hr as Guest said, or status. show_hr will continuously log hash rate, while status is a one off.

When using the GUI wallet, the daemon hash rate is reported in the "Mining" tab.


Can I store the Monero local blockchain on a Ledger Nano S?

No.  There is only a few MB, not 100's of GB on the device for apps and key stores.


How many payments can be included in one transfer command?

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

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

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


Getting "Error retrieving blocks, missed (#) transactions for block with hash" while running pruned node

From moneromoo on Github:

That's from nodes that don't understand pruning are asking you for data that you pruned. It's OK.
For the lockable memory issue, you can increase the amount of lockable memory using the command the message is giving you.


Compiling GUI from source differences by OS

There is no publicly available reason as far as I know, but compiling on Windows is usually a bit more difficult to compiling on OSX and certainly on Linux. However, Ilya Kitaev has provided Windows build instructions in one of his branches. The instructions have, at the time of writing, not been PRed to master yet. The Windows compile instructions can be found here. The instructions are as follows:

  On Windows:

  Install msys2, follow the instructions on that page on how to update packages to the latest versions
  Install monero dependencies as described in monero documentation
  Install git:

  pacman -S git

  Install Qt5:

  if you need to build x86 application, install:

  pacman -S mingw-w64-i686-qt5

  if you need to build x64 application, install:

  pacman -S mingw-w64-x86_64-qt5

  Open mingw shell. MSYS2 will install start menu items for both mingw32 and mingw64 environments, so    you need to open
  appropriate one:    %MSYS_ROOT%\msys2_shell.cmd -mingw32 for x86
  targed    or     %MSYS_ROOT%\msys2_shell.cmd -mingw64 for x64
  targed

  Where %MSYS_ROOT% will be c:\msys32 if your host OS is
  x86-based or c:\msys64 if your host OS    is x64-based
  Clone git repository:

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

  Build the project:

  cd monero-core
  ./build.sh

  Take result binary and dependencies in ./build/release/bin

  important: if you testing application within VirtualBox virtual
  machine, make sure 3D acceleration is enabled    in machine's
  settings:    Machine > Settings > Display > [v] Enable 3D
  Acceleration


Download Monero Blockchain data and the official client

Both blockchain and clients are on https://getmonero.org/downloads/.

The blockchain (https://downloads.getmonero.org/blockchain.raw) needs to be imported once downloaded. Verification is recommended, but it can be turned off for speed (current master is a lot faster for this, so the coming release will be too).

Current master is also much friendlier on the download size needed (barely more than blockchain.raw).


Will it be possible to prune all non-RingCT outputs once we know they are all converted into RingCT outputs?

This would be possible only after every single one is spent. Given the extremely high likelihood that at least one output is lost (private key lost), it seems that it's unlikely to yield any benefit, though it seems it could be done per denominations, and there could plausibly be some denominations where all could be spent. Unfortunately, those are likely the ones with few outputs in the first place.


How does TumbleBit privacy and security compare with Monero?

Update 2018.02.04 In light of recent of environment changes, this answer needs update, since blockchain scalability cannot be ignored anymore. TumbleBit's mixing technique became completely uneconomical, due to high fees. Although Monero has a similar fee problem, not as bad as TumbleBit has. That being said, TumbleBit has a Payment Hub mode, which is just as unusable, because it's unidirectional, however if someone figures out how to make it bi-directional, then things can change. As far as I know, nobody works on its payment hub mode.

Original post:

You are specifically asking for privacy and security, so I will omit the practicality, where Monero would win by far if we wouldn't count that it needs to have its own token to work.

From a privacy point of view TumbleBit's payment hub might be slightly superior, since it's borrowing the anonymity set from Bitcoin users and if there are more Bitcoin users than Monero users that'd result in better privacy.
TumbeBit uses a central server, called the Tumbler.The only disadvantage having a central server is if the server goes offline no payment will happen, but this does not affect privacy.

From a security point of view there is not much to talk about. None of them has the risk of losing money. Both protocol is theoretically secure. How they are/ will be implemented is an other question.
I would also like to mention cryptographers might also make the argument that TumbleBit solely relies on text-book RSA cryptography.


Using remote node still syncs blockchain?

In Monero there's two "syncs". First, the blockchain sync, which is basically downloading the blockchain from other nodes / peers. Second, the wallet sync, which is the wallet "refreshing" / scanning blocks looking for transactions belonging to your address / wallet. Since you're using a remote node, you're skipping the first step. Thus, the status indicator on the left bottom (of the GUI) is showing the number of blocks it still needs to refresh. If it states Connected it's fully refreshed and should show your balance.

Now, to make sure you are properly connected to a remote node and restore your wallet, use the following command (CLI):

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

monero-wallet-cli.exe --daemon-address node.moneroworld.com:18089 --restore-deterministic-wallet

On Linux and Mac OS X, you need to open a new terminal from the same directory as monero-wallet-cli and subsequently type:

./monero-wallet-cli --daemon-address node.moneroworld.com:18089 --restore-deterministic-wallet

For the GUI, go to the wizard (if you currently have a wallet open, go to the Settings page and press Close wallet, it'll bring you back to the wizard) and (on the second page) set node.moneroworld.com:18089 as custom daemon address. Subsequently, choose Restore wallet from keys or mnemonic seed. As restore height you can use the block height of your first transaction to the wallet minus 10k blocks. Thus, if the first transaction to your wallet was included in block 1410000 you ought to use 1400000 as restore height.

Note that if you want to use a different remote node, simply change node:moneroworld.com:18089 to the preferred remote node and its port.

Lastly, as user36303 said:

  It does not. It HAS to download something. It just isn't the whole chain.


Is there a reference about format of transaction?

Beyond the somewhat dated CN doc you referenced, and if you need more specifics, the best resource is really the code. For example, you can see that the tx prefix is serialized (src):
BEGIN_SERIALIZE()
  VARINT_FIELD(version)
  if(version == 0 || CURRENT_TRANSACTION_VERSION < version) return false;
  VARINT_FIELD(unlock_time)
  FIELD(vin)
  FIELD(vout)
  FIELD(extra)
END_SERIALIZE()

Then just look at the BEGIN_SERIALIZE... for the sub-fields, such as the FIELD(vout) is  defined as std::vector<tx_out> vout; and tx_out being (src), and so on. It's not terribly difficult when you get the hang of it.
As @koe mentioned, Zero2Monero also gives a fairly up-to-date overview. As he also points out, it's not "fixed" so to speak, which is why I'd advise to get comfortable navigating the code definitions, as outlined above.


No.

However, you can get blocks by height, and height maps fairly well to date. There are on average two minutes per block since height 1009827, and one minute per block before that. It's then a simple conversion.

To get blocks by height, use the getblockheadersrange, which has start_height and end_height parameters.

Example:

curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block_headers_range","params":{"start_height":1545999,"end_height":1546000}}' -H 'Content-Type: application/json'


Is it safe to leave "back ground mining" on as long as I want too?

Yes, leaving it on in the background should be fine. Background mining limits CPU usage to 40%, so you shouldn't have any trouble with overheating.

https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/miner.h#L100

static constexpr uint8_t  BACKGROUND_MINING_DEFAULT_MINING_TARGET_PERCENTAGE        = 40;
static constexpr uint8_t  BACKGROUND_MINING_MIN_MINING_TARGET_PERCENTAGE            = 5;
static constexpr uint8_t  BACKGROUND_MINING_MAX_MINING_TARGET_PERCENTAGE            = 50;

Also FYI, on a laptop it will also check that you're on AC power so it doesn't kill your battery (although you can override that check).


How do fees affect tx priority and how did these specific high fee tx's sit unconfirmed for > 1hr

I asked the same question over on reddit, and
although I did not get to the bottom of why these particular txs sat there so long, I did learn several things which may be helpful/interesting for others...

As mentioned by samwellj above and nanoakron on reddit, the PR to prioritise txs by age has only just been merged, so unless all miners have already updated or are using custom software, it is likely that it is not in full effect yet (and was not at the time of these txs), but it is on its way. Nice work, I look forward to seeing it fully implemented in due course.

That answers one aspect of the question - why 'time in mempool' was not a factor in tx processing.

The second aspect regarding fees is a bit murkier. Monero has had a 'prioritise by fee' algorithm for a while now and it functions on a fee per byte basis (thanks smooth for your patience on that one). Currently there are 3 presets in the GUI/CLI to prioritise txs using a fee multiplier of 1x, 20x and 166x. The reasons for the 'super multiplier' of 166 is to pay a fee high enough at times of high load to compensate /incentivise miners to take a block reward penalty and increase the block size above the permitted % over the median, thus allowing the block size to increase faster if people are prepared to pay for it, and allowing any backlog to clear quicker. Very cool.

No firm answer on why these tx's did not get prioritised by fee, and it looks like we are not going to get one, but hey, I learnt plenty along the way and I hope this information is useful to others too.

One question that is raised for me now is how do the 'prioritise by time' and 'prioritise by fee' algorithms interact with each other. Do fees trump time, or is there something more complex at play?

Obviously tx prioritisation has only really come into focus since the HF due to the larger size of RingCT txs and the more frequent though relatively small mempool backlogs. I imagine we have not yet arrived at a final destination here (will we ever!), and that things will be optimised as the system is observed.


Transaction from suprnova to local gui wallet failed

A transaction may fail to make it into the chain for various reasons:

it might be intrinsically invalid in some way: for example, the signatures being incorrect, or using a ring size smaller than the network minimum
it might be double spending an output already on the chain: this can happen if a transaction is dropped from a daemon, which then accepts another spending one of the original inputs, but other daemons might mine the first one in the meantime
it might stay more than a day in the txpool, in which case it'll be dropped due to age: if the tx was valid, it could be because its fee was too small and there was non stop contention by other txes.

If you got a transaction hash for that missing transaction, you can check whether it's on the chain by looking it up on a block explorer, for instance moneroblocks.info. If it is there, then it was not really missing, and it could be a bug in the wallet, or the wallet wasn't up to date. Or it could have been mined later than the time you deemed it to be missing.


Get public key of tx that currently in txpool

The transaction public key is contained in the txextra part of the get_transaction_pool response.

The format of txextra is documented here: https://cryptonote.org/cns/cns005.txt

You therefore want to parse txextra and look for subfield 0x01.

Please could you leave a comment and let us know how you made the tx private key deterministic? What are you hashing together to determine your tx private keys?


How is the number of key images for a transaction selected?

[Though this wasn't always the case, due to a bug that was discovered and patched prior to any exploit] there is a single key image that can be derived for each output on the blockchain.  The output's recipient is the only one who can create that key image using their secret spend key.  When you spend your Monero, your transaction must attach the key image and sign the transaction (another use of the secret spend key) in order to create a valid transaction.

Any key images you're seeing on a block explorer represent the proof that a particular output is able to be spent, plus it prevents that output from being spent again because the key image remains in the key image list.


Can I chose my own outputs to mix in a transaction?

In theory, you could choose yourself if the software supported it but I don't see much benefit in doing so.

In practice, the current monero-wallet-cli has 2 different transaction building algorithms depending on which transfer command is invoked. The 2 commands for the monero-wallet-cli are transfer and transfer-original. I'm not familiar with how they decide which outputs to pick, though.


Why excludes the transaction bodies in the structure of the block?

The blockchain is a logical concept. When you store the blockchain locally, your Monero node implementation can store blocks and transactions together, or in separate places. How your Monero node implementation stores things is only a performance consideration.

There is no need for blocks to always be stored alongside the transactions they logically 'contain'. By using transaction identifiers, it makes it easy for blocks and transactions to be stored in different places for performance reasons, should an implementation choose to do so.


Historical XMR price volatility compared to BTC

Poloniex.com is the largest market for Monero and maintains records for XMR and BTC price information which can be given in terms of USD via the symbol USDT.  This market-specific price information can be retrieved through their exchange tab or through the site's API (example).  Further API documentation can be found at https://poloniex.com/support/api/.


What are the chances of discovering a block solo mining with my current hashrate?

tl;dr

Solo mining is a lottery unless you have a few dozen GPUs

Explanation

Target block time in Monero is 2 minutes, based on that and your share in the network hashrate you can calculate how frequently you will find blocks.

Let H be the network hashrate, and h be your own hashrate. Then on average you will find a block every

t = 120 / (h / H) = 120 * (H / h) (seconds) = (H / h) / 720 (days)

Now let t and t' be your "substantial enough" target, in seconds and days accordingly. You can find minimum h / H ratio to achieve it, i.e. a proportion of the net hashrate you must own:

h / H = 120 / t = 1 / (720 * t')

If H is known, your minimum hashrate to achieve that is

h = H * 120 / t = H / (720 * t')

Current network hashrate is ~125 MH/s (Jul 19, 2017), so with 4 KH/s you'll have to wait for 43 days on average to find a block, meaning that you can easily have zero payouts during a month or two.

Finally, let's calculate how much hashrate you currently need to get payouts at least once a week on average (bear in mind that H tends to grow over time):

h = 125000 / (720 * 7) = 24.8 KH/s


Korbit exchange access and currency support

I've not used the exchange, but with some google fu I've managed to piece together the following:

You need a Korean bank account, in your name, to use Korbit.

Level 3 means you've verified your account by sending in a scan of your diver's license or equivalent.

If you browse the Korbit site you see that the only fiat that is supported, for the listed pairs, is the South Korean Won.  It's a reasonable guess that the same is true to for the currencies that are available upon verification.


Are Monero hashes generated based off of the block header?

Partially. A block hashing blob is constructed which includes the block header, a miner coinbase transaction, a merkle tree root hash of the blocks transaction hashes, and a count of the transactions. This is updated with a nonce and only then hashed and checked.


How does a wallet check when their output has been spent from the keyimage shown in a tx?

If a wallet has received an output in the past, that means the wallet will know the private key for that output. This is the case even if you restore the wallet from seed.

The private key for the output is calculated as x=Hs(8aR||i)+b, where a is the private view key, R is the transaction public key published with the transaction, i is the index of the output in the incoming transaction, b is your private spend key, and Hs() means keccak hash the contents and return a scalar (integer).

The key image is calculated as xHp(Hs(8aR||i)G+B), where G is the agreed-upon base point on the ed25519 curve, B is your public spend key, and Hp() means keccak hash the contents and return a curve point.

The wallet checks if the key image of any previously received output is observed to be attached to any transaction it comes across as it scans the blockchain.

The daemon will reject transactions that are broadcast which contain any previously encountered key images. Although the daemon will not know which specific output referenced in each ring that each key image refers to, it doesn't need to know. All it needs to do is reject duplicates.


how do you sign a message with your monero private key?

With monero-wallet-cli, you can sign the content of a file (e.g. message_file)  with the command sign message_file, and verify the signature with verify message_file address_of_the_signer signature.

With monero-wallet-gui, in the menu go to Advanced -> Sign/Verify, then you can sign (or verify) a message or a file by filling the appropriate boxes.


If you want to use ready made binaries, these will be available soon (in the next few days) on getmonero.org.

You will not need to replace your blockchain, nor move your monero. Just start using the new version when it's out.


How do I create a subaddress with the cli wallet?

The new cli command is called address.

address [ new <label text with white spaces allowed> | all | <index_min>
[<index_max>] | label <index> <label text with white spaces allowed>]

To create a new sub-address for the current account use address new.
You can view all addresses with the address all command.

Each sub-address will get an index starting with 1 since the primary account address is at index 0.

You can also add a label to each sub-address as optional parameter or later with the label option.

Edit:
If you want to see balance on the sub-addresses you can use the command "balance detail" on the cli.


How can I explain the meaning of Monero to my grandma?

I wouldn't try differentiating between Monero or Bitcoin, or any other crypto-currency, and just say: "It's like PayPal, but instead of the bank keeping track of your balance, there's no bank. Every one's computer (or phone) is keeping track of all that.". It is an oversimplification, but summarizes the essence of blockchains I think.


Indeed, the question cited refers to a list of url. The reseed process starts with choosing randomly one of them.

So let's assume that the choosen URL is : https://i2p.mooo.com/netDb/.
Here are the next steps :

Download an SU3 file, which must be named i2pseeds.su3 and located at the root :

curl -k -A "Wget/1.11.4" https://i2p.mooo.com/netDb/i2pseeds.su3 > i2pseeds.su3

Check Signature and type:

java -jar lib/i2p.jar su3file showversion i2pseeds.su3

Or

kovri-util su3file showversion i2pseeds.su3

Extract the included file :

java -jar lib/i2p.jar su3file extract i2pseeds.su3 i2pseeds.zip

Or

 kovri-util su3file extract i2pseeds.su3 i2pseeds.zip

Unzip :

 mkdir tmp && cd tmp && unzip ../i2pseeds.zip

At this point, you should see a list of files whose name looks like    routerInfo-(44 character base 64 router hash).dat

Each file can be inspected with :

kovri-util routerinfo <filename>

Or

java -jar lib/router.jar routerinfo <filename>

These are the informations needed to start contacting other peers in the I2P network.


How to save wallet after create_address?

create_address does not generate wallet key files, it creates a subaddress. Therefore even if the wallet RPC crashed, you would not lose anything. The wallet can still receive funds sent to that subaddress also.


How can I assist in testing RingCT on the Monero testnet?

You can help by performing the most unlikely actions that should still work, keeping track of what you do, and reporting what doesn't work.

Sending transactions to other addresses is the obvious case, which has been well tested already. Things worth testing now are features that were added recently to the git repository, such as cold wallet signing.

You can also test restoring a wallet through various means (from seed, from keys, etc), and checking ringct transactions are still recognized. You can check all transfer commands: transfer, sweep_unmixable, sweep_all. You can check that you can still prove a payment using get_tx_key/check_tx_key. Basically, go through everything, especially the most obscure, since that's what is more likely to have been overlooked.

If anything does not work, please file a bug on https://github.com/monero-project/monero/issues, detailing what you tried, what the results were, and what you expected would happen instead.

Thanks for testing!


Block reward and transaction fees over time

Why does the reward look like it resets at the point where major version 2 appears in the block?

Transaction v2 (Monero v10) was the introduction of RingCT. There were various fee related changes over the Monero v10.x.x releases to account for the size changes introduced by RingCT. As @dEBRUYNE notes, the block time changed earlier that year too, to retain the original emission schedule – this is what the jump in your chart shows.

What are the high spikes in the rewards?

The spikes you reference are in transaction fees, not the block reward. Also, just because someone constructed a transaction with a high paying fee, this is not necessarily a reflection of the norm. For example, the transactions immediately before and after the high paying transaction you reference in block 262990 only pay 0.100 and 0.146 respectively. The block reward for each of those blocks was ~13.72, steadily reducing.

As far as I understand, a bigger block size would have higher fees... but I could not find an explanation

Not necessarily. Miners create blocks and they incur a penalty for creating unusually large blocks, hence the block reward is reduced, via the penalty function. Miners are not obliged to include large transactions just as senders are not obliged to pay higher fees.


Have you tried upstart? See http://upstart.ubuntu.com/cookbook/

Also see: https://askubuntu.com/questions/351879/how-to-create-a-service-on-ubuntu-upstart/448536#448536

Upstart Example: /etc/init/xmrstakcpu.conf

# xmrstakcpu.conf
start on net-device-up IFACE=eth0
exec /usr/local/bin/xmr-stak-cpu/xmr-stak-cpu

This would run /usr/local/bin/xmr-stak-cpu/xmr-stak-cpu after the Ethernet0d device was initialized.

If you just want to run xmr-stak-cpu in background - for instance after SSH - you can use

nohup ./xmr-stak-cpu &

This will run xmr-stak-cpu and keep it active in background and log all output to a file nohup.out, while you can logout / exit SSH.


Your 24 word seed is your Ledger device seed which is used for restoring the Ledger. It is used in the Ledger Live app when you need to restore a device. Recall that the Ledger has your wallet private keys, not the Monero GUI application. Each Ledger device only uses one seed phrase; you do not have different seeds for each cryptocurrency you use your Ledger for.

Ledger has a full guide for using Monero with your Ledger and there is also a guide on StackExchange. There is also this guide for restoring a Ledger with Monero.

The long address you mention I can only assume is your wallet address, though I don't have a Ledger to confirm this.


This address received 94.502 monero, with 550 confirmation(s)

This means that particular address received that amount of monero in the transaction you're looking at, and that this transaction was mined with that many blocks mined after it.

If you're not seeing this in your wallet, then you need to update your wallet to at least that block. This could be your wallet being out of date compared to your daemon, or your daemon being out of date compared to the network (or both). See questions about these things if that's the case.


Does the Key Image leak privacy information?

The key image of the real output being spent in a transaction is consistent, regardless of the choice of other outputs referenced as decoys.

Therefore if you attempt to spend an output twice, and each time a different set of decoys are chosen, then from the perspective of any nodes listening for transactions it will be obvious which output is the real output being spent.

This is a problem if you are using the same wallet on multiple computers and there is a simultaneous attempt to spend the same output. It's also a problem if the transaction you attempt to send is aborted for any reason (perhaps due to connecting to a malicious node), which causes you to reattempt the transaction to spend the same output using a different selection of decoys.

Therefore to avoid these attacks, announce transactions to your own node rather than directly to a public one, and do not attempt to spend funds from the same wallet simultaneously from multiple devices.

Outputs are only supposed to be spent once, and so under normal conditions this isn't a problem.


How to make a symlink to an external drive?

The simplest and most portable approach is provided by dEBYUNE above. The --data-dir can also be defined in the monero node's configuration file so it does not have to be passed as an argument of the monerod CLI.

Otherwise, a UNIX only approach is provided below.

Step 0 - make sure monerod is not running

Step 1 - make sure the owners, groups and permissions of the external directory are the same or appropriate for your system's permission security model.

Step 2 - make a relative path tape archive (tar) file of your ~/.bitmonero file.

% cd ~

% tar cvf /your_desired_external_drive_path/.bitmonero.tar .bitmonero

% cd /your_desired_external_drive_path

% tar xvf .bitmonero.tar

Step 3 - rename your original .bitmonero directory. (Can delete after step 6 after confirming monerod is functioning reliably.)

% cd ~

% mv .bitmonero original.bitmonero

Step 4 - make a relative .bitmonero directory link

% ln /your_desired_external_drive_path/.bitmonero .bitmonero

Step 5 - confirm link was made properly by:

% ls -l .bitmonero

Step 6 - start your monero daemon the way you did previously, in this case --data-dir becomes optional.


Can someone walk me through a simple example to explain how RingCT works?

Let's say you'll use two of your outputs, 12.34 XMR and 7.89 XMR and send 18.37 XMR to your recipient for a fee of 0.022 XMR and change of 1.838 XMR. If you use mixin of 4, you'll be creating two rings with 5 output keys contained in each. You'll pick a secret index between 1 and 5 for each ring, so let's say you picked 2 for the first and 4 for the second. I.e., you know the private keys of these two output public keys:

P_2^1 = x^1 G
P_4^2 = x^2 G

Here, underbar is used for denoting an index in a given ring (1,...,5), while hat is used for denoting the index of an input (1 or 2).
You also know the masks for the Pedersen Commitment paired with P_2^1 and P_4^2:

C_2^1 = a^1 G + 12.34 H
C_4^2 = a^2 G + 7.89 H

Then, you choose dummy ring partners to create two rings:

( P_1^1, P_2^1, P_3^1, P_4^1, P_5^1 )
( P_1^2, P_2^2, P_3^2, P_4^2, P_5^2 )

Note that each P_i^j has its associated Pedersen Commitment C_i^j.
Now you generate what's called pseudo output for each ring (which is not officially described in MRL-0005, see Issue #6 in the GitHub repository):

D^1 = b^1 G + 12.34 H
D^2 = b^2 G + 7.89 H

where b^1 and b^2 are random scalars. These pseudo outputs are recorded in the transaction. Let us define another pubkey:

Q_i^j = D^j - C_i^j

Important thing to note here is that you know the secret keys of:

Q_2^1 = (b^1 - a^1) G = z^1 G
Q_4^2 = (b^2 - a^2) G = z^2 G

These secret keys are needed for signature generation. You also need to generate two key images:

I^1 = x^1 HashP(P_2^1)        // HashP(.) outputs an EC point
I^2 = x^2 HashP(P_4^2)

With these ingredients at hand, you can generate the signature as follows: first randomly pick alpha^1 and beta^1 and compute:

L_2^1 = alpha^1 G
R_2^1 = alpha^1 HashP(P_2^1)
S_2^1 = beta^1 G
c_3^1 = HashS(Msg, L_2^1, R_2^1, S_2^1)     // HashS(.) outputs a scalar

Here, Msg is the message describing the transaction: e.g., which output pubkeys constitute each ring, the fee, the newly generated output pubkeys, etc.

Then you randomly choose r_3^1 and s_3^1 and compute:

L_3^1 = c_3^1 P_3^1 + r_3^1 G
R_3^1 = c_3^1 I^1   + r_3^1 HashP(P_3^1)
S_3^1 = c_3^1 Q_3^1 + s_3^1 G
c_4^1 = HashS(Msg, L_3^1, R_3^1, S_3^1)

You repeat this computation two more times with the index being incremented, and the index goes back from 5 to 1:

c_1^1 = HashS(Msg, L_5^1, R_5^1, S_5^1)
L_1^1 = c_1^1 P_1^1 + r_1^1 G
R_1^1 = c_1^1 I^1   + r_1^1 HashP(P_1^1)
S_1^1 = c_1^1 Q_1^1 + s_1^1 G
c_2^1 = HashS(Msg, L_1^1, R_1^1, S_1^1)

And you do a trick to r_2^1 and s_2^1 as:

r_2^1 = alpha^1 - c_2^1 x^1
s_2^1 = beta^1  - c_2^1 z^1

This makes the following magic possible:

c_2^1 P_2^1 + r_2^1 G            = c_2^1 P_2^1 + (alpha^1 - c_2^1 x^1) G            = alpha^1 G
c_2^1 I^1   + r_2^1 HashP(P_2^1) = c_2^1 I^1   + (alpha^1 - c_2^1 x^1) HashP(P_2^1) = alpha^1 HashP(P_2^1)
c_2^1 Q_2^1 + s_2^1 G            = c_2^1 Q_2^1 + (beta^1  - c_2^1 z^1) G            = beta^1 G

I.e., the hashed value c_3^1 becomes independent of (c_2^1,r_2^1,s_2^1).

For anyone but you, the resulting sequence of numbers (c_1^1, ..., c_5^1) looks really magical because the following special relationship holds:

c_2^1 = HashS(Msg, <some value depending on (c_1^1, r_1^1, s_1^1)>)
c_3^1 = HashS(Msg, <some value depending on (c_2^1, r_2^1, s_2^1)>)
c_4^1 = HashS(Msg, <some value depending on (c_3^1, r_3^1, s_3^1)>)
c_5^1 = HashS(Msg, <some value depending on (c_4^1, r_4^1, s_4^1)>)
c_1^1 = HashS(Msg, <some value depending on (c_5^1, r_5^1, s_5^1)>)

No one but you can create this and know which keys are fake, hence the unforgeability and anonymity of the ring signature scheme.

This way, the first ring signature is generated:

R^1 = [ Msg, (P_1^1,...,P_5^1), (C_1^1,...,C_5^1), I^1, D^1, c_1^1, (r_1^1,...,r_5^1), (s_1^1,...,s_5^1) ]

In practice, P_i^j and C_i^j are stored somewhere in the blockchain and the signature contains only indices of them. You do exactly the same computation for the other ring R^2.

You'll also create two new output pubkeys along with their associated commitments corresponding to 18.37 XMR for your recipient and 1.838 XMR for your change. You randomly choose e^1 and e^2 such that

b^1 + b^2 = e^1 + e^2

and compute two commitments:

E^1 = e^1 G + 18.37 H
E^2 = e^2 G + 1.838 H

This way, anyone can observe that the total amount is the same before and after the transaction:

D^1 + D^2 = E^1 + E^2 + 0.022 H

(I omitted the range proof part which is needed to ensure that every amount in a commitment is between 0 and 2^64 .)

See also: Can I manually check consistency of Pedersen Commitments in RingCT?


Why not have Torsocks on by default while we wait for Kovri?

If the majority of monerod instances were wrapped with torsocks, but otherwise not Tor-aware, then the network would end up having to concentrate all of its traffic through the few nodes that weren't using torsocks. And I don't know the details of the P2P protocol, but in a lot of designs the discovery system could end up degraded or inefficient as well.

The basic problem is that you can't receive incoming connections to clearnet addresses when you're running through Tor. If you want to set up a web of connections, SOMETHING has to receive incoming ones.

You could use Tor hidden services, but that's a lot more complicated than just wrapping the client in torsocks, and you'd have to actually change the Monero P2P protocol to pass around .onion names instead of IP addresses. And any nodes that weren't Tor-aware couldn't connect to those at all... so in practice you would either have to either switch the whole thing over to Tor, or think very hard about how you were going to properly manage a divided network.

Basically you're talking about something almost as disruptive as the I2P transition, with at least some changes to the actual P2P protocol... and then doing it again when it's time to move to I2P. That doesn't make a lot of sense.


How does the dynamic blocksize and the dynamic fees work together in Monero?

In addition to the excellent summary by ArticMine already given, here below is shortened & updated version of my research on the topic.
Dynamic Blocksize Penalty
This is the penalty which will be subtracted from the block reward. In practice it means that whenever a penalty is triggered, the start of tail emission will be slightly postponed (it will start later to "give back" the penalized amount), and once tail emission kicks in it will be an effective coin burn because the block emission will no longer depend on current emission as it will be fixed at 0.6 monero per 2-minute-block, as explained by ArticMine.
It can be written as:
P = R * (W - 1) ^ 2,
where P is the dynamic blocksize penalty (monero), R the block emission (monero), and W the blocksize expansion factor (unitless).
The expansion factor is W = B / M where B is the blocksize (kB) of the examined block, and M the blocksize median of previous 100 blocks (kB). For example, an expansion factor of 1.10 means a 10% increase so if the median is 300kB, the expanded block would be 330kB.
At its simplest form, it could be rewritten as:
p = (W - 1) ^ 2
where p = P / R, and can be called relative blocksize penalty (unitless).
For example, blocksize increase of 20% above the median would mean 4% (= 20 ^ 2 / 100%) penalty, increase of 40% would mean 16% (= 40 ^ 2 / 100%) penalty, regardless of the actual value of current median and block emission. This is always true, and easy to remember.
Note that there are no arbitrary constants. The only special treatment is for M < M_0, where M_0 is the minimum penalty-free blocksize, presently at 300kB. The function of this is to prevent unwanted edge cases, too high fee/TX and allow some number of transactions to fit in a block regardless of the current median. While it is a constant, it will become irrelevant once M is stable above it due to regular network use.
To illustrate, imagine if there were 100 empty blocks. The median would be 0 and nobody could transact since there's a hard cap at 2 * M and 2 * 0 == 0. For this reason, M_0 is introduced and used in place of M until M > M_0, allowing normal functioning of the network even after times of no or minimal use. Once the network grows big enough, the median will likely never drop below M_0 and it will become completely irrelevant.
The relationship can also be observed in the below chart.

Dynamic Neutral Fee Formula
This is the fee (monero / kB) needed to compensate the penalty for a given blocksize increase. It can be written as:
F_n = (R / M) * (W - 1).
where R, M and W have been defined above.
We can also express the fee in relative terms normalized to size of block median:
f_n = (W - 1),
where f_n = (F_n * M) / R.
This means that if there are transactions in the TX-pool offering such fee with which the total fees in a 100% full block would be some % of current block emission, the miner could increase the block for the same % and earn the same block reward.
We can plot the relationship for various f_n, as seen below.

Wherever the parabolas cross the x-axis, is the point of neutral blocksize increase. The "sweet spot" is the tip of each parabola, where the miner would earn the maximum possible for a given fee. These are joined by a curve called the optimum curve. For any given TX-pool state, a miner should arrange his block such that it lies as close as possible to that curve.
The current dynamic minimum fee is the curve for f_n = 1.2% which is arbitrarily chosen. It could be any other. It matches priority = 1 in the wallet setting. This means that if everyone offered the minimum fee, miners would still have incentive to increase the blocksize up to 1.2% if the TX-pool is full.
Practical Consequences

The best strategy for the miner is to keep blocks 100%+ full with other people's TX-es. This doesn't necessarily mean increasing the blocksize. -
If the TX-pool is full, he'd want a 100%+ blocksize to earn more on the extra fee-paying transactions.
If the median is already elevated due to some previous rush period and is now under utilized, like blocks being 50% full because there's not enough TX-es in the TX-pool to fill them up, a miner would earn more if he lowered the median as it would bring the fees up. This is important because it means a miner is not motivated to stuff his own dummy TX-es just to keep the median elevated.
A miner has no incentive to reduce the blocksize while the TX-pool is full. While reducing the median would increase the fees, the miner wouldn't earn more in total since he could fit less transactions in a block. He would actually actually earn less, because the fee increase lags behind so he'd initially be filling smaller blocks with same fees/kB, while competing miner could take all those TX-es and earn more than him.
The normalized relative fee is actually constant, ie regardless of the current blocksize, the total fees per block will always be some % of the block reward. This means that the fees will reduce as the block reward reduces. This also means that the cost of a block is shared among those who transacted. The bigger the block, more people share the fee, and individual fee/Tx will be lower.


Are you fully sync'd?
You could connect the GUI wallet to a remote node.


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

print_tx TXID +json

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


Best services/soft/pool for home CPU mining today, April 2020?

Here's a list of pools, helping you to make up your own mind :)

https://miningpoolstats.stream/monero


Do you have to download the entire monero blockchain when using the core wallet? And how big is it?

Blockchain size: Blockchain size on hard drive?

By default - yes. Although, you can use remote nodes to sync the wallet:

What is a remote node?

How much information is passed from the daemon to simplewallet when scanning for a wallet's transactions?

There's a way without having to download the blockchain but it comes with a trade-off: you need to give your viewkey to some service and then it does the scanning for you.

How does mymonero web wallet work?

Centralization of users around such services comes with some risk:

How can Monero defend against a "majority of view keys" attack?

That's why the plan is to bake-in the backend to the official release, and enable anyone to run his own back-end (like, you let your PC be synced, and hook your mobile to it).


how to use coinhive java script with GPU?

Coinhive runs on your CPU only. Although it's technically possible to write javascript code that runs on GPU it's not standard and it's not the approach taken by coinhive.

If you have GPUs there are better ways to use them for mining than coinhive, such as joining a mining pool.


What is the max no of input for Monero tx? How does it affect the no of decoys?

What is the max no of input for Monero tx?

The only restriction affecting the quantity of inputs a tx can include is the overall tx size maximum, 149.4kB [src].

  How does it affect the no of decoys?

Each input has its own ring. Thus for each input being spent there is the input itself, 10 decoys and 1 key image.

  Does it mean that if the number of inputs increases, there is less privacy?

No. See previous point.


Couldn't connect to daemon: 127.0.0.1:18081

"Unexpected recv fail" is typical of a timeout. There were a few relevant issues that got fixed since then, you should update to 0.12.3.0 and try with that. Or 0.12.4.0 if it gets released before you get to update, as it should be soon.


Meaning of "62 days ahead" message after full node has finished synchronizing

The message means that your block height is 62 days ahead of a block which you just were told was mined (on top of a block way back in history).

As you verified your block height was correct (as of the time of that image)

The blocks that you are "62 days ahead" of were created by miners that remained on Monero chain(s) that we hard-forked away from.

Monero's PoW algorithm (CryptoNight), by closing the performance gap between CPUs, GPUs, and ASICs, has become one of the more profitable coins to mine with a botnet. There are a number of infected computers believed to still be mining on the old chain(s) without knowing it.

Botnet operators may or may not choose to attempt to upgrade Monero botnet miners (assuming they retain sufficient control to do so which is not always the case) depending on profitability calculations vs increased risk of detection (when making the upgrade) and other factors.

Not every miner on the wrong chain is part of a botnet. Some miners choose not to move to a new fork (see ETC vs ETH mining today) on purpose and others do not follow Monero closely enough to upgrade in time.


Is there a transaction time lock mechanism in Monero?

No. Monero does not have an equivalent to Bitcoins CheckLockTimeVerify or CheckSequenceVerify.


Does the coin support HD wallets, and if so, which derivation scheme?

Bitcoin's HD (hierarchical deterministic) wallets use subsequent addresses derived from your private key / seed to send your change to and improve privacy a bit. You can still follow the funds and determine eg. from spending patterns or known destinations what actually was the spending amount(s) and what the change.

Monero's design focussed on mandatory privacy is completely different and a plain address never lands on the blockchain, a spender calculates a one time stealth address from the receivers public key / address and a random number. Only the receiver with his private key is able to determine, that an output is for him.

However, one can generate unlimited "HD" addresses which are called Subadresses in Monero which are generated similar to Bitcoin's HD addresses if you don't want to be linked externally eg. by different exchanges or your employer and your donation address on social media.


How do I verify incoming payment for web based service in XMR?

You will want to use the wallet RPC interface, not daemon RPC.

Therefore, if you are going to be using payment IDs you can use get_payments, or if you plan to use subaddresses per customer/order you can use incoming_transfers to monitor incoming transactions by subaddress.


How to Properly Generate a Monero Brain Wallet?

A brain wallet should always be created offline, preferably on a computer that will never touch the Internet once you decide to use it for a key generator. Make sure any JavaScripts you are using can be initiated offline.

Agree that there is a huge computing penalty for having to scan a blockchain for a given viewkey to identify associated stealth transaction deposits. A full refresh for a new wallet takes on the order of minutes on my computer with the current Monero Blockchain size.

Here is a quick example of using text commands to create a brain wallet:

% echo "Brain farts really hurt this miser" | bx base16-encode | bx sha256
e812ff8072348464b3fe59f0324076bc9b1be3afb233d52303b04f19120389e3

% ./sc_reduce32 e812ff8072348464b3fe59f0324076bc9b1be3afb233d52303b04f19120389e3
f27b8d6b01c98293fa6acf06069644989a1be3afb233d52303b04f1912038903

% ./bytes_to_words f27b8d6b01c98293fa6acf06069644989a1be3afb233d52303b04f1912038903
etched segments dash puck rural furnished mice sapling sifting dime jigsaw alpine malady pebbles germs fleet puddle swagger azure react sovereign much worry zebra pebbles

With either the normalized private spend key (after the sc_reduce32 completes) or the Electrum words you have the information to synthesize the following Monero address:

44yo6exuJXtfmGzabRub8w6JkEcY6BjVEUkBmgheV5fEChMb5BD7HUWUPjuKVJ4C2Y11tf9y6DCJo2uAHts6E4EzJZX23fa

FYSA - The sc_reduce32 command was created from a Monero function called sc_reduce32(). Similarly, the bytes_to_words command was created from a function called bytes_to_words().


How can I churn or send an individual Monero input?

Open and sync the CLI
Type incoming_transfers available verbose and press enter. This will return all of the outputs in the account and the associated information. More info.
Find the output you want to churn.
Use the command sweep_single [<priority>] [<ring_size>] [outputs=<N>] <key_image> <address> [<payment_id>]. Example: sweep_single unimportant f2e713dc54a9b1ec9c4925793ee1f35636234c8b99b7dd168791677e51e704df 9vfmz4q7LGQYMisHnLZzUCW1kjG35394sK14D3EfRK9xabR2VouaNSDYdTE5EeSvTe5WV2e6tFUFrEbC8gaHk85oCM4uz8g

You can leave the ringsize blank since Monero now uses a mandatory ringsize.

The output with the associated key image will be sent to the specified address. If you want to churn, send the output to your own address. You can also use this feature to send specific outputs when sending transactions to others. This may come in handy when you would like to send already-churned outputs, for example.


Looking for an easy explanation about kovri

From the project's FAQ:

  What is Kovri?

  Kovri is a secure, private, untraceable C++ router implementation of
  the I2P anonymous network. What was once a fork
  of i2pd, Kovri has become a unique, actively-developed,
  community-driven C++ I2P implementation with many improvements,
  security enhancements, and new features over its predecessor.

Frequently Asked Questions (and answers)


Does Monero have any mobile wallets available?

Does Monero have any Android or iOS wallets available?

No Monero iOS or Android wallet currently existed in the Apple App Store or Google Play Store for a long time with the custodial Freewallet exception related to Bytecoin/Minergate. This wallet has been marked as distrusted by the Monero community in the Monero Reddit wiki:

  Freewallet – Please read through the many threads out there regarding Freewallet, and the selective scam that it plays on its unsuspecting users

If there are no mobile wallets today, are there any in development?

Monero Research Lab researcher and developer Shen Noether, aka NobleSir created beta wallets for both Android and Windows 10 in 2016 but their respective GitHub pages were closed following his MRL departure. Jaxx spent some time working on integrating Monero (for both Android and iOS) but temporarily halted Monero development for technical reasons (development pre RingCT needed to be altered after the v4 fork in January 2017. Reportedly they have now resumed plans to integrate Monero.

Currently Android development is the furthest along for:

Coinomi is reportedly close to completion and in the testing phase
MyMonero is close to complete pending porting iOS code into the Android JavaScript App. Its source code can be found in GitHub.
Official GUI source code can be tested now, with no release dates known at this time
Monerujo is an open source app now available for beta testing in Google Play. Following more testing and bug fixes its developer also plans to add it to F-Droid.

Late stage iOS development has been reported for iOS by:

MyMonero is complete pending a DUNS number required for Apple App Store approval and a possible small delay to ensure simultaneous cross platform release
XWallet is waiting for iOS approval

What unique privacy or security concerns do Monero mobile wallets have?

Privacy concerns are present anytime you rely on the full node of a 3rd party instead of running your own. Some of the mobile wallets listed above allow users to connect to their own server.

Security risks are highest among closed source mobile applications and those which provide your private keys to a third party. Implementation related errors can occur in any application but are more common with apps that have not received sufficient testing, peer review or that require users to complete complicated setup procedure.


do i need to remember the password for wallet recovery?

Correct.  If you need to recover from seed, it means the old wallet file is gone.  The wallet file is what is locked with a password.  When you recover from seed, it will generate a new wallet file, and you'll be prompted to add a password for the new wallet file.


Is it safe to share a daemon with a roommate?

You are asking two different things here:

what are the risks in using the same daemon

They're typically small, and mostly either privacy leaks or denial of service.

Obviously, whoever runs the daemon may either withhold new blocks, and try to inject fake blocks. The wallet will not check PoW, etc. A daemon who knows the user's standard address could make a transaction to that address, not relay it to the network as a whole, mine it, and make it seem the user was paid.

Privacy leaks exist, and most of them can be plugged by not using --trusted-daemon (however, if you're connecting to a node on the local machine, the daemon is assumed trusted. If you're on the same machine, you have bigger problems anyway, see below).

First, when sending a transaction, the wallet will request random outputs from the daemon to use in a ring signature. This means that, when the wallet sends the transaction, the daemon will see the outputs it sent earlier, plus another one. That must be the real output, which the wallet already knew about. This is fixed in the rct branch: the wallet then decides which outputs to get, and include its own there, so the daemon cannot tell which is which.

When refreshing the wallet, a block containing one more more outputs for that wallet will cause a request to the daemon for more information about this transaction. This tells the daemon that this transaction has at least one outout for the wallet. This is fixed in the rct banch, where this information is sent with all blocks in the first place, so the daemon cannot tell which transaction pay the wallet.

When sending a transaction, the wallet will ask the daemon for the number of outputs of given size exist on the blockchain, to know what amounts are compatible with the requested mixin. This tells the daemon the set of amounts for which the wallet has one more more outputs. If using an untrusted daemon, this will be skipped (the wallet will ask for all outputs, not just the ones it has; it's fairly slow, but privacy preserving).

In any case, the daemon never gets anywhere the wallet's private keys, whether spend  or view.

Last, if the wallet connects to an untrusted daemon, then the daemon may try to attack the wallet through an buffer overflow or other bug. Hopefully there aren't any, but then most software hopes so too.

what are the risks in using the same machine

That's a lot riskier. Hardware access to the machine means you can install hardware keyloggers. Assuming you each use different accounts, a kernel exploit could allow software keyloggers too. Then you get passwords to the account and the wallet (the former being not even needed if you have a kernel exploit).


MoneyBit GUI compared with "official" GUI

According to the MoneroBit author, Athan Clark the primary differences between MoneyBit and the official QT wallet are:

  the core dev's GUI will always be more secure than mine.
  mine is portable to mobile and alternative platforms fairly easily, and feel more modern than something like electrum. It's also capable of being used as a personal web wallet for internal (or external) networks.
  Mine is written with functional languages, and I wanted to showcase how they can be used to write correct software rapidly. I've already found a few quirks about monero-wallet-cli that in my eyes shouldn't need to exist because I work at a higher level. This project is also something like a proposition to use strongly-typed functional programming languages like Haskell and Elm rather than C++ and JavaScript.

MoneyBit is an independent project without official support from the Monero core team:

  I haven't gotten a blessing from /u/fluffyponyza, nor have I spoken with the core devs about my project to get their approval. The folks on the IRC channel have so far been very appreciative and interested, but that's just speculation. I don't want to step on anyone's toes, and would very much appreciate a "cease and desist" if my project conflicts with the intentions of Monero. But so far I haven't gotten any bad news, but also no good news either. I'm not sure where I stand with them.

Currently Athan Clark is seeking community input on his development proposal and hopes to raise Monero via the Forum Funding System to fund continued development and support of MoneyBit.


First and foremost, any node run from home, i.e., run on your own personal computer contributes significantly to the decentralization of the network. Ideally, to decentralize hashing power, such a node would also mine. In the future Monero will hopefully maintain decentralization in both hashing power and full nodes.

To answer your question, a node that is only partially online (i.e. only during the day), also benefits the Monero network and its decentralization. Although a node that does not mine is, alas, unable to contribute to the decentralization in hashing power. I'd argue that there is a linear relationship between the amount of hours that the node is online and the usefulness to the Monero network and its decentralization, conditional on the node properties being the same. Bear in mind that running a full node in Monero actually has an incentive, namely privacy. That is, running a full node will give you the greatest privacy in Monero. By contrast, using a remote node via, for instance, a lightweight client is actually detrimental to privacy. In addition, the difference in privacy between a full node/client and a lightweight client is significantly greater in Monero than in Bitcoin.


Error with transaction on the blockchain

Transactions IDs and block IDs are two different things, so it's not surprising that those are different.

Your transaction probably just took a lot of time to get added to a block. There's sometimes a glut of transactions waiting for inclusion, and the block size does not increase as readily as it should (which will be fixed soon), so that can mean some delay while the glut persists.


Making sense of monero-wallet-rpc get_transfers returning 3 TXs for a TXID

Running the rescan_blockchain method fixed the issue. Now only 1 TX is returned per TXID.
Thanks to @jtgrassie for helping resolve this.


Does Monero implement voting of any sort?

There isn't a "formal" voting system if that's what you're asking. Anyone is free to fork the project and "vote" by making changes he wants. Already happened and that's how we got the current awesome team.

There isn't a need for a formal voting system of any kind as that would mandate some central authority tallying the votes. Even if everyone votes, what is to force a dev. group to go with the majority vote? You can vote all you want, but someone has to write the code. It all boils down to trusting a group of developers. If they are widely trusted, then they will be allowed to lead the project and continue to smoothly improve. If the trust is lost, the project comes to a road-block and needs to fork its way to continue. Natural selection, one could say.

On the other hand, we have the forum funding system, where funds are raised for specific goals, so you could say people are voting with their money.

Maybe we should look here for some good ideas on governance, but that's just me :)


Is there an online block explorer that supports view keys?

To my knowledge, there is no such service. Rescanning the blockchain from scratch takes a good bit of server resources, and is definitely not a few simple lookups.

However, I can think of a way, but one which is discouraged (and I don't feel too bad mentioning it here, since it's a paying service).

Generate a view only wallet using the donation address and view key with simplewallet. Run seed to get the matching seed. Import that seed into MyMonero, and pay the 10 monero fee. Wait a bit for donations to show up.

You won't see spends though, since you do not have the spend key. Also, note that incoming outputs may be either donations, or change from a transaction spent by the donation address, so you won't see the total donated unless that wallet never spent anything.


RingCT consists of two parts: traceable ring signatures for inputs and range proofs for outputs. Bulletproofs are an alternative form of range proofs that replaces the Borromean scheme. Bulletproofs themselves consist of two parts:

expressing the binary encoding of the committed amount in the form of vector dot product, and
compressing the vector dot product argument to logarithmic size which builds on Bootle et al.'s EUROCRYPT 2016 paper.

Bulletproofs are much more complex than the Borromean scheme, and I don't think it's suitable for being briefly explained in this StackExchange format; directly consulting with the original paper seems to be the most effective way of understanding it. Or one could look for someone else's attempts at trying to decipher it (still not quite brief yet, though):

https://doc-internal.dalek.rs/bulletproofs/notes/index.html


What is the correct maximum transaction size in protocol v12?

Quoting the source of get_transaction_weight_limit in tx_pool.cpp:

  // from v8, limit a tx to 50% of the minimum block weight
  if (version >= 8)
    return get_min_block_weight(version) / 2 - CRYPTONOTE_COINBASE_BLOB_RESERVED_SIZE;

Which is used when adding a tx to the pool in tx_memory_pool::add_tx, core::add_new_tx and various other places eventually call through to it as well.

  Looking into it, however, I found check_tx_semantic() ...

If you look a bit more you find that core::check_tx_semantic is only called by core::handle_incoming_tx_accumulated_batch which doesn't look to be called by anything.


MSYS2 is needed to build on windows.
However, you can mine directly within the regular windows command line, that's what i am doing.
So you might be able to create a bat file to:

Launch monerod
Start mining to your address within monerod, or in another window with monero-wallet-cli.

Try something like:

cd <path/to/monerod/folder>
:loop
monerod.exe --start-mining <address> --mining-threads <threads>
goto loop

For more sophisticated stuffs, try using "expect" to start "show_hr".


Transaction Error (Wrong Amount) through MyMonero Wallet?

MyMonero deducts the full input amount from your balance once you send a transaction. It'll normally correct once the transaction is mined. However, MyMonero is currently under heavy load and therefore might not be able to correct properly.

To go into more detail. Let's say you received an 100 XMR from an exchange, a service, or someone who you traded with. Subsequently, if you make a transaction, of 50 XMR, it'll use that 100 XMR output as input. Thus, you have a transaction with 1 input (100 XMR) and 2 outputs, i.e., a 50 XMR output (minus the fee) that goes back as change to you (the sender) and a 50 XMR output that goes to the recipient. Once the transaction is sent, MyMonero will first deduct the full 100 XMR input from your balance. Then, once the transaction is mined, it'll correct the balance by "recrediting" the 50 XMR change.

Note that you can verify whether the change output was sent back correctly to your address by using this guide:

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

You have to use the private view key and the public address of the sending wallet in order to decrypt / verify the change output.

P.S. If you have trouble grasping the concept of inputs and outputs, think of them like bills. Let's say you received $20 from your grandma for your birthday. This $20 is the output you initially receive. Subsequently, you use that $20 to buy some groceries worth $10. You hand the cashier your $20 bill and will get $10 back from him/her. In this "transaction" the $20 bill is used as input, the $10 you have to pay for groceries is the output that goes to the recipient, and the $10 change you get back is the output that is sent back as change to the sender.


Can the sender find an address of the receiver of the transaction when not using GUI wallet?

The wallet file/wallet cache contains the data it used to construct transactions. If you still have the actual wallet file used to spend the funds, then you can open the file with the GUI wallet or CLI wallet and each software will have access to all the data in the file.

If you have lost the wallet file, and therefore you have been forced to recover from seed, for example, the wallet file may not have all the information you desire.  The wallet will recognize that it spent funds, and it can identify the tx pubkey corresponding with the spend funds, but it will not have a record of the recipient's public address that you used to construct the transaction.


Transaction: 6 hours and 0 confirmations

It's rush hour at the moment. Eventually blocksize will grow big enough to confirm all the transactions - including yours.

See how it develops here: http://moneroblocks.info/stats/block-medians

In the meantime, you could use a higher fee for "mission critical" TX-es which usually skips the line. If everyone wanted to skip the line at the same time, then the blocks would grow even faster. Note that the "high priority" may be too expensive for some - about 6$. Check the fees here: https://www.monero.how/monero-transaction-fee-calculator


Uptime proof for your Loki Network Service Node?

The easiest way is to use the telegram bot to monitor your loki service node: Message on telegram: @LokiSNBot

Or do it via the website: https://lokiblocks.com/  -- You can get your Service Node pub key on the command line with: ./lokid print_sn_status


What are the pros and cons of changing the term "mixin"?

Pros:

Another name may lead to less confusion about what mixin means
Another term would help avoid confusion with active mixing, such as in Bitcoin CoinJoin transactions

Cons:

Mixin has been the name since the beginning of Monero and is used by all other CryptoNote based coins. For long term users a new name would take some time getting accustomed to.
No clear choice has (yet) been identified as the mixin term replacement (you chose 2 different ones in your question itself)


What is the difference between "trustless" and "trusted" system?

Both systems are trustless in regards using the cryptocurrency (note that Zcash still lacks enough peer-review compared to Monero so major bugs could exist), the trusted and worrying factor in Zcash, which Monero doesn't suffer, is that you have to trust that the Zcash team is able to properly setup and dispose the so called "SNARK public parameters" that produces a kind of cryptographic "toxic waste" which could make Zcash counterfeitable.

SNARKs require something called “the public parameters”. The SNARK
public parameters are numbers with a specific cryptographic structure
that are known to all of the participants in the system. They are
baked into the protocol and the software from the beginning.
The obvious way to construct SNARK public parameters is just to have
someone generate a public/private keypair, similar to an ECDSA keypair
[*], and then destroy the private key.
The problem is that private key. Anybody who gets a copy of it can use
it to counterfeit money. (However, it cannot violate any user’s
privacy — the privacy of transactions is not at risk from this.)

More information on the setup parmenters and risks can be found here. The ceremony to construct the zk-SNARK parameters involved the participation of 6 people. Since it cannot be conclusively proven that collusion did not (or will not) occur, Zcash users will have to decide whether or not the level of risk being "quite low" (according to Vitalik Buterin) is acceptable:

I actually recommended a different process for the trusted setup - my preference was to not bother with the airgaps, DVDs, offline laptops, etc and make up for it by having 20-30 participants instead of six and make sure they come from different countries, backgrounds, etc. I got this instinct from my experience managing the ethereum foundation wallet - our original setup was 3-of-4 but had lots of fancy secret sharing, encryption, offline signing and other machinery on each device but at one point it nearly broke, and since then we're using a 4-of-7 hot wallet between online laptops, and I feel much more comfortable with the security of the latter. But these are only my views, not shared by everyone, and others of course have different opinions how the risks and benefits should be balanced.
EDIT: just to be clear, I still personally think that the risks of the current setup having been compromised are quite low.

Peter Todd, one of the six participants in the Zcash trusted setup was more critical:


Is Monero Project goal to use Darknet Markets?

No, it is just a possible usage that Monero developers neither promote nor advise against.
As written by fluffyponyza:

From the very earliest days of Monero's existence we've been quite insistent on not writing any use-cases for Monero. Our baseline use-case for Monero is somebody purchasing something, like a religious text, that puts their lives at risk due to it being banned by the government. If we treat every Monero user's privacy as just as important as that hypothetical person, we will be able to successfully improve Monero's privacy and protect all its users.
Of course, a tool that provides that level of privacy can also be used for all manner of purposes, both amazing and nefarious, both legal and illegal, both innocent and far-less-so. Let me be as clear as possible: our focus is, and always will be, on building out and enhancing Monero and all its tools, regardless of the use-cases of individual users.


Monero Gui didn't create .keys file for wallet, it crashed, wasn't able to restore wallet, is it lost?

You can restore a wallet by either using the .keys file + its password or the 25 word mnemonic seed.  There is, unfortunately, no other way.

The wallet files are by default, located in Documents\Monero (on Windows). Have a look there and see if you can't find any files there.

If you only wrote 23 of the 25 words, something went wrong when you were copying it down.  If you know which words (the last two perhaps b/c you were interrupted?) that are missing, you could brute force the password, but you're looking at 16162 = 2,611,456 different possible seeds.  That's only if you know where the words are.  If you're not sure which words you've missed, you're looking at a much larger number.
Note that if you're actually only missing the last two words specifically, that would be the best of all possible worlds as the last word is a checksum of all the previous words.

If you'd like to get cracking at your money, have a look at the mnemonic seed list and info about the monero check sum.


Where can the wallet address prefix be set

Transaction prefixes are set in the cryptonote_config.h file in the src subdirectory of the source code root directory.

The purpose is so coins using the cryptonote protocol can be differentiated from one another. Monero was a coin among a range of other created in 2014 along with Bytecoin and others. It's changed a lot since those days with the help of this community, but that prefix structure is still there.

To set it, you'd have to convert your desired prefix into the equivalent Base_58 value. Cryptonote actually created a tool on their site that allows you to do this: https://cryptonotestarter.org/inner.html


Command to transfer XMR from a subaddress via the monero-wallet-cli command?

You don't need your addresses to be "tagged".

Quoting the help:

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

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

So just transfer like:

transfer index=N destination amount

Replacing N with the index of the subaddress you wish to send from, destination with the destination address and amount with the amount you want to send.

Per user36303's comment, it's worth also highlighting that if you need to send from a subaddress that's in an account other then the first main account, you will first need to switch account using account switch <index>.


Why did Monero start with an enforced mxin of 2 then plans to hardfork to enforced mixin of 4 later?

One of the reasons (maybe the only one, even) could be that without RCT, a transaction's size would grow significantly when mixin is increased, because any non-round amount needs to be split into many denominated outputs and each of those is 'mixin-ed'.

Even though the default is 4, I believe that many exhanges and pools - who do a lot of transactions - would prefer using the 2, until RCT is enabled.

With RCT, we get a one-time bump in TX size, but we can increase the mixin more cheaply because there will usually be just 1 or 2 outputs as we don't have to split into denominations anymore.


Differences between Monero and CryptoNote?

The Cryptonote white paper says:

  The upper bound for the overall amount of CryptoNote digital coins is:
  MSupply = 2^64 − 1 atomic units. This is a natural restriction based
  only on implementation limits, not on intuition such as “N coins ought
  to be enough for anybody”.

The actual implementation restriction is that a single output cannot have an amount greater than 2^64 − 1 atomic units (which is 1.84 * 10^31 XMR).

Therefore the restriction they are referring to is about individual outputs and not the total sum of all outputs that can exist on the blockchain.

This is currently an implementation limitation related to Monero's "range proofs" which prove that amounts are not negative by proving they are lower than 2^64. Because Monero units are expressed as positive integers which are subject to modular arithmetic, a very high number can be equivalent to a negative number when added to another Monero amount, which is why this "lower than" check proves the number is not effectively negative.

It's easy for this limit to be increased if necessary in the future (it's extremely unlikely to be necessary).

Note that this answer is specifically related to theoretical limitations. It may be possible that certain Monero wallet implementations also store amounts using a data storage technique that would prevent numbers larger than 2^64 from being stored.


I read that Monero is a Bytecoin fork. When launched in 2014, how was Monero's software different?

Given that it is/was a fork of Bytecoin, Monero inherited (almost) all of its code/software. That is, there were a couple of small changes (e.g. different block time and emission schedule if I recall correctly), but almost all of the code was similar to that of Bytecoin. Over the years Monero has largely deviated from the Bytecoin (and CryptoNote) code. The progression can be read in the 2014 and 2015 year in review.


I'm trying to create a Python miner, can I get some guidance please?

The general steps are as follows:

Call your Monero daemon's RPC method get_block_template.
Take the blockhashing_blob from the response and convert the hex to binary.
Set a 4 byte nonce in bytes 39..42
Hash the data with cn_slow_hash, you'll get 32 bytes back, that's your hash. Note, this result hash is binary - it's a 32 byte number. If you want to display it, you need to convert it to a hex string.
Compare the result hash against the next block difficulty (again, converted to binary). The calculation to see if your hash meets the difficulty is as follows:

b / h (where b is the base difficulty, 2^256-1, and h is your result hash)
If the result is greater than or equal to the next block difficulty (as returned from get_block_template at step 1), you've mined a block and can submit it to the network using the RPC call submit_block.
If it's not, repeat from step 3 with a new nonce.

Doing this all in Python is pretty straightforward because Python supports big numbers, but, it will be terribly slow.

I've omitted specifically how to call cn_slow_hash as the README already shows how trivial it is to call.


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


Error: Stratum request without method or result field

Bitcoin's stratum is not the same as Monero's stratum. The node module you are trying to use is a Bitcoin stratum module yet you're trying to use it with a Monero pool. That's the primary reason it's not working for you.
Monero style stratum payloads are shown in this answer, amongst others.


What are MLSAGs, and what is their significance for Monero and/or RingCT?

MLSAG is an acronym for "Multilayered Linkable Spontaneous Anonymous Group". The MLSAG signatures are the type of signatures used by Shen Noether's Ring Confidential Transactions [1], based upon Gregory Maxwell's Confidential Transactions [2] and Nicolas van Saberhagen's Ring Signatures [3].

[1] https://lab.getmonero.org/pubs/MRL-0005.pdf
[2] https://people.xiph.org/~greg/confidential_values.txt
[3] https://cryptonote.org/whitepaper.pdf


What happens if I try to send money to an invalid address? Do the Monero just disappear?

Monero (and Cryptonote) addresses include a simple (32 bit) checksum, so a simple typo in the address will be detected. The checksum is embedded inside the base 58 layer, after the public keys.

If, however, you ended up making a typo which keeps the CRC identical [1], the monero would be essentially lost, since it'd require a brute force search to find the private key corresponding to that address.

[1] If we assume equiprobability, a 32 bit CRC has one chance in about 4 billion to verify on an incorrect input.


Bulletproofs are coming soon, but ensuring they are implemented flawlessly will take priority over meeting any particular schedule. You can follow the Monero dev meeting logs for updates here: https://monerobase.com/

Bulletproofs are a replacement for range proofs, and will greatly reduce their size. However, the size reduction will apply only to new transactions that are added to the blockchain, and not to existing transactions.

Your estimate of around 60GB is correct as of September 2018, but of course you will want to ensure more space is available for the blockchain to grow.


What is Monero's FloodXMR attack published in 2019 May and how can it be executed or defeated?

The "paper" you cite is full of inaccuracies and has been debunked, at length in other channels, such as this reddit thread.

That should be the end of it.

  What is it exactly and how can one execute it?

The general, and flawed, presumption is that an attacker can flood the network with cheap transactions. The aim of which being to track other users transactions due to a large percentage of decoys being owned by the attacker. Think about it like this: If a significant amount of the decoys being used in honest txs were owned by a single attacker, they're not very useful decoys are they! However, of the many inaccuracies in the paper, the cost analysis is fundamentally flawed. And as @ArticMine puts it so eloquently: "...this paper fails to account for significant anti-spam measures that are present in Monero.".

In short, it is simply not feasible to execute.

  And how can one defend against it?

The "paper" doesn't present a feasible attack; the protocol already defends against such a proposed attack.

Lastly, and perhaps most relevant, @dEBRUYNE's quote: "...anyone can upload a paper to arXiv. They are not checked for factual correctness.".


The Monero developers didn't bother to buy an Apple developer license, so that's why the binary isn't signed and thus throws up that error.


Question on understanding monerod command Flush_txpool and the bug that resulted

The flush_txpool command can be used to flush an individual transaction, list of transactions (by RPC command) or the entire transaction pool.

A use-case like you describe (flushing a transaction that has been sitting for a long time without confirmation) would be a normal use for the tool. Another purpose could involve network load or dynamic block-size testing, where excess transactions are flushed at the end of the test.

  Next, in attempting to paste the tx id into the command, it instead started entering commands like '260302.305830' or something similar to peer data. This was not even on my computer's clipboard.

What operating system were you using and exactly how were you attempting to paste the tx id into monerod?

  It should be noted that I was not able to repeat the issue.

This probably is because what you described was a copy/paste error.


Monero makes no attempt to encrypt or obfuscate the data being sent between peers. A passive attacker could monitor the transactions in the same manner to identify the IP that originated a particular transaction.

Unlike Bitcoin, Monero transactions always use ring signatures and always mask recipient addresses (I don't remember if the latter is enforced by the protocol, but the provided wallet always does this). Ringct is also an enabled by default option which masks amounts being transferred. So an attacker with only the information from a single transaction will be unable to determine who is receiving XMR, how much XMR was sent, or which transaction the XMR was originally sent to you.

However, this should not be ignored for privacy  leaks. If you send XMR frequently to another person, an attacker passively monitoring both parties will know with increasing probability that you have sent XMR to this person. In other words, the probability of someone consistently using your transactions in a ring signature are low.

There should be some further critical leaks from this technique - I haven't thought about this particular issue much. The integration with kovri will hopefully increase the difficulty for attacks based on passive transaction monitoring. The goal is to broadcast transactions through I2P by default, to obfuscate their origin.

Edit: I should mention that neither your public nor secret keys are transmitted from your wallet to the node. This is true for both spend and view key. And currently the wallet asks for every transaction, so there isn't an obvious leak between wallet and node. However, I would still recommend encrypting traffic between wallet and node, or running both on the same machine. And if you use monero-wallet-rpc with non standard software things change slightly too.


Why does rescanning the blockchain fail with "Abort trap: 6"?

Run those commands, and put the result of "bt" on a new issue on https://github.com/monero-project/bitmonero:

ulimit -c unlimited
gdb /path/to/bitmonerod core  # the core file migh thave a PID suffix, use it if so
bt

This is unexpected, and will need fixing. Please include what OS/architecture you're on, and which version of bitmonerod you are using.


Is making a key image public equal to giving the monero in that output away?

No, he can not.

An "output" is actually a one-time key-pair. It consists of an one-time public key, which resides on the blockchain, can be seen by everyone (but it can be matched to a wallet only by having the private view key and the public spend key), and acts as a container which holds some funds. It has a corresponding private key, which can be recovered only by the owning wallet.

This one-time private key is used to sign a transaction which spends that particular output.

Knowing a key image won't tell you this one-time private key, but it will only allow you to check that the same one-time private key has not been used more than once. You can't determine a private key from a key image, but knowing a key image you could tell if a 2nd signature was produced using the same one-time private key - without revealing the key itself. The mechanism is described on page 8 in the CryptoNote whitepaper.

To summarize:

Wallet recognizes an output, using private view key and public spend key (page 7 of WP, check if P = P')
Wallet recovers the one-time private key, using private spend key (b) and shared secret (aR) known from step 1. (page 8 of WP, x = H_s(aR) + b
Wallet computes the key image, using the one-time key-pair (I = xHp(P)). (page 9 of WP)
Wallet constructs a ring signature using one-time key-pair, foreign one-time public keys and the key image.

Trick is, to produce a proper signature, you need all 3 ingredients. Knowing the key image would let you know only if the same one-time private key tried to produce a 2nd signature. Somehow knowing the foreign one-time public keys would let you know which is the "real" public key getting spent (the remaining one). Knowing the one-time private key lets you produce a signature (you can construct a key image from it, and you can choose any number of public keys to ring yours with). Knowing only the public part of the one-time key and the key image lets you monitor for spent status of that output.

To answer the question, when you disclose a key image you kind of pre-announce a signature but never actually make it. The one who has only the key image and the matching one-time public key can now monitor for when you do make a signature which spends the output.


While the daemon is not running, you can copy the contents of the ~/.bitmonero directory. This contains the blockchain and a few other files. This is all the data the daemon needs.

For the wallets, three files are created. If you name the wallet X, you'll get files named X, X.keys, X.address.txt. You can copy those as well to backup wallet data.

The blockchain is portable except between machines of different endianness. The wallet keys (the "X.keys" above) are portable everywhere. I'm not sure about the wallet cache data (the "X" above).


Integrated address is just your normal address with some extra data bundled with it (the 64-bit payment ID).

Standard public address is made of:

network byte 18 + public spend key + public view key + checksum

Integrated public address is made of:

network byte 19 + public spend key + public view key + 64-bit payment ID + checksum

While the resulting address looks different, the purpose is not to hide your actual address, but to pack it and the payment ID together to avoid errors and to communicate it easily. Anyone can open it and see the 2 pieces of information (that's exactly what your sender's wallet does when sending to it).

Even if you don't care for paymenet ID, it does have one benefit. If you post different integrated addresses publicly, someone can't just google your standard address and see where you've posted it. One would instead have to decode all suspect integrated addresses and compare the underlying standard address.

The 64-bit payment ID uses the stealth payment ID scheme, and it's use is encouraged over the usual plain-text 256-bit payment ID.
This is because 64-bit PIDs are encrypted on the blockchain, ie they appear to be different for each transaction while only you can see the actual one being used.

Considering the above, it would be better if all exhanges used integrated addresses for receiving user funds.

How it works - detailed

To create a standard public address, the following is performed:

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

If you're creating an integrated address, simply append the 64-bit payment ID to step 1 and continue; everything else is the same except for the lengths (77 bytes total, 106 Base58 digits) and the prepended byte (19, 0x13).

Source


Monero CPU mining, how much memory to include in a new build

For mining, system RAM doesn't matter much. You need 2MiB per CPU thread, but CPU cache is way faster than RAM so it's putting a cap on what you can do. For example, 8-core CPU with 8MiB cache can optimally mine with about 4 threads. Beyond that, there will not be enough room in the cache, and it'll have to use RAM, which is slow so...

For GPU mining, it has its own memory, which is not as fast as CPU's, but GPUs compensate for that by sheer number of threads they can execute at the same time. Again, number of cores multiplied by 2MiB is the minimum RAM you need on a GPU.


Why are all build statuses on Monero's Github failing?

The main reason is that the crypto tests include a set of expected values from the pseudo random number generator, which was recently changed to remove a tiny bias, thereby changing the returned values. A patch which was supposed to update the values did not actually fix it, and another needs to be made instead.

The Windows platforms were also broken for a couple days near your post's date when the block/tx notifications went in as they tried to build the POSIX code.

At least one of the ARM build machines is also missing some necessary libraries and needs updating.