Estimating anonymity set size? Is there any way to at least estimate what kind of anonymity set a user would have after churning Monero X times assuming the anonymity set of each individual transaction is the ringsize (i.e. there are no major flaws that would give an attacker any ideas about which inputs are decoys)?
The adversary I'm thinking about in this case would be someone looking at a future transaction (say, a cash out to an exchange to convert Monero to fiat) and attempting to correlate that transaction to the earlier transaction where the same user converted fiat/another cryptocoin to Monero at an exchange. So basically an E-A-E attack.
Intuitively, it would seem like if you waited a reasonable amount of time between transactions the anonymity set would be ringsize^(number of churns), as each transaction has (ringsize) inputs and by the time you started your next churn each decoy has likely been used at least once giving another (ringsize) decoys for each decoy you used, and by the time you churn again each of those decoys has likely been used again giving another (ringsize) decoys per decoy etc, but the anonymity set in that case grows well beyond the total number of transactions on the entire blockchain with just a few churns so that can't be right.

Any given output in a ring has a 1/11 chance it is the true spend, whether you see that output in one ring or N different tx rings.
One of the problems with churning is it can easily have the opposite and undesired effect - reducing ones anonymity set. This can either be through timing analysis and / or linked outputs (e.g. seeing a tx with 3 specific outputs being spent and those 3 input rings each having one of the original 3 outputs).
For example, if an exchange sends you 3 outputs in a transaction (your withdrawal) and you then merge all those outputs (via a churn) to a subsequent single tx, the chance of it being you spending becomes significantly higher: 1 tx, 3 input rings with each ring containing 1 of the original 3 withdrawal outputs; it's an almost certainty it's you.
If on the other hand you hadn't performed this churn, you defer the decision making to the wallet to make its best effort in avoiding creating this kind of association. Which brings us to one of the specific cases of churning that can help. If you don't have enough other spare outputs to fund the new transaction, then performing careful churns (utilizing sweep_single) comes into play, as you can perform individual churns on those 3 outputs. Which brings us to the interesting part of your question: timing.
Performing 3 sweep_single transactions to churn those outputs in quick succession, isn't going to help much. Imagine all 3 in different transactions but in the same block - bingo, you're not greatly improved. What you really want to do is space them out to a degree that they could have naturally been selected as decoys in other transactions.
There's no comprehensive research yet (at least that I've come across) to give an indication of the best timing to use, though this topic does come up from time-to-time in MRL discussions, often in relation to the output selection algorithm, to improve default wallet behavior. One thing we can say for certain is that spreading out these single output churns over hours, days or even weeks is going to be better that in the same transaction or block.


Error when launching (--rpc-bind-ip) monerod with external IP address: Failed to bind server I thought I would try and set up a remote node, but I'm getting errors:

$ ./monerod --rpc-bind-ip 31.xxx.xxx.xxx --restricted-rpc --confirm-external-bind
2017-05-30 10:47:13.002     INFO    global  contrib/epee/src/mlog.cpp:145   New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO
2017-05-30 10:47:13.003     INFO    global  src/daemon/main.cpp:282 Monero 'Wolfram Warptangent' (v0.10.3.1-release)
2017-05-30 10:47:13.003     INFO    global  src/daemon/protocol.h:55    Initializing cryptonote protocol...
2017-05-30 10:47:13.003     INFO    global  src/daemon/protocol.h:60    Cryptonote protocol initialized OK
2017-05-30 10:47:13.003     INFO    global  src/daemon/p2p.h:63 Initializing p2p server...
2017-05-30 10:47:17.789     INFO    global  src/daemon/p2p.h:68 P2p server initialized OK
2017-05-30 10:47:17.789     INFO    global  src/daemon/rpc.h:58 Initializing core rpc server...
2017-05-30 10:47:17.789     INFO    global  contrib/epee/include/net/http_server_impl_base.h:70 Binding on 31.185.55.164:18081
2017-05-30 10:47:17.790     ERROR   net.http    contrib/epee/include/net/http_server_impl_base.h:74 Failed to bind server
2017-05-30 10:47:17.790     INFO    global  src/daemon/p2p.h:90 Deinitializing p2p...
2017-05-30 10:47:17.793     INFO    global  src/daemon/core.h:89    Deinitializing core...
2017-05-30 10:47:17.793     ERROR   daemon  src/daemon/core.h:94    Failed to deinitialize core...
2017-05-30 10:47:17.793     INFO    global  src/daemon/protocol.h:77    Stopping cryptonote protocol...
2017-05-30 10:47:17.793     INFO    global  src/daemon/protocol.h:81    Cryptonote protocol stopped successfully
2017-05-30 10:47:17.793     ERROR   daemon  src/daemon/main.cpp:290 Exception in main! Failed to initialize core rpc server.

I'm pretty sure I've got ports 18080 and 18081 open and have forwarded the ports on my router.

It works if I set up a LAN IP address. Just can't get it working with an external IP address. Any ideas?

It looks like you are attempting to bind to your public internet address, which is the address of your router. This will not work, because you need to bind to an IP address that is actually attached to your local network interface (the IP address of your computer on your local network).

If you bind to that, then traffic that hits your router's public internet address will be forwarded to your computer's IP address on your local network, and the daemon will be listening on that IP address to accept the traffic.


Get transaction input ring members as public keys How can I get transaction ring members using the monerod RPC methods?


How can I calculate the Monero network hashrate? I've seen this question but unfortunately it doesn't contain an answer to my question.

The question is: how can I calculate actual hashrate of the whole network? As far as I understand, it depends on difficulty in some way but I can not understand that dependency.

The hash rate can only be estimated from the difficulty, which is itself adjusted up and down based on how fast blocks are found compared to the 120 second target. This estimation is the difficulty (currently 7462457559) divided by the target (currently 120 seconds), so currently about 62 MH/s.


output_tx on Genesis Block I made a monero fork and generated a genesis block with a new one-time P but i never see the first reward in my wallet.

Can somebody tell me what is the index_output used on the output of a custom genesis block. ?

i mean, in order to create an output pub key we do

P=Hs(8rA || i)G+B

A = Pub_view_key , B = Pub_spend_key , i = index

so, i have to do it with i = 1 ? or i = 0 ?, is it the same to do Hs(8rA || 0) than Hs(8rA).

It's the output index. Assuming you just have one output (all the reward to a single output), just use 0. E.g. P=Hs(8rA || 0)G+B.


How do you make sure a sender isn't sending bogus funds? It is my understanding that RingCT allows the verifier to make sure that the sum of the inputs is the same as the sum of the outputs in a transaction, so that no monero is magically created or lost. All while hiding the actual amounts.

However, in the event where the sender would be giving more monero than his balance, how is that detected by the network ?

If the sender would be giving more monero than his balance,

In this event, he can't sign the transaction because the actual transaction input (P,C) is previous transaction output someone sent to this sender and (P,C) was recorded by blockchain.

P is the stealth address, C contains the amount.


A way to add to tx_extra with current monero executables Disclaimer: This is my first ever post. Please let me know if I didn't follow the guidelines for asking a question. Thank you all.

I have stumbled upon this issue with other questions but none answered a proper way to add some kind of sender-based data to be added in the extra field of a monero transaction.

Some suggested editing the monero source code and some say to use paymentID. However, with paymentID being obsolete now, I want a way to add data to the field without any restriction knowing that I won't exceed the block size of course.

If the only way is to edit the source code of monero, I had a look at the structure of the code (especially monero-wallet-rpc) and I was wondering what I can change to provide that functionality. I know I will have to change something too in the wallet-cli or the daemon but I'm still exploring.

Any guidance towards solving the problem of having the ability to add bytes to extra that are sender specified would be much appreciated.

Only the old, long-form, unencrypted payment IDs are obsolete. You can still use the short (8 byte) encrypted payment IDs.

You create/attach encrypted payment IDs by using the command integrated_address:

help integrated_address

Command usage:
  integrated_address [device] [<payment_id> | <address>]

Command description:
  Encode a payment ID into an integrated address for the current wallet public address (no argument uses a random payment ID), or decode an integrated address to standard address and payment ID

Replacing <payment_id> with the 8 hex bytes you want to use. The result will be an integrated address with an embedded encrypted payment ID. E.g.

integrated_address deadbeeffacefeed

More information can be found: https://web.getmonero.org/resources/moneropedia/paymentid.html


Which CPU/GPU Monero miner for macOS? I was wondering what would be the best CPU/GPU Monero/cryptonight miner for MacOS. I have an Intel Core i7 CPU and AMD Radeon 460 GPU.

Xmr-stak is one of the best Monero mining programs and you can easily compile it for macOS. All the necessary instructions are here: Compile xmr-stak for macOS.


Funds received from subwallet are not showing My wallet has approximately 60,000 subaddresses.

I was running monero-wallet-rpc, and somehow (I think) the program was not able to save the wallet successfully.

When I started monero-wallet-rpc again, my wallet shows the last 10 transactions missing.

I think the wallet file lost some subaddresses.

Is there a way to recover funds from subaddresses? I can’t find any options in Monero GUI.

I also want to know if I can get all 60,000 subaddresses from just recovering the keys from a mnemonic seed.

Thanks.

Monero "looks ahead" 200 subaddress indices from the highest subaddress index that it observes it has received an incoming payment to.

Therefore if you ever issue more than 200 subaddresses in a row and none of those receive any funds to them, then you need to force your wallet to scan beyond the subaddress index that it would normally stop looking beyond.

To do this, use the command line Monero wallet (CLI) and type address new as many times as necessary to get the wallet to recognize higher subaddress indices. Then type rescan_bc to rescan the blockchain for those higher numbered subaddresses.

  I also want to know if I can get all 60,000 subaddresses from a just
  recovering key from a mnemonic seed

