What is a sweep input and how do they work?

Your balance is made up of outputs of various amounts which you've received in the past. Every time you send, some of those get combined together until you reach some amount, which is then sent to the destination, and some change returned to your wallet.

Think of outputs as bills: you received a bill of 40 and 100 in the past, and now you want to pay something worth 120. Your wallet 'burns' the 100+40 bills, creates new bills of 120 and 20, sends the 120 to your recipient and returns the 20 to yourself and you're left with the bill of 20, plus whatever else you already had in the wallet. In Monero, these 'bills' can now be created with any amount (pre-RCT, they had to be round numbers like 10, 1, 0.1, 0.01 ...).

Sweep takes all of your outputs and sends the balance to an address of your choosing. You'd want to use this to move entire balance of one wallet to another, or to clean up your wallet and combine everything into one big output (by sweeping to the same wallet).

There are normal transaction fees (per kB) applied. Of course, each additional output increases the size, and with it the fee. Another reason why it's convenient to have just a few big 'bills' instead of lots of small ones in your wallet.


Why is Monero more sensitive to reorganizations than Bitcoin?

This was touched on in another question here Why was the block time changed from 1 to 2 minutes? , and linked to this explanation. https://forum.getmonero.org/20/general-discussion/2401/increasing-the-block-time

Unfortunately smooth doesn't specifically spell it out, but my best guess is that ring signatures make reorganisations more difficult, which would make sense.


What is the output of a hash so that the PoW is validate

A hash is just a number. The hash is valid (in PoW terms) if it meets the current network difficulty. The network difficulty keeps getting adjusted so that the subsequent blocks get found approximately every 2 minutes.

As for determining if a hash meets the current network difficulty:

if B / H >= D then valid

Where B is the base (max) difficulty, 2^256-1, H is the hash and D is the current network difficulty.

Of course, the block being submitted also has to be a valid block (i.e. parses to a Monero block structure, has correct coinbase transaction etc etc).


Could something like the Bitcoin Lightning Network be implemented for Monero?

Yes most definitely. Much of the infrastructure that LN would require already exists in Monero, although multisig is a key component that is currently missing. Thankfully that is coming in the near future, after RingCT has been implemented, as it builds on the RingCT work.

There are some key improvements we'd likely make to an LN implementation for Monero, mostly focused on retaining as much privacy as possible. This is very early on in the process, however, and there is much discussion and thinking that still has to happen before we can commit to developing any such additional LN functionality.


Is the high transaction fees problem addressed in the upcoming monero v7 upgrade?

Monero's (dynamic) fee structure is very depending on the dynamic block size and the other way round and all changes have to be very carefully evaluated since otherwise the penalty algo for miners increasing block size might get obsolete.

For now, in the v7 upgrade (Monero 0.12) there has been just a quick fix implemented choosing low priority, so 0.25x of the standard fee if these criteria match:

there's no backlog in the tx pool for the low priority fee level
the last N (=10) blocks are not 'almost full' (>80%) (estimated by summing up the last N block sizes and dividing it by N times the current full reward zone)

There were no changes made to the constants per kB in this release and the fee structure is meant to be evaluated for the September hard fork along with Bulletproofs, which will be released if there is no serious flaw found during the currently ongoing external audits.


Where can I find binary (alpha) builds of the Monero GUI?

At this time, there are not any compiled alpha GUI binaries.

That being said, when such binaries exist, the only safe places to download said binaries from are:

Github - https://github.com/monero-project/monero/releases
getmonero.org - https://getmonero.org/downloads/

One last possibility is the stickied posts on https://reddit.com/r/monero, but use all normal precautions when downloading from untrusted sites.

Personally, I would not trust any links outside of these locations.

As for an ETA on binaries you can download? Soon™, as they say...


Definitively answering a question about sc_reduce32 with a simple to explain working example created a related unanswered question


How is the quadratic miners penalty calculated

When a block is built a block larger than the median size of the last 100, then a quadratic penalty is imposed on the miner such that:

penalty = base subsidy * ((block size / median size of last 100 blocks) - 1)²
subsidy = base subsidy - penalty

Miners can avoid this fee altogether by refusing to include transactions in blocks that would lead to exceeding the median block size, although this is likely not the optimal practice as including such transactions will often still be profitable.
Miners can create their own criteria for including transactions in blocks by balancing transaction fees collected against the quadratic miners penalty that will be applied.
For example for all blocks exceeding the median blocksize they could enforce minimum transaction fees with a formula that scales fee requirements to compensate for the quadratic penalty.


