How can I compile a mining software for my mac computer that uses an NVIDIA GPU?

You want tsiv's ccminer-cryptonight.

I've never successfully compiled it on macOS, and don't have a mac desktop anymore to test it on, but I believe a few recent Issues on github answer this question...

https://github.com/tsiv/ccminer-cryptonight/issues/9

https://github.com/tsiv/ccminer-cryptonight/issues/6

Your best bet is to try to follow the build instructions there, maybe follow up on one of those issues if you have similar problems, and see what you can do. If you succeed, you should post the full compile process here as the "Accepted Answer" unless someone else answers better than me before then.


To get your wallet to display the correct balance, click "Settings", "Info", then look for the line "Wallet restore height" and click the "(Change)" link to the right of the number.  Following the format YYYY-MM-DD, enter a date that is before the time your transactions were made and click the Ok button.  Then wait a while for everything to fully resynch.  It should update to the correct balance.


How to change the standard port for monero on linux and windows?

The monerod daemon listens to RPC commands on port 18081 by default (28081 for testnet). Wallets such as monero-wallet-cli will connect to this port by default to interact with the daemon. This default can be changed with the following monero-wallet-cli command line options:

--daemon-address a.b.c.d:N
 --daemon-port N

These will will use port N. For instance, if yo're running your webserver with a 1.2.3.4 external IP, and want to use port 8080, you'd use:

--daemon-address 1.2.3.4:8080

Note that if you allow your daemon RPC to be reachable from the Internet, you may want to set a user/password, using the --rpc-login username:password option to monerod (optional, since the daemon doesn't know your keys, only the wallet does), and use --restricted-rpc to avoid people doing things like mining on your daemon.


Example, taking your seed number:

688b988f7de513383daa61f282807fe5aabe71a639aa58b9cb6beab6f5f80a0c

Then byte swapped (and split):

8f988b68 3813e57d f261aa3d e57f8082 a671beaa b958aa39 b6ea6bcb 0c0af8f5

The first 4 bytes are:

8f988b68

Which as decimal is:

2409139048

Then:

2409139048 mod 1626 = 538 = words[538] = gesture

Which (following on from this question), is the first of the 3 words (gesture, mouth, bids), generated from the 4 bytes 8f988b68.


What to do about "Please check your wallet and daemon log for errors. You can also try to start monerod.exe manually." in the GUI

This message tells you that the GUI failed to automatically run the monerod software. This softwere's logs might have more information about why it failed to start, and the GUI is telling you to check those logs. They're typically stored in ~/.bitmonero/bitmonero.log (at least on Linux and Mac).

You can also run monerod yourself, instead of relying of the GUI automatic system. If you don't change the defaults (eg, port), then the GUI will spot a running monerod and not try to run it automatically.


Issues starting Oxen Node after installing debs package on a fresh server

Make sure /var/lib/oxen/lmdb files are owned by _loki user otherwise you would get this error. This happens when users download the Oxen blockchain manually and then start oxen. Just change ownership of all files to _loki in that directory.


The method is get_outs.

Here is an example of a query:

curl -X POST http://127.0.0.1:18081/get_outs \
     -d '{"outputs" : [{"amount":500000000000, "index":154735}]}' \
     -H 'Content-Type: application/json'

Result:

{
    "outs": [{
        "height": 141288,
        "key": "29a5f6af06999f1c61c97a415c4ac02a38be8a09be090a76fcf5abc2dad3fc1e",
        "mask": "e9aa7c81cdb5b3148fb7628063cd7a07d1add1643cedd3fa34479d859cc56265",
        "txid": "87dec17ae302c75d202ebcf7bac0d2c295573ec5976b253106fe48ee082c292e",
        "unlocked": true
     }],
     "status": "OK"
}

In addition, RPC method gettransactions return an array of offsets that uses a differential encoding, like :

"key": {
    "amount": 1111111111,
    "key_offsets": [ 103, 46, 15, 24, 36 ],
    "k_image": "6fc468a7e6205ec3acece150343a2b1971743f8292ca51b04079950d975a1da0"
}

Before querying get_outs, the array should be interpreted as

[ 103, 149, 164, 188, 224 ]


Are mixins now officially called decoys (and when did that happen)?

There's no "official" anything. The term appeared about 1.5 yrs ago and it has since caught on. Many share the thought that "mixin" is misleading.

In the "official" software, mixin got replaced with ringsize (=mixin+1)

See also: Mixin vs Ring Size


Why there are four parameters for hard fork?

Explained in the Monero source code comments.

 * @param version the major block version for the fork
 * @param height The height the hardfork takes effect
 * @param threshold The threshold of votes needed for this fork (0-100)
 * @param time Approximate time of the hardfork (seconds since epoch)


How can I accept Monero payments from my classifieds ads website with unique client information

If you're not a coder and want to allow people to pay in Monero, maybe the easiest way is to consider https://globee.com, a payment processor which allows people to pay with Monero, while settling in your choice of Monero, Bitcoin or fiat (maybe not yours though, do check).


Transfers from 3 days ago still "locked" in Monero GUI wallet

Normally, transfers are locked for 10 blocks. If yours were still locked, it means either node node was failing to sync to the chain, or the wallet failed to refresh from the node. You'd see that if the wallet was claiming the same height for a few days, though I'm not sure if it displays that promoinently.

Of course, it could also be a bug in the GUI or the monero code it uses. You may want to check the logs for the daemon (~/.bitmonero/bitmonero.log) and the GUI wallet (on the console, I'm not sure it logs to a file, but check for a monero-wallet-gui.log wherever the binary is) for errors or suspicious messages which may give a lead.


Can this be accomplished with a large USB-Stick

Yes.

...and decent write speed?

Define "decent". USB 3.1 gen 2 is pretty fast. There are loads of USB drives on the market so you'll need to research carefully which you get.

Current blockchain size is about 73GB...

No, it's more like ~90 GB unpruned and more like ~30 GB pruned. Hence you can focus your attention on speed rather than size. For example, 64 GB will be fine for the foreseeable future if you run a pruned node.


How can I integrate Monero in a website using PHP?

The file you linked is not a Monero library. At most, all it shows is a couple of examples of calling the RPC methods, for which is an easy task in any coding language. Just run the monero-wallet-rpc application and call its HTTP methods.

If you want/need to use a library that wraps that up further, for example because you don't know how to call a HTTP based API or don't want to work with parsing JSON, there are a few Monero PHP wrapper libraries, such as monero-integrations/monerophp.

Regardless what library you use (if any), you will first need to create a wallet file (either with monero-wallet-cli or the Monero GUI wallet), then on your server, run monerod (the daemon) and monero-wallet-rpc (the thing that exposes RPC methods to work with your wallet).

Another approach is to use a payment processor, such as GloBee. These have their own API but allow you to accept payments without needing to run a daemon or wallet RPC, useful if you don't have a hosting environment that you can install/run your own applications on.


Can miners know when their pool mines a block?

Yes. A pool operator gives its miners the hash of a block it created in the hopes that some miner will discover a unique solution to a hashing algorithm. If a miner finds a solution it gives it to the pool, and the pool then submits the entire block it created on the network. All the miners know the block hash and can thus verify if it is an accepted block.


Why not use bLSAG for one input instead of MLSAG?

MLSAG allows us to include more than just the set of keys. We can thus use both keys and commitments.

Quoting the paper:

  An MLSAG is essentially similar to the LSAG’s described in [8], but
  rather than having a ring signature on a set of n keys, instead, an
  MLSAG is a ring signature on a set of n key-vectors.

Currently we use RCTTypeSimple, which creates a signature for each input ring. Each ring contains public keys and commitments. This means we are creating a signature on a matrix whereby each column represents an input that has two rows. The first row contains the key, the second the commitment. A "matrix" is another way of saying "set of n key-vectors".


Recent simplewallet has an automatic refresh, every 90 seconds. If can be enabled and disabled by set auto-refresh 1 and set auto-refresh 0. To view current settings: set.

When this was implemented, I believe the default was disabled, so if you created your wallet at that time (not sure exactly when that was), this might be off, and you need to enable it. The default is now enabled.


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).


Open the basic wallet and let it synchronize
Click on the "exit" button at the top left of the window (the symbol is like a door with an arrow)
There you should see a "Change wallet mode" button


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

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

GUI

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

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

CLI

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

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


Would this be a good hardware setup for Monero mining?

GPU mining configurations often use the cheapest CPU. Thus, your CPU should be powerful enough to work with 3 Rx 480.  Yes, PCIE x 1 should work for mining but you have to buy a riser (recommended to use a powered riser).  RX 480 draws around 150W (from specification) - 200W. Probably give some more allowance when buying your Power Supply and don't go cheap on it.

Lastly, don't forget about cooling with 3 Rx 480 it could get very hot.

You can come and visit the other miners at https://www.reddit.com/r/MoneroMining/ or you can read specifically this


I'm wondering, what exactly a Monero is, speaking data wise. According to the Bitcoin Whitepaper, a Bitcoin is "a chain of digital signatures" and I think I get what that means and having read the Cryptonode Whitepaper, this hasn't fundamentally been changed in Monero.

That's right. It's the same. But in Bitcoin, one signature is checked against one public key, and in Monero it's checked against arbitrarily many keys (ring signature), thus hiding the private key used to create the signature and authorize the movement.

  What I'm wondering is: What exactly is created when a new block is found and the Moneros as reward are given out to the lucky miner? Is it just a series of bytes which propably can be represented as a string? And if so, how is the nominal amount (e.g. 25 Monero) attached to that string and how is it possible to only spend a fraction of those Monero?

A brand-new cryptographic key is created together with an associated amount matching the emission formula. That's it. Since the amount is stored as a 64-bit number, we can represent numbers from 0 to 2^64 - 1. The atomic unit is literally 1 bit. We arbitrarily pick where the decimal point will be and call that a Monero :) That's why it can be divided, because we've left enough digits after the decimal point. Fundamentally, it's really 64-bit integer math.

  Or to put it another way: What exactly is a satoshi or the atomic unit of Monero made up from?

Bits :)