Yes, you can use the --subaddress-lookahead option when restoring a wallet from seed using the Monero CLI (command line interface) wallet. E.g. use the command ./monero-wallet-cli --restore-deterministic-wallet --subaddress-lookahead 50:70000 to automatically scan the first 70,000 subaddresses for each wallet in each of the first 50 accounts. Note that unlike the GUI, the CLI allows multiple accounts each with multiple subaddresses. If you've only been using the GUI so far, then you'll only have one account.


Altcoins to Monero payment buttons for website? I tried to implement a monero payment button onto my website via shapeshift and changelly, but neither of them support this payment button widget. Apparently changelly supports XMO (monero original) but not xmr for some odd reason. I want users to be able to pay me with any crypto, but I want to only receive monero which services provide this?

You could consider using globee and changing afterwards to monero through ShapeShift (you could automate this i think).

Changely has a bad reputation, maybe related to big ASIC miners, and it must be the reason they're on XMO and not XMR.


Ability to return funds At a protocol level is there anyway to embed a return address to allow a transaction recipient to send funds back?

No, but there's nothing preventing it - either.

We have the TX-extra data field which could be used to embed a return address. For example, you could store an encrypred return address. However, how does the recipient know that those apparently random numbers represent an address? So, there needs to be some convention amongst supporting wallets on the method to write and recognize this.


Where can I find binary (alpha) builds of the Monero GUI? I would like help testing the Monero GUI, but can't compile it under MacOS. Are there anywhere binary builds of the Monero GUI?

At this time, there are not any compiled alpha GUI binaries.

That being said, when such binaries exist, the only safe places to download said binaries from are:

Github - https://github.com/monero-project/monero/releases
getmonero.org - https://getmonero.org/downloads/

One last possibility is the stickied posts on https://reddit.com/r/monero, but use all normal precautions when downloading from untrusted sites.

Personally, I would not trust any links outside of these locations.

As for an ETA on binaries you can download? Soon™, as they say...


Why is the Monero hash rate so low after the v7 fork compared to other Monero forks? After the v7 fork, the Monero hash rate went down, but some opportunistic Monero forks such as Monero Classic had hash rate shoot up. Why is that so ?

When Monero forked to v7, it changed its proof of work algorithm. While it previously used Cryptonight, it now uses a slight variant (technically, variant 1) of Cryptonight, which should be typically slightly slower to compute.

After the fork, miners would were not able to update their hash algorithm were left unable to mine Monero. While patches were made to most known mining software, one major type of miner could not update: ASICs.

ASICs are hardware made to run one particular piece of code fast, and nothing else. ASICs were made to mine Cryptonight, and were able to do it much faster than CPUs and GPUs, leaving normal users out in the cold. When Monero forked, these ASICs were left unable to mine Monero, causing the overall network hash rate to plummet, restoring viability to everyone else.

However, these ASIC miners could still mine other forks such as Monero Classic which are still using the legacy proof of work, leading to high hash rates. However, since they are mining incompatible algorithms, their hash rate can no longer be compared. Indeed, the average time to compute a "variant 1" hash is larger than the average time to compute a legacy hash, since ASICs exist to compute legacy ones very fast.


Mining with monerod vs xmr-stak-cpu The Monero website explains how to set up xmr-stak-cpu to mine Monero, though monerod already has built-in mining ability. Please explain what the differences are between these two miners, and which one is best.

xmr-stak-cpu is a pool miner: it doesn't mine directly, it just hashes on behalf of a central pool, who actually mines. The pool will pay you later from the blocks it finds, based on the work you did for the pool. You can see pool mining as some kind of subcontracting: the pool operator wants to mine monero, but subcontracts the hashing power to others, who run such programs as xmr-stak-cpu, minerd, etc.

In contrast, monerod mines directly for you. You get the block reward when you find a block, rather than the pool operator.

