Are AMD cards easier to mine with than NVidia? Performance/cost/efficiency aside: are AMD/ATI/Radeon cards easier to set up than NVidia cards? I've been trying to start mining using ccminer on Linux with my Nvidia card and it has been a nightmare. Is it less frustrating with other cards?

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

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


How do I set the user agent in simplewallet? For using simplewallet in RPC mode. Also, are there any limitations in terms of length or characters that are not allowed?

To set the user agent, when you are launching simplewallet you want to do something like the following:

./simplewallet --wallet-file <filename> --password <password> --user-agent <user-agent> --rpc-bind-ip 127.0.0.1 --rpc-bind-port 18082

So you use the --user-agent flag.

At this time, I do not know the limitations of user agent characters/length.


How does MoneroClub work? How does MoneroClub work? Is there a trust system that can be used to compare traders? Is escrow available? How does the site make money?

How does MoneroClub work?

It basically is similiar to LocalBitcoins. However, MoneroClub works more like a bulletin board, where buyers and sellers can find, and subsequently contact, eachother. From MoneroClub's website:

MoneroClub is localized peer to peer (P2P) exchange platform for Monero (XMR).
Compared to typical exchanges, MoneroClub is decentralized. MoneroClub never has control of your transactions or funds. Instead, buyers and sellers work directly with each other.
We recommend local cash transactions as the best way to prevent fraud and scams that often occur with PayPal, Western Union, or credit card transactions. However, it is possible to arrange any payment type with your correspondence.
MoneroClub behaves similarly to a bulletin board. Buyers or sellers post advertisements describing the prices and quantities of XMR they desire to exchange, and interested parties can contact them directly to work out the details.
We provide fixed or flexible pricing using a custom MoneroIndex (+/- any%) which removes dependencies on centralized exchanges for price information.
Meet nice people in your region and let MoneroCommunity grow!

Is there a trust system that can be used to compare traders?

At first glance, there does not seem to be some kind of trust system in place. Therefore, it is advised to be cautious when doing trades. Especially with a new trader.

Is escrow available?

Given that is kind of a bulletin board, there seems no escrow available. However, the core-team members are usually open to acting as escrow. You can contact them via their emails, or on IRC (#monero on Freenode).

How does the site make money?

As far as I can see the site is basically a non-profit and was build to contribute to the Monero ecosystem.


Wordpress :: mining with user's CPU We are in 2020 and I was having a look at this post from 2018 which describes 3 WordPress plug-in we might use to mine Bitcoins through users CPU:

Simple Monero miner: needs subscription to https://coinhive.com/ (deprecated)
SpareChange: needs subscription to http://www.sparechange.io/ (deprecated)
Coin Auth: needs subscription to https://coinhive.com/ (deprecated)

So it looks like there is nothing I can do, I have to do it by myself.
Are there any open source libraries that allows you to add a .js file to the header of your website and mine Bitcoin in 2020?
Why have all the CoinHive services gone away? It looked like a legit way to make money to me, why they are all failed?

The viability of browser based CPU mining on Bitcoin is zero. Bitcoin is not even profitable to mine on dedicated CPUs or GPUs these days, let alone in a browser. Bitcoin mining requires specialized hardware to compete (ASICs).
Monero on the other hand has always favored general purpose compute (CPUs and GPUs), and back when CoinHive started, the PoW algorithm used was at least feasible to be mined in a browser (albeit with very low profitability). The algorithm has however changed since then to RandomX, which whilst it still preserves the favoring of general purpose compute, the RAM requirements make it infeasible to mine in a web browser.
In short, browser based mining Monero is over and Bitcoin mining on anything other than an ASIC is long since dead.


How do I connect monero-wallet-cli to a remote node? In the post What privacy or security trade offs are associated with not running your own full node? the privacy ramifications of connecting monero-wallet-cli to a remote node are discussed. However, I cannot find information on stackexchange about actually connecting to a remote node? What is the proper way to use, for example, node.moneroworld.com's node?

monero-wallet-cli supports a command line argument "daemon-address" that allows you to specify the host and port to use instead of the defaults. The argument value takes the form host:port.

So if you wanted to run monero-wallet-cli using a remote node being hosted by node.moneroworld.com, you would launch simplewallet with the following arguments:

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

You can see some of the code that deals with initialization and connecting to the daemon on the github:
https://github.com/monero-project/bitmonero/blob/master/src/simplewallet/simplewallet.cpp#L1215


How should I approach the issue that bans do not persist after ending the monerod process? I've been manually banning peers that are (a) clogging up my logs and (b) taking away space that would otherwise be used for legitimate in_peer connections (which I have limited for data usage reasons).  It is a little time consuming, but it's fine.  It does the job.

I didn't realize that closing monerod would discard that ban list.  My logs had been clearing up, and then I had to briefly shut down monerod.  Now I've got a sea of bad peers to manually ban again.

Is there a way to make the ban list persist?
If not within monerod, what might another (simple) strategy be to "preserve" that state?
Am I stuck having to write some script to detect IPs for auto-banning according to my rules? Perhaps by parsing the daemon log and sending a ban RPC command to the daemon?

I like the idea of learning new things, so if #3 is required, then so be it.  I just don't want to overcomplicate things if I don't have to.

1) Not that I know of.

2) & 3) One way would be to make use of the built-in monerod commands and a little scripting. E.g.

monerod bans | awk  'NR>2 {print $1}' > bans.txt

Gets a list of any currently banned IPs. After you have restarted monerod, you could then:

cat bans.txt | while read ip; do monerod ban "$ip"; done

Which will re-ban them all.

If you want to permanently ban them though, I would add them to your firewall instead. I.e. block via iptables rules.


I exchanged some BCC and LTC to my Monero GUI Wallet via Shapeshift, and my funds wont show I am fairly new to the Crypto Currency world and have some experience trading and exchanging various AltCoins to one another using different services and apps without any hiccup.

Last night, I decided to try and get some Monero created a Wallet using the GUI Wallet. I found the receive address and used shapeshift to send a little bit of BCC from my Coinomi wallet. I generated a payment ID ont he GUI wallet but was a little confused when I tried to start the transaction on Shapeshift and it said the payment ID had to be 64 characters long. I deleted the Payment ID and tried to send the payment anyway to see what would happen, and it started! The transaction actually went through and heres the blockchain link:

https://xmrchain.net/tx/d697954fdec0b71784064927997ea392804c80713209d24ef3610c511550ff84

I waited 20 minutes and the funds did not show up, and I figured the reason why was because i did not enter the Payment ID. Before trying to troubleshoot and figure out where my BCC went, I did not want to lose on the opportunity to get some Monero so I went ahead and started another transaction on Shapeshift, but this time with LTC and using the Integrated Address that was generated when I clicked the Generate Payment ID button in the GUI Wallet (leaving the Payment ID field blank again on Shapeshift because the one on the GUI wallet was not the required 64 characters long). The transaction went through once again and you can see here:

https://xmrchain.net/tx/1a9e11d04711bd7b07ac872637472e1533ea060a2565e6ae9a99cd11ebc25e12

The funds for both transactions did not show up for an hour, so I decided to sleep and check back in the morning. Here I am in the afternoon (PST) and I definitely figured I did something wrong because I still have a 0.0000 balance in the Wallet. I noticed that the GUI wallet is constantly show Synchronizing, so I tried the cli version and managed to get that to fully synchornize, but even that showed a 0.00000 balance. I am a noob to Monero and treated it like the other AltCoins I have used, and now I am out some money trying to dabble in Monero. What can I do to track down where these exchanged coins went and possibbly recover them? I have tried to do some troubleshooting within the cli version of the wallet to find myself even more lost. I did not find a support email or contact on the getmonero.org website, and could not get into the Slack community, so I turned to here. Hopefully someone can guide me in the right direction to recover those coins via return to my Coinomi wallet or properly get the exchanged value xmr in my MoneroWallet.

If needed I can provide the links of the completed transactions on shapeshift.

My MoneroWallet address is: 496tk5NN3nPLtycwuYnDnEP4coURKSxuvMjPDtMiMEmfbzAnvqFqaFNWMg6VZGxHTXGze6TzZrgS7TsLsKggGqoo94hryLb

TLDR: I exchanged some coins on Shapeshift to my Monero Wallet without a Payment ID and the funds did not show up. What can I do to track where they went and how can I recover them?

Both of the transactions above have now been mined and confirmed. If your wallet is synced you are now be able to see your balance. If not this answer will explain how you can validate receipt of Monero or you can use a block explorer and the cryptography described here

Most of today there has been a large backlog in unconfirmed transactions because of a surge of network activity. This is a temporary problem which will self correct thanks to the Monero dynamic blocksize limit


Multisignature - get one signed transaction, send another, use first signed transaction The nature of my problem is the following: I, side A, need to get a multisig transaction signed by side B to send it to side C later on, store that signed transaction (not broadcast it yet), then sign another transaction by me (side A) for side B, broadcast it and finally use my first signed transaction I got first to send it to side C.

Is it possible? I've read that every time new transaction is being signed there is a sync required for key image.

Question is: Does it make my scenario impossible to do?
I hope it doesn't...

Assuming those two transactions do not double spend each other, it's perfectly acceptable. If the second transaction double spends the first one (which hasn't been mined yet), then the first one will be rejected if it's broadcast to the network.

You can't sign twice with the same multisig data, but that does not prevent a signed transaction from being held for a while before being broadcast.


How can I configure a node for use by Monerujo? I am trying to run my own node for use by Monerujo to connect to, but I'm having a some trouble.

If I run the node like this:

./monerod --rpc-bind-ip 0.0.0.0 --rpc-bind-port 18090 --restricted-rpc --confirm-external-bind --rpc-login MYUSER:MYPASSWORD

Putting user and password in the node config page in Monerujo, it fails on testing the connection.
Putting no user and no password in the node config page in Monerujo, it fails on testing the connection with error: "FAILED AUTHENTICATION".

If I run the node with this:

./monerod --rpc-bind-ip 0.0.0.0 --rpc-bind-port 18090 --restricted-rpc --confirm-external-bind

Putting no user in the node config page of Monerujo, it returns the height on testing the connection. But it fails on updating transactions in my wallet with error: "Node connection failed! check username/password"