Detecting the real output in ring signature

The reason we use elliptic curve multiplication is that it is a trapdoor function. This means you can multiply by a point, but you can't divide by a point. Trapdoor functions are an essential component in any asymmetric encryption scheme (i.e. anything involving public and private keys). If we didn't need a trapdoor function, there would be no point in using elliptic curves at all.

You can't look at a public key A = aG and determine the private key a by calculating a = A*G^-1 (otherwise written as a = A/G). Similarly, you can't divide the curve point I by the curve point H(P_i).

You can't ever divide one elliptic curve point by another. This is called the Elliptic Curve Discrete Logarithm Problem, and it is one of the fundamental building blocks of Monero's encryption scheme.


Find everything you asked for at https://github.com/monero-project/research-lab

I do not know how well PRs will work on that though, but do try.


Is there a way to get the latest blocks from monero rpc

You can use the getblocksbyheight, which is a binary call for speed. Or getblockheadersrange, getblockheaderbyheight. You get current height with get_info.


View only wallets only shows incoming transactions only. How to see outgoing aswell?

First and foremost, a view-only wallet with merely the private view key will only be able to see incoming transactions to its corresponding public address. A more theoretical explanation can be found here:

Why is the viewkey able to track incoming transactions, but not outgoing transactions?

As a practical example, let's say you received a 10 XMR output initially and thus have an initial balance of 10 XMR. Subsequently, you make a transaction of 2 XMR. The wallet will create a transaction where the 10 XMR output is used input, a 2 XMR output that goes to the recipient, and an 8 XMR (minus fee) output that goes back as change to the sender (you). Now, the view-only wallet will see the change as another incoming transaction and therefore show an "erroneous" balance of 10 XMR + 8 XMR (minus fee).

To get a correct balance in the view-only wallet, one has to import the accompanying key images, i.e., each output has an accompanying key image that allows the view-only wallet to check whether an output has been spent and thus show a proper balance as well. Step 1 to 6 of this guide explain you how to import the key images into a view-only wallet:

  Yes, there is. It works a bit different than in Bitcoin due to Monero specifics involving scanning for outputs with the view-key and checking the spent status by using key images.

  First, we assume you have a fully-synced node and fully-refreshed watch-only wallet on the hot computer. Also, we assume you have wallet software on the cold computer (don't need the node, just monero-wallet-cli).

  Using watch-only wallet, command export_outputs <filename>. There will be a file with <filename> created in the working folder*.
  Copy the file to the cold wallet computer.
  Using cold wallet, command import_outputs <filename>*. The cold wallet now has all the outputs and can prepare a signed key image for every one of them (unless something new was received after step 1. It won't display the correct balance because it can't check the spent status of the key images, as it is offline.

  --- Stop here if you only want to monitor incoming transfers and don't care to see the correct balance and when something has been spent ---

  Using cold wallet, command export_key_images <filename>. There will be a file with <filename> created in the working folder*.
  Copy the file to the hot wallet computer.
  Using watch only wallet, command import_key_images <filename>*. The watch wallet is now aware of spent status for each output and it shows the correct balance (unless something new was received in the meantime, after step 1.

  --- Stop here if you only want to monitor the balance with the watch only wallet. Goto 1. after each newly received funds. Continue for cold spending. ---


Cloud mining can mean a couple of things. 1) mining using a cloud server 2) browser based mining - e.g. javascript mining in a web page.

Coinpot falls into the latter e.g. browser based mining. It also claims tiny amounts of real cryptocurrencies from public faucets (which are for gifting small amounts of a currency for user adoption). You'd do better financially by wandering the streets looking for cents than using Coinpot IMO.

If you want to get into mining, download a miner such as xmr-stak and mine to one of the many mining pools.


What is the most common way currently being used to create web based wallets?

To much to explain, but in short: frotnend sends private viewkey and address to the backend. Backend scans the blockchain, using your viewkey and address for incoming transactions to you. At the same time, it makes guesses about possible outgoing transactions. Only guesses are possible, because backend does not have spendkey. Found your incomming txs are send to frontend along with possible spendings. The frontend, because it has spendkey, can filter out incorrectly guessed spendings, thus giving you the correct balance.

I can point you to full source code of a web wallet (OpenMonero) and its working example on testnet

https://github.com/moneroexamples/openmonero
http://139.162.32.245:81

It contains both fully open sourced frontend and backend, so that you can even host it yourself. The backend has a lot of comments explaining what it does. You can also make issues on github if something is not clear.


A pool update is needed for the last fork.
The patch is at https://paste.fedoraproject.org/506116/17116821/
There are updated trees which include this patch, but I do not have URLs handy.

After applying to the node-cryptonote-util tree, I think "npm rebuild" will be enough to get you going.


firstly, your wallet gets an index of where your transactions are on the blockchain. So, when you first connect to a node (remote or either) with your wallet, your wallet first scans the chain with your private view and spend keys. it then stores the index information for where your outputs are in a local file... the cache.

When you want to create a transaction, the wallet asks the remote node for a bunch of random outputs. The node then sends these random outputs to the wallet. The wallet then combines these outputs with the ones that you actually own to create a ring signature. Its somewhat more complicated than that, but thats the general idea. For instance, I know there were advancements regarding how the wallet asks for outputs, such that the remote node can't run a differential between the two sets of outputs. I think the wallet is the one responsible for picking outputs, so it requests output information for index 1,2,3,4,5,6,7. Your real output is one of them. The remote node doesn't know which one.

Then, when your transaction is created, your wallet creates a key image.


There are generally two approaches to getting Monero functionality into other languages: 1) to make use of the JSON-RPC interfaces and 2) building Monero source files and creating bindings. The former is the simplest and easiest to maintain. The latter gives more fine grained control but requires thought for portability.

Jumping back to your requirements:

  generate key pair, manually build a transaction, sign it and broadcast it to a remote node

Generating keys is fairly simple and can be done without a "monero" library.

Manually building a transaction is not as simple. This requires a running node and wallet file. This is because you will need (amongst other things) to select inputs and outputs. Using the JSON-RPC interface is definitely the best route for this.


Is it possible to restrict to scope of rescan_bc in monero_wallet_cli?

Not directly, but rescan_bc should not be needed in most cases nowadays. It used to be that the wallet's idea about what outputs are spent would get out of sync with the network, but I believe no such bugs exist anymore, making rescan_bc unnecessary.

If you rescan the blockchain by recreating a wallet from seed or keys, you will be prompted for a block height to rescan from.


The 100% part of the message means that you are connected only to nodes with at most that height, which is far in the past.

Try print_cn and see if you have any peers, and how many. This is odd that you'd be connected to only bad peers.

To try to fix the problem:

exit monerod
remove ~/.bitmonero/p2pstate.bin
start monerod again

This will cause monerod to start picking new peers, and hopefully pick at least one good one this time.


Essentially, RingCT increases the number of usable outputs to mix with and reduces the need to use multiple outputs for transactions.

The first part is easy - because RingCT hides the amount, all transactions are interchangable. I can mix a 10 xmr output with a 1000 xmr output... because you can't see the amount on the chain anymore.

For instance, in the old style, if I were to send 123.45 monero, and assume I owned a nice distribution of outputs, the transaction would be created by:

100 monero output
10 monero output
10 monero output
10 monero output

So, if I just started using Monero, its likely all of those outputs are in the same block, therefore they'd all stack in time, and it would be obvious which outputs are the real ones (ok, obvious is a strong word here). If I had a well "seasoned" wallet, they would be distributed over time. Please refer to the SE entry here

Now, with RingCT, I don't need the entire stack. Indeed, the outputs no longer need to be split into those denominations. With a ringCT transaction, if I send you 123.45 XMR, there's gonna be an output for 123.45 xmr, not 5 outputs. And I can use any of my outputs (as inputs for that transaction) that I want. Indeed, with the advent of RingCT, it will probably be the case that wallets will only maintain 1 output.

I have 145.3 xmr in my wallet, all in one output.

I create a transaction to send 20 xmr. I use my 145.3 output, and the change comes back. So I have a new single output of 125.3 xmr. That I can then mix with whatever.


Is there any way to turn a payment id into a readable message and not randomness?

It is just hex characters, so you can use a tool like this to convert it to ascii.


As of 0.10.1.0, how do you use monero-wallet-rpc?