Pool operators run monerod themselves (though typically don't bother mining with it directly, they just use the hashing power supply by their miners).


Fatal Error when trying to build monero-core I'm trying to follow the directions from here...

https://github.com/mbg033/monero-core

I'm running a fresh install of Ubuntu 16.04.1 x86 in VirtualBox.

When I get to "make" it gives me the following fatal error.

In file included from main.cpp:38:0:
src/libwalletqt/WalletManager.h:5:32: fatal error: wallet/wallet2_api.h: No such file or directory
compilation terminated.
Makefile:596: recipe for target 'main.o' failed
make: *** [main.o] Error 1

Can anyone point me in the right direction?

Got some help from radfish on github...

https://github.com/mbg033/monero-core/issues/52

Here's what radfish said...

  You need to manually merge monero-project/monero-core/PR # 14 in order
  to build (alternatively use develop branch in this repo), because
  monero daemon repo was updated to not build/install wallet lib/headers
  by default (need to pass BUILD_GUI_DEPS=ON option to cmake).

Here's what I did...

$ git clone -b develop https://github.com/mbg033/monero-core
$ cd monero-core
$ ./build.sh

And the resulting binary was in ~/monero-core/build/release/bin/monero-core


Using a block template to mine I am a little confused about how I use the block template. I saw this question which leads me to think that perhaps I need to call this function until I get a hash that fits the difficulty. Basically what are the function calls I need to perform in order to mine a block template so I can then call submit block.
Sorry if this is a vague question I am just quite confused.
I have also seen this question but again it doesn't really answer what function I should call.
Just for more context I am calling monero from a bazel repository so things are a bit hairy and complex.

I am a little confused about how I use the block template... Basically what are the function calls I need to perform in order to mine a block template so I can then call submit block.

A block template is just that, a template for a block that a miner can perform work on (repeated hashing) to try and find a solution (a hash that meets the network difficulty) and then submit to the network.
So first a miner obtains a block template, typically using the daemon method get_block_template.
Next the miner relatedly updates the nonce space1 and performs a hash2 (using the RandomX hash function). If / when the resulting hash (which is just a number) meets the network difficulty, they can submit the block to the network using the daemon method submit_block.
Lastly, peer nodes validate that any proposed blocks hash meets the network difficulty. If no other miner submits a valid block (or chain of blocks) with more work done, after 60 blocks the miner gets paid the reward.
1 the nonce space can be any combination of the nonce field in the block header or in any reserved space of the miner transaction.
2 what actually gets hashed is a block hashing blob, which is a concatenation of the block header, a merkle root hash of the blocks transactions and a varint of the count of txs (src). A miner can either directly use the returned block hashing blob from get_block_template or they can construct the block hashing blob themselves using the block template blob. The latter is required if the miner is changing the reserved space of the miner tx.


Can someone help me understand the dynamic block size in Monero? I can't quite figure out the purpose of the dynamic block size in Monero, or I'm just missing something.

Based on the original CryptoNote code, from my understanding, you need to change a specific constant to adjust to your preferred block size, which in Monero, is defined by the constants:

#define CRYPTONOTE_BLOCK_GRANTED_FULL_REWARD_ZONE_V2    60000 //size of block (bytes) after which reward for block calculated using block size
#define CRYPTONOTE_BLOCK_GRANTED_FULL_REWARD_ZONE_V1    800000 //size of block (bytes) after which reward for block calculated using block size
#define CRYPTONOTE_BLOCK_GRANTED_FULL_REWARD_ZONE_V5    300000 //size of block (bytes) after which reward for block calculated using block size - second change, from v5

So I have made a little experiment to determine what size would cause the core code to emit an error when the block size is over this expected value. I created numerous transfers with a mix of some big and some small amounts in the transaction, I then encountered this error:

2019-05-29 10:21:28.662      0x10e85a5c0    ERROR   cn  src/cryptonote_basic/cryptonote_basic_impl.cpp:114  Block cumulative weight is too big: 64156336, expected less than 62562850

So I am puzzled by this. Are the numbers specified by the constants calculated in some way, or are they just getting values with trial and error, proceeding with the max value and some reasonable offset?

Thanks.

The constants you reference specify the maximum block size you can reach before the dynamic fee calculation is used.

Therefore, if the block size is below 300000, the full reward is granted and there is no need for the dynamic fee calculation. If however the block is larger than 300000, the dynamic fee calculation is applied. This doesn't mean a full reward is not granted, rather there may be a penalty applied.

A little outdated, but https://web.getmonero.org/2017/12/11/A-note-on-fees.html details more on how the dynamic fee calculation works.

Lastly, "dynamic block size" and "dynamic fee" are related terms. Monero does not have a maximum block size, therefore, it is a dynamic block size. However, dependent on the size of the block being mined (in relation to average block size over the last N blocks), it can only grow by a certain amount before incurring a penalty fee. This is where the term "dynamic fee" applies.


How are dust and fees related? When sending a transaction now, I get the prompt:
The transaction fee is 0.010000000000, of which 0.006000000000 is dust from change. Is this okay?  (Y/Yes/N/No). What does that mean, is it that the fees would have been only 0.004 (or 0.006) but the client wants to round that up to 0.01?

This is a minor bug due to the dust threshold (0.01 XMR) being higher than the current fee (0.002 XMR per kB). This is fixed in this pull request.

  What does that mean, is it that the fees would have been only 0.004 (or 0.006) but the client wants to round that up to 0.01?

Basically yes.


Why is Monero GUI stuck when it says it's syncing? Save a newbie of Monero and Linux.  I'm running Ubuntu and Monero 'Wolfram Warptangent' (v0.10.3.1-release).  Network status is green and says synchronizing, but blocks remaining moves up 1 every so often.

Daemon Log says the following:

2017-06-15 11:45:04.262     7f249e936740    INFO    global  contrib/epee/src/mlog.cpp:145   New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO
Height: 1317604/1333187 (98.8%) on mainnet, not mining, net hash 72.03 MH/s, v5, up to date, 8(out)+0(in) connections, uptime 0d 0h 48m 54s

Any suggestions?

This issue was resolved by simply adding --block-sync-size 20 as daemon startup flag. You can do this on the Settings page of the GUI. In addition, a full guide to getting your blockchain "unstuck" can be found here.


Do all blocks that end up in the main chain pass through handle_block_to_main_chain at some point? Do all blocks that end up in the main chain pass through handle_block_to_main_chain at some point (even during reorgs?)


What are the potential attack vectors of doing a kind of "quick sync" by just asking for/validating the last X blocks? Would it be possible to request for example the latest 200 blocks from peers, and let the user start using their wallet while the rest of the blockchain is sync'd normally in the background?

What kind of attack's would this be opening the user up to?

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

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

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

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

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

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

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

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

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

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


A thread problem and a query for solo mining Once the blockchain synchronization was complete, I wrote the command

start_mining my local/remote wallet address [threads=number of threads I wish to use]

for starting the mining process. I specified 3 in the number of threads I wanted to use for mining but after executing the command the terminal says

Mining has started with 1 threads, good luck!
Miner thread was started [0]

So although I have mentioned to use 3 of the 4 threads of my processor for mining, it shows the above message for initializing 1 thread only. I do not understand that. 35 blocks have been mined since the time I have started the mining process but still after refreshing my wallet, the balance has not changed even in fraction. My starting balance was 0.000000000000 [12 decimals] and I expected my balance to be at least 0.000000000001 after 35 blocks have been mined on the blockchain because I am also a part of the network now contributing my hash power to it. Is it normal? I used to get better rewards on the Minergate pool than what I am now getting when I'm running a full node. Please explain like I'm five. Don't the miners get rewards in fractions (like in pools)? Do the miners get reward only when they mine a complete block. This is the first cryptocurrency for which I am running a full node. I am mining on CPU as I do not have a graphic card.

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

start_mining [<number_of_threads>]

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

start_mining <address> [<number_of_threads>]

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

start_mining 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A 2

  Is it normal?

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

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


How do I build the Monero source for OpenBSD? How would openbsd users go about building the monero source? There are no builds currently

Build instructions are on the main repository's main README.md page:

https://github.com/monero-project/monero#on-openbsd

As this is bound to change, and that location will always be the most up-to-date of anything, I don't feel it's appropriate to walk through the steps here.


monerod print_coinbase_tx_sum 0 100 Returns Unsuccessful -- What am I doing wrong? ( Ubuntu 16.04 )

monero@monerod:/opt/monero/bin$ sudo ./monerod --version
Creating the logger system
Monero 'Wolfram Warptangent' (v0.10.1.0-dd580d7)
monero@monerod:/opt/monero/bin$ sudo ./monerod print_status
Creating the logger system
monerod is running
monero@monerod:/opt/monero/bin$ sudo ./monerod print_coinbase_tx_sum 0 10
Creating the logger system
Error: Unsuccessful --
monero@monerod:/opt/monero/bin$ sudo ./monerod print_coinbase_tx_sum 0 1000
Creating the logger system
Error: Unsuccessful --
monero@monerod:/opt/monero/bin$ sudo ./monerod print_coinbase_tx_sum 1 1000
Creating the logger system
Error: Unsuccessful --

I recompiled with the "Bleeding Edge" code. Getting more errors now!

monero@monerod:/tmp/monero/build/release/bin$ sudo /opt/monero/bin/monerod print_coinbase_tx_sum 0 10

2017-02-13 11:02:08.327 7f4fabc51740 INFO global contrib/epee/src/mlog.cpp:145 New log categories: :WARNING,net:FATAL,global:INFO,verify:FATAL,stacktrace:INFO

2017-02-13 11:02:08.329 7f4fabc51740 ERROR msgwriter src/common/scoped_message_writer.h:94 Error: Unsuccessful --

Error: Unsuccessful --

Version: Monero 'Wolfram Warptangent' (v0.10.1.0-3f171b9)
OS: Ubuntu 16.04

Per comments, this was fixed some time ago.

print_coinbase_tx_sum 0 100
INFO  [default] Page size: 4096
Sum of coinbase transactions between block heights [0, 100) is 1759.135559809471 consisting of 1759.135559809471 in emissions, and 0.000000000000 in fees


Are there any linux drivers for msi graphics cards? I'm trying to setup my machine to mine. Not real concerned about return, just trying it out and would like to support the network that way.

Have an msi n760 graphics card (is it okay to post a link to it on newegg? don't want to post an unwelcome link) that I'd like to use but I don't believe I have the proper drivers for it to mine with. Unfortunately graphics card mining is not my specialty, so any help or point in the right direction is much appreciated.

You want an nVidia driver for linux that will support the GTX 760, which covers your graphics card. Here is one such driver, though newer drivers likely also work:

http://www.nvidia.com/object/linux-display-amd64-319.32-driver

I would guess that mining with that card might be okay from an income perspective, but the electricity costs will probably also be high.

This post would seem to get you started on how to actually mine on linux:

https://steemit.com/monero/@mobidick/how-to-mine-monero-on-ubuntu-16-04-using-ccminer-cryptonight


How to include libboost into the executable? (Ubuntu) I am able to build everything, but I always have to do:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(pwd)/libs
to have boost available.

Is there a way to include it inside the library?

My compile process is:
mkdir build && cd build && cmake .. && make -j8

(-j8 for 8 core parallel build)

Thanks

You can build a "static" binary (not actually static, but links statically against most dependencies). See the top level Makefile for the targets. The dependencies will have to be built with -fPIC (neede for ASLR), which isn't always the case for static libraries on all distros.


What is the difference between monerod --detach and monerod --non-interactive? It seems like each of these would run monerod in the background.  How does the behavior differ?  Under what circumstances might one choose --detached over --non-interactive or vice versa?

Only --detach will run the daemon in the background. --non-interactive will run in the foreground but the daemon will not require a Terminal for input.
Quoting from monerodocs monerod reference:

--detach

Go to background (decouple from the terminal). This is useful for long-running / server scenarios. Typically, you will also want to manage monerod daemon with systemd or similar. By default monerod runs in a foreground.

--non-interactive

Do not require tty in a foreground mode. Helpful when running in a container. By default monerod runs in a foreground and opens stdin for reading. This breaks containerization because no tty gets assigned and monerod process crashes. You can make it run in a background with --detach but this is inconvenient in a containerized environment because the canonical usage is that the container waits on the main process to exist (forking makes things more complicated).


What is the monero stagenet? Realised there was no SE question for what the 'stagenet' is when setting up a monero wallet via the gui or CLI.

From my understanding the stagenet is a sandbox environment similar to testnet but is a copy of the 'current' mainnet whereas the testnet is a sandbox environment were you can test upcoming features on the monero network - is this correct?

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

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

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

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

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

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


Fastest way to sync and start using Monero GUI wallet? What is the fastest way to sync and start using Monero GUI wallet and how to do it?

If anyone has tried various methods, what is the different time taken for each method to start using Monero GUI wallet.

I followed the instructions provided here to download the raw blockchain and import it. The raw blockchain is somewhere around 4GB, and the import process for me took a couple of hours or so.

You'll need to be somewhat familiar with using the command line and installing packages using Homebrew, because you may need to install additional packages (such as wget) if you haven't already. I was somewhat familiar with using the command line and got stuck a couple of times, but was able to Google my way through it pretty easily whenever an error came up.

Note that these instructions include the process needed to set up a wallet in the command line, so if you've already got a wallet you won't need to do that.

If you need instructions on how to create a wallet in the GUI you can go here.


Monero comparison wiki states zcash is not "decentralized": why? https://www.reddit.com/r/monero/wiki/comparison

The monero comparison wiki states zcash is not decentralized. Why? Also since it's a monero subreddit, it can be seen as biased toward monero. What are some comparisons to make dash or zcash bias over monero?

The monero comparison wiki states zcash is not decentralized. Why?

The link you posted in your question, if you scroll down the page, has a pretty thorough answer to the question.

Most common criticisms of Zcash are the "Trusted Setup" and the "Founders Reward".


Can a Monero account get blocked? Can a Monero account / address get blocked?

Are there any actions that might limit the access to the account?

It is impossible for a miner or any other blockchain observer to know whether any transactions are destined for a particular wallet address (or wallet account). This is because wallet addresses do not appear on the blockchain at all.

Monero instead uses stealth addressing, which encrypts the destination of the transaction such that only the recipient can scan the blockchain to see that any particular transaction is destined for them.

When outputs (which are amounts of Monero) are sent to an address, the sender will know which outputs are sent. So an exchange, for example, will know what outputs were sent by the exchange to the wallet address you told the exchange about.

It could theoretically be possible that miners could decide to censor transactions that attempted to reference those outputs in any ring signature, thus preventing those particular outputs from being spent in the future.

It is most likely, however, that not all miners would agree to censor those outputs. This would lead to a blockchain fork, where one group is recognizing certain transactions as valid and others are considering them invalid due to their decision to censor.

In such a circumstance, the outputs would only be spendable on the fork of the blockchain that did not decide to censor.

Because Monero miners are spread across the world in many different legal jurisdictions, it would be very difficult to force miners to perform any kind of censorship.


Monero wallet balance I have a monero-gui wallet: it shows my XMR balance, which is not zero.  When I open monero-wallet.cli it shows my balance is 0.000. What is going on here?

This look like you have a balance on subaddresses but not on main address.
While the GUI aggregates all accounts addresses in a single balance, the CLI does not.

You could do a show_balance all on the CLI (IIRC) and check if the balance is on one or many subaddresses.


Is this a typo in Mastering Monero.pdf I can't figure out the meaning of this line in chapter 5.3.4:
This subaddress public spend key is multiplied by the primary private spend key to yield the subaddress public view key:

Because the notations are like below:
PVi = pV0 * PSi

The sentence shows private spend key but the notation is pV0.

Is it a typo?

Yes, it is a mistake. It should read:

This subaddress public spend key is multiplied by the primary private view key to yield the subaddress public view key


How to reset xmr-stak configuration? I've installed this recent unified miner called xmr-stak and in the first time I used I mine on xmrpool.net, now I want to mine on xmrpool.eu. If I run the program with no parameters, it doesn't show me option to set the target pool and just choose the previous configured (.net), if I run with parameter -o xmrpool.eu:3333 it shows:

[2017-12-15 21:23:17] : Fast-connecting to xmrpool.net:3333 pool ...
[2017-12-15 21:23:17] : Fast-connecting to xmrpool.eu:3333 pool ...

So my question is, how to reset these config so it doesn't connect to the old pool?

1) Edit the config.txt file by changing the "pool_address" field in the "pool_list" section. You could also have a list of additional pools and adjust the weights as you wish (e.g. mentioning some backup options).

OR

2) Delete the config.txt file. Next time you run the executable it will ask you to set the target pool as it did on the first run (it will also ask for the rest of configs as it did then).


