Which is better for Monero mining: AMD Threadripper or Intel i9 7900x? I have seen a lot of reviews of this two processors but they have focused on movie editing, videogames, compresion, etc. But I haven't seen a good benchmark particularly on monero mining. I know that is depends on a lot of external factors too, but only in terms of processing power and how to handle threads, temperature, etc. which on is better?

AMD Threadripper is clearly better. Take a look at this german article. If you don't understand german, take a look at the table with the number of threads. The more threads the better.

On the second page you will then see the relevant charts

Here are the details from that article

Cache size and optimal number of threads

CPU                             L2-Cache    L3-Cache    Optimal # Threads
AMD Ryzen 3 1200                2 MB        8 MB        4
AMD Ryzen 5 1600X               3 MB        16 MB       8
AMD Ryzen 7 1800X               4 MB        16 MB       8
AMD Ryzen Threadripper 1920X    6 MB        32 MB       16
AMD Ryzen Threadripper 1950X    9 MB        32 MB       16
Intel Core i7-7700K             1 MB        8 MB        4
Intel Core i7-8700K             1,5 MB      8 MB        6
Intel Core i9-7900X             10 MB       13,75 MB    10

Hashes per Second

CPU                                 H/s
AMD Ryzen Threadripper 1920X        1.139
AMD Ryzen Threadripper 1950X        1.009
Intel Core i9-7900X                 533
AMD Ryzen 7 1800X                   495
AMD Ryzen 5 1600X                   429
Intel Core i7-8700K                 339
Intel Core i7-7700K                 218
AMD Ryzen 3 1200                    197

Power consumption in Watt

CPU                                 Watt
AMD Ryzen 3 1200                    21
Intel Core i7-7700K                 27
AMD Ryzen 5 1600X                   48
Intel Core i7-8700K                 52
AMD Ryzen 7 1800X                   58
AMD Ryzen Threadripper 1920X        69
Intel Core i9-7900X                 80
AMD Ryzen Threadripper 1950X        87

Hashes per Watt

CPU                             H/s
AMD Ryzen Threadripper 1920X    14,6
AMD Ryzen Threadripper 1950X    13,1
AMD Ryzen 3 1200                9,4
AMD Ryzen 5 1600X               8,9
AMD Ryzen 7 1800X               8,5
Intel Core i7-7700K             8,1
Intel Core i9-7900X             6,7
Intel Core i7-8700K             6,5


How can I see my hash rate? I am solo mining using monerod.  When I run './monerod show_hr', I am told 'Hash Rate Logging is on', but I can't find the files.  Where are they stored in Ubuntu 14.04?

Also, is it possible to redirect the output of this command to the display rather than a file so I can monitor the rate on a real-time basis?

The log file is ~/.bitmonero/bitmonero.log. On Windows, it is somewhere else which someone who knows will edit here soon.

The status command reports your hash rate. If you're running a detached monerod:

./monerod status

You could use watch to run this at whatever interval you want, eg:

watch -n 60 monerod status >> /tmp/monerod.log

Or you could grep the log, where the hash rate goes once requested by the show_hr command you included:

tail -f ~/.bitmonero/bitmonero.log | grep --line-buffered hashrate:

Edit: The hashrate isn't logged, as mentioned below. Another way, then:

(watch -t -n 60 './monerod status >> /tmp/monerod.log'&) 2>&1 2> /dev/null; tail -f /tmp/monerod.log


Monero Wallet For Raspberry Pi 1? (ARMv6 I think) Is there a version of the monero wallet for the Raspberry Pi Model B that is up to date? I have looked and can only find ones a year or older often with the links 404ing. Or could anyone help me compile one? (specifically the wallet I plan to use a remote node)

As seen on the Monero downloads page, there are no official builds for ARM v6. There are only v7/v8: https://github.com/monero-project/monero/releases

However, Howard Chu has some unofficial builds listed here that include ARM v6: https://www.reddit.com/r/Monero/comments/543euo/monero_unofficial_arm_builds/

FYI, these may not work with the current network, especially after the next hard fork when RingCT will be enforced network wide (Sept 2017).

Edit: Hyc released some new binaries! (v0.10.3.1): https://www.reddit.com/r/Monero/comments/6eg72k/updated_binaries_for_armv6_raspberry_pi_1/


Is Monero susceptible to botnets? When reading up on CryptoNote, something struck me on the wikipedia page.

From wikipedia (emphasis mine)

  CryptoNight is a proof-of-work algorithm that mixes graphics
  processing unit (GPU) and central processing unit (CPU) mining to
  create a system resistant to both application-specific integrated
  circuits (ASICs) and fast memory-on-chip devices. This is designed to
  create a more uniform distribution of coins through the currency's
  life. However, there are some questions about its susceptibility to
  botnets.

This information is provided without any sources. Is there truth in the statement and could this affect Monero?

Botnets do not have magical ability to affect Monero more than any other hash source.

As other PoW based currencies, Monero is vulnerable to 51% attacks, and any adversary who is able to sustainably mine faster than the rest of the network will be able to slowly increase the cumulative difficulty of an attack chain, and thus override a "legitimate" chain. Thus, Monero is vulnerable to any party that can attain 51% of the network hash rate (and, similarly to other PoW curencies, to any party that can attain a significant minority hash rate too, for different types of attacks).

Monero uses the Cryptonight PoW hash, as most Cryptonote based currencies do. Cryptonight is designed to close the efficiency gap between CPUs, GPUs, and ASICs. With Bitcoin, CPU mining is a thing of the past, and the vast majority of "normal people" are thus unable to partake in Bitcoin mining, and, by extension, are unable to have a say in how Bitcoin's blockchain evolves. The intent of Cryptonight is to curtail the advantage ASICs have over GPUs (there are no ASICs for Cryptonight at this time, two and a half years after its introduction), and GPUs have over CPUs, thus restoring the "one CPU, one vote" idea.

Now, botnets are able to commandeer a large number of CPUs, and thus may be viewed as a potential danger to Monero. Botnets are typically composed of low to medium strength machines, and without high end GPUs. They are thus able to sustain a fairly high hash rate, but not so high to reach a majority of Monero hash rate. Of course, this is variable, and it is theoretically possible that a large botnet might be able to reach 30 MH/s (the current Monero network hash rate - if a new entrant was able to bring 30 MH/s, thus increasing network hash rate to 60 MH/s, that entrant would then have about 50% of the network hash rate).

Moreover, if a botnet was able to reach that point, it could either decide to mine honestly and make money that way, or attack Monero (eg, double spend). Similarly to Bitcoin and other PoW currencies, it is more profitable to "play nice", since an attack would cause the exchange rate to drop dramatically very quickly, since the coin would no longer be safe. This incentive is a failsafe, should someone be able to amass that much has power.