If you previously ran simplewallet in CLI mode (or 0.10's monero-wallet-cli in RPC mode) then you would simply transition to using monero-wallet-rpc with the same flags. As always, running the binary with --help will give you a list of all possible flags.


Should the monero community look to have the dev team working on the project full time?

I'm reminded of this quote.

“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
--Upton Sinclair

No, money creates a conflict of interest. Bounties that devs can choose to accept, as well as donations is fine, but once they get a salary their loyalty is no longer to the users, it is to the salary. What if there's a critical bug that could threaten the value of XMR? what if the salary he's being paid depends on him putting down his fellow devs to get to the top? What if the other devs get jealous/envious and try to make the paid devs lives difficult?

No, a salary is a horrible idea. They'll no longer be doing it because they enjoy working on an innovative, collaborative, vibrant technology, they'll be doing it because they look forward to the pay checque at the end of the month and they'll get fucking vicious if necessary to protect it.

Bounties, forum funding and donations are good, salaries, bad.


Exchanges that support integrated addresses

Tux exchange added Monero with integrated addresses:


Explanation of the Monero Daemon running arguments

Looks like you had a previous version already running. I would close your GUI, killall monerod, ensure there are none running with ps aux | grep monero, restart the GUI (which starts a daemon automatically).


XMR not showing up in my gui wallet after refreshing wallet

Okay, so it did get solved, by just waiting for the local node to sync completely. This was weird because I would have thought that using a remote node would be sufficient. I just had to wait a day. (Longest day ever!)


All you have to do is extract the .zip to some folder and run monero-wallet-gui.exe. In case the GUI window is looking strange or not displayed, run start-low-graphics-mode.bat.

If you're already running monerod manually, it will connect to it. If you're not running monerod, the GUI will start it itself in the background (using the default %programdata% folder where to look for blockchain data).

You can simultaneously have the CLI and GUI open, and they will both talk to the same daemon. Just don't open the same wallet with both, unless you're opening a copy of wallet files.


Why did I get an error -18 whilst attempting an RPC transfer?

Given that you're attempting a transfer of over a 1080 XMR, you will likely be using a high number of outputs to fund the transaction internally, which is pushing up the transaction size. As the error message states, try transfer_split instead.

The ringsize parameter is redundant these days as it has to be 11 for the tx to be valid now. The code for the RPC method is adjusting the supplied ringsize, but in a funky way. I suggest just setting it to 11.

The documentation needs some love to keep it current.


You may well have 10 cores (or 20 threads), but you only have enough cache for 5 threads to mine, and your output is only showing 3 threads mining.


Is there a way to get a current option value from within the monero-wallet-cli?

Just type set and hit return. That lists all the currently set values.


Actually making smaller transfers fix it, I had 20.9 xmr total and started by making 5.2xmr transfers, then the cli itself break it in 3 or 4 even smaller payments with fees each, but it all when tru at the end, Thank You all for your help!


QUESTION : is it safe to use a remote monero demond (monerd)

The only risk that you incur by using a remote node, its that if the remote node goes offline, you have to rely in another remote node.

https://moneroworld.com/ this is the most popular site where remote nodes are. I guess you are using one of the nodes listed there. Feel free to read the entire tutorial over there.

If you feel paranoid about your security, use a remote node and start the daemon from your wallet-gui (or run monerod), this way you can use a remote node connection while your monerod is syncing the blockchain data.

Once your monerod is synced, delete node parameters at monero-gui and save.

If you dont want to get full node, well, use this guide Is there any way to construct a transaction manually?

Im yet to see someone robbed by a remote node. But again, if you worry about your security, use a full node. Kind regards...


What parts of Bitcoin's Lightning Network can be ported to Monero?

Lightning Network (LN) was predominantly devised as a way to scale Bitcoin (in terms of both throughput and keeping tx costs low). Some people also throw in "privacy", but that has been largely debunked, e.g. 1.

Monero doesn't have these problems, hence there is not some great need for LN with Monero.

Another much trumpeted "feature" of LN is the potential for cross-chain atomic swaps. However, this has also come up against some criticism, for example 2.

Leaving aside the questionable needs / benefits of LN, the question isn't really what or not can be "ported" due to the fact Monero is not a Bitcoin clone, but rather: is it possible to implement LN for Monero. And the answer to this right now is no. LN requires time-lock and refund mechanisms to operate. Whilst some kind of time-lock trickery could perhaps be achieved, due to the way the blockchain and transactions operate, there is no refund mechanism currently.

So,

  ... what parts of Lightning would need to be rewritten for Monero?

Monero would need non-trivial changes to be able to use the LN scheme. Then any LN daemon would need work to implement on top of the Monero blockchain. Thus "what parts" is actually a lot of both.

  Would the Lightning Network Daemon be compatible with minimal changes, for instance?

No.

  What are some things that wouldn't be compatible?

Given how tightly any 2nd layer needs to operate with any base layer, there's a considerable amount of incompatibility.

Lastly,

  Monero has been unable to directly port much of the tools and code written for Bitcoin and its forks

You say this like it's some kind of negative. There are many issues with Bitcoin's (and its forks) design and code. Monero is not a fork of Bitcoin for good reason.


If Poloniex was hacked or shutdown, what effects would that have on Monero?

It would hurt Monero users who rely on exchange wallets instead of offline cold storage.

Volume would quickly move to other exchanges such as Cryptopia, Bittrex, Shapeshift and Bitsquare. Depending on the reason Poloniex shut down, decentralized options such as Bitsquare would likely benefit the most.

No hard fork would even be considered to recover the losses of those who had funds on the exchange. Monero is immutable and such a fork would be an impossibility for both technological and social contract reasons.

From a practical standpoint, there would be no way to trace any Monero stolen from the exchange as the result of a hack. The best chance of finding the attacker would be to trace other coins he/she may have stolen from the exchange and hope the hacker confesses and returns all the Monero after being caught.


Is it possible to have a full Monero node, a Monero testnet node, and an Aeon node all on the same VPS?

Aeon has not yet integrated LMDB so the 2GB RAM is probably not enough. Although it should work (slower) if the swap is big enough.


Installation and Update of monero cli and gui

but no Walletgui file, where is it?

Looking for "Monero Wallets" folder on your disk

  Which files are created by the program on which location (Windows)? Where ist the blockchain?

On Windows the blockchain is stored in C:\ProgramData\bitmonero\lmdb. It's a hidden folder.

  How can I update the program, just copying the new files over the old?

Yes, you should make a back up if things gone wrong.


Can a new participant be added onto a multisisg 2/3 scheme?

No. Once the wallet has been finalized, you cannot change the participants. Should you need to add a new participant, you would need to create a new wallet with the old and new participants then transfer funds from the old multisig wallet to the new one.


Are there any blockexplorers that will track RingCT usage after the v4 fork?

Yes, the Onion Monero Blockchain Explorer supports RingCT. Currently it is:

  the only explorer supporting Monero testnet network and RingCT,

More blockexplorers may add support in the coming weeks but I am not aware of any specific announcements.


Is there any remote node list to connect simplewallet?

Check out https://moneroworld.com/#nodes for a current list and instructions.


How do I run a remote node on windows (so I can connect mobile wallets to my own node)

I extracted the Monero files to monero folder in C:

Right click on monerod and create a shortcut.

Right click on monerod.exe -shortcut and open "properties"

In the "target" field put in C:\monero\monerod.exe --rpc-bind-ip 192.168.1.100 --confirm-external-bind --restricted-rpc

In your router you will need to forward ports 18080 and 18081 to the IP of your machine running monerod.

I am unsure if there are any benefits to setting a password.

In addition, I made a task in task scheduler to start monerod at bootup (with the same options --rpc-bind-ip 192.168.1.100 --confirm-external-bind --restricted-rpc), and set my PC bios to automatically boot in case of power outage, this way its always running.


Is there a way to use CLI wallet non-interactively?

If you can predict the questions you are expecting the command to require an answer to, then on Mac/Linux you can simply pipe in a list of answers. E.g.

monero-wallet-cli < echo -e "response1\nresponse2"

However, this could be brittle if changes are made to monero-wallet-cli. The best option is therefore to use the Monero RPC interface, and to use something like jq to extract fields from the response.


Trying to get private view key from hash seed generated from mymonero mnemonic (13 words) in Python

Your sc_reduce32 function was using the wrong value to reduce by, and you had not reversed the endianness of your bytes. Here is working code:

import sha3

l = 2 ** 252 + 27742317777372353535851937790883648493

def reverse_byte_order(hex):
    if(len(hex)%2==1): hex = '0' + hex
    return "".join(reversed([hex[i:i+2] for i in range(0, len(hex), 2)]))

def sc_reduce32(key):
    return reverse_byte_order("%x" % int((int(reverse_byte_order(key), 16) % l)))

def cn_fast_hash(hex):
    k = sha3.keccak_256()
    k.update(bytearray.fromhex(hex))
    return k.hexdigest()

hexadecimal_seed = "852249bca4446e65501cc7f8338027ec"
hash_of_seed = cn_fast_hash(hexadecimal_seed)
private_spend_key = sc_reduce32(hash_of_seed)
private_view_key = sc_reduce32(cn_fast_hash(hash_of_seed))

print "Non-standard Seed = ", hexadecimal_seed
print "Normalized Seed   = ", hash_of_seed
print "Private Spend Key = ", private_spend_key
print "Private View Key  = ", private_view_key


Will Monero CPU mining always be feasible?

The algrithim Monero uses, CryptoNote, has a POW mechanism that makes it hard for asic miners to be developed, so that CPU mining and GPU mining will remain the standard. But the difficulty of mining coins will not be constant.

"The proof of work mechanism acts as a voting system. Thus, it is crucial that during the voting process all the participants have equal voting privileges. CryptoNote brings this equality with its egalitarian proof of work, utilizing built-in CPU instructions, which are very hard and too expensive to implement in special purpose devices, but perfectly suitable for ordinary PCs." CryptoNote


Does the Monero daemon and wallet connect with other nodes by ssl or unencrypted?

From my knowledge the connection is not encrypted, but this doesn't hurt anything because the data that is exchanged is already public record.

For example: the same information can also be found on Moneroblocks


What other cryptocurrency has implemented the RandomX PoW for mining?

Wownero and Loki are the only other currencies I know of that plan on, or are currently implementing, variants of RandomX.


Are GPUs more efficient at verifying transactions?

GPUs are pretty good at parallel execution of the same program (or similar programs, if they can be made to be the same program where some threads can "dry run" part of the program). They are much less good at running more complex code which doesn't have that much in parallel.

While mining is about doing the same thing again and again, fast, transaction verification is more complex, and less parallelizable. Besides, the basic operations are fairly diverse. A lot of comparisons.

One notable drawback is the speed hit taken by moving data back and forth between CPU and GPU. GPUs really want the same data to be uploaded once, and worked upon many times. This doesn't really apply to transaction verification, which involves different data.

Howover, some parts of verification could make sense on GPUs, such as range proof verification. For this to be worthwhile, there would have to be several transactions to verify in parallel, or verifying several signatures in parallel. Whether it is a win or not would need trying it, though.


How to upgrade Linux Monero to 0.10.3.1?

Whether you're on Linux or macOS, I personally think the most elegant way to install or upgrade the CLI software is using this method, by storing the binaries in /opt/monero, as one would typically do with optional software outside the packaging system on UNIX-like systems.
Make sure to cleanly shut down the previous version of the monerod daemon, using just the exit parameter. See also this question. The blockchain LMDB database stays within ~/.bitmonero and will be picked up by the new version where you left it with the old version. As an extra precaution prior to starting up the new version of the daemon, you could optionally either export the blockchain to a file (using monero-blockchain-export), or make a (recursive) copy of the ~/.bitmonero folder. The latter will be faster to put it back in case something broke your blockchain …
When you add --version to either the monero-wallet-cli or monerod command, it will print the version, e.g.: Monero 'Wolfram Warptangent' (v0.10.3.1-release)


Calculate the output amount using MiniNero

You haven't reduced tmp. I.e.

tmp = MiniNero.sc_reduce_key(MiniNero.cn_fast_hash(aR+"00"))

Hs in the referenced question's answer refers to Hash to scalar, not simply hash. Otherwise keccak would have been written in place of Hs.

Thus, following your experiment through with the correction, I calculate 1 XMR:

tx_pub_key = "f6d51a0cabd6a68f2c4960bc06b4132d6b937622b8954ea95851aa5f3b32c1de"
pri_view_key = "89a705a1a6427e7a19fd17a78d4a5c35bcb9ce4af74d6c180d5e39909694ab0a"
aR = MiniNero.mul8(MiniNero.scalarmultKey(tx_pub_key, pri_view_key))
tmp = MiniNero.sc_reduce_key(MiniNero.cn_fast_hash(aR+"00"))
res = MiniNero.cn_fast_hash("616d6f756e74"+tmp) #616d6f756e74 is ASCII of "amount"
amount = MiniNero.xor("54f95f7d7f4d1e2a",res[:16])[:16]
print(MiniNero.hexToInt(amount)*1e-12)

Which yields:

1.0


How does mymonero monitor so many Monero private keys and update its balance?

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.


Why does sending Monero coins out once prevent me from sending more of my remaining XMR coins immediately?

It's possible that you have a situation where you don't have enough UTXOs to independently send the second payment.

Monero uses a transactional blockchain, in that every transaction must have exactly one origin/source and one or many destinations/spends. When you either mine a coinbase transaction or have a transaction sent to you it becomes an unspent transaction output (UTXO) with a specific amount of value attached to it. If you want to spend this UTXO for the exact amount of it, you simple submit a new transaction with the chosen transaction destination. But if your UTXO has more value than you want to send, you must split this UTXO into multiple new UTXOs, one of which goes to your chosen destination and another that goes right back to yourself. (You could have chosen multiple destinations for the UTXO so that you can save on transaction fees, but this is normally more complicated and takes planning.) Since a new transaction takes time to be mined and be embedded into the blockchain you cannot spend the new UTXO that you sent to yourself, but must wait for it to be confirmed. (This is to prevent problems such as a 51% attack.)

If you know that you only have 1 UTXO and have tried multiple spends on it in quick succession then you will get the above warning. The easiest solution is to simply wait for the first transaction to timeout and then submit the next one.


Making a public Monero node with RPC open so I can connect to it from my app

Firstly, you are correctly binding to 0.0.0.0.

Next you need to make sure your firewall on your server is allowing inbound connections on the port you specified (18081). This step will vary based on what firewall you are using. For example, if you are using iptables and ufw, you would use the command sudo ufw allow 18081. Some VPS providers have a web-based firewall you would need to configure also.

Lastly, you connect to the server using the public IP address your provider assigned to your server.


How will users be notified of future updates to the beta GUI wallet?

New releases get tagged on the github page, which is currently the freshest source of info on development progress.

Shortly after, downloads would be found on the "official" project site https://getmonero.org

Also, the Monero sub-reddit usually has important information stickied as the first post.

With this kind of software, it is probably not a good idea to implement auto-check as it could become a security vulnerability.


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

First, theoretical background can be found here:

Selective transparency in Monero vs Zcash

Why is the viewkey able to track incoming transactions, but not outgoing transactions?

What is the TX key?

Is there any way to construct a transaction manually?

Basically the gist is that you know r (the private tx key) and A (the public view key, which is part of the public address). As a result, you are able to compute the shared secret (rA = D) and "decrypt" the transaction.

If you are using the CLI, you ought to perform the following steps:

Enter the following command: get_tx_key <transaction_hash>.
Copy the output of the get_tx_key command.
Type check_tx_key <transaction-id> <txkey> <recipient-address>.
If this checks out, the CLI will show the following message: <Recipient-address> received <amount> in txid <transaction-id>.

Alternatively, you could use these steps:

Enter the following command: get_tx_key <transaction_hash>.
Copy the outcome / output of the get_tx_key command.
Go to this tool, which was created by core-team member luigi1111. Furthermore, "Note: this site operates completely on client-side Javascript; no data is ever sent to the web server."
Enter your transaction ID / hash in box 1. Transaction Hash:
Set box 2. Private Key: to Tx Private Key
Enter the private transaction key you obtained in step 2 into box 2. Private Key:
Enter the public address of the recipient in box 3. Recipient's Public Address
Press on Check.
If it shows This address owns output        x with pubkey: y for amount: z it proves you correctly sent your XMR to the recipient.

I'd personally advise to use the former method, as it's more privacy preserving.

If you are using the GUI, you ought to perform the following steps:

In the GUI, go to the History page and click on details of the transaction of interest.
A window should pop up that shows the private tx key. Copy it.
Click on the Advanced tab and subsequently click on the Verify Payment tab.
Enter the public address of the recipient in the first box, the transaction ID in the second box, and the private transaction key you copied in step 2 in the third box.
Press on Check.
If it checks out, it proves you correctly sent your XMR to the recipient.

Alternatively, you could use these steps:

In the GUI, go to the History page and click on details of the transaction of interest.
A window should pop up that shows the private tx key. Copy it.
Go to this tool, which was created by core-team member luigi1111. Furthermore, "Note: this site operates completely on client-side Javascript; no data is ever sent to the web server."
Enter your transaction ID / hash in box 1. Transaction Hash:
Set box 2. Private Key: to Tx Private Key
Enter the private transaction key you obtained in step 2 into box 2. Private Key:
Enter the public address of the recipient in box 3. Recipient's Public Address
Press on Check.
If it shows This address owns output        x with pubkey: y for amount: z it proves you correctly sent your XMR to the recipient.

Again, I'd personally advise to use the former method, as it's more privacy preserving.

Unfortunately, MyMonero currently doesn't have an option to obtain the private tx key. Therefore, it is currently impossible to use aforementioned method.


A good place to start would be https://getmonero.org/home, try looking at the various topics under Knowledge Base. If you have further specific questions, you can ask on Reddit, IRC, or here.


You use port 18089 in config, but try connect to port 18081.
Also you need set your extetnal ip and config your routers and firewalls to redirect port 18089 to you daemon host.


Why won't monerod.exe connect to daemon?

I solved the issue by connecting to a remote node.  I used the following as a guide.

How to connect to a remote node within GUI wallet:

[https://web.getmonero.org/resources/user-guides/remote_node_gui.html#:~:targetText=Connecting%20to%20the%20node%20from%20the%20GUI%20wallet&targetText=Click%20on%20it%2C%20and%20you,you%20want%20to%20connect%20to.][1]


Is xmr.to fast enough for 15 minute time window on bitpay.com?

To add to expez's answer, BitPay should already stop the 15 minute countdown once it's found the broadcasted Bitcoin transaction.

To my knowledge some services that use BitPay require confirmation(s) but it shouldn't be an issue as the invoice shouldn't expire after the tx has been broadcast (but not yet confirmed).


XMRig will always use 100% of a core, it is not possible to go lower. max-cpu-usage does not limit usage on a core, but only limits how many of your total cores are used and it is overriden by the threads option.

The best you can do is to set cpu-priority to 0, this means all other processes will be preferred and XMRig will only use unused CPU resources - at least in theory, in practice you might still experience some slowdown.


It's possible that when you first set up the wallet you chose Simple Mode (bootstrap) or Advanced Mode, both of which require downloading the blockchain to your computer. If so, there is a Simple Mode (without bootstrap) that instead of downloading the blockchain, connects to a remote node, allowing you access to your funds almost instantaneously. It should be noted that this may compromise some aspects of your privacy. The remote node will have access to your IP address for example (unless you're using a VPN or ToR).
To check your wallet mode, go to Settings > Info and see Wallet mode:

If you are not in Simple Mode, and are happy to accept the trade-offs that come with using a remote node, you can switch your wallet mode.
If your wallet is open, you need to close it first. Go to Settings > Wallet > Close this wallet:

The main menu (Welcome to Monero screen) will open. At the bottom left, click on Change wallet mode button, and on the next page select Simple Mode. Next, open your wallet file again.

The wallet should automatically connect to a remote mode and show your balance, but in the event it doesn't there's info on how to find a remote public node in the guide on getmonero.org: https://www.getmonero.org/tr/resources/user-guides/remote_node_gui.html


Why does proposed transaction fee fluctuate heavily sometimes?

It all depend how much outputs are needed to build-up you transactions.

A higher mixin transactions can result in a smaller size transactions because it so happened that it needed less outputs to build it.

Even if the amount are very close simplewallet might have needed a complete different set of outputs. Sometimes resulting in widely different transactions size to the point (I guess) it has negated the benefit of a smaller mixin.


Distribution of number of inputs and ouputs per transaction over time

For non coinbase transactions, from block [1000000,1500000] grouped by 100000 blocks (green bars corresponds to "recently", i.e from block 1400000 to block 1499999 included).


sc_reduce32 ... is it really supposed to be that complicated?

I experimented with this using javacsript biginteger library and it is what it says - just a mod l operation. Endianness and encoding could make some confusion, though.

From your code it looks like the difference is just in the input/output format. One uses a string with base16 encoding, and the other one uses a byte array. They should both represent the same number, though.


How can I save the destination address of my transaction?

In the CLI the command is as follows:

set store-tx-info <1|0>

Where 1 as argument will store transaction info. Note that for newly created wallets it is automatically set to 1. Thus, newly created wallets will automatically save transaction info.

  I am not sure if it's the actual address that is saved or the one-time public key,

It will save the transaction hash, amount, private transaction key (you can obtain this by using get_tx_key <transaction-hash>), recipient's address, and payment ID.

Note that the GUI will automatically save transaction info as well. If you go to the History page and click on Details of a particular transaction, it will show all relevant information.


How to set up a mining pool on Ubuntu 20.04?

See nodejs-pool for a javascript pool or monero-pool for a C based pool.


How might one stop pruning when started in monerod?

One does not. Pruning is a long one shot operation.
If your database is too large, pruning in place will not actually decrease the file size. You will need to resync from scratch with --prune-blockchain for this, which neatly moots your question in the first place :)