Why didn't Monero developers just improve bitcoin? There are plenty of reasons for creating an altcoin to test a concept, but there are also good reasons to improve the primary protocol. Considering that cryptocurrencies are a strange meld between financial instrument and software, the scale tips more towards improvement than replacement. Bitcoin maximalists have plenty of reasons why altcoins shouldn't exist.

Please be aware that I have had no involvement in creating Monero (or knowledge of the rationale behind it), so the following should be regarded as speculation.

On a general note: there is no reason that there should be only one cryptocoin, on the contrary there are use cases for different coins. Bitcoin might not be particularly useful for e.g. the banking infrastructure, where Ripple might be. Ethereum focuses on smart contracts and other coins might try to address the initial distribution or may only exist to get some infrastructure built. Many different technologies and goals and there will be a lasting need for at least some "altcoins".

Monero offers improved anonymity/fungibility (among other differences) with respect to Bitcoin. There might be good reasons to have a separate coin rather than to try and push this technology to Bitcoin:

It may not even be seen as an improvement to Bitcoin. Who says that Bitcoin's limited anonymity may not prove to be an asset as it could allow for monitoring. Some people like it that way.
Creating Monero allows for a testing ground for new technology. As it matures and the wrinkles get ironed out, the technology will be more suitable for adaption by other coins. Why risk breaking Bitcoin?
Bitcoin does not seem to be very conductive to change. Changing into Monero tech would be a massive change (if at all possible) and it is very unlikely that the community would want it.
Other perceived shortcomings of Bitcoin are fixed along the way as well. Such as dynamic block size, no inflation and the substantial pre-mine.
It allows to build a separate and more healthy community around the new coin. Something that I think has worked out pretty well with Monero.

I am sure that others can expand on my answer. I have really tried to be light on technology, partly because of my limited knowledge, but it might also serve non-savvy readers better.

In conclusion: a different coin or technology is not necessarily hostile towards the Bitcoin project, although it may be perceived as such by a part of the community. It may expand cryptocoins into other domains or even serve to improve the Bitcoin project itself. There is still nothing stopping Bitcoin from adopting improved technologies and ideas.


Running a full node without revealing my home IP address How can I safely run a full node without revealing my home IP address?

Please compare the privacy and security of the following methods for running a Monero node both from home and by using a cloud based VPS:

Tor
I2P
VPN

I can only speak for Tor: using torsocks can make monerod connect to other nodes via the Tor network.

This will run monerod with Tor:

DNS_PUBLIC=tcp torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd

If you cannot connect your wallet (which should not use Tor), you may need to add TORSOCKS_ALLOW_INBOUND. Apparently, different systems may or may not need this option:

DNS_PUBLIC=tcp TORSOCKS_ALLOW_INBOUND=1 torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd

In any case, make sure your firewall blocks the port monerod may listen for RPC connections, assuming the wallet runs locally.


A pool didn't find a block since 4 days, is it normal? I've been mining on a pool for more than 24h and my balance didn't increase. It is supposed to increase when the pool find a block.
I also remarked that the pool didn't find any block since 4 days, is it bad? Is there a way to estimate the required time for the pool to find a block?

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

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

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


Old node that is still on monero v11 - Is this on a fork now? Is this considered Monero Original and Classic? I have an old node that is using monero cli v11. I'm guessing this is on a fork now.

Can I load my old seed which is empty now to claim the monero original coins?
What about monero classic? How do I claim that?
So the asics being sold by bitmain is mining on the v11 client?

Yes v11 is not supported anymore. And installing v11 of monero does put your on the old chain which is called classic / original. It will wither and die over time due to the lack of development on it. The only thing has it for them is the ASICs that are mining on it as there is no other use of the asics. Just stick with v12 software.


Where are wallet files located (Mac OS) I have been away the last few months from my laptop and now upgrading to 0.10.3.1 from 0.10.0.0.
In the post on Reddit it says that I should copy my wallet files into the directory with the 0.10.3.1 binaries.
However I cannot find where any of the 3 files (wallet.keys, wallet and wallet.address) are actually located. They are not in the 0.10.0.0 binary folder and when I search for these names nothing is found.
To be honest I do not recall ever using these files, but I do know that I had a wallet and was able to access it by running monero-wallet-cli and typing in the wallet name and password.
Does anyone have any suggestions on where these files might be found?

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

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


synchronization going backwards Synchronization appears to be going backwards. im 700 blocks behind, but it moves to 701 then 702. It keeps repeating synchronization started as if it stops and starts again. Sometimes it just stops altogether.

That's because your daemon isn't getting new blocks however the blockchain is advancing the reason your "falling behind" is because you are on a specific block say 100 and the blockchain is at 110 your daemon says 10 blocks behind. now a new block is found block 111 your daemon now says 11 blocks behind because it is still on block 100. So synchronisation isn't going backwards it's just stopped.


Contributing to Monerobase Who created the Monerobase wiki? Can anyone contribute to it? What measures are in place to prevent or remedy malicious editing from unknown parties?

Monerobase is run and maintained by community member Aerbax.
Anyone is free to create an account and contribute to the wiki.


GUI wallet cannot send My Monero GUI wallet cannot send! I've tried repeatedly on different computers, tried restoring wallet, it crashes or gives the message "Can't create transaction: Unexpected error: Call method failed." What is wrong?? Using latest GUI wallet (monero-gui-install-win-x64-v0.17.1.9.exe) connected to Trezor Model T on Windows 10. Is all my XMR frozen forever???

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


Error when trying to run monero-wallet-rpc with docker-compose up I provide user and password in config file, but I got the error as it tries to create .login file. When I run for the first time it runs without restriction, but when I run for the second time, it throws error.

  docker-compose up        Starting monerodocker_monero_1 ...  Starting
  monerodocker_monero_1 ... done Attaching to monerodocker_monero_1
  monero_1  | 2018-04-10 11:18:35.660       7fafb52e0740    INFO
    global  src/daemon/main.cpp:279 Monero 'Helium Hydra'
  (v0.11.1.0-release) monero_1  | Forking to background... monero_1  |
  Monero 'Helium Hydra' (v0.11.1.0-release) monero_1  | Logging to
  ./monero-wallet-rpc.log monero_1  | 2018-04-10 11:18:35.674
  7f4811fef740  ERROR   wallet.rpc  src/wallet/wallet_rpc_server.cpp:198    Failed
  to create file monero-wallet-rpc.18557.login. Check permissions or
  remove file monero_1  | 2018-04-10 11:18:35.674
  7f4811fef740  ERROR   wallet.rpc  src/wallet/wallet_rpc_server.cpp:1894   Failed
  to initialize wallet rpc server monerodocker_monero_1 exited with code
  1

I had the exact same error message when running monero-wallet-rpc without the option --disable-rpc-login.

Then, as explained by vtnerd in this open issue:

  The file is always created in the current working directory when
  authentication is enabled.

To create the file, you need to be the owner of the working directory.

I set the current user within the docker container as the owner of the working directory, so Check permissions disappeared and monero-wallet-rpc started correctly.

By the way:

When leaving --disable-rpc-login you should provide --rpc-login user:password.


Rescan Ledger wallet from 0 in the GUI? I created a fresh Ledger wallet using the 0.14.1.0 GUI on Windows 10. That's working fine as expected.

I tried to force the GUI to rescan the Ledger account from block 0 by renaming the wallet cache file. But when I do that, the GUI opens the .keys file and only scans the blockchain from roughly 20,000 blocks in the past. Is there some info in the keys file that is indicating the creation date of the wallet?

On a side note, attempting to force a rescan using the GUI results in this error:

rescan spent can only be used with a trusted daemon

I have seen that this function of the GUI may not be wired-up yet. However, my remote node is run by me and the tickbox for trusting it is marked. I have tried un-ticking and re-ticking, but it did not help.

With the wallet open, changing the wallet restore height in the GUI's Settings section under the Info tab will cause the chain to be re-scanned from the block height specified.


What is the difference between an orphaned block and a alternative block? I see alternative blocks reorganizing the blockchain in monerod, but my mining pool's orphaned block doesnt show.

