Payment processor for DigitalNote (Cryptonote coin)? Sorry if you feel this is not the right place for this question, but how I can integrate a payment processor onto a website for DigitalNote?

Websites like coinpayments.net require donations to support your coin, so how exactly can I add support for DigitalNote (and possibly XMR/Bytecoin in the future)?

I am not aware of a payment process for XDN.

One thing you could do is look at, say, https://github.com/TheKoziTwo/xmr-integration and modify it to support XDN. This might involve porting some Monero specific RPC calls, but most of it ought to be fine, since both Monero and XDN are Cryptonotes.

I would be wary of using a "pay for support" site, as some of them are scams, and others may drop you without further warning if they stop getting payments.


Mining from multiple servers to local wallet I am mining using ./monerod on Windows 10. I have created a wallet using monero-wallet-cli.

I want to setup more machines that run ./monerod.   How can I set them up so they mine to one wallet and not have to setup a new wallet on every machine?

While monerod does the mining, it does not control/manage wallets, and just uses whatever wallet address the user tells it to.

Therefore, if you created one wallet with address A on some computer, any monerod can mine to that wallet address by giving A to the start_mining command, ie:

start_mining A 3

This will start mining to wallet A with three threads.

Wallet A could well have been created on an offline computer. The public keys represented by the address are enough to mine to it.


Is the 10-block lock time a protocol rule? What rules accompany it? Every Monero transaction consumes old outputs (used as inputs to the transaction) and creates new outputs.  The new outputs are locked for 10 blocks before they can be spent.

A. Is this a wallet rule or a protocol/daemon rule?

B. Does the rule only apply to spending one's own output, or are new/locked outputs also excludable from a ring signature even as decoys/mixins?

C. If someone clones the Monero repository and removes the 10-block lock requirement:

What happens if they try to spend an output that would otherwise still be locked?
What happens if they use as decoys outputs that would otherwise still be locked?

A. Is this a wallet rule or a protocol/daemon rule?

It's a wallet / daemon rule. The number of blocks is defined as a pre-compiler constant CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE.

B. Does the rule only apply to spending one's own output, or are new/locked outputs also excludable from a ring signature even as decoys/mixins?

Generally, it applies to all outputs. So if you change the constant for both the daemon and the wallet, then you could have both the real one and the decoy of the age younger than usual.

In my experiment, I used a normal daemon and modded wallet. Since the daemon was using the usual setting of 10, and the daemon gives fake outputs to the wallet via RPC, it means that only the real one could be younger than 10. If I ran the daemon with the mod, they could (in theory) all be younger than 10.

C. If someone clones the Monero repository and removes the 10-block lock requirement...

I just did that to test and successfully sent 3 TX-es in succession, all using the CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE of 1.
So yeah, it can easily be done by changing that one line of code, and transactions made with the modded wallet will stick unless some reorg happens.

It's the same for both 1. and 2. because the network can't know whether the 1-block-old output is a decoy or the real one.

Note that by making such TX-es you'd stand out from the crowd, and it would probably be easy to tell that the same person did a few TX-es in a row if they're all spaced <10 blocks.

The Why

One could ask, but why isn't it set to 1 then?

Problem is, the input one-time keys are referenced using an offset. If a re-org would swap the order of transactions, then the transaction referencing any one-time key at the wrong offset would become invalid and would never confirm.


Is there a Javascript implementation of the CryptoNight algorithm? Before I seek to write one of my own, I wanted to see if there's a CryptoNight Javascript algorithm anywhere out there.  I found the CryptoNoter project, but it only contains an obfuscated binary file taht does the heavy lifting, which is banned from most browsers anyway -- https://github.com/cryptonoter/CryptoNoter/issues/34 .  It would be nice if there were a JS implementation so that I could see the algorithm in action and play around with it on my local machine.

Sure there is.

Do a npm search cryptonight-hashing and take a pick :)

NAME                      | DESCRIPTION          | AUTHOR          | DATE       | VERSION  | KEYWORD
cryptonight-hashing       | node-cryptonight-ha… | =moneroocean    | 2018-10-04 | 3.0.5    | crypton
node-cryptonight-lite     | node bindings for…   | =excitableaard… | 2018-02-01 | 1.0.1    | crypton
node-cryptonight          | node bindings for…   | =excitableaard… | 2018-10-08 | 1.2.0    | crypton
node-cryptonight-old-hard | node bindings for…   | =adaxi          | 2018-10-14 | 1.1.0    | cryptonware                      |                      |                 |            |          |
turtlecoin-multi-hashing  | ![image](https://us… | =brandonlehmann | 2018-12-11 | 0.0.18   | scrypt
multi-hashing-bbscoin     | multi-hashing-bbsco… | =randing89      | 2018-09-23 | 1.0.2    | scrypt
cryptonight-hash          | JavaScript…          | =andrehrf       | 2018-03-30 | 0.0.4    |


Any quick way for me to test my browser's hash rate for CryptoNight v2? I want to test the rate at which a WebAssembly miner can calculate CryptoNight v2 hashes in my Chrome web browser (or what my browser's Monero hash rate would have been as of ~May 2018). Is there an easy way to do this?

I've tried to hack some open source GitHub repos, but it's just too much work.

Given that Monero is now on CNv4, I doubt very much you're going to find a "quick" way to test this. You'd need to find or setup a version of the chain running the older version, setup a mining proxy, edit and build one of the CN wasm miners etc etc. So nothing "quick".

This all said, why do you need to test this? I can tell you right now that javascript mining gets you sub-100 Hs.


How can I generate the blockhashing blob for my Python miner? I am in the works of making a pool-compatable fully python miner, and I need to know how to generate the blockhashing blob for the miner.

Step #1 in this answer details how to get a blockhashing_blob.

If you plan on creating it yourself instead, this is much more involved. You would have to deserialize the blocktemplate_blob, calculate the merkle tree root hash for the blocks transactions (including a newly constructed coinbase transaction), then concatenate the block header, merkle tree root hash and transaction count (as a varint). That would get you a manually constructed blockhashing_blob. Doing this in just Python will be a big task.

It's worth noting, a pool-compatible miner doesn't need to create a hashing blob as the pool gives the miner the blob to hash.


Hash as encryption used by Monero Monero uses a Pedersen commitment yG + bH to obfuscate the value of a transaction, where b is the value and y is the blinding factor.
For the receiver to know both variables, it uses a Diffie-Hellman key exchange to share a secret rK, where r is a randomness chosen by the sender and K is a public key of the receiver. R = rG is public and sent as part of the transaction. The sender computes the following (the $amount$ is also sent in the transaction and H is a hash function):
y = H(“commitment mask”, H(rK))
amount = b xor H("amount", H(rK))

The receiver is able to compute y and b using R and his private key k.
Source: Zero-to-Monero, page 45
My questions are: can this be considered an encryption/decryption scheme and is it already known or is it original to Monero? If the latter, how can we prove its security?

My questions are: can this be considered an encryption/decryption scheme and is it already known or is it original to Monero?

Pedersen commitments (which are a commitment scheme not "an encryption/decryption scheme"), have been around since the early nineties. The encryption bit of what you refer to is simply the XOR of the amount and a key, the latter of which is a hash of a piece of data only the sender or receiver can construct (as it makes use of the shared secret). Using XOR to encrypt data is extremely common and certainly predates even Pedersen commitments.
What's original to Monero is how these elements (and others) are brought together and what they are applied to (i.e. a cryptocurrency, private digital cash). The security properties of all these elements is already well researched and understood.


Page 11 in that paper is still only concerned with the general ring signature case, not particularly focused on the Pedersen Commitment part.

The MGs field corresponds to the struct mgSig in src/ringct/rctTypes.h:

typedef std::vector<key> keyV; //vector of keys
typedef std::vector<keyV> keyM; //matrix of keys (indexed by column first)
struct mgSig {
    keyM ss;
    key cc;
    keyV II;
};

In this case, ss is a matrix of 2 rows and 5 columns, and two entries in each j-th column are (P_j, C_j - \sum_{i} C_{i,out}). II corresponds to the key images.

To answer your question 2., yes, we do need two secret keys x and z, for the output public key P_s = x*G and its corresponding commitment part C_s - \sum_{i} C_{i,out} = z*G, respectively. We don't need the second key image corresponding to z, because the output public key P and its commitment C are always coupled, so double spend checking using just one key image suffices.


In what ways can a wallet connected to a malicious remote node be abused? There are several efforts under way at the moment to build easy to use mobile wallets for Monero.  The most popular approach is to rely on a trusted remote node (either your own or one provided by a trusted 3rd party).

If we want to run wallets against potentially adversarial remote nodes, what problems can we run into?

I'm interested in both points addressing privacy and opsec, as well as technical challenges related to consuming potentially malicious data.

If we want to run wallets against potentially adversarial remote nodes, what problems can we run into?
I'm interested in both points addressing privacy and opsec, as well as technical challenges related to consuming potentially malicious data.

There are two categories of risks with malicious nodes. The first, most dangerous type of risks are the permanent ones which can't be undone. Temporary risks can be canceled once a legit node is used to replace the malicious one.
Permanent Risks

IP Logging: The data you leak when connected to a node contains among others your IP. This IP is a form of identity which criminals can exploit to target victims (thefts, ransoms, blackmail, ...), authorities can use to list Monero users (identify, surveil, arrest, ...), ISPs can monetise to charge extra fees (which can be performed regardless of the nodes nature) and other consequences associated with the knowledge of a physical person using Monero. As this risk is real and permanent, Monero is developing a cross-cryptocurrency solution called Kovri which solves this problem. Recently a wallet has been caught inserting a second transaction fee as funding system for their software which was a massive breach of privacy. Using the attack vector exposed in that article in cooperation with IP logging would allow a node to know which kind of software and/or hardware is being used. The knowledge of software and/or hardware is always the first step in hacking which could be targeted to this specific user.