What encryption algorithm is used for the wallet.keys file?

ChaCha8; the key derivation is done with CryptoNight.
https://github.com/monero-project/monero/blob/e06530e2d97a0a44f1f954b0d9a49e522e2ca74a/src/wallet/wallet2.cpp#L1362

Specifically note L1429 which calls https://github.com/monero-project/monero/blob/e06530e2d97a0a44f1f954b0d9a49e522e2ca74a/src/crypto/chacha8.c#L43


Verifying a payment in Monero in an automatic manner, without a third-pary and without full node?

That would not work, since you cannot check the transaction id is on the chain or not without a node or a third party to do the check for you, without even getting into checking whether that transaction id does pay you.
If you really must have no node and no third party, then...
The customer sends you the block header the tx was mined in, plus the ordered transaction id set in that block, which includes the tx the customer sent you. The customer also sends the actual tx.
Then you can verify that the transaction hash is in the claim tx id set. Then you can calculate the hashing blob, and thus verify the block yields a hash below a high difficulty which corresponds to the rough Monero difficulty.
Doing the above ensures about as much energy was expended in creating the block as was on the real Monero network, so it is unlikely someone would expend thats much work without actually mining. Of course, it can still mean the block was orphaned.
If this is not enough, you can request N blocks prior to the block with the tx, and do the same for those N blocks too.
Once this is done and you know with reasonable certainty the tx is certain to be in the chain (and thus valid), you can check the tx actually pays you and how much. For this, the customer would also send a proof generated by get_tx_proof, which you'd check using check_tx_proof.
If you're worried about the block being orphaned, you can also require M blocks after the block containing the tx, and do the same block checking work for those (do not forget to verify each block does point to the block hash of its purported parent). This will of course mean a delay before such a proof can be made.