Orphaned block means that your pool was able to  mine a block but somehow someone was able to mine that same block. In the end your block was not chosen thus it became orphaned.

Other nodes that may have added your pool's mined block will have to discard it.

An alternative block could happen if the network is divided and is extending on two different blockchain. This happens because it was not detected that two same block was mined by two separate pool and the network was extending on different blockchain. When the network notices this it will have to reorg and have to select the longest block chain.

Here is a nice answer
Block added as alternative on height xxxxx


Can an ISP swap out Monero's default peers? Would this be detectable? As I understand, P2P networks work by first connecting to a fixed set of peers and learning about other peers based on them. Since those peers are hardcoded into the Monero software, could a malicious ISP intercept initial communications by redirecting traffic to those peers? Would this be detectable?

Since those peers are hardcoded into the Monero software, could a malicious ISP intercept initial communications by redirecting traffic to those peers?

Sure, to another valid Monero node.  Traffic NAT'ing happens all the time.

  Would this be detectable?

I don't see anything in the codebase that reaches out to STUN, etc. to determine its outside IP (and then include it encrypted), so it looks possible to spoof a peer by IP.  That said, the codebase has the genesis transaction hard-coded in it, and every block in a blockchain depends on the previous block, so if an ISP or the spooks want to run an extra Monero node, then - great!

Never trust any Monero node on the Internet.  Assume BadGuys are doing all the traffic analysis they can.  The protocol exists so you don't have to trust anybody.  Improvements with noisy Tor (and I2P) make it less likely that you have to trust your ISP to not be your adversary.


Do ring signatures sometimes leak "X definitely did not pay Y" info? I'm trying to understand how privacy in Monero compares to shielded transactions in Zcash. I understand that with Zcash's zk-Snarks, there's no information about sender, receiver or amount.
I think I understand that with Monero, these data are visible, but obfuscated with "ring signatures" that basically add a bunch of noise so an observer can't detect the signal from the noise. The dancing analogy is that you'll see "me" dancing with many people, but most of what you see isn't really me, so you can't prove that I danced with any one of them. Is that about right?
If so, my question is this: can an observer prove that I didn't pay (or dance with) some recipient X?
I get that the noise might include me dancing with X in which case they cannot disprove it. But what if amidst all the signal and noise, none of it suggested that I might have paid X. Does that not then prove that I did not pay X?
If that is correct, then that certainly seems like information disclosure that makes zk-Snarks superior in privacy.

The dancing analogy is that you'll see "me" dancing with many people, but most of what you see isn't really me, so you can't prove that I danced with any one of them.

The "dancing" analogy is poor.
Monero has:

Sender privacy: Ring signatures
Receiver privacy: Stealth addresses
Amount privacy: Confidential Transactions

Observers don't know who the sender is (or more specifically which outputs are being spent), due to the ring signatures.
Observers don't know who the receiver is (or more specifically who owns the destination outputs), because they are uniquely created for the destination, with no way of attributing them to specific addresses.
Observers don't know how much was transacted because the amount is encrypted with a shared secret (only the sender or receiver can decrypt).

can an observer prove that I didn't pay (or dance with) some recipient X?

No they cannot. Only you (as the sender), can prove whether or not you actually sent funds.

Does that not then prove that I did not pay X?

No, it does not. Only you (as the sender), can prove whether or not you actually sent funds.


Scratchpad Initialisation : What is the input to Keccak? So this is probably a question I should be able to find the answer to easily but I am stumped.  In the documentation for cryptonight the part on scratchpad initialization says:

  First, the input is hashed using Keccak [KECCAK] with parameters b =
  1600 and c = 512. The bytes 0..31 of the Keccak final state are
  interpreted as an AES-256 key [AES] and expanded to 10 round keys. A
  scratchpad of 2097152 bytes (2 MiB) is allocated. The bytes 64..191
  are extracted from the Keccak final state and split into 8 blocks of
  16 bytes each ...

What is the input parameter?  Where does it come from?

As far as I'm aware, Monero didn't deviate from what was inherited from CryptoNote when it comes to PoW and difficulty.

Input should be the block header, although I'm not sure about all details. It should be according to chapter 4.1 of CNS003.

The winning hash is never recorded to the blockchain. Instead, nodes just hash the header themselves and verify that the resultant hash is above target difficulty for the block height.

The difficulty is evaluated according to CNS010.

Here's some more info:

Cryptonote SHA3 bigger than 64byte? (Scratchpad Initialization)

Keccak vs Keccak-f permutation in cns008

Understanding the structure of a Monero transaction

If you poke arond and get more clear info, please update here (you can answer your own question, as well).


Is it better to mine Monero on solo mining or joining a mining pool? Considering fees and profits, but also the best thing for the Monero network, which is the most valuable solution?

Also, is it depending on hardware and hashrate power?

Thanks in advance.

It's for sure the best thing to join a pool - unless you have a really high hash-power. If you own a data center you can go on and solo mine but in nearly any other case, it's more profitable to use a mining pool.

Apart from profitability, for the Monero network it doesn't make a big difference if you solo-mine or not.

In general, you of course need "good" hardware to get a high hash-rate. A really fast CPU or GPU is what you need. Everything else isn't significantly important. GPU mining is more profitable than CPU mining.


Getting "Unauthorized Access" with RPC (using Python Requests) I can successfully do a getbalance RPC with digest authentication, e.g.:

url = "http://localhost:18082/json_rpc"
headers = {'content-type': 'application/json'}
rpc_input = {
       "method": "getbalance"
}
rpc_input.update({"jsonrpc": "2.0", "id": "0"})
response = requests.post(
    url,
    data=json.dumps(rpc_input),
    headers=headers,
    auth=HTTPDigestAuth('wallet_username', 'wallet_password'))
print(response.text)

However, when I want to do a create_wallet RPC I get an Unauthorized Access HTML response:

<title>Unauthorized Access</title>
401 Unauthorized

E.g.:

url = "http://localhost:18082/json_rpc"
headers = {'content-type': 'application/json'}
rpc_input = {
        "method": "create_wallet",
        "params": {"filename": "mytestwallet", "password": "mytestpassword", "language": "English"}
}
rpc_input.update({"jsonrpc": "2.0", "id": "0"})
response = requests.post(
    url,
    data=json.dumps(rpc_input),
    headers=headers,
    )
print(response.text)