connecting wolf`s miner to monero daemon

This is my config:

{
    "Algorithms":
    [
        {
            "name": "CryptoNight",
            "devices":
            [
                {
                    "index": 0,
                    "corefreq": 500,
                    "memfreq": 1500,
                    "fanspeed": 65,
                    "powertune": 20,
                    "threads": 1,
                    "rawintensity": 640,
                    "worksize": 16
                },
                {
                    "index": -1,
                    "threads": 2,
                    "rawintensity": 16,
                    "worksize": 16
                }
            ],
            "pools":
            [
                {
                    "url": "daemon+tcp://127.0.0.1:18081",
                    "user": "4262DpuALSSiXgTZnZyuqaeJPbGFkRofkbdE2skF52xMHMnwtYceCw9CikUv44cC7bP1ejqSzE5dN18LagZkins4UBSjZUX",
                    "pass": "x"
                }
            ]
        }
    ]
}


Can I fake a balance by giving the view key to an auditor but omitting some transactions and key images?

The auditor will see that you have omitted part of the key images.

The auditor can see all the outputs received by your account. Without the spend key, the auditor cannot generate the key images corresponding to those, however. In order to prove your balance, you generate a signed list of key images (see https://github.com/monero-project/bitmonero/pull/928 for the new commands and RPC calls to do this, soon to be merged now merged), and send this to your auditor.

The signatures are essentially a 0-mixin ring signature. Since these have only one public key attached, this proves that the key image is that of the public key.

The auditor then loads those key images, and checks that each purported key image matches the public key of the output that the auditor knows was received. If the signature checks out, it is proof that the key image really is the key image for this output. The auditor can then check the blockchain to see whether this key image appears on it (spent) or not (unspent).

For reasons of simplicity, this check is done in blockchain order, so you're supposed to give the key images in the same order as their appearance on the blockchain. If you omit a key image (or add one, or change one), the signature will not check out, and the auditor knows you're trying to pull a fast one (or, you never know, a bug somewhere, data corruption in transfer, but Questions Will Be Asked).

A special case happens at the end of the list, since it's very possible that new outputs will be received between the time the signed key images are generated and the time they are checked. This is handled simply by stating that the balance is correct as of the last seen block height in the key images (technically, it's also valid till the block preceding the next output received, if any).

As for omitting transactions, this system works on key images for the outputs received. Transactions are not used, so you can't omit any.


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

To answer this question, we first have to explain how Monero works. The letters used in this answer correspond to the letters used for the math in the CryptoNote whitepaper. Note that scalars (private keys) are always represented by lowercase letters in equations and points (public keys) are always represented by uppercase letters.

In Monero you have two set of keys, namely the private view key (a) and the private spendkey (b), and the public view key (A) and public spend key (B). The public view key (A) and public spend key (B) are the counterparts of the private view key (a) and private spend key (b). That is, the private view key and private spend key are multiplied by the base point (G) to create their counterparts, the public view key (A = aG) and public spend key (B = bG). The public keys are needed to generate a public address. A detailed explanation of how this is done can be found here, but is irrelevant for this question. The view key that we can publish is known as the tracking key (a,B) in the CryptoNote whitepaper.

To illustrate how this view key works, we first have to explain how transaction outputs work in Monero. In Monero, coins are received to a unique, one-time stealth address. The formula for stealth addresses is as follows:

P = Hs(rA)G + B

Where:

P -- the final stealth address (one-time output key, the destination where funds will actually be sent);
Hs* -- a hashing algorithm that returns a scalar (i.e., the hash output is interpreted as an integer and reduced modulo l);
r -- the new random scalar Alice chose for this transaction;
A -- Bob's public view key;
G -- the standard Ed25519 base point;
B -- Bob's public spend key.

Stealth addresses are created as follows. First, the sender (Alice) does ECDH (Elliptic curve Diffie–Hellman) with her randomly-chosen r and the receiver's (Bob) public view key, A. This is point D (D = rA), which is a shared, secret point known only to Alice and Bob (D = D'). Thus, no one other than Alice or Bob is able to compute D. Second, Alice uses D to generate a new scalar, f, with f = Hs(D). Third, Alice computes F = fG. Lastly, Alice computes P = F + B (Bob's public spend key). Note that F is equal to Hs(rA)G in the formula above. Also Alice computes R by multiplying r by G, the curve's base point, (R = rG) and attaches it to the transaction.

If Bob receives a transaction, he wants to check if it belongs to him. This is done as follows. First, Bob retrieves R, which Alice has attached to the transaction. Second, Bob computes D'. In this step Bob doesn't (yet) know if D' is equal to D. D' = aR. Third, Bob computes f' = Hs(D'). Fourth, Bob computes F' = f'G. Fifth, Bob computes P' = F' + B. Lastly, Bob checks if P' is equal to P, which was included in the transaction as the destination. If P' = P the transaction output belongs to Bob.

From the aforementioned formula and explanation we can infer that, if an auditor knows a and B of Bob, he is able to compute aR (= D') for every transaction on the blockchain. Given that he also knows B, he is able to compute all stealth addresses for Bob (P) and thus is able to view all transactions and corresponding amounts Bob has received. Thus, the view key is able to track all incoming transactions for the corresponding account.

If Bob receives a transaction that belongs to him, he also wants to check if the outputs in this transaction have already been spent. This is done as follows. First, Bob recomputes f' = Hs(D') (as above). Second, Bob derives x = f' + b (to reiterate, b is Bob's private spend key). Third, to check if P is spent, Bob computes its "key image" and queries the blockchain to see if it is marked as spent. Key image = I = xHp(P). Lastly, to spend P, Bob needs to sign a new transaction with x.

From these steps we can infer that key images require the private spend key of Bob. Thus, if we want to track key images of a certain account (and thus the outgoing transactions), we would have to give the auditor our private spend key as well, which means he can also spend our funds! However, Bob would be able to retrieve the key images from the wallet and publish them, since an auditor wouldn't be able to derive the private spend key from the key images. This is a benefit of asymmetric cryptography. An auditor could subsequently query the blockchain to see which of Bob's published key images has been spent. Furthermore, he is able to compel Bob to publish corresponding key images for all outputs Bob has received. Given that he can also see all incoming transactions with the view key, he would be able to compute a balance for Bob's account.

I acknowledge this answer is quite technical and would certainly understand if you don't fully grasp it. It's quite difficult to answer this question in a less technical way. However, if you read the excellent articles of core-team member luigi1111, you would probably be able to understand. Most of this answer is based on his articles, hence.

P.S. luigi1111's articles can be found here:

https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-introduction

https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-part-2-stealth-addresses


Does the dynamic blocksize limit and penalty function lead to a tragedy of the commons?

With sufficient demand, one would end up with a boundless block size, and a minuscule block reward, a tragedy of the commons. What am I missing?

I would argue you are missing physics. At some point, the physical limits of the network bound the blocksize. I.e., if a miner decides to keep pushing the blocksize higher, eventually a blocksize will be reached that takes considerably longer to propagate through the network than a smaller block.

Indeed, there are two prerogatives for blockchain mining:

Crafting a block with the highest reward possible
Propagating that block to the entire network before a competing block propagates through the network

The evidence for #2 can be seen in the bitcoin network - mining pools opt to mine empty blocks even though they could receive more bitcoin if they mined blocks with transactions. (although this behavior seems to have stopped recently with the advent of centralized block relay networks)

So, as is often the case, the phrase "tragedy of the commons" is missing a key qualifier that the coiner of the term realized he should have added - "Tragedy of the unregulated commons". In our case, the regulation is physics, so the Monero network will always adapt at the rate of the technology that runs the software.

Edited to add: The dynamic fee algorithm also provides an incentive to keep the blocks small. As the block size increases, the minimum relay fee decreases.  Thus, even though you are filling the blocks with more transactions, it not necessarily the case that the transaction fees are worth more.


Step by Step tutorial to mine RandomJS on Wownero?

RandomJS is not used as a proof of work for Wownero.


Can I disclose transaction id of a transaction to the customer?

This is absolutely safe, and the simplest way to let him know payment has been sent.
Using a block explorer tx id will let the customer check in which block it has been included.


Can the Monero network survive if nodes never enable incoming peers? Is it a threat to decentralization?

Theoretically if no node accepted incoming connections then the network would be limited to transactions originating from any of the aforementioned nodes. The network would survive as miners would still process those transactions.

The biggest effect would come in the loss of third party services that require a remote node to operate (for example some light wallets). It is worth noting that this is highly dependent on the implementation of the service. For example markets supporting Monero run a full node to handle Monero network transactions and typically call in via the RPC interface to accomplish this. In this case (RPC) the services would not be affected.


how to cpu mine on arch linux after installing monero-v0.10.3.1?

Open the monero daemon (monerod) and type start_mining followed by your wallet address and then the number of threads.

For example:

start_mining 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A 4

This would start mining with 4 threads to the monero donation address. However this is solo-mining and it is unlikely unless you have high hashrates to actually find a block so I would recommend you join a pool.

A list of pools can be found here:

http://moneropools.com/

http://chainradar.com/xmr/pools

And a guide to mining to pools can be found here:

https://www.reddit.com/r/MoneroMining/wiki/index

https://www.cryptocompare.com/mining/guides/how-to-mine-monero/

It should be noted that mining to a pool requires additional software:

Confusion over Monero Mining Software

https://www.reddit.com/r/MoneroMining/wiki/index/windows-pool


How exactly is a pool mining reward distributed

It depends on the pool. Every mining pool will have a slightly different set of rules. Generally speaking they pay you on the amount of shares your miner submitted, and then do some type of formula involving the difficulty of those shares vs the rest of the pool (to determine your actual % of contribution) then once they get that %, thats what you'll get from the block reward that is shared among your fellow pool miners (after the pool takes its 1-2% pool fee).

As far as seeing a payout from mining on a pool for one day, in all of time, and never going back to it, you'll most likely get rewards for the shares you submitted, but unless you are mining with a few large rigs, one day's worth of mining may not be enough for you to get to the "payout threshold" of that pool.


Can someone give me an example of doing a json-rpc call such as getbalance in java

Ok i managed to do it, here is the code:

String curlCode ="./getBalance";
System.out.println(curlCode);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream ps = new PrintStream(baos);
PrintStream old = System.out;
System.setOut(ps);
InputStream is = Runtime.getRuntime().exec(curlCode).getInputStream();
InputStreamReader isr = new InputStreamReader(is);
BufferedReader buff = new BufferedReader (isr);

String line;
while((line = buff.readLine()) != null)
System.out.print(line);

System.out.flush();
System.setOut(old);
System.out.println("Here: " + baos.toString());
String balance = baos.toString();
JSONObject json3 = new JSONObject(balance);
Long long1 = (json3.getJSONObject("result").getLong("balance"));
BigInteger bigInt = BigInteger.valueOf(long1);
BigDecimal one = new BigDecimal(bigInt, 12);

System.out.println("Monero balance is: " + one);

Basically what i did was run a system command with the curl code inside, convert the terminal output to a json object and printed out the balance. I also had to convert the balance with bigDecimal because it didn't have a decimal place in it.

There is one important thing to add, i added a getBalance script with the following curl code inside:

curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"getbalance"}' -H 'Content-Type: application/json'


Can my mnemonic seed be hex data instead of something ASCII based?

When recovering by mnemonic seed, you must actually type your mnemonic seed (or at least the first 3 letters of each word, 4 in some languages). You are able to recover a wallet with hex data but in a different manner:

With simplewallet(monero-wallet-cli) the private key is the hexadecimal representation of the 25 word mnemonic seed. Recovery options from that hexadecimal representation are found here

With Mymonero the private key is the hash of hexadecimal representation of the 13 word mnemonic seed as demonstrated in the code below:

int main(int ac, const char* av[]) {

    // get command line options
    xmreg::CmdLineOptions opts {ac, av};

    auto help_opt = opts.get_option<bool>("help");

    // if help was chosen, display help text and finish
    if (*help_opt)
    {
        return 0;
    }

    // default language for the mnemonic
    // representation of the private spend key
    string language {"English"};

    // get 13 word mnemonic seed from MyMonero
    auto mnemonic_opt = opts.get_option<string>("mnemonic");

    // get the program command line options, or
    // some default values for quick check
    string mnemonic_str = mnemonic_opt
                          ? *mnemonic_opt
                          : "slid otherwise jeers lurk swung tawny zodiac tusks twang cajun swagger peaches tawny";

    cout << "\n"
         << "Mnemonic seed    : " << mnemonic_str << endl;

    // change the MyMonero 13 word mnemonic seed
    // to its 16 byte hexadecimal version
    xmreg::secret_key16 hexadecimal_seed;

    // use modified words_to_bytes function.
    xmreg::ElectrumWords::words_to_bytes(mnemonic_str, hexadecimal_seed, language);

    cout << "\n"
         << "Hexadecimal seed : " << hexadecimal_seed << endl;

    // take the 16 byte hexadecimal_seed, and
    // and perform Keccak hash on it. It will
    // produce 32 byte hash.
    crypto::hash hash_of_seed;

    cn_fast_hash(hexadecimal_seed.data, sizeof(hexadecimal_seed.data), hash_of_seed);

    cout << "\n"
         << "Hash of seed     : " << hash_of_seed<< endl;

    // having the hashed seed, we can proceed
    // with generation of private and public spend keys.
    // the keccak hash of the seed is used as a seed
    // to generate the spend keys.
    crypto::public_key public_spend_key;
    crypto::secret_key private_spend_key;

    crypto::generate_keys(public_spend_key, private_spend_key,
                          xmreg::get_key_from_hash<crypto::secret_key>(hash_of_seed),
                          true);

    cout << "\n"
         << "Private spend key: " << private_spend_key << "\n"
         << "Public spend key : " << public_spend_key  << endl;

    // now we get private and public view keys.
    // to do this, we keccak hash the hash_of_seed again
    crypto::hash hash_of_hash;
    cn_fast_hash(hash_of_seed.data, sizeof(hash_of_seed.data), hash_of_hash);

    crypto::public_key public_view_key;
    crypto::secret_key private_view_key;

    crypto::generate_keys(public_view_key, private_view_key,
                          xmreg::get_key_from_hash<crypto::secret_key>(hash_of_hash),
                          true);

    cout << "\n"
         << "Private view key : " << private_view_key << "\n"
         << "Public view key  : " << public_view_key  << endl;

    // having all keys, we can get the corresponding monero address
    cryptonote::account_public_address address {public_spend_key, public_view_key};

    cout << "\n"
         << "Monero address   : " << address << endl;

    cout << "\nEnd of program." << endl;

    return 0;
}


Sent some monero with the cli using the transfer command. How can I get the key to view proof that I sent it using an monero explorer?

If you know the txid for your transaction:

  get_tx_key TXID

And replace TXID with that transaction's txid.

Note that once you disclose that secret tx key to a third party, that third party can use it in the same way you do (ie, to try to prove they sent that tx).


You can restore a wallet by either using the keys, .keys file, the password or the 25-word mnemonic seed.

You can learn more about reading these answers:
How can I recover a wallet using the mnemonic seed? or Restoring Wallet from Keys file.


How do I check the process of mining, ie the percentage of a block to be finished?

...the percentage of a block to be finished?

It's not like a progression to completion, rather how many times you've tried to find a solution. If the network difficulty is 10, you'd likely find a block by the time you've tried 10 times, but you might find on the first try or any number of attempts.
If you want to track your luck, it's simply the amount of hashes you've tried divided by the network difficulty. If your hashrate is 20 KH/s, then 20,000 multiplied by the duration (in seconds) you've been mining gives you how many hashes you have tried.


How does one query the OpenAlias DNSSEC to return an XMR address in Javascript?

To query OpenAlias is to simply perform a DNS query on TXT records for a given domain. These queries can be secured by utilizing DNSSEC.

Full details of implementing (and more) is all documented at https://openalias.org


Why is a key image xHp(P), and not something simpler like Hs(x)?

An output has public key P and private key x, where P = xG and G is the well-known ed25519 base point.

The key image is I=x*Hp(P) where Hp() is a function that takes a hash of P and returns a valid curve point.

  Couldn’t you just hash the private key of the real input?

Take a look at the section 3.4 Back’s Linkable Spontaneous Anonymous Group (bLSAG)
signatures in Zero-to-Monero

That is the simplest example of a linkable ring signature, and all of Monero's more complex ring signatures are essentially based on this concept.

For the key image to be verified, even the simple bLSAG scheme requires the key image to be the scalar multiplication of the private key x on a point other than G. In simple (non-Monero) situations, that alternate point could be e.g. another universally well-known point H. However, if Monero used H instead of Hp(P), it would be possible for someone that sends you outputs to detect if you've later spent more than one of them (see Notes on the hash function Hp on page 17 of the CryptoNote white paper).


Perhaps I could run two instances of monerod on the same machine, with settings that cause one of my disks to synchronize against the other; but I don't know what command-line arguments to use. Can someone provide an example?

If you start a second monerod instance like:

monerod --p2p-bind-port 38080 --rpc-bind-port 38081 --zmq-rpc-bind-port 38082 \
    --no-igd --hide-my-port --p2p-bind-ip 127.0.0.1 \
    --data-dir /path/to/backup/data \
    --add-exclusive-node 127.0.0.1:18080

It will sync it's blockchain from your main, localhost, instance of monerod.


If history is rewritten, you will not be able to pull over an existing tree (it's a bit more complicated, but in the general case where you're only ever on master, it holds). This is the "fast forward" mode. If history you already have is rewritten, git will fetch the new data, but will complain that it can't fast forward, and leave you with your master branch, and the new commits in origin/master (assuming it's named that way in your tree).

Now, I am not 100% sure this is not gameable, since git does not use cryptographically strong hashes AFAIK. But it'd take some doing, at least.

Note that if the rewriting happens all in (from your point of view) future history (ie, in commits you have never pulled yet), you will not see this.


What are the different commands for `balance [detail]` in monero-wallet-cli

The command balance detail will show your balance for each address in your current account.

The command account will show you the balance in each account.

The command account switch N, where N is the number/index of an account, will switch to that account. You can then use the command balance detail per above to show the balance of each address in that account.

The command show_transfers is what you use to identify specific transactions. For example, to see all incoming transactions to subaddress index 3 of the current account, run show_transfers in index=3.

There is detailed help on all the commands by running help [command]. E.g. help show_transfers.


How can I manually stop attempting to connect to offline nodes

If I recall correctly the IPs of these nodes are stored in p2pstate.bin and therefore bitmonerod (the daemon) will try to keep connecting to them. This also answers your second question. There are two solutions two solve this issue. First, you can delete p2pstate.bin. Bear in mind to exit bitmonerod first before doing this. Second, you can manually ban these offline nodes with the ban command in bitmonerod. This command allows you to ban a certain IP for a certain amount of time.


How can Monero defend against a "majority of view keys" attack?

Let's start with the original question, which is making some false assumptions.

  Riccardo Spagni answered around 80%, which is a lot and an entity like IRS would not be able to get that many keys from actual users.

It's important to clarify 80% of what exactly, as we'll see below.

  But what about generating millions of accounts every hour to keep having 80% of all view keys in the network?

Doesn't matter. "Accounts" don't really exist. There's nothing written to the blockchain once you create an "account". Only when you actually receive your first funds, there are some outputs which are controlled by some wallet and which could be used for the mentioned attack.

  These generated and otherwise unused accounts would be used for transaction input mixing, right?

Not right. Until you actually receive some funds, there's nothing "yours" on the blockchain to "mix" with.

  There are 3 aspects I would like to see answered:

First, we must understand how the attack is supposed to work. Currently, by default, ring signatures are constructed with a ring size of 5 (1 of the signer + 4 other). This means that for any 1 input, there are 5 possible sources, ie 5 possible one-time keys (aka "outputs"). If someone recognizes all those 4 other one-time keys which your wallet picked as his, then to him it will be clear that the remaining 1 is the real one getting consumed.

Obviously, we get 80% based on that. So, if we increase ring size to 10, then the attacker would need 90% and so on. Remember, we're talking about one-time keys. Every Monero transaction generates those as destination and Monero are never sent to the address itself. Each Monero trasaction consumes some existing one-time key and generates a brand new one for the destination. The address is like a blueprint to create those, and the viewkey is a template used to recognize them as belonging to your wallet.

So, an attacker could own just 1 view key, but 80% of the one-time keys used for the input to be able to tell which one is the real one getting consumed. It still wouldn't reveal the owner just like that, but would only trace the funds 1 step back to some other one-time key. If you don't own 80% for the transaction which created that one, it's a dead end and you cant trace back further.

Since your wallet picks those other outputs randomly, an attacker can't plant them in advance. He must instead keep generating 80% of the outputs on the blockchain to uniformly cover 80% everywhere, so whatever your wallet would pick there would be a good chance of picking those that belong to the attacker. Remember, other people are transacting at the same time. So an attacker needs to beat the entire user-base of Monero. For every 1 legitimate output, he must make 4 others. He must pay the fee for it, too! Can you imagine the cost of sustaining such an attack?

We can now answer the 3 points

  How likely is such an attack? Is it merely theoretical?

Higly unlikely, as explained above.

However the above is not the full story, as there are other ways to recognize outputs as belonging to some address. You could steal people's view keys which would give you an edge without having to make the transactions yourself. You could coerce mymonero-type services (which keeps user viewkeys) to give up all user accounts, and then all of their outputs would then help you as well. So a situation where 80% of transaction volume originates from mymonero users would be a real danger.

  Is there way to detect such an attack?

I guess not really, since we can't ever tell 2 outputs apart. We can't know if some TX is legitimate or if it's been made with the purpose of generating noise. However, the cost of such attack is a good deterrant.

  Would increasing the ringsize help? Or would that just gain time?

It would help, yes. And time is really gained just by transacting normally - any legitimate transaction increases the cumulative cost for the attacker so he must try hard to keep up.


Acquiring greater than 51% of the Monero network can pose what kind of risks?

As I understand it, if a mining operator was to attain 51% of the network, they can perform a double spend.

This is one thing they could do, yes.

  But would this be detected?

You cannot detect a 51% attack occurring. To perform a 51% attack, you'd have to mine a secret chain with greater difficulty than the main chain, then replay this secret chain on the main network. Only at the point of replaying can this attack be observed, as this would cause a massive reorg on the main chain. To sustain the attack, the attacker would then have to continuously mine at greater than 51% of the total network. The damage will have already been done though.

  And if the same attack was done on Zcash, could it be detected also?

Same answer as above.

  What other potential abuse can a 51% mining entity cause?

Censoring transactions, double-spends, delayed tx processing, spam the network... just a few things that immediately spring to mind.


What signature prevents me from spending others' coins?

Section 4.4 of CN white-paper describes this. With the ring signature, all the keys used are equivalent, so you can't say which one is the actual signer. The signature can be checked against any of the public keys used in the ring. Let's define our one-time keys as

P = xG

Where P is the public key, x the private key, and G the EC basepoint.

If we let the same key produce two signatures, we would allow for a double-spend. That's where key images come in. The key used must also produce a key image with the signature. Trick is, the key image is a function of only the one-time key so it will be the same regardless of other parameters of the transaction.

I = xHp(P)G

Note that knowing I, you can't recover the P used. The key image also forms part of the signing and all the key images ever used are stored on the blockchain. If anyone would attempt to re-use x, then the resulting key image would be the same, and the signature would be rejected by the network as it would already be found on the 'used' list.

Note that there are no 'accounts' or 'addresses' on the blockchain. There are only one-time keys and key images. An address is kind of a 'blueprint' which lets the sender produce one-time key such that only the owner of the address is able to recognize it as belonging to it and recover the private one-time key.


At what date will the initial 18.4 million coins have all been mined?

The emission was set and determinable from day 0 and will never be changed.

The initial 18.446 million coins will be mined by May 26, 2024 (by comparison Bitcoin will be over 93% mined at the time). The precise hour and the minutes cannot be inferred because of the variance in the time to mine Monero.


In LOKI, how do you tell how much loki is being staked?

Given that the staking requirement is a known value, and the number of nodes active on the network is also known, you can calculate the minimum amount of Loki being staked on the network by simply multiplying the staking requirement by the node count. Let's take today for example:

Staking requirement (27137) * node count (465) = 12,618,705 Loki

The process of staking itself is explained in detail here https://lokidocs.com/ServiceNodes/SNFullGuide/

With the introduction of Infinite Staking, unlocking a Service Node takes 15 days. If your node goes down, it'll be unlocked in 30 days.


Monero block explorer, xmrblocks, build failing

The error, at the library linking phase, is stating it cannot find libcurl:

/usr/bin/ld: cannot find -lcurl

Install that and do a rebuild.

I would also double check you have any other dependencies installed before rebuilding.

To quote the README section on how to build:

# first install monero dependecines
sudo apt update

sudo apt install git build-essential cmake libboost-all-dev miniupnpc libunbound-dev graphviz doxygen libunwind8-dev pkg-config libssl-dev libcurl4-openssl-dev libgtest-dev libreadline-dev libzmq3-dev libsodium-dev libhidapi-dev libhidapi-libusb0


Monero margin trading on Poloniex and BitMEX

I'm going to just put a link to Poloniex's documentation, as pasting it here wholesale would be too much copy to be considered fair use (and it has formatting and images, and might change in the future):

https://poloniex.com/support/aboutMarginTrading/

And, one word of warning: margin is high risk, high reward. Keyword being "risk".


This may be related to the bug 4117: https://github.com/monero-project/monero/pull/4117

If so, then please ensure that you have the latest version of the app as it should have the fix that prevents that situation. If you are sure that you have the latest version, please update us here.


How do you force create a new monero address on coinomi?

Here is the official coinomi response:
If you need a completely separate address for this monero TX then you can add a second wallet from +coins. In Coinomi you cannot select which UTXOs are spent in each transaction, this is automatically done by the app.

The 'refresh' icon on the receive page, creates an integrated address - this address is the same receive address with a payment ID attached.

Monero Core/Coinomi: you can use the recovery tool listed at the bottom of our recovery guide for converting your Coinomi phrase to be used in the monero wallet. However, this is not needed since you can add a second XMR wallet in Coinomi (+coins) or simply just use the one address. - You will be happy to know that we have plans to add XMR sub-address support in the future too.

Hope this helps

Kind Regards,
Coinomi Support


Boolberry's Transaction identification by prefix

I just took a look at the get_transaction_hash function in the Monero source code, and if I understand it correctly, the way the transaction hash is computed will change once ringct is activated.

The comments in the code indicate:

v1 transactions hash the entire blob
v2 transactions hash different parts together, then hash the set of those hashes

The 3 parts of v2 transactions are:

prefix
base rct
prunable rct

Hashing the hashes of these 3 parts together gives the final transaction hash.

I suppose pruning the signature from the block chain will be possible (like in Boolberry), because keeping the hashes of the signature parts instead of the whole signature will still allow computing the transaction hash.


ccminer hashing speed not onpar with minergate-gui

i experienced similar Hashrates with MinerGate v6.6.
After updating to 6.7 the Hashrates were more accurate compard to them from ccminer.

From my perspective it was a wrong hashrate which was displayed.
You didn't name your operating system, but you could do a double check hashrates using linux ccminer vs windows ccminer.

Best regards


1)

Tails is a live OS, therefore changes made to your firewall (iptables) will not persist restarts. As per your last question, the iptables command is a different command to the one you are using to start Monero, thus the command:

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

Needs running each time you boot into Tails and want to use Monero.

The second command:

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

Needs running each time you wish to use Monero.

  If so is there a way to make this persistent?

As Tails is a live OS, I'd imagine you would need to build your own Tails image if you want the firewall rules to be persistent.

2)

  Why would I get the errors above and which steps would I have to take to avoid them?

This is a Tor specific question. According to this answer, you need a new bridge. I suggest you ask Tor questions on the Tor StackExchange site though.

3)

If you have the daemon running, you can mine. See the command start_mining:

help start_mining
Command usage:
  start_mining <addr> [<threads>|auto] [do_background_mining] [ignore_battery]

Command description:
  Start mining for specified address. Defaults to 1 thread and no background mining. Use "auto" to autodetect optimal number of threads.

If you want to pool mine (with something like XMRig), you're going to need to add appropriate firewall rules so the miner can communicate with the pool.


I lost all my funds after performing a transaction on the wrong (old) chain

Normally, you have not lost your XMR I think.
Why not start with the latest version of GUI/CLI and restore your old wallet with your seed.
The coins should be in your old wallet. Also check the restore hight.


How open Monero wallet and sweep_all with one command in CLI?

monero-wallet-cli --wallet-file MyWallet --password MyPass sweep_all address


How can I add my business to the merchant list on the Monero website?

Easy method:

Visit the merchant page
Use the open issue link at bottom of page
Login to and/or create a GitHub account
Click new
Enter your merchant information
Click submit new issue
Track your request here

Do it yourself method:

Visit the GitHub for the monero website
Login to GitHub
Make a fork of the site
Click data
Click merchants.yml
Click edit
Add your merchant information in a format consistent with the existing listings
Click create a new branch for this commit and start a pull request
Click propose file change
track your pull request


How do I get the weight of a transaction from the RPC daemon ... Not the weight of a transaction

Due to the contradiction, I'm going to assume you want the size.

I guess I could get size from the hex representation of the TX

Yes. Like:
curl -sd '{"txs_hashes":["329c12515493165e5580cf5541d429ca3f59d7ac949ba918c0f84af9450f13a8"],"decode_as_json":false}' http://localhost:18081/get_transactions \
  | jq .txs[].as_hex --raw-output \
  | wc -c \
  | xargs -I N expr N / 2

to get size of any transaction(s).
Or to also include fee related data:
curl -s http://localhost:18081/get_transaction_pool_stats

to get the size and fees of transactions in the tx pool. No use for historical, but useful for data gathering moving forwards.

but that doesn't take into account the weight-penalty

Note the penalty function applies to miners and block size. A user simply pays fees to cover the size of the tx they are sending. Want to send more data, pay more in fees. So if you're wanting data around the penalty imposition, you want to be looking at the block size and history.


See here for considerations on security.

Note that it is only partially true that brute forcing would involve having to scan the blockchain for every attempt. If you're doing a random search to find some random address with a balance then yes, you need to scan the blockchan for each to know whether you've hit the jackpot. If you're doing a targeted brute-force against a known address (or a list of them) then - no. This is because just rolling the seeds until the resulting address matches is enough. To actually see the balance, you'd still have to scan, though.


What is the concept of Refund Transactions from the MRL?

This isn't particularly helpful, but it's all I can find.

"Refund Transactions

Informal discussions with a Purdue researcher at the IEEE workshop yielded great new information about refund transactions under active research by one of his students. Refund transactions are a necessary component of certain payment channel applications. A scheme was proposed to us that involves modifying the structure of outputs and ring signatures to allow for a sender to include two outputs: one is valid prior to a specified block height, and the other is valid afterward. We are working with the researchers on the details and security of this scheme, which could have great applications to Monero transactions."

Source: https://www.reddit.com/r/Monero/comments/8fzfzx/april_monthly_report_from_sarang_noether/


How can a View Wallet be implemented in code?

Your code looks fine to me. Here is an explanation of what it's doing:

For each transaction, get the public key of each output listed in the transaction. Call the public key P.
We need to check whether this output was destined for us. We do this by calculating P' as P' = Hs(aR || i)G + B. If P' == P then the output is destined for us.

The generate_key_derivation method in your code produces aR. The derive_public_key uses that to then calculate P' as Hs(aR || i)G + B.

The only step that I think seems to be missing is to decrypt the amount of the output. For details, see my answer here How the receiver knows the amount that he received from the sender?

You probably also want to extract the public spend key from the user's public wallet address, rather than require that you know their private spend key to derive it. For information on how to extract it, see https://xmr.llcoins.net/addresstests.html


How can I change gui wallet display locale/language

When starting monero-wallet-gui, cancel where it ask for wallet password and you can select the language and regional format. selected english, then restart monero-wallet-gui and login.


In terms of raw performance, Nvidia and AMD compare favorably. Once electricity usage is factored in, Nvidia wins out with far higher efficiency in the current round of technology.

http://monerobechmarks.byethost5.com/index.php?i=1

In terms of Nvidia cards, the GTX 1070 seems to be at a good price/performance/efficiency inflection point.


Technical contributions of non-mining full nodes

A node helps miners know they are on the correct chain, it also helps users verify transactions, nodes also supply the blockchain to other nodes that are not yet up to date, it also acts as a broadcasting service for users when they want a transaction to be sent to all the miners.


Upgrading APK version of Monerujo with Google Play Beta version

it should work. BUT it may not, because the wallet folder has been renamed from "Monerujo" to "monerujo" (small m) so you may need to rename the folder with a file explorer.


Could Monero help me to implement a safe election for a small group of students?

This is possible with a "daughter" project of Monero called URS (Unique Ring Signatures) and was introduced by core-team member tacotime. From the README of the repository:

URS can be used to sign plaintext or binaries anonymously (among a group of known users). That is a user can sign a message, hiding among a group of known/registered users, that prevents the verifier from revealing the signer's identity other than knowing that it is in the set of registered users. The size of the set of registered users is flexible. Increasing this number slows down signing and verifying linearly, and also increases the size of the signatures linearly.
Bitcoin public and private keys are used to generate the signatures. You may generate your own keypairs with the set-generate function described below. Bitcoin addresses are also generated.
When in default (unique) mode, signatures are generated with the prefix '1' and contain immutable Hx, Hy values as the first two bigints in the signature. These are immutable per message and private key. That is, any single message signed with the same private key and keyring will always generate the same Hx, Hy values, so for this single message you can identify if multiple members of the keyring have signed (but not which one).
Signature blinding has also been implemented. Blind signatures are prefixed with '2'. While blind signatures lose their Hx, Hy uniqueness, they use an ephemeral key to generate that signature that is afterwards discarded. This will prevents someone in the future from being able to identify which member of the ring signaturesigned the message, even if all private keys for the public keys in the keyring are later revealed.
For more information on signature blinding, refer to this link.

From the abstract of the paper:

Abstract. We propose unique ring signatures that simplify and capture
the spirit of linkable ring signatures. We use new techniques to provide
an instantiation which can be tightly related to the DDH problem in the
random oracle model, leading to the most efficient linkable/unique ring
signature.

With these sources you should be able solve your "problem".


What is the size of the set of spent key images in Monero?

Each transaction input has a key image, and there are around 2.1 inputs per transaction on average. So, the 'key image set' is around 2x the number of transactions on-chain.
I do not believe a zero-knowledge proof is currently available, although you may find the description of a hypothetical 'unspent proof' in section 8.1.5 of Zero to Monero 2 is in the right direction.


What is the XMR Withdrawal field for when there is another address field on top for Binance?

This really is kind of misleading at Binance and i think they do it on purpose.

The field XMR Withdrawal Address is the wallet. The field XMR Withdrawal is the payment ID.

If you want to transfer XMR to your own wallet, you don't need to enter anything into the XMR Withdrawal field aka payment ID. But if you want to transfer XMR to a wallet at an exchange, then you often need to add a payment ID that you get together with your wallet address from the exchange you want to transfer XMR to.

Now the interesting part: If you don't get a payment ID along with the wallet address from an exchange, then most of the time you got an integrated wallet. An integrated wallet is a wallet that already includes the payment ID inside of the wallet address string.

So if you don't get any payment ID, don't worry, just enter the integrated wallet address into field XMR Withdrawal Address, check the No checkbox to indicate that you don't want to add a separate payment ID and hit the button!

I had the same problem while transferring XMR from Binance to Kraken. Worked flawlessly the way i described it.

If you want to know more about integrated wallet addresses, take a look here


If you did not include a paymentID shapeshift can not identify you as the payee so will not credit you if this is the case contact their support. I'm afraid your Monero may be lost.


How do you lock X amount of monero for 200 blocks using the cli wallet?

You can use the locked_transfer command:

locked_transfer 4xxx... 10 200

It will look something like this:


How do I stop locking my balance when executing transactions?

It's not a case of how much is in your wallet, rather how many outputs you own. If you only have 1 output, when you do a transfer, the recipient get's a new output with part of your spend output and you get the rest into a new change output. This answer explains nicely.

So this brings us to the question of how to prevent this. There is no way to prevent the locking of funds in the above scenario. However, what you can of course do is batch your transfers. If you need to send money to multiple people within the confirmation time (locked time), both commands transfer and transfer_split allow sending to multiple people in the same transaction.


GUI Beta 2 error on login: std::bad_alloc -

Locate your wallet files, there should be 3 files with the name of your wallet:

YourWallet.address.txt (This is not important, just the address written inside)
YourWallet.keys (This is the main thing to back-up, it holds your keys encrypted with your password - if you lose it you will need to restore from your seed words to make a new file; if you lose both this file and the seed your funds can't be recovered)
YourWallet (This holds wallet refresh data, and your TX history. If you need the history, keep a backup. You're probably getting the error because of compatibility of this file between GUI versions)

Rename the last one to YourWallet.backup and try to start the GUI again. You will have to wait for it to refresh the wallet, shouldn't take too long since you're already synced with the network.


Monero Gui syncing... is this supposed to take this long?

You aren't alone and it's one of the reasons (imo) that Monero isn't more largely adopted. Sync'ing the blockchain when spinning up a node takes a full day - which is simply untenable.


Are there any CryptoNote Monero forks that have a company backing the project?

Still no reply, so I'll post the one I know of, but there might be more.

Electroneum is a fork of Monero, which eschews development in favour of marketing. As https://electroneum.com/about/company/ shows, they have a company.

For those who might be tempted to click on the above, this fork is mostly a scam. See https://captainaltcoin.com/electroneum-price-prediction. It's basically a centralized premined coin with all flash and no trousers, and its "phone mining" does not actually mine, it just wastes your electricity and the company pays you for it. They're basically marketers and liars.


Could a tipbot be construed as a money service business?

Gov'ts seem to like making rules and seem to think that numbers (aka Mathematics, aka. crypto currencies) must be regulated by them.

Check your gov't, but assume the answer is yes.


How can I receive monero on my openalias address?

Type:

transfer xmr.mysite.com 0.50

You will get a prompt asking you to confirm the full address and show a DNSSEC validation notice. If it is okay, enter Y


Actually, there is no device that is so small that you could carry it with you like a laptop.

You could build your own desktop computer with a small case and a really good processor (that's what is important for mining Monero) but it would most probably still be bigger then a laptop.


If you have a recent enough daemon, you can run the bc_dyn_stats 100 command, which will include the median block size over the last 100 blocks, among other things.

If you have a recent, but not so recent daemon, you can try the getinfo RPC call, which includes the current block size limit, which is twice the last 100 blocks median:

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


Why does Monero prevent transactions from being spent without 10 confirmations?

Cryptonote is more sensitive to reorganizations than Bitcoin.

In Bitcoin, if N blocks are reverted, all the transactions they contain are now ready to be mined again (or might already be included in blocks that replace those N blocks).

In Cryptonote, if N blocks are reverted, any transaction that include an output created in those N blocks is also (probably) invalid, since outputs are refered to by their index within an amount. This means those transactions will be rejected, and will have to be recreated. Bear in mind that, due to ring signatures, the recipient of a coin is not the only one to include it in a subsequent transaction. Third parties also do.

Now, there are ways around that. The simplest is to prevent outputs from being used within a given number of blocks. Another would be to include public keys of inputs in a transaction, instead of indices. This would increase the size of a transaction markedly, though an optimization could be made when storing the transaction (turning public keys into their index). However, this is a bit complex, since you have to keep the public keys for a while, in case those outputs end up in a reorg.

As a last point: this has to be both a wallet and daemon rule, otherwise someone would be able to tell whether an input that was created very recently is the real one or not.


Best method to query address balance of 10,000+ monero private keys and store it in a mysql database?

There's a Monero wallet PHP library here (I've never used it so just suggesting) . Perhaps you could use it to create a PHP script that retrieves a wallet balance based on a view key and updates your DB accordingly

The your cron job could iterate over the 10000 wallets (using a managed queue) with the script.

Your DB should hold information like last_update_time in addition to keys, balances, etc.

I would use something like MongoDB for this kind of thing rather than mysql as you don't need a relational db and you will probably want to add fields as you figure out the angles on this thing


What is the command to unstake / unlock loki from a service node on the loki network?

request_stake_unlock <service node key>

The guide can be found here: https://docs.loki.network/ServiceNodes/SNFullGuide/#step-8-unlock-stake


From v4 at height 1,220,516, where rct becomes allowed, coinbase outputs are stored as pseudo rct outputs. There is one such output in block 1,220,516 and one in 1,220,517.


How to distinguish between the amount of the real input amount and the decoys

Since every transaction has multiple decoys from previous transactions that are connected to it (while only one is real), how does the user link the amount that is linked to the "real" transaction?

Firstly, all the decoy outputs are "real", they are real outputs created by previous transactions.

Second, the whole point of the decoys is to not be able to determine which is the real output being spent. The signer is proving they own one in each set/ring, but not which.

Third, the amounts for the generated outputs are encrypted in the transaction ecdhInfo field. Thus to obtain the decoy encrypted amounts, you grab them from the ecdhInfo of the transactions that created those outputs.

  EDIT: What is the math behind discarding the unnecessary "decoy" values, when checking the Pedersen commitment (of our output and the real inputs).

There is no "discarding the unnecessary "decoy" values". I suggest reading 5.4 in Zero to Monero which goes into greater detail, but to summarize: The input commitments included in the tx, are actually pseudo output commitments. These pseudo output commitments use the same original amounts but use different binding factors. As the sender knows the difference between the commitments, they can use this as the commitment to zero and sign.

Thus

     C = xG + aH
    C' = x'G + aH
C - C' = (x - x')G
     z = x - x'

Where x' is a new binding factor, C' is a pseudo output commitment and z being the private key of our commitment to zero.

With regards to your comment of "checking the Pedersen commitment", I presume you are referring to checking the sum of inputs and outputs is zero. For this, one is checking the sum of the pseudo output commitments (the inputs) minus the sum of the tx output commitments.

Of course one also needs to ensure none of the values are negative, and this is the purpose of the range proof (see Zero to Monero 5.5).


0 hashrate - issue when mining Monero with CPUminer

You are using a 3-4 year old miner.  The mining/hashing algo was changed in April (May?)  You are using the old and incorrect miner, thus bad shares.

Try:
https://github.com/fireice-uk/xmr-stak/

(oh and minergate is a pool with a bad rep for scamming/stealing hashes, from what I've read.)
Quick update:  I couldn't get xmr-stak to compile easy enough.  but got xmrig to compile on a Raspberry Pi3 & and Orange Pi Zero.  Getting accepted hashes/shares.

apt-get install -y git build-essential cmake libuv1-dev libmicrohttpd-dev
git clone https://github.com/xmrig/xmrig.git
cd xmrig
mkdir build
cd build
cmake ..
make


How to run xmr-stak with AMD gpu on Ubuntu 18.04

The AMD drivers are indeed frustrating on Linux, but these are required by XMR-Stak for AMD cards. You will almost certainly need to download the official drivers from AMD and try the various releases until you find one that works with your specific card. For me, this was only amdgpu-pro-17.40.2712-510357, but it depends which card you have. There are several minor point releases and finding one that works is honestly trial and error unfortunatley.

The other issue you may face is that you are on Ubuntu 18.04 - and none of the currently released drivers state supporting Ubuntu 18.04, you might get lucky though.


Are there protocol-level incentives regarding mix-in selection?

There's no direct incentive scheme at the present moment.

The only protocol requirement is for the number of decoy outputs in the ring signature (and that they're of the same denomination, for non-RCT TX-es). Which ones get chosen is up to the wallet.

If someone were to use a different one, he would probably be fingerprinting his TX-es in some way. It would likely not be possible to exactly be sure which ones because of some false-positives from other wallets, but still - some could be marked as "likely origination from xx wallet implementation". If enough people used the xx wallet, each user would still be hidden among other users of xx wallet.

Considering that with RCT you will be able to pick any random output on the blockchain as decoy, it doesn't make sense to re-use same ones. At the end, you'd be sacrificing your privacy - for what? So, there's that indirect incentive to stick to the default.

I'm sure that this aspect will attract more research as monero grows, which will provide more substantial answer to your question. Some research has already been done, see MRL-0001 and MRL-0004.


GUI Beta 2 Error Message (sync stuck and unable to send funds)

You're using an outdated version and therefore you won't be able to complete the initial sync nor send funds. You have to upgrade first using this guide:

How do I upgrade my software to v0.11.1.0?

This guide is applicable to upgrading from Beta 2 (v0.10.3.1) to v0.11.1.0 directly too.

Thereafter, use this guide to solve your pending transaction issue:

Transaction stuck as "pending" in the GUI


Best method of sweeping monero private keys without rescanning the blockchain for a balance?

To be able to make a transaction, the wallet must know how much it contains.

The approach for you would be to only scan from when the user made the transaction by specifying a restore height or date. Allowing you to only scan i.e. the last 10 blocks.

This technique only works if you are sure that each user only used an address from a specific moment. You can couple it with a remote node to allow multiple scans from multiple wallets without being bothered by the download speed.

However, I still would advise you to really consider the option of a single address as this entire process becomes automated.

Keep yourself informed you still use separated addresses as sub-addresses may be useful for your case once these become a thing.


Can I process incoming transfers from the daemon RPC?

The daemon (monerod) has no wallet functionality, it's for working with the blockchain. To determine incoming transactions for a given wallet (e.g. viewable and spendable using your wallet keys), you would need to scan the blockchain for outputs owned by your wallet and check their spent status.

A full scan (in pseudo code) looks something like follows (ignoring subaddresses):

unspent = [] # array which will hold tuples of (tx, output)
a = hex2bin(v) # my private view key
A = hex2bin(V) # my public view key
b = hex2bin(s) # my private spend key
B = hex2bin(S) # my public spend key

for each block in blockchain:
    for each tx in block:
        R = get_tx_pubkey(tx)
        for each output, i in tx:
            if is_mine(output, R, i) and not is_spent(output, R, i):
                unspent.append((tx, output))

is_mine(out, R, i):
    P = Hs(8aR||i)G + B
    return P == out

is_spent(out, R, i):
    x = Hs(8aR||i) + b
    I = xHp(xG)
    return has_key_image(blockchain, I)

get_tx_pubkey(tx):
    return key from tx.extra

Given the blockchain is hundreds of thousands of blocks each with N transactions, a full scan is pretty intensive.

Also, you cannot perform the above with just the daemon RPC method get_block, because other than the miner tx, get_block will only get you the tx hashes - not the actual tx data. Therefore you'd also need to use get_transactions. And of course, calling these JSON methods repeatedly over the whole blockchain would be very slow.

If you are looking to develop your own wallet implementation, there are the necessary binary methods, which remove the JSON parsing overhead, but really, this is why there is a wallet RPC interface - monero-wallet-rpc. That handles all the lower-level stuff and exposes a useful RPC interface for higher-level wallet functionality.

If you just want to process a single blocks transactions, with only the daemon JSON RPC interface and your wallet keys, you can use get_block (to get each tx hash) and get_transactions (to get the tx pubkey and outputs for each tx). Then you'd need to implement a method like is_mine above to check if you owned a given output and a method like is_spent above to check the spent status (and for has_key_image you could make use of is_key_image_spent).


Why was I2P chosen over Tor for native Monero integration?

There are several advantages where I2P implementation is more suitable over Tor, e.g.

I2P is significantly faster when routing internal traffic, where Tor is optimized for low-bandwidth clients and high-bandwidth exit nodes,
I2P doesn't have floodfill routers hardcoded as Tor's directory of servers,
I2P is a packet-switched network (as opposed to circuit-switched) which makes it more rubust,
I2P supports UDP, Tor not,
in I2P all peers assist in running short-lived tunnels, not only client-only peers as in Tor,
I2P uses API to interact with the network directly, as opposed to SOCKS proxy in Tor,
I2P aims at being its own lower latency network.

Source: Why is Monero aiming to integrate I2P? at reddit


Is there a way to cap the size of the tx_extra_field?

I wouldn't do that. The tx_extra field opens some possibilities for unforseen inventions build on Monero. Monero doesn't have such rich scripting language as Bitcoin, but the tx_extra field offers some other possibilities how to make use of the anonymous blockchain in other ways than simple monetary transactions. It may for example interlink monero transactions (which are private yet very secure) to other distributed p2p data..

The larger the tx_extra, the more fee you pay and you still need to be able to fit your transaction into block.


How will payment metadata be incorporated into the range proof?

Can someone please explain the technical method by which this can be completed successfully?

The range proof requires generating a lot of random values in the process. Nothing would change security-wise if that data was not entirely random and carried some encrypted payload instead.

  What are the advantages of using this method over the current txextra method?

The main one is that you wouldn't be able to tell whether a given TX contains a message nor what its length is. It's like steganography. With the payment ID, it's simple to tell whether or not there's a message. If we wanted to allow arbitrary length of payment ID, you could also tell the length unless we force some padding to nearest 256 bits or whatever.

Another advantage is that we use the bandwidth which has to be used anyway so that message is not inflating TX size. Few kB of covert data could have many useful applications we haven't even thought of yet.

For example, you could make a shop where the act of payment is also an order. You embed your return (monero) address, shipping address, item no., qty, size, color etc... all in the TX. Only the recipient can see this, and send the order. For anyone looking, it's just another TX on the blockchain.

  Are there any disadvantages?

Maybe some, but not really significant, IMO. Sometimes you want the possibility to leave a message on the blochchain out in the open, to be easily read. Maybe it could be achieved with range proofs as well, but then you'd have to reveal some secret info by other means in order for anyone to be able to decrypt the message.

Another disadvantage is that range proofs could be pruned eventually so those messages may not be readily available permanently.

Also, the amount of data you can store is limited, but then again you could chain multiple TX-es. It's not like we're seeing TX-es with 10s of kB in TX-extra, anyway.

In conclusion, with sub-addresses alone, most common payment-ID use-case (telling incoming TX-es apart) could be entirely replaced by sub-addresses with another advantage of support for sending to multiple sub-addresses in the same TX.

Public messaging would remain as an use-case of "legacy" 256-bit payment ID, while stealth payment ID could be replaced by range proof messaging unless you want the message to be kept in the blockcain forever for which you could still use the TX-extra.


Monerod and wallet fully synced, not recognizing transactions made before the fork as valid

Your transaction has an ADDITIONAL_PUBKEYS tag in the tx_extra field. This means it was a transaction with at least two destinations, at least one of which was a subaddress.

These warnings mean that your wallet does not know how to interpret this ADDITIONAL_PUBKEYS tag. Therefore your wallet must be an older wallet version that does not support subaddresses. Please check that you're using the latest GUI wallet.


FreeWallet is a third party, closed source wallet associated with Bytecoin and Minergate where you are not in control of your private keys. Therefore the only way to be able to recover your XMR/account is to keep asking them. However it looks like that they are not replying to you.

The best way to address this is go to the App and submit a review so other people may know. Probably FreeWallet may have to help you.

Sorry, hopefully you'll be able to recover your account and withdraw your XMR to a real monero wallet. In case you've recovered your account you can create  a wallet here https://moneroaddress.org/ and transfer your XMRs.


What are the main advantages / disadvantages between proposed RandomX to ProgPoW?

What are the main differences between ProgPOW and RandomX?

The design goal of ProgPoW is to have the algorithm’s requirements match what is available on commodity GPUs, while RandomX is inefficient (as stated on https://github.com/tevador/RandomX) on GPUs.

  can some parts of it also benefit Monero's development in a longer-term ASIC resistant mining algorithm?

Monero's developers are constantly following the evolution of the other opensource mining algorithms (as for example https://github.com/monero-project/monero/issues/3545) and if something can help the mining algorithm of Monero, it will be implemented in a safe and secure way.


Does Monero have any connection to the Esperanto community other than its name?

There is no official relationship. The Monero name was inherited from the original developer who never revealed any connection to the Esperanto community other than providing the definition:

  Bitmonero = bit + monero
  monero = mono (money) + ero (bit) = coin (esperanto language)

There are some unnoficial connections such as an Esperantist named Kaja accepting Monero for Esperanto lessons and an attempt from longtime Monero user dnale0r to encourage more Monero users to begin learning the language


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

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

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


Is it possible to use light wallets / remote nodes with Kovri?

The goal as outlined by Mr. Fluffy is to use I2P to broadcast transactions and provide Monero services.

By default, Monero nodes would still connect as they do now for communicating new blocks and transactions. Wallets would not broadcast transactions through the local node, and instead would broadcast through I2P in an attempt to hide the IP that initiated the transaction. Devices such as phones would connect to a specific I2P router of the users selection to get latest account balances or to broadcast transactions.

Basically Monero nodes will be offering monerod RPC services over I2P. The advantage is that user does not have to configure dynamic DNS or accept inbound connections for this to work (although the latter would be helpful for the network as a whole). The phone (or other device) simply needs the I2P address - which is used for routing, encryption, and authentication. This way a user only needs to run a single node (which would have the highest amount of trust), and can have multiple devices connect to it easily with minimal setup. A user could also provide this service to less technical people fairly easily - only an I2P address needs to be exchanged. Presumably this Monero service would require client authentication for some RPC requests, to limit resource usage.

Or that is how I understand the intended goals.


What is the best Python library for hashing Cryptonight?

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


In the Monero Wallet GUI I see an reception address in the first line. Is this my unique address?

Correct. This is your unique "plain" address. Note that you can also find your plain address in <wallet-name>.address.txt, which is stored in the directory of your wallet files (Documents\Monero for Windows | ~/Monero for Mac OS X and Linux).

  And what means the integrated address?

An integrated address is a plain address with the short, encrypted payment ID embedded. Merchants and services (e.g. exchanges) give each user a unique integrated address, such that they are able to distinguish between incoming transactions (in case of exchanges) or payments (in case of merchants). Note that plain addresses are 95 characters, whereas integrated addresses are 106 characters. More information about integrated addresses can be found here:

What is an integrated address?

https://monero.stackexchange.com/questions/tagged/integrated-address


In which order does a node select peers to create a connection?


How to transfer synced blockchain along with another OS on a USB

I assume you will use the environment based on Debian or Fedora. In that case, you can copy the current .bitmonero to the equivalent location on Qubes.
When you re-run bitmonerod, it will continue as it would have on your Lunbuntu system.

There is no need for a specific verification of the chain since you trust the provide of the file (yourself).


View key, spend key, paper key, seed... Is there a short presentation of vocabulary around Monero wallet?

Wallet Seed / Mnemonic

Minimum piece of information used to restore the cryptographic keys that make up the wallet. Basically, just a very very big number impossible to guess. I'd like to separate the mnemonic and seed terms:

seed: a 256bit integer (usually represented as a 64 digit base16 number)
mnemonic: in this context, a word representation of the seed, with one extra word used as a checksum.
Both represent the same thing, but the mnemonic is a human readable form of it.

Convention currently in use consists of encoding the seed using a 1626 words dictionary which results in a 24-word mnemonic. A CRC32 checksum is performed on them to give the 25th word which is used for error checking.

The seed itself, if smaller than a certain number, is used directly as the private spend key. Otherwise a seed mod l operation is performed to obtain the private key from the seed, where l is a very big number, specific to the elliptic curve used in Monero cryptography.

The private view key is derived deterministically from the private spend key (it doesn't have to be) and that is why we call such wallets deterministic.

Private Key / Public Key / Keypair

General terms specific to public-key cryptography where a private key and a public key make up a keypair. A public key is derived from the private key.

The public key is safe to share, and gives the recipient the ability to encrypt something or verify a signature.
The private key gives the owner the ability to sign or decrypts something, so should be kept private. It's important that private keys are generated in a good way as they shouldn't be easy to guess.

View Key

A keypair specific to Monero. The public part of it makes up the 2nd half of monero address, and is used by the sender to generate a one-time stealth address to where the funds are actually sent. The owner of the wallet uses the private view key to scan the blockchain and find the funds sent to his address. At the protocol level, the sender performs an encryption with the recipient's public view key, and the recipient attempts to decrypt all the outputs on the blockchain to find the one belonging to him (where decryption was successful). For audit purposes, it could be shared with the auditor, along with the signed key images to prove the balance of a wallet. Sharing only the view key would enable the auditor only to see received transactions, but he wouldn't be able to tell if any funds were spent, so he couldn't know the actual balance.

Spend Key

A keypair specific to Monero. The public part of it makes up the 1st half of monero address, and is used to make new transactions and participate in ring signatures. The private spend key is used to sign a key image when the owner wants to spend funds, and the public spend key is used by the network to verify the signature of the key image and accept the transaction as valid. This is what prevents double-spend as the network enforces the rule that a key image can be spent only once. I'd like to expand this a bit, but I'm a bit lacking here, so can't right now.

Address / stealth address

A minimum piece of information compacted to a single 95-character base58 string which the recipient needs to give to the sender in order to receive monero. The information encoded in the address is the network byte, public spend key, public view key and a checksum. The bare minimum which the sender needs are the 2 public keys, but the network byte and the checksum are added to prevent errors.

Any Monero address is a stealth address. They're called stealth addresses because no monero are actually sent to the address itself, ie it never appears on the blockchain. Instead, it's used by the sender to create a one-time destination from which only the intended recipient can spend.

One-time public key

An one-time use destination for the actual monero transferred. Monero addresses are never found on the Monero blockchain, but these one-time destinations are. They  take care of obfuscating the destination as they all look the same but only the owner of a private view key can know that it belongs to him. They're generated by the sender and used by the recipient to find his funds.

From Moneropedia:

  Every transaction involves two keys: a public spend-key, and a public
  view-key. The destination for an output in a transaction is actually a
  one-time public key computed from these two keys.

  When the wallet is scanning for incoming transactions, every
  transaction is actually scanned to see if it is for "you". This only
  requires your private view key and your public spend key, and this
  check is immutable and cannot be faked. You cannot receive
  transactions and identify them without the corresponding private view
  key.

  In order to spend the funds you have to compute a one-time private
  spend key for that output.

View-only Wallet

A wallet created by only using the private view key and the address. It enables the user only to monitor the blockchain for any incoming transfers. Practical use could be for increased security of the user or for audit purposes, if given to an auditor.

Audit Wallet

A view-only wallet to which the signed key images has been imported. One key image is needed for every output. Considering that the list of outputs can be seen with only the view key, it's easy to tell if some key images were witheld. With key images imported, such wallet would show the actual balance. If some new funds were to be received, the auditor would then have to ask the owner to send him the signed key image for this new output in order to be able to verify the actual balance again.

Hot Wallet

A Monero wallet which was exposed to a device with network access.

Light Wallet

A Monero wallet where the user doesn't store the Monero blockchain or runs a full node. The full node part and the wallet part of Monero software have been separated from the start. As such, the Monero CLI wallet is already a light wallet but it usually communicates with the local node run on the same computer as the wallet software. It could be connected to a remote node, and in that use-case it would become a light wallet. There are some nodes publicly available for this purpose, even on the Tor network.

There's another model which could be used for an even lighter wallet, but with some sacrifice of privacy. In this model, the server would store the user's private view key so it could keep updating the wallet while the user is offline. When the user would connect to the server, the client-side software would get a list of received outputs for which it would generate signed key images and send them to the server. The server would then tell to client software the exact balance. For spending, the server would prepare a transaction, send it to the client which would locally sign it with the private spend key and send it back to the server which would broadcast it to the network. In principle, it is as secure as the normal hot wallet, because all the spend key cryptography is performed on the client side.

There is a working implementation of this, but it is web based (javasrcipt) where the client-side is run by the browser. A stand-alone software would be significantly more secure as it would avoid certain vulnerabilities.

Cold Storage

A Monero wallet generated completely offline and never exposed to a device connected to a network. It could be a file store on an USB, could be just the mnemonic written on a piece of paper. What makes it cold, is the fact that it has and will always remain isolated from network.

Payment ID

A feature developed to make it easier for the sender to prove to the recipient that he sent him the funds. Due to Monero privacy features, the recipient can't tell from where the funds came. However, if there's a payment ID attached to it, it would give him a clue. Payment IDs should be randomly generated for each transaction to avoid linking transactions.

It works like this:
1. Recipient gives the sender his address and an unique payment ID
2. Sender sends the Monero with payment ID specified
3. Recipient sees an incoming transaction with the payment ID specified, and he can know that it came from that specific user because only that user could have known the payment ID.

Integrated Address

Similar use as payment ID. The difference is that both the address and the payment ID are encoded in a single string, which avoids mistakes and prevents accidents where the sender could forget to specify payment ID. Also, the payment ID in this scheme is encrypted with the transaction shared secret, so the privacy is improved as well. Due to this scheme, even when using the same payment ID and sending to the same address, the encrypted payment ID will appear as something entirely random on the blockchain. This is desired as it breaks linkability which occurs when using plain-text payment IDs.


Bunch of errors when running monerod. ERROR cn src/cryptonote_core

This is a secondary error which happens after a DB error. The DB may or may not be corrupted. The recovery steps, in increasing order of violence:

restart monerod
restart monerod adding --db-salvage
remove the ~/.bitmonero/lmdb directory


Setting up monero blockchain explorer on unbuntu 16.04

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

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

The second solution is probably easier:

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


Is it possible to see the number of confirmations and source address using Monero wallet CLI?

If show_transaction does not show the number of confirmations, nothing else does. It should be pretty easy to add. Same thing for source.


How hard is it to create a monero wallet site?

It would be moderately easy to get a working wallet site provided you know some basic programming (python, php, node.js) and a little about web server usage (linux!).

You just need to run a full node on your server, create a wallet, then write some code which checks for payments, makes payments etc. See wallet-RPC for some guidance on this.

As already mentioned, the challenge here would be to implement these things securely/reliably. Making something like this for public use is not recommended unless you know exactly what you are doing. Just imagine if all your users monero was stolen or lost - you'll certainly end up in hot water.

You're right though that there is a lot of opportunity in this space. I encourage you to at least experiment with your idea (i.e get a full node working on your server and programmatically check your balance). Its the best way to learn and from there you'll have a better feeling of what you can do with this technology.


Monero cli show_transfers transactions for only a specific subaddress

How do I view only these transactions that were sent to this subaddress?

[wallet]: help incoming_transfers
Command usage:
  incoming_transfers [available|unavailable] [verbose] [uses] [index=<N1>[,<N2>[,...]]]

Command description:
  Show the incoming transfers, all or filtered by availability and address index.

  Output format:
  Amount, Spent("T"|"F"), "frozen"|"locked"|"unlocked", RingCT, Global Index, Transaction Hash, Address Index, [Public Key, Key Image]

Example:

incoming_transfers index=1

Shows all incoming transfers to subaddress index 1.


Would It Be Technically Possible To Delete Old Blocks From A Blockchain?

You've formed an opinion and make a lot of statements based on inaccurate information.

"to store a copy of the entire blockchain" – Miners do not need to have a copy of the blockchain. They only need to have access to the network. This is because miners don't need to verify transactions, that's the job of the network (everyone who runs a node). A miners job is to propose new blocks.
"Private blockchains like Monero can't be pruned" – Yes they can and Monero has this exact feature.
"So it would just grow forever until mining becomes centralized in a few data centers" – You make the common mistake of ignoring the advances in storage capacity and decreasing cost.

Therefore the question of whether it's possible to delete old blocks becomes a moot point.


Replacing an older version monero-wallet-gui.app with a newer version

The version, if I recall correctly, is in the Settings tab and shows both GUI and daemon versions.

And yes, if you didn't change the default blockchain location, upgrades will still find the previously downloaded blockchain.


xmrig.exe is not recognized as a internal or external command, operable program or batch file

You can add at the beginning of the batch the following line:
cd /d "%~dp0"

This will change directory from the current one ("C:\Windows\System32") to the one the batch file is


Mining pools overseas and the impact on the hashrate

I'm not sure what miner you are using, but if you're using XMR-Stak, one of the better ones at the moment, you can click 'r' to get a report on your submitted work. If you have a low acceptance rate, you are losing your work.

Here's an example from one of my own workers that runs through an SSH tunnel (which adds latency).

RESULT REPORT
Difficulty       : 18000
Good results     : 9233 / 9284 (99.5 %)
Avg result time  : 105.2 sec
Pool-side hashes : 45846000

Top 10 best results found:
|  0 |         62213495 |  1 |         54395912 |
|  2 |         28981579 |  3 |         28899680 |
|  4 |         28802304 |  5 |         26687670 |
|  6 |         23322195 |  7 |         16208637 |
|  8 |         15118120 |  9 |         13861144 |

Error details:
| Count | Error text                       | Last seen           |
|     9 | Low difficulty share             | 2017-06-19 15:55:14 |
|    11 | [NETWORK ERROR]                  | 2017-06-18 15:01:07 |
|    31 | Block expired                    | 2017-06-21 07:07:45 |

As you can see, my "good rate" is 99.5%. This is on a slow CPU which also does a lot of other work and often has CPU power taken away for other tasks.

I've noticed that the hashrate reported by the pools vary a fair bit, so I'm not sure they can be trusted. I calculate my own hashrate by polling the pool API and averaging over 1 hour. I can then compare that to the sum of rates reported by each worker. ('h' key in XMR-Stak.)


What is block propogation in Monero network?

In a cryptocurrency network (like Monero and Bitcoin), miners are finding solutions to blocks. When a solution is found, the miner has created a block and this new block can now become the tip of the blockchain (the newest block).

In order for this block to become the tip of the blockchain, the block has to get to every node in the network - the block has to propagate. This occurs through the peer to peer network. The miner creates the block, and sends it to the peers it is connected to. These peers validate the block, and then relay it to their peers.

This is block propagation.


Whatever the difficulty, you have the same expected return in the long run, so it does not matter. If you use a difficulty that's twice as high, you'll find half as many shares. A higher difficulty will just increase the variance. Some people say "but it can mean this miner never finds a share so it's wasted", but that's hindsight bullshit since they won't complain when the worker gets lucky and finds way more than its expected share.

If it's your own pool, shares don't matter anyway. Whether or not a miner gets a share, you only get some monero if its difficulty is at least the current target, so any share with less difficulty is pointless.


Is there any obfuscation in the communications between nodes?

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

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

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


How do I enable incoming connections? (ELI5)

You should not have anything to do to allow outgoing connections, unless you're in a restrictive environment - in which case the steps to allow this are independent of Monero.

If you meant incoming connections, then you need to setup your router to allow port 18080, and forward it to the machine running monerod.

If you run "status" in monerod, you will see a "X+Y" counter pair at the end of the line: X represents the number of outgoing connections, and Y represents the number of incoming connections.

Port 18081 is for RPC connections, and you generally want to keep it local.

If you're getting any errors, posting them will help determine what issue you're facing.


How to set up password on xmrpool.net mining pool?

Username - your wallet id

Password - workerId:your@email

You should specify above as parameters or configuration of your miner. If you have done everything correctly, your online account will be created automatically. To login there, use wallet is as username and your@email as a password.


What benefits are there of using an ARM device like Raspberry Pi?

Raspberry Pi is good for testing the minimum resource requirements needed to run Monero. As long as Monero continues to work on ARM devices like the Raspberry Pi then scaling concerns related to hardware requirements will not be a problem for most people.

It also is extremely inexpensive in terms energy consumption, with a Raspberry Pi and other ARM systems able to operate as a full node with only 1 or 2 watts of electricity.

Security benefits of using a Raspberry Pi result from it being isolated from other irrelevant (to Monero) programs installed on every modern PC. Such an isolation model is ideal for creating offline wallets for cold storage.


Why are there so many different amounts received when receiving a payment?

When sending a payment, the amounts are split by denominations, such that every single output's decimal representation is made up of a single non zero digit, and zeroes for the remainder.

For instance, 875.4 would be split into 800, 70, 5, and 0.4. If you're sending, or receiving, 875.4, the protocol will be sending these 4 different outputs. The intent is to make it easier to find other outputs of the same amount on the blockchain, so they can be mixed (this will become moot when RingCT transactions are used).

Mixin has essentially no relevance for this (on the output splitting side).


Forum Funding System donations earmarked for projects that are never completed

Monero related projects that are not finished or do not hit certain milestones will have the donated XMR/BTC/USD used for other Monero related projects.
Donations are non-refundable and go into a development pool to be used on Monero projects. (This also answers what happens to donations if they are made by anonymous donors).
As for multisig and the forum funding system, the Monero core team hasn't explored the topic yet and will wait until multisig is available to use before they think of applying it to the forum funding system.


Step by step guide on how to connect to peers

It's tough to write a step by step guide for port forwarding, because port forwarding is something your router does, and people have different routers.

If your router has UPnP, that would be the easiest.  Many people will argue that it's safer for UPnP to be off, which is correct; but you can enable it long enough for it to allow the daemon to punch a hole through the firewall (a non-technical term for port forwarding), and then turn it back off.  The port forwarding would have been performed automatically in that case.

But anyway, just look at your router's instructions for port forwarding.  Nearly all modern routers allow port forwarding, and it is not complicated.

Your other questions can either be asked in separate questions, or they may actually have already been asked and answered, so please search a bit.