How long are mining rewards locked on testnet?

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

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


Monero GUI isn't letting me create wallet from Ledger (monero-wallet-gui)

This ended up being a forgotten old version of the monero wallet from 2017 which wasn't overwritten when I installed the latest one.  Everything is working now


As Monero is not a Bitcoin fork and uses its own RPC API, I'm convinced there is no such thing as a RPC proxy converter out there.
However, you could read the wallet RPC guide (pending refresh) to build your own, with the methods that are actually convertible.


Approximately how many developer hours have been spent on Monero so far?

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.


Doing a Send Transfer using monero-cli v0.14.0.2 with long payment id enabled, still getting errors on send

Reason why is the format:

  transfer < receiver_address > < amount > < payment_id >

I had the payment id and amount swapped! Absolutely noob unfriendly...


What does output of running ccminer for mining monero actually means?

Stratum detected a new block

Stratum is a protocol for miners, wallets etc to talk to nodes. It's not specific to Monero and it is used for other coins too. It's just informing you that the miner has started on a new piece of work.

  accepted: 1/1 (100.00%), 320.07 H/s (yay!!!)

When miners mine in a pool, they're not working together. You're doing the same work as if you were mining on your own.

Think of miners going through a load of random numbers, doing "maths things" to them and seeing what comes out. If the number that comes out is greater than the difficulty, they've found a block (or a share). The problem is that the difficulty on the network is very high, most miners would never see a block despite all of the work they're putting in.

Pools give miners reduced difficulties, this means that not every share found is a block. If it's a block, it's mined by the pool and then all of the miners get rewarded based on how many shares they've submitted (and the difficulty of the shares). If it's not a block, the pool just gives you a thumbs up for trying and you carry on working.

I'm not sure if that was a terrible explanation or not, but to summarise, shares are just a way of miners to show that they are attempting to find blocks.

  Also, I wanted to know how much block needs to be accepted to reach the payout of 0.5 XMR.

It's not possible to know just from the number of shares submitted, it also depends on the difficulty. You could submit hundreds of shares with a low difficulty and then still earn less than somebody submitting only a few shares with high difficulty.


Implementing monero accepting for online merchant with monero-python

Conceptually, yes. The defaults for wallet.incoming return confirmed transactions. Depending on the rest of your architecture, you may want to make use of unconfirmed transactions (e.g. mark product as sold but not ship until the transaction is confirmed), if this is the case you'll need to also make use of the parameters for incoming: wallet.incoming(unconfirmed=True, confirmed=False).


As stated in your question, precision in answering this impossible. The most detailed estimate I have seen is from almost 3 years ago and updated 2 years ago.

Based on the continual growth of all community metrics such as bitcointalk metrics, Reddit subscriptions, network hash rate, node count,
 transaction data and development activity the userbase has grown by orders of magnitude since 2014.

Assuming a similar distribution to 3 years ago and some partial divestment of some of the largest holders for diversification or other reasons I think possible distribution estimate would be a 20x multiple of Case "A" 2014 estimated users (approximate increase in r/Monero subs between then and indirectly supported by MyMonero account numbers much higher than r/monero subscriptions according to fluffyponyza).