I do notice that the create_wallet RPC does not take a wallet username parameter, could this be my problem, or am I missing something else? (Note that at https://getmonero.org/resources/developer-guides/wallet-rpc.html#create_wallet the example does include a filename parameter but no username parameter).

When digest authentication is activated in the monero-wallet-rpc program (with the rpc-login option), every RPC request must contain the authentication information.

So your request should be something like:

url = "http://localhost:18082/json_rpc"
headers = {'content-type': 'application/json'}
rpc_input = {
        "method": "create_wallet",
        "params": {"filename": "wallet_file", "password": "wallet_password", "language": "English"}
}
rpc_input.update({"jsonrpc": "2.0", "id": "0"})
response = requests.post(
    url,
    data=json.dumps(rpc_input),
    headers=headers,
    auth=HTTPDigestAuth('rpc_username', 'rpc_password'))
print(response.text)

There is no relation between the name and password required to connect to the RPC server of the monero-wallet-rpc program and the name and password of the wallet file.

They should be different, so that if someone gets to know the credentials of the RPC server (e.g. by reading your configuration file for monero-wallet-rpc or by listing the processes running on your machine and seeing what parameters were passed to the --rpc-login option), your wallet file is not compromised.


Monerod finished syncing but now never catches up in GUI wallet, monerod still syncing I'm using Windows 7, 64 bit, on a crummy burner laptop.
So monerod finally finished syncing last week and I followed advice here and opened the GUI wallet, it was all syncing together as it should but literally only for about an hour - after that monerod never stopped adding blocks, coming up with the 'new top block candidate' message.
I had to leave it overnight and when I came back it was way out again, only by 7 days but that's eons on my old machine and slow connection. It's been the same for a week now, it never catches up to the top block and the wallet constantly says syncing to the daemon.
What am I doing wrong? I just want to use my wallet but this is about 4 weeks building it now. Everything has gone right, just that it's taken forever to do so.
Because it was synced at one point is it ok/safe to use now? Or do I have to keep waiting for it to fully sync with that never-attainable top block?
Thanks for the help, really appreciated, and my apologies if this has been answered but I can't find the answer to this on here, maybe I'm being blind or stupid or both. I am useless at this stuff, I've followed the guides here and reddit to get this far with a lot of trial and error, never fully understanding what I'm actually doing. Yep, it's bad...
Thank you!!!!!!

Step 1:
cd ~/Downloads/monero-gui-0.10.3.1-beta2

Step 2:
wget -c --progress=bar https://downloads.getmonero.org/blockchain.raw

Step 3: I
./monero-blockchain-import --guard-against-pwnage 0 --input-file ./blockchain.raw

Step 4:
rm -rf ./blockchain.raw

Step 5:
./monerod --detach


Are Cryptonight lite and Cryptonight lite v1 the same? Are Cryptonight lite and Cryptonight lite v1 the same?

No, they are not.

Cryptonight lite is a derivative of Cryptonight with two changes: a smaller memory usage (1 MB vs 2 MB) and half the loop iterations.

Cryptonight lite variant 1 is a modification of Cryptonight lite which adds a few operations to the main loop and the setup phase. The intent is to break existing ASICs to fight mining centralization. It is expected that Aeon will soon switch from Cryptonight lite to Cryptonight lite variant 1.


What do these two lines in electrum-words.cpp do? Analyzing the seed logic here;

Can someone please explain this expression:

w[0]= w[1] + word_list_length * (((word_list_length - w[1]) + w[2]) % word_list_length) +
word_list_length * word_list_length * (((word_list_length - w[2]) + w[3]) % word_list_length);

Source: https://github.com/monero-project/monero/blob/b60078d1b3b85caca1936f9f22894ced6ee2e88d/src/mnemonics/electrum-words.cpp#L328

Once I understand, I would like to PR a comment for it. Are such PR's welcome?

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

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


Stealth address, is there a static part at the end? If I understand things correctly from the whitepaper in order for Alice to send me monero she will use my two public keys A (public view key) and B (public spend key) which she gets from my address (A,B).

In order to generate the stealth address she then performs:

P = Hs(rA)G + B

using P as the generated stealth address.

The question: Is the part B a static part of every stealth address which can be created from my address (A,B)? So:

Address: Random looking data + B
Address: Random looking data + B
...

If this is true, couldn't Eve then scan the blockchain for every address which ends in B and be pretty sure that this stealth address is derived from my public known address (A,B) (which Eve also knows)?

I'm sure I'm missing sth. here, but I can't figure out what.

It's not like last X bits equal to B. If you do elliptic curve addition or subtraction all the bits change. Any random number could be a sum of any two numbers. Same like 5 = 1 + 4 = 2 + 3 = ... but we're talking about really rally big numbers.

Eve can do P - B, and then what? Random looking data - B = some other random looking data.

Compare it against what to see if it's a match? Normally the scanning wallet does this but it can also compute the target because it knows the shared secret rA=aR because it knows the viewkey a. Without the viewkey you have nothing to compare against to see if it's a match.


What is the difference between i2pd and Kovri? I was looking through the contributors of Kovri, and saw that an account named Orignal had contributed a lot in the early days.

Looking at his current projects, it appears that he is now working on something called i2pd, which bares striking similarities to Kovri.

After a little bit of research, it appeared that Kovri and i2pd are two projects sprouted from the same initial project. But as it quickly became apparent to me, that there was a lot more to it, I felt it would be better if one of you could shed some light on it.

My questions would be;

What is the main differences between i2pd and Kovri?

And with the more subjective glasses on, why is the one more beneficial than the other for the Monero project?

Kovri is an alternative implementation in C++ of the I2P protocol which original daemon i2p is written in Java, is bloated and quite difficult to use. Kovri is a fork of the C++ implementation i2pd.

You'll find a quite good answer in Kovri's FAQ

Why should I use Kovri instead of i2pd?

Security: our focus is on securing our software; not rushing to get things done for the sake of having a release
Quality: you're supporting efforts to ensure a quality codebase that will stand the test of time. This includes all aspects of code maintainability
Monero: you will be supporting a crypto-currency that prides itself on privacy-preservation and anonymity while increasing both your privacy and anonymity

What are the biggest differences between Kovri and i2pd?

We provide a Forum Funding System for features/development.
We focus on creating a "secure by default", easily maintainable, more-likely-to-be-reviewed I2P router. This will come with the cost of dropping lesser-used features found in the other routers, but core functionality and an API will be fully intact. By creating a smaller, efficient, "bare-bones" router, we will provide developers and researchers more time for security auditing and more time to question the I2P design and specifications.
We focus on implementing an intuitive, developer-friendly API for any application to connect to and use the I2P network; this includes Monero.
We provide both end-users and developers a quality assurance and development model in order to provide better software for everyone.
We will implement alternative reseeding options so users can use Pluggable Transports instead of HTTPS for reseed.
We will implement extended functionality (hidden mode + disabled inbound) to provide anonymity for those who live in countries with extreme conditions or those firewalled by carrier-grade NAT or DS-Lite.
We will always create a welcome environment for collaboration.
We will always listen to your feedback and do our best to improve Kovri!

Why did you fork from i2pd?

We forked for at least several reasons:

We wanted a robust, secure, and viable C++ implementation of the I2P network; and i2pd was not delivering
We wanted a positive community that encouraged collaboration for the betterment of the software; not negative, narcissist glory
We wanted a lead developer who could lead; not someone who could ignore requests for responsible disclosure or tuck-tail-and-run when faced with collaborator conflict

What were the turning points that lead to forking from i2pd (and why are there two i2pd repositories: one on Bitbucket and one on GitHub)?

So began the drama of i2pd.

In early/mid 2015, one of the developers with push privileges on GitHub pushed a commit(s) that i2pd's first author did not like. Instead of working together to resolve the issue, said author took i2pd to Bitbucket, deleted all existing git history, and made himself sole 'contributor' of the software. He then vowed to never return to Irc2P.

These actions offended many in the I2P community, including the developers, and nearly ended the C++ project.

In the fall of 2015, along came anonimal who, not wanting to see everyone's work to go to waste, revived the project through contributions of their own and by reigning-in development. An open invitation for all remaining active developers to meet and discuss i2pd's future was then given. i2pd's first author never showed but the act of meeting apparently rustled i2pd's feathers to the point where he retaliated and began to work on GitHub again - but this time within an openssl branch (which turned out to be the Bitbucket repository) instead of the community-driven master branch.

Seeing that this sort of erratic behavior would only hurt the I2P network and the project as a whole, the remaining developers continued to have several important meetings and set the foundation for what is now Kovri.


Should Monero start using MIPs(Monero Implementation Protocol) similar to Bitcoin(BIPs)? It might be a little early and Monero is still young, but should we in the future start making our own MIPs?

Once a project starts to gain significant traction, like having its own research lab papers, it's ready to have a formal improvement process.

The BIP ("Bitcoin Improvement Process") was introduced by Amir Taaki back in the early days of Bitcoin and was inspired by the PIP ("Python Improvement Process"). Consequently having the MIP ("Monero Improvement Process") is a great step towards a structured approach to improving the protocol that each Monero client would implement.

Clearly the MRL (Monero Research Labs) papers are just one (very strong) initiator for a MIP. An MRL paper would provide deep technical analysis and requirements that the MIP would then implement. However other initiators could come about through community feedback.

In each case I'd see the MIP as being the second (more developer accessible) layer so that the community can provide further discussion and acceptance.


How GPU gets its mining work and nonce range? I tried to study source of both xmr-stak and xmrig to understand how it communicates with the kernel running on GPU, but both these softwares are too huge to understand (too many objects calling each other and various data passing between them).

I can have several GPU devices and each runs several threads which performs several calculations at the same time, right?

I know the software "communicates" with GPU by writing/reading some shared memory segments. So it writes the input hash (job blob from pool) to each GPU. I assume it somehow divides the whole 32-bit nonce between all the devices and threads, but how?

I have found this in minethd.h of older xmr-stak-amd:

// We use the top 8 bits of the nonce for thread and resume
// This allows us to resume up to 64 threads 4 times before
// we get nonce collisions
// Bottom 24 bits allow for an hour of work at 4000 H/s
inline uint32_t calc_start_nonce(uint32_t resume)
{ return (resume * iThreadCount + iThreadNo) << 24; }

I didn't find anywhere what is resume (or ResumeCnt)? Does the miner delegate ranges of nonce in batches? Or it gives them only once when new job from pool is received? (And hopes as per the comment above that it will receive another job earlier than 1 hour to avoid nonce collisions?) If in batches, how does the GPU tell the miner it needs a new range to work on?

Then for the results, the miner thread just periodically checks the shared mem if GPU has put some winning nonces there?

Also does the GPU perform all the calculations or some parts are done by CPU? I assume to be able to check if the result is above target, the GPU needs to finish the whole calculation.

I would study the most up-to-date code for xmr-stak: https://github.com/fireice-uk/xmr-stak

With that codebase, every thread, whether that be a CPU or GPU thread, mines with it's own blob/nonce. The first thread to calculate a valid hash (one who's hash value is below the target) causes the result to be submitted to the pool.


How to generate a Monero wallet programatically? I want to generate both the monerowallet and monerowallet.keys files, but I can't find any resources on how to do it. The cli tools offer a --generate-new-wallet, but it requires manual overhead and user input. Is there any good way to do this?

Update:

Using monero-python I can generate all the keys, but even using the monero-wallet-cli's --generate-from-json it still prompts for user input so I can't do it that way either.

You have a couple of options.

One option is to have a running wallet RPC: monero-wallet-rpc --wallet-dir . --rpc-bind-port 18085 --disable-rpc-login

Which you can then call its create_wallet method like:

curl -X POST http://localhost:18085/json_rpc -d \
  '{"jsonrpc":"2.0","id":"0","method":"create_wallet","params":\
  {"filename":"monerowallet","password":"pass","language":"English"}}' \
  -H 'Content-Type: application/json'

Another option would be to use monero-wallet-cli --generate-from-json wallet.json when you have a wallet.json with content like:

{
  "version": 1,
  "filename": "monerowallet",
  "scan_from_height": 1796000,
  "password": "pass",
  "seed": "some valid seed ..."
}

But of course that requires you to have already created a seed.

Lastly, another approach I've seen used is to create a wrapper script around monero-wallet-cli --generate-new-wallet which uses redirection to echo input to the monero-wallet-cli processes stdin. There are many ways to accomplish this and is very much shell specific.

The RPC method is probably your best option (without knowing your use-case).


Best practices to keep Monero wallet secure I'm using a read-only wallet on a computer connected to the Internet, a dedicated local server for the Monero node and I keep on a USB key the full wallet as cold storage to use it only in case. Also, I have printed the seed and I'm keeping it in a safe place.

What are the best practices to keep keys and seed secure?