So I'm out of ideas, can someone help me please?

EDIT: I found out that the "Node connection failed! check username/password" occurred only with that specific wallet. I couldn't even show the secret of that wallets. I created a new wallet and the connection worked perfectly.

Thanks.

I imagine --restricted-rpc is part of the problem. Remove that and you should be fine.

Also, make sure your remote node is fully sync'ed and externally accessible.

Also, if you are going to use RPC login (e.g. running the daemon with --rpc-login user:pass), in Monerujo, the format of the node address needs to be user:pass@xx.xx.xx.xx:port.

Edit: latest version has these options separated.


Why does Monero use epee in the crypto module? Is there any obvious gain to using epee in the crypto module?

I don't know why this code is inside crypto instead of cryptonote:

  inline std::ostream &operator <<(std::ostream &o, const crypto::public_key &v) {
    epee::to_hex::formatted(o, epee::as_byte_span(v)); return o;
  }
  inline std::ostream &operator <<(std::ostream &o, const crypto::secret_key &v) {
    epee::to_hex::formatted(o, epee::as_byte_span(v)); return o;
  }
  inline std::ostream &operator <<(std::ostream &o, const crypto::key_derivation &v) {
    epee::to_hex::formatted(o, epee::as_byte_span(v)); return o;
  }
  inline std::ostream &operator <<(std::ostream &o, const crypto::key_image &v) {
    epee::to_hex::formatted(o, epee::as_byte_span(v)); return o;
  }
  inline std::ostream &operator <<(std::ostream &o, const crypto::signature &v) {
    epee::to_hex::formatted(o, epee::as_byte_span(v)); return o;
  }

It is a way to convert data to hex, so why is this part of the crypto module?

And maybe a template function can do the job:

template <typename T> std::ostream &operator <<(std::ostream &o, T &v) {
  epee::to_hex::formatted(o, epee::as_byte_span(v)); return o;
}

As we know public_key and private_key are parts of cryptonote not crypto. So why should this code be put into the crypto module?

To my understanding, the crypto module only cares about hashing. Am I wrong?

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

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

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


Has Monero published a definitive, concise threat model? I2P's threat model consolidates various aspects of garlic/onion threat modeling into one document. Does Monero have a similar document and, if so, where can this document be found?

There is none.

This is an excellent opportunity for a new contributor with knowledge of threat modelling :)


Location of merkleroot per block / block header Is it possible to acquire the merkleroot per block with rpc command or core command?

Why is the merkleroot not included in the block header in the cns003.txt?

I see the transaction hashes are included in some rpc responses so must I calculate merkleroot manually?

The merkle root hash is used when creating the block hash. This is in the block_header as returned from the daemon RPC method get_block.


Relationship between pseudoOuts and Real outputs For each real input, we have a pseduoOut which is commitment to the same amount as the real input. We can therefore subtract the realInputCommitment from the pseudoOut and prove that it is a commitment to zero by signing for it in a ring signature.

Once I do this for each input, how do I then prove that the sum of inputs is equal to the sum of outputs? If I understood correctly, the pseudoOuts are an intermediate step.

Page49 of zero to monero shows a formula whereby: Sum of PseudoOuts = sumOuts + fees * H

This seems to imply that we must choose the blinding factors in the pseduoOuts in such a way that the sum cancels out with the sum of the blinding factors in the real outputs plus fee*H?

This seems to imply that we must choose the blinding factors in the pseduoOuts in such a way that the sum cancels out with the sum of the blinding factors

And that's what happens. The blinding factors chosen are random numbers [source] for all but the last input. Then the last inputs is calculated so that the sum of all inputs is the same as the sum of the outputs [source].


What are the differences between the slow hash, fast hash, and tree hash on the monero github? Additionally, if I wanted to put together my own implementation of the Monero CryptoNight PoW, specifically for mining, and was using one of those (with the corresponding tests on GitHub) to validate my implementation, which one should I use?  Would it matter?  I ask because after using the slow hash, it produces the correct output for the given slow hash tests but it doesn't produce the correct output for the given fast hash tests.

cn_slow_hash is CryptoNight. cn_fast_hash is Keccak. As the names imply, the former is much slower than the latter. Both hash a contiguous buffer. Cryptonight is used for PoW and KDF, while Keccak is used for everything else.

tree_hash is a merkle tree hasher: it works on a binary tree of hashes, and uses cn_fast_hash for the actual buffer hashing.


Can Monero's privacy features be integrated into (copied) by bitcoin? Can Monero's privacy features be integrated into (copied) by bitcoin? If so,  to what degree given the current political gridlock?

By the way, I'm a true believer and I'm setting up a full node as I type this. I'm also buying a monster GPU to up the hashrate and increase the security.

The simple answer would be no. The codebases simply aren't in any way similar. Bitcoin devs would need to do a massive rewrite of the code to implement ring sigs with confidential transactions, it would require a hardfork and would likely break functionality with code outside of Bitcoin such as wallets and such.

The longer answer would be maybe. It could possibly be integrated as a sidechain, but even then, it would not be as private as Monero's implementation as it would not protect fungibility on the Bitcoin blockchain, so chainalysis would still be possible, albeit harder. Given that, it would likely be a huge amount of effort for little gain.


My Ledger Monero wallet shows an incoming transaction with a value of zero (0), how do I resolve this issue? I withdrew some funds from an exchange to my Ledger Monero wallet. However, the incoming has a value of zero (0). How can I resolve this issue?

This bug is caused by the GUI wallet, if used in conjunction with Ledger Monero App v1.1.3 (or lower), not being able to properly decode the amount. Fortunately, however, the following fix can be used to resolve your issue:

In case you are using the GUI:

Exit the GUI (make sure you are using GUI v0.14.1.0).
Make sure your Ledger Monero app is upgraded to v1.3.1
Make sure your Ledger Live firmware is upgraded to v1.6.0
Browse to the directory your wallet files are located (Documents\Monero<wallet-name> on Windows | home/<username>/Monero/<wallet-name> on Linux | Users/<username>/Monero/<wallet-name> Mac OS X).
Rename <wallet-name> (the file without extension) to <wallet-name>-old
Restart the GUI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.

In case you are using the CLI:

Exit monero-wallet-cli (make sure you are using CLI v0.14.1.0).
Make sure your Ledger Monero app is upgraded to v1.3.1
Make sure your Ledger Live firmware is upgraded to v1.6.0
Browse to the directory your wallet files are located (normally in the same folder as monero-wallet-cli)
Rename <wallet-name> (the file without extension) to <wallet-name>-old
Restart monero-wallet-cli. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.


Mining Monero with Pencil and Paper People have successfully performed SHA-256 hashing with pencil and paper

If I wanted to perform the CryptoNight PoW by hand how would I do so?
Are there any PoW instructions that a human with a pencil, paper and enough patience could follow? What about with the assistance of a basic hand held calculator?

I think the overall answer is "it's ridiculously impractical to perform by hand". The Cryptonight hash operates over a 2 megabyte data space, using multiple rounds of AES along with a variety of other cryptographic hash algorithms. What human is going to have the patience to write out 2 million bytes of data even once, let alone multiple times?

I would downvote this question as being utterly ludicrous. Some of it is blindingly obvious:

E.g. "How much harder is hashing CryptoNight by hand compared to hashing SHA-256 by hand?" - The ratio of difficulty for CryptoNight vs SHA-256 is the same, whether calculating by hand or by computer. The difference in amount of computations is the same either way. This is a stupid question.

A valid question would be "where can I find a description of the CryptoNight hash algorithm".


Are [solo] mining yield calculations like dice or playing card calculations? If I want to know how many times I need to roll a die in order to have a given chance of seeing at least one six, I can use the formula:

n = (log(1 - s))/(log(1 - p))

where n is the required number of rolls, s is the desired probability of rolling at least one six, and p is the probablity on each roll. It tells me that I must roll the die 26 times if I want a 99% chance of seeing at least one six. As applied to playing cards (where p is 1/52 rather than 1/6), the same formula tells me that I would have to pick a card randomly from 237 packs if I want a 99% chance of seeing at least one Ace of Spades.

My question is: Does this formula apply to mining yields? For instance, if the network hash rate is H and my local hash rate is h, would I have to mine for the time taken for (log(1 - 0.99))/(log(1-(h/H))) blocks if I want a 99% chance of receiving the reward for at least one of them?

Yes, kind of. Your model is an idealized representation of mining, and works with one exception. The network has a certain degree of latency between nodes, and as a result miners do not know immediately when another miners finds a block, but rather have to wait something like 1-10 seconds before learning about a new block. Now, at first glance,this might not seem like a big deal because everyone has this issue. But the reality is that network latency results in bigger miners winning a slightly higher share of blocks than their hashrate would suggest, and smaller miners get less. This is due to the fact that a miner effectively gets a head start on the next block after mining a block, and bigger miners therefore get more of these headstart a, gaining a slight advantage. The smaller one's hashrate is, the more exacerbated this effect becomes. I don't know of a foolproof way of representing this effect, though. A good starting point might be to say that a small miners is only 90-95% efficient, but such a factor would have to be empirically tuned to be as accurate as possible.


About the actual implementation of the **mix-ins** construction process Following problems occur to me during my reading codebase of the current monero project,

Are the mix-ins grabbed through wallet2::get_outs function in the wallet side, which is further delegated to the core_rpc_server::on_get_output_histogram and core_rpc_server::on_get_outs_bin interfaces in the daemon side by means of rpc call?

If YES, when is the double spending checked during the execution of wallet2::get_outs?
If NO, which function is responsible of the mix-ins generation?

Will the double spending be checked during the mix-ins procedure? If yes, by who?

Really appreciate if someone can share something about the questions~

Yes, get_outs does mixin selection. There is no double spending check done there.
The second question looks like the same as the first one. There is no double spending check done during the mixin selection procedure.


What are Borromean signatures? For more background info visit GitHub or Bitcointalk

It looks like borromean signatures are going to be replacing schnorr signatures in the RingCT hardfork. What does this mean for Monero and RingCT performance etc? thanks

I happened to have read Greg Maxwell's paper recently, so here I try to lay down my interpretation in a bit abstract manner:

Before talking about the Borromean scheme, let us recapitulate the current ring signature scheme described in MRL-0005.
The signature data looks like:

R = (M, {P_1,...,P_n}, c_1, {r_1,...,r_n})

where M is some message's hash, each P_i is a pubkey in the ring, and c_1 and r_i are scalars (the key image part is omitted here for brevity).
Any participant in the network verifies this signature as follows:

L_1 = c_1 P + r_1 G
c_2 = H(M, L_1)               // H(...) is a hash function
...
L_i = c_i P + r_i G
c_{i+1} = H(M, L_i)
...
L_n = c_n P + r_n G

Finally, the signature is confirmed as valid if c_1 = H(M, L_n).
I skip explaining how such a signature can be generated only by a true signer knowing the secret key x of one of the pubkeys P_s = xG for some secret index 1<=s<=n.

A transaction generally has multiple inputs, say m inputs, so you create a ring signature for each input:

R^j = (M, {P_1^j,...,P_n^j}, c_1^j, {r_1^j,...,r_n^j})

for j=1,...,m.
Note that the signature contains m*(n+1) scalars of c's and r's.
Note also that such a concatenation of multiple ring signatures is needed for RingCT when proving that a given committed amount is within a certain range (called range proof).

The goal of the Borromean ring signature scheme is to reduce the signature size by making all c_1^j's identical:

c_1^1 = c_1^2 = ... = c_1^m
      = c_1

so that the number of scalars stored in the signature becomes m*n+1.

To achieve this goal, the scheme modifies the verification rule a little bit.
As before, the verifier computes for each j=1,...,m:

c_1 -> L_1^j -> c_2^j -> ... -> c_n^j -> L_n^j

and the signature is confirmed valid if the following holds:

c_1 = H(M, L_n^1, ..., L_n^m)

The signature generation can be implemented by adding some small modifications to the original scheme (I believe).


How the sender recover the transactions that he spent? In order to compute the balance of his own wallet, (I assume that) a client needs to retrieve:

1- The transaction that he is the receiver.(By scanning the whole block-chain and compare with his own view-key).

2- To reduce from 1, the transactions that he already spent.

According to 2, does he needs to keep the secret rs that he used to compute the stealth address of the the recipients?

What if he lost those secret values? (The only solution that is to see whether the transactions that he spent already spent in other transactions- but unfortunately I'm not sure it still possible to distinguish if that transaction were a decoy or not)

The user can recover the dates and amounts of the transactions they have made, but not the destination wallet addresses of any of those transactions or any encrypted payment id. They would be able to see any old style 256-bit payment id, because those old style transaction ids are not encrypted on the blockchain. The new style 64 bit payment ids (as used in integrated addresses) would be encrypted.

The spent outputs can be discovered because the user can use their private spend key to determine the 'key images' of all of their received outputs. Key images are published with every transaction, so they can scan the blockchain to determine which of their outputs have been spent. Therefore they can subtract the amount of that spent output from their wallet balance. They know the amount of that output for the same reason they knew it when they first received it. That reason is that it's communicated to them in the ecdhInfo part of the transaction, and encrypted using the transaction shared secret so that only they can decrypt it using their private view key.

The outgoing transaction payment ids cannot be recovered because they would have been encrypted with the transaction shared secret. As the sender, they would have needed to retain the transaction private key to know the transaction shared secret.

In algebra, the sender knows the shared secret as Hs(rA), and the recipient knows the same shared secret as Hs(aR). This is why the sender cannot recover the shared secret later. The sender would have needed to know both the transaction private key r and the recipient's public view key A in order to recover the transaction shared secret.


Error when trying to reach own remote node I've created a node on a VPS server. I run the node this way:

monerod --rpc-bind-ip <IP_SERVER> --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind --detach --data-dir=/mnt/volume1

But when I try to get the status I get this message:

monerod --rpc-bind-ip <IP_SERVER> --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind --detach --data-dir=/mnt/volume1 status

Error: Couldn't connect to daemon: <IP_SERVER>:18089
Height: 1478406/1478406 (100.0%) on mainnet, mining info unavailable, net hash 561.65 MH/s, v6, up to date, 8(out)+28(in) connections, uptime 4d 0h 37m 23s

What does this mean? How can I solve this?

status uses a few RPC to the daemon, and one of them (asking for mining status) is restricted. Calling it errors out since you used --restricted-rpc, and you see it tells you "mining info unavailable".

If you want to get access to the server's mining info, remove --restricted-rpc (but then anyone else can get that info from your server). In that case you probably want to connect through a ssh tunnel, or set a password.


Unable to import outputs I'm following the instructions on here https://monero.stackexchange.com/a/2916 to set up a cold and hot wallet. In the hot wallet I ran export_outputs outs which successfully generated the with the outputs. After moving the file outs to my cold device I ran import_outputs outs in the cold wallet. I get the error message Error: Bad output export file magic in outs.

Am I doing something terribly wrong or is there a bug?

EDIT:
On the hot wallet I was using a dynamically linked executable I built from the source on github but on the cold wallet I was using the officially built statically linked executable. When I switched to the official build on the hot wallet as well it worked! Is this behavior intended?

There was a portability issue with the wallet (i.e., the wallet cache file, exported outputs, unsigned/singed transfers) which was fixed only after the release of the 0.10.1 binary, see pull requests #1462 and #1515.

What happened in your scenario is that the outputs exported from the recent master build are in the new portable file format and thus cannot be read by the release 10.1 binary which uses the old unportable file format. Output files exported using the 10.1 binary can be read from your cold wallet that uses the same 10.1 binary.


I forgot to upgrade (from CLI or GUI v0.13 to CLI or GUI v0.14) and, as a result, accidentally synced to the wrong (alternative) chain I forgot to upgrade (from CLI or GUI v0.13 to CLI or GUI v0.14) and, as a result, accidentally synced to the wrong (alternative) chain. How do I resolve this issue?

With the most recent version, this particular issue is, fortunately, trivially fixed as follows:

GUI

Exit the GUI by clicking on the x (right top) and subsequently making sure to stop the daemon as well.
Upgrade to GUI v0.14.0.0 -> https://www.reddit.com/r/Monero/comments/ayshug/gui_v01400_boron_butterfly_released/
Start the "new" GUI (v0.14.0.0) and let it start the daemon.
The GUI (v0.14.0.0) should now automatically resolve your issue + perform a database conversion. However, this may take quite some time. Therefore, I'd advise to let it run overnight. Note that the GUI may state that it cannot connect to the daemon. You can safely ignore this message though and let the GUI run.
If you also made a transaction on the wrong (alternative) chain, proceed with this guide:

I forgot to upgrade (from CLI or GUI v0.13 to CLI or GUI v0.14) and created / performed a transaction on the wrong (alternative) chain

CLI

Exit all Monero related processes by simply typing exit
Upgrade to CLI v0.14.0.2 -> https://github.com/monero-project/monero/releases/tag/v0.14.0.2
Start the "new" v0.14.0.2 monerod
The daemon (monerod - v0.14.0.2) should now automatically resolve your issue. However, this may take quite some time. Therefore, I'd advise to let it run overnight.
If you also made a transaction on the wrong (alternative) chain, proceed with this guide:

I forgot to upgrade (from CLI or GUI v0.13 to CLI or GUI v0.14) and created / performed a transaction on the wrong (alternative) chain


MyMonero is down again, how do I get my money out? MyMonero.com is once again down for maintenance.  Is there any way to get my funds out of my wallet, or are they permanently stuck there?

Yes, it's possible to get it out, although the process is a bit complicated, because MyMonero does not use the standard 25-word seeds.

Use https://xmr.llcoins.net to convert your MyMonero 13-word seed into a standard Monero public address, private view key and private send key.

This is very risky and requires that you trust the website.  If you don't (and you shouldn't), you'll want to either disconnect the Internet so it can't call home, or use the source and run it completely offline.

Install the Monero GUI client.
Initialize an existing wallet using the address & keys you extracted in step 1.
Configure the app to use a remote node, so you don't have to wait days to sync the full blockchain.  (This is safe, but may compromise your privacy to some extent; details here.)
Wait until connected and fully synchronized.  If you're having trouble, try the steps here.
Transfer the money out to a new wallet/exchange.
Profit!


Using monero-wallet-cli to do a transfer after version 0.14+ I know ring size is not required anymore so has the transfer command changed after the v0.14+ monero cli wallet update?

How do you send monero using the transfer command now with payment id?
Do you have to do anything else special with the transfer command after v0.14?

I know ring size is not required anymore so has the transfer command changed after the v0.14+ monero cli wallet update?

It's still required by the protocol but the wallet sets the ring-size to 11 without the need to specify in the transfer command. The command and it's parameters are unchanged (backwards compatible) however.

  How do you send monero using the transfer command now with payment id?
  Do you have to do anything else special with the transfer command after v0.14?

It works the same way as before.

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

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

You will however get a warning:

Unencrypted payment IDs are bad for privacy: ask the recipient to use subaddresses instead


unexpected error: Trezor returned failure: code=99, message=Firmware error Monero CLI Monero 'Boron Butterfly' (v0.14.1.2-release) with Trezor model T
Trezor Firmware: 2.1.4 / Bridge 2.0.27

I was really happy with CLI trezor wallet but unfortunately it seems I cannot transfer funds:

-monerod running synced, open cli, refresh wallet
-use the transfer   command.
-as expected the cli indicates "device requires attention"
-confirm on device. Device indicates "generating outputs 2/2" etc as expected
-CLI throws the error

In this case I'm sending to a new generated address in the same account.
Regular wallets (no HW) don't have the issue.
It's latest version of cli. Trezor has newer version but nothing in the changelog mentions monero.

How to solve?

According to Trezor's CTO, the issue has been fixed in firmware v2.1.7:

  This is already fixed. Install firmware 2.1.7 from https://beta-wallet.trezor.io

Source: https://www.reddit.com/r/Monero/comments/dm0zqx/trezor_transaction_failure_code99_message/f4wia95/


What does it mean when the Monero daemon says "LMDB Mapsize increased"? I had an old daemon open and it was giving me the various SYNCHRONIZED OK messages that I was used to. Suddenly it said "LMDB Mapsize increased.  Old: 13312MiB, New: 14336MiB". What does this mean?