50% hash rate has happened in the last, at least for Bitcoin. A single pool reached 50% hash rate (I can't remember the name right now). Yet, no double spend or other such attack happened. This is because that party stood to gain more from continuing playing fair. Of course, this is a bad place to be, but there is yet another incentive to act as a last chance shield against a catastrophic failure.

A separate, though related, criticism leveled at Monero is that botnets mining Monero somehow make Monero "bad". I'll mention this because it is a common canard, even if shortsighted. There are two reasons why this argument does not hold water: first, a criminal using something does not make that thing a bad thing. After all, criminals use cars to get to the place of their crimes, dollars to pay for their tools of the trade, etc. Second, if a botnet is being used to mine Monero, it means it isn't being used for other socially negative use, such as spamming, DDoS, or other. One can therefore argue that botnets mining Monero is in fact a social good, since those botnets switch from a nefarious activity to a positive one, increasing Monero hash rate to make it more difficult to attack by another party.


Personal Node on Server 2012 R2 I'd like to run a personal node on existing infrastructure, which already provides peer2site VPN connection. So I installed Monero GUI on the Server and synced blockchain. Now I want to connect to this "remote node", which only listens on localhost. Can I get the daemon to listen on the Windows Server's real IP instead of localhost. And if, would this setup work?
Can anyone provide instructions?

Thanks in advance

Bernie

Instead of running the Monero GUI, just run the monero daemon executable (it's called monerod).

The command line flags you should use are:

monerod.exe --rpc-bind-ip 111.222.333.444 --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind

Replace 111.222.333.444 with the IP address of your externally facing network interface.


Why does Monero use a 256 bit seed? Apparently, ECC 256 bit keys have a bit strength of 128 bits. See https://crypto.stackexchange.com/questions/26791/how-many-bits-of-entropy-does-an-elliptic-curve-key-of-length-n-provide

And apparently, no one needs more than 128 bits of entropy https://security.stackexchange.com/questions/102157/do-you-need-more-then-128bit-entropy

So if I'm correct in saying that it's pointless for the private spend key to be derived from a seed with more than 128 bits of entropy, and given that it is currently the case that the private view key is derived from a hash of the private spend key, why does Monero use a 256 bit seed?

Perhaps the 'multi-target attack' mentioned here is relevant? https://crypto.stackexchange.com/questions/39991/can-i-use-128-bits-of-entropy-and-a-kdf-to-make-a-256-bit-ecc-key

Update: Multi-target attacks do not appear to be an issue. See https://crypto.stackexchange.com/questions/56541/is-it-safe-to-generate-two-256-bit-ecc-keys-from-128-bits-of-entropy

Update 2: It looks like BIP32 actually recommends that 256 bits of entropy are used to generate a Bitcoin wallet. See https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Master_key_generation

This means that the 13 word, 128 bit seeds used in many Bitcoin wallets actually go against the recommendation in BIP32.

Therefore Monero is actually following the recommendations of BIP32 by using 256 bits of entropy via a 25 word seed.

Perhaps the real question should therefore be: Why do Bitcoin HD wallets use only 128 bit seeds, and ignore the BIP32 recommendation? I've asked that question here: https://bitcoin.stackexchange.com/questions/72612/bip32-recommends-a-256-bit-seed-why-do-most-bitcoin-wallets-only-use-a-128-bit

BIP32 recommends that 256 bits of entropy are used to generate a Bitcoin wallet. See https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Master_key_generation

This means that the 13 word, 128 bit seeds used in many Bitcoin wallets actually go against the recommendation in BIP32.

Monero is following the recommendations of BIP32 by using 256 bits of entropy via a 25 word seed.

I asked the author of BIP32, Pieter Wuille, why 256 bits were recommended instead of 128. He responded in the comments here: https://bitcoin.stackexchange.com/questions/72612/bip32-recommends-a-256-bit-seed-why-do-most-bitcoin-wallets-only-use-a-128-bit

He said:

  Well, being able to break an EC key with just 2^128 steps is somewhat
  theoretical. In practice, these algorithms have significant memory/cpu
  tradeoffs, and in practice would still be much slower than a straight
  2^128 exhaustive search on keys with just 128 bits of entropy. I guess
  the answer is defense in depth: less than 128 bits of entropy
  definitely hurts security. Less than 256 bits may hurt.

We therefore have an answer. 256 bits gives us defense in depth, because fewer than 128 bits of entropy may hurt security.


What is the speed difference between CryptoNote Easy Miner and Monero Spelunker? Links to CryptoNote Easy Miner and Monero Spelunker.

Is there a difference in speed on Windows machines? I notice pools offer one or the other to first-time users. Other than speed, is there a reason to choose one over the other?

Monero spelunker is just a GUI wrapper for Wolf's cpu miner. It looks like the easy miner one also generates a wallet and mines to that address, where as for spelunker you have to generate your own wallet. It also appears that easy miner comes bundled with very old simplewallet binaries, so you probably don't want to generate your wallet that way. It's not clear if the miner bundled with easy miner uses aes (wolf version) or not (lucasjones version), but spelunker is bundled with wolf version, so if you have aes that might make spelunker significantly faster.


How do I make my macOS detect my Ledger Nano S when plugged in? There is a section in Ledger's guide (Chapter 3.2.2) to configure your Mac so it will detect your Ledger Nano S.

Could someone write a more descriptive guide for this section?

PLEASE NOTE!!!!!! With the launch of the official 0.13 Beryllium Bullet CLI and GUI wallets, the following guide is now redundant. You should be able to set up the Ledger Nano S without the need to complete this guide.

Part 1 - Check if you have Smart Card Services installed.

Open a Finder window. Then press CMD + SHIFT + G. Paste the following into the prompt window and select Go:

/usr/libexec/SmartCardServices/drivers/

If Finder can find this folder, then you have Smart Card Services installed and can move onto Part 2. If Finder doesn't find this folder, then you will have to install the the Smart Card Services by choosing the correct installer for the macOS version you are using. You can find the installers here:

https://smartcardservices.github.io/installers/

Once installed, you can move onto Part 2.

Part 2 - Disabling SIP (System Integrity Protection) in order to edit a file.

You will need to boot into your Mac's Recovery OS in order to edit a file. To do this, restart your Mac and immediately hold down the CMD + R keys after you hear the Apple startup 'boooong', until you  notice you are in the Recovery OS (this will have a light grey background and will look different to your usual user account desktop). Ignore the macOS Utilities window and move onto point 2.
Launch Terminal from the Utilities menu.
Enter the following command and press Return:

csrutil disable

Restart your Mac.
Once restarted, open a Terminal window and type:

csrutil status

Press Return and you should see the following message:

System Integrity Protection status: disabled.

If it says that it's enabled then you may have to repeat Part 2.

Part 3 - Editing a file.

Open a Terminal window and paste this command:

sudo nano /usr/libexec/SmartCardServices/drivers/ifd-ccid.bundle/Contents/Info.plist

Press Return and you will get asked for your user password. Enter it and press Return. You will then enter the editor.

Using your down arrow key (or you might be able to scroll using your mouse), scroll down the file until you see:

<key>ifdVendorID</key>

Immediately following this, you will see there is an <array> tag. Inside the <array> tag there are many <string> tags on separate lines. Begin to scroll down the <string> tags until you get to the last one inside the <array>. Move the cursor after the last closing </string> tag and press Return to go onto a new line.

Press the Tab key twice to indent the cursor and then paste/type the following:

<string>0x2C97</string>

Immediately after the closing </array> tag, you will see the following:

<key>ifdProductID</key>

Like before, begin to scroll down the <string> tags until you get to the last one.

After the final </string> tag, make a new line, indent twice and paste the following:

<string>0x0001</string>

Immediately after the closing </array> tag, you will see the following:

<key>ifdFriendlyName</key>

Like before, begin to scroll down the <string> tags until you get to the last one.

After the final </string> tag, make a new line, indent twice and paste the following:

<string>Ledger Token</string>

To save/write out the file, press CTRL + O. Then press Return. The file has been saved.
Press CTRL + X to exit the editor and then close Terminal.

Please note: Even if the <string> you need to add already exists, you will still need to add it, despite it being a duplicate.

Part 4 - Enabling SIP (System Integrity Protection) to restore Mac OS security.

Once again, boot to the Recovery OS by restarting your machine (see Part 2.1 for this explanation).
Launch Terminal from the Utilities menu.
Enter the following command and press Return:

csrutil enable

Restart your Mac.
You can check that SIP has been enabled by opening up a new Terminal window and typing:

csrutil status

Press Return and you see the following message:

System Integrity Protection status: enabled.

If the status is disabled, then you will need to redo Part 4, otherwise your Mac might be at risk.

You are now ready to generate a wallet from your Ledger Nano S.

Further information

Configuring SIP


Pruning the Monero blockchain, a number question According to this web https://web.getmonero.org/2019/02/01/pruning.html

Why only 2/3 of the blockchain data can be pruned? 1/3 of the blockchain cannot be pruned. This pruning is not as efficient as bitcoin because in bitcoin the UTXO set is just 4GB vs full node size of 250GB approx.

".Monero pruned nodes will only prune 7/8 of the pruneable transaction data. A random 1/8 of the data is maintained. This 1/8 will be used to sync with other nodes. Pruned nodes will also hold and share the most recent blocks". How do I relate 7/8 (87.5%) pruneable transactions to 2/3 (66.6%) pruneable blockchain? These numbers do not match. (at least if it stated 80% pruneable transaction and 75% pruneable blockchain I can still accept.) Or the protocol is just too complex for some calculation to be done.

Which component of the transaction is actually pruned? Is it the decoy's signature? The whole intermediary transaction. It's not clear in the website. I hope I don't have to look into the source code to find the answer.

Why only 2/3 of the blockchain data can be pruned?

Think about it like this: If you pruned 100% you would have nothing, your node, and wallet connected to your node, wouldn't be able to do anything. So how much do we actually need to keep to still be usable? Well, once we've verified every transaction, we no longer need the signatures, so they can be discarded. However, we still need the rest of the tx data.
Now to be usable to others...

How do I relate 7/8 (87.5%) pruneable transactions to 2/3 (66.6%) pruneable blockchain?

With pruned nodes, we still want them to be useful to others also, so they can sync and crucially verify every transaction. This is where the 7/8 comes into play. Of a full blockchain, we will only prune 7/8 of it, leaving a random 1/8 unpruned, so others can still fully verify that 1/8. When a new node comes along, it will sync and verify parts of the blockchain from many different nodes.
So, 7/8 will be a candidate for pruning and of this 7/8, ~2/3 can be discarded.
Or to put another way, 1/8 will be left untouched, of the remainder, ~2/3 can be thrown away after we have verified.
The 2/3 number in the linked article is speaking approximately* as to how much will be discarded from a full blockchain - bottom line is this, 1/8 will be kept unpruned (untouched), the rest can be pruned, which means discarding parts of data we no longer need (e.g. the signatures), post verifying.
*approximately because transaction size and volume are not uniform.

Which component of the transaction is actually pruned?

Signatures.

This pruning is not as efficient as bitcoin

Comparing is pointless. The requirements of the blockchains are fundamentally different.


Are Wallets "Forward" Compatible? So, I generated a "cold" wallet with a previous version of Moneromooo's generator a while back.

I checked balance and transactions at xmr.llcoins.net, then stowed it.

Can I be assured that this wallet/seed will remain patent going forward or might there be some reason to create another wallet and transfer funds at some point?

Thank-you!

Basically, as long as the wordlist or the format doesn't change, the wallets are forward compatible with respect to 25 word mnemonic seeds. Furthermore, I am certain that, even if the wordlist or format changes, the devs will make sure the old seeds are forward compatible. However, I don't expect either to change in the foreseeable future. There was a minor change in the beginning of 2015, because there was an issue with a few of the words.

Bear in mind that you are always able to restore from keys as well. That is, restore your wallet from the spendkey and viewkey. Therefore, I'd advise to note down these keys too, in addition to the 25 word mnemonic seed.


do i need to remember the password for wallet recovery? trying to clarify something. To recover a wallet I just need my 25 mnemonic seed correct? I don't need the password right？

thanks

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


Is there a Blockchain-like hub for Monero to manage wallets with an easy interface? I created an offline Monero wallet with https://moneroaddress.org/, now is there any easy way to check its balance? I used ShapeShift to exchange Bitcoin for Monero and sent it to my public address using the MoneroAddress address generated for me.

If you want to check your balance with an offline wallet that becomes a little difficult. You can take the view only key and generate a watchonly wallet. Optionally, if you have the transaction id, you can check whether funds a user sent in a transaction enter the blockchain using various block explorers. With shapeshift, immediately after the coins are received, a link should have appeared on the next page allowing you to open a block explorer to see the transaction that contains you coins. It does not allow 100% verification however.


Lost monero money after switching wallets I am a monero noob, please help. I could not send funds from my MyMonero wallet, so as everyone suggested I imported the keys in the Monero GUI wallet. Problem is, it shows a 0 balance. When I tried sending to this wallet it did in fact increase the balance but my old balance has disappeared.

I tried running a local node, which kept failing and saying "incorrect version" after a few hours, which makes no sense because I downloaded the full package zip. So I tried using a remote node on Moneroworld. When I look at the daemon logs though, it is constantly spamming different IP addresses - "new top block candidate - xxx days behind".

I have no idea what is happening. Can someone offer clarity? I can send and receive now, but my old balance is missing. Am I out of sync or something? I thought remote nodes should be able to pickup my proper balance immediately.

As a side note, when I log back in to view my MyMonero wallet, all the transaction amounts are incredibly weird and wrong.

What probably happened is that you hit a bug which skips early scanning, but skips too much.

If this is indeed the reason, you can fix it by doing this:

exit the GUI
rename the wallet cache, eg adding ".old" [1]
restart the GUI, and wait for the cache to be rebuilt

[1] The wallet cache is one of three files created by the wallet. Assuming you named your wallet "XYZ", then the files would be XYZ.keys (important, back this up and keep it secret), XYZ (that's the cache we're talking about here), and XYZ.address.txt (your public address). So in this example, you'd rename XYZ to XYZ.old. Those wallets are in ~/Monero/Accounts (if you're on Windows, just search the disk for XYZ.keys to find it).


Removing private view key from computer after exporting from ledger? According to How do I generate a Ledger Monero wallet with the CLI (monero-wallet-cli)? exporting the private view key when generating or using the monero wallet with a ledger device speeds up block scanning, but at the same time:

  if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy

Is the private view key removed from the computer once the wallet application is closed? If not, can it be manually removed?

You have to manually remove the wallet files from your computer. The best option would be to store them on an encrypted removable device.


Monitoring an address for activity if you have the private view key I'm building out an email notification system for monero. Correct me if I'm wrong or not:

There's no way to monitor an address by looking at transaction data, as the blockchain never reveals the addresses.
If you had the private view key, you could view whether the address has received funds or not. But how would one do this in the cli if you had the private view key from a paper wallet?
The monero address is the combination of the public view key and public send key combined, correct?

This is all correct.

To create a view wallet from the private view key, you can use the --generate-from-view-key option:

monero-wallet-cli --generate-from-view-key sample-view-wallet

You will be asked for address and view key, and will end up with a wallet from which you cannot spend. Note that you will not see outgoing monero, so when you see incoming funds, it might be change.


If I download a monero client for windows - am I running a full node? Tipping my toe into Monero :)