Maybe, use GPG or a dedicated software to encrypt the keys and the seed, making multiple backup copies of the USB key, make an encrypted backup and save it in cloud services, other?

Is there a vademecum or some references for this? Where can I found it?

Thanks in advance for answers.

Here's my paranoid guide for keeping your wallet safe & secure:

  I have printed the seed

That might already have screwed you up depending on how your printer was connected to your PC. Writing down the seed is the preferred way imo; make sure to use a solid desk pad to avoid imprinting / engraving what you write to other materials below your paper wallet :) In addition to that you can create a steel "wallet" containing your seed, see https://cryptosteel.com/

  I'm using a read-only wallet on a computer connected to the Internet

That means this computer holds your private view key making it possible for hackers to see the amounts you're sending and receiving. Not too unlikely given that the computer is connected to the Internet. May I ask what the reason for this Internet-connected computer is? Why does it need to have view access to your wallet?

  I keep on a USB key the full wallet as cold storage

It might be worth creating an encrypted container on the USB stick, e.g. with TrueCrypt 7.1a or VeraCrypt. In addition to that, you can encrypt the wallet with GPG to have another fence in case TrueCrypt or VeraCrypt was backdoored. Make sure to only use these tools from a computer which will never be connected to networks, e.g. the Internet. Also you should have multiple backups of that USB stick at different places, preferably in different countries in a fire and water proof safe.

  a dedicated local server for the Monero node