For performance reasons, LMDB asks the OS to preallocate its storage space in large chunks, instead of growing incrementally as new records are added. Periodically this space must be increased as the actual usage increases.


monerod block height is 1,500,000 - How do i pop off 100,000 blocks and start syncing at 1,400,000 instead? What is the monerod command to pop off a certain amount of blocks? Say I am at block 1.5 million and I want to start from 1.4 million instead. What is the monerod command for this?

The command you are searching for on linux called:

  ./monero-blockchain-import --pop-blocks 100000

and on windows you need to use

  monero-blockchain-import.exe --pop-blocks 100000

A detailed howto is on point 4 at this answer from dEBRUYNE.


CryptoNight detail. Why this kind of multiplication? The Cryptonight description by the CryptoNote team states that

  The 8byte_mul function, however, uses only the first 8 bytes of each
  argument, which are interpreted as unsigned 64-bit little-endian
  integers and multiplied together. The result is converted into 16
  bytes, and finally the two 8-byte halves of the result are swapped.

I can't understand why this multiplication is computed this way. Why the protocol needs to run an 8 byte multiplication? Is it a hardware optimisation or is it something else I don't understand?

Choices made date back to the original goal of having a hash function that favored modern CPUs (vs GPU/ASIC/FPGAs). Requiring a scratchpad of 2MB fits nicely into a modern CPU L3 cache and thus the required read and writes from that cache are fast. The choice for the 64 bit multiply is again that the operation is fast on modern CPUs.

Of course, history has shown us that todays GPUs can work comfortably with the hashing algorithm, and with enough effort (and money) even ASICs can be built to run as fast or faster - hence the recent tweaks to the algorithm which again, chose operations that are fast/easy on CPUs but harder to (re)implement in ASICs.


What happens to pool server if redis data is lost? I was looking at http://cryptonotemining.org/ and it looks really easy to set up. I'm wondering what the ramifications would be if redis lost some data? I'm not too worried about total data loss. But I am curious what would happen if a primary redis server failed and a read-only replica that was 10 minutes out of sync took over. Or if a standalone redis crashed and the checkpoint data was a few minutes behind.

The Redis database constains all the memory of miners' work and balances, found blocks, etc. So losing it would be a bad thing, though not extra bad.

Assuming everything got wiped at once, it'd be functionally identical to starting a new pool from scratch, except you already have miners connected and mining.

This means mainly three things:

the work history for the current block will be wiped, and only work submitted between the wipeout time and the next block found will be used (same as what happens when a block is found and work history resets)
miners' current balances get lost.
info on who to pay for any blocks found that are not yet unlocked is lost

Now, if you have a recent backup, the first one's probably not a big deal (unless you find a block just after that event, where submitted shares don't have time to re-approximate miners' real hash rates), and the second one's a bit annoying, but these are small amounts, typically below 0.2 monero. The third one is pretty bad though, as miners lose (their part of) the entire block.

Now, if the wipeout is not total, then other things can happen. For instance, if the wallet paid something, but this is not recorded, it will be paid again. This time, it's an error to the miners' benefit.


Is it possible to avoid Monero address re-use without having to create a new wallet for each transaction? I understand that currently, if an user wants to avoid re-using Monero addresses to avoid off-chain linkability (ie same address used for withdrawal from 2 exchanges and the exchanges releasing their logs to some entity), he has to create a new wallet for each transaction. This is cumbersome considering that for each wallet, entire blockchain needs to be scanned for outputs belonging to it,
Recently, a proposal which hopes to address this issue was presented on Reddit by user kenshi84. The idea describes a way to avoid Monero address re-use while maintaining normal performace when scanning the blockchian.

As previously discussed in StackExchange, exchanges can link withdrawal transactions if one uses the same receiving Monero address repeatedly, and it is recommended to create a one-time Monero address for each withdrawal to make sure no exchanges can ever link any withdrawals. Since such one-time Monero address generation can be tedious and error-prone, I came up with an idea of slightly modifying the protocol as follows:
Instead of telling the exchange the actual Monero address (A,B), a user (receiver) tells the exchange an integer k>0 and a one-time Monero address (C,D) where C=a^k A and D=a^k B. Note that it is impossible to link (A,B) to (C,D) using k without knowing the viewkey a. The exchange then generates the one-time stealth address using (C,D) as in the current protocol, but it also adds k to the transaction data along with R. The receiver can test if a given transaction output belongs to him or not by computing one-time Monero private view+spend keys (c,d) as c=a^{k+1} and d=a^k b. Address reuse can be avoided by making sure to use a new value for k associated with a that hasn't appeared in the blockchain.
Can this idea be useful?

Latter on in the comments he adds that this could be an improvement over HD wallets:

(...)I guess there's one advantage of this proposal over HD wallet though: when checking if a given tx output belongs to him or not, with HD wallet one needs to check against all the previously created Monero addresses (ie. linearly growing cost), whereas in this proposal one only needs to check against one address computed from k (ie. constant cost).

And also that this could be implemented just using the already available payment IDs:

(...)I think the additional task of generating unique k is quite similar to generating unique payment id. In fact, this proposal can be thought of as a replacement to the current payment id scheme, and k can be passed to the sender in the form of integrated address.

kenshi84's idea sounded extremely promising to me, so I would like to hear more about its viability.
I'm curious about the following aspects of the proposal:

What would be the benefit over a HD wallet scheme?
Would it affect the blockchain size if implemented?
Would there be any loss in privacy if such a scheme was to be used?
Would there be any risk to user funds?
Is a protocol change required for this to work or could it be done entirely wallet-side?
Are there any other points to consider?

Update May-2017: there has been some novel research into this, and it will be possible to tweak the sending wallet to allow sending to a special address acting as an "alias". The funds would go to the same wallet regardless of the number of these "alias" addresses used. The scheme makes it so that given an "alias" address, you can't work out the regular address or other aliases. Again, the actual records on the blockchain would never store any public address (be it regular, integrated, or alias), but the sender would generate a seemingly-random one-time destination address, as usual.

Read up on Github: https://github.com/monero-project/monero/pull/1753

I will attempt to answer the question while considering what had been discussed through other channels: Reddit, IRC/Slack Pt.1 & Pt.2

First of all, let's get the terminology straight to avoid confusing the similar terms.

Address / stealth-address: any Monero address is also a stealth address. This is because it never appears on the blockchain and is used only to calculate the one-time public key which is the destination of an output. Will be referred to as (A,B) where A is the public view key and B is the public spend key. Small-caps are the corresponding private keys.
One-time public key, referred to as P is the one time destination of an output. Generated from the stealth addres public keys and sender's random data.
Sub-address: I propose this term for the addresses created using the proposed scheme. It's another normal Monero address but generated in a special way so it can be derived from (a,b,k). It will be referred to as (C,D). It's worth highliting that any of them could be used as a stand-alone monero wallet if the keys (c,d) were to be imported.

  What would be the benefit over a HD wallet scheme?

The proposal boils down to having the recipient give to sender his (C,D,k) and the sender is expected to include the k in the transaction data when paying to (C,D). This way, the receiving wallet has to scan every one-time publick key on the blockchain only twice:

first time with the assumption that the payment was done to (A,B), using a
second time with the assumption that the tx data contains k, so it attempts to check if it belongs to a matching (C,D) by using c derived from (a,k)

Now, let's compare this against a HD wallet. It would have to check each output against every address belonging to it, so the refresh time would grow linearly with the number of addresses used. From this point of view, there is a clear benefit of the proposed sub-address sheme.

  Would it affect the blockchain size if implemented?

Yes, as it is required to store the k on the blockchain. It could be in the range between 1-32 bytes, depending on the details of implementation.

  Would there be any loss in privacy if such a scheme was to be used?

It depends. Let's consider some options:

Have k randomly generated and limit the size of it in a way that collisions are expected often. This would mean that there would be many transactions with the same k, but not neccessarrily belonging to the same user. Also, if it's generated randomly, distribution should be uniform. This allows for accidential or intentional re-use of the (C,D,k), which is not neccessarily a bad thing.

Consider we limit size of k to 1-byte. This would give each wallet 256 sub-addresses to work with. Once exausted, the user could start to re-use some old ones or archive the wallet and start using a new one. This way we have linear growth again, but slowed down 256 times, which may be just enough to preserve reasonable refresh time. Remember, the only reason HD wallets are inconvenient is the long refresh time it would take them.
Privacy would be preserved, but some loss of it would occur as we could assert that some transaction belongs to the group of users who decided to use the proposed scheme. In fact, we have the same kind of situation with payment ID now as some transactions have it and some don't.
If the protocol would enforce the k to be non-empty, then some random data could always be written in place of k when it would not be used, and it would completely preserve privacy while increasing the size of blockchain for a fixed amount / each tx. This way, every transaction would have a number 0-255 associated with it which would hint to the recipient which (c,d) to use.

Have the k randomly generated and of size big enough to avoid collisons. Also, re-use should be prohibited by the protocol.

In this case, collisions should be avoided entirely because if size of k is big enough. This is because it would be unlikely that 2 different users would happen to "roll" the same k, so one could assert that its more likely that any 2 transactions found on the blockchain belong to the same user because the (C,D,k) could have been re-used, accidentially or intentionally.
If we would enforce k to be unique, then any accidental collision would make the 2nd transaction fail to send if another one with the same k would get in a block first. The chance of this happening would be reduced with increasing the size of k.
Again, we have the potential loss of privacy if they're not enforced. Here, we'd increase the blockchain size more just because k has to be bigger for this option to work.

Also note that it may be better to opt for some deterministic scheme to generate k on the receiver end, like k=H(a,0..n). This way, the k would appear as random to the world, but the user would have a way to restore the list of (C,D)s issued in case he would lose the wallet file.

  Would there be any risk to user funds?

It would depend on the implementation adapted. Imagine that the sender, for whatever reason, just sends to (C,D) and omits the k in the transaction data or puts a wrong one. If size of k is small enough, the receiver could attempt a fall-back method to try every k for each one-time public key. This way, his refresh time would be 128 times longer than usual, but he'd have a chance at recovering the funds. If allowed size of k was too big, the funds would probably be irrecoverable in some cases. In case deterministic ks were to be used, I guess it would mitigate this risk as well.

  Is a protocol change required for this to work or could it be done entirely wallet-side?

