I will first quote the abstract of MRL-0006 draft by kenshi84:

In the CryptoNote protocol, wallet addresses never appear in the blockchain, protecting users' privacy from blockchain analysis. However, wallet addresses are inevitably known to senders and can be kept by them locally, which may become privacy concerns. Consider a typical example: a user buys Monero at an account-less exchange service more than once. If the user reuses the same wallet address, the exchange would know the total amount of Monero transferred to that address, which is generally not desirable for the user. A naive solution to this problem is to create a temporary wallet for each fund receipt, which is not only tedious and error-prone, but also vulnerable to temporal association analysis.
In this research bulletin, we propose a new scheme where a single wallet can generate a one-time address for each fund receipt by making use of the payment ID. Two kinds of such one-time addresses are proposed: one is in the current standard address format with a 256bit payment ID attached separately, which is useful in that the sender's wallet software does not need to be upgraded. The other one uses a new address format where a 64bit payment ID is integrated into the address, which is easy to use but requires upgrading the sender's wallet software. The scheme is already implemented and confirmed to work.

In short, it works like this:

Receiving wallet generates a new set of keys and a payment ID. The newly generated set of keys is deterministic and it's generated from the root keys and the payment ID. The root keys are the keys of your standard Monero address.
A disposable address is derived from those new, disposable keys
The sender pays to the disposable address as normal, but he must attach the payment ID from 1. The integrated format proposed makes this easy.
The receiving wallet sees the payment ID, recreates the matching disposable keys and and checks if any of the outputs in the transaction belongs to it.
If yes, you can spend this output as usual. The wallet can combine it with others from your wallet, as it makes no difference. All outputs are created the same, but here we have a bit different scheme on how to retrieve the private key of an output.

It's important to note that it's sensitive to correct implementation of payment ID. If the sender omits payment ID, the recipient has no way of knowing which disposable key to generate. He could recover the funds by trying with all previously issued payment IDs, but it could take a long time. If the sender would provide a TXID, it would make it easier to recover the funds - in case of some dispute or accident.
Also, a new integrated format is required because the payment ID must remain plain-text, while the existing integrated format uses stealth payment ID which encrypts it so it's not fit for purpose.
Re-use should be discouraged because 2 TX-es sent to the same integrated address could then be linked together with high probability. Although, there's still a slight plausible deniability because anyone could be re-using payment IDs already found on the blockchain, only it's not likely.
Also, for the record, here's the history of this development.

If I use a disposable address will I need back up those keys or will my main wallet be able to recover all my disposable addresses with my original wallet seed?

No. Your main wallet will be able to recover all of them because the information required is actually "saved" in the payment ID of the transaction sent to the disposable address. Only in case of faulty implementation where the sender doesn't specify the PID would you need to recover the funds "manually" and send to yourself so you could access them later.


Which two strings I need to get from tx_json, if I want to determine whether output is mine or not?

The full math you have to do is:

D = P - Hs(8aR || i)G, where i is a varint representing the index of the output. You then check whether D matches your main public spend key or any of your subaddress public spend keys. if it does, the output is destined for you.

The output public key P is in the json as vout.target.key. The transaction public key R is not separately listed, so you'll need to parse the extra field in the json and locate the txpubkey subfield.

The txextra field format is documented here: https://cryptonote.org/cns/cns005.txt

It's the "Tx public key" field mentioned in that document that you are interested in.

Also note that to support transactions with multiple subaddress recipients, there is also a new TX_EXTRA_TAG_ADDITIONAL_PUBKEYS field. If this field is present, then you'll need to check each output against the corresponding additional txpubkey listed in that field.


Can any one please tell me where I can find the latest python implementation of monero RingCT?

I've implemented the Monero transaction code signing for the Trezor in python, the code is here:

https://github.com/ph4r05/monero-agent

And MLSAG in particular: https://github.com/ph4r05/monero-agent/blob/master/monero_glue/xmr/mlsag2.py

The python implementation also contains pure-python Bulletproofs implementation.


Which mining software is most efficient for CPU mining?

I use wolf's XMR miner and am very happy with the results, compiled from source. However, your performance with any miner is going to be dependent upon the OS you are running (I run varying flavors of Debian for reference).

As far as pool preference, they don't care what miner you are running just that you are submitting hashes.


What is the proper way of scanning a bunch of monero private keys to get an updated balance?

Use the monero-wallet-rpc https://getmonero.org/resources/developer-guides/wallet-rpc.html.

You would use the methods open_wallet, refresh and get_balance.


Well, private spend keys are 64 character hex strings, see here:
https://moneroaddress.org

That will give you around 1e77 possible private keys. If n is the number of possible private keys, and you only generated two private spend keys, the odds they would be the same is:
     1 - (n-1)/n
Which Python tells me is 0.0 due to floating point arithmetic.

In order to estimate how many keys you would need to generate to produce a collision you can just take the square root of n, which is about 3e38, which is a lot of keys.

See this page for more info:
https://stackoverflow.com/questions/22029012/probability-of-64bit-hash-code-collisions

Bitcoin uses the same 64 character hex string for private keys, so I think it should be the same.

Disclaimer: I'm no mathologist.


Missing one word from 25 word mnemonic seed

It will not matter if it is 13 or 25 words seed since the script will just need to add another word in the first, last or in between your seed and create the wallet. Your problem is implementing it for the real monero-wallet-cli/monero wallet since it will take longer to scan compared to mymonero. In mymonero a single query would return that the wallet is new or old but in real monero wallet you need to scan the whole blockchain to find if there was a transaction.

This is not impossible to implement but you need to  create a script on top of monero-wallet-cli and be able to automate the creation of wallet using the --restore-deterministic-wallet command or just create a new program based on monero-wallet-cli which automates the wallet creation and scanning of the blockchain.

Lastly, you can't trivially find the transaction hash knowing only the monero address and view key. You have to scan each transaction in the blockchain.

Edit: In the case that you have the view key you don't need to scan the blockchain you just need to compare it with the view key of your new created wallet.

Edit 2: Actually the address is enough and there are three ways you can implement this.

Use the javascript code found in mymonero.com. The same source can be found here and  the specific file
Modify the cli wallet which is in github to just create wallet address base on given seed and looping to all possible combination.
Use your favorite scripting language and automate the monero-wallet-cli --restore-deterministic-wallet. It will return the address.

Edit 3: I implemented it in javascript. The seed is missing the word older in the end. http://jsfiddle.net/gundamlancer/9jvdkrat/1/


I think almost any server would be capable of running a node, and this is useful in the sense of expanding the network. As far as mining, it's only worth it if the server's CPU is equipped with AES, if it is, then it's probably "worth it" to mine if your electricity costs are less than $0.15/kWh or so. Of course it's always useful to mine to help decentralize the network too, but if your mining at a loss you might just be better off buying XMR from an exchange.


If you install Monero GUI over Tails, should you install the blockchain on same drive as Tails

You don't have to. This is up to you. If it's not on the same drive, wherever you do sync the blockchain to will need to be mounted in Tails when you want to use it.

  Can I install the full node (blockchain) on a section of my hardrive on my PC?

Yes.

  Or should I install it on the same USB flash drive as the Tails is stored on?

You state above that your flash drive is only 32 GB. Even with a pruned full node, you will struggle to fit both OS and full node on the same drive.

  Where would be a good place to store the GUI? Or doesn't it matter?

Wherever you like. It's your computer.

  If it is OK I can store the full node and GUI on the Hard Drive.

If you have space for them both, that's fine.


Going through customs in a foreign country. I want to delete my monerujo app. Can I re-download with everything intact?

If you are removing Manerujo from your phone, first view and write down the mnemonic seed. When you reinstall the app, recover wallet from the seed.

https://github.com/m2049r/xmrwallet/blob/master/doc/FAQ.md

You should be backing up your password and seed or keys anyway. Then just try with a test wallet to verify before using with your real wallet.


The binary files are the .exe files, and I guess the .dll files too. The ones from 0.11.1.0 are wholly obsoleted by the ones in 0.12.0.0, and you should use only the ones from 0.12.0.0.

The wallet files are FOO and FOO.keys, with FOO being whatever you named your wallet. You don't necessarily have to copy them, if you give the path to them when loading monero-wallet-cli, ie:

./monero-wallet-cli --wallet-file /home/yourlogin/monero/walletname

Replace yourlogin and walletname with the right names. And set the path to wherever the wallet files are.

I think the instructions tell you to copy because they assume you put your wallet in the same directory as the binaries, which you might or might not have done.

In any case, if you delete any directory, make sure you didn't put your wallet files in there first.


Was the reasoning behind the large tx extra in minergate's transactions ever revealed?

The extra payload appears to be for merged mining, as per the definitions in src/cryptonote_basic/tx_extra.h:

field 0: extra pub key: <c4230d59c83b3042fd82999cfda5be6b77c1673d9442d1f21c7ab9215bdc6c18>
field 1: extra nonce: 9841490000000000000000000000000000
field 2: extra merge mining tag: depth 0, merkle root <4bff195014248ae22838853bcf293b8945f9baaac693c2d05bafe2f0f3e6c69e>

I believe XDN was switching to merge mining with Monero, so it could be this. XDN was abandoned a year ago though. Fantomcoin was also merged mined, but has been dead even longer.