Just to be sure this node (even if it's downloading the blockchain only) should do so through Tor via torsocks.

When creating your wallet, make sure to use a computer which will never be connected to any networks. Remove its harddrive and WiFi antenna. Make sure to use a good random number generator, how to ensure that? I don't know. Use an open source OS, e.g. Debian or Tails. Only download software from trustworthy sources and verify its integrity.

I recommend to split your balance across multiple wallets; even if you somehow lose access to one (maybe due to hackers, robbers, etc.) you have still access to your other funds.


Terminology clarification: stealth address I've seen the term stealth address being used for both:

Monero standard address
One-time public key

I'm guilty of using the term for 2. initially, but later I realized that it may actually refer to 1. and went on to correct some of my posts here.

Moneropedia definition hints to 1. (emphasis mine):

  Stealth addresses are an important part of Monero's inherent privacy.
  They allow and require the sender to create random one-time addresses
  for every transaction on behalf of the recipient. The recipient can
  publish just one address, yet have all of his/her incoming payments go
  to unique addresses on the blockchain, where they cannot be linked
  back to either the recipient's published address or any other
  transactions' addresses. By using stealth addresses, only the sender
  and receiver can determine where a payment was sent.

So, which is it? I figure any Monero address is a stealth address. It could also refer to the stealth address scheme, describing the overall process, or it could refer to the individual one-time public key.

If we look how the term "stealth address" is used outside of Monero, for example in bitcoin ecosystem:

  The concept was invented Peter Todd based on earlier work by ByteCoin,
  and with feedback from other developers.
  It’s a powerful tool for allowing one to accept Bitcoins using a
  public Bitcoin address while preventing passive observers from knowing
  your transaction history.

or:

  Stealth address means that for an external observer of the blockchain
  is not possible to identify what payments were made to you, because
  your address is not recorded in blockchain.

So in my opinion, correct is stealth address = "Monero standard address" ie your point 1. I would also say it is OK to use the term to describing the overall process.

Sources:

https://www.codeproject.com/articles/775226/nbitcoin-cryptography-part
(This is actually very good explanation of the principles how stealth address works. It uses different terminology than is used in Monero e.g. "ephemeral key" but principles are same)
http://sx.dyne.org/stealth.html
https://bitcoin.stackexchange.com/questions/20701/what-is-a-stealth-address


Could IPFS (InterPlanetary File System) be used with Monero? Are there plans? The IPFS website states that it is a perfect match with the blockchain. Is this true with Monero's blockchain? Or, IPFS has no point at all / useless?

https://ipfs.io/

I'm going to attempt to answer the two parts of this question, but with the caveat that the second half of my answer is certainly at least in part opinion based.

Could IPFS be used with Monero's blockchain?

Yes. In theory, any blockchain could be used to store non-transaction-related information, and tokens could even be involved in such a storage scheme so as to incentivize such actions in some manner. In Monero's particular case, the TX-Extra field could probably be adapted to include extra data (right now it barely allows more than a few words of information, so we're talking a massive expansion of that field or the introduction of some new field.
Or, is there even a point to this?

With the caveat that this is highly opinion based, this would be a terrible use of the Monero blockchain. On the Monero Design Goals roadmap, there are a number of examples of potential future sidechains and daughterchains that could expand Monero's reach beyond monetary exchange, including a decentralized DNS service that is loosely related to this question.

However, to actually store what amounts to a permanent, distributed backup of all web content is both a ridiculous notion, given the shear quantity of information on the web, and not at all desirable. Why do we need a permanent archive of all blog posts, reddit discussions, cat memes, and other things that come and go? The IPFS site specifically states:

  Remember GeoCities? The web doesn't anymore. It's not good enough for the primary medium of our era to be so fragile.

Quite frankly, the reason GeoCities is lost in the depths of internet past is because it no longer served a purpose. With IPFS, it would be part of a permanent record, a website graveyard of sorts, that would be with us forever. Why do I want this, exactly?


Comparison of Curve25519 with secp256k1? How does the security of Curve25519 compare with secp256k1? Is it known why the creators of CryptoNote may have chosen one curve over the other?

https://safecurves.cr.yp.to/ (joint work between Daniel J. Bernstein, University of Illinois at Chicago, USA, and Tanja Lange, Technische Universiteit Eindhoven, Netherlands) has rated Curve25519 as "safe"

The specific reasons why CryptoNote creators chose Curve25519 are unclear but it appears to be trusted by top cryptographers.

Monero developers trust DJB, Curve25519 and the fast Schnorr algo (EdDSA).

Riccardo Spagni has stated:

  We will absolutely switch curves if sufficient evidence shows that the curves / algos we use are questionable.


How to change password on a wallet created with simplewallet? I have created a wallet using simplewallet, but I am not satisfied with the password.
How do I go about changing the password on the wallet?

(I am running monero.linux.x64.v0-9-4-0)

As far I know, this is not possible. You have to restore you account with
simplewallet --restore-deterministic-wallet and give a new password.


Running a Monero Node on Linux (Ubuntu 16.04) with no incoming connections Is there any point in having monerod daemon running all the time without any open ports for incoming?

Does it still help the Monero network by providing a node or is it pointless?

I am unable to open the ports as I am using a wireless connection to a router in the building that I don't have access to. It's running fine for me but I get this message every 15 minutes:

WARN    global  src/p2p/net_node.inl:1338   No incoming connections - check firewalls/routers allow port 18080

If you run a node and do not open inbound connections, then you cannot relay other users transactions or relay blocks. So having a full node in this scenario wont be helping the network. However, it is still useful for yourself, as it increases your security when creating and relaying your own transactions.

It's also worth noting that even if you do not specifically open-up/forward inbound connections, any p2p nodes your node initiates a connection to, can still sync blocks and receive transactions from you.


How to fix "Exception in main! locale::facet::_S_create_c_locale name not valid" when starting monerod? If you have upgraded to 17.1.0 of the monero wallet software and run into the error
Exception in main! locale::facet::_S_create_c_locale name not valid

... when starting monerod

Simply add
LANG=C LC_ALL=C

infront of the ./monerod command...
The entire command could look something like this:
LANG=C LC_ALL=C /home/$USER/monero-x86_64-linux-gnu-v0.17.1.0/monerod


Replacing an older version monero-wallet-gui.app with a newer version I have the Macintosh monero-wallet-gui.app I downloaded long ago, but there's no version information, say's "Created by Qt/QMake" in the file's version field. The files 'modified:' field is 'October 25, 2017'

The new version I just downloaded has "- -" in the version field, 'modified' field is October 15, 2018. How does one tell what the version number is?

When I start the app, will it figure out where the blockchain is without me having to do anything?

(Sorry if this is a dup, the 'similar questions' link addressed Windows, didn't find it specifically for Mac)

Thanks!

The version, if I recall correctly, is in the Settings tab and shows both GUI and daemon versions.

And yes, if you didn't change the default blockchain location, upgrades will still find the previously downloaded blockchain.


transaction verification failed on monero-blockchain-import I am new to monero. I'm running version:

Monero 'Boron Butterfly' (v0.14.0.2-release) on Arch Linux

I started with the following steps:

wget -c --progress=bar https://downloads.getmonero.org/blockchain.raw
/usr/bin/monero-blockchain-import --data-dir /path/to/monero --input-file blockchain.raw

After running for many hours, it failed with this message. I'm showing just the last few lines of output:

block 1633270 / 18472752019-06-02 11:15:18.531      7fcc4d902bc0        INFO    global  src/blockchain_db/lmdb/db_lmdb.cpp:615  [batch] DB resize needed
2019-06-02 11:15:58.407     7fcc4d902bc0        INFO    global  src/blockchain_db/lmdb/db_lmdb.cpp:535  LMDB Mapsize increased.  Old: 63571MiB, New: 67151MiB

block 1663990 / 18472752019-06-02 11:22:44.953      7fcc4d902bc0        INFO    global  src/blockchain_db/lmdb/db_lmdb.cpp:615  [batch] DB resize needed
2019-06-02 11:22:48.405     7fcc4d902bc0        INFO    global  src/blockchain_db/lmdb/db_lmdb.cpp:535  LMDB Mapsize increased.  Old: 67151MiB, New: 71675MiB
block 1797110 / 18472752019-06-02 13:17:42.733      7fcc4d902bc0        ERROR   bulletproofs    src/ringct/bulletproofs.cc:1221 Verification failure at step 1
2019-06-02 13:17:42.733     7fcc4d902bc0        ERROR   bcutil  src/blockchain_utilities/blockchain_import.cpp:207      transaction verification failed, tx_id = e32ac43f3371cf76d7a0e9fdd62c1ccd315e5ccd648e356fda69c52d945e6822
2019-06-02 13:17:45.343     7fcc4d902bc0        ERROR   bcutil  src/blockchain_utilities/blockchain_import.cpp:207      transaction verification failed, tx_id = e32ac43f3371cf76d7a0e9fdd62c1ccd315e5ccd648e356fda69c52d945e6822

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


Unable to connect to monero-wallet-rpc from code I have run the monero-wallet-rpc using the below command:

./monero-wallet-rpc --rpc-bind-port 8080--rpc-bind-ip 127.0.0.1 --prompt-for-password --wallet-file sample-wallet --rpc-login walletuser:user1234 --confirm-external-bind

When I do the below curl command, it's working fine.

curl -X POST http://127.0.0.1:8080/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_address","params":{"account_index":0,"address_index":[0,1,4]}}' -H 'Content-Type: application/json' -u walletuser:user1234 --digest

But when I try to call the RPC from the below javascript code, I am getting 401 Unauthorized error.

var digestRequest  = require('request-digest')('walletuser', 'user1234');
digestRequest.requestAsync({
  host: 'http://127.0.0.1',
  path: '/json_rpc',
  port: 8080,
  method: 'POST',
  json: true,
  body: {"jsonrpc":"2.0","id":"0","method":"get_address","params":{"account_index":0,"address_index":[0,1,4]}},
  headers: { "Content-Type": "application/json" }
})
.then(function (response) {
  console.log(response);
})
.catch(function (error) {
  console.log(error);
});

Can any one please help me to resolve this issue. Thanks in advance.

You are trying to use digest authentication in your javascript but the wallet RPC uses basic authorization.


View key, spend key, paper key, seed... Is there a short presentation of vocabulary around Monero wallet? There is a lot of domain specific terms in Monero ecosystem (which is completly normal), and one must clearly understand them to do even basic wallet related operation in a safe way, or prevent problems in the case of a hungry dog being around.

Is there somewhere a one-page presentation of a Monero wallet anatomy with definition for all the important parts (assume I don't have previous exposition to cryto-currencies, nor to crytography, and barely of a computer internals) ?

With a couple of hours around this stackexchange, I encountered at least these ones (but certainly the list isn't exhaustive):

(mnemonic) seed
private keys
view key
spend key
address, stealth-address
view-only-, hot-,light-wallet
cold storage
payment ID
integrated address

An answer to that question could become the said one-page summary if nothing alike already exists.

Wallet Seed / Mnemonic

Minimum piece of information used to restore the cryptographic keys that make up the wallet. Basically, just a very very big number impossible to guess. I'd like to separate the mnemonic and seed terms:

seed: a 256bit integer (usually represented as a 64 digit base16 number)
mnemonic: in this context, a word representation of the seed, with one extra word used as a checksum.
Both represent the same thing, but the mnemonic is a human readable form of it.

Convention currently in use consists of encoding the seed using a 1626 words dictionary which results in a 24-word mnemonic. A CRC32 checksum is performed on them to give the 25th word which is used for error checking.

The seed itself, if smaller than a certain number, is used directly as the private spend key. Otherwise a seed mod l operation is performed to obtain the private key from the seed, where l is a very big number, specific to the elliptic curve used in Monero cryptography.

The private view key is derived deterministically from the private spend key (it doesn't have to be) and that is why we call such wallets deterministic.

Private Key / Public Key / Keypair

General terms specific to public-key cryptography where a private key and a public key make up a keypair. A public key is derived from the private key.

The public key is safe to share, and gives the recipient the ability to encrypt something or verify a signature.
The private key gives the owner the ability to sign or decrypts something, so should be kept private. It's important that private keys are generated in a good way as they shouldn't be easy to guess.

View Key

A keypair specific to Monero. The public part of it makes up the 2nd half of monero address, and is used by the sender to generate a one-time stealth address to where the funds are actually sent. The owner of the wallet uses the private view key to scan the blockchain and find the funds sent to his address. At the protocol level, the sender performs an encryption with the recipient's public view key, and the recipient attempts to decrypt all the outputs on the blockchain to find the one belonging to him (where decryption was successful). For audit purposes, it could be shared with the auditor, along with the signed key images to prove the balance of a wallet. Sharing only the view key would enable the auditor only to see received transactions, but he wouldn't be able to tell if any funds were spent, so he couldn't know the actual balance.

Spend Key

A keypair specific to Monero. The public part of it makes up the 1st half of monero address, and is used to make new transactions and participate in ring signatures. The private spend key is used to sign a key image when the owner wants to spend funds, and the public spend key is used by the network to verify the signature of the key image and accept the transaction as valid. This is what prevents double-spend as the network enforces the rule that a key image can be spent only once. I'd like to expand this a bit, but I'm a bit lacking here, so can't right now.

Address / stealth address

A minimum piece of information compacted to a single 95-character base58 string which the recipient needs to give to the sender in order to receive monero. The information encoded in the address is the network byte, public spend key, public view key and a checksum. The bare minimum which the sender needs are the 2 public keys, but the network byte and the checksum are added to prevent errors.

Any Monero address is a stealth address. They're called stealth addresses because no monero are actually sent to the address itself, ie it never appears on the blockchain. Instead, it's used by the sender to create a one-time destination from which only the intended recipient can spend.

One-time public key

An one-time use destination for the actual monero transferred. Monero addresses are never found on the Monero blockchain, but these one-time destinations are. They  take care of obfuscating the destination as they all look the same but only the owner of a private view key can know that it belongs to him. They're generated by the sender and used by the recipient to find his funds.

From Moneropedia:

  Every transaction involves two keys: a public spend-key, and a public
  view-key. The destination for an output in a transaction is actually a
  one-time public key computed from these two keys.

  When the wallet is scanning for incoming transactions, every
  transaction is actually scanned to see if it is for "you". This only
  requires your private view key and your public spend key, and this
  check is immutable and cannot be faked. You cannot receive
  transactions and identify them without the corresponding private view
  key.

  In order to spend the funds you have to compute a one-time private
  spend key for that output.

View-only Wallet

A wallet created by only using the private view key and the address. It enables the user only to monitor the blockchain for any incoming transfers. Practical use could be for increased security of the user or for audit purposes, if given to an auditor.

Audit Wallet

A view-only wallet to which the signed key images has been imported. One key image is needed for every output. Considering that the list of outputs can be seen with only the view key, it's easy to tell if some key images were witheld. With key images imported, such wallet would show the actual balance. If some new funds were to be received, the auditor would then have to ask the owner to send him the signed key image for this new output in order to be able to verify the actual balance again.

Hot Wallet

A Monero wallet which was exposed to a device with network access.

Light Wallet

A Monero wallet where the user doesn't store the Monero blockchain or runs a full node. The full node part and the wallet part of Monero software have been separated from the start. As such, the Monero CLI wallet is already a light wallet but it usually communicates with the local node run on the same computer as the wallet software. It could be connected to a remote node, and in that use-case it would become a light wallet. There are some nodes publicly available for this purpose, even on the Tor network.

There's another model which could be used for an even lighter wallet, but with some sacrifice of privacy. In this model, the server would store the user's private view key so it could keep updating the wallet while the user is offline. When the user would connect to the server, the client-side software would get a list of received outputs for which it would generate signed key images and send them to the server. The server would then tell to client software the exact balance. For spending, the server would prepare a transaction, send it to the client which would locally sign it with the private spend key and send it back to the server which would broadcast it to the network. In principle, it is as secure as the normal hot wallet, because all the spend key cryptography is performed on the client side.

There is a working implementation of this, but it is web based (javasrcipt) where the client-side is run by the browser. A stand-alone software would be significantly more secure as it would avoid certain vulnerabilities.

Cold Storage

A Monero wallet generated completely offline and never exposed to a device connected to a network. It could be a file store on an USB, could be just the mnemonic written on a piece of paper. What makes it cold, is the fact that it has and will always remain isolated from network.

Payment ID

A feature developed to make it easier for the sender to prove to the recipient that he sent him the funds. Due to Monero privacy features, the recipient can't tell from where the funds came. However, if there's a payment ID attached to it, it would give him a clue. Payment IDs should be randomly generated for each transaction to avoid linking transactions.

It works like this:
1. Recipient gives the sender his address and an unique payment ID
2. Sender sends the Monero with payment ID specified
3. Recipient sees an incoming transaction with the payment ID specified, and he can know that it came from that specific user because only that user could have known the payment ID.

Integrated Address

Similar use as payment ID. The difference is that both the address and the payment ID are encoded in a single string, which avoids mistakes and prevents accidents where the sender could forget to specify payment ID. Also, the payment ID in this scheme is encrypted with the transaction shared secret, so the privacy is improved as well. Due to this scheme, even when using the same payment ID and sending to the same address, the encrypted payment ID will appear as something entirely random on the blockchain. This is desired as it breaks linkability which occurs when using plain-text payment IDs.


Where is the monero conf file in the portable binaries version? The installation version has conf files here, but what if you unzipped the portable version from here?
Does it not exist until created manually with monerod --config-file=/etc/monerod.conf? I installed the monero gui and even then no bitmonero.conf exists on my pc nor in the registry.

You must create it yourself manually according to this answer. I believe I remember bitcoin operating the same way.