Not required but it could be desired for some cases. If it was to be implemented using TX_EXTRA, then all it would need is to be supported by the sending and receiving wallets. Some new address scheme could be used to pass all the data (C,D,k) in one string to avoid accidents with omitting the k. Compatible wallets would be able to read this address, while others would just report an error.

  Are there any other points to consider?

There was talk about using payment ID as k and also consideration of using integratted addresses. Later it was realized that integrated addresses can't really work with this scheme as there is a chicken-egg problem involved in those :)
There are surely different ways to go about generating (c,d) from (a,b,k) so this could use some further examination.
There was a suggestion to look into bi-linear groups, but I can only mention it as I know nothing about this.
Further consideration would be needed to see how this would fit together with payment IDs. Also, k should be protected from pruning, if it's ever implemented.
Some other clumsy scenario with handling these kind of addresses?
Some neat crypto-magic which could help in solving this in the most elegant way?
What happens if we make a transaction sending to multiple addresses in the same tx?


Could MimbleWimble increase privacy in the Monero network? MimbleWimble needs a very minimal scripting language which Monero has, but doesn't use, and also takes advantage of Monero's RingCT. Is there anyway mimblewimble could run on top of Monero or in a sidechain maybe? Also would it help with scaling in anyway? Or is mimblewimble just not really very helpful in Monero whatsoever?

It's hard to answer such broad questions because answering it requires deep understanding of both technologies. But in general, throwing one thing on top of another doesn't necessarily make it better, especially if a desired feature is already present by some other means, as it is with Monero. Mimblewimble is interesting, but on its own.

It's a novel approach to a problem, but it doesn't feel like it could be compatible with what Monero is already doing in a diferent way. See here for some considerations.


Why is my Monero transaction not appearing in wallet? I have transferred Monero from an exchangeto my windows desktop wallet. I was having trouble receiving it and the synchronizations was stuck so i downloaded the new version.  It seems to have synched now. ("just says connected") but no coins received. I put the transaction id given by the exchange into the block explorer and have checked the receiving address on my wallet.  The transaction id confirms that it has been included in a block over 24 hours ago. why is the transaction not appearing in my wallet?  Is there a way to check if my wallet is synced properly and that i do in fact have the most recent version installed (i think i do). please advise as to the next course of action I should take.

UPDATE: I have realised that the wallet keeps alternating from saying "connected" (to my mind indicating that the blockchain is up-to-date) and actually going into synching.  So i guess if i leave it for long enough it will eventually sync.  However, this would indicate that every time i want to do a transaction i will have to wait several days for the coind to show up. This makes me think that something is not right with maybe the configuration fo my wallet or some other problem. Please could somebody shed some light on this situation for me.  When i checked on the wallet it has gobe from 35000 blocks remaining a few hours ago to something like 25000.  Is this behaviour normal for a monero wallet? it hasnt been that long since i opened it so i dont know why it is so far behind. Is there a quicker way to download the blockchain apart from waiting for days and days to make one transation?

The wallet needs to synchronize with blockchain. In Monero, where transactions are encrypted, it means the wallet must download all the data and try to decrypt every single transaction in order to check if it received any funds.

Every wallet remembers the blockchain height at which it was synchronized last time, and each time you open it, all following blocks are downloaded. You may choose between syncing often or waiting a long time when you sync seldom.

I'll also answer two questions that may arise:

When creating a new wallet, the code estimates creation time measured in block numbers that should have been mined until that moment (a block is being mined every ~2 minutes). Then it just requests those above the level.
When a wallet is being restored from keys or mnemonic, it must download, scan and discard entire blockchain. In such situation it's worth considering to download the blockchain to permanent storage and run full node.


Android wallet with Tor Is there a way to force all connections through Tor on any android wallet?
I tried Cake wallet with Orbot in VPN mode but I don't think it blocks connections without Tor if Orbot is off. I don't have Orbot on all the time.

There are no wallets I know of with an in-built Tor router. There would be no reason why any of the wallets don't work with Tor however, like making use of Orbot.
Of course, if you switch Orbot off, you wont be connecting through Tor.


Why is sc_reduce32 needed? I recently read a question about sc_reduce32 I stumbled on while investigating on Monero's Mnemonic Seed working. A great tool has been llcoins which states the following when talking about conversions between the Hexadecimal and Mnemonic seed:

  The "seeds" created by this method will always be valid scalars as they are sent to sc_reduce32 first.

MRL-0003 defines sc_reduce32 as:

  4.1.11 sc_reduce
  Takes a 64-byte integer and outputs the lowest 32 bytes modulo the prime q. This is not a CryptoNote-specific function, but comes from the standard ed25519 library.

  4.1.12 sc_reduce32
  Takes a 32-byte integer and outputs the integer modulo q. Same code as above, except skipping the 64→32 byte step.

My question can be split in two:

Why does the first statement imply that without sc_reduce32, the hexadecimal seed would potentially be an invalid scalar?
How is sc_reduce and sc_reduce32's prime q chosen? When looking at crypto_ops::generate_keys I have the feeling that it can be a random scalar, not even prime.

The paper is incorrect; it's actually mod l, not q. l is the curve order of ed25519. The primary reason AFAIK is that the code doesn't work correctly with scalars above a certain multiple of l. The random_scalar() function outputs an integer


Cryptonote bug question Assume someone is exploiting DigitalNote, Dashcoin, or Bytecoin.  Apparently, they could issue large amounts of those coins to manipulate that individual coin value.  But what keeps them from exchanging this fictional value for other cryptos, and thus creating fictional demand for Monero and other coins?  Also, do we know if these other cryptonote coins HAVE been exploited, yet?  Should we be exploring attack-vectors from even state level attackers who might exploit one broken coin to devalue others?

Bytecoin was exploited shortly after its developers were privately notified of the bug. Most reasonable conclusion is the Bytecoin devs themselves performed the exploit. https://twitter.com/fluffyponyza/status/865619303651053568


Can Monero miners be picky about adding transactions to blocks With Bitcoin, miners are picky about which transactions to add to blocks due to the limited block size, opting for transactions with higher fees (larger transactions). This means micro/nano payments take a long time (if at all) to process on the bitcoin blockchain.

Can this happen on Monero ? Is there anything there to disincentivize mining nano/micro payments? I’m aware that the block size grows and that miners only know the range of the transaction amount but is this enough when monero scales up like bitcoin has?

Partially.

Miners can't know who send how much to who. What miners do know is the fee associated to the transaction. One way miners can "select" transactions would be to prioritise higher fees, which is actually how a lot of cryptocurrencies work.

What miners can't do is prioritise transactions, on their own, to/from addresses. They would only be able to do so if the transaction maker gave them the tx-id.

  With Bitcoin, miners are picky about which transactions to add to blocks due to the limited block size

This won't happen on the long-term with Monero due to the Dynamic Block Size which specifically prevents a Bitcoin situation from occurring.


i send my monero without payment id about 1hours 30min ago i sent my monero from bter.com to bittrex.
but i didn't wrote my payment id. bittrex say that i have to wait about 2 weeks
but i am very urgent my money.

can i get some help?
my txid is 80dde5fc0b62cfa8294ab511f76b005e85473e22d8e365ab5d6848f32ce102dd
and amount is 34.2189

and bittrex wallet address is 830666 463tWEBn5XZJSxLU6uLQnQ2iY9xuNcDbjLSjkn3XAXHCbLrTTErJrBWYgHJQyrCwkNgYvyV3z8zctJLPCZy24jvb3NiTcTJ

If you already sent it, you should just wait it out. As long as it's not lost. For faster transactions, you can raise the priority for a higher fee.


failed to deserialize extra field I've started simplewallet together with bitmonerod and looking into simplewallet.log file I can see something like this:

2016-Sep-08 12:01:29.853608 [RPC0]Transaction extra has unsupported format: <c24dcecfe0ad013293600321caf59e22582f87c180264d592a02bb2d5edb7b42>
2016-Sep-08 12:01:29.857208 [RPC0]failed to deserialize extra field. extra = 0108b69d5bfdade32af5c14910f637fb72039cd9bec2353367f3ecd8958ac69d130221009a40d25b6c84e7993aed986da4d428eb33b050ccc40aba4f53dec3c779b92955de208af73ef76e6b9799f12d4883177198e75cb45ba694def49c036a1cadb965ebca

There is more entries like this in log file.
Can someone explain what does it mean?

I'm running 'Hydrogen Helix' (v0.9.4.0-release) in screen.

According to moneromooo-monero, it may be that someone is adding invalid TX extra by using a custom software, on purpose or by error. Therefore when the usual daemon receive the transaction, it is not possible to decode the value.

I'm guessing someone hacked the tx_extra code, or is using an entirely new tx_extra generator. These have a pubkey field, but either garbage after it, or too much data in it, so the rest of the parsing gets out of sync.
I use hack in the original sense, like I hack on monero

This is not dangerous so the level of warning have been downgraded in PR #831. The problem have then been solved by adding a new type of extra TX ("tx_extra_mysterious_minergate") in PR #856.
The fix have been merged on Jun 19 so it not present in v0.9.4 but will be in v0.10.0.


installing Aeon on Ubuntu I'm trying to install Aeon on ubuntu following this post.

everything is fine until I try to use the "make" command. Then I keep getting an error for which I have no idea how to fix it:

mkdir -p build/release
cd build/release && cmake -D CMAKE_BUILD_TYPE=Release ../..
-- Boost version: 1.54.0
-- Found the following Boost libraries:
--   system
--   filesystem
--   thread
--   date_time
--   chrono
--   regex
--   serialization
--   program_options
CMake Error at CMakeLists.txt:108 (message):
  Boost version 1.54 is unsupported, more details are available here
  http://goo.gl/RrCFmA

-- Found Git: /usr/bin/git
-- Configuring incomplete, errors occurred!

Any clue?

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

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


Does Mimblewimble have any relevance to new pruning ideas for Monero? This Mimblewimble paper was introduced last month by Tom Elvis Jedusor.

It appears that the system will not work with Bitcoin (on chain)

  The first thing we need to do is remove Bitcoin Script. This is sad, but it is too
  powerful so it is impossible to merge transactions using general scripts.