Temporary Risks

Censor: A malicious node has the power to block your transactions from being broadcasted to the network with or without your knowledge. You would wrongfully think that you successfully made a payment.

Tempering: A malicious node can alternate the blockchain to decrease or increase your balance. This attack is complicated as the node should know your public address. The risk lies in the following example: A user using his exchange's node could buy funds from the exchange, make a withdraw of the bought funds and be tricked into believing the withdraw was successful. The user would think he lost his funds as, while using the exchange node, he saw his funds in his wallet.

Extorsion: As explained with the risk of censor, a node can block your transaction. Although this scenario is hypothetical, nodes could theoretically force a rise in fees by preventing low-fee transactions from being broadcasted and picked-up by good-will miners accepting them. This would be beneficial in the case of miners operating nodes in an attempt to increase their profits.

These are the only risks known to me. Feel free to edit to increase this list.


Setting up monero blockchain explorer on unbuntu 16.04 I am trying to setup Monero blockchain explorer on Ubuntu 16.04 by following this github repo.

I have checkout monero v0.12.1.0

but I am facing this error while running make command

  /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libgtest.a(gtest-all.cc.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
  /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libgtest.a: error adding symbols: Bad value
  collect2: error: ld returned 1 exit status
  tests/unit_tests/CMakeFiles/unit_tests.dir/build.make:1206: recipe for target 'tests/unit_tests/unit_tests' failed
  make[3]: * [tests/unit_tests/unit_tests] Error 1
  make[3]: Leaving directory '/home/monero/build/release'
  CMakeFiles/Makefile2:4425: recipe for target 'tests/unit_tests/CMakeFiles/unit_tests.dir/all' failed
  make[2]:  [tests/unit_tests/CMakeFiles/unit_tests.dir/all] Error 2
  make[2]: Leaving directory '/home/monero/build/release'
  Makefile:138: recipe for target 'all' failed
  make1:  [all] Error 2
  make1: Leaving directory '/home/monero/build/release'
  Makefile:64: recipe for target 'release-all' failed
  make: * [release-all] Error 2

I couldn't find any solution yet? can anyone help?

The error "/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/libgtest.a(gtest-all.cc.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC" tells you that the libgtest.a file of your system has not been compiled with position independent code, which is necessary to compile monerod.

You must either compile gtest with the -fPIC flag on your system or uninstall the gtest version on your system for the version of gtest embedded in the monero source code to be used.

The second solution is probably easier:

apt-get remove libgtest-dev
cd directory_of_the_monero_sources
make clean
make


monerod logging of hashes submitted Is there any way to include statistics of hashes submitted, blocks attempted, etc, in monerod logging when NOT using a pool? Right now, the only info seems to be the hash rate per second in the gui, and none whatsoever in the command line.

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

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


Can Monero ever have a 10 sec. block-time? I wonder whether Monero could have a 10 sec. block-time like Ethereum. I imagine that would be beneficial for near instant transactions. Why can they, and why can't we?

I don't think so, and I'm not sure it would work out long term for ethereum either, although they plan to switch to proof-of-stake and implement sharding, both of which would possibly help.

Monero actually used to have a 60 second block time, and then in March of 2016 switched to a 120 second target time. There are several issues with a very fast block time, some general and some unique to Monero (or other coins using a slow to verify hash like cryptonight).

The shorter the block time the more bloat you get for empty or nearly empty blocks. By forcing users to store empty blocks you are just wasting space basically. By increasing block time you should get more txs per block and therefore more efficiency. This probably becomes moot once a coin gets widely used, but that is basically only Bitcoin at this point.
The shorter the block time the higher the probability of orphans. Ethereum deals with this using their uncle concept, which I believes rewards miners even if their block gets orphaned, but that concept doesn't exist in Monero. Monero's proof-of-work algorithm is also pretty slow to verify, so for very short block times this may become a factor that contributes to increasing the orphan rate even more.


MoneroX wallet! Trouble with connecthion I have downloaded client MoneroX, generated address, and send XMR to my Monero address. Now, I can't see XMR on my wallet because MoneroX can't connect with network. What am I doing wrong?

Screenshot: http://prnt.sc/f2ss6h

MoneroX is deprecated and does not work properly with the latest versions of Monero. Please use a different wallet to use Monero.

If you want a desktop graphical interface, please use the official GUI, in beta 2 as I am making this post. You can download it from the official Monero website here.

Of course, you can also use the CLI interface available here or a web wallet such as MyMonero. Web wallets are typically less secure than desktop wallets.

To access your Monero from another wallet, please write down your mnemonic seed from MoneroX. You can use these words to restore your account on any other wallet software. In the GUI linked above, it will give you the option to restore your account from mnemonic seed. Select this option (full instructions here).

In the CLI, you can follow the steps shown on this page (full instructions here).

If using MyMonero, you will need to pay an import fee (full instructions here).


What's the easiest way to integrate Monero Payments without trusting a third party? I would like to integrate Monero payments on my website. I already know some of the PHP Libraries and https://monero-merchants.com/

Is there a simple way (somehow easy like monero-merchants.com) to integrate Monero payments to my website without having to trust a third party? The PHP libraries seem to require an own full node to run, or are there "open" nodes available which I can use in the PHP libraries?

From the looks of it it seems that you need to run a full node. I run a node myself and there is very little system overhead outside of hard disk space to store the block chain (which honestly isn't too big of a deal, so long as you make sure you have enough space for it to grow).

Once you have a node that's caught up on the blockchain (in my experience this takes anywhere between a few hours to 2 days depending on the system (SSD's help a lot) and network).

The basics of receiving payment are:

  Generate a payment ID (a random 64 character hexadecimal string)
  Communicate the payment ID and Monero address
  Check for the payment using the "payments" command in simplewallet

It's worth noting that the name of this command has been changed to monero-wallet-cli since the writing of the tutorial

Then you'd want to check your wallet to ensure that the funds have been received. To do this programatically a JSON RPC API is available. Here are two helpful commands to accomplish this:

  get_payments: this requires a payment_id parameter with a single payment ID
  get_bulk_payments: this is the preferred method, and requires two parameters, payment_ids - a JSON array of payment IDs - and an optional min_block_height - the block height to scan from.

additionally here is the general algorithm that is recommended to scan for transactions:

  Get the current block height from the daemon, only proceed if it has increased since our last scan
  Call the get_bulk_payments RPC API call with our last scanned height and the list of all payment IDs in our system
  Store the current block height as our last scanned height
  Remove duplicates based on transaction hashes we have already received and processed

Also the following is essential knowledge to tally payments:

  a transaction will typically have multiple outputs that add up to the
  total required for the payment, the amounts should be grouped by the
  tx_hash or the payment_id and added together. Additionally, as
  multiple outputs can have the same amount, it is imperative not to try
  and filter out the returned data from a single get_bulk_payments call.

See https://getmonero.org/getting-started/accepting for more details


The entire lifecycle of an XMR transaction with RingCT I'm trying to understand the data structure in monerod and create a simple workflow for a transaction's life cycle.

It doesn't look like this has been done post-RingCT activation, and I see a lot of confusion in the community (myself included). I will create a public post once I fully understand this, I will attempt to further simplify it, and share it with the community.

Here's what I have so far, I would appreciate comments or corrections.

1) The transaction starts with the Monerod aggregating the input(s) that a sender needs for this transaction.

2) Once that's determined, the wallet sources decoys TXOs (and their respective key images) by looking at past transactions in the chain.

3) A Borromean ring signature is generated by aggregating the signature of the real TXO and its key image with all mixins.

4) A Pedersen commitment scheme encodes the value of all TXOs through homomorphic addition. A separate data field is created with a range proof to confirm that the product > 0.

5) The sender then generates a Stealth Address by wrapping the receiver's address a la quasi-CryptoNote, plus an indexer: P = Hs(r, A, index#)G + B

6) The sender's wallet looks for decoy outputs (with their key offsets) and output values are not encoded through a Pedersen commit. I'm assuming two things here that are not clear:

6.1) Output values are not encoded though the commitment scheme (?)
6.2) Key images are separate data points that (put simply) represent a transaction's pubKey. The intended receiver has a private key that allows an output to be spent. Each output has its own key image, which is not included in the TXO list (?) I'm also assuming TXOs can be separated from key images.

7) The transaction is created & broadcasted to the network.

8) The receiver's wallet will use the private view key to see which images he can decode. Every time the chain is scanned, a list of key images appears. Some of them are unspendable (either because they have already been spent OR they have been used as decoys), but some of them are spendable. The receiver uses a private spend key to verify this by attempting to sign the image.

9) One of the key images with the intended amount can be singed and the receiver can confirm that he has received the funds.

I also plan to create a diagram showing this workflow so any help would be greatly appreciated.

I'll do my best to answer:

1) Actually it starts with the wallet, not daemon, aggregating the inputs for spending.

2) The wallet asks the daemon for the mixins (decoys)

6) All values are encrypted as Pedersen commitments

6.1) They are also Pedersen commitments

6.2) Key Images are actually on each txin

8) Receivers wallet (receiver) checks each txout stealth address to see if it belongs to them. The wallet does Hs(aR)G + B with a being the receivers private view key, R being the tx pubic key, G the Ed25519 base point and B being the receivers public spend key. If the output stealth address matches Hs(aR)G + B, the wallet then checks to ensure it's not already spent by computing it's key image and checking the blockchain. This is the purpose of key images, to check whether an output is already spent (double spend protection).


Is it possible for an adversary to shut Monero down? Imagine a government wants to ban XMR. Is it possible for them to do so? Only possible options, nothing like turning off the internet.

And if it is possible, what could be done against that?  Thank you.

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

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

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

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

  Is it possible for an adversary to shut Monero down?

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

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

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