Installed a windows GUI client from here - https://getmonero.org/downloads/
It's synching as of now.
But once it's done, will it mean :

a. I'll be running a full node ?
b. Will it be actively mining ?
c. If it will be mining - can I choose which transactions to pickup for mining ?

I know the hashrate of my machine is probably pathetic, but just wondering :)

a. I'll be running a full node ?

Yes.  You won't necessarily be acting in the same capacity as other nodes though.  At first, you'll only have outgoing connections, meaning your node is reaching out to others for its data.  You generally must port-forward port 18080 in your router in order to enable incoming connections, where you would then be feeding blockchain and mempool data to other nodes.

  b. Will it be actively mining ?

Negative.  It will not automatically start to mine, but you can mine.  Mining is a function of either the wallet or a mining software.  If you would like to solo-mine, once the blockchain is synced, and the wallet has fully refreshed, you can tell the wallet to start mining.

However, most people who mine will mine on a dedicated machine, using mining software, and they mine to a pool, since a pool has a greater collective hash rate and therefore a better overall chance of winning a block. You don't need to have a local copy of the blockchain to pool-mine.

  c. If it will be mining - can I choose which transactions to pickup for mining ?

The transactions chosen will automatically be the most profitable ones.  You likely won't have to "worry" about this, however, since you're very, very unlikely to ever solo-mine a block at this point in the Monero ecosystem's evolution.


How long would it take to get the monero blockchain size to over 100 GB and 200 GB at today's usage rate? Currently the monero blockchain is about 70 GB as of 2019 May 14. Assuming monero usage rates stay the same, how long would it take to hit 100 GB and 200 GB blockchain size?

Also I read that if monero usage increases the blocks are smaller? I'm just curious to what is the average growth rate after the bulletproofs upgrade since it significantly reduced the block size by 90%.

Looking at https://moneroblocks.info/stats, the current growth rate looks to be about 400 MB per month, average over the past last half year. This is about 5 GB per year. This means reaching 100 GB (+30 GB) in 6 years, and 200 GB (+130 GB) in 26 years. This is assuming no increase nor decrease in usage, nor in software improvements (transactions are likely to get 25% smaller in the next fork).

Monero will support pruning in the coming release. a 70 GB database prunes to about 25 GB. The effect is smaller on current bulletproof transactions than previous Borromean proof based transactions though. I'm not quite clear what the practical growth will be for a pruned blockchain compared to 400 MB, but it should be significantly lower, increasing the times above.

To your last point, blocks do not get smaller with more usage. They will get larger, since they'll have to store more transactions.


What is the mining reward equation? I've tried using this equation, but while it works for Bitcoin, it doesn't work for Monero.

Questions: what's the Monero mining reward equation? And a soft question, why is it so difficult to find this information?

Of course it doesn't work for Monero, because Monero is not a fork of Bitcoin.
For mining profit, the simplest would be the following:
Daily mining estimate =
( (your hashrate) * (current block reward) * 720 ) / (network hashrate)

Note that you can't use Bitcoin hashrate for this, as it is a different alghorithm (CryptoNight). For example, a RX 470 will yield about 600H/s for Monero.
For the current block reward, we must look at the emission schedule, or simply look it up at some block explorer.
The emission is a function of current supply, and was defined in the CryptoNote whitepaper, section 6.1.

The upper bound for the overall amount of CryptoNote digital coins is: MSupply = 264 − 1 atomic units. This is a natural restriction based only on implementation limits, not on intuition such as "N coins ought to be enough for anybody".
To ensure the smoothness of the emission process we use the following formula  for block rewards:
BaseReward = (MSupply − A) >> 18,
where A is amount of previously generated coins.

The above is not really user-friendly since it uses bit-shifting for faster calculation.
User-friendly variant of the expression can be found here. Repeating for readability:

The Monero block reward = (M - A) * 2-20 * 10-12, where A = current circulation.

And a soft answer: all I had to do to find it was search for "emission" here on StackExchange.
Also, searching "mining" yields:
How to calculate mining profits in Excel?
Estimated mining profits are overestimated
Are [solo] mining yield calculations like dice or playing card calculations?
Where can I find a tutorial on how to mine with Monero?


Are there options for `show_transfers` to change the date format? I recently made a transfer; and, when running show_transfers in the CLI wallet, the transaction reflects a date format of HH:MM:ss AM/PM.  All the other transactions in that output are reflected as YYYY-MM-DD.

Is there a way to change/customize the date format for individual transactions or for the overall output of show_transfers? If so, the way to do it is currently not reflected in the help output.

There are no such options. There are two different date/time formats, selected based on the age of each transaction, as seen in src/simplewallet/simplewallet.cpp, function get_human_readable_timestamp. If the transaction is older than a day, the timestamp will be YYYY-MM-DD, otherwise it'll be the more precise HH:MM:SS.


How many destinations can there be for a single transaction? Can I transfer to as many addresses as I'd like in a given transaction?  Is there a technical upper bound?  If there is an upper bound that is not technical, is there a reason why the upper bound was chosen?  Is it a "consensus" limit or just a software default? If there is a limit, was there always a limit?

There is no hard coded limit to the quantity of destinations in a single transaction. However, there is an overall transaction weight limit, which is roughly half the block weight. Therefore, if you tried to pack in an unusually high quantity of inputs / outputs, you could end up with a transaction that exceeds the maximum allowed tx weight limit and thus gets rejected.

So:

  Can I transfer to as many addresses as I'd like in a given transaction?

No.

  Is there a technical upper bound?

Yes. The transaction cannot exceed its overall weight limit, which is half the penalty-free block weight.

  is there a reason why the upper bound was chosen?

Presumably to prevent spam attacks.

  Is it a "consensus" limit or just a software default?

It's consensus level.

  If there is a limit, was there always a limit?

There has always been a limit to the maximum tx weight. Prior to HF version 8, this limit was the set to the penalty-free block weight. Since version 8, it's half the penalty-free block weight.

UPDATE

Since bulletproofs, there is also a maximum of 16 outputs per transaction.


5-party Ring Signatures still being implicatory for sender? Why are 5-party ring signatures enough for privacy? I don't understand how even if I get everything else right privacy-wise, I can still be connected to a transaction and potentially implicated in something to the tune of a 1/5 chance I was involved. Say there was some other real-life clue that would never be enough on its own, but could be damning enough if combined with the knowledge that I was at least a potential signer of that transaction? Hoping I'm just underestimating one-time stealth addresses or something, because it seems like all the introductory material seems to gloss over this as being fine.

Privacy concerns related to ring size are most significant in cases where an exchange or person that gave you the output you are spending knows you control it and is aware of your identity. Significantly reducing the statistical likelihood of a TX being connected to you in the above situation is not difficult using the current default ring size:

  Can you tell that those funds actually came from the TX you sent to me 5 hops ago? Probability would be (1/N)^5 that it came from me. For ringsize 5, that's 0.0000032% chance. Just one of many possibilities, without any way of knowing which one is the real trail.

Monero Research Lab continues to evaluate the ring size issue. Minimum ring size will be increased in the future. However, because of the way ring size currently impacts tx size, it is likely that bulletproofs will be implemented before or in conjunction with any major adjustment to the minimum ring size:

  Bulletproofs offer substantial improvements when using multiple outputs. With current Monero range proof technology, transaction sizes scale mostly linearly depending on the number of outputs (eg: 1 output = 7kB, 2 outputs = 13kB). With bulletproofs, these scale logarithmically instead (eg: 1 output = 2kB, 2 outputs = 2.5kB).


Are the blocks mined by a wallet shown as transaction? How can one be sure that a wallet address has mined 1 or more xmr blocks?
Do they show as transactions or is there any way to confirm?
I ran a wallet with monero wallet cli and upon running show_transfers commands it returned nothing
Does this guarantee this wallet has never mined any block or done any transaction?
(Pardon my naivety I am totally new to xmr)