Assuming there are now 20x the 2014 estimated (5,200) we are now looking at about 104,000 users. Only July 20th 2014 when the original estimate was made there were about 2.2 million XMR and today there are about 14.5 million XMR. (14.5/2.2)/20 = a mean XMR holding of around 1/3 the mean size from 2014 (to accommodate a balance between 20x more users and the increase in total XMR supply. This means that although there are many more Monero users now compared to 2014, the additional users (and previous users that have since redistributed some or all of their coins) will now be more heavily weighted towards smaller sized average holdings.

Based on the above, mean XMR holdings may be about 140 coins (total current supply/estimated users) with a very large margin for error.  There are likely to be very few "Leviathans" with the great majority of users being "herrings" based on user growth and reasonable redistribution estimates.

Many users never use Reddit or MyMonero and instead rely on the official CLI for which download counts are not recorded. On the other hand some people may have multiple MyMonero or Reddit accounts, making those numbers unreliable as well. Because Monero is so private, we will never know for sure what the exact distribution looks like.


The math behind output checking is as follows

When output is created (by the sender), it's created as:

P = H_s(rA||i)G + B,

where P is the output, H_s the hash to scalar function, r the TX private key (randomly generated by the sender), A the recipient public view key, i the output index in the transaction (|| is concatenation), G the basepoint of the elliptic curve, and B the recipient public spend key.

Thanks to elliptic curve arithmetic, rA == aR holds true, where a is the recipient private view key, and R is the TX  public key. This is what is know as shared secret since only the sender and recipient know it but they never had to communicate it to one another.

When the recipient is looking for his outputs, he's doing, for each TX on the blockchain:

Get the TX public key R, outputs P and output indexes i.
For each index, compute P' = H_s(aR||i) + B
Compare P' == P ?
If equal, it's a match, continue to decode the amount.

For implementation, tha xmrchain block explorer is actually open source and you can inspect the source.

Also, there's a TX checker on Luigi's page, which is another implementation of the above.

Note that PR-2056 will change this somewhat for some cases, so it's worth looking into.


How to "unpack" a Monero integrated address using the command line?

This site helped:

https://xmr.llcoins.net/addresstests.html

The relevant code is here:

https://xmr.llcoins.net/js/site.js

on function addrCheck().


Is the entropy for the mnemonic seed and the private spend key exactly the same?

The seed is another representation of the private spend key. Because of this, entropy of the seed must equal the entropy of the private spend key.

Wallet recovery is easy with either the private keys or the mnemonic seeds.

The benefit of using mnemonic seeds are that you can in theory memorize them and when entering the data, it is easier to avoid making typos when using words instead of long strings of alphanumeric data.


Upon running monerod, I get two errors "cryptonote_protocol_handler.h:94 Unkonown command:1007" and "net_node.h:150 Unkonown command:1007"

Someone is running a node that supports fluffy blocks and running on mainnet. In handshake, it's sending a request to find out if you support fluffy blocks, but current release nodes don't know about that command.

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


rsync copies what's changed:

rsync ~/.bitmonero/lmdb/data.mdb /mnt/wherever/monero-blockchain/data.mdb

This should be done when nothing is writing to the blockchain database file. If you need to copy while it is being written to, use mdb_copy:

mdb_copy ~/.bitmonero/lmdb /mnt/wherever/monero-blockchain/

Note how mdb_copy wants the directory, and not the file.


Ring multisignature transactions can theoretically be implemented for any number of users and required signatures:

  Suppose that a group of n users wants to create a multisignature address requiring t of the group to sign in order to spend any funds received, and in such a way that any observer will be unable to determine for certain whether funds have been sent from this address or not, but in such a way that spending funds twice is impossible

Although I am not aware of plans to facilitate placing specific time requirements for the completion of signatures for Ring multisig transactions, research has focused on some use cases where that feature would have value:

  Another possible use of threshold multisignature is for an organization, such as the board of directors of a company holding company funds, or the developers of an open source software project holding donated funds, to control their funds in such a way that a certain number of members is required to execute any decision regarding the expenditure of those funds.

RingCT will provide multisig Monero transactions with unique anonymity related benefits not available in any other crytocurrency:

  threshold signatures can be used in conjunction with the ring signatures, one-time keys, and ring confidential transactions of Monero to allow for anonymous threshold signature transactions with recipients, senders, and amounts obscured.


Where can I find the AEON pruning branch?

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

Clone from GitHub:

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

Compile:

  make

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

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


Did not receive a transaction after a day from supportXMR

I found the issue and leave the answer here.

As of later March, there was a hard fork on the Monero network and the old databases (on Mac and Linux is found at ~/.bitmonero folder should be removed and refreshed. So all needs to be done is the following:

1- Kill/close the running daemon
2- remove the `~/.bitmonero` folder. Note that it is a hidden folder.
3- Download the latest official Monero binary from [getmonero][1]. As of now it is `v.0.12` and paste it into a new folder.
4- Copy your keys and wallet files from the previous folder.
5- Run the monero daemon (`./monerod --detach`) and wait till it synced with the new fork. (You can use external untrusted nodes instead of running daemon locally, but that always comes with its own risk)
6- After daemon was synced connect the wallet to the daemon and you find the missing transaction.


Block added as alternative on height xxxxx

I will quote a good explanation by bigreddmachine, found here.

  Reorgs happen when there is temporarily a disagreement about what the
  longest chain is. It happens in every Cryptocurrency, and the shorter
  the block time, the more frequent it happens. Basically, picture a guy
  in the Philippines and a guy in Spain each mining what they say is
  block 780000 at almost exactly the same time. Half the network sees
  the one guys block first and accepts it, while rejecting the other
  guys block. The other half the network does the opposite. It's
  actually not that uncommon for this to happen, but usually someone
  mining on one of those two chains finds another block and adds it on,
  and then everyone goes "oh look, that chain is longer" and ditches the
  other one. BUT, sometimes, the near tie in finding blocks can happen
  two or three or four times in a row. Eventually, one side wins out,
  and anyone on the wrong chain has to reorganize. This is why merchants
  are recommended to wait for a few confirmations before fully crediting
  a payment for big ticket items. The more confirmations (or the more
  blocks that get added on top of the one your transaction is in), the
  harder it is to happen on a reorg. The whole problem is caused by a
  slight delay in sending signals to all corners of the earth that a
  miner found a block. The total lag is pretty much ~15 seconds or so.
  The shorter the block time, the larger an effect that lag has. i.e.
  for a 1 minute block, that lag is 1/4th the block time, but for a 2
  minute block, it is 1/8th the block time. In bitcoin's case, it is
  1/40th the block time. The smaller that fraction gets, the less likely
  a reorg is to occur.


Steps to generate a job for miners using a mining pool

Your pool first calls get_block_template and reserving some space by making use of the reserve_size parameter.

You then take the returned blocktemplate_blob, convert the hex data into binary, and modify the data at the offset provided by the returned reserved_offset parameter. This is where you will write your per miner, miner ID for example. So assume you asked for 4 bytes of reserved space, you have 4 bytes you can change at this reserved offset.

Now you have to create a hashing blob for the miner from this data. To do this, you need to make use of two Monero functions: parse_and_validate_block_from_blob and get_block_hashing_blob. The former converts your binary data to a C block structure and the later gets a hashing blob of the block. To use these functions you have to be in a C/C++ environment as they are not exposed via the RPC. Alternatively, you would have to re-implement them in your chosen language.

get_block_hashing_blob is the notable function here and what it does is return the binary data (a blockhashing_blob) of:

The blocks header data
Appended with the blocks merkle tree root hash
Appended with the tx count

Lastly, once you have your binary blockhashing_blob, you convert it to a hex string and send to the miner.


Syncing my full node - only connects to 1 peer

As you have found, you need to run a v0.12 release (currently 0.12.1.0). So download the current release and sync. As @user3603 mentioned in the comment, 0.12.2.0 will be released very soon. You can still use the current release to sync and then update to 0.12.2.0 when that gets released (or just wait for 12.2).


How to restore a wallet on the Monero GUI

You just need to back up your mnemonic seed and you can restore your wallet through the Monero GUI or Monero CLI using any computer anytime.

However, if you are using a 13-word seed from mymonero you can use the following guide to restore it to the GUI since the GUI does not accept a 13 word seed. How do I use my MyMonero wallet via the Monero Core GUI?

Just an additional information: You can use the 25 mnemonic seed as login in mymonero but you have to pay 1XMR to synchronize your past transactions.

Edit:

Monero GUI Beta 2 was just released. So it is easier to restore your wallet using the keys.

Download Monero GUI Beta 2
https://getmonero.org/2017/03/29/monero-gui-beta-2-released.html


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


Can't get AMDGPU-PRO drivers working with R9 290x and xmr-stak

I was struggling too with 290x. Currently I am unable to overclock...but at least I got it up and running.

1) Ubuntu 16.04
2) AMD-APP-SDK-v3.0.130.136-GA-linux64.sh - install it, reboot
3) amdgpu-pro-17.40-483984.tar.xz drivers - install it, reboot
4) /etc/default/grub change GRUB_CMDLINE_LINUX_DEFAULT="amdgpu.vm_fragment_size=9"
5) cp /opt/amdgpu-pro/lib/x86_64-linux-gnu/libOpenCL.so.1 /usr/lib/libOpenCL.so.1
6) Clone sgminer-gm and install all needed deps.
7) Go to sgminer folder

autoreconf -fi
CFLAGS="-Os -Wall -march=native -I/opt/AMDAPPSDK-3.0/include" LDFLAGS="-L/opt/amdgpu-pro/lib/x86_64-linux-gnu" ./configure --disable-git-version
make

I hope this helps. In any case you should see, if it ends with _CPU then something is still wrong.

clinfo | grep Type
  Device Type:                                   CL_DEVICE_TYPE_GPU


What caused the mandatory update for the hardfork in early January 2017?

First, some background. In MRL-0005 - Ring Confidential Transactions there's a section on range proofs, relevant quotes below.

5 Aggregate Schnorr Range Proofs
In [11], the confidential transactions without ring signatures uses a
type of ring signature based on [1] called a Borromean ring signature,
which helps to prove a committed value lies within a certain range. In
this article, I will outline an alternative method, inspired by [7],
which has the same space savings, but perhaps simpler security proofs.

...

For space savings, one can either use a Borromean ring signature (as
in [11]) to combine all of these simple ring signatures, or a type of
aggregate ring signature defined as follows:
5.0.1  Aggregate Schnorr Non-linkable Ring Signature (ASNL) Generation

Now, why do we need these? From the same paper (emphasis mine):

... as -1 is a very large number modulo the curve group order, free
money has been created. It is therefore necessary to prove that the
C_out,i are commitments to values which are positive and lie in a
restricted range [0,2^n] for some n.

These signatures are used to prove that one is not using just anything to hide the amounts, ie to prove what I've highlighted above. It's important because allowing just anything would make it possible to cheat the sum(ins) == sum(outs) part of transaction verification. Thus, it's important that the proof be air-tight.
Now, an issue had been discovered with proof for ASNL signatures used in ringCT. If I understand well, it would open a theoretical possibility of someone forging the range proof somehow. Because of this, it had to be changed from ASNL to Borromean signatures.
If there was no update, everyone running the already deployed code of 0.10.0 would move on and start making rCT-ASNL transactions, but the theoretical problem would still be there and present an unnecessary risk.
Thankfully, at the time of this writing, there's still approx. 27 days until the HF (as reported by monerod).
See also: Failure of an exchange or pool to upgrade to Monero v0.10.1 by January 5th


Why does Monero use keccak over something like sha-256?

While Monero does not use Keccak for its hashing, one advantage of using CryptoNote is to prevent Monero from immediately being able to be mined by ASICs. There is tremendous investment in SHA-256 hashing because of Bitcoin's popularity, so using a less popular / more memory intensive standard allows Monero to be mined by the "common man"- at least until ASICs are developed.


Monero daemon sees deposit but doesnt record it

I was able to solve this with dEBRUYNE's help on reddit here.
Basically the wallet created block was too high and by lowering it I could scan for new transactions in the lower block heights.
I used the command:
monero-wallet-cli --testnet set refresh-from-blockheight <blocknumber>