How to generate Monero wallet without displaying keys/seed on the screen? I travel frequently, and many times I need to generate a new wallet while I am in an airport, or another public place. Heck, this question even applies in one's own home, if you are paranoid enough.

All wallets I've tried (including the core), insist on displaying the seed or the private keys on the computer screen, which of course can be captured easily from behind you.

Is there an easy way to generate a Monero wallet, and save the files, without having every bit largely displayed on the screen?

This web page kind of does that: https://moneroaddress.org/. The only problem with that page is that it's an offline wallet, and in order to even view the transactions I need to view/display the keys on the screen in order to copy-paste them in an online wallet.

If you use the --non-deterministic flag to monero-wallet-cli, the seed will not be displayed, since there is no seed for these. The secret view key is displayed, but not the secret spend key. This may or may not be enough for your purposes.

If you're on Linux machine (or similar), you can also pipe it to grep, like this:

./monero-wallet-cli --generate-new-wallet somename --non-deterministic | grep --line-buffered -v ^View\ key:

Note that you will NOT see the password prompts, so you should know when it's asking for one, and enter it blind when you know it's asking for one.


Why does rescanning the blockchain fail with "Abort trap: 6"? After importing a wallet in simplewallet, issuing the rescan_bc command consistently results in the following "Abort trap: 6" error on my computer:

[wallet 4*****]: rescan_bc
Starting refresh...
Abort trap: 6/ 1124452

The refresh command also fails:

[wallet 4*****]: refresh
Starting refresh...
Abort trap: 6/ 1124458

It happens around height 85000. What could be the reason for this, and how should one resolve it?

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

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

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


Blockchain database file size variance by Operating System I have a full node on both an Ubuntu 16.04 LTS and a Windows 10 device.

Why is the database file containing blockchain a different size on each OS?

You are probably looking at a database file with the blockchain in it. The main variation cause is that the database library Monero uses, LMDB, preallocates some space for writing. Every so often, when that space falls too low, LMDB will resize the file to get more breathing space.

Some OSes do not support sparse files - that is, files with "holes without data" in them. So these will actually have allocated space with data there, instead of just nothing, which makes the file larger than it'd be on an OS which supports sparse files.

It also depends on the version of Monero that is running. Recent versions have made optimizations which shrink the size of the database without impacting performance.

Last, it should be noted that this database is a few times larger than the actual blockchain data. This is because a database is geared towards reading the data back in an efficient matter, so data is stored denormalized (ie, with some duplicated parts, etc).


Will unlock_time lock sender wallet balance? I sent some transfers between two of my wallets yesterday with unlock_time about a month in the future. The incoming transfers show up in the new wallet as expected with the correct unlock time.

What also happened is that part of the balance in the wallet I sent it from is still locked. Will this balance also be locked for the same amount of time?

Yes, it will be locked for the same amount of time.

This is because the wallet had split some of the inputs into 2 amounts: one which it sent to the destination, and one which it sent back to yourself as change. The amount which will be locked on the sending wallet will depend on what input was chosen by the wallet when sending, and duration will be the same.


What are Fluffy Blocks? I heard the term thrown around here and on Reddit, but I haven't found its definition anywhere. Could someone please clarify?

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

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

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


Create bulk Monero addresses How can i create multiple Monero addresses?

anyway to make 1000+ Monero addresses at once.

Any tools/ software c an be used?

An easy scriptable way is to run:

  for n in seq 1000; do ./monero-wallet-cli --generate-new-wallet wallet$n; done

It's a bit heavyweight though. If you can code, you can generate new keypairs with:

cryptonote::account_base account;
account.generate();
account_public_address address = account.get_keys().m_account_address;


Is there any obfuscation in the communications between nodes? If a dictatorship decided it wanted to block Monero, how easy or hard would it be at the ISP level? Does Monero have any built in obfuscation to counter censorship (of Monero use in general such as running a node, mining, or sending or receiving transactions) at the ISP level?

If no such obfuscation exists, what plans are there for users in countries such as China where bans for anything not tightly controlled by the government are common. Bitcoin is transparent, trackable, and censorable, so I do not consider that an example.

There is none, hence the work on https://github.com/monero-project/kovri/.

A government might make I2P itself illegal, though, and that'd be yet another hurdle. Tor has something to try to look like other traffic (pluggable transports), which could be adapted to Kovri in the future.

See Why is it I2P (garlic routing) well suited for Monero (compared to possible alternatives)? for a recent list of why Kovri/I2P was chosen for Monero's future network level foundation.


One more question about sign transaction on cold-wallet node via wallet-rpc I need to make a transfer on hot-wallet (view-only) and sign it on my offline wallet(cold-wallet) via wallet-rpc

And then send it to blockchain

It possible?
I know how it can be done through a wallet-cli and unsigned_tx file