Is there a secure way to boostrap a node?

You are probably looking for bootstrap node

monerod --help

  --bootstrap-daemon-address arg        URL of a 'bootstrap' remote daemon that
                                        the connected wallets can use while
                                        this daemon is still not fully synced.
                                        Use 'auto' to enable automatic public
                                        nodes discovering and bootstrap daemon
                                        switching


Error on initial monero daemon start with *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL

That's not an error. Looks normal to me :)
The first line is starting with INFO, and it's just telling you which kind of events will get logged.

Also, I suggest creating a shortcut to monerod.exe, and adding --block-sync-size 10 to it, as below. Seems to be a cure-all for slow sync.


How to convert Bitcoin mnemonic to Monero mnemonic?

Assuming your wordlists match, the 13th word is just a checksum word. You concatenate the prefixes of the main 12 words, run a checksum over it, mod that with the word count and, hey presto, you have the index of the word to use as your 13th word.

Example from luigi1111 here which shows creating the checksum

Note that the official Monero wallets makes use of 25 word versions nowadays as these offer much higher entropy.


What are the risks of using a remote node through the Tor and a node hidden service?

Similar question and answer.
Using Tor only lessens the risks associated with using a 3rd party remote node. If the node is not yours, you are trusting the data it gives you.


Overclocking In Linux With Wolf or Silentarmy

I tried on Lubuntu 16.04 with sgminer-gm, and the settings didn't seem to change anything as well. It is as if the card is just ignoring the OC settings.

It seems that for Linux, it's not so straight-forward to OC. I remember reading somewhere that you can do it by changing the GPU BIOS. Haven't done it myself yet so can't really give guidelines.

Here I found mention use of some aticonfig script to OC. Maybe it's worth investigating further. Some more info here.


According to these benchmarks, K620 is supose to get around 120 H/s

http://monerobenchmarks.info/ (threads 32, block 6s)

Also XEON E3-1271 gets 338 H/s

So yes, its probably correct. But you can always tweak it a little bit.


How synchronization with a remote node works?

In addition to the comments above:

When using a remote node, you are using it's daemon and downloaded blockchain. If you cannot connect to a remote node, you can run the local daemon. This then needs to download the blockchain to your local machine. Depending on how fast your connection is and whether your disk is a spinning HD or SSD, this can take from hours to a week.

It's also worth noting that when using a remote node that is not your own remote node, you are trusting the remote node operator and thus can lose some security and privacy.

A common and very useful reason to run your own remote node is when you have multiple devices that you wish to use Monero with and don't want to trust someone elses remote node. For example, run a simple cloud server as your own full remote node, secure access to the daemon using something like stunnel, SSH tunnel or proxied Apache/Nginx using SSL. Then you can use your own remote node from other devices like your phone / laptop etc without having the overhead of the ~70GB blockchain on each device.


How many blocks must miners wait before spending the block subsidy?

The Coinbase can be spent after 60 blocks.

See
CRYPTONOTE_MINED_MONEY_UNLOCK_WINDOW


What does the "hashes" field mean in an authentication message received from a pool?

It's the number of valid shares that the miner has sent to the pool.

Relevant excerpt from the CryptoNoter source:

// (whenever the upstream pool accepts a share)

// increment the number of accepted shares
conn.accepted++;

// notify the miner via websockets
buf = {
    "type": "hash_accepted",
    "params": {
        "hashes": conn.accepted
    }
}
buf = JSON.stringify(buf);
conn.ws.send(buf);


Is it possible to embed message for recipient in transaction?

Yes you can do it, but.

There are 2 options which you can use at the moment: plain-text 256-bit PID and encrypted 64-bit PID as part of the integrated address scheme. In principle, you could put anything in the tx-extra field but you'd need to customize the wallet software to do this.

Plain-text 256-bit PID - You could encode a string of 32 ASCII characters into this one. However, the receiving wallet would still display it in "hex", so your recipient would need to c&p the "hex" string into some converter to see the human-readable message. This is not private, because anyone could read the message attached to the TX.
Encrypted (stealth) 64-bit PID - You could encode a string of 8 ASCII characters into this one. Again, the receiving wallet would still display it in "hex". This is the more private version, because only the intended recipient would see the actual message. In this scheme the message is encrypted with the shared secret. This means that each TX has a different encryption key so it looks like the PID is randomized every time, while the recipient would see the same message.

Of course, some arbitrary length "note" functionality could be implemented into the wallet, using the TX-extra field. It would be better to encrypt it with shared secret, as it's done for stealth PIDs already.


C++ program to generate mnemonic seed, view/spend keys and wallet address?

XMR is a bit clunky, but should get you rolling. Also look at http://moneroexamples.github.io/spendkey/.


List of things that were proposed and rejected for bitcoin but implemented in Monero

I don't have an exhaustive list to hand for you, but a few things that spring to mind: "one-CPU-one-vote" (Satoshi), Confidential Transactions (Maxwell), privacy (many aspects proposed by many people), Schnorr signatures (although it's looking like this will get implemented at some point) and of course Dandelion.


How do I merge wallet data from multiple wallets that control the same address?

There is no tooling to do this at this time.


How to manually add public nodes to your node?

... --add-peer  node.supportxmr.com:18081

--add-peer arg is the correct parameter, however, by the peers you are trying to add it's clear you are using the other peers RPC interface, not their p2p interface. The p2p port is 18080.

--add-peer arg is for adding p2p peers.

Also,

  But after requesting get_connections to rpc node ...

You can check which peers your node is currently connected to with the monerod command print_cn, which will show all the inbound and outbound connected peers.

  And another question, will the list of nodes to which my node has an incoming or outgoing connection will be saved and used when rebooting the daemon?

Yes.


MyMonero is down again, how do I get my money out?

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

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

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

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


Is there a tool for making secure cold wallets?

Funny you should ask, Taushet, because indeed there is!

The Taushet USB Monero Cold Wallet Generator is a pre-packaged, pre-hashed and pre-zipped collection of the tools required to make a secure wallet that only requires a single checking/security hash. It takes around 10 minutes to make a secure cold wallet. The tool has been hashed and verified by many community members (see here).

The full instructions can be found on the reddit post, but here is the meat of it:

What you need:

1 x taushet-USB-wallet-gen.zip
3 x USB thumbdrives
1 x paper
1 x pen
1 x Hash utility ()

How to use:

Download the zip from the link on the reddit post (pgp signed)
Physically disconnect from the internet.
Check that the hash of the file matches those on the reddit post.
Extract the zip file, which contains: slacko64-6.3.0.iso, Rufus-2.11.exe, monero-wallet-generator-master (dir), and this ReadMe.txt.
Make a bootable USB of the ISO using Rufus 2.11. Agree to all the default settings in the dialog boxes.
Drag the monero-wallet-generator-master directory to the USB drive.
Reboot using the USB into PuppyLinux (hold down F12 during boot to select boot drive)
Open the monero-wallet-generator.html file in the directory, generate the wallet seed and keys
Save the seed, address and keys to the second USB drive. Copy/paste, don't type. This is you digital vault, not to be used until fund extraction.
Write down the seed three times on a single sheet of paper. This is your physical vault.
Save the address (and maybe viewkey) to the third USB drive. This is your address usb, which can be used with relative abandon.
Remove second and third USB drives.
Wipe the first USB drive (containing the wallet generator and linux), or destroy it.
Remove all USB drives.
Reboot, reconnect internet.

You now have a cold wallet!


When sending monero with a payment id, is the transaction still 100% anounymous?

Yes. Using a payment Id still maintains Monero’s privacy features

A payment Id allows the receiver to keep track of incoming payments from specific sources.

The best way to use a payment is to integrate it directly into a wallet address by creating an integrated address. This will generate a unique address with an integrated payment Id that the receiver can give to a specific source so the receiver can keep track of a payment from that source.

See here and here for more details

Note: when transferring monero to your wallet from some exchanges, they will ask you for a payment id in a separate field to the address, in this case you should use your original address (not the integrated address) and the payment id separately


Where to find a computation example of the monero traceable ring signature mechanism in a small finite field?

Have you tried https://lab.getmonero.org/ and the cryptonote whitepaper(s) here? https://getmonero.org/research-lab/ They have some very thorough documents on the technology at a more academic level.


Where can I find charts of Monero's price to dollar?

Try Poloniex website here, which gives usd/xmr chart:

https://poloniex.com/exchange#usdt_xmr


Has bandwidth usage or data transferred when mining or hosting a full node increased since the introduction of RingCT?

Yes, RingCT transactions are much bigger than non-RingCT transactions. The monthly blockchain growth has already more than doubled in comparison to December 2016, when RingCT hasn't been enabled yet.

Why are you hosting more than one full node at home? You just need one full node and all your local machines can connect to it via local network.


Is having P2Pool 'baked' into the Monero network possible?

The one problem with a p2pool baked into the core code is that the payouts would have to be distributed to everyone participating in the p2pool (which would presumably be everyone), and each of these payments would be infinitesimally small. Or, you would have to have a payment threshold to reduce the amount of crazy small outputs from being created, and this threshold would be so much that a participant wouldn't get paid for a long time - probably the same amount of time that natural mining variance would permit the user to find a block.