The system would provide inferior privacy to RingCT because RingCT provides untraceability that CoinJoin and CT cannot. Are there any pruning concepts from Mimblewimble that could benefit Monero? If so how would those potential savings in compare to the type of database pruning already in production with Aeon?

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

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

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


Examples of real stealth address from the blockchain I am looking for examples of stealth addresses. Not only theoretically what they are, but real examples. What do they look like in the blockchain?

Here's one example: 47c99dab149170154cf1cdfb7e6a5993e1683e9d952aa0502b7b9f27f4129735

This is the public key for the first output in tx http://moneroblocks.info/tx/e706b52d74f74da37f0c016b976ede566fabf106c344a0fe1fb18cdb3751b0f6, the last tx made as of now.

I won't give the private key to it, both because I don't know it, and because it'd allow you to spend it :) But it'd look like a private key, which is, very much like the above (but modulo l).


Are mining pools necessary? I have a free tier AWS t2.micro that I use for development purposes. It sits idle most of the time. I figured I would just put it to use, and after some time, I settled on mining Monero, as I can do it with a CPU. My question is this: Are mining pools really necessary? I feel like if you get a payout, the pool splits the payout into a huge amount of users. Is it beneficial to use one or am I better off mining individually?

You have to choose between having a little chance to find your own block with a high reward if you mine on your own, or having a high chance of finding a block but with a low reward as it is shared if you mine in a pool.

This being said, if your objective is to make "profit" I would use a pool.


How are Monero seed nodes selected? As far as I understand Monero uses a number of seed nodes to bootstrap new nodes entering the network. And I gather from this question that the address of those nodes are discovered by resolving some fixed DNS names. However, I was wondering how the actual nodes are chosen? Is it just a list of fixed addresses (and if so, who picked them)?

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


How does Ring Confidential Transactions work? Can someone explain to me how RingCT works and how the recipient gets the actual amount from the encrypted amount in a RingCT transaction?

All outputs on the Monero blockchain have encrypted amounts, with the exception of outputs created in a 'coinbase' transaction. A coinbase transaction is a transaction that creates new Monero out of thin air according to Monero's emission schedule. Here is an example coinbase transaction: https://xmrchain.net/tx/c0b6b35c1a9c580aaa5ba04db6477cb255b33abb6492f9b5d6e02d7768aefcee

The amount of each output is encrypted and written into the transaction in two different ways. Once, as part of the 'ecdhInfo' in a way that allows only the recipient to decode the actual value, and  a second time as a 'Pedersen commitment'.

Only the recipient of an output is able to decode the actual amount. This amount is encrypted by the sender using the transaction shared secret, and is transmitted to the recipient in the 'ecdhInfo' section of the transaction. The transaction shared secret is computed by combining the recipient's private view key with the transaction public key (the latter is transmitted as part of the transaction).

Third party observers will not be able to decrypt that amount, and will need to use the Pedersen commitments to verify that other than the allowed creation of new Monero as part of the emission schedule, no Monero has been created out of thin air.

RingCT achieves this by doing two things:

Proving that all of a transaction's outputs are greater than zero. This prevents the sender from starting with 1 XMR, and then creating two outputs where one has a value of -99 XMR and the other has a value of 100 XMR. This is achieved with a 'range proof'. A range proof proves that the encrypted amount must have been created out of the addition of a series of positive powers of 2, without disclosing what the actual powers of 2 are. For more information, see https://people.xiph.org/~greg/confidential_values.txt
As you probably know, there are real inputs and fake inputs referenced in each transaction. No third party can tell which are real and which are fake. RingCT proves that in at least one combination of the possible inputs and the outputs, that Pedersen commitments of the inputs - Pedersen commitment of the transaction fee - Pedersen commitments of the outputs = a zero Perdersen commitment.

This is possible because input and output amounts are encrypted using 'homomorphic' Pedersen commitments, meaning that although you can't tell the values, you can verify that they sum to zero. Proving that they sum to zero is achieved by proving that you know the private key of the 'zero' Pedersen commitment for at least one of the combinations of possible inputs and outputs.

Therefore, for a transaction of ring size 5, as an outside observer you'll come up with 5 different possible 'zero Pedersen commitments', where only one of those possibilities really will be a commitment to zero. Since the Pedersen commitments are all technically public keys, and since the sender of the transaction needs to prove that they know the private key for at least one of those combinations (thus proving one of the combinations really does sum to zero), this is an ideal task for a ring signature. This is because ring signatures are a device to prove that out of a set of public keys, you know the private key for at least one of them.

The full math is here: https://lab.getmonero.org/pubs/MRL-0005.pdf

To sum up, RingCT is a mechanism that allows an outside observer to check that in at least one combination of inputs and outputs, no Monero has been created out of thin air. This mechanism is impossible to cheat.


How is the Monero wallet picking outputs for transactions to spend? It seems like there are a lot of things to take into account for which outputs in a wallet to spend to preserve privacy. Preventing temporal alignments etc. Is there a lot of code for picking? How does it work?

There is a lot of code indeed.

Since you mention temporal alignment, I assume you mean selection of the real outputs (as opposed to fake ones). The code is in src/wallet/wallet2.cpp, and the interesting functions are:

get_output_relatedness: this returns a score for how much two outputs are thought to be related (ie, same tx, from similar heights...)
pop_best_value_from: this will pick a new output, trying to keep to outputs which aren't related to ones we already picked
create_transactions_2: this is the main function, and it creates the transaction(s)

There's an attempt to build a tx with one or two outputs. If this fails, random outputs (unrelated, if possible) will be selected until enough monero is gathered. If a single input is enough, a second one will be used too, if an unrelated one is available, and it will be the smallest (in terms of monero).

That's the general idea. See the code mentioned above for all the details.


JSON RPC with digest auth Is there anyone using Monero JSON RPC authentication?
I can only use curl with username:password to request the daemon RPC. But I cannot do the request with nodejs.
Anyone tried with nodejs successfully with digest auth?

I've got a working JSON RPC wrapper with digest auth working in https://github.com/sneurlax/moneronodejs (merging into https://github.com/monero-integrations/moneronodejs, I hope.)  Here's the relevant code:

lib/walletRPC.js

  var request = require('request-promise');

  ...

  _run(method, params) {
    let options = {
      forever: true,
      json: {'jsonrpc': '2.0', 'id': '0', 'method': method}
      auth: {
        'user': 'rpcuser',
        'pass': 'rpcpass',
        'sendImmediately': false
      },
      params: params
    };

    return request.post(`http://127.0.0.1:28083/json_rpc`, options)
    .then((result) => {
      return result;
    });
  }

EDIT: also, in my library I have to call a throwaway get_balance() ... the first call always fails for me, but subsequent calls work fine.


Ability to choose your own transaction fee When using simplewallet and bitmonerod transaction fees are calculated based on the mixin and outputs being used in a transaction.

During times where network usage is high, is there an ability to choose a larger transaction fee than the fee automatically calculated for me?

If the answer is yes, does choosing a higher fee provide me with a highly level on transaction confirmation priority from Monero miners?