curl -X POST http://127.0.0.1:18083/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":1000,"address":"9uUr8urCW73Hf1S2PxDkmKBk8wRujbSNuVgusyUDGv5seSjbKwDATafCXAmbWd8cWHghhzF2J4hpGLXEkUkxHCT35A4VaU3"}],"mixin":1,"get_tx_key": true}}' -H 'Content-Type:application/json'
{
  "error": {
    "code": -4,
    "message": "transaction was rejected by daemon"
  },
  "id": "0",
  "jsonrpc": "2.0"

with do_not_relay parameter it returns:

curl -X POST http://127.0.0.1:18083/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destiations":[{"amount":1000,"address":"9uUr8urCW73Hf1S2PxDkmKBk8wRujbSNuVgusyUDGv5seSjbKwDATafCXAmbWd8cWHghhzF2J4hpGLXEkUkxHCT35A4VaU3"}],"mixin":1,"get_tx_key": true, "do_not_relay":true}}' -H 'Content-Type: application/json'
{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "amount": 1000,
    "fee": 851850000,
    "multisig_txset": "",
    "tx_blob": "",
    "tx_hash": "f7afba7ccb8e859a7600927053759d51f3904add1ba5217329a4a402d48fa6c5",
    "tx_key": "f9a932f872f28b1c1be19342c84e59fbe244b6e902430daf22dbd8b2f0eb4100",
    "tx_metadata": ""
  }

Can anyone help me with create and sign transfer with wallet-rpc??

If you call transfer or transfer_split on a hot wallet, you'll get data back in the unsigned_txset field. This was not yet present when you posted your question.

This unsigned_txset data can then be conveyed to the cold wallet, which signs it with sign_transfer, which gives you back a signed unsigned_txset field.

In turn, this is conveyed to the hot wallet, which then uses submit_transfer with that data.


What's the difference between the CryptoNightR and RandomX algorithms? My understanding is that CryptoNightR randomly creates different calculations for each block, and that RandomX does the same, but using a system where any bytecode can be translated into a calculation. What makes RandomX a more long-term solution that requires more auditing/testing?

Quoting SChernykh (one of the CryptonightR authors):

  CryptonightR is a modification to Cryptonight whereas RandomX is done completely from scratch. The main purpose of CryptonightR is to be the next PoW for Monero until RandomX is ready.

Which leads to why RandomX needs more auditing/testing. RandomX is a completely new PoW algorithm, not just a modified version of CryptoNight.

There is also the question/issue remaining of what can be done with RandomX in regards to GPU mining.


Anyway to pick which monero subaddresses one can use? Subaddresses are pre-generated for each wallet, but how many are generated?

Also would we be able to see all the available ones and pick out which ones we want to use? Say I wanted a vanity type address that ends with XX, how can we generate our own?

Subaddresses are deterministic. Your wallet will only search ahead 200 subaddresses at a time in order to check for incoming funds at those addresses. Therefore it would not be recommended to attempt to discover 'vanity' subaddresses, because it would later be more complicated to restore your wallet from seed and instruct it to search for incoming funds at very high subaddress indices.

If you really want to do this, you can just keep clicking the button to create additional subaddresses in the GUI, or use the address new command repeatedly in the CLI. See instructions here for restoring your wallet in a way that will scan to higher subaddress indices: Funds received from subwallet are not showing

Setting up the wallet to scan for larger numbers of subaddresses is a computationally expensive one-time operation, after which blockchain scanning speed will not be increased. This means that if you're willing to tolerate the one-time setup costs, you can monitor huge numbers of subaddresses without slowing your computer down.


what is my xmr mining capacity processor:2 duo cpu T6570@ 2.10GHz
RAM: 3GB
operating system: 32 bit
Windows 7 pro

what would be my expected daily return using my hp laptop with these specs

You can try mining with monero-wallet-cli to see your hashrate but I'm pretty sure it will be below 30H/s (a laptop i3 CPU). With this, you'd be getting about 0.006xmr/day. You can estimate mining profits here, just scroll down a bit and type in your hashrate.


Why does imported wallet not show correct balance? I have imported my seed from CakeWallet to MyMonero on iPhone, but MyMonero wallet balance shows 0 XMR.

What is the problem?

Don't import it, just create an entirely new wallet on MyMonero and just send all your coins from CakeWallet to MyMonero. This gives you the following benefit:

You won't have to rescan the entire blockchain from where your old wallet started and just start scanning today. Saving ALOT of time.

Don't import just send the entire thing over.

But if you want to keep your old transaction history for whatever reason, you'll have to pay that import fee.


Alternate Coins Implementation in this pool I'm curious to use this pool for 5 of different cryptonote based coins.
which includes:
XDN,
Bitsum,
Dero,
BCN,
Karbo

Please give some advice to put them in the pool,
I've successfully deployed this pool on the server for monero but need to know about alternate coins implementation and one more thing , if we can implement them in the pool so should we use all of them coins on parallel basis in a single pool.
Thanks

Adding a new coin to the pool requires creating and implementing a new js file in /lib/coins, creating and implementing a new js file in /lib/payment_systems and referencing both these new files in the coinConfig.json file. If you just duplicate an existing coins files and edit appropriately, that's probably the easiest method. Note, you'll need to be running a daemon for any coin you add of course.

With regards to running multiple coins in a single pool, you can't with nodejs-pool.


How do I find the value behind the pederson commitment? Given that I have found a tx that is for me, what would be the maths to find out how much I have received?

It's impossible to reverse the Pedersen Commitment if you don't know the mask.

The commitment is amount*H + mask*G, so if you were told the secret mask, it would be possible to brute force all likely amount values to discover the amount.

But then if the mask can be securely communicated to you, so can the amount. So this is what Monero does. It encrypts the amount using the transaction shared secret, and bundles that encrypted amount as part of the transaction.

The decryption math is: decrypted amount = encrypted amount - Hs(Hs(8aR||i)) where a is the private view key, R is the tx public key and i is the index of the output whose amount we're decrypting.


Converting the network identifier to text In the cryptonote_config.h file, the network identifier is given as:

boost::uuids::uuid const NETWORK_ID = { {
      0x12 ,0x30, 0xF1, 0x71 , 0x61, 0x04 , 0x41, 0x61, 0x17, 0x31, 0x00, 0x82, 0x16, 0xA1, 0xA1, 0x10
    } }; // Bender's nightmare

I believe the comment means that this series of hex values should translate or convert into a string that reads "Bender's nightmare", but I'm not seeing how. Inputting the values into a site such as http://www.rapidtables.com/convert/number/hex-to-ascii.htm I don't get that as my return string. So, how does the network identifier convert from hex values to ascii words?

I don't think the numbers encode the phrase, but it must be a reference to Futurama.

In season 2 episode 7, Bender has a nightmare of random 1s and 0s appearing, and he thinks he even saw a 2! Whether our network identifier somehow relates with numbers appearing in that episode, I have no idea.


How much "Earned uptime credit" do I get when staking Loki on a Service Node? How much earned up time credit do I get when I stake Loki on my service node? What is the maximum amount of credit can I get? And how does one calculate the how much you earn in a day?

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


Does running a full node becomes harder as the blockchain grows? I'm wondering if a larger blockchain means that running a full node is computationally harder, i.e. requires more resources?
(maybe more verifications should be done?)

Yes, it does.

The first obvious requirement is a larger storage space needed for the raw blockchain.

The second one is the need to store an increasing amount of output data in fast storage, as they're randomly referenced by incoming transactions. This include key images, public keys, and amount masks. This set never shrinks.

If you also consider that the amount of transactions per unit of time increases, then you also need more CPU, memory, and network capacity. This is not implied by your question though.

There is no pruning in Monero currently, but this is something that is doable, and preliminary work was done to hash prunable and unprunable RingCT parts separately. There is also talk of dropping signatures beyond a certain age (ie, when they have more than a huge number of "confirmations"). What will be done is not yet decided though.


Bus error (core dumped): v0.11.0.0 monerod on Ubuntu 14.04 Ever since the fork, I have been unable to get monerod to work for more than a day, if that.  I have reloaded the database several times, but they all crash the same way.

My latest effort got the following:

2017-09-20 21:27:53.077     7fe5aa00f780    INFO    global  src/daemon/main.cpp:279 Monero 'Helium Hydra' (v0.11.0.0-release)
2017-09-20 21:27:53.078     7fe5aa00f780    INFO    global  src/daemon/protocol.h:55    Initializing cryptonote protocol...
2017-09-20 21:27:53.078     7fe5aa00f780    INFO    global  src/daemon/protocol.h:60    Cryptonote protocol initialized OK
2017-09-20 21:27:53.078     7fe5aa00f780    INFO    global  src/daemon/p2p.h:63 Initializing p2p server...
[1505942873] libunbound[2658:0] info: warning: unsupported algorithm for trust anchor . DS IN
[1505942873] libunbound[2658:0] warning: trust anchor . has no supported algorithms, the anchor is ignored (check if you need to upgrade unbound and openssl)
sendto: Network is unreachable
2017-09-20 21:28:05.383     7fe5aa00f780    INFO    global  src/daemon/p2p.h:68 P2p server initialized OK
2017-09-20 21:28:05.383     7fe5aa00f780    INFO    global  src/daemon/rpc.h:58 Initializing core rpc server...
2017-09-20 21:28:05.383     7fe5aa00f780    INFO    global  contrib/epee/include/net/http_server_impl_base.h:70 Binding on 127.0.0.1:18081
2017-09-20 21:28:05.383     7fe5aa00f780    INFO    global  src/daemon/rpc.h:63 Core rpc server initialized OK on port: 18081
2017-09-20 21:28:05.383     7fe5aa00f780    INFO    global  src/daemon/core.h:73    Initializing core...
2017-09-20 21:28:05.384     7fe5aa00f780    INFO    global  src/cryptonote_core/cryptonote_core.cpp:323 Loading blockchain from folder /home/jacques/.bitmonero/lmdb ...
Bus error (core dumped)

I am running Ubuntu 14.04 on two different computers and downloaded monerod via the GUI wallet to each one, but, since I see the problem is the daemon, I am running it from the command line.  The problem exists on both machines.

Please, any help you can offer will be appreciated.

Bus error is a typical symptom of a corrupt blockchain, though 0.11 is meant to switch to LMDB safe mode to avoid such corruption once the blockchain is synced - something which appears not to have helped here.

One possible way out is to run monerod with --db-salvage, which will make monerod attempt to use the previous state of the blockchain database. This is a one off flag: the next time you run monerod, do not run with --db-salvage again (unless also corrupt).

If this doesn't work, a full blockchain resync is probably necessary.

If you feel like doing this, you can also run gdb on the core file to see where the bus error comes from. It's very likely to come from the LMDB code, but maybe it doesn't:

gdb monerod core*
  bt

Replace monerod with the path to monerod if it's not in the current directory. Also, if you have several core files, use the correct (it should be the most recent one). If you do not have a core file, you may need to run these first:

ulimit -c unlimited
  echo core | sudo tee /proc/sys/kernel/core_pattern

The message you quoted says "core dumped", but some recent distros seem to lie about it.


How will transaction fees be calculated after RingCT? I read that RingCT will bring transaction sizes close to about 13kb.

How much larger would a mixin=4 Monero transaction be compared to a Bitcoin transaction?

Based on a 13kb size, it would be about 0.13 monero per transaction, which is quite a bit more than normal. Are there plans for changing the fee structure calculation based on this transaction size change? How will this affect wallet dust?

I can't imagine a scenario where we base-price transactions at anything more than per-kb pricing. It's the most logical way to price it, given that you're literally paying for indelible space on the blockchain.


Why are do some addresses on the Monero testnet begin with '9' and others with 'A'? I thought the prefix of a cryptonote address was fixed. For example AEON uses a Wm. And Monero a 4. But sometimes the Monero testnet has addresses that begin with a 9 and sometimes they begin with an A. Why is this?

Example - these are both valid XMR testnet addresses: 9uXRFi4PZMqhsnthBF6bGdfVnBSZtfKkR7Td8qPM7jUKZeTfR1tLhCoTLqYNE12xuiQg3aWGiLw83bWsqwTRLaM4Jk47xYM

A1kVSWahxwRM2sABJzDWj5ZX1eJZ2FzuWLPTU3Kru97wQYNMrqex6k91LGALK3qvnMNVBPHEY76YqjWG4SB3y9SVR6tcypR

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

Those 2 addresses decode to:

353e39ae5e839ff8f46141a37551e6bae627575a6d8da8be269dae6f3410e188c32d446e4e687c749d7d165250f740b58d885ec452f317d8ce5a35de40ef08679d428d4a16

and

35e280bafa4b88c077c3b05ad67691acc268b5feb93c02e973e88a7a78b86a228cbdcf062b8776a201fc46bdd3fc1bda80749a241d0df4eafe1e1f17bb067ec6d5a0213a66

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


Does the coin support HD wallets, and if so, which derivation scheme? Can you tell me which derivation scheme is used in Monero, as BIP32/44 is well defined for ECDSA only and not for EdDSA?

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

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

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


Monero log error messages ("transaction extra has unsupported format") I'm using the Linux Monero command line client v0.11.1.0 compiled at home from github with no errors at all and I can find in the wallet log file many error messages like this:

WARN    wallet.wallet2  src/wallet/wallet2.cpp:660  Transaction extra has unsupported format <too_long_to_copy_string...>

I have the same errors messages when using a Monero client compiled by monero devs found on github.

Every time I open my wallet, the monero wallet writes in the log file many of these error messages. I have two questions. 1) is it a problem ? 2) I'm waiting for some mining pool payouts and I want to know if these error messages are related to some payments sent to me that have been rejected, what can I do in this case ?
Many thanks in advance for your replies.

This error happens when the extra field in a Monero transaction cannot be fully parsed. This may or may not be a fatal error: the transaction public key (which is needed to scan for incoming monero) is located in that field, but is usually present before such errors.

One recent cause for these errors is a slight issue in subaddress code recently pushed to master, which would add an empty list of additional tx keys where none was needed (this has since been changed). It seems likely that the transactions showing that error are sent by people using Monero software built from master with that issue.

In any case, if this is indeed what is happening, the message can be ignored as the tx public key is already extracted and scanning will proceed normally.


How long are mining rewards locked on testnet? I started a Monero testnet daemon this morning, and started mining to get a few testnet coins. Meanwhile, after mining 13 blocks, my wallet says:

Balance: 167.583046443332, unlocked balance: 0.000000000000

However, they're all still locked. The oldest block I mined is already ± 40 blocks ago. Is there a longer lock time for testnet? Or is this always the case (mainnet and testnet) for coinbase transactions?

If the rules are the same as on the main network, you need to wait 60 blocks (ca. 2 hours) to see the balance unlocked for coins that you mine.