Ultimately, satoshi was a smart guy and the block reward distribution via random lottery works within the confines of a tokenized ledger consensus currency network.

But thats not to say that it could be built. It just has a lot of interesting dynamics to be worked out.


That command is not correct.

You are connecting a cpuminer, which talks pool language by default, to a daemon's P2P port, which speaks monero P2P.

You need to change two things:

connect to the RPC port (18081 by default)
tell the cpuminer to not talk pool language but dameon RPC language using daemon+tcp instead of stratum+tcp

Not all miners know how to talk to the daemon instead of to a pool, so yours may not be able to. If not, use another miner (or use a more recent version).

For more information, see Solo GPU mining (partly applies to solo CPU mining).


What is the logic behind multiexp method in bulletproof Monero implementation

The function is performing Multi-Exponentiation and is just a stub for using the most efficient algorithm (Straus or Pippenger, cached or uncached), based on the input data.
Some timings in this commit, which have informed selection criteria.


Both the RPC wallet and daemon support SSL.
$ monero-wallet-rpc --help | grep ssl -A 3
  --daemon-ssl arg (=autodetect)        Enable SSL on daemon RPC connections:
                                        enabled|disabled|autodetect
  --daemon-ssl-private-key arg          Path to a PEM format private key
  --daemon-ssl-certificate arg          Path to a PEM format certificate
  --daemon-ssl-ca-certificates arg      Path to file containing concatenated
                                        PEM format certificate(s) to replace
                                        system CA(s).
  --daemon-ssl-allowed-fingerprints arg List of valid fingerprints of allowed
                                        RPC servers
  --daemon-ssl-allow-any-cert           Allow any SSL certificate from the
                                        daemon
  --daemon-ssl-allow-chained            Allow user (via --daemon-ssl-ca-certifi
                                        cates) chain certificates
  --rpc-ssl arg (=autodetect)           Enable SSL on RPC connections:
                                        enabled|disabled|autodetect
  --rpc-ssl-private-key arg             Path to a PEM format private key
  --rpc-ssl-certificate arg             Path to a PEM format certificate
  --rpc-ssl-ca-certificates arg         Path to file containing concatenated
                                        PEM format certificate(s) to replace
                                        system CA(s).
  --rpc-ssl-allowed-fingerprints arg    List of certificate fingerprints to
                                        allow
  --rpc-ssl-allow-chained               Allow user (via --rpc-ssl-certificates)
                                        chain certificates

$ monerod --help | grep ssl -A 3
  --rpc-ssl arg (=autodetect)           Enable SSL on RPC connections:
                                        enabled|disabled|autodetect
  --rpc-ssl-private-key arg             Path to a PEM format private key
  --rpc-ssl-certificate arg             Path to a PEM format certificate
  --rpc-ssl-ca-certificates arg         Path to file containing concatenated
                                        PEM format certificate(s) to replace
                                        system CA(s).
  --rpc-ssl-allowed-fingerprints arg    List of certificate fingerprints to
                                        allow
  --rpc-ssl-allow-chained               Allow user (via --rpc-ssl-certificates)
                                        chain certificates
  --rpc-ssl-allow-any-cert              Allow any peer certificate

If none of the options are specified, the default (--rpc-ssl arg (=autodetect)) applies, which causes the wallet/daemon to present a self-signed certificate to any client that attempts an SSL connection - it's then up to your client to either allow or reject this self-signed certificate. If you already have a CA signed cert, or any other you'd like to use, then start your wallet/daemon with the relevant options.


If you are sending Monero to yourself from an exchange a payment ID or integrated address is generally unnecessary because you know when and where the Monero came from and in what amount.

Based on "paid" in your screenshot it appears as if the transaction was sent. With the transaction ID / hash provided by the exchange you will be able to follow these steps to verify you received the Monero.

If the Monero was sent, you will be able to see your Monero in your wallet after your GUI has synced or connecting to a remote node.


The process to compute the mining blob can be described by the following pseudo-code:

miner_transaction = build_miner_transaction(...)
miner_transaction_id = compute_transaction_id(miner_transaction)
header = serialize(build_block_header(...))

transaction_ids = append(miner_transaction_id, other_transaction_ids...)
count = serialize_varint(number_of_transactions)  // miner transaction included
tree_root_hash = compute_merkle_tree_root_hash(transaction_ids)

blob = append(header, tree_root_hash, count)

Then the blob is hashed using the Cryptonight function.

Some details about the formats of block headers and miner transactions can be found in What is the format of a block in the Monero Blockchain.


Is Monero the first cryptocurrency to use Confidential Transactions (RingCT), 0MQ, and LMDB?

RingCT

RingCT was developed by Monero Research Labs specifically for coins with ring signatures (and even more specifically Monero). Monero is by far the most common of these, and Monero is the first to include this in their code. Keep in mind that RingCT was based on Confidential Transactions for Bitcoin, so a coin like Bitcoin would implement CT instead.

  0MQ

I do not know, mostly because I do not know much about 0MQ. Read more about Monero's project to add 0MQ here and what (may) be a similar project for Bitcoin here. Keep in mind that I may be very wrong here.

  LMDB

There appear to be some Bitcoin projects built on LMDB. From my research, though, Monero appears to be the only blockchain that uses LMDB in its core functions.


Can the Monero block chain be pruned to increase scalability?

Theoretically, there is nothing preventing this. Practically, there is no code to do this yet, however.

There are a few things that can be pruned. Ring signatures, for instance. Once RingCT is in, range signatures can also be pruned. These take a large portion of the transaction data. Note that Aeon, a fork of Monero, does implement some kind of pruning already.

It is important to remember that pruning data makes a node unable to supply the pruned data to other syncing nodes. That data is necessary to fully validate the blockchain in a trustless manner, so while a client may decide to trust a pruned node, there should be at least a few "full data" nodes on the network, keeping the entirety of the blockchain, in order to keep the ability to re-verify the whole thing from scratch.

It is also relevant to note that the current on disk blockchain database is several times larger than the full blockchain data (very very roughly, the disk database is 6 to 8 GB, while the full blockchain data is maybe 3 GB). This is done to speed up subsequent reads from the database.


Yes, written instructions for installing Monero on your system can be found here with a video tutorial including GUI setup and testing here

Dependencies:

# update Ubuntu's repository
sudo apt update

#install git to download latest Monero source code from github
sudo apt install git

# install dependencies to be able to compile Monero
sudo apt install build-essential cmake libboost-all-dev miniupnpc libunbound-dev graphviz doxygen libunwind8-dev

# or git and all dependencies in one command
# sudo apt install git build-essential cmake libboost-all-dev miniupnpc libunbound-dev graphviz doxygen libunwind8-dev

Compilation:

# download the latest bitmonero source code from github
git clone https://github.com/monero-project/bitmonero.git

# go into bitmonero folder
cd bitmonero/

# apply patch for using Onion Blockchain Explorer (optional)
# https://github.com/moneroexamples/onion-monero-blockchain-explorer
# curl https://raw.githubusercontent.com/moneroexamples/compile-monero-09-on-ubuntu-16-04/master/res/tx_blob_to_tx_info.patch | git apply -v -
#

# compile the release version.
make # or make -j number_of_threads, e.g., make -j 2

# alternatively `make release` can be used instead of `make`. This compiles
# the source code without compiling unique tests which is faster, and can
# avid problems if there are compilation errors with compiling the tests

Installation:

The Monero binaries should now be located in ./build/release/bin

# launch the Monero daemon and let it synchronize with the Monero network
/opt/bitmonero/bitmonerod

# launch the Monero wallet
/opt/bitmonero/simplewallet

Once the above is complete, prepare the source code:

git clone https://github.com/mbg033/monero-core.git
cd monero-core
./get_libwallet_api.sh

Compile QT:

sudo apt-get install qtbase5-dev qt5-default qtdeclarative5-dev qml-module-qtquick-controls qml-module-qtquick-xmllistmodel
qmake
make

Launch:

 release/monero-core


Monero wallet says sent 25 XMR, other wallet says 0 received!

My guess would be due to the recent hard fork and verification times being slowed down. I'm running a full  node and things look weird at the moment. The data is on the blockchain and should eventually sync. It doens't look like the Ledger bug is affecting you.

https://www.reddit.com/r/ledgerwallet/comments/aywyj2/is_monero_safe_to_use_again/


How do I start using Monero with the command line tools?

When you’re on Linux or macOS, I usually put the Monero software in the /opt directory. That’s where “optional” software typically goes outside of the OS packaging system. I also try to plan ahead and keep multiple versions.

E.g. on macOS, for the Wolfram Warptangent release, I created a subdirectory like this:

$ cd /opt
$ sudo mkdir monero.mac.x64.v0-10-0-0
$ cd monero.mac.x64.v0-10-0-0
$ sudo tar -jxvf /Users/Nicolas/Downloads/monero.mac.x64.v0-10-0-0.tar.bz2
x ./monero-blockchain-export
x ./monero-blockchain-import
x ./monero-wallet-cli
x ./monerod

Then I make a symbolic link to the “current” release:

$ cd ..
$ sudo ln -s monero.mac.x64.v0-10-0-0 monero
$ ls -lrd monero*
drwxr-xr-x  10 root  wheel  340 Aug 31 22:21 monero.mac.x64.v0-9-4-0
drwxr-xr-x   6 root  wheel  204 Nov  6 13:02 monero.mac.x64.v0-10-0-0
lrwxr-xr-x   1 root  wheel   24 Nov  6 13:03 monero -> monero.mac.x64.v0-10-0-0

As you can see, I did the same for the 0.9.4 release. It allows to easily switch to an older release (by removing the monero symbolic link, and recreating it to another target directory), in case you need to test something with an older wallet.

At the user level, from my home directory, I just added the following to my .profile file:

# Monero
PATH="${PATH}:/opt/monero"

Then, from a new terminal (or after re-login), you can just call the binaries without ./ in front of it.

$ which monero-wallet-cli
/opt/monero/monero-wallet-cli
$ monero-wallet-cli --help
…


New Wolfram Warptangent 10.1 cold wallet transaction signing mechanism

It introduced most of the commands mentioned in this guide:

import & export outputs
import & export key images
offline transaction generation
pushing transactions generated offline to the network

Some bugs were observed during testing, which were fixed prior to the point release. Also, I'm not sure it was even possible to perform cold spending prior to this release (maybe via RPC, but definetely not with commands available in the old release)


What stops the miner or the pool owner from cheating?

Here is the answer when it comes to Bitcoin mining pools.
https://bitcoin.stackexchange.com/a/10693

TL;DR: The miner will find a valid hash based on the merkle root provided initially by the pool. Once a solution is found, the miner will submit it to the owner. The owner would not be able to change the transactions (to divert the BTC to their own address) without making the solution invalid due to a different merkle root.

Presumably the same would apply to Monero, although I haven't been able to find much documentation on the structure of Monero blocks and their mining.


Are there any technical reasons why Monero Classic could not exist?

No reason. Some did just that (probably not intentionally, though). You're free to mine on that chain, I think it's still there. You could make an exchange and sell those monero if you wished (assuming you find buyers).

The reason ETC kept going strong is that the ETH fork chose to reach back and blacklist some transactions or outputs (I don't know the details), rather than fix or improve something.


Does the Monero default client deduct the fee from the sent amount?

When you transfer monero, you also pay the miner fee. This fee is also taken from your inputs, so if you transfer an amount A, then you end up with this:

N inputs, totalling X, such that X >= A + F
I outputs, totalling X-F
One of these I outputs is A
Change is X-F-A

So you spend A+F.

It would be confusing if you sent some amount, but the recipient would receive some slightly smaller amount.

Note that this is how the monero-wallet-cli and monero-wallet-gui wallets behave, so another wallet may well decide to it otherwise.

There is an exception to this rule: the sweep command family. sweep_all tries to send all your balance, but since you wouldn't have anything left for the fee, it sends all your balance minus the fee.


Monero wallets with native xmr.to integration

There are currently no wallets with native XMR.to integration. This is, however, planned for the official GUI at some point in the future.

EDIT 12/25/2017: Monerujo, a third-party Android wallet, currently has native XMR.to integration1

Sources:

https://www.reddit.com/r/Monero/comments/7lv9d8/update_monerujo_satoshis_dream_beta_now_with_btc/


How can I verify the SHA256 hash of 0.10.3 “Wolfram Warptangent” on FreeBSD?

The process for Linux and FreeBSD is similar to that for macOS, described here: How can I verify the SHA256 hash of 0.10.3 “Wolfram Warptangent” on macOS?

For FreeBSD, use the command sha256sum <filename> in the terminal and compare the output to the checksums on the Monero webpage.


Connect to remote node using moner-wallet-cli with --daemon-address with a password?

A login (username + password), if set on the daemon (via the monerod --rpc-login flag), has to be passed via the --daemon-login flag upon launching monero-wallet-cli. That is, monero-wallet-cli --help states:

--daemon-login arg          Specify username[:password] for daemon                                       RPC client

Thus, in your example, the login would be passed as follows:

./monero-wallet-cli --daemon-address <domain-or-ip-of-remote-node>:<port-of-remote-node> --daemon-login <username>:<password>


1. What is the hash function Hp?

The Hp is the hash-to-point function. Result of that would be some random point on the Ed25519 curve. In the CN whitepaper it's defined as:

  H_p: a deterministic hash function E(F_q) -> E(F_q)

If I understand well, it takes any point on the curve, and yields a random point on the same curve. The implementation is in the hash_to_ec function. It's not entirely clear to me, but I've written what I could understand as an answer to this question.

Anyways, the definition is clear: a function to take a point and return a random point, so implementation is expected do the same. Anything multiplied with the basepoint will yield a point, and we must multiply it by 8 to get a point on the primary group. There's some info about that here.

2. How can we know that Hp(P) is a point on the Ed25519 curve? Or is it not?

It is, and that's not the only requirement - it must also be a point on the primary sub-group of the base-point G. You can check by multiplying with l. If you get the identity element, it's in the G sub-group.

3. Is the value I published with the transaction?

Yes, the value of I is published with each transaction. You can look up any TX on a block explorer and see that.

4. How can an external person verify that the key image has been produced by the owner of one of the transactions, without revealing the identity but at the same time providing double spending resistance (even when the signer chooses two different rings)?

I was asking myself the same thing. Looking at the CN whitepaper again, we see that the ring signature is composed of the public keys + the key image.

Similarly, the signature checking alghoritm involves key image as part of it.

If the signature is ok, the verifier checks whether it had already been used, effectively preventing double-spends.

Finally, there are some general notes about the whole mechanism.

And that answers the question - the coefficients (r_i, c_i) are used by the signer to prove that he knows such x that at least one H_p(P_i) = I * x^-1, effectively proving that it's one from the ring.

Some more info can be found here in the comments.


What is the best way to help the Monero network?

There are many ways to help the Monero both directly and indirectly.

Run a full node to directly support the network
Donate to the Monero Forum Funding System
Join a Monero workgroup for mining, support, or any others
Participate in many of the Monero forums, such as here on the Stackexchange, on Reddit, Quora, etc
Learn as much about Monero as you can so you can help others
Join a local cryptocurrency/Monero meetup or start your own
Contribute to the Monero Ecosystem project
Run as a solo miner or join a small pool to help decententralization aspects

You could additionally set up a mining rig, to both equalize on profits and make your hashpower of larger significance.


Previous balance showing after upgrade and resync

This problem was caused by me not understanding how the GUI update process works. I didn't realise I had both the old and new versions on my system, and was inadvertently opening the old version. My balance is now accessible as expected.


How do miners attempt to avoid duplicating nonces of other miners? Do they try?

There's no need to worry about duplicating nonces between miners/pools because they construct the block header, which contains the merkle root of all txs in the block, one of which is the coinbase tx that will payout to the miner/pool. So, the block header is different for every miner, so no need to worry about duplicating nonces.

As knaccc points out in the comment below, pools will also assign each miner a so called "extra nonce" to prevent miners at the same pool from duplicating work.


Is Monero the only CryptoNote based coin with a public testnet?

I am not aware of any other Monero forks besides the two that you mentioned.

There are other CryptoNote currencies but I am not aware of any that have a public testnet. The level of community and developer interest in most other CryptoNote projects is minuscule compared to Monero. Most CryptoNote coins were originally forked from Bytecoin with development severely lagging behind Monero. It would surprise me if any of them had a public testnet with much use.


After not running monerod for a couple of weeks, it throws me errors and closes before I can read them. What is my strategy here?

An issue of deamon not starting after a while has been already made. Maybe this is same what you are experiencing:

https://github.com/monero-project/monero/issues/1598


Can I verify that a "forgotten" subaddress belongs to my wallet?

When restoring a wallet from seed phrase, you do not lose your subaddresses. This is because subaddresses are deterministically derived from you wallet keys. Therefore there is never a scenario whereby you would need to restore subaddresses "by other means" or " add them back to my wallet". By restoring a wallet, you have all the subaddresses too.

Getting technical, it is also possible to verify if you own a given subaddress. To do this you would need to create all the subaddresses that cover the range of possible indexes of the subaddress you wanted to check for a match. E.g. if you knew your wallet only had 2 accounts and up to 100 subaddresses, you would create the first 100 subaddresses for account 0 and account 1, then one of those will match the address you are checking.


Instead of trying to figure out how a pool operates by analyzing network traffic, you'd be better off studying the source code of working pools such as:

node-monero-pool
Monero Stratum
Miningcore


Are mnemonic seeds possible in right-to-left languages?

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


Looks like its a WIP (Work in Progress), we can read some info here. I wouldn't rush anything related to the difficulty algorithm or other essential aspects.


You should not consider the pool hash rate in your profits calculation.
Pool hash rate influence the variance in block finding frequency but not your profit. A lower pool find less blocks but you get a bigger reward of each.

For your calculation take the ((your hashrate) / (the network hashrate)) * (720 blocks per day) * (block reward) = XMR/day


How can I verify the SHA256 hash of 0.10.3 “Wolfram Warptangent” on Windows?

Windows also has a built-in command-line tool to check hashes.

First, using Windows Explorer, navigate to the folder to which you downloaded monero-win-x64-v0.10.3.0.zip.

Then, shift + right-click somewhere on the background (don't select any files) and select Open command window here.

You'll be presented with the console which will start in the same working folder so it'll make the following steps easier.

Then, command:

certutil -hashfile monero-win-x64-v0.10.3.0.zip SHA256

You'll see an output like:

SHA256 hash of file monero-win-x64-v0.10.3.0.zip:
37 a5 7d 1b e8 1b 61 19 ac 06 d3 f6 37 b4 c5 6f c6 25 f3 e7 90 f3 49 1c 1b dc a4 d6 29 02 bf 13
CertUtil: -hashfile command completed successfully.

which you can compare against the one published on getmonero.org


Can't create transaction: internal error: Failed to get height

This was resolved by selecting a different remote node.


Though I increase number of cpu, hash rate does not increase

Whilst your CPU may have the ability to run 8 threads, it may not have enough cache for mining with 8 threads. With Monero, you need 2MB CPU cache per thread. So for 8 threads you'd need a CPU cache of 16MB available.

If you run more threads than you have cache for, it will slow down the hashing.


Safety is a scale relative to your requirements. If the remote node is not your own remote node, you are trusting that remote node to a) not censor you by not relaying transactions or send you blocks from the main chain and b) not to log your IP address.