where blocknumber is lower than current block height (I put 10% lower).
The downside is past transactions I sent are not recorded still, but new ones are. I'm unsure why yet.


there is MiniNero and RingCT-Python as simple implementations of the the math behind Monero

there is also the GUI lightwallet which is implemented in python.


Does a node that is more geographically centered in the Monero network have a higher chance of mining a block?

What matters is where the last block was found, and this is due to latency. So if the last block was found on a pool server in new york, another pool server located in new york will be notified of the new block a lot faster than a pool located in france.

Granted, we're talking on the scale of milliseconds here, but if you do the napkin calculations of a 1 megahash per second pool, a 100 msec delay between a new york server and a server in france means that the new york server can perform 100,000 hashes before the pool in france is even aware of the new block.

Ultimately, these minuscule advantages are for edge cases when a pool gets lucky and finds a new block very quickly. More often than not, multiple seconds have passed before a new block has been discovered and these latencies do not matter, so ultimately it does not matter where a node is geographically.


How does a Monero node know to reject Borromean range proofs

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


What is the maximum value for x in the command "monerod --db-sync-mode fastest:async:[x]"

The maximum value is 2^64-1 (which is, never actually reached in practice).


How to start syncing and check status of Remote Daemon Node using monero-javascript npm package?

You can use setDaemonConnection() to change the wallet's daemon endpoint using monero-javascript.


blockchain.raw download for the testnet?

No.

Spam for stupid length check not wanting short answers.


Block height and notification procedure for v7+ forks

Has the block height for the v7 fork been decided upon yet?

As can be seen from the code here, there's currently no block height set yet for the v7 fork. It'll likely be somewhere in March 2018 though. However, there has also been some talk about pushing it back 1-2 months to accommodate more review for single-output Bulletproofs.

  What procedure will be used to provide notice exchanges, mining pools and merchants about the upcoming fork.

Typically the core-team and the community will try to make exchanges, merchants, services, mining pools, miners, and (economically sensitive) nodes aware of the upcoming hard fork. This is done by spreading awareness of the hard fork on social media, sending out emails, or by other means of contact. In addition, I typically put up a hard fork megathread (example [1], [2]). These threads basically inform users and asks the community to spread awareness of the hard fork.

  Starting with v7 will their be any wallet based notification systems for upcoming forks?

A few weeks before the fork, the daemon will start notifying the user of an upcoming hard fork. In addition, if the user hasn't upgraded after the fork, the daemon will notify the user that there's a new version available.


What is the relevance of the restore height?

The wallet application will scan the blockchain from the height you have given. If there were transaction linked to your address before that height, they will not be included and your balance will probably be incorrect (unless all the previous transactions add up to 0).

So yes, try to use a height that is a little before your first transaction on that address and you will be fine.


What exactly do miners communicate with a pool?

Monero pools all (to my knowledge) use (roughly) the following payloads:

{
    "method": "login",
    "params": {
        "login": "wallet_address",
        "pass": "pool_pass",
        "rigid": "",
        "agent": "user-agent/0.1"
    },
    "id":1
}

{
    "result": {
        "job": {
            "blob": "blob hex",
            "target": "target hex",
            "job_id": "job id"
        },
        "id": "login-id",
        "status": "OK"
    },
    "id":1
}

{
    "method":"submit",
    "params": {
        "id": "login-id",
        "job_id": "job-id",
        "nonce": "deadbeef",
        "result": "hash hex"
    },
    "id":1
}

{
    "result": {
        "status": "OK"
    }
    "id":1
}

{
    "method": "job",
    "params": {
        "blob": "blob hex",
        "target": "target hex",
        "job_id": "job id"
    },
    "id":1
}

The sensible way to get the exact payloads is to run a network capture while mining to a pool.

As for connection to the pool, this is done using a raw TCP socket to the pools address and port. Every payload is a single line of the whole JSON payload string ending with a linefeed character (\n).

Once connected with your socket, you first send the login payload. The pool will respond with the job result payload (or error). Mine the blob and send the pool a submit payload.

The pool at any time may send you method job payload. You should finish mining any existing job and then use that new job.

I have thrown together a fully working example of both a Python pool miner and a solo miner for you here.


Monero old version wallet wipeout my xmr

This is a very old version. Remove the wallet (except the .keys file, which you must keep), get a recent version, run that, and let it rescan the chain.


No. A wallet address, monero payment id, and monero transaction id are not enough to recover your wallet. You will need the mnemonic seed or spend and view keys


Is there any discussion about creating one-time use Monero addresses?

Someone's Monero address can still be linked if one was to use it for a withdrawal from an exchange and then reuse it again.

No. Monero uses stealth addresses for the outputs. Therefore sending from an exchange to your wallet, the exchange knows the address it sent to, but the outputs in that tx are one-time stealth addresses. When you spend those one-time outputs, they are mixed in a ring of decoys for which an observer has no way of knowing which output is then being spent. At no point does your wallet address ever appear on the blockchain.


Can an output be used as a decoy after it has been spent?

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.


What is the meaning of wallet2::transfer_details::m_global_output_index?

In the CryptoNote protocol, outputs are organized into groups according to their amounts, and m_global_output_index represents the index of a given output in its corresponding group. This reduces the size of the ring signature by only storing those indices of outputs in the signature instead of the actual public keys.

Some examples:

https://xmrchain.net/tx/a32927808b02915060008b6806b0ea4458c61d54566f5bc4eb22347c8e674ca4

In this pre-RingCT transaction, the output amount is denominated into 6 different digits, each having its own group of outputs. The meaning of "amount idx 278059 of 308522" on the right hand side is that there exist 308522 outputs of 0.005 XMR in the blockchain, and this newly generated output is the 278059th one in the group.

https://xmrchain.net/tx/0c951a488193c08f3411f0b7f0023a6b72b22e6f2f376f2c720c8d4c31face6e

After the activation of RingCT, the denomination of outputs is no longer necessary, and all the RingCT outputs (whose amounts are hidden) are stored in the same group (associated with the amount of 0 XMR by convention). There are 1491097
RingCT outputs as of now, and this transaction generated the two latest outputs at indices of 1491095 and 1491096.


Sure!
Boot the Raspberry, change admin password (keep this safe!) turn off the wifi and bluetooth.

Turn wifi and bluetooth off:

sudo nano /boot/config.txt
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt

Reboot and NEVER turn on the internet again on this Raspberry.

Note all the software you think you will need (Monero, gpg and maybe KeePassX). Download them on your online mac/pc, checksum all the files and signatures, move to usb stick. Plug into Raspberry and checksum again all the files.
Install what you need, store your password for the Monero Wallet in KeePassX (maybe also use an extra usb-stick as a KeePassX-keyfile).

Some more information on making a cold wallet and a view-only wallet on your online machine to check the balance:

Monero, how to create a view-only wallet and verify cold wallet's balance - Youtube tutorial

Setup view only wallet and check balance - Reddit topic


Do nodes authenticate other nodes for p2p purposes? (re: incoming connections)

While opening ports does put you more at risk than having none open, you are only in danger if an attack can exploit the service that is using that port. An open port is not an all access pass to your PC/network if an attacker happens upon it. They would need to manipulate whatever it is on the other side to gain some type of basic system access.  Then they could maybe gain enough privileges to compromise your system.

It's a bit like leaving your car keys in a restaurant bathroom 100 miles away. While someone could use them to steal your car, they still have a loooong way to find your car and make it happen.

You should also consider doing the following if you run a full node:

Switch to another OS other than Windows.  They are all much less vulnerable to attack, especially Freebsd and Openbsd.
Hard wire everything--your mouse, your keyboard, your connection to the router.  No Wi-fi.
Use a dedicated computer with only the Monero and one web browser program on it.
While on the web, only go to sites you know are clean and only Monero associated ones at that.  Never surf the internet for anything.  Never click on any ads.

Do the above and your odds of getting hacked and your Monero stolen are low, if not zero, IMO.


A 51% attack allows the attacker to effectively censor the blocks of any other mining participants, as even if they do mine blocks, the attacker can outrun the competing chain.


Tools to ease Monero source code pull request

In addition to the comments from user36303 and JollyMort see this answer to my recent question about the difference between ring size and mixin. The distinction is clarified below:

  Ring size = 'mixin' (number of foreign outputs) + 1 (your output)

I agree with the advice above that this task is not urgent and should be left to someone very familiar with the codebase. No find/replace script or other automated tool is appropriate here.


Problem: Daemon failed to start. Timed out, local node is not responding after 120 seconds

Update to the new version 0.17.1.8 and use —enable-dns-blocklist


sc_reduce just takes a 256 bit number and reduces it mod 𝑙 to yield a scalar of the correct curve order. Nothing special. Any number between 0 and 𝑙 is a valid scalar.

For a point (which is what a public key is) however, the bytes need to first decode to a point and this can vary based on what format has been used to store the point. Assuming it's a compressed 32 byte point, this will consist of the y coordinate (a scalar) combined with a 1 bit sign (used during recovery). Thus after taking the binary of the y coordinate, one must recover the x coordinate. This is a little more involved but covered perfectly well in [ref]. Having recovered x one can then check the resulting  x,y point is actually on the curve with a check such as: (-x*x + y*y - 1 - d*x*x*y*y) % q == 0. In practice, you will be using a tried-and-tested library to do any decoding / point operations.


What is the best way of monitoring if monerod is still running on a VPS server?

There are lots of ways this can be achieved. The simplest is to make use of the daemons RPC interface and call a method like get_height or get_info. When you start monerod, I'd recommend starting with the --restricted-rpc flag (to restrict it to view only commands). Then just configure your firewall to allow inbound connections to port 18081 (or a different port if you changed from the default via --rpc-bind-port).