For normal transactions, the balance is locked for 10 blocks only (ca. 20 minutes).


What is the minimum number of nodes for a private I2P testnet? What is the minimum number of nodes for a private I2P testnet ?

I do not know the absolute minimum, but I expect you should need ~10 nodes to have most operations function smoothly.


Are mnemonic seeds possible in right-to-left languages? For Electrum-style mnemonic seeds, words start with a unique prefix, usually the first 3 or 4 letters, so that users can change the rest of the word. But what would happen with languages that are written from right to left, like Arabic, Persian and Hebrew? Would the code expect the end of the word to be unique? And would it be difficult to change the system to accommodate right-to-left scripts?

At the moment, the GUI has been translated into Arabic and Hebrew, but we don't have any word lists for mnemonic seeds in right-to-left languages.

It'd be interesting to see if it displays correctly, but the system should be the same. In RTL languages, the display is different, the ordering of letters or glyphs is not changed. The first glyph in a string is just displayed at the rightmost position, instead of the leftmost position. You would therefore have prefixes like in English.


Solo, own pool, monero, need help I have about 50 instances I want to use for mining monero solo. I was hoping to setup my own pool and connect them all to it, but most tools such as coiniumserv don't support solo mining.

Any suggestions?

How about setting up your own stratum engine with MiningCore and connect everything you have to that?


Possible to turn off CLI Wallet logging? Is it possible to completely turn off logging for the CLI Wallet? I've looked around and haven't found any way of doing it. I know that there are a couple of logging parameters that can be adjusted so that the logging file/info is greatly minimized, but I would like to turn it off completely.

OK, so I originally asked this question (and previously commented) as a "guest", but now that I've finished setting up this account fully, the account is no longer tied to this question. So I can't comment on it anymore, and will have to respond to you guys with an answer.

@user36303 - Yes, you are right about the default logging. Apparently I had somehow carried over an old log file from previous versions of Monero without realizing it until now. Currently, the default logging is just the startup message (which is what I was trying to eliminate with this question anyway).

@dEBRUYNE - No, your suggestion did not work; the arg was right, but the option was wrong. To completely prevent logging, you need to put that arg (or the arg @jtgrassie submitted in his answer) on the --log-file option. So, two options work to prevent logging:

--log-file ""

or

--log-file /dev/null


Block height for v6 fork What is the block height and approximate date for the v6 Monero fork? Has there been a decision to change the targeted block height based on discussions to keep the fork near Sept 21st despite a recent increase in network hashrate that otherwise might cause it to come about 5 days sooner?

  Due to much more hashrate, the intended hardfork date of Sept 21 2017, may be closer to Sept 16 2017.
  Discussion is ongoing on whether the hard fork block number should be adjusted to something closer to Sept 21st.