Therefore it's always preferable to use your own node (local or remote). If you're happy with the risks above, it safe to use public remote nodes.


Restored monerujo wallet key file and password is not working. What could it be?

For whatever reason the wallet cache file was corrupt on my monerujo app. A monero wallet consist of 2 files:

wallet file (wallet_file)
wallet key file (wallet_file.keys)

However, when using the wallet files from monerujo on desktop or cli, it sets the password to something else vs what you use in the mobile app. This is called CrazyPass, which is a long 20-30 character alphanumeric password that looks something like this (spaces included):
XX55 ARPT R3QH Z97K XXXX WTCK LSPK YYA2A FBC2 Y4DD XXXX XXXX GYS3
When opening a corrupt cache wallet file on the desktop, it will throw an error. The only solution here is to delete the wallet_file, but not the keys file. It will regenerate when you open the wallet_file again using your keys file.


I created and executed a transaction to shape shift on the incorrect block chain, can any one help me?

All you need to do is start from scratch. Install the latest wallet, restore your wallet from your seed, and your funds will still be there. You spent the coins on the wrong blockchain, but on the new (correct) blockchain your funds have not been spent. This is confirmed by observing that the txid does not exist when searched for on xmrchain.net

If you don't want to start from scratch, you can instead upgrade your wallet by following instructions here: I forgot to upgrade (from CLI or GUI v0.11 to CLI or GUI v0.12) and, as a result, accidentally synced to the wrong (alternative) chain


1st (1 Monero) + 3rd (100 Monero) = 4th_Mine (90 Monero) + range proof balancing (11 Monero)
2nd (1 Monero) + 3rd (100 Monero) = 5th_Mine (90 Monero) + range proof balancing (11 Monero)

Let's call these TX1 and TX2 and lay them out a little more accurately.
The outputs either being spent or created are denoted by oN. Each real spend output appears in its own ring of decoy outputs, dN. For each created output there is a range proof bN.
TX1:
  Input rings:
    [o1, dN, dN, dN]
    [o3, dN, dN, dN]

  Key images:
    k1, k3

  Created outputs:
    o4, o5

  Range proofs:
    b4, b5

TX2:
  Input rings:
    [o2, dN, dN, dN]
    [o3, dN, dN, dN]

  Key images:
    k2, k3

  Created outputs:
    o6, o7

  Range proofs:
    b6, b7

In these two cases, I spent two outputs that originally had 1 Monero each but supposedly succeeded in creating a total output of 180 Monero.

But no. Only one of the above transactions will work, the other will be rejected.

What can prevent me from creating [these] two separate transactions...

The key image k3. As soon as a transaction is seen using kN, no subsequent transaction will be accepted trying to use the same key image. This is our double-spend protection.

The logic of range proofs supposes that the amount of input Monero equals to the amount of output Monero.

Not quite. The purpose of the range proofs are to ensure the outputs are within a non-negative range (e.g. [0, ..., 264-1]), they have nothing to do with double-spending. They aid in the balancing, only so far as to ensure none of the values used are negative, which could introduce a hidden inflation.


How to connect to a remote node from NodeJS?

I've found a solution, using monero-rpc-client library. When I use node.moneroworld.com:18089 as host, the code doesn't work. When ip is used instead everything is OK. The ip is taken from here.

const rpcClientClass = require('monero-rpc-client')
const nodeAddress = 'http://62.210.124.152:18089'
const rpcClient = new rpcClientClass(nodeAddress)
rpcClient.getBlockCount()
  .then(result => {
    console.log(result)
  })
  .catch(error => {
    console.log(error)
  })

Here's the result:

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "count": 1492683,
    "status": "OK"
  }
}


Getting "Unauthorized Access" with RPC (using Python Requests)

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

So your request should be something like:

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

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

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


Will I need to update wallet and miner after the next upcoming (March 2019) fork?

Yes, as we have done before for the other forks, you'll need to update daemon, wallet, and miner.

As you can see here, the upcoming fork will bring to Monero a new PoW algorithm: the CNv4, Cryptonight variant 4 aka CryptonightR.


Monero forked into 4 separate chains. How can one claim them, and where can one dump them?

First off, there are not 4 separate chains. There are only 2 chains: the official Monero, and a common chain shared by Monero Classic, MoneroC, Monero 0, and Monero Original. The last four are simply rebranded versions of pre-network-upgrade official Monero. Since they operate on the same blockchain, spending (receiving) coins with (say) Monero Classic will have the same effect as spending with Monero 0.

  How does one claim all these forked coins from Monero's hardfork of April 2018 in a safe way?

Depends on what you call safe. Your fund on both forks will not be gone as long as (1) the forked coins' binary is not malicious, and (2) there is no replay attack when you spend your coin in one fork.

For (1), the safest is to compare the source code of any of the four "brands" with Monero's Helium Hydra (v0.11.1) source code, make sure nothing nasty is present, and compile it yourself. (This implies trust on Helium Hydra source code.) If that sounds too much work, you can try using Monero's binary for Helium Hydra, and change the seed nodes to be the forked coin's nodes. However, there's no guarantee that the old Monero binary will still work after network upgrade. It will certainly not work if any of the four "brands" undergo a network upgrade.

For (2), simply spend your coins with at least one post-fork image inside the ring. It will be automatically rejected when attacker replay it on another chain. Alternatively, spend the fork coin first with default ringsize, which is below Monero's new ringsize minimum.

If you are talking about privacy, have a look at my previous question. The two answers there basically said it all. Not claiming the forked coins is the safest. But if you have strong reasons to do so, you still have a chance to preserve part of your privacy. Make sure to spend the coins using the same ring. Note that since Monero Lithium Luna (v0.12.0) has a higher minimum/default ring size, you will be using a non-default ring size in the fork. Note also that this strategy is incompatible with the mitigation against replay attack above. I'll leave the work of suggesting a "safer" operation to a real expert.

  And which exchanges support these coins to dump them on?

CoinEx and HitBTC (unsurprisingly) has rewarded Monero holders with the fork coins. CoinEx uses the name Monero Classic (XMC), while HitBTC uses Monero Original (XMO).