You can select a higher fee if you want. This choice is intentionally limited to a 1x, 2x, and 3x multiplier to avoid leaking too much information via the fee (ie, if you're the only one using a 2.7x fee, your transactions will stick out).

NOTE: from two weeks after the v3 fork, the fees multipliers will change from 1/2/3 to 1/20/166. The simplewallet setting blow is renamed from fee-multiplier to priority, so 1/2/3 are still used in simplewallet, but do not express actual multipliers anymore. The base fee will also decrease by 5 times at the same time.

This behavior is a global setting in simplewallet, and can be changed with: set fee-multiplier 1 to reset to default, same with 2 and 3.

Miners will select transactions based on decreasing fee per byte, so transactions with a higher fee multiplier will get priority over transactions with lower fee multipliers.

As J Dog says, a glut of transactions in the pool cannot be expected to last long term, as the block size will increase to meet demand.


Do coinbase transactions use stealth addresses? When miners are awarded a block reward my understanding is that it occurs using a "Coinbase transaction" do Coinbase transactions send Monero to the Miners public address directly or do they use stealth addresses? i understand they dont use RingCT and use 0 Mixin ring signatures.

moneropedia

  Stealth addresses are an important part of Monero's inherent privacy. They allow and require the sender to create random one-time addresses for every transaction on behalf of the recipient.


Difference between Unlinkability and Untraceability Please provide a simple explanation that can distinguish Monero unlinkability and untraceability.

Is it possible for a cryptocurrency to have one (unlinkability or untraceability) without the other? Or is there a mutual reliance between the two?

With Monero, unlinkability means that you can display your receiving address publicly yet all payments made to this address cannot be linked to it.

This phenomenon is accomplished with the use of one time use stealth addresses for every single transaction.

Monero untraceability is provided by ring signatures each transaction uses multiple cryptographic signatures controlling multiple outputs to mix with the outputs of the sender. An observer cannot tell which outputs are controlled by which party providing untraceability (and plausible deniability) for everyone included in the ring signature.

It is possible to have unlinkability without untraceability. In fact there are many coins that offer one time use stealth addresses. Monero (and other CryptoNote currencies) are different because the use of stealth addresses is automatic and mandatory. If one time use addresses are not used every time, user
and network privacy is decreased. Monero makes it easy to obtain a high level of privacy by automating this process at the protocol level.

Ring signatures did not exist in any cryptocurrencies until it was introduced by CryptoNote. There are technologies that used mixing (CoinJoin) to make tracing Bitcoin (for example) transactions more difficult. However more difficult tracing is not the same as untraceable, particularly with the rise of companies offering blockchain analysis tools such as ChainAnalysis and BitCluster


How could Monero profit from TumbleMoneroWimble? Core developer fluffypony on Twitter recently published a link to his whitepaper on TumbleMoneroWimble, "One-time Ring Signature Scalable Off-Chain Untraceable Instant and MimbleWimble".

Since the use cases listed on page 52 are very interesting, could someone please explain the mechanism in easy words? Especially the instant transactions and micropayments would be very interesting and how can they still can be private.

The whitepaper is fake, never meant to be taken seriously.

Quoting @fluffypony's followup tweet:

  Don't take the 3 papers I tweeted as serious, I used the Koinster whitepaper generator for altcoin-quality papers: https://whitepaper.koinster.com/


Monero mining compiler error I am trying to compile monero on ubuntu 16 LTS, but i get the following compilation error (see screenshot), I am running the Linux machine in esxi hypervisor (virtual machine). It seems there is an issue with the assembler?

worked with the following
 ./configure CFLAGS="-march=native" --with-crypto --with-curl


How to go back to previous command when using monero cli? I'm on ubuntu 14 and installed monero v0.11.1 - I'm trying to press the up arrow to go to my previous command, but that doesn't work. How can I get this to work? Also I sometimes want to clear the entire line with CTRL-L but that dosn't work either. I'm just looking to get bash commands to work.

If readline commands aren't working, there are two possibilities:

you build without readline enabled (it's optional). Check libreadline-dev or equivalent package is installed (ie, the headers are usually missing when a basic package is installed on many distros)
you have a bad ~/.inputrc - much less likely, but try moving it out of the way if you've really built with readline enabled.


Not receiving stagenet XMR to cli-wallet I created a monero CLI wallet a few weeks ago with the --stagenet option:

./monero-wallet-cli --stagenet --generate-new-wallet ~/example_stagenet_wallet

I've now just connected it to the monero stagenet:

./monero-wallet-cli --daemon-address monero-stagenet.exan.tech:38081 --stagenet --wallet-file example_stagenet_wallet

I attempted to have some stagenet XMR sent to my address by going to this faucet and entering my address into the box. It said that it sent me 10 XMR with this Tx hash:

6ff1259db667622c8ac59faefed5a6d772af2b2042f1779580deee2cc1e6e5f4

However, over an hour later and with 32 confirmations, it's still is not showing in my wallet, even though it is showing up in the explorer. Whenever I type 'refresh' in the CLI wallet, I'm told Refresh done, blocks received: 0, suggesting it's not properly connected to the remote stagenet daemon at monero-stagenet.exan.tech:38081; however, when I start the wallet it does say Warning: using an untrusted daemon at monero-stagenet.exan.tech:38081 so it at least thinks it's connected to that daemon.

  Why is the XMR not showing in my wallet?

I'm totally new to monero and just learning the ropes, and would like to be able to send and receive XMR in this sandbox environment before doing it properly, so any help would be much appreciated!

Your transaction is apparently in stagenet block at height 565903, but the daemon you are using appears to be stuck back on height 558151 (at time of writing). Thus you need to use a daemon that is up-to-date.

Seeing as you are using the xmr.to explorer and faucet, perhaps use their stagenet daemon too: https://community.xmr.to/nodes.html.

E.g.

./monero-wallet-cli --daemon-address node.xmr.to:38081 --stagenet \
    --wallet-file example_stagenet_wallet


How many languages will the official GUI support? How many languages will the official GUI support at launch?

Were the translations done with help from native speakers or by Transifex?

7 mnemonic seed languages will be available for the GUI:

  +List of available languages for your wallet's seed:
    +0 : English
    +1 : Spanish
    +2 : German
    +3 : Italian
    +4 : Portuguese
    +5 : Russian
    +6 : Japanese

11 wallet "locales" are supported with 5 different languages:

+        <language display_name="US English" locale="en_US" wallet_language="English" flag="/lang/flags/usa.png" qs="none"/>
+        <language display_name="UK English" locale="en_GB" wallet_language="English" flag="/lang/flags/uk.png" qs="none"/>
+        <language display_name="Russia"     locale="ru_RU" wallet_language="Russian" flag="/lang/flags/russia.png" qs="none"/>
+        <language display_name="RPA"        locale="en_SA" wallet_language="English" flag="/lang/flags/rpa.png" qs="none"/>
+        <language display_name="Palestine"  locale="ar_PS" wallet_language="English" flag="/lang/flags/palestine.png" qs="none"/>
+        <language display_name="India"      locale="hi_IN" wallet_language="English" flag="/lang/flags/india.png" qs="none"/>
+        <language display_name="Italy"      locale="it_IT" wallet_language="Italian" flag="/lang/flags/italy.png" qs="none"/>
+        <language display_name="German"     locale="de_DE" wallet_language="German"  flag="/lang/flags/german.png" qs="none"/>
+        <language display_name="China"      locale="zh_CN" wallet_language="English" flag="/lang/flags/china.png" qs="none"/>
+        <language display_name="Brazil"     locale="pt_BR" wallet_language="Portuguese" flag="/lang/flags/brazil.png" qs="none"/>
+        <language display_name="Bangladesh" locale="en_US" wallet_language="English" flag="/lang/flags/bangladesh.png" qs="none"/>

Translations will be automatic with the support of QML which relies on the internationalization capabilities provided by Qt on which the new Monero GUI is being built.


(Non-ring) Wallet signatures I am reading about ECDSA and EdDSA. I was wondering what the Monero void  crypto_ops::generate_signature signature is based upon. From the code, I see that the math to generate one is

k = rand()
t3 = kB
buf = H(data) || pk || t3
c = Hs(buf)
r = k - c.sk

and the signature then is the tuple (c,r). This seems to take some ideas from standard ECDSA, but I would like to know what scheme exactly is used here.

The crypto_ops::generate_signature function is using the Schnorr signature scheme.


RingCT 3.0 in Monero Is there a plan to transfer Monero to RingCT 3.0 (https://eprint.iacr.org/2019/508.pdf)?
Is there any (test) implementation of RingCT 3.0 in computer code or at least parts of it?
The authors' arguments seem to me quite convincing.

Thanks in advance for your reply.

Is there a plan to transfer Monero to RingCT 3.0?

The Monero Research Lab are looking into RingCT 3, Lelantus and Omniring as I recall.

There would be no migration until a careful evaluation was complete, followed by an implementation developed and audited.

  Is there any (test) implementation of RingCT 3.0 in computer code or at least parts of it?

Only some MRL test code to my knowledge.


Wallet JSON RPC methods I need the following JSON RPC methods.

1. create new account (getnewaddress)
2. get balance by address/account (getbalance)
3. send balance to another address (sendfrom)
4. import/export privatekey (dumpprivkey, importprivkey)

Those methods mentioned in brackets are like bitcoind JSON RPC. Could you please let me know any JSON RPC for those purposes.

Thanks in advance

create_account
get_balance
transfer_split
query_key and create_wallet

See https://getmonero.org/resources/developer-guides/wallet-rpc.html for basic documentation.


Installation of Monero on Linux I have downloaded the tarball and extracted the contents, now how do I install this in Linux?

After extracting, you can either run the binaries directly from where you extracted them, or copy/move them to some other location (such as /usr/local/bin). Where you choose to install (i.e. copy/move), them is really up to you as the admin/user of your Linux box.

A nice overview of the binaries can be found at: https://monerodocs.org/interacting/overview/


Is there any security risk to using a nonrandom encrypted payment id? With plaintext payment ids, you should a random payment id. Using a nonrandom one can affect your and other parties privacy.

Is this still a risk with payment id? Or could you include messages in the payment id safely.

What if you reuse the same id?

Using a non-random plaintext ID doesn't hurt your privacy (unless you publish it somewhere to link it to yourself), but reusing the same plaintext ID significantly reduces your privacy.

There should be no issue reusing an encrypted ID (the plaintext version, as in the integrated address) in the context of the Monero blockchain (this answer does not address any out-of-band concerns, like assigning your customers incremental IDs where they can tell what order # they are, etc.).

The key is a "random" one-time-pad, so the randomness (or lack of) of the plaintext doesn't matter. Knowing the plaintext ID and seeing the encrypted ID (revealing the key, as it is simple XOR) provides no additional useful information, since the key is used only for that particular transaction.

Since they are only 64-bit (space-saving), collisions of the "ciphertext" are expected to occur after about 5 billion transactions (with IDs). A collision also provides no meaningful information.

8 bytes isn't much room to include a message, though.


Throttling/Adjusting Bandwidth in Conjunction with Bitmonerod When running bitmonerod and using the following bitmonerod bandwidth parameters, is the rate measured in bits or bytes?

limit_up Used within bitmonerod while running.
limit_down Used within bitmonerod while running.
--limit-rate-up  Command line argument for launching bitmonerod.
--limit-rate-down Command line argument for launching bitmonerod.

All of these are measured in kB (1024 bytes). See src/p2p/net_node.inl, in set_rate_up_limit.

The defaults are 2048 kB/s upload, and 8192 kB/s download. If those are near or above your connection's capabilities, you may want to lower them to a bit lower, to keep some QoS. Similarly if you have a fast connection, you might want to increase them.


What would happen to the Monero network if a significant part would be isolated? What would happen to Monero in case of a cataclismic event that would cause the American continents to be data-isolated (that is all data links severed) from Eurasia?

What would be the maximum time interval the network would survive for in case of such an event?

The isolated North American nodes would continue communicating, transacting, and mining among themselves. The world set of nodes would do the same.

At this point you have two possible chains. If communication is ever re-established the fork would resolve itself with the longest chain winning.

Depending on the time-span this could be catastrophic economically because one chain is basically going to be refunded. So if the North American chain fails, everyone that made purchases on that chain would have received goods and services, but then would get all their Monero back once the chain resolves.


How much money would be required to cloud mine 51% of the network hash rate? Cloud mining is generally a very expensive way to mine over the long run.

However if the goal was to mine only for one day and in attempt to 51% attack a network it might be cheaper than purchasing equipment.

Approximately how much money would be needed to lease enough cloud mining hashing power to 51% the Monero network for one day?

Assume for calculation purposes the current hash rate wss 21.1 Mh/s before the cloud mining attack began. Also assume that is would take at least one day for the network to respond (and increase its mining efforts) to counter an attack.

Assuming a current hashrate of 21.1 MH/s, an attacker would need a bit more than 21.1 MH/s to perform a 51% attack. This assumes that doubling the hashrate for a day doesn't drive miners out. According to Fluffypony's slides¹ from his presentation to a group of bankers at the Thales User Group², the rental price of 1 KH/s is approximately 13.11$. Thus, an attacker would need to spend 13.11 * 22,000 (this gives you approximately 51%, i.e., 22/43.1 = 51.04%) = 288,420 $ per day to perform a 51% attack on Monero.

However, it should be noted that, in practice, less than 51% could be needed to perform an attack. If I recall correctly something like 35-40% is already sufficient, in case of lucky variance. This would bring the cost per day down to approximately 200,000 $ - 225,000 $ a day. However, to sustain his attack, an attacker would need to constantly have >50%, because variance reduces over time.

Sources:

[1] https://cloud.getmonero.org/index.php/s/gFLjnZ40Oo14kY5 - Slide 27

[2] https://twitter.com/fluffyponyza/status/760078858867671041


There has just been a fork. Not everyone updated before or just after the fork. Difficulty adjustment algorithm not settled yet to reflect. Block times, as a result are not yet smoothed out to the ideal time of 2 minutes. It will settle, just be patient.


Monerujo Send Pword Reset? I can log into Monerujo just fine. I have no idea what my "Give" password is. I can access this wallet because i have fingerprint auth turned on. Is there anyway i can transfer funds from this wallet without knowing the password although i can login via fingerprint?

Typical passwords specified by endusers are used by Monerujo to unlock native monero-wallet-cli chacha8 encrypted files. I've not examined Monerujo CrAzYpass functionality that might be integrated with 2 factor authentication such as fingerprints. Unclear if CrAzYpass-enabled password files are portable to other devices.

Monerujo can use the very same wallet files the monero-wallet-cli uses. The Android File Transfer application allows wallet files to be transferred to or from Android devices to an external host supporting monero-wallet-cli.

Beside enabling an end user to specify a server name and port number, the Monerujo application allows an enhanced username:password@server_adddress:port syntax to be applid when connecting to a monerod server.  Both the monero-wallet-cli and iOS Cake Wallet clients also support this same functionality for establishing server connections. However, I do prefer not having to drill down so many levels in the Cake Wallet to specify a specific server.

Related Command Line Interface Information:

Server Syntax:  monerod --confirm-external-bind --rpc-bind-ip  address --rpc-bind-port port --rpc-login username:password

% monerod --confirm-external-bind --rpc-bind-ip 192.168.200.100 --rpc-bind-port 18081 --rpc-login test:123

Client Syntax: monero-wallet-cli --daemon-address address:port --daemon-login username:password

% monero-wallet-cli --daemon-address 192.168.200.100:18081 --daemon-login test:123


Is there an RPC call to get the txFee of a block? getblockheaderbyheight and any other simmilar calls only returns the data below. None of the other calls returns the txFee of the block

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "block_header": {
      "depth": 78376,
      "difficulty": 815625611,
      "hash": "e22cf75f39ae720e8b71b3d120a5ac03f0db50bba6379e2850975b4859190bc6",
      "height": 912345,
      "major_version": 1,
      "minor_version": 2,
      "nonce": 1646,
      "orphan_status": false,
      "prev_hash": "b61c58b2e0be53fad5ef9d9731a55e8a81d972b8d90ed07c04fd37ca6403ff78",
      "reward": 7388968946286,
      "timestamp": 1452793716
    },
    "status": "OK"
  }
}

Presumably you'd have to use the getblock method to get the transactions also and then iterate the transactions to add up total fees of a block.

Update: doc


monerod is sync or not? Is my monerod database sync or not?

status
Height: 1554546/1554546 (100.0%) on mainnet, not mining, net
hash 502.65 MH/s, v7, up to date, 8(out)+1(in)  connections, uptime 0d
0h 2m 14s 2018-04-19 09:57:49.516
[P2P4]  INFO    global
src/cryptonote_protocol/cryptonote_protocol_handler.inl:310
[113.240.xxx.yyy:47738 INC] Sync data returned a new top block
candidate: 1554548 -> 1554739 [Your node is 191 blocks (0 days)
behind] SYNCHRONIZATION started
status Height: 1554552/1554552
(100.0%) on mainnet, not mining, net hash 508.09 MH/s, v7, up to date,
7(out)+0(in) connections, uptime 0d 0h 14m 47s 2018-04-19 10:12:16.673
[P2P0]  INFO    global
src/cryptonote_protocol/cryptonote_protocol_handler.inl:310
[163.172.73.21:57694 INC] Sync data returned a new top block
candidate: 1554552 -> 1554965 [Your node is 413 blocks (0 days)
behind] SYNCHRONIZATION started

After restart monerod I have info:

2018-04-19 10:16:18.889 [P2P4]  INFO    global
src/cryptonote_protocol/cryptonote_protocol_handler.inl:1557
SYNCHRONIZED OK

One easy way to check whether the sync has completed is to check the current block height using a block explorer (e.g. https://moneroblocks.info) and then check to see whether your status height is the same as that shown on the block explorer.


Are the LMDB files cross-platform compatible? I would like to know if the LMDB files are cross-platform compatible, more specifically between macOS and Linux. I am trying to import a raw blockchain (that I exported yesterday on macOS) onto a Raspberry Pi 3. However, judging from the current commit rate, it's going to take roughly 19 more days. That isn't feasible. I was thinking, if the LMDB files are compatible, I will just temporarily stop my macOS node, copy over the entire .bitmonero directory, and fire them backup up on both platforms. Would that work?

Note: The .bitmonero directory on the Raspberry Pi 3 is currently on an external USB-attached 5400 rpm drive (exFAT file system).

Update:
I copied my .bitmonero directory from macOS to Raspberry Pi (Ubuntu MATE 16.04). Started monerod --detach, seemed to recognize it, so far so good. After about 1h20m, I am still at block 1175453 and daemon is not catching up:

$ monerod status
Creating the logger system
Height: 1175453/1176194 (99.9%) on mainnet, not mining, net hash 25.08 MH/s, v3, up to date, 5+0 connections

I switched to --log-level 1, and am seeing some error messages:

2016-Nov-09 22:42:18.803852 [P2P6]ERROR /DISTRIBUTION-BUILD/src/cryptonote_protocol/cryptonote_protocol_handler.h:94 Unkonown command:1007
2016-Nov-09 22:42:18.804381 [P2P6]ERROR /DISTRIBUTION-BUILD/src/p2p/net_node.h:150 Unkonown command:1007

At --log-level 2 I see an endless series of these errors:

2016-Nov-09 22:56:50.576666 Attempting to get output pubkey by global index, but key does not exist
2016-Nov-09 22:56:50.642883 EXCEPTION: Attempting to get output pubkey by global index, but key does not exist

Not sure how to debug this further …

As of v0.10.0, yes the LMDB files are cross-compatible between 32 and 64bit architectures. They have always been cross-compatible between OSs. They are still byte-order dependent but almost everyone uses little-endian CPUs these days so it's not much of an issue.


What does the Monero wallet do during I/O bound initial sync? Quote from How Long For Initial Sync to Complete

  Sync'ing speed really depends on your hardware and Internet
  connection. The blockchain is 20+ gigs and there's some processing
  that happens for each block - so it's going to take a while.

  SSD drives make a huge difference. Older rotational drives are slow.

There is huge disk traffic on MacBook:

but the blockchain is much smaller:

> pwd
/Users/Fyodor/.bitmonero
> du -sh *
1.6M    bitmonero.log
6.6G    lmdb
132K    p2pstate.bin

What's the exact processing it does? How to move my wallet (official GUI wallet) from MacBook to Raspberry when finished?

It's verifying transactions for blocks past the set of known hashes (past 1.2 million), and storing tx and block data in the database. It can also be serving some blocks to others, but that's typically not much compared to the load from syncing. If you have a wallet connected, the wallet will also compete to get the blockchain lock so it can refresh blocks. It's best to keep the wallet off while syncing.

Monero uses LMDB, a fast key/value database, but writing new data to the database isn't just appending the block blob at the end of the file, as it is structured, with some tables being sorted in a tree.

As for moving the database once done, it's as simple as stopping the dameon and copying the data.mdb file. It's platform independent except for endianness.


Mining at pool: All results are rejected All results are rejected by the pool. I tried to restart many times but that didn't help. It used to work in the same setting before.

This problem caused by recent network upgrades and if you are using old miners you will get the reject response which means your shares not accept by the pool. if you are using the minergate pool you have to use their official miner ( I tested 2-3 days ago and the last version of XMRig didn't work )

Try supportxmr pool, It has no problem with the last version of the XMRig miner.


Twisted Edwards curve and stealth addresses Monero uses Twisted Edwards curve Ed25519. My questions:

Is it necessary to use this curve for stealth addresses or can one use any kind of elliptic curve, such as secp256k1?
How to define Ed25519 and other Twisted Edwards curves with Sage?
In the Monero source is a predefined constant ge_precomp ge_base[32][8]. How can I compute it?
Is it possible to define small toy Twisted Edwards curves with 16 or 24 bits instead of 255 bits, with another parameter d which is equal 121665/121666 for Ed25519?

Stealth addresses require an agreed upon eliptic curve and hash function. For use with Monero, this is Ed25519 and Keccak (as used in Hs - hash to scalar), respectively.
I have no knowledge of "Sage". Perhaps someone else can answer this for you.
See https://crypto.stackexchange.com/questions/53154/how-is-the-precomputed-table-for-25519-elliptic-curve-generated
Possible, yes. Useful, doubtful.


Creating a wallet in non-interactive mode using monero-wallet-cli? I building wallet software for monero and I'm running into issues of creating wallets from monero private keys. I'm trying to import a private key as a wallet via monero-wallet-cli command, but the command is interactive. Is there a non-interactive mode setting for the cli command? I tried monero-rpc but that doesn't let you import private keys to create a new wallet.

monero private spend keys stored in mysql database as plain text
php script that reads the db and runs the monero-wallet-cli command to creat a wallet

Looks like you can't provide all arguments in the command, but you can pass them via stdin, and "simulate" the interactive process.

If you use ./monero-wallet-cli --generate-from-spend-key walletName
The cli will ask you for the following arguments in this order:

private-spend-key
wallet-password (twice)
seed-language
blockchain-height-to-restore-from

You can create a file will all these arguments, each on a new line and tell the cli to read input from this file:

$ cat commands
8106ca36c4206caba03b463e42ba7bf87fd212789c719fd180666d0d9bec230b
myPassword
myPassword
1
0

Create wallet:

./monero-wallet-cli --generate-from-spend-key walletName < commands