The v6 fork is planned for block 1400000, which is on or about the 16th of september. Hash rate increase had little effect on the projected date, as can be seen in the patch (https://github.com/monero-project/monero/pull/2335/commits/2147859ac9d4660d0cc7736c8524fb2b48e9fbb2), so the discussion above is incorrect. Apparently the 21 date comes from a note in the README.md file which had not been grounded in anything.


Monero RPC over SSL for client and server I am trying to setup an RPC connection between monerod and monero-wallet-cli over SSL. For monerod, the recommended way seems to be to use nginx as a reverse proxy and add SSL support there. How do I use this SSL connection from monero-wallet-cli (and/or the GUI wallet too)?

Once you have setup the tunnel, it is equivalent to having monerod running in localhost. It is transparent for monero-wallet-cli and monero-wallet-gui.

The only difference, that i noticed so far, is that it doesn't accurately detect network failures, as the connexion with the tunnel manager stays up.

You can see here an example of setup using stunnel.


Livecoin doesn't credit my balance after missing Payment ID I sent 0.34293098 XMR to the Livecoin Deposit address. The problem is that I used my Freewallet XMR wallet and put the Payment ID in the comment field but Livecoin says the following:

  Deposits without Payment ID, or with the wrong Payment ID, will lead to a loss of funds. About this there is a warning inscription: http://prntscr.com/h7qfl5
  Unfortunately, we can not process your transaction, your funds are lost.
  In next time try to fulfill the necessary conditions or refuse from risky transactions.

I know they received the XMR but they just won't lift a finger to help.
Can I do something or can you help?
Best Regards,

Marcel

There is nothing you can do.

Per Monero's privacy they even can't know which transaction came from you, that's why they require a payment ID. Public coins like Bitcoin let you know who send the transaction and thus do not require payment IDs. There are procedures to prove you made the payment but Livecoin won't probably loose time on that. More information about the proof of payement can be found on Monero's Wiki.


What are the risks/benefits of mining on a pool using SSL/TLS encryption vs mining on pools with non-encrypted connections? Claymore released the newest version of his miner for XMR, version 9.7, and among one of the features introduced is "- added SSL/TLS encryption support for better security..."

I see one incentive to mine using that connection being a reduced fee, down to 2% now, I also get that encryption improves security, but so far I haven't seen any pools offering SSL/TLS support aside from the one listed as a default in his miner.

My question is, what are the pros and cons of this SSL/TLS vs normal connections to pools that the majority of miners use?
If non-encrypted connections are unsecured, to what risks, major or minor is one exposed for using such a connection?

Thank you for your time and information in advance!

It's less about the security of the data moving across the connection than about the authentication of the remote server. When you have the TLS fingerprint for the pool server set up in your miner configuration, such as with XMR-STAK, then you can be assured that the pool is the same one as last time you connected, and nobody has hijacked the domain name or some such in order to steal your hashrate.


Wallet initialization failed: basic_string::resize I just transferred a demo wallet from MyMonero.com to simplewallet, refreshed the wallet using the node.monerohash.com public node and saved it. Afterwards, when trying to set auto-refresh to 1 it asked for a password but said my initial password was incorrect. That's why I closed the wallet and wanted to re-open it.

I open it using this parameter on Windows

  simplewallet --wallet-file xx --password yy --daemon-host node.monerohash.com --rpc-bind-port 18082

Sidenote: As it was only for testing purposes, both xx and yy only consist of lowercase letters and are fairly short. My computer is also not suitable to run a full node.

Now I cant open my wallet anymore - the password checks out but it immediately crashes afterwards. As I am stuck on bad wifi and refreshing took more than an hour I would prefer not having to re-do it. If I have to do so, I would like to prevent this problem from happening again.

2016-Aug-28 22:46:52.097101 Monero 'Hydrogen Helix' (v0.9.3.0-release)
2016-Aug-28 22:46:52.097101 Setting log level = 0
2016-Aug-28 22:46:52.097101 default_log: C:\Temp\Monero\simplewallet.log
2016-Aug-28 22:46:52.098101 Logging at log level 0 to C:\Temp\Monero\simplewallet.log
2016-Aug-28 22:46:52.098101 Loading wallet...
2016-Aug-28 22:46:52.163105 Loaded wallet keys file, with public address: 45FZMgNtBQ7ZnhdKvJNDDyNqcAg8GxcXtQtt42qYtf7uHqmcic8K2K7YP4xiXfa5r94bhY6mYpLByCPQ4kENsZyiV8QQguy
2016-Aug-28 22:46:53.510182 ERROR C:/msys32/DISTRIBUTION-BUILD/src/simplewallet/simplewallet.cpp:2721 Wallet initialization failed: basic_string::resize

It is very likely that this (at least the reversion to watch only) is due to a bug in 0.9.3, which is fixed in 0.9.4.

Note that the 32 bit Windows binaries for 0.9.4 mistakenly include 0.9.3 instead. This will be fixed shortly, see https://github.com/monero-project/bitmonero/issues/1019 for reference.


Can I view seed words of non deterministic wallet? I have created my Monero wallet long time ago. Today I tried to see my seed and the terminal give me the message "wallet is non-deterministic and have no seed" So do I have to create new wallet or do I have another option?

If you want a seed, you have to make a deterministic wallet. The seed is a representation of your private spend key, and deterministic wallets derive the private view key from it. Therefore, a non deterministic wallet would not be able to restore the private view key from a seed (or it'd have to be twice the size, which is was not done for unknown reasons).


Can the monero-wallet-rpc handle multiple requests at the same time? For example, to process several "transfer" requests in parallel. The question is about this implementation of the wallet. I can't figure it out quickly on my own.

The wallet RPC server is not really designed for high traffic, concurrent connections. It only operates on one wallet at a time and runs single threaded. I.e. it assumes only one person is using it at a time, so only one call needs handling each time.

Very near the top of the linked file (line 144), you can see:

//DO NOT START THIS SERVER IN MORE THEN 1 THREADS WITHOUT REFACTORING
return epee::http_server_impl_base<wallet_rpc_server, connection_context>::run(1, true);

Which points out this is running in a single thread.

This of course does not prevent multi-user, multi-wallet setups, it just means you would need to run multiple processes of the monero-wallet-rpc.


Is Hybrid mobile wallet is as just secure than native For example in the future we will be able to have an implementation that  would allow a light wallet to connect to a remote server. Does a hybrid appp (e.g. Ionic ) is just safer than native? One good example right now  is mymonero.com converted into a mobile app.

I researched about this and only found a researched by IBM on cordova, but the vulnerability is very easy to mitigate and probably is not a problem if the hybrid app is just securely implemented.

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

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

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


Raspberry Pi 3, 64bit Suse and Monero I know a lot of issues that people encounter running Monero nodes on rPis is due to the 32bit OS.

I was planning to use this:https://en.opensuse.org/HCL:Raspberry_Pi3
(A 64bit version of Suse) and run a full node.

Anyone tried that out?

Pi 3 is still not a decent system, even with a 64bit OS. Their chip lacks AES instructions. Will be slow at verifying blocks.


Official encrypted wallet generator I'd like to make a cold storage wallet such that if it is found it will appear to be an empty wallet unless a password is used to decrypt it. This site xmr.llcoins.net was recommended by moderators, but it still seems like an unofficial method, and I'm worried about decryption method being lost. Also if it hasn't been tested thoroughly I'd hate to send xmr to nowhere and have it lost.

Is there any plan for an official encrypted wallet generator to be run/distributed by core team?

I would like any encrypted wallet to itself be a valid wallet. You could create an arbitrary tree inside with different passwords for duress situations.

The scheme from the site is a good one and it won't be lost if you don't lose it :)

But anyways, it's fairly simple to remember: hash the passphrase with CryptoNight and EC add it to the original seed. Even if lost, knowing the scheme, it could be reimplemented.

This method has the benefit you seek -  encrypted seed looking like any other. You could roll a random seed, and then make multiple other seeds from it by applying different passphrases. Store only the "main" one, and put some pocket change on it to fool a potential thief into thinking that's all there is.

There's acutally already a PR to implement the same method into "official" software: https://github.com/monero-project/monero/pull/2257


Drawbacks of running a RPC-enabled node Besides increased resource requirements, why would someone not want to run a RPC node?

You're putting your node out in the wild where everyone can see it.  The more attention on monero/your node, the more people will try to hack/attack it and use any information on the node to further hack/attack you or anyone else linked to that node.  For many foreign hackers with lots of time and a modicum of skill this is a risk free endeavor that will net them lots of untraceable magic internet money.


What all information we can gather from a Monero wallet address? I am pretty new to this crypto currency. My question is that what all information can be found, if we only know a malicious user's Monero
wallet address?

Can I check this Monero wallet balance? If so, how?
Can I check who (wallet address) deposited to this wallet address? if so, how?
Can I track to which wallet the owner withdraw the monero from this wallet address? if so, how?

@JollyMort,  Adding one more question:

Today all these Ransomware attacks ask the ransom in the form of Bitcoin. In this case authorities can trace to which exchange this bitcoins are ending up (justing using the wallet address of the attacker) . So are you saying that if the ransomeware people ask for Monero coins instead of Bitcoin, authorities are in trouble? That the authorities cannot track in which exchange the ransom (Monero) coins ended up?

Thank you so much,

No.
No. Naturally, you can only know about what you sent to that address. You can't know whether that address ever received anything else from the side. When the target spends what you sent to them, you won't be able to tell if it was your target who did the spending or someone else who just happened to include output of your TX as his "decoy" input (look up how ring signatures work) - you can only make a guess, with no way of telling if it's right. However, if the target combined what you sent to it together with something which came from someone else in the same TX, you could make a following guess: maybe your target spent what you sent it and if so maybe he combined it with something he received from elsewhere.
No. Sending back to the same wallet or to another wallet looks exactly the same and can't be linked to any address (look up how stealth addresses work)

Here's a simple explanation of the mechanics: Simple explanation of Monero mechanics - how does Monero work?


Is deanonymisation via propagation analysis possible for Monero? In Bitcoin, every node tries to establish 8 outgoing connections and sends new messages to its neighbors with random delays ("diffusion"). This enables certain deanonymisation attacks, where an attacker establishes many parallel connections to many nodes and creates an approximate (tx -> IP) mapping based on network propagation delays, e.g. as described in this paper (another propagation algorithm was used at the time, but the improvement was only marginal, as per another paper).

If I understand correctly, Kovri aims to solve this problem for Monero, but is not yet deployed. Does this mean that correlation of Monero transactions based on traffic analysis is possible?

Yes, the same idea applies to Monero, as it uses a very similar network system.


How to enable pruning in the command line of the monero blockchain in version v0.14.1? Monero v0.14.1 has just been released with pruning. How does one activate it on the command line for ubuntu?

Quoting relevant part of the commit message:

  There are three ways to prune a blockchain:

  run monerod with --prune-blockchain
  run "prune_blockchain" in the monerod console
  run the monero-blockchain-prune utility

  The first two will prune in place. Due to how LMDB works, this will
  not reduce the blockchain size on disk. Instead, it will mark parts of
  the file as free, so that future data will use that free space,
  causing the file to not grow until free space grows scarce.

  The third way will create a second database, a pruned copy of the
  original one. Since this is a new file, this one will be smaller than
  the original one.

  Once the database is pruned, it will stay pruned as it syncs. That is,
  there is no need to use --prune-blockchain again, etc.


Why is the emission curve of Monero so steep? It seems to be steeper than Bitcoin. Why is this?

It's steeper than bitcoin's because thankful-for-today made it that way. Indeed, if you dig into the bitcointalk forum history, you can find that not many early monero community members were supporting this curve and there was actually discussions about changing the curve.

While this is outside the scope of this particular question, no one actually knows the characteristics of an ideal emission curve. Take for instance Cryptonite (the bitcoin-based coin that uses an innovative accounting system as opposed to straightforward ledgering). This coin has an extremely shallow emission curve - if you mine it now you will get very similar rewards compared to if you mine it in 4 years (or something). This provides no incentive to start mining now - you could wait a couple of years. Thus, there's no incentive to "bootstrap" the network in a speedy fashion. As a result (or its just coincidence), the coin languishes, albeit its obvious advancement of blockchain technology that would completely eliminate any concerns of blockchain scaling, at least regarding the blockchain database.


Where can I find the AEON pruning branch? Very recently smooth_xmr said:

  You might try the experimental pruning branch, which has been updated to 0.9.7.1 (I don't have the link for the instructions, maybe someone else knows it?)

The download link on Aeon.cash leads to the GitHub release page but I cannot seem to locate the pruning branch.

Where can I find the newly updated pruning branch referenced by Smooth?

Does it have install instructions available?

As the post indicated the pruning branch is still considered experimental. Therefore it resides in another GitHub repository found here. I have included a summary of the instructions smooth provided upon releasing the pruning branch which should still be accurate today

Clone from GitHub:

  git clone https://github.com/iamsmooth/aeon light-node
  cd light-node
  git checkout light-node

Compile:

  make

Copy your blockchain.bin file to blockchain-pruned.bin in the same location. Save the unpruned copy as a backup and in case you experience problems with the pruning branch.

Start your node with --pruning option. Then exit to save the pruning branch and reset RAM. Then start with --pruning again and run as normal.


Multiple CPU miners with low hashrate vs single CPU miner with high hashrate I looked at the Monero algorythm (unfortunately not fully understood) and wonder if I could increase the probability of hitting a block with multiple CPU miners (low hashrate - for example 10 x 200h/s) or with a single CPU miner (high hashrate - for example 2000h/s).

Has anyone already drawn up a comparison and what strategy would make more sense with regard to the algorithm?

If all the computers have a good network connectivity, the probability of successfully mining a block is proportional to your total hash rate.

Mining with 10 CPUs doing 200 h/s each and mining with 1 CPU doing 2000 h/s will give the same probability of finding a block.


When should I choose "MEDIUM" or "HIGH" transaction priority? In Monero's GUI, monero-wallet-gui, I see a drop-down box for "Transaction priority" with the following options:

When should I ever choose anything else but the default value ("LOW")? As far as I know, blocks aren't full so far, and there's a dynamic block size …

Transaction priority is a setting used to set your payment apart from other payments in the mempool if there is any competition, confirming your payment sooner. This can be seen in Bitcoin, where low-fee transactions can take hours at various times to complete, while higher fee transactions are completed relatively quicker since miners (who confirm every transaction) prefer those with higher fees since it earns them more money.

As you correctly stated, blocks currently are not very full in Monero, so there's no reason to choose a higher fee at this time. However, blocks may increase in size, so this could change, perhaps with the switch to RingCT and the larger block size that will entail.


Pre-Mined Monero Fork I would like to create a Fork of Monero with a certain number of coins premined.

I have tried to follow How would someone premine a direct fork of monero ( can it be done ) but it is incomplete.

Based on this, I have found on line 92 of src/cryptonote_basic/cryptonote_basic_impl.h

  bool get_block_reward(size_t median_size, size_t current_block_size,
  uint64_t already_generated_coins, uint64_t &reward, uint8_t version);

Lets assume I have a maximum supply of 5000000 coins of which 90% are premined. Where do I modify the Monero code to show this? Also, where do I specify the wallet address for the pre-mined coins to be sent to?

You can add this line of code in the first line of the get_block_reward function for premine, set  the reward of your choice

 if(already_generated_coins == 0) {
       reward = 4000000;
       return true;
    }


I read that Monero is a Bytecoin fork. When launched in 2014, how was Monero's software different? I know it didn't have a premine, unlike Bytecoin, but was its software any different as well?

Edit: I've read the history between the two, but the details on their original software differences isn't described there.

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


Warning when restoring from seed When I restore a wallet from a standard 25 word English seed:

./monero-wallet-cli --restore-deterministic-wallet

I get the following warning:

  You had been using a deprecated version of the wallet. Please use the new seed that we provide.

However the "new" list of mnemonic words shown by the wallet is the same as what I entered.

Is there something wrong with my seed?

If I remember well there was a minor bug in displaying the new one. Try using the command seed to show it again, it should be different. Note that both old and new seed will encode to the same private key.

The difference is that old one was just a random number which would have to be 'normalized' to a valid private key. Now, your seed is your private key. More in-depth explanation here: Why did monero-wallet-cli restore the same wallet with different mnemonic seeds?


Saving the blockchain with monerod Is there any difference in how the save and exit commands save the blockchain?

Is there any benefit in using the save command before using exit to close bitmonerod?

What is the danger is closing monerod without saving because my computer froze up, or my laptop battery died, etc? Is a failure to save new blocks since the prior save the worst that could happen or is data corruption also possible?

Saving isn't really needed now. All it does is call mdb_env_sync, which will flush the filesystem, so the OS really writes things on the disk. Exiting bitmonerod normally will also call this, so using save before exit is unneeded.

Originally, save was needed because the blockchain was all held in RAM, so if your node was running long term and crashed, you'd lose days or weeks or even months of sync time. This is not the case anymore, and the use of LMDB means any changes are reflected on disk automatically (that is, depending on whether the OS decides to keep certain pages in its disk cache, and this is where mdb_env_sync comes into play).

Ideally, there should not be corruption if bitmonerod crashes. I don't know the details of db transactions though, so if you can, always exit gracefully, but if you can't, it should usually be OK. However, there have been reports of failing to start back up, which I've not seen here when killing bitmonerod abruptly, so better safe than sorry.


If you have mnemonic seed, does the phrase need to be in order? Let's say I have all the words to a mnemonic seed. I scramble them in an order that only I know. Can someone take that scrambled up order of words and unlock my wallet? Or does the phrase have to be exactly in the same order that I first saw it?

Yes, the word order matters. Somebody else can provide the correct math behind this answer, but the short version is that words out of order will have different results.

For example, if I generate this random seed using Luigi1111's generator:

down nurse broken pager phrases owner shuffled titans pavements zapped fungal balding ruffled swagger noodles duties haystack yearbook navy akin woes glass pram punch haystack

it results in this address:

49fvJmi7uRs3gn7PEf1skdLnYueQ2yNFVWpoAFbPudyr1TCQgXV699t5B8yDJKuCzH8chLczzvMR9dWj9Xi8UR2Y1a7Udjk

But if I switch the first two words (placing "nurse" in front of "down") the generator errors:

"Your private key could not be verified, please try again"

Long story short, the word order matters. The one change you can do is shorten each word to its first three letters. So instead of "down nurse broken ..." you could write "dow nur bro ..."

Edit: Good input by Jolly Mort below. The generator errored, not because that mnemonic seed is bad, but because the 25th word in the seed (haystack) is a checksum of the other 24, so it will error if any of the previous words are changed. If the checksum word was recalculated after switching down and nurse, the address would give a legit address, but it would not be the same one as before. So the word order still matters.


Creating Monero payment buttons which convert USD to Monero, customers pays and monero sent to my wallet I have been looking at the developers sections for a solution. Is it possible to create a payment button for Monero similar to Paypal for an e-commerce website and have the monero sent to my GUI Wallet? I suppose I want a very simplied version of Globee. I prefer a solution using PHP and MYSQL on an Apache server which is what the website will be made in. At home I will be using Win 10, and a Monero GUI and running my own node.

Let us suppose that I want customers to click on a button to make a payment for $20.
I would like this converted into Monero using some sort of converter which converts USD to XMR.
The customer makes the payment.
Two payment confirmations are sent out by email. One email to me, telling me who (email identity) paid what for which service. And the other email to the customer.
In these emails, and in the transaction itself there should be some form of unique identity number which only the two of us know, in order to affirm payment. I think this is already included in Monero transactions, but i'd like it to show in the emails so customer gets proof of payment/invoice.

So with this in mind, my questions are:

Should I be looking at the Monero Integrations Library written in
PHP? https://github.com/monero-integrations/monerophp Or is there another tutorial relevant to what I want to do?
Would OpenAlias be relevant to me?
If I used the ‘subaddress’ facility in Monero to generate an address
and use that on the website, would that be sufficient to pull out a
new address for each customer? Should I combine with OpenAlias here?
Do I need to make RPC calls to the Monerod Daemon if I have the
Monerod sent to my wallet direct?
As I understand, I would need to set these parameters in the code
but I’m wondering if I need any others?

Monero address
Tx_payment_id
Recipient _name
TX_amount
TX_description
By any chance, is there some code around I could just copy and paste
and use?

Thanks in advance for any help.

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

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

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


MinerGate mining Monero cryptocurrency with ArubaCloud For 21 days I've been mining Monero cryptocurrency using the VPS from ArubaCloud. At the beginning, mining was about 25h / s. For 3 days I have been having problems with mining, the speed has decreased to 5h / s and in addition I lose connection with my miner.

Do you know what can be the reason?

When mining on a VPS drops, the likely reason is that you either got throttled by the admin, or your VM shares hardware with other VMs which are competing for the CPU time.

If this VPS provider can migrate VMs on other hardware, it might also be the case that the previous hardware had (and exposed to guests) AES-NI instructions, and the new one does not. AES-NI on Intel/AMD are instructions which speed up Cryptonight mining a lot.


How can I mine continuously? Is there a way to keep "start_mining 2" mining continuously?  If so, what command can I use?  I started "start_mining 2" yesterday, left for work and came home and mining appeared to have stopped.  Thoughts?...

start_mining 2 is supposed to mine continously.

Mining is paused at a few points, when modifying the blockchain. It is possible that a bug crept in, causing mining to not get out of pause. A bug report on https://github.com/monero-project/monero/issues will be help in getting this fixed.

In the meantime, you can have a simple cron job restarting mining through RPC, like this:

curl -v -X POST http://127.0.0.1:18081/start_mining -d '{"miner_address":"insertyouraddresshere","threads":2}' -H 'Content-Type: application/json'


Can't copy/paste in GUI I get nothing on right click in any field in the GUI wallet. Is this a bug? I sent a transaction by typing the address manually and it worked but it's not really usable like this.

You can copy nearly every field in the GUI with an double-click or the copy symbol and you can paste in any field with strg+v.


What are the best practices to move coins out of cold storage? There are tutorials on how to set a paperwallet but I found nothing on the best practices to recover funds out of a paperwallet.

I imagine it is a critical step too, what is the best way to do?
What are the mistakes or practices to avoid?

Thanks,

Excellent question. I suppose the only way, for now, would be to boot into a clean system by using a live CD with network access, syncing the daemon, restoring your wallet*, syncing the wallet and immediately spending what you intended to spend (or send to your "hot" wallet) and then sending the remainder to a new cold storage. This last step is an important one just in case that, even with the precautions, your system was compromised somehow. If you spend and send the change back to a new cold storage immediately, the potential thief probably wouldn't have a chance to steal your funds.

*For added safety, I'd create the wallet file on an offline PC, secure it with a password and copy it to the online PC, sync and spend the funds. This way, the potential thief would need both your password and the wallet file to steal your funds.

Another approach would involve having 2 nodes. One exposed to the internet, and the other firewalled so that it allows only the monero node traffic between your 2 nodes, but for this you need to know your networking to set it up securely (I wouldn't know how to do it).

Eventually, we will have the functionality to do offline signing. It would work like this: you'd get all the data required to build a transaction from the online PC, copy it to the offline PC and use it to sign the transaction with your private keys, copy the signed transaction back to the online PC and broadcast it to the network.

To avoid all the hassle, there is a device (Trezor) which you plug into USB of the online PC and it serves the purpose of the offline PC and signs the transaction, with the tx data going back and forth over USB, saving you the trouble. The firmware for monero is available for testing purposes and we should expect a stable version in the nearby future. This is the most convenient option, and I think it can't come too soon.


Are 0-output transactions possible? Is it possible (as in allowed by consensus, not doable with today's software) to create a zero-output transaction in Monero? In other words, is it possible to create a transaction whose inputs are entirely used as fees and creates no new outputs?

Yes, it is possible, and while I can't point at it right now, I know there's at least one in the chain.


Is there any block size limitation? In Bitcoins the blocks have a size limit of 1MB.

Is there any hardcoded limit for Monero? If not, how does it affect the cryptocurrency in terms of scalability?

There is a block size limitation.

The maximum block size is variable, and a function of the size of the previous blocks.

More precisely, the maximum block size at a given height is the maximum of (1) 60000 bytes and (2) twice the median size of the last 100 blocks.

The intent is that, as transaction traffic increases, blocks fill up. When enough do, the maximum block size will increase too. When transaction traffic decreases, block size goes down, and the maximum block size will follow, up to the 60000 bytes limit.

This prevents an attacker from submitting lots of transactions to overwhelm the network at once, while allowing some artificial space scarcity to create a fee market.


How does a Monero node know to reject Borromean range proofs Now that Bulletproofs have been deployed, how does a Monero node know to reject any Borromean range proofs?

Is there something like a checkpoint, so that after block N, no more Borromean range proofs are allowed?

There are numerous places that check transactions, but perhaps the most pertinent is here, where Borromean range proofs are no longer allowed, based on fork version.


What is "Migrating Blockchain Version"? I just got the recent version of bitmonero wallet winx64 v0-10-1-0. It says Migrating blockchain from DB version 0 to 1 with the total number of blocks being 1,142,544 (data.mdb is 9.67 GB).

What is the "migration" process? Is it having to completely export the blockchain to raw data then import it to a new data.mdb?

I've been running monerod.exe for over 24 hours and I don't see any export data or raw blockchain file so I would like to confirm that progress is being made somewhere. It is not a SSD hard drive and it's consuming resources to the point that my machine is out of service until it is done working.

What is it doing and how can I confirm progress is being made?

Thanks to Jolly Mort's comment, I can answer this question now.

Running it with monerod --log-level=1 is much more verbose in both terminal and the log file at C:\ProgramData\bitmonero\bitmonero.log

The logs explain the process a bit more in depth:
2017-Jan-02 04:24:09.636702 Migrating blockchain from DB version 0 to 1 - this may take a while:
2017-Jan-02 04:24:09.636702 updating blocks, hf_versions, outputs, txs, and spent_keys tables...
2017-Jan-02 04:24:09.636702 Total number of blocks: 1142544
2017-Jan-02 04:24:09.636702 block migration will update block_heights, block_info, and hf_versions...
2017-Jan-02 04:24:09.636702 migrating block_heights:
2017-Jan-02 04:24:09.636702   block_heights already migrated
2017-Jan-02 04:24:09.636702 migrating block info:
2017-Jan-02 04:24:09.636702   block_info already migrated
2017-Jan-02 04:24:09.636702 migrating hf_versions:
2017-Jan-02 04:24:09.636702   hf_versions already migrated
2017-Jan-02 04:24:09.636702 deleting old indices:
2017-Jan-02 04:24:09.636702   old indices already deleted
2017-Jan-02 04:24:09.636702 migrating txs and outputs:
2017-Jan-02 04:24:09.652302 [check_and_resize_for_batch] checking DB size
2017-Jan-02 04:24:09.652302 [get_estimated_batch_size] m_height: 1142544  block_start: 1142044  block_stop: 1142543
2017-Jan-02 04:24:09.823902 average block size across recent 500 blocks: 5814
2017-Jan-02 04:24:09.823902 estimated average block size for batch: 5814
2017-Jan-02 04:24:09.823902 calculated batch size: 130815000
2017-Jan-02 04:24:09.823902 increase size: 536870912
2017-Jan-02 04:24:09.823902 DB map size:     12884901888
2017-Jan-02 04:24:09.823902 Space used:      10393010176
2017-Jan-02 04:24:09.839502 Space remaining: 2491891712
2017-Jan-02 04:24:09.839502 Size threshold:  130815000
2017-Jan-02 04:24:09.855102 Percent used: 0.8066  Percent threshold: 0.8000

At the bottom of the terminal, though not in the log file, it displays 827000 / 1142544 which I am assuming is the number of blocks migrated out of the total number of blocks in my database. This is exactly what I was looking for and it means that the migration process is much faster for me than trying to sync the blockchain all over again. I can see it updating and it's currently at 830000 / 1142544.

It looks something like this:

Side note: If you shut down by pressing Ctrl+c and then X out the window, it will say
2017-Jan-02 04:48:05.138644 [node] Stop signal sent
2017-Jan-02 04:56:25.103922 Got control signal 2. Exiting without saving...

Ignore this as it does appear to save and resume where it left off. I've tested and confirmed that this is the case.

Edit: This took somewhere under two days to complete (I didn't pay attention to the exact time, which could have been a day and a half) and my blockchain data was about 102 days behind the ledger after migrating. As of today, the ledger has a total of over 991 days on it. So I'm guessing this was faster in my case than synchronizing the entire blockchain. I'm on a 2.10Ghz laptop running Win64 with 4GB RAM and, perhaps most relevant, HDD (specs) not SSD.

Edit 2: It may be better to just download the blockchain again after updating because it eventually got stuck on a blockchain around 23 days behind with a bunch of errors that it just would not get past for some reason. It ended up costing me a lot more time than it was worth.


How to close a wallet without stopping the RPC server? I am trying to use RPC to perform such actions as:

Check balance and make transfers using selected wallet
The needed wallet should be unlocked just before any tranfer and locked immediately after

monero-wallet-rpc (with --wallet-dir option) can do the first part, but I have some problems with the second.

When I start monero-wallet-rpc, no wallet is loaded and I should manually do that using "open_wallet" function with filename and password parameters. After that, I can request balance ("getbalance") or transfer ("transfer") funds, none of them needs password anymore. I tried to close wallet using "stop_wallet" command to "lock" the wallet, but it stops the entire monero-wallet-rpc daemon (so I can't anymore open wallets without restarting monero-wallet-rpc).

The only solution that I found to solve the problem is to use "open_wallet" on some temporary wallet, so that it replaces the "battle" one, but I am not sure, that "battle" wallet is fully closed and the whole solution doesn't seem to be correct.

What else can I do to achieve listed requirements? May be there are some other tools (or options) that can be used?

Recent monero code has a close_wallet RPC, as seen in https://github.com/monero-project/monero/pull/4007.

This call will close the currently opened wallet, if any, if you've started monero-wallet-rpc with --wallet-dir.


AMD and Nvidia Same Computer XMR-Stak I'm mining with a 1070, and I have a 580 lying around. Is it possible to mine on XMR-Stak with both AMD and Nvidia GPUs in the same system? To do this, I would need to purchase a new motherboard, and possible case, as I'm running an mATX build right now.

Would it be worth it to go for the bigger board and extra slots? Or am I better off selling the 580 and the 1070, and go for a better card?

Yes, it's possible to mine on XMR-Stak with CPU, AMD GPUs and Nvidia GPUs in the same system at the same time. Take a look at Monero Mining Wiki on Reddit for more info on building a Monero mining rig and how to configure software.

In your case, the problem isn't mATX board, but how many PCI-E slots on it. Supposing that you're using the only full-size PCI-E x16 slot, maybe you have some PCI-E x1 slots free and you can use them with risers to add other cards to your rig.

If you plan to go big in mining, also a motherboard with many PCI-E slots could be helpful and you will need some risers. Get the ones that fit in a PCI-E x1 slot, since they also fit in the larger PCI-E x16 slots. Lastly, Nvidia 1070 and AMD RX 580 are nice cards for Monero mining and a good starting point for sure, I will remain with them.


You are now synchronized with the network. when i synchronize with the network I receive this message:

"You are now synchronized with the network. You may now start monero-wallet-cli."

But monerod.exe is still synchronizing:

SYNCHRONIZATION started
2016-Oct-09 12:55:22.426086 [P2P9][216.249.85.44:55740 INC]Sync data returned unknown top block: 1148310 -> 1107265 [41045 blocks (57 days) ahead]

So can i use the wallet.exe already or not?

The reason you see that the blockchain is synchronized is because one (or more) of the nodes you are connected to say that you are up to date. Just because one node says you are does not mean that you are actually up to date.

Some nodes you are connected to may be running an old version of Monero, and these do not have the new elements of the blockchain stored. From their perspective, your node is fully synced (57 days ahead!). From everyone else on the current network, you still have some way to go.

You can start simplewallet/command-wallet-cli, but it will not have the information from the latest transactions. You should wait until is is completely synchronized with all of the nodes.


Impact of Range Proof Optimizations on M_O After beginning at 60kB, the M_0 (minimum penalty-free block size) proved problematic after the v4 fork (introduction of RingCT) led to increased transaction (and block) sizes. Following an initial recommendation of 240kB from JollyMort, further discussion and research on an ideal M_0 was conducted. 300kB was settled on as the new  M_0 in the v5 fork.

Is M_0 likely to be adjusted again in the future to account for future TX size reductions resulting from RCT range proof optimizations? If so would the most likely outcome be a proportional decrease in M_O based on the proportional decrease in transactions sizes resulting from those optimizations?

It could be argued that there's no need to re-adjust M_0 again as just reducing typical TX size would give us more margin and would further reduce the effect of TX size / block size ratio. However, do-not-relay fee could be adjusted at any time to keep the price/fiat at some reasonable level and deter irrational network use.

The more TX-es can fit in a block, the less likely we are to experience problems with dynamic block size as it can then be better fine-tuned by the miners to give smaller step increases.

Unlike Bitcoin which has a hard-coded max. block-size, with Monero the block-size is not a parameter but a state of the network negotiated by the participants. Users bribe the miners by offering the fee, and miners increase the block size if it's economical or reduce to match reduced TX demand. They actually earn the most if blocks are always 100%+ full so they'd also want to reduce the size if network is under-utilized.

If there's no TX-es in the mempool, miners are actually motivated to reduce the size to match usage because that would bring individual fees up and give them more total earnings. 60kB worth of TX-es at 60kB current median yields more than 60kB worth of TX-es at 120kB current median because in the latter, the fee/kB would be smaller. This is just because of dynamic fee calculation. Taking dynamic block size into account, anything over the median is even more economic than that base case until the point determined by the fees offered in the mempool.

M_0 is simply the lowest possible median, and if "background radiation" network usage will become such that at any given time the actual median block size will be bigger than M_0, then M_0 will become completely irrelevant forever! It's there just to ensure we don't get to some weird low-energy state where the cap would be so small that adding a single TX over the median becomes too hard to negotiate - like starting a cold engine. M_0 ensures it's always warm and ready to rumble.


How are the Monero ARMv7 CLI binaries built? My goal is to set up a full Aeon node on a Raspberry Pi 3. I have been trying to compile the rebased Aeon code on it. After numerous attempts from scratch, the problem I encounter is that it errors out each time at different percentage of the build process, which suggest to me that the cause is not related to software dependencies but the environment instead, such as memory, swap space and so on. It feels like the Raspberry Pi 3 is severly underpowered to successfully accomplish this. Are the downloadable ARMv7 Monero builds cross-compiled? Wonder how they do that.

Monero's build instruction suggests that the swap size needs to be increased:

sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=1024
sudo /etc/init.d/dphys-swapfile start

https://github.com/monero-project/monero#on-the-raspberry-pi


xmrMiner does not detect RX 580 gpus I'm new to xmr mining on Windows and yet to find some decent miners.

I'm trying xmrMiner but it only detects GTX  gpu on my pc.

I'm wondering how can I fix it?

Im not an expert about miners, but taking a quick look to xmrminer in github site, its says that its a CUDA-based miner for xmr. CUDA is the platform used by Nvidia cards, so dont expect it to work properly with your Rx.

Being said that, you have plenty of options about choosing a proper miner.

Do you have only amd or mixed amd-nvidia cards? you can try the new xmr-stak which will recognize both platforms (CUDA for Nvidia and Opencl for amd).
https://github.com/fireice-uk/xmr-stak/releases
If you are willing to try it, i recomend you to try both 2.0 and 2.1 releases, and use the one which gives you better results.

Also, there is claymore cryptonote miner, xmr-stak-amd, and others, but i think those are the most popular.

If you are using windows and will try the new xmr-stak, and dont want to use CPU for mining, make a batch file "xmr-stak.exe --noCPU". I hope this helps. Kind regards...