(Exercise left to readers: If I bought XMC from CoinEx, can I withdraw it to HitBTC's XMO deposit address?)

If you really have a bullish view on the forked coin, I recommend against claiming the fork coin. Instead, sell your Monero for BTC or USD(T), then buy XMC (aka XMO). Currently XMRUSDT is 170 while XMCUSDT is 3.66. With a price difference of 46x, you just need to sell ~2% of your Monero to get the same amount of Monero Classic, without compromising your, or other people's, privacy.

Remember, when you use the coins in both chains, you are automatically causing damage to everyone's privacy. From an economic point of view, this will devalue both coins and, ultimately, your fortune.


Largest ring size ever used in a Monero transacation

According to Monero Blocks statistics the highest pre RingCT ringsize was 850. I was not able to immediately locate that transaction on the blockchain.

I was able to find a sample 150 mixin transaction from block 1,067,631 with a size of 70,219 bytes and a transaction fee of 0.69 XMR.

The above pre RingCT ring size and transaction size records were prior to the introduction of RingCT. With the recent v0.10.3.1 point release a new dynamic block size limiter algorithm was introduced to account for the unexpectedly fast adoption of RingCT.

Someone recently completed a transaction with a new record ringsize of 4500 with a size of 306,775 bytes and tx fee of 0.093729000000 XMR. This transaction appears to be near current limits, with anything larger according to smooth likely being:

  too big relative to fee and penalty (unless the block size grows).
  If it were slightly smaller, say 4000 instead of 5000, it likely would confirm and with a fee of less than $2. That's a pretty nice demo of how to achieve an extreme degree of untracability at significant but not obscene cost.


Can I use Coinhive to mine Monero without problems with Google Safebrowsing?

Google Chrome as far as I'm aware doesn't block the coinhive miner that asks for your permission, so unless you're having an issue already I think you'll be fine.


According to Abuse IP DB, this IP has been involved in hacking and spam attempts several times. This could be also a dynamic IP used by DSL subscribers. However, it should be save to whitelist all outgoing connections for monerod, since it only syncs with the monero network and shouldn't be able to download any executable code (unless there is a serious security flaw in monerod itself).


Can the monero-wallet-rpc handle multiple requests at the same time?

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

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

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

Which points out this is running in a single thread.

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


Quoting https://src.getmonero.org/resources/moneropedia/tail-emission.html:

  Monero block rewards will never drop to zero. Block rewards will gradually drop until tail emission commences at the end of May 2022. At this point, rewards will be fixed at 0.6 XMR per block.


Error mining has not been started :possibly lost conection to daemon

Apparently you are trying to start mining on a random remote node.

When you connect your wallet to a remote node and enter the start_mining command, you are in fact asking the remote Monero daemon to start solo mining and sending the reward to your address if it finds a block. Obviously, the owner of the remote node will not allow random stranger's wallets to use his computing power (by starting his Monero daemon with the --restricted-rpc option).

The start_mining command will only work if your wallet is connected (with the --trusted-daemon option) to one of your own Monero daemons (i.e. started without the --restricted-rpc option, and not openly accessible from the whole internet).


If you create a Bitcoin wallet with Trezor first, could you use the private key to create a Monero wallet using NoodleDoodle's firmware?

Installing a new firmware on a Trezor, it won't be possible to import private keys.

Because of the way Hierarchical Deterministic wallets work, a new seed and wallet will be created (with its own set of private keys).

Therefore, you should temporarily transfer your bitcoin to another safe offline device while you set up the new firmware and seed and make sure you have back ups for the temporary wallet.


What's the explanation for certain high fee transactions/blocks?

From my understanding transaction fees are calculated automatically based on the transaction size in bytes, the current average block size, etc.

That's right. It's the minimum fee, and the fee (per kB) is actually calculated based on only the current block reward, and last 100 blocks median block size. The constant parameter chosen means that the minimum fee is enough to make it economic for the miner to expand the block size for exactly 0.6% as it wold result in the biggest earnings per block.

  Does the monero wallet have an option to specify transaction fees I'm not aware of?

There is a setting in the wallet offering 3 priority levels: 1, 2, and 3. The first level is your minimum fee, 2nd level is 20x that, and the 3rd level is 166x the min. fee. After the HF, there will be 4 levels with x1 x4 x20 and x166 multipliers, where x4 will be made the default. Note that due to HF changing the min. block size, the x4 will cost/kB the same as x1 does right now. This will make x1 a kind of "low priority".

Anyway, monero CLI wallet allows you to set the level to use with set priority <level> command. Thing is, it remembers the setting for all following transactions.

  Any idea what's going on here?

We can only speculate. Maybe someone needed to move a big amount urgently for catching some trading wave so the high fee would not really be an issue considering the value of a transaction. If he forgot to set the fee back to low, he'd be accidentally making high-fee TX-es even after the rush-hour.


More cores are better for Monero CPU mining?

I would say that it will not automatically mine better. What is important is the cache size of the CPU. You need 2 MB for one thread.

Let's say your cache is 4 MB and you have 8 cores, you still can only mine with 2 threads - or at least having more cores doesn't help.


What's the point of ring signatures if stealth addresses hide the actual addresses anyways?

Stealth addresses mask a receiver, so 5 different people could all send XMR to the same address, but the construction of stealth addresses is such that none of the 5 people could tell that any of the other 5 people sent XMR to the same address. All they would see are five outputs to five random stealth addresses, and they only know the true address that their own transaction was sent to.

If we extend this to more people, they could all be sending coins between one another (B to D, D to A, C to E, E to B, etc) but no one would be able to tell any other pairs by looking at independent transactions (B couldn't see D and E even if B has traded with both D and E separately).

Ring signatures mask which outputs are used as inputs to create a new transaction output. So extending our previous example, ring signatures would hide when (if ever) any of those five outputs are spent. They do this by essentially saying "one of these X outputs is being spent as an input into a transaction, but you can't tell which one." This prevents anyone from knowing when an output is spent.

In addition, ring signatures prevent linking of multiple stealth outputs that are combined as multiple inputs into a transaction. Without ring signatures, you could tell "these X outputs are all from the same person" while ring signatures obfuscate that.

With stealth addresses, you can't link two different transactions to the same address, but you can link the path of outputs. aka, A to B to C to D. So if I send you coins, I could tell when you then spend them. Ring signatures block this by making the source of a transaction be "either A or G or K or P" instead of "definitely A", etc.

Example:

Putting all this together, this means that if person A spends outputs "aa" and "ab" to send coins to person B as new output "bb", and then person B spends output "bb" and some other output "bc" to send coins to person C as new output "cc", each person involved could only see the following bits of information:

Person A:

Outputs "aa" and "ab" were spent, send to the address of person B, as new output "bb".
I included outputs "ff", "hh", "kk", and "oo" in the ring signature for "aa" and "fg", "hi", "kl", and "op" for the signature for "ab".
No idea what happens to "bb"... there's a tx that included it in a ring rignature to output "cc", but there are also txs that included it to output "dd", "qq", "tt", and "zz". Maybe one of those outputs have the coins now?

Person B:

Some coins from somewhere (the ring signature says it's either "aa", "ff", "hh", "kk", or "oo") and other coins from somewhere else ("ab", "fg", "hi", "kl", and "op") are now my output "bb".
I spent them when I sent coins to person C as output "cc".
I included outputs "dd", "ee", "ii", and "jj" in the ring signature.
I also spent output "bc" which became part of "cc" as well. "bc" was ringed with "de", "ef", "ij", and "jk" to hide the origin.
I can't tell if they've been spent, but they have been included in these tx ring signatures: "rr", "ss", and "uu". So maybe he spent them.

Person C:

Some coins from somewhere (either "bb", "dd", "ee", "ii", or "jj") and somewhere else ("bc", "de", "ef", "ij", or "jk") were sent to me and are now my output "cc".
I haven't spent them, but my output was included in ring sigs txs "rr", "ss", and "uu" so now Person B doesn't know if I still have them ;)


What was the difference in hashrate power when the March 2018 anti-ASIC Hardfork occurred?

The fork was moved to today (April 6, 2018), so it is hard to tell. Early indications based on block-times are about 80% of the hash-rate is missing. Some of that is non-ASIC miners failing to update on time. We should know more in a week or so.


What is the easiest way to get a notification for incoming transaction?

Using the --tx-notify parameter to monero-wallet-cli/monero-wallet-rpc, you can run an arbitrary program when the wallet receives a transaction. The option takes a command line as parameter. The binary in that command line should have a path if necessary. Before being called, any instance of the "%s" string will be replaced by the transaction hash.

For instance:

monero-wallet-cli --wallet-file example-wallet --tx-notify "/usr/local/bin/on-new-tx %s"

This on-new-tx binary will be called when the tx appears in the pool, and again when it is mined. In both cases, the txid will be passed as first and only parameter.


Where can I find the issue tracker for the smart mining?

See https://github.com/monero-project/monero/issues. It looks like I must have a lot more filler for the post to be accepted.


Backward compatibility will be attempted for at least a couple versions. Some breakage is unavoidable, however. Push comes to shove, you've got your private keys and you should always be able to use them with any future version of the software.

Auto update is not done, but the daemon checks for updates and tells you when a new update is available. It can download it and check hashes, but you will have to unarchive it manually for now.


How do you convert the mymonero.com seed to the simplewallet/monero-wallet-cli seed?

By using this page, you can generate your private keys from the mnemonic (note that you can also see and back-up your keys directly from mymonero.com interface, when logged-in with the mnemonic), which is all you need to restore your address. I would suggest to anyone to download that page and keep it somewhere just in case the site would go down.
Once you have the private spend key and private view key, you simply start the cli wallet like below:

Windows:

monero-wallet-cli.exe --generate-from-keys <filename>

Linux:

./monero-wallet-cli --generate-from-keys <filename>

This will create a new wallet from your keys and save it with the filename specified. You will be prompted for your password with which you want to encrypt the wallet, and then for your address and the 2 private keys. When you finish refreshing your wallet, you will see your actual balance.


Please refer to the following as to why your Base58 decoding mismatches:

Base58 does not strictly specify the format. This results in some implementations being incompatible with others, for example with regard to alphabet order.
...
Monero has its own variant of Base58.
In Monero the Base58 encoding is performed in 8-byte blocks, except the last block which is the remaining (8 or less) bytes .

[src]
I'm not aware of an existing Java implementation that encodes/decodes in the specific way Monero does (as described above), so you will likely need to roll your own, which should be an easy task.
Please also note, the Base58 decoding does not validate an address, it simply decodes the human readable string representation to binary. Depending on your needs, you could perform a very minimal verification of just the length and valid Base58 characters, a slightly fuller verification where you also check the network byte (which doesn't require a full Base58 decode), or you can go all the way doing a full decode, checking the network byte, verifying the checksum and checking the public view and spend keys are valid curve points.
I'd also like to draw your attention to an ecosystem project: monero-java. It currently has very little in the way of address validation (lots of "TODO" comments in the relevant file MoneroUtils.java), so if you do end up writing the relevant code, please consider contributing back to that project.


Does the monero-powpy miner check if it has a new job?

The stratum miner processes any jobs sent to it. Although the stratum miner is one file, it is actually two processes:

The main process handles the socket messages between itself and the connected pool.
A worker process which mines jobs.

Line 88 (which is in the 1st process) has q.put(job), which puts a received job in a queue and line 111 (which is the 2nd process), has job = q.get(), which consumes a job and mines it.


What are the "public" viewkeys and spendkeys?

Note: the letters between parantheses correspond to the letters used for the math in the CryptoNote whitepaper¹.

The public view key (A) and public spend key (B) are the counterparts of the private view key (a) and private spend key (b). The public keys are needed to generate a public address. This is done as follows. First, the private view key and private spend key are sent to the ed25519 scalarmult_base function (G) to create their counterparts, the public view key (A = aG) and public spend key (B = bG). To create the actual public address, the following steps are performed²:

The pair of public keys are prepended with one network byte (the number 18, 0x12, for Monero). It looks like this: (network byte) + (32-byte public spend key) + (32-byte public view key).
These 65 bytes are hashed with Keccak-256.
The first four bytes of the hash from 2. are appended to 1., creating a 69-byte Public Address.
As a last step, this 69-byte string is converted to Base58. However, it's not done all at once like a Bitcoin address, but rather in 8-byte blocks. This gives us eight full-sized blocks and one 5-byte block. Eight bytes converts to 11 or less Base58 characters; if a particular block converts to <11 characters, the conversion pads it with "1"s (1 is 0 in Base58). Likewise, the final 5-byte block can convert to 7 or less Base58 digits; the conversion will ensure the result is 7 digits. Due to the conditional padding, the 69-byte string will always convert to 95 Base58 characters (8 * 11 + 7).
This 95-character result is the (obscenely long) CryptoNote public address!
If you're creating an integrated address, simply append the 64-bit payment ID to step 1 and continue; everything else is the same except for the lengths (77 bytes total, 106 Base58 digits) and the prepended byte (19, 0x13).

Given that MoneroAddress automatically calculates (and provides you with) the public address, you don't have to save the public view key and public spend key.

Luigi1111 wrote a somewhat easy to understand introduction to the cryptography of CryptoNote (and thus Monero), which can be found here.

Sources:

https://cryptonote.org/whitepaper.pdf
https://xmr.llcoins.net/addresstests.html


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


Could a sidechain with complete transparency be pegged to Monero?

Would is be possible for a developer to create a completely transparent sidechain that is pegged to Monero?

That would certainly be possible. To prevent issues with the mainchain we would have to implement a cryptographic proof, i.e., the amount of XMR that went into the sidechain would have to be equal to the amount of XMR that goes back into the "mainchain". The biggest issue with sidechains currently is how to secure them. One would need to convince miners to secure their sidechain. In sum, it doesn't matter whether the sidechain would be private or (completely) transparent.


Why does the Monero difficulty increase?

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

You can find the answer here: Blockchain properties: what are Height and Difficulty?


Do Transaction version 2 (ringct) have a different hash function or different input for computing tx hash?

It turns out that for version 2, the hash is computed by combining 3 other hashes and then computing the hash of the aggregate.

To be specific, the tx hash turns out to be:

H(H(prefix) || H(RingCTBase) || H(RingCTPrunable))

Where H is the Keccak256 hashing function, prefix is the Transaction Prefix serialized, RingCTBase is the RingCTBase serialized and RingCTPrunable is the RingCTPrunable serialized.

The details can be found in src/cryptonote_basic/cryptonote_format_utils.cpp's calculate_transaction_hash.

https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_format_utils.cpp#L604


Do any Monero wallets have the ability to create a transaction without broadcasting it, and then broadcast it later?

You can use a watch-only wallet to create the TX. When executing transfer command, it'll just save the TX to a file. You can then later open a full wallet and sign & send the TX. It's the same process as described here, only simpler, because you're not using a cold set-up. If you have both wallets in the same folder, you can just have them both opened and execute the commands without having to move the files around.

It's really a work-around because there's no option to have the full wallet make a TX to a file.


How much funds or runway does the Monero foundation / marketing department have?

There is no Monero foundation or marketing department. If any funds are gathered, it's for a specific purpose via project-specific crowd-funding platform known as FFS (forum funding system): https://forum.getmonero.org/8/funding-required


What's the easiest way to integrate Monero Payments without trusting a third party?

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

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

The basics of receiving payment are:

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

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

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

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

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

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

Also the following is essential knowledge to tally payments:

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

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


I have a private key for a monero address. Which application lets me load in a custom private key to spend from?

Both the official CLI and GUI will allow you to restore a wallet from keys. In order to import a wallet from keys you need (i) the private spend key, (ii) the private view key, and (iii) the public address. Note that in the current implementation the private spend key is deterministic. Thus, if you only have the private spend key, you can easily "derive" the private view key and public address from it. There are tools out there that will streamline this process for you. For example, there is this tool from core-team member luigi1111. You can use either the addressgen or addresstests page to generate the private viewkey and public address from the private spendkey. In addition, for security reasons, it's generally advised to use these pages offline.

To actually restore a wallet from keys, you have to add the following flag to monero-wallet-cli:

--generate-from-keys <new-wallet-name>

On Windows make sure to launch it from the command line. Go to the folder monero-cli-wallet is located and make sure your cursor isn't located on any of the files. Subsequently do SHIFT + right click and it will give you an option to "Open command window here". Lastly, type the following command:

monero-wallet-cli --generate-from-keys <new-wallet-name>

On Linux and Mac OS X you should use the terminal to launch monero-wallet-cli. Note that this has to be done from the directory monero-wallet-cli is located in. The command is as follows:

./monero-wallet-cli --generate-from-keys <new-wallet-name>

For the GUI, it's fairly straightforward, as the wizard will provide you with an option to restore from keys.


You seem to be missing the applicable libraries for the build.

If you go to the Monero github page.

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

and scroll down to: Compiling Monero from Source.

And install the necessary libraries highlighted, that should resolve your issue.


MyMonero architecture question: blockchain scanning put into backend mainly to save CPU in the app, or to save bandwidth?

MyMonero saves both Bandwidth and CPU in the expense of giving up your view key.

Monero has no light wallet that is comparable to Bitcoin & other similar Altcoins because monero requires the whole Blockchain for both receiving/sending transactions.  Having the whole blockchain is resource intensive specifically when starting to synchronize.

Thus, the only way to have a light wallet that is both less compute/bandwidth is to use a third party server where it will listen for your incoming transactions. In addition, this is not an ideal solution since it will not scale compared to P2P and you have to give up your view key.

In the future a light/hardware wallet maybe implemented.


The miners use standard HTTP, and the pool will send information to the miner via the connection the miner itself initiated. This means you don't need any incoming rules for new connections. You will need to allow new outgoing connections to the port you want to mine on (this depends on your pool and chosen starting difficulty, see the "Getting started" page on the pool for details), and allow incoming data on the same connection.

Now I can't give iptables rules for this, but since it's a bog standard TCP duplex connection, you should be able to easily find one on the internet and adjust the port number.


How to get network hashrate from monero daemon via RPC?

You can call the getinfo RPC, which contains the two values you want: difficulty (the threshold a hash must meet to be a valid block) and target (the number of seconds the monero network attempts to keep between blocks, on average). Divide the former by the latter to get the estimated network hash rate.

Example using curl:

curl -v -X POST http://127.0.0.1:18081/getinfo -d '{}' -H 'Content-Type: application/json'


Am I understanding PPLNS correctly in this example?

You are paid proportionally to the number of shares which are yours in the last N (in this case 100000).

If only 1/100000 of those are yours, you'll only get 1/100000 of the block reward.


Simplewallet password confirmation during wallet creation

That feature does not yet exist, but there is an open issue for it in GitHub and a fix is being worked on.

+bool password_container::read_from_tty_double_check(const char *message) {
+    std::string pass1;
+    std::string pass2;
+    bool match=false;
+    bool doNotVerifyEntry=false;
+    do{
+        if (message)
+            std::cout << message <<": ";
+        if (!password_container::read_from_tty(pass1))
+            return false;
+        if (m_verify==true){//double check password;
+            if (message)
+                std::cout << message << ": ";
+            if (!password_container::read_from_tty(pass2))
+                return false;
+            if(pass1!=pass2){ //new password entered did not match
+
+                std::cout << "Passwords do not match" << std::endl;
+                pass1="";
+                pass2="";
+                match=false;
+            }
+            else{//new password matches
+                match=true;
+            }
+        }
+        else
+            doNotVerifyEntry=true; //do not verify
+            //No need to verify password entered at this point in the code
+
+    }while(match==false && doNotVerifyEntry==false);
+
+    m_password=pass1;
+    return true;
+  }


Yes, you have to place your xmr address in the config, along with the pool address you chose.
Not necessarily, you could just keep the same address and pool, but other settings depends on your mining hardware
Yes, why not? it's just another debian based OS. you can edit the Cmake file to deal with your OS.
You could probably use it with tor or i2p by redirecting the traffic to it.


Keep mining to replace an already published block

Assuming that the network is healthy which means there are many competing  miners for a block. It would not make sense for a miner to keep mining an already published block because by the time it will be able to find that block the blockchain is already longer compared to his chain. Even if there are nodes that would accept it the network will always select the longest blockchain.

For example, if we assume that the said miner can find a block every 1 hour and blocks are being found every 2 minutes in the entire network. The worst scenario is when it just mined a block. This means it is impossible for him to grab the block from an hour ago because there are already 30 blocks ahead of it.

Therefore, the best case to steal a publish blocked would be that when the miner found a block an hour ago. There is a chance for that miner to keep mining for that block and be able to be accepted. However, its chances diminishes as the blockchain increases. In this case every 2 minutes. Probably at 2 blocks that miner would not be able to submit its block and accepted in the network.

This would cost a lot for that miner since it has only a very small window to publish an already submitted block. It would  be profitable  to just be a good miner and find the next block which has more probability of mining it rather than mining with an already published block.

In another case if the network is not healthy and that miner can mine blocks faster than the entire network it would be a different story. But this only happens when the network is at its infancy.


To completely remove Monero GUI Wallet from Windows 10 you need to:

Delete folder bitmonero in: C:\ProgramData\bitmonero\
Delete folder Monero in: %userprofile%\Documents\Monero
Delete registry entries The Monero Project:

regedit > Computer\HKEY_CURRENT_USER\Software\The Monero Project\


is the Bitmain X3 compatible with Monero

No the hardfork changed the algorithm to prevent ASIC usage.

Source


What is the difference between Monero (XMR) and Nav Coin (NAV)?

Despite both being advertised as privacy-focused cryptocurrencies, they are very different.

Monero uses ring signatures, RingCT, and stealth addresses to hide information on the blockchain. For every transaction, there is no way for an outside observer to determine the sending address, the amount sent, or the receiving address. Optional transparency can be provided off-chain by giving the desired person(s) the view key. Monero can be used with Tor or I2P manually, and Kovri is being worked on to provide native anonymous routing functionality.

Nav Coin uses trusted clustered servers to process transactions. When the "anonymous" option is selected, transactions are sent to these servers, which conceal the recipient address from others. It does not protect the sender, it does not hide the amount, and there is a trusted party that is omniscient in this process.

In summary, Monero protects significantly more information about all transactions (not just a select few) without using a trusted party.


There is no avoiding editing the firewall rules on Tails. Instructions for running Monero on Tails can be found in the projects README and quoted below:

  Using Tor on Tails

  TAILS ships with a very restrictive set of firewall rules. Therefore,
  you need to add a rule to allow this connection too, in addition to
  telling torsocks to allow inbound connections. Full example:

sudo iptables -I OUTPUT 2 -p tcp -d 127.0.0.1 -m tcp --dport 18081 -j ACCEPT

DNS_PUBLIC=tcp torsocks ./monerod --p2p-bind-ip 127.0.0.1 --no-igd --rpc-bind-ip 127.0.0.1 \
--data-dir /home/amnesia/Persistent/your/directory/to/the/blockchain


How does Ring Confidential Transactions work?

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

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

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

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

RingCT achieves this by doing two things:

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

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

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

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

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


I know the daemon RPC guide has recently been fully updated and the wallet RPC guide has recent updates.

Issues can be tracked (and contributions to update) at https://github.com/monero-project/monero-site/


What alternative cryptography could be used in the future to protect Monero against quantum computers?

Hash functions are not (as) vulnerable to attacks made possible by the existence of quantum computers, as the quickest way to break a hash function is via Grover's algorithm, which provides "only" a quadratic speedup, unlike other quantum algorithms, which can provide exponential speedup over their classical counterparts.

So if you never reveal your public key until you spend all the money from that address, and reveal only the address, you might be okay, as address -> public key would require inverting a hash, which we can assume is still difficult.

Signatures such as edDSA would be broken though, so Monero would probably be best moving to hash-based signature such as Lamport signatures, so that an attacker with a quantum computer can't calculate your private key from your public key/signature and then attempt to double spend your coins.


Mining and not seeing anything so for at 500H/s

If you're using the GUI to mine, what's happening is the GUI is basically sending a message to its daemon to say "hey, this is my wallet address, please start mining, and then if you find a block, please pay the block reward to that wallet address."

That's fine, but note that you are solo mining.  Mining rewards are only issued to a miner that solves a block.  In a pool, pooled resources add hash power to increase the likelihood of finding a block.  If a pool finds a block, it shares the block reward with the pool miners (generally minus a fee).  In your case, you'll keep the entire block reward if you find a block, but your hash rate is very low compared to the network hash rate, so it will be very, very, very seldom that you find a block.

Assuming a network hash rate of 500 MH/s, and with your 500 H/s, you should statistically win 0.0001% of the time.  There are 720 blocks mined per day, so you'd win .00072 blocks/day.  This basically means you would win an actual block of your own every 1,400 days or so.  So if the network hash rate were 250 MH/s, then you'd only have to wait, on average, 700 days for a block.

Considering that you may not want to play the lottery for several years before accumulating any winnings at all, you may want to use a pool mining software like xmrig or xmrstak, among possible others, and then mine on a pool.


How can the network or monero community reduce the txpool size?

Not really. Rapid growth in hashrate would only be slightly useful short term until the difficulty retargets which happens rather fast. This is only because you'd reduce the time between the blocks slightly so you may be able to squeeze a little more over some time period.

It really relies on blocksize median increasing, which is happening slowly - right now at 70kB. However, there's a problem with the current set-up (due to size of a single typical TX relative to min. blocksize) which ought to be fixed in the next HF. See here for more details: How can block size grow over time when miners are incentivised to keep size small?


As I understand it, it'd be a form of 2FA on a particular address.

It could work, but it'd be clunky (no such thing is implemented at this time).

You'd do something like this:

Create a new address type, call it "password-protected address".
Append the public key of k to the normal public spend/view pair. The address will be even longer than normal. :)
The sender then creates a normal stealth output, but adds the pubkey of k to it (P + K if you will).
The receiver, when scanning for outputs, would also check if any match P' + K.
To spend protected outputs, the wallet would prompt for the password to derive s, then add s to the generated private key for that output to get the real one.

Overall it's not that clunky, but you would also have to provide s to get the key image (for spent status when scanning).


How can we make Monero based eCommerce payment integration?

You will have to have some code or product that is able to determine when a monero payment has been received at your merchant address, and compare it to the payment id (or integrated address) your ecommerce system generates.

There are two easy approaches:

Use a 3rd party merchant solution
Run your own wallet live on your server to scan for incoming transactions

Number one is easy, but does require you to rely on a 3rd party. You may be sacrificing some privacy or reliability, but these are pretty easy to work with. From getmonero.org has a list of merchant info, including payment processors:

https://getmonero.org/getting-started/merchants

At this time, there are two publicly known services to help:

https://payb.ee/
https://monero-merchants.com/

PayBee is in beta, and requires a beta signup. I don't have details on their API or how to use it.

Monero Merchants appears to be an open API that does not require an account or API keys. You will need a developer to help write some of the code, but it should be very easy to set up. Your website just tells the merchant API how much monero you need and what address you want it deposited into. They respond with a different monero address and payment id for your customers to send monero into. Your website can then check to see if the monero has been received. They collect the monero in a wallet they control (that you can't see) and will then transfer it to your account.

If you need more control or privacy (so a third party isn't involved) you will need to run a wallet live on your servers to scan for incoming transactions to your wallet address. There are libraries available for a developer to integrate with your website, although it requires an ecommerce platform that can accomodate custom code. You can see a list of libraries at https://getmonero.org/getting-started/merchants in the "Libraries and Helpers" section.

One such library is https://github.com/PsychicCat/monero-php which is a php library that will communicate with a monero wallet via RPC and is a good starting place if you need something custom.


Is it possible to get the wallet address from an integrated address?

Yes, you can use Box 8 in the Check Address section of this tool: https://xmr.llcoins.net/addresstests.html


How do I set the user agent in simplewallet?

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

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

So you use the --user-agent flag.

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


Adding misc text values onto the get_info page of a public node

The only way to add custom values would be to edit the source code and recompile. There are however good reasons why such a feature is not made easily available - fingerprinting. In fact, quite the opposite feature exists, a way of restricting what get_info divulges (restricted mode).
As a node operator one should want to share as little information as possible and for what information is shared, should not have unnecessary distinguishing marks. Monero aims to limit the mistakes users can unwittingly make in this regard, for example the addition of restricted mode mentioned above and the removal of unencrypted payment IDs.


How is Karbowanec different from Monero?

Both CLI and QT wallets are forks of CN reference implementations. By skimming over the Github pages, it seems like there are just some minor adjustments done to the original CN implementation, and that's about it. Also, their website doesn't state any specific features which would differentiate it from CN.

The difference between Monero and Karbowanec is practically the same as the difference between Monero and CN.

Since 2014, and at the time of this writing, Monero had 2866 commits on Github so it's hard to point a finger at some specific difference as there have been thousands of lines of code edited and decades of man-years spent working on it since the inception.


It sounds like you're still synced to the wrong chain. You'll need to download the latest GUI wallet (v0.12.0) from here: https://getmonero.org/downloads/  When you have allowed the new wallet time to sync, you will likely find your funds in your wallet and that they have not been sent.  You can then send them to your recipient safe in the knowledge that you and your recipient are using the same current blockchain.

You can get more info from the guide you've already mentioned above:
I forgot to upgrade (from CLI or GUI v0.11 to CLI or GUI v0.12) and, as a result, accidentally synced to the wrong (alternative) chain  Following this guide should resolve your problem.