They do show as transactions. Special types of transaction with a dummy input (since noone's actually spending any monero) and one or more outputs (usually just one, pre-rct coinbase transactions have more than one).
Example on testnet:
Height 1635197, txid <0e74095b092051a9742a36a09b6a550137132504579101062ddb2e973f837344>, 2.822135419737, idx 0/0
Height 1635198, txid <fced7485c1ee265132c5a910986b2c48b123f0c58609f61a107e7db73e4b71d8>, 2.822130036941, idx 0/0
Height 1635199, txid <775200145a2cd4891334c6181e07b9f1227b2213eb04265dc77b188210c8bdf0>, 2.822124654155, idx 0/0

These are all new blocks. With show_transfers, they show as "block" type rather than "in":
 1635197  block  40 blks       2021-01-19 14:20:31       2.822135419737 0e74095b092051a9742a36a09b6a550137132504579101062ddb2e973f837344 0000000000000000 0.000000000000 9yvGzysbcaWPHNjzkdKTMy5E7uvf85eNtZmuDQ3FLJrq3TeMy9cEaEi5CK7FqXNboWKHBvLGAxHFB5gq8KpSxmgJPah9MJc:2.822135419737 0 -
 1635198  block  41 blks       2021-01-19 14:20:55       2.822130036941 fced7485c1ee265132c5a910986b2c48b123f0c58609f61a107e7db73e4b71d8 0000000000000000 0.000000000000 9yvGzysbcaWPHNjzkdKTMy5E7uvf85eNtZmuDQ3FLJrq3TeMy9cEaEi5CK7FqXNboWKHBvLGAxHFB5gq8KpSxmgJPah9MJc:2.822130036941 0 -
 1635199  block  42 blks       2021-01-19 14:20:55       2.822124654155 775200145a2cd4891334c6181e07b9f1227b2213eb04265dc77b188210c8bdf0 0000000000000000 0.000000000000 9yvGzysbcaWPHNjzkdKTMy5E7uvf85eNtZmuDQ3FLJrq3TeMy9cEaEi5CK7FqXNboWKHBvLGAxHFB5gq8KpSxmgJPah9MJc:2.822124654155 0 -

If show_transfers shows nothing, this is either because your wallet has not sent/received anything, or because it has not scanned the chain (or only part of the chain).


Support for a Ledger Nano S Recovery Plan B? For a Ledger Nano S recovery contingency plan, how can one compute an associated vector of 25 Electrum wallet recovery words for each primary address using BIP 44 technology that is seeded from BIP 39 using 12, 18 or 24 seed words (not to be confused with Electrum seed words), and an associated BIP 39 passphrase (not to be confused with a Monero wallet password)?

It is unclear if or how m/44'/128'/0' or m/44'/128'/0'/0/0 or some other HD wallet path(s) is/are used to synthesize a primary Monero private key and associated address.

It should be possible to calculate associated Electrum seed words for a given set of BIP 39 seed words and a specified HD wallet path. Those Electrum words could then be used by monero-wallet-cli to recover funds using --restore-deterministic-wallet, or other wallets (e.g., Monerujo, Cakewallet, X Wallet).

With a Plan B Recovery Plan, it should be possible to engender more trust in a Ledger Nano S beta Monero capabilities. The Trezor had such a Plan B recovery capability 18 months ago before the Monero Ring CT fork activated.

The original answer is found at https://github.com/LedgerHQ/ledger-app-monero/tree/master/tools/python.

For OSX hosts, to complement the ledger-app-monero documentation, the Homebrew package manager's brew command is used instead of the apt command to install two dependent packages. The ledger-app-monero application has a dependency upon the libusb and libusb-compat packages that can be installed using:

% brew install libusb libusb-compat

The Advanced Package Tool package manager's apt command is frequently used for Ubuntu and Debian hosts. Those hosts need the libusb-dev and libudev-dev packages to be installed, per ledger-app-monero documentation.

After cloning the ledger-app-monero package and satisfying documented pip3 python package dependencies, change into your local the ledger-app-monero/tools/python/src directory and execute the following:

% python3 -m ledger.monero.seedconv offline

Unfortunately, the results for the README.md 12 word test vector did not match.  Here are my results that are also embedded in code here.

BIP 39 Test Vector with no passphrase:
abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about

Test Vector Monero Electrum words:
tavern judge beyond bifocals deepest mural onward dummy eagle diode gained vacation rally cause firm idled jerseys moat vigilant upload bobsled jobs cunning doing jobs

Independently validated the Monero seed words synthesized using ledger/monero/seedconv.py (that was supplied with the same 24 BIP 39 seed words and a BIP 39 passphrase used to configure a Ledger Nano S) were successfully loaded into Monerujo and CakeWallet mobile wallets and the same addresses appeared in both software wallets and a Nano S.

For the same test vector above, the m/44'/128'/0'/0/0 technique shown below using bitcoin-explorer is documented further here.

% echo "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" | bx mnemonic-to-seed -p "" | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 128 |  bx hd-private -d -i 0 | bx hd-private -i 0 | bx hd-private -i 0 | bx hd-to-ec | ./kec256 | ./xmr

Seed                 : 907cf0eb0e0bbd761a7ed9bc8777fa5530e8262792a3e718533a1a357a1e4199
Private Spend Key    : 3b094ca7218f175e91fa2402b4ae239a2fe8262792a3e718533a1a357a1e4109
Private View Key     : 0f3fe25d0c6d4c94dde0c0bcc214b233e9c72927f813728b0f01f28f9d5e1201
Public Spend Key     : dae41d6b13568fdd71ec3d20c2f614c65fe819f36ca5da8d24df3bd89b2bad9d
Public View Key      : 865cbfab852a1d1ccdfc7328e4dac90f78fc2154257d07522e9b79e637326dfa
Monero Address       : 49vDbkSo7eve3J41sBdjvjaBUyz8qHohsQcGtRf63qEUTMBvmA45fpp5pSacMdSg7A3b71RejLzB8EkGbfjp5PELVF2N4Zn
Electrum Seed Words  : tavern judge beyond bifocals deepest mural onward dummy eagle diode gained vacation rally cause firm idled jerseys moat vigilant upload bobsled jobs cunning doing jobs

Here is an update concerning Trezor Model T Monero capabilities:

When contrasted to the Ledger Nano S and Nano X, the Trezor Model T uses a different HD path and replaces the secp256k1 elliptic curve with the ed25519 elliptic curve when computing a seed for the m/44'/128'/a' HD wallet path, see https://github.com/trezor/trezor-core/tree/master/docs/coins#list-of-used-derivation-paths.

The default primary address a Model T uses follows a different path and complies with SLIP-10 and the application of the ed25519 curve (not the secp256k1 curve) when computing HD keys. This creates an BIP 39 seed word wallet restoration interoperability issue between Ledger and Trezor hardware devices:

% trezorctl monero-get-address -n "m/44'/128'/0'"

44jKQv6ZKMd5ecLLmkNJGi7azgSptEq8ki7TFiat1TfLfdDQ1tQ7ZYa3cRh7X2uRwvLDjddWh97ajeyhR2seKSECQeDx1WR

The trezorctl Python command above queried a Model T, previously configured with the "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" seed words, for its root level Monero address of account number 0.

Since libbitcoin's bx command is not currently SLIP-10 enabled to directly support the ed25519 elliptic curve (bx only implicitly supports the secp256k1 elliptic curve), custom code needed to be developed to mimic SLIP 10 ed25519 behaviors. The following independently developed code of piped command lines generates the same result as Trezor hardware wallets.

% echo "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" | bx mnemonic-to-seed -p "" | ./slip10 --ed25519 | ./slip10 -i 44 | ./slip10 -i 128 | ./slip10 -i 0 | xmr

    Seed                 : 98f0cdd5993ce34eb46b57c1fa6399f6643516416fae089d74ecfd0c389a6bd8
    Private Spend Key    : 8f2d521d4334f4d5d174c47aacb346e7633516416fae089d74ecfd0c389a6b08
    Private View Key     : 84b0087a63854856686f80596a5a1a6090795b4d1311139173262170d7e7180f
    Public Spend Key     : 51fd81faa5e2641bca8a5c43d764ab276033c12b459fd9f5c9c23b7733af67e6
    Public View Key      : eb8855fd7d21670f9bdfc0cdcfa54172e80322c4eaee5ce30d85cb9ec90d21d1
    Monero Address       : 44jKQv6ZKMd5ecLLmkNJGi7azgSptEq8ki7TFiat1TfLfdDQ1tQ7ZYa3cRh7X2uRwvLDjddWh97ajeyhR2seKSECQeDx1WR
    Electrum Seed Words  : symptoms ugly ablaze anchor roster neon feel gemstone spud plywood extra daft alchemy apart fowls dexterity puck films liquid vigilant yesterday people awful blender plywood

The SLIP 10 path above is applied to generate a Monero seed that then must be little-endian normalized/reduced to ed25519's curve order 1000000000000000000000000000000014DEF9DEA2F79CD65812631A5CF5D3ED using Monero's sc_reduce32() function to produce a private key.

% echo 98f0cdd5993ce34eb46b57c1fa6399f6643516416fae089d74ecfd0c389a6bd8 | sc_reduce32
8f2d521d4334f4d5d174c47aacb346e7633516416fae089d74ecfd0c389a6b08

Eventually there will be independent bx open source code made available to implement implement SLIP 10's ed25519 behaviors that Satoshi Labs  defined openly.


Impact of Collective Code Construction Contract on Monero development How will the Collective Code Construction Contract (C4) alter the historical process for reviewing commits contained in Monero pull requests?

How does ZeroMQ relate to the decision to implement C4?

C4 is a ZeroMQ spec inspired by Pieter Hintjens and the Monero ZeroMQ implementation meant meant to provide a

  reusable optimal collaboration model for open source software projects

According to the specific spec the goals are:

  To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
  To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
  To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
  To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
  To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
  To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.

For purposes of Monero development the C4 process going forward is designed to look like this:

  for i = 1 to 180 days               # 6 months of 30 days each, this is a magic for loop that knows when a day passes
  for i = 1 to 180 days               # 6 months of 30 days each, this is a magic for loop that knows when a day passes

  new PR gets eyeball review
  PR is merged to dev branch
  if merge == crap, new PR made to address crap, goto 1. elseif, goto 4
  if i == 180, merge to master. elseif, goto 1

Compared to historical practices the above will help reduce the workload of some Monero core developers, whose previous practice was to thoroughly review each new PR upon submission. In the past PRs often went to master right away and in the new system they will sit in dev branch for quite some time before being moved to master. This will allow more time (and eyeballs) to review the code long before it has have potential to do harm in master.

This process should be more welcoming to developers new to the XMR codebase who don't need to worry about immediately breaking something in master or requiring a lot of time from the core development team to thoroughly review their PRs right away.

The system is not perfect and it is still possible that hard to detect malicious code could eventually by merged into master, but there are safeguards in place to minimize this risk. On balance the benefits of inclusion and efficiency outweigh the risks in the opinion of the Monero core development team.


Can't load wallet in CLI v0.13.0.2 or GUI v0.13.0.3 (error: std::bad_alloc | error: basic_string::_M_replace_aux) Just downloaded the CLI binaries from getmonero. When trying to load a wallet in the CLI I get one of two errors:

Error: failed to load wallet: std::bad_alloc

Error: failed to load wallet: basic_string::_M_replace_aux

The errors don't appear together. Each time I try I get one of them, seems pretty random to me.

I can load the wallet using the old CLI binary.
Anything to do about it?

Edit:
The solution suggested by dEBRUYNE works in the sense that my wallet can now be opened. However, this way I lose information I cannot restore, about past outgoing transactions (specifically, addresses I sent to).
Furthermore, I just noticed that v0.11.1.0 doesn't support subaddresses yet, and I should note that my previous cli did support it, and my wallet did have subaddresses, so I guess this caused the incompatibility.

First, make sure you're running either CLI v0.13.0.4 or GUI v0.13.0.4.

Both errors imply an incompatible wallet cache, which results in monero-wallet-cli not being able to open it. Fortunately, the fix is quite trivial.

Perform these steps and you should be able to open your wallet again.

Browse to the directory your wallet files are located. By default, this is the same directory as monero-wallet-cli.
Rename <wallet-name> (the file without extension) to <wallet-name>-old.

Note that, because you renamed the wallet cache, <wallet-name>.keys now doesn't have a accompanying wallet cache. Therefore, monero-wallet-cli will create a new wallet cache, which will simultaneously trigger a wallet refresh from scratch. A wallet refresh from scratch, however, shouldn't take that long to complete.

GUI:

If you're using the GUI, you can utilize the following steps:

Exit the GUI.
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.


Creating multiple XMR addresses in a single XMR GUI wallet I downloaded the Monero GUI wallet from the official website, extracted all files, opened my .exe file, got me the XMR address and finally, successfully sent and received bunch of XMR already.

At this moment, I have a need to create 2-3 additional XMR addresses, but I cannot see this option in GUI wallet itself, like with most of the other wallets, so I wonder how to create additional addresses?

Should I run multiple instances of GUI wallets instead? Or can I use CLI to manage multiple addresses in a single GUI wallet?

The purpose of this is to be able to point my mining rigs to separate addresses and manage incomes in that way, rather than "predicting" the income every month...

Subaddresses have now been merged but not yet included in a tagged release. If you build from master, you can use them with the CLI now.

GUI support is still being worked on. Anyone with Qt experienced is encouraged to help!

Depending on your reason for wanting to use more than one address, the account command may be a helpful option for you.


Approximately how many developer hours have been spent on Monero so far? For the purposes of this question please include research from the Monero Research Labs and any time preparing the work that is visible in GitHub today.

Itemization of estimated hours for each focus (RingCT, LMDB, Kovri, GUI, etc) would be ideal but is not necessary.

This is really hard to tell, but here are a few things we know:

In April of 2015 smooth estimated that there was a rough estimate of two to three full time equivalents working on Monero software development, testing, and research reports. For clarity, this estimate varies over time.
moneromooo spent at least 710 hours (https://forum.getmonero.org/9/work-in-progress/2410/a-continuation-for-all-purpose-programming-of-what-needs-to-get-done-in-monero, https://forum.getmonero.org/22/completed-tasks/334/fund-a-developer-moneromoo-will-work-part-time-on-monero-for-260-hours-over-approx-6-months)
Ilya spent some amount of 280 hours on the GUI (https://forum.getmonero.org/9/work-in-progress/2476/the-official-qt-gui-project), there is some item list in the thread.
other tasks in that forum may or may not mention smaller chunks of time.

This is start to give an idea maybe, but I doubt it can be made into a reasonably accurate estimation.


What are 3 types of Ring CT transactions? In monero, there are three types of RingCT transactions:

enum {
  RCTTypeNull = 0,
  RCTTypeFull = 1,
  RCTTypeSimple = 2,
};

They can be observed in https://xmrchain.net/

But it's not clear what differences there are among the three types, and why there are three types at all. Why not only one type?

Null is used for coinbase transactions. There are no inputs to sign, so no signatures can be provided. If a miner uses this mode (as opposed to tx.version == 1) then the coinbase output can be used as a dummy input in any rct transaction (AFAIK, primarily due to how it is stored in a database).
Simple is currently used when a transaction has multiple inputs. There is a LSAG signature for each input. Each LSAG is smaller in size than a tx.version == 1 signature, so there is still some space savings over the original signature method.
Full is used when the transaction has a single input. The MRL-005 discusses this mode in the MLSAG section - it is a signature over all inputs. This allows for more space savings over Simple mode when there are multiple inputs. However, Full mode requires that all "real" inputs be at the same offset within the ring, and therefore has not been enabled primarily due to privacy concerns (along with one subtle implementation detail).

Edit - Some clarification:

Full mode is used, but only when a transaction has 1 input.
Simple mode is actually a collection of MLSAG signatures, each of which links the commitment to zero with the key image / previous output address.


Preventing DDoS attacks against a Monero service while protecting user privacy How can I best protect a Monero service (clearnet) from DDoS attacks while at the same time protecting the privacy of users? The Monero service will require that I provide users with the IP address of my full node, so they are able to connect to it.

While of the following measures are generally seen as less intrusive to the privacy of users:

Cloudfare with capcha
Email address confirmation for upon registration and subsequent login with username and password
Blacklisting of IP addresses that have been involved in previous DDoS attacks

All three of the options you mentioned negatively impact user privacy.

Cloudfare is often unfriendly to Tor users.
Logic requirements mean the collection of data from users
IP blocking harms innocent users (whose VPN ip address or Tor exit node usage may be flagged as abusive due to no fault of their own).

One thing you could try is to require none of the above as your baseline and only activate Cloudfare selectively at times of unusually high usage.


What's the scratchpad for? Attempting to follow the pseudo-code here -- What exactly has been changed in PoW algorithms in the v7 fork?, I was curious about this part of the Monero hashing algorithm ...

scratchpad = fill_scratchpad(state)

What is the scratchpad for?  When you "fill" the scratchpad, are you simply taking the value (state) from teh step above and prepending zeroes to it until you have 2 MB worth of data?

The scratchpad is filled with pseudo-random data based on the state (using rounds of the AES block cipher).

Check https://cryptonote.org/cns/cns008.txt for a detailed description of the algorithm (without the modifications introduced in version 7 of the protocol).


Can a node I am connected to with monerod cause any damage to me if it is malicious? I am not referring to a remote node who I have to trust to give me an accurate copy of the blockchain, but any one of the many nodes I connect to to synch my blockchain.

I am imagining a scenario where one of the nodes I have connected to is intent on inflicting maximum damage. What are his options or possibilities?

This may be worth a read:

https://bitcoin.stackexchange.com/questions/40383/what-is-the-protection-against-a-malicious-node-with-a-bad-block-chain

This would mean that a node cannot simply make a blockchain up as it is compared with peers so it must generate an equally as valid one so thus in order to perform a malicious attack with a bad blockchain must contain 51% of the hashing power.


monerod throws Error starting server: Failed to bind IPv4 (set to required) I started monerod on my linux server to sync the (pruned) blockchain and start working with a wallet.
The syncing completed fine.
However trying to restart monerod the next day yielded the following error. How can I resolve it?
$ LANG=C LC_ALL=C  ./monerod --prune-blockchain
2021-05-01 07:56:27.451 I Monero 'Oxygen Orion' (v0.17.2.0-release)
2021-05-01 07:56:27.451 I Initializing cryptonote protocol...
2021-05-01 07:56:27.451 I Cryptonote protocol initialized OK
2021-05-01 07:56:27.451 I Initializing core...
2021-05-01 07:56:27.452 I Loading blockchain from folder /home/deploy/.bitmonero/lmdb ...
2021-05-01 07:56:27.529 I Loading checkpoints
2021-05-01 07:56:27.535 I Core initialized OK
2021-05-01 07:56:27.535 I Initializing p2p server...
2021-05-01 07:56:27.540 F Error starting server: Failed to bind IPv4 (set to required)
2021-05-01 07:56:27.540 I Deinitializing core...
2021-05-01 07:56:27.560 I Stopping cryptonote protocol...
2021-05-01 07:56:27.560 I Cryptonote protocol stopped successfully
2021-05-01 07:56:27.561 E Exception in main! Failed to initialize p2p server.

This error is typically due to trying to start more that one daemon process or a previous process not exiting cleanly. Thus make absolutely sure there is no other monerod process running, such as running killall monerod, then trying to start again should fix the issue (or a reboot).


Does change appear as an output in a transaction? Let say Alice wants to send Bob 10 XMR and she has 15, so assume the outputs are divided like this -

transaction - {

  output #1 - {7, Bob's stealth address}

  output #2 - {3, Bob's stealth address}

  output #3 - {5, Alice's stealth address}

}

Am I right or am I far off?

If it's liked I said above, I would like a reference to the code that handles the change (calculates a stealth address for it, puts it in the outputs, etc).

Thanks a million for any answers!

A transaction has inputs and outputs. All inputs must be spent.

So in your example of Alice wanting to send Bob 10 of her 15 XMR, assuming Alice has all her 15 XMR in 1 UTXO, she would have 1 input and 2 outputs. The 2 outputs would be a stealth address for Bob with a value of 10 XMR and a stealth address for Alice with a value of 5 (minus the tx fee) XMR.

Search for create_transaction in https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp to see code for how transactions are constructed.


How does someone become a contributor to Monero code? I'm not a C++ developer, although I have been trying to learn slowly. Are there any prerequisites or requirements to contribute to the Monero code? Also what resources are good to read before trying to contribute to the code?

A good way to get started it to use Monero, and improve something small which you think can be improved. This allows you to start on a change that's simple enough to start with, while having a goal to achieve. Then do it again :)

Monero's git repository is at https://github.com/monero-project/bitmonero/. There, you can find a list of issues (https://github.com/monero-project/bitmonero/issues), some of which are fairly self contained and simple for a new contributor.

To talk with other contributors, join Freenode IRC, in #monero-dev. There is also #monero for monero talk that's not about developing monero. It is a good idea to idle in those channels.

There aren't really prerequisites, but some of the Monero/Cryptonote code is fairly complex. Some is less so (eg, the wallet code).

There are also other things you might want to contribute to, which are helpful to Monero: Kovri (https://github.com/monero-project/kovri/), the I2P router which will allow Monero to connect to the network via I2P, or the pool software (https://github.com/zone117x/node-cryptonote-pool), written in Javascript, or the GUI (https://github.com/mbg033/monero-core), in C++/QML.


Backup and Disaster Recovery for Monero Fork For a clone of Monero in a production environment, what files/directories to be backed up and and what intervals?

Once you have lots of people using your cryptocurrency, you can back up nothing at all (I'm talking about not backing up your seed nodes. If you have a wallet, you'll want to keep the mnemonic seed for that backed up, of course. And you'll want to keep a safe copy of your passwords/private keys that are used for connecting to the server via SSH and for logging in to your server hosting provider and domain name provider).

The whole point of a distributed cryptocurrency is that you all keep a copy of the blockchain, so that there is not a single point of failure.

This means that you could restore your seed nodes from the other nodes on the network. You'd just have to keep a note of some of the IP addresses of other nodes, so that you could reconnect your seed node to them when you reinstall your seed node after a disaster. Or better, you should encourage lots of people you trust to control their own nodes, who are willing to be listed as a seed node. Now you have resilience and don't need to keep your own written notes of IP addresses.

If you wanted to keep a copy of the blockchain on a machine that you want to control, just install a node on that machine, and it will constantly effectively back up the blockchain as it syncs with other nodes constantly during the day.


Monero never arrived (Poloniex->GUI wallet) I sent monero from Poloniex to my GUI wallet last week via two transactions.  Both show as complete transactions on Poloniex.  Neither one has shown up in my GUI wallet.

What can I do?

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

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

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

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


How can I verify that a Monero Block explorer is not under a MITM attack? How can I verify that a Monero Block explorer is not under a MITM attack? Aside com comparing the most recent block height and block hash with another blockchain explorer what else can I do?

This question is not meant to be specific to any particular Blockchain explorer but I am interested in how the answer varies (if at all) for clearnet vs Tor usage.

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


Can an output be used as a decoy after it has been spent? The title of the question is probably specific enough, but I'll give more color anyway.

Here's a quick timeline.

I received output A a year ago.
In the last year, output A has been a decoy in 3 transactions.
Today, I spend output A; therefore the key image ensures the output can't be spent again.

Question: In the future, can output A be used as a decoy again?

Bonus question: Is there a limit to how many times an output can be a decoy in a ring signature?

Any output can be used as a "decoy" at any time after it matures, whether this is before or after it's been spent.

In the general case [1], the network cannot determine when an output is spent, and thus does not treat spent outputs differently from unspent ones. Indeed, if the network could determine whether any output was spent, it would mostly defeat the purpose of ring signatures.

There is no maximum number of times an output can be used as input to a ring signature.

[1] In some particular corner cases, such as spending with mixin 0, you can tell.


How can one merge mine Townforge with Monero? Townforge, a fork of Monero, can be merge mined with Monero (https://townforge.net/faq/#faq-13).
How can one merge mine both blockchains ?

Merge mining can only be done if two chains use the same PoW algorithm. In this case, both Townforge and Monero use RandomX, and merge mining can be done using a standard pool miner such as xmrig, which can either be used with a pool or with the monero daemon.
Townforge includes a merge mining proxy which will sit between the miner and the monerod daemon, and will transparently alter the RPC communications between monerod and xmrig to allow merge mining Townforge too.
Note that for the following to work, monerod must first be patched with https://github.com/monero-project/monero/pull/6810 (once this PR is merged, this will not be needed anymore).
Consider a straightforward setup where a user is mining with xmrig to the monerod daemon:
monerod --rpc-bind-port 18081
xmrig --coin monero --url 127.0.0.1:18081 --daemon --user 4....

We will need to run the townforged daemon and the merge mining proxy, such that the proxy stands between monerod and xmrig:
monerod --rpc-bind-port 18083
townforged --rpc-bind-port 18881
townforge-merge-mining-proxy --rpc-bind-port 18081 --monero-daemon-address 127.0.0.1:18083 --aux-daemon-address 127.0.0.1:18881 --aux-wallet-address TF1....
xmrig --coin monero --url 127.0.0.1:18081 --daemon --user 4....

The proxy will connect to townforged too, and is set up with the Townforge address any block coinbase should be sent to. The xmrig command line does not change: while it was previously talking to monerod, it is now talking with the merge mining proxy, and does not see the difference.


Looking for a paper describing Monero I want to learn about Monero in good detail. Unfortunately I am not able to find any good and complete resource which described how this cryptocurrency works.

Most of the papers I found are analyzing the anonymity of Monero. On the homepage of Monero I found this resource. However this is not explaining how Monero works, it is explaining Group signatures which are used by Monero. Still its not explaining how everything works together.

Since Monero is based on the CryptoNote protocol, you should take a look at this resource and the standards here


Help needed after best friends death to retrieve wallet Hello hopefully can help me and my friends mum out.
My best friend past away suddenly just before christmas and i have started to sort out his affairs for his mum who is 80 years old. I know he has got a monero wallet. We have his mnemonic word but not his password there is a file on his computer called wallets inside are flies with his name on and one with his name and keys.sorry but i haven't got a clue what to do to get access to the wallet. i can provide a death certificate etc.
please help

You can recover a wallet with just the mnemonic seed. This should help: How can I recover a wallet using the mnemonic seed?


Monero address - is it safe to share? Someone wants to add funds to my account. Please advise if it's safe to share my Monero Wallet Address with them.
My underlining concern is - can they withdraw funds from my account with my address?
Finally, what else can they do with it?
Thanks,
Mr Magic!

Please advise if it's safe to share my Monero Wallet Address with them.

Yes. It is safe to share a wallet address with someone who wants to send you money. If you don't give them a wallet address they cannot send you money.

...can they withdraw funds from my account with my address?

No. They would need your private keys (or your seed to restore) to spend your money. Your wallet address (or a subaddress) is only good for sending funds to.


Can the sender of the transaction find out via any blockchain explorer, how much money he sent? The sender has all 4 keys and can have the destination address, but does not have the tx_key, is there any way to find out, how much money he sent in a transaction using any blockchain explorer?

Or can the sent amount be found out only by the recipient?

Using your spend secret key, you can calculate the key images for all your outputs. Using your view secret key, you can see their amounts. When you check the outgoing transaction in question, you can see which outputs of yours were spent by looking up the key images. This gets you the amount.

A block explorer does not have your secret keys, so is unable to see this.


Why did the total network hash rate drop by 50% after 0.10.1 release? According to coinwarz.com chart, the total network hash rate dropped from more than 70MH/s to below 35MH/s on December, 13th 2016, right after 0.10.1 has been released. It smoothly recovered and is again above 50MH/s, but still far below it's highest levels above 80MH/s.

In the release notes I can't find any (technical) reason for that.

The network hash rate never reached 70 MH/s (I don't think it even reached 60 MH/s, though it came close), so this points to a bug in the site you're looking at. It seems likely that this is related to the switch in block target from 60 seconds to 120 seconds a while back. Some sites never noticed, and started reporting wrong difficulty. Maybe this site updated their logging at that time.

To see the "other side" of the problem, look at http://chainradar.com/xmr/chart, look at the difficulty chart, zoom out to "all", see the (false) bump from less than 1 billion to 1.9 billion on the 20th of march 2016, which is the hard fork that changed the block target.


Using sneurlax/monerojs and I'm having a problem connecting to wallet Here is my code:

const Monero = require('monerojs');

var daemonRPC = new Monero.daemonRPC({ autoconnect: true })
.then((daemon) => {
    daemonRPC = daemon; // Store daemon interface in global variable

    const walletRPC = new Monero.walletRPC() // Connect with defaults
    .then(wallet => {
        walletRPC = wallet;
        walletRPC.create_wallet('monero_test_wallet', '')
        .then(new_wallet => {
            walletRPC.open_wallet('monero_test_wallet', '')
            .then(wallet => {
                walletRPC.getaddress()
                .then(balance => {
                    console.log(balance);
                })
                .catch(err => {
                    console.error(err);
                });
            })
            .catch(err => {
                console.error(err);
            });
        })
        .catch(err => {
            console.error(err);
        });
    });
})
.catch(err => {
    throw new Error(err);
});

And my error:

(node:8373) UnhandledPromiseRejectionWarning: Failed to autoconnect to wallet
(node:8373) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:8373) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I'm a newbie, so help would really be appreciated. Thank you so much in advance!

As you are not specifying the wallet details (port, host etc), that library uses the defaults:

class walletRPC {
  constructor(hostname = '127.0.0.1', port = 28083, user = undefined, pass = undefined, protocol = 'http', network = 'mainnet') {

Therefore, you would need to have started the monero-wallet-rpc, on the same host, with something like:

monero-wallet-rpc --rpc-bind-port 28083 \
    --disable-rpc-login --wallet-file your-wallet --password your-password

Or to start without an initial wallet like:

monero-wallet-rpc --rpc-bind-port 28083 \
    --disable-rpc-login --wallet-dir /some/path


How to compute block weight? To compute fees we need the median block weight for 100 blocks (AFAIK). I was wondering how exactly is the block weight computed? Is it just the sum of weights of all of its transactions? Or are other things also used to compute it (like maybe the blockheader)?

The block weight is indeed the sum of the transactions it contains (including the coinbase transaction).
For most transactions, the weight is the size in bytes. For transactions with more than 2 outputs and bulletproofs, weight is adjusted up, see details in get_transaction_weight in src/cryptonote_basic/cryptonote_format_utils.cpp.

You do not normally need to compute fees yourself, this will be done automatically. Moreover, recent versions of Monero will return a new transaction's weight via RPC (as well as its fee).


What is the 'base point' (G) from the whitepaper and how is it represented as a single hex value? The white paper introduces G, aka the base point, as G = (x, −4/5).
I have two questions:

what is x? Is this the x from the elliptic curve (is it a variable)? If so, how is a private key aG computed?
A point has two coordinates (x and y). How is a point represented as a 256-bit value?

G is the base point of the Ed25519 elliptic curve. The x coordinate is not written explicitly because it can be found back using the y coordinate, the sign of x and the equation of the curve (x is positive for G).

Points on the Ed25519 curve are represented by 32 bytes. These 32 bytes are in fact the little-endian representation of a 256-bit number.

bits 0 to 254 for the y coordinate
bit 255 indicates the sign of the x coordinate

Therefore the hex string representing G is 5866666666666666666666666666666666666666666666666666666666666666.

There are more info about this base point in https://crypto.stackexchange.com/questions/27392/base-point-in-ed25519


Monero GUI privacy info If i install GUI in advanced mode with local node, when i import seed , can anyone see which wallet is being opened besides me?
if I open GUI wallet in simple mode and use remote node with imported seed, can anyone see which wallet is being opened?

Given - no transactions are being made, just balances check
Thanks

No. Unless they have some kind of access to your local machine of course.
No.

The issue main issue with using a remote node is the operator can log (and associate), your IP address to your transaction(s). That and you're trusting they serve up valid blockchain data.


Does each node have a maximum number of peers? How many peers can each node be connected to simultaneously? Is the maximum the same as the number of full nodes on the Monero network? Are there any performance benefits of limiting the number of peers of a full node?

A node will connect to up to 8 peers by default (P2P_DEFAULT_CONNECTIONS_COUNT in src/cryptonote_config.h). I think there is no set limit of incoming connections, though if a lot of peers try to connect, you might end up hitting your open files quota.

The more peers you are connected to, the more traffic you will have to propagate blocks and transactions. If many of those peers are not up to date and are syncing historical blocks, then you will be sending a lot of data. The upload and download rates can be throttled via the --limit-rate-up and --limit-rate-down bitmonerod command line switches (adjustable at runtime in the daemon console with limit_up and limit_down).


Try to send XMR to Bittrex My wallet gives me with balance:

balance

Balance: 5.530000000000, unlocked balance: 5.530000000000

I feel confident, that a transfer of 5 XMR will cover the transaction fee.

At Bittrex, I learned my [Base Address] and [Payment ID]

I tried:

transfer 1 [Base Address] 5 [Payment_Id]

and keyed in my wallet password. I got an empty line as reply. Not sure, if that means WAIT, or if it means FAILED.

I tried then balance again, which shows me the initial answer.

With show_transferes I only see incoming XMRs.

Maybe I am just too impatient. How long do I need to wait? Am I using the right way to transfer and check the transaction?

The instructions, simplified go like this (brackets indicate optional arguments):

transfer [<priority>] [<ring_size>] <address> <amount> [<payment_id>]

Your transfer command attempts a ring_size of 1. The default (and minimum) ring_size is 5.

If you want a priority of 1, it would be:

transfer unimportant <address> <amount> <payment_id>

Or, you would first set priority 1 to make all transfers unimportant (low fee),

then transfer <address> <amount> <payment_id>


Why do we have MLSAG when we only need two keys? If I understand correctly, MLSAG is being used only when we have two keys. Is it being used in other places when we have maybe three or more keys?

To clarify, by two keys I mean we are trying to prove ownership of the private key for two public keys (P1, CommmitmentToAmount).

I may be reading the code wrong; but it says MLSAG unless MLSAG is being used to mean 2-Key MLSAG and the general case of n-keys?

Edit to clarify:

"two keys" refers to the vector size being 2, however we can have N of these vectors due to things like decoys

Why do we have MLSAG when we only need two keys?

We have to sign over more than one set of keys - the private keys for the inputs (real and decoys) and the private keys to the corresponding commitments.

An MLSAG signature fulfills this need - a signature over a set of N key vectors, not simply two keys. It is used to prove the signer knows the secret keys to an entire key vector.

Section 2.2. in the original RingCT paper describes this:

  The intent of the MLSAG ring signature is the following:

  • To prove that
  one of then signers knows the secret keys to their entire key vector.

  • To enforce that if the signer uses any one of their m signing keys in
  another MLSAG signature, then the two rings are linked, and the second
  such MLSAG signature (ordered by the Monero block chain) is discarded.


How to reduce the CPU consumption of my Monero node? I have both a testnet and mainnet node running on my Intel i7 CPU, and the CPU is completely maxed out, leaving little room for my other services. Given that the nodes are both in complete sync, what flags could I use to reduce the CPU consumption?

Thanks

The nodes only really consume high amounts of system resources upon syncing large amounts of blocks. Thus, if you don't leave them running continuously, and only start them up occasionally, they will have a larger number of blocks to sync and will therefore require high amounts of system resources.

The simplest fix is to leave them running continuously - which is how they are designed to operate. Otherwise you can use make use of various tools, such as cpulimit.


How would a transition from cryptonight PoW to cuckoo cycle work? What would be the smoothest transition for changing the PoW? Miners would need to be given a heads up to install new software but how would the switch over happen in practice? The block before the fork would be cryptonight and the block of the fork would be cuckoo cycle. I can only think of maybe having both the cryptonight code and cuckoo cycle code available in a miner and have code checking for what block it is so the miner knows what PoW to use. Later miners could just use a miner with only cuckoo cycle because cryptonight would no longer be needed after the fork period.

Yes, that's basically what would happen if Monero switched to any other PoW. A good example is Vertcoin's switch from Scrypt-N to Lyra2RE (and then to Lyra2REv2).

Essentially, the changeover works like every other hardfork in the network. A future block height would be picked as the changeover point, after which the proofs of work in the block would have to follow the new algorithm. Node software would have to maintain the capability of verifying the cryptonote PoW as well as the new one because new nodes would need to be able to verify the work in all the blocks before the fork. Mining software would be able to abandon all cryptonote related code, though.

Note that as of now, my understanding is that Cuckoo Cycle can't be pool mined, which means the transition would have to have miners ready to start solo mining at the right height. This would be an issue that would have to be thought out carefully.


Why AVs reject miners? I have been trying to install miners on my windows, but mostly detected as a threat by AVs.
Why are most of the miners blocked by Antivirus programs?
Is there any miner which has no problem with Antiviruses?

I don't know of any AV software that doesn't detect miners.

If you want to know what you can do so that AV software doesn't detect a miner, take a look at my answer here


Where can I get information on network congestion? I've had a mining reward sitting at 1/60 confirmations for 5 days. I have also been unable to complete transactions due to timing out.

Usually, a default, lower priority transaction will make it. The last couple days, not even a Fast priority transaction will get through on time.

I have been using the latest monero-wallet-gui on Linux, as well as the updated monerod.

Is this a network problem?

There's been no noticeable congestion in the last few days. One way to see this is to use the bc_dyn_stats command, which takes the number of blocks to consider for the stats. Here, we see the stats over the last 5000 blocks (with 720 blocks a day target, this is about a week):

bc_dyn_stats 5000
Height: 1407694, diff 30128085264, cum. diff 3696203931783216, target 120 sec, dyn fee 0.000252520000/kB
Last 5000: avg. diff 29701519077, 119 avg sec/block, avg num txes 5.3806, avg. reward 6.451334569868, median block size 54240
Block versions: 5000 v6
Voting for: 5000 v6

We see the median block size is just 54240 bytes, and the minimum block size limit is 300000 bytes, so there is plenty of space to spare. Of course, this does not mean there can't have been a massive glut at some point, and little traffic for the rest of the week, but that seems unlikely.

About the "mining reward sitting at 1/60 confirmations for 5 days", two things are important to note: First, transaction traffic (ie, congestion) has no real influence on the speed at which blocks are mined. Whether or not there is heavy use or light use, block time will continue to target 120 second (you can see the actual average was 119 second per block over the last week's worth of blocks, pretty close to target). Second, if a block you mined 5 days ago is still not seeing any further block, then either you're most likely disconnected from the network. This could happen if you're not finding any peer, or because you and the peers you find don't agree on the consensus rules. Note a fork happened a few days ago, on the 16th. I think you might be running Monero 0.10.3.1 ? If this is the case, you're out of date, and you may be mining on your own lone fork, and you need to switch to 0.11.0.0 to be able to follow the network again.

About transaction priority, it's very unlikely that a higher than default priority (and thus fee) will not be mined quick. The vast majority of transactions use the default fee, even in a glut, so a higher fee will be mined pretty fast - again, assuming you're on the correct fork, where miners are working.


I have the impression blockchain reorgs are more prevalent on testnet? They also seem more significant if they happen, e.g. I just see REORGANIZE on height: 839127 of 839203 in the log file, which is quite a number of blocks. Can anyone comment whether these observations are a correct / typical (or an exception)?

If that is so, why is testnet more "vulnerable"? Is it because the network's hash rate is massively lower on testnet vs. mainnet? Intuitively, I would have thought it is simpler to agree on the longest chain if there are fewer nodes, but maybe that is flawed logic from my side?

FYI: I have read this explanation already, but wondering what the differences are with respect to testnet vs. mainnet.

In theory, yes, fewer nodes should make things easier to agree upon, but in practice, that's not always the case. A few things might contribute to a big reorg on testnet that wouldn't usually happen on mainnet:

The testnet's hashrate is massively lower than the mainnet. As in, I could attack the network with my personal computers alone and have way more than 51% most of the time.
As a result of 1., new person joining the network might bring enough hashrate to accidentally "attack" the chain, meaning they might start mining on a different top block than the rest of the chain and cause confusion on the network for a while.
Alternatively, someone might intentionally attack the testnet just to try out things or test for robustness.
Most likely, nodes on testnet are not optimized for connectivity, etc. I doubt there are many nodes running on cloud services like AWS for instance. As a result, the latency problem described in the linked post is likely exacerbated, and so the few miners on the testnet are probably more likely to end up on different chains.
Building on 5, lets say there are basically 2-3 people mining on testnet with roughly the same hashrate. If they end up on different chains, it's decently likely that they will occasionally diverge on what they think is the longest chain and continue to disagree for some time, as both chains might keep up with each other within the latency lag window described. More miners would actually help to mitigate that issue, as blocks would be propagated from more locations around the world, and thus have more variance in latency between miners.

There are probably some other reasons as well, but these are the ones that come to mind right away.


Generate an integrated address from a different wallet's standard address I am attempting to generate an integrated address from a standard address, via an RPC call to a monero-wallet-rpc instance with an unrelated wallet. It seems I always get back an integrated address from the default address in the loaded wallet.

Is is possible to generate an integrated address for a standard address that is totally unrelated to the loaded wallet?

I am running

{"jsonrpc": "2.0","i": "0","method": "make_integrated_address","params": {"standard_address":"55LTR8KniP4LQGJSPtbYDacR7dz8RBFnsfAKMaMuwUNYX6aQbBcovzDPyrQF9KXF9tVU6Xk3K8no1BywnJX6GvZX8yJsXvt", "payment_id": "5626bb63c38aec3c"}}

which returns

4DKZNCZKW2MguWaxD3AnycfqJAdRMMy17iyAVunUBKVNAKgn41PZrNkSWQybGjkpXvfL553pN5aMdWn5Bq1DkupXi1bt4GJou4g3an4XCz

and then

{"jsonrpc": "2.0","i": "0","method": "split_integrated_address","params": {"integrated_address": "4DKZNCZKW2MguWaxD3AnycfqJAdRMMy17iyAVunUBKVNAKgn41PZrNkSWQybGjkpXvfL553pN5aMdWn5Bq1DkupXi1bt4GJou4g3an4XCz"}}

which returns

43ctMPjptkqguWaxD3AnycfqJAdRMMy17iyAVunUBKVNAKgn41PZrNkSWQybGjkpXvfL553pN5aMdWn5Bq1DkupXUfpSmcn

The only way, via RPC, is to load a wallet with monero-wallet-rpc and call the make_integrated_address method. This accepts either no address or a supplied address, and a payment ID.

However, depending on your use-case and with a little code, it is fairly simple to create an integrated address from a given standard address and payment ID. The format is described in this answer.


If I'm solo mining from the GUI, am I still helping the Monero network even if I don't ever "win" any blocks? I've been mining everyday for about 4 or 5 weeks now from the GUI, where you can just click the "advanced" icon and then click "start mining" icon. It asks me if I want to use the recommended # of threads which is 2 and I always do so. At bottom of screen I average only about 300 H/s and that's only about 1 in 10,000 chances of getting a block for a reward.
I assume I'll never earn anything doing this but I keep doing it because I've read things like "Solo mining helps strengthen the Monero network", "The more people that mine the harder it is for the network to be attacked", and "Every little bit helps".
So I was recently wondering, if I never work out a block, how am I helping mine anything? Hence, how am I helping the Monero network if my computer is never finding any block solutions? Am I helping the network at all?
Thank you!

It depends on what you call "helping" here. It will become apparent with an analogy:
Imagine Alice lost her wedding ring on the beach. She's distraught, and isn't sure where she lost it exactly, but wants to find it. She shouts "$100 to who finds my wedding ring", and some of the beachgoers nearby start looking.
Now, it's a small ring, there aren't that many people looking, the ring may have been covered by a layer of sand already, etc. Most people will not find the ring. Only one person will. call him Bob. if the search lasts long enough. But is only the person who finds the ring helping Alice ? If none of the people who don't find the ring had not searched, Bob would still have searched the same area and found the ring, but it was  not known in the first place that the ring was in the area where Bob ended up looking.
Now if Carol also loses her wedding ring on the beach and people start looking again, the same will happen: only one person will find it, but the more people look, the faster the ring will be found. So in that sense, everyone is helping speed up the search, even those who do not actually find any ring.


I see gray inactive peers. Will they be recorded forever? I know that white peers are active peers on the latest version and gray peers are either on an unsupported version or inactive.

In my understanding, my computer connected to all of these peers directly at some point (there is not a shared list of gray peers). Will I always have a copy of these peers? Where are they stored?

Until I2P is implemented, is a possible privacy concern that every person running a node will have their IP recorded by the other peers? Could a malicious individual attempt to correlate spending patterns with the times a node is online?

There is a limit of 5000 entries (P2P_LOCAL_GRAY_PEER_LIST_LIMIT), and they are stored in p2pstate.bin, which is in your daemon's data directory (typically $HOME/.bitmonero).

It is a privacy leak if you connected via clearnet. If that is a problem to you, you can run your node through Tor (see the instructions near the end of README.md in the monero tree).

Note that there being a limit for the gray peerlist does not have (much) privacy implications since you can assume a network adversary will not keep a limit.


Mining Monero with NvidiaGTX1080 Is it profitable to mine Monero with GTX1080?
And what would be the best hardware to mine it with?

B.R
Jan

You can have a look at the hashrates of various GPUs and CPUs on monerobenchmarks.info or google docs monero gpu/cpu comparison.

The GTX 1080 should get around 590 H/s, which at the current difficulty should get you around 0.04 XMR per day.

Whether this is profitable or not depends on your electricity costs, at $0.12/kwH, you should expect the card to cost about $0.51 in power per day to run (not including the rest of the system).

You can use the cryptocompare mining calculator to check things out for yourself.

Have fun :)


What is the best Python library for hashing Cryptonight? What is the best Python library for hashing Cryptonight hashes and building mining software?

At this time, the best Python library for hashing CryptoNight is still the py-cryptonight, a Python CryptoNight implementation. This library has the crypto stuff in C/C++ (lifted straight from the Monero code base) and compiled into the Python library.


How to know when I would get any profit by Monero mining program? I am an absolutely newb to Monero and Blockchain.

I download the Monero GUI program from https://getmonero.org/downloads/ and run on my windows system.

After sync all block to my local, I started to mine by click the mining btn in advanced tab.

The program shows that the speed of mining is 200H/s, but I have not got any Monero coin so far.

I want to know when I would get any profit?

If I pause the mining and change some config, then continue mining, is there any negative influence on mining?

The current difficulty of the network is approximately 125 billion, meaning that on average you need to calculate 125 billion hashes to find a block. At 200 hashes per second, you can expect to find a block in 125,000,000,000 / 200 = 625 million seconds. That's 20 years.

Now of course you could get lucky and find a block on your first hash but the probability of that happening is extremely low.

You would probably be better off mining to a pool - if you find a pool with a minimum payment of 0.01 XMR, you could expect to receive 0.01 XMR in about 15 days (your difficulty for that payment will be 125 billion x 0.01 XMR / 5.15 XMR, where 5.15 is the average current block reward).


How does mymonero monitor so many Monero private keys and update its balance? I'm looking to setup a XMR wallet type service, but was wondering how does mymonero scan so many private keys to update its balance as scanning can take awhile. Is there a method of scanning multiple monero private keys at once using the monero daemon? What is a fast way of scanning multiple private keys? Say I have 1000 XMR private keys to scan.

The wallet uses the daemon to retrieve the bulk transaction data that the wallet then performs computations against to scan for received funds. The wallet checks each transaction with a wallet private view key using elliptic curve operations.

You would want to modify the wallet code to read each transaction once, but then to check multiple private view keys against each transaction. A modern server could easily check many thousands of private view keys per transaction per second.

This would require you to be familiar enough with the Monero codebase to make these changes.


Number of outputs in each RingCT transaction In this answer, coin selection was discussed both pre and post RingCT.

  Once Ring CT is merged, each transaction will typically have two outputs, growing the TXO set by the same amount

What is the reason why two outputs will be most common? In what situation would the number of RingCT outputs be higher or lower than two and why?

The most common scenario is for a transaction to have an output going to the destination, and an output for change going back to the sender. Since the amounts are masked, there is no need to split them into several outputs by denominations as Cryptonote does.

If sending to multiple addresses at once, a transaction will have more than two outputs.

If there is no change, a dummy zero amount change is generated and sent to a random address, so a one output transaction is not possible right now (but the consensus will allow it).


PPS reward per share I am wondering how the pool decides how much you get for you share.

An interesting parameter might be the difficulty.

However is there any equation to calculate the payout per share?

Let's say we have a difficulty of 10000, Fee of 2% and a result time of 20 seconds.

As a miner finds shares, each share's difficulty accumulates on that miner's "account". When the pool finds a block, all miners' accumulated shares are reset to 0, and the cycle restarts till the pool finds a block again.

Upon finding a block, the block reward (minus the pool fee) is distributed to miners in proportion to their accumulated share difficulties.

So a miner finding two shares at difficulties 2000 and a miner finding one share at difficulty 4000 will be allocated the same percentage of the block reward. Finding a share at difficulty X happens twice as often as finding a share at difficulty 2X, on average.


How was the Monero emission curve chosen? The Monero block reward = (M - A) * 2-20 * 10-12, where A = current circulation.

Approximately 86% of pre-tail Monero will be mined within 4 years of its launch. What was the stated rational of the original developer(s) for selecting this particular emission curve? Where faster or slower emission curves considered for Monero after the community takeover from thankful-for-today? Was a change considered at the same time the tail emission was added?

It was chosen arbitrarily by thankful_for_today, with no research or thinking of any kind. But we're stuck with it, and since it's part of the social contract it isn't going to change:)


How to properly verify MyMonero? How do we ensure that the MyMonero executable is legit? The sha hashes are published on Github, but where is the maintainer's public key to check that he signed the executable or zip file? That's the only sure shot of confirming that the file is not tampered with.

At the moment, the releases up until now haven't been signed.
What is possible at the moment is you could clone the existing GitHub repository at https://github.com/mymonero/mymonero-app-js and build the desktop app from source. We realise this is a bit cumbersome.
That said, there will be a new version released soon with GPG-signed hashes, and all future versions will be signed in the same fashion.
Hope that helps.


How to access Monero GUI desktop wallet in MyMonero web wallet? I have Monero GUI and some XMR in this wallet, but suppose I want to access this wallet in MyMonero (without creating a new mymonero wallet and sending xmr to it), how do I do it? MyMonero requires a 13 word seed, whereas Monera GUI requires 25 word seed.

Even though MyMonero generates a 13 word mnemonic seed by default, it will accept a 25 word mnemonic seed (generated by either the CLI or the GUI) as well. There are basically two options:

You import the 25 word mnemonic seed generated by the CLI/GUI before any transactions are sent to the corresponding address. In this case you won't have to pay an import fee.
You import the 25 word mnemonic seed generated by the CLI/GUI after any transactions are sent to the corresponding address. In this case you will have to pay an import fee (of 0.1 XMR), because MyMonero has to scan the blockchain looking for transactions that belong to your wallet / address, which can be quite resource intensive.


Confused about the monero hardforks that spawned xmc monero classic and xmo monero original? On April 6th, it spawned 3 hardforks of monero supposedly.

monero original
monero classic
monero zero???

I see that monero original is just monero v0.11, but what is up with the other 2? What is the difference? Classic seems to be the same as original as its on the same blockchain. why were there different names?

As far as I know, they're all the same. There's no actual maintained fork, just the ASICs which didn't switch to another coin continuing mining on their own chain. Three (four I think ?) different people tried to "put a flag" on that in case it amounted to anything, but as far as I know, none of the Monero devs have any interest in maintaining an old version of Monero.

As far as I know, none of those repos merged the key reuse mitigations from Monero, so that tells you a lot about whether anyone is actually spending any time on those forks.


Using Trezor, trying to retrieve tx_key I made sure to check that store-tx-info = 1 before sending.

I seem to recall trying this in an earlier version and it was successful

Now I am getting a result of:

get_tx_key txid

Wallet password:

Tx key: 0000000000000000000000000000000000000000000000000000000000000000

Monero v0.14.1.0,
Trezor v2.1.0

Is there any way I can still recover it from the wallet file?

Some fixes were merged to the master branch recently, so should make the next release (any day now™).