As an alternative to opening up for inbound connections, you could write a cron job   that runs on the same host, which again uses the RPC interface, but emails you if there are issues.


Starting a new pool. questions about payout levels

Not a good idea as answered here

https://www.reddit.com/r/MoneroMining/comments/7lrv3r/starting_a_new_pool_questions_arize/

the Tx fee would eat up 30% of miner profit...


What makes decoding the total sent amount using the viewkey potentially inaccurate?

Because without the private spend key, the outgoing transactions will not be decoded.
It means if you send some monero, you will not see the negative transaction, but only a positive transaction corresponding to the change sent back to your address.
Therefore, the amount will be highly inaccurate.
However, if you only received and never spent any Moneroj, it will be accurate.

Example:
You received 10XMR in one output.
Your balance is 10XMR using the view key or spend key: it's accurate.
Then you send 2XMR.
You send this from the output you own and get 8XMR as change.
Using the spend key you'll see a balance of 8XMR.
Using the view key, you'll see a balance of 18XMR: the 10XMR output + the 8XMR output from change. As you do not see the first output being spend, it's inaccurate.


You'll find an extensive analysis here.

The tl;dr version is that the attacker exploited an obscure edge-case bug to fork the network. The fork was the intention and the net-effect. The devs promptly notified the community and the exchanges and released a fix.


Impact of Range Proof Optimizations on M_O

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

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

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

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

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


How to check balance of monero paper wallet from nodejs?

There are several nodejs packages for working with wallets. They essentially just wrap the JSON-RPC methods on the daemon / wallet RPC interfaces.

You don't actually need a wrapper though as you can just call the JSON-RPC methods directly. For getting the balance, you would call this. The examples use cURL at the command line, but if you know how to make HTTP requests in nodejs, it should be pretty obvious what request payloads to use and the example responses show what JSON data you'll get back.


How to send Monero from a cold (paper) wallet via RPC?

The monero-wallet-rpc requires a wallet file to operate on. Therefore, if you only have the keys, you will first need to restore a wallet file from your keys, which can be done using the monero-wallet-cli:

monero-wallet-cli --generate-from-keys my_wallet

This will prompt you for your address and keys then save the new wallet file as my_wallet.

You can then proceed to opening the wallet file you just created with the RPC:

monero-wallet-rpc --wallet-file my_wallet --rpc-bind-port 18084 ...

At which point you can then call the RPC methods, such as transfer, to transfer funds.

All the RPC commands are just HTTP POST calls, no special libraries are needed.


What does ask-password = 1 (action) mean for the monero cli wallet?

0 means do not ask for things like transfer, etc. The password will still be needed to change settings, since this requires writing the keys file, which is encrypted with the password.
1 means ask for things like transfer. The password is checked, and the command only proceeds if the password is correct.
2 means ask for things like transfer, but the spend key is actually encrypted in RAM, so that it can only be read again with the password. This is basically like 1, except the check is not only a "is the password correct", but "if the password is not correct, I don't even have the spend key". This guards against a memory dump of the process exposing the spend key. Monero takes steps to avoid core files or swapping of sensitive data, but this is just another layer of defense.


Where in the PoW block header is the variant version?

The duplicate is correct. Block header version number changes when there is a fork (network upgrade).

  However reading the block header breakdown here: What is the format of a block in the Monero Blockchain?

If you read on in the answer:

  Note that major version is used for hard-fork upgrade counting, as seen in Monero source code (1, 2). Looks like it's not exactly following the CN specification, where it was supposed to be changed only if the header parsing scheme changes.

A miner could alternatively change algorithm based on the current block height, as the fork version changes at a predetermined block height (i.e. when a fork is scheduled, it is done so in the Monero code against a block height).

Either method works.


running monerod on background thread always stops after some time

This ended up being because I was running monerod on a child process via remote shell in which case one should use screen to keep the process running should there be a disconnection or run on a system owned background process


Transferring monero from Binance to my wallet

Please see this post to resolve your issue.

It's most likely an issue with the GUI and not with your payment


Monero fork: block creation time fluctuation

Yes, it is normal. Block creation is random. Sometimes it'll take more time than your target, and sometimes less.

Think of it as flipping a coin. You can expect tails in... hmm... a bit more than 1.5 tries I think. But if you try it, sometimes you'll get tails in just one try, and sometimes it'll take 20 tries. But the average will converge to about the expected if you try for long enough.

By the way: I see you are forking with the existing Monero chain. If you do not start your own chain, you are a bad person. See How can individuals safeguard themselves and the community against a key reusing fork? for details. I misread the hash rate, this looks like a new chain, all good :)


How many hashes are needed to solve a Monero block of difficulty 1?

One Monero block is (1 << 21) / 16  [Source (Lines 40, 43 and 90): https://github.com/monero-project/monero/blob/master/src/crypto/slow-hash.c#L40 ].

The Monero block reward = (M - A) * 2-20 * 10-12, where A = current circulation. Source: https://monero.stackexchange.com/a/4254/2828 .

With Monero the difficulty is dynamically adjusted so that Blocks are completed in 2 minutes.

"Difficulty is a numerical representation of how long on average it will take to create a valid block that satisfies the Proof-of-Work algorithm being used, it does not represent minutes or time per se. but instead is an integer number that makes the PoW calculation take longer to perform, this is adjusted by the nodes and miners so that on average it ensures the network creates blocks at a generally consistent rate.

This is calculated among all the nodes and miners in accordance with the globally agreed rules in the network, AKA consensus rules.

Miners that do not include this number in their difficulty calculations will not have their block validated and included by the rest of the network." - Source: https://monero.stackexchange.com/a/1494/2828 .

ZCash and Monero use different POW algorithms, comparing blocks solved or chances of success between the two isn't a good means to determine which is more profitable/difficult.

Try https://whattomine.com/ where you can say what equipment you have available and it will estimate your earnings for dozens of Cryptocurrency types simultaneously, including Monero and ZCash.

Example Mining Profitability Calculations:

Source: https://minergate.com/calculator/zcash .

For Ethereum:

Reward = ((hashrate * block_reward) / current_difficulty) * (1 - pool_fee) * 3600

For CryptoNote-based currencies (Bytecoin, Monero, Quazarcoin, DigitalNote, etc.):

Reward = ((hashrate * block_reward) / current_difficulty) * (1 - pool_fee) * 3600

For Bitcoin-like currencies (Bitcoin, Litecoin):

Reward = ((hashrate * block_reward) / (current_difficulty * 2^32)) * (1 - pool_fee) * 3600

Source: https://bitcointalk.org/index.php?topic=1732808.0 .

"<YOUR HASHRATE> / (<YOUR HASHRATE> + <NETWORK HASHRATE>) x <BLOCKS PER 24H> x <BLOCK REWARD>"

Bitcoin : userHash/(difficulty*(2^32))*blockReward*3600*1000000000(hashFactor)

ETH: (userHash/difficulty)*blockReward*3600*hashFactor

Zcash:  userHash/((difficulty)*solsPerDiff)*blockReward*3600*hashFactor (sollsPerDiff = 8192)

Monero: userHash/(difficulty*1e9)*blockReward*3600


Does my mnemonic seed ever need to be updated?

There always exists the risk that the seed words will change. However, because the words correspond to a 256 bit integer which is itself the spend key, I believe as long as you're able to obtain the same version of simplewallet that you used to generate the key, you should be able to restore your wallet.

Additionally, it is possible to restore a wallet without the mnemonic if you have the private spend and view keys. So if you're worried about the mnemonic scheme changing, you should store the private spend and view keys as numbers will never change.


PHP Libraries to assist with Monero integration

Any business wanting to accept Monero could contact the community for assistance, ideally no kind of "permission" is required since anyone can use and trade Monero. The idea there is an official structure to support Monero is misleading but the community shall be forthcoming in helping and supporting merchants to integrate Monero since the project's aim is a secure and easy method of transferring wealth.

There are several PHP libraries available with varied degree of quality:

https://github.com/MalMen/PHP-Monero

https://github.com/TheKoziTwo/xmr-integration

https://github.com/PsychicCat/monero-php

https://github.com/monero-integrations/monerophp


This URL provides two independent means for mapping 12, 18, or 24 BIP 39 seed words used to configure Ledger devices to Monero Electrum seed words (25 seed words) that enable other traditional Monero wallets to gain access to your funds.


How does the Coin Selection work in Monero?

The coin selection in Monero is very simple and naive, so I'm afraid you're not going to find much to take inspiration from.

Currently, the selection is random, with an equiprobable distribution.

There is a patch that will be merged along with RingCT (https://github.com/moneromooo-monero/bitmonero/commit/90fb5e411307a949779c65a1931f3462ee3a564d) which improves this, but only to avoid correlation attacks on the inputs.

As such, there is no attempt made to favor small fees, or transaction size, or number of outputs.

Fees are per kB in Monero, so small fees and transaction size are the same metric (down to quantization at 1 kB). Once Ring CT is merged, each transaction will typically have two outputs, growing the TXO set by the same amount. The vast majority of outputs on the blockchain are not known to be spent/unspent, due to the use of ring signatures (but this does not hold for dust, which is typically consolidated at mixin 0), therefore using up many inputs does not actually decrease the TXO set (and this is why it's a TXO set and not a UTXO set).

Additionally, and I add this since you're using "changed [...] compared to Bitcoin" wording: Monero is not a Bitcoin clone. It is a Bytecoin clone. So the algorithm hasn't really changed, it's just a new one. Not sure if you know this or not, but I thought it worth a mention.