Could (merge) mining provide a vector for deanonymization?

When merge mining all you're doing is re-using your PoW calculation on different blockchains that share PoW algorithms.

Merge mining is therefore equivalent to, but more efficient than, running two or more miners in parallel against a mining pool supporting multiple currencies.

Since one blockchain doesn't know anything about the other (remember, you're only submitting PoW solutions) the XMR payouts cannot be tracked (by the properties of XMR) as they're moved around.

The XDN on the other hand, can be tracked, unless you take steps to hide your trail.

In conclusion, it's only slightly worse than if you were to only mine XDN, because the pool operator would also know your XMR address.

If you've re-used that XMR address, e.g. in your forum signature to solicit donations, they could watch the XDN blockchain and know what that forum user is up to.


Why didn't Monero developers just improve bitcoin?

Please be aware that I have had no involvement in creating Monero (or knowledge of the rationale behind it), so the following should be regarded as speculation.

On a general note: there is no reason that there should be only one cryptocoin, on the contrary there are use cases for different coins. Bitcoin might not be particularly useful for e.g. the banking infrastructure, where Ripple might be. Ethereum focuses on smart contracts and other coins might try to address the initial distribution or may only exist to get some infrastructure built. Many different technologies and goals and there will be a lasting need for at least some "altcoins".

Monero offers improved anonymity/fungibility (among other differences) with respect to Bitcoin. There might be good reasons to have a separate coin rather than to try and push this technology to Bitcoin:

It may not even be seen as an improvement to Bitcoin. Who says that Bitcoin's limited anonymity may not prove to be an asset as it could allow for monitoring. Some people like it that way.
Creating Monero allows for a testing ground for new technology. As it matures and the wrinkles get ironed out, the technology will be more suitable for adaption by other coins. Why risk breaking Bitcoin?
Bitcoin does not seem to be very conductive to change. Changing into Monero tech would be a massive change (if at all possible) and it is very unlikely that the community would want it.
Other perceived shortcomings of Bitcoin are fixed along the way as well. Such as dynamic block size, no inflation and the substantial pre-mine.
It allows to build a separate and more healthy community around the new coin. Something that I think has worked out pretty well with Monero.

I am sure that others can expand on my answer. I have really tried to be light on technology, partly because of my limited knowledge, but it might also serve non-savvy readers better.

In conclusion: a different coin or technology is not necessarily hostile towards the Bitcoin project, although it may be perceived as such by a part of the community. It may expand cryptocoins into other domains or even serve to improve the Bitcoin project itself. There is still nothing stopping Bitcoin from adopting improved technologies and ideas.


It is known that Poloniex switched to non zero mixin for a short time for withdrawals. However, they reverted to zero not long after, and I believe this to be due to the increased fees. Unfortunately, exchanges have to deal with people sending very small amounts of every coin, as they mine directly to the exchange address, or if they don't, they send everything as soon as they've got any, for selling as soon as possible. This means that Poloniex ends up with a lot of small outputs. When people withdraw larger amounts (or maybe even not so large ones), Poloniex has to find a lot of outputs to build that withdrawed amount, making them all the more vulnerable to high transaction fees when using non zero mixin.


How much time does it take to transfer monero?

how long does a typical transfer take to be recognized as part of the total balance of the receiving wallet?

It varies, but in general it will take less than 5 minutes. Once the receiving wallet scans and identifies the transfer as belonging to the receiving wallet, it will be included in the total balance. A cautious user of any cryptocurrency, however, will wait for additional blocks to be found after the transfer. This ensures that the funds are secured in the receivers wallet.

  Does the mixin # influence the transfer time?

Generally, no. The mixin does increase the size of the transfer, so it is possible for very large mixins to be delayed on the network due to either propagation of the transaction data itself, or that the transaction is so large that a miner doesn't want to include it in a block due to block size penalties.

  Does the amount of monero being transferred affect the speed?

Generally, no. However, if you are creating a transaction that uses a lot of outputs, then the transaction will be large and the same thing described above


code=-28, message=This wallet is already multisig

You're apparently trying to switch a multisig wallet to multisig. Which it already is. That's what it's telling you. Start with a non multisig wallet to make it multisig. You have nothing to do turn a multisig wallet multisig, since it already is.


After downloading the blockchain from scratch overnight, the daemon stalls with 118,508 blocks. What can I do to resolve this?

Ring CT started up somewhere around that block.  If you do not have the latest Monero version, you will never synch up with the network.  You have to keep up with the latest software versions.  Also, the last remaining blocks are much slower than the others because of Ring CT.

An SSD speeds things up 4 to 5 times faster in comparison to an HDD.  If you don't have one, get one.  They're cheap.


Payment received with old wallet not shown in new one

You might be using a payment id with your address which could be why you might not see the same address. To verify you can tell if the address is an integrated payment id, by see if the address looks similar. If it is, then you have it in your wallet. Also make sure you have your wallet fully synced too.


Help me setup a good mining rig on my high end gaming computer

Its really not that hard.

Create your wallet (GUI works well)

install:
XMR-Stak

XMR-Stak seems to work well (one unified version for CPU & GPUS:AMD/NVidia).  I did build it for linux, but there are prebuilt versions.
Then fire it up, answer questions (no to nicehash, and probably no to multiple pools) and point to to a pool (monerohash.com, xmrsupport.com, etc. Avoid minergate at ALL costs)
You can tweak settings in the .config file. (if Windows use notepad, NOT wordpad, word to edit the config.  ultra basic text file, no formatting codes)  Most pool sites have guides.
Basically you point it at an address and port.  Some want a user:password, typically just an email address.

While your mining your XRM, run monerod to fully sync your node.  It will be sync'd before you get a payout from a pool.  (wallet won't show balance until fully sync'd)

But to give you some insight:  I'm running a I7 (some version) 32GB and 3 GTX 1070's (8GB) and getting about .08 XMR a day.
(But I built the rig for password hashes not mining)


Why/how does monero generate public ed25519 keys without using the standard public key generation provided by ed25519 libraries?

Monero doesn't use EdDSA, which all of those libraries are specifically set up for. We don't use SHA512 at all, but rather Keccak (~SHA3). We don't use secret keys as seeds like EdDSA does, but rather as scalars. If you look at ed25519.py on L63, you can see what I'm talking about.

Change the function to look like this:

def publickey(sk):
  a = decodeint(sk)
  A = scalarmult(B,a)
  return encodepoint(A)

Now you'll get the correct result: 0f3b913371411b27e646b537e888f685bf929ea7aab93c950ed84433f064480d. I use binascii.hexlify to get the output converted to hex (and also unhexlify to use the secret key as input to publickey(sk)).


What is the best way to pop the top block from the monero blockchain and fix a bad "unknown top block" error in the sync data process?

While getting a bad block on top should not be possible in the first place, it could happen in case of crashes, etc, on some systems.

Popping one or more blocks can be done with blockchain_import, eg: blockchain_import --pop-blocks 1 will pop the last block. However, if the blockchain got corrupted somehow, this might not work.

Last, note that the message you are quoting here does not indicate any sort of corruption. It just tells you that a peer has a top block you don't know about (and thus may either be on a different fork than you, or synced further then you). In this particular case, you seem to be catching up with the network. From your wording, it appears you're constantly getting this message as well as not progressing, but the message itself is expected. set_log 1 in the daemon will tell you more about what the syncing problem is, if popping the last few blocks does not fix things for you.


How do I set transaction priority with the JSON RPC wallet?

The transfer_split RPC indeed has a priority field, which may be set to 0-4, as you suspected. 0 stands for default (which is 2 currently, but will use the default you set via simplewallet if any), and 1-4 for their respective priorities (unimportant, normal, medium, highest).

The documentation does indeed need updating, this is one of these neverending tasks that often get behind.


Yes, any mining rewards will go to the wallet from which you executed the start_mining command.


Has the testnet been reset with a new genesis block?

There was no new genesis block. However, there was a massive (about two months, I think) reorg when the ringct implementation switched from ASNL to Borromean signatures for the range proofs.


How does a user pay a monero node operator via the RPC pay feature?

The latest monero update gave users the ability to pay...

Actually this feature was released in v0.15, not the latest release.

  How does...

Instead of me copying verbatim the commit message or each related flag/command, here is the direct link to the commit for which the commit message thoroughly documents the feature: github.com/monero-project/monero/commit/289937...


The sort is to be done on key images. See src/cryptonote_core/cryptonote_tx_utils.cpp from line 321 on current master.

Are those rejected transactions created by monero-wallet-cli or monero-wallet-gui ? If so, please file a bug on github.


What is the fee cost of a Loki blink instant transaction and does this fee get burned?

The loki blink transactions are 5x the fee minimum fee of 0.04 which equals to 0.2 loki fee to do a blink transaction. 4/5 of that fee is burned and the 1/5 is paid out to miners.

  The base fee is slightly higher than 0.04; it's 0.04 plus a small
  per-byte amount.  The cli wallet has a "fee" command that can spit out
  the details along with a typical tx estimate:

  Current fee is 0.000000192 loki per byte + 0.020000000 loki per output
  Current blink fee is 0.000000960 loki per byte + 0.100000000 loki per
  output Estimated typical small transaction fees: 0.040480000
  (unimportant), 0.202400000 (normal), 1.012000000 (elevated),
  5.060000000 (priority), 0.202400000 (blink)

Eventually blink transactions will be on by default making every transaction on the loki network instant.


Is there a pool that will tell you the real time shares you've submitted?

most pools have a "lookup" where you can put in your wallet address and it will show you how many shares you've submitted (after your first share is found usually)

most pools i've seen will show this information even if you haven't reached payout


Can't create transaction: failed to get random outputs to mix: failed to get random outs

First, you're using too old a version, and won't be able to sync past where you are now.

Next, the reason for this message is that you're sending a lot of outputs, and nodes exposed to the public have an artificial limit to the number of outputs they will serve, as a crude defense against DoS. This limit is set to increase in next release.

So the solution is to send smaller amounts at a time, so the tx needs less outputs to meet the requested amount. You probably have lots of small outputs, likely from mining. You can think of it as having $100 in one cent coins. You have the money, but it takes work/time to use.


Calculating the cost of a double spending attack

It depends heavily on how much work has to be (provably) redone. If you act upon a transaction that has just hit the txpool, there is not work yet to be redone by a miner, so it's cheap. Same as for bitcoin. This assumes that the attacker is able to send a tx to your pool, while sending a different tx spending at least an identical input to mining pools. As monero and bitcoin use the same PoW system, attacks against either are the same.

Now, with your particular example, you probably have a way to determine who cheated, so you can either ban them from your toll gate in the future, or force them to use a queue where payments wait for one confirmation, which should in itself be a good incentive not to cheat :)


Pools do not know your hash rate, they can only estimate it based on the shares you submit. Since finding those shares is in inherently random process, you will sometimes have lucky breaks, and sometimes long dry spells. This will translate to a randomly changing hash rate being reported by the pool. Your miner knows the rate at which it is hashing, so reports the actual rate.


Where is the best place to propose ideas for Monero

#monero on Freenode IRC is probably the best sounding place. Or #monero-dev on Freenode if this is about monero development itself. #monero-research-lab for ideas to do with the theory or R&D.

Note that many people have a funny view of what's about monero development. They think if it involves them using a compiler (or sometimes just involves them), it's about development. That's not correct. If in doubt, try #monero. You'll be redirected if needed.


Generate an integrated address using javascript in the browser?

You can generate an integrated address if you just have the monero public address. See here: https://dustinlemos.com/integrated-address-demo/

Source from that site:

    <title>Integrated Address Demo</title>
      <meta charset="utf-8">

Integrated Address Demo

      <input id='input-address' type="text" style="padding: 5px; width: 700px;" placeholder="Enter a standard (netbyte 12) XMR Address" />

    <button id='generate'>Generate Integrated Address</button>

      Address:

      Payment ID:

      Integrated address:

addresses.js file:

//This file was created using code from luigi1111's address tools
//located at https://xmr.llcoins.net/
//see copyright below

//functions for various XMR/Cryptonote stuff
//(c) 2016 luigi1111
//can't imagine this is useful for anything but this site, but
//Licensed under the MIT license:
//http://www.opensource.org/licenses/MIT

//requires cn_util.js, mnemonic.js, sha3.js, and their requirements

generateIntegratedAddress = function (walletAddress) {
    var addr58 = walletAddress;
    var pubSpend2 = {};
    var pubView2 = {};
    var pubAddrHex = {};
    var pubAddrChksum = {};
    var pubAddrForHash = {};
    var pubAddrHash = {};
    var pubAddrChksum2 = {};
    var xmrAddr = {};

  if (addr58.length !== 95 && addr58.length !== 97 && addr58.length !== 51 && addr58.length !== 106){
    throw "Invalid Address Length!";
  }
  //Get the netbyte
  var addrHex = cnBase58.decode(addr58);
  if (addrHex.length === 140){
    var netbyte = addrHex.slice(0,4);
  } else {
    var netbyte = addrHex.slice(0,2);
  }
  //viewkey + pID stuff
  if (netbyte === "13"){
    throw "Invalid Address (netbyte 13): you must use a standard XMR address (netbyte 12)";
  }
  if (netbyte === "11"){
    throw "Invalid Address (netbyte 11): please use a standard XMR address (netbyte 12)";
  } else if (addrHex.length === 140){
    pubView2.value = addrHex.slice(68,132);
  } else {
    pubView2.value = addrHex.slice(66,130);
  }
  if ((netbyte !== "11" && netbyte !== "13") && addrHex.length !== 138 && addrHex.length !== 140){
    throw "Invalid Address Length!";
  }
  var addrHash = cn_fast_hash(addrHex.slice(0,-8));
  pubAddrHex.value = addrHex;
  if (addrHex.length === 140){
    pubSpend2.value = addrHex.slice(4,68);
  } else {
    pubSpend2.value = addrHex.slice(2,66);
  }
  pubAddrChksum.value = addrHex.slice(-8);
  pubAddrForHash.value = addrHex.slice(0,-8);
  pubAddrHash.value = addrHash;
  pubAddrChksum2.value = addrHash.slice(0,8);

  if (addrHex.slice(-8) != addrHash.slice(0,8)) {
    throw "checksum invalid!"
  }
  // *** Generate random payment ID
  var pID = rand_32().slice(0,16);
  xmrAddr.value = toPublicAddr("13", pubSpend2.value, pubView2.value, pID);
  return {
    // "publicViewKey": pubView2.value,
    // "publicSpendKey": pubSpend2.value,
    "integratedAddress": xmrAddr.value,
    "paymentId": pID
  }
};

function toPublicAddr(netbyte, pubsk, pubvk, pid){
  if (pubvk === undefined){pubk = "";}
  if (pid === undefined){pid = "";}
  if ((netbyte !== "13" && pid !== "") || (netbyte === "13" && pid === "")){throw "pid or no pid with wrong address type";}
  if (netbyte === "11"){pubvk = "";}
  var preAddr = netbyte + pubsk + pubvk + pid;
  var hash = cn_fast_hash(preAddr);
  var addrHex = preAddr + hash.slice(0,8);
  return cnBase58.encode(addrHex);
}


How to prevent stack smashing on ccminer

It turns out that I was accidentally using the ancient and unmaintained tsiv branch of ccminer. When I had tried to install the KlausT version, it didn't overwrite this old version.

To solve this, I ran sudo rm /usr/bin/local/ccminer and re-cloned the KlausT branch of ccminer.


Function ge_fromfe_frombytes_vartime() step by step explanation?

ge_fromfe_frombytes_vartime takes as input a field element (as a string of bytes) and outputs a point (a group element), on the ed25519 curve. The precise implementation is detailed in Shen Noether's paper on the subject.

As @knaccc commented above, a better example for porting the implementation is probably Mininero's implementation of hashToPointCN.


Silicon Valley Monero meetup just announced:

https://www.reddit.com/r/Monero/comments/5h9zo0/silicon_valley_monero_meetup/


Easy way to see my balance without having wallet synced

If you have tx hashes/id of tx that you expect (i.e., incoming txs) then you can check using this tool: http://xmr.llcoins.net/checktx.html
or this blockchain explorer: http://explore.moneroworld.com/

Just use your address and viewkey. No need to sync entire blockchain.


Is it possible to set the GUI to run over Torsocks?

There is no way to directly configure Torsocks in the GUI at the time of writing. However, you can run monerod and connect the GUI to your local daemon.

Set the daemon to connect to Tor. Use the guide here.


CPU does not have AES-NI, which is required

You can't efficiently mine using a chip that doesn't support AES-NI.

Verify that the current CPU has the AES instruction set using the following command:

grep -m1 -o aes /proc/cpuinfo

If it supports AES-NI, your output will be "aes" . If it doesn't output anything, you can't mine on your Raspberry Pi using cpuminer.


Mining aeon but the balance is still zero

From the output you gave, you seem to be mining just fine.

Your wallet balance will increase when you find a block. Blocks are found randomly, but a probability which depends on the network hash rate and your own. Roughly, you can expect to find 100 * 312 / 3000000 = 0.01% [1] of Aeon blocks. As there are 360 Aeon blocks in a day, you will find a block every 26 days on average. Note the on average, as variance can be large for small hash rate compared to the network hash rate.

Once you found a block (the daemon will point it out), you will have to refresh your wallet so it sees the incoming aeon.

[1] 312 H/s is your hash rate, and 3000000 H/s is the current network hash rate. At the time of your post, the network hash rate was closer to 1000000 H/s (see http://chainradar.com/aeon/chart), which would make the answer closer to a block every 9 days on average.


Security concerning private keys on monerowallet rpc on hosted server if taking monero payments

The secret view key allows one to see outputs going to the address corresponding to that key. It does not allow spending them. If that secret view key is on a machine, whoever has physical access to that machine can ultimately extract it, if they care enough. Whoever has control over a hypervisor where a VM which contains this key runs can also do, even if they do not have control over the actual hardware. From the above, anyone who has extracted your secret view key can therefore see incoming monero (and usually see when you spend too, since you usually get change back, which is seen by the view key).

The reason is is recommended to run the wallet on the same host is because you can have the wallet listen to the loopback interface (lo), which means it does not listen to anything coming from the outside NIC. Only local connections will succeed. You can however run the wallet server on a machine you control, and enforce SSL usage as well as whitelist the SSL certificate to use. Of course, this does not help as much as you might think since the certificate will be extractable by the hardware/VM provider in the same way they could get the view key previously, and they can make requests to your wallet server as if it was coming from whatever website client you use. You do get an auditable trace of the request, however, so it is objectively better in that respect.


Monero RAM requirements compared with Zcash

Monero originally required a lot of RAM, because it stored the blockchain in RAM. Currently, Monero uses LMDB to store its blockchain. As a result, people are able to set up Monero nodes with only 512MB of RAM. When running, bitmonerod (the daemon) uses less than 100 MB of RAM.  For Zerocash the requirement will be much higher for nodes that generate spend (aka "pour") transactions:

  Zooko also added that privacy-preserving spend generation likely requires more than 4 gigabytes of RAM, although he also mentioned that they don’t have precise measurements on RAM requirements quite yet.

In your 8GB RAM example a RingCT Monero transaction would be generated nearly instantly, while a Zcash transaction would take minutes according to Zooko, Zcash founder & CEO

  “The current alpha code that we have running on a testnet ‒ it takes like about a minute or two of CPU time to generate a new privacy-preserving spend and only like a few milliseconds, I think, to verify. The latter part is for the good for performance, and that’s really important because all the full nodes and the miners have to be doing verifications all the time. The former part is pretty bad because it takes a whole minute or two on like a high-powered, supercomputer 64-bit laptop CPU.”

Lastly, it should be noted that the integration of RingCT will not result in additional RAM requirements.


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


Who Generates parameters G & H for Pedersen commitment in Monero?

G is a universally agreed-upon base point. Almost everyone that uses ed25519, including Monero, uses the same G.

H is an agreed-upon base point within Monero's implementation of the Pedersen commitment scheme. It is chosen arbitrarily such that it is impossible to know the discrete log with respect to G (i.e. there is some x such that xG == H, but x will never be known).

The security of Pedersen commitments relies on x being unknowable.

Bottom line: All Monero wallets and daemons use the same values of G and H.


Do all blocks that end up in the main chain pass through handle_block_to_main_chain at some point?


Stealth addresses: where do they come from?

"Stealth Address" is really just a fancy name for a neat use of Elliptic Curve Diffie-Hellman key exchange. Its use in Monero is described here in detail, but not under that name. This allows for the sender to effectively salt the output and privately communicate the salt to the recipient. I have no idea who and when coined the term "stealth address" to describe it.

As for cryptanalysis, it's all using existing well-known primitives and should be trivial. There's a nice presentation from UCL going through various set-ups, and looking at the site of origin, I also discovered that a nice paper has been published recently.

Courtois N. and Mercer R. (2017). Stealth Address and Key Management Techniques in Blockchain Systems. In Proceedings of the 3rd International Conference on Information Systems Security and Privacy ISBN 978-989-758-209-7, pages 559-566. DOI: 10.5220/0006270005590566

But let's look at it from another angle, and try to build it from bottom up.

What's the minimum you need to do to be able to transact Monero? All you need is outputs and amounts (post-RCT, commitments take the role of amounts). The network verifies the signature, and the signature is produced by using the individul one-time output's private key.

So, all you really need are keypairs P=xG. You could create the destination key by any means you want.

For example, I (the receiver) could roll some x, communicate the P to you, and you make a TX with output P. You could omit the TX keys entirely because I already know my P and x and can tell my wallet to use them when I want to spend. This is because I (the receiver), have decided what the output will be.

This is practically the same as Bitcoin. I give you a public key (well, hash of it) and you pay to the public key (hash).

With CN we could do it the same way. Network doesn't force you to use ECDH & TX keys. However, due to use of ring signatures, we must be sure to never receive twice to the same key. With this in mind, it would be a big hassle to receive. You'd have to generate a new unique key whenever someone wants to send you something. If someone intercepts the payment request, he could monitor the blockchain for appearance of that P and know when you received something.

So, we want a way for the sender to roll the destination output P, in such a way that he won't know x, but such that I will.

For that, I could have some key B=bG for passive receiving, and the sender could construct outputs like P = R + B where he picks some random R=rG. Problem is, he needs to tell me the r as well in order for me to be able to spend so I could recreate the output's secret key x = r + b, compute the public key P, and use that to check that the output is indeed recorded on the blockchain and later spend it. We could make this work today, between me and you. All it requires is a wallet modification. It's not the best however, as you need to communicate the r via secure channel if I am to keep my privacy.

What about using blockchain for communication? That way I can't lose or forget the r and with that lose access to my funds. Problem is, while blockchain is great for record-keeping it is public so it's insecure communication channel. And what's a good way to privately communicate via insecure channel? ECDH.

We could say, OK, let's have the sender roll the outputs like: P=Hs(rB)G+B. Now he can tell me (write it to the blockchain) the R, and I can re-create the keys with x = Hs(bR)+b. Cool. Now someone intercepting the R can't tell that some P is for me, even if he knows my address B. But now, I can't ever be audited otherwise I have to leak my secret key to the auditor and then he could run off with everything. I can't even reveal selective, already spent, outputs, because someone knowing shared secret (bR) and secret key (x) of an output could work out my secret spend key b.

That's why we make the receiving address use dual keys, and then one is enough to check ownership without risk of revealing x, and the other is required to recover the x. With that we arrive to the current set-up.


"Refreshing" means telling the wallet to check the blockchain to see if any transactions were sent or received in any blocks added to the chain since it last looked. This makes it clearer why this has to be done,

If you want the wallet to refresh automatically, try set auto-refresh 1 in thw wallet. This needs a recent enough wallet, and it might not be in the binaries yet.

The GUI will almost certainly have the ability to auto refresh too. And if not, it will be added pretty fast.


Historical significance of FEE_PER_KB_OLD

I discovered this term FEE_PER_KB_OLD in the code base, but it seems unused.

It is unused.

  What is the historical context around it? Was it ever used?

It was used (or rather its value was used), until PR #1074 (Sep 15, 2016), where the definition was added (relevant part of #1074):

-#define FEE_PER_KB                      ((uint64_t)10000000000) // pow(10, 10)
+#define FEE_PER_KB_OLD                  ((uint64_t)10000000000) // pow(10, 10)
+#define FEE_PER_KB                      ((uint64_t)2000000000) // 2 * pow(10, 9)

  Was FEE_PER_KB used from the beginning?

Not quite. It was added in PR #184 (Nov 7, 2014).

  Also, it sounds like the minimum fee is not enforced at the protocol level, just by node consensus (won't relay transactions with fees below the minimum).

The minimum fee is enforced by the consensus protocol, whereby nodes will not relay transactions that do not have the minimum fee. If a miner however edited the code to allow zero-fee transactions and happens to mine one in a block, the block can still be accepted.

  Was there a time where fees were ignored?

Fees were never ignored, although there was no minimum tx fee enforcement initially; this was added a few months later in commit d9f3421ce7 (Jul 17, 2014).


What effect has the increase of minimal ring size from 5 to 7?

Privacy: Outputs are where amounts of Monero are stored on the blockchain. When you spend one of your outputs in a transaction, it cannot be known which of 7 different source outputs you're really spending. Therefore your anonymity set grows by 40%. Another advantage is that outputs that you receive will now more likely be used as decoys in other people's transactions, which adds to your plausible deniability.

Transaction size: A typical Monero transaction would be 13,792 bytes, up from 13,524 bytes. This is an increase of 2.0%.

Transaction fees: Monero uses KB boundaries when calculating fees. Since a typical transaction would still be counted as a 14KB transaction whether it has 5 or 7 ring members, in most cases the fee would be unchanged.

It is of course possible that, depending on your specific transaction (especially if you're spending many outputs in the same transaction), that the transaction fee would increase. For example, if you're spending 10 outputs in a single transaction, the fee would increase by 6%.

Transaction verification time: Ring signature verification time is directly proportional to the number of ring members. Verification of the MLSAG ring signatures (which obfuscate the source outputs) would therefore increase by 40%. However, MLSAGs are not the only part of the transaction that needs to be verified. There is also a range proof Borromean ring signature required for each output created.

By my estimations, a Monero transaction currently requires about 70ms to verify on a single core, of which about 60ms is spent verifying just the output range proofs. Therefore overall verification time would rise from approx 70ms to approx 74ms, which is a 6% increase.

The choice of 7 is a tradeoff between privacy and verification time.

Later this year, the Borromean ring signatures will be replaced with Bulletproof signatures. This may very significantly reduce transaction verification times and provide for the possibility of increasing ring sizes further.


Monero GUI Crash on Launch "api-ms-win-core-libraryloader-l1-2-0.dll is missing"

Following links contains solution:

(1) api-ms-win-core-heap-l1-2-0.dll is Missing

(2) change-the-monero-wallet-gui-rendering-mode

Linux & OS-X:

QMLSCENE_DEVICE=softwarecontext

./monero-wallet-gui

Windows:

Add User Environment Variable.

Name=QMLSCENE_DEVICE

Value=softwarecontext

Now run monero-wallet-gui, this time there should be no error. Hope this helps.


Why does my RPC call return "Connection refused"?

If I recall, RPC is disabled by default, and needs to be explicitly enabled when running the wallet.

I tried it out and got it working by using the command:

monero-wallet-cli --restricted-rpc --rpc-bind-port 18082 --wallet-file <wallet path here> --password <wallet password here>

The program will then listen and wait for rpc commands sent to it on 127.0.0.1 . The command in your post should then work.


electrum seed word list for monero != official electrum wordlist (english): why?

Any reason why?

TL;DR: It's a different convention. Monero is not a fork of Bitcoin, so most things were worked out from scratch.

Does this mean that mymonero-simplewallet wouldn't accept a Bitcoin-style seed phrase I generated inside electrum(and not inside monero)?

Yes

Neither seed type would be accepted in the current implementation of monero-wallet-cli (--restore-deterministic-wallet) anyway because (the latter) only accepts 25-word seeds. But I tried converting 13word (official)electrum seeds using Luigi's address tool but those are failing too :(

That's to be expected because it's a different convention. It's not only the matter of wordlist and length, but the whole checksum and key derivation process.
If you really want to have one mnemonic for both Bitcoin and Monero, you'd have to hash the Electrum mnemonic with something to get a 256-bit integer, and continue from there, or invent some other method.
Simplest way is to input your Electrum seed into "custom entropy" box on Monero offline wallet generator. If you go this way, save a copy of that page somewhere for future reference. Given the same input, it will always create the same Monero wallet with the corresponding Monero mnemonic. This will run the string through 10000 rounds of Keccak-256 and use the result as your seed and private key. Looking at the source of the site, your seed will be derived using:
seed = cnUtil.sc_reduce32(poor_mans_kdf(user_entropy));

function poor_mans_kdf(str)
{
  var hex = cnBase58.bintohex(cnBase58.strtobin(str));
  for (var n = 0; n < 10000; ++n)
    hex = keccak_256(cnBase58.hextobin(hex));
  return hex;
}

Note that sc_reduce32 actually performs a = a mod l operation, where l is defined in CryptoNote whitepaper. This is to make the seed a point on the elliptic curve and a valid private key.

Any reason why?

Long answer
Looking at Electrum documentation, we find the following:

Electrum was the first Bitcoin wallet to derive private keys from a seed phrase made of English words. Early versions of Electrum (before 2.0) used a bidirectional encoding between seed phrase and entropy. This type of encoding requires a fixed wordlist. This means that future versions of Electrum must ship with the exact same wordlist, in order to be able to read old seed phrases.
BIP39 was introduced two years after Electrum. BIP39 seeds include a checksum, in order to help users figure out typing errors. However, BIP39 suffers the same shortcomings as early Electrum seed phrases:

...

Electrum currently use the same wordlist as BIP39 (2048 words). A typical seed has 12 words, which results in 132 bits of entropy in the choice of the seed.

In Electrum, the seed is used as the root for deriving individual Bitcoin keys (addresses). Since Monero only needs one address, the seed is used to derive the private key of the address, and that's all it's used for. Actually, seed == private spend key, and the private view key is derived from it. Public counterparts of those are what makes a Monero address.
Electrum is trying to achieve the following: have the mnemonic seed generate the same HD wallet, without having to know the dictionary used to create it. The size of dictionary was chosen to give exactly 11-bits of entropy to each word in the mnemonic, resulting in total of 132-bits for 12 words.
Monero is not a fork of Bitcoin and neither is Monero wallet software a fork of Electrum, so it did not inherit this.
Monero uses another philosophy. A seed mnemonic is just an encoding of a 256-bit integer seed. It's 2-way. You can always calculate back and forth BUT you need to have the dictionary to recover the wallet. This has a benefit that you can convert an English seed into Japanese, or any other language and get the same result. This allows far more flexibility but the "drawback" is that you have to keep the dictionary around. I'd argue you always need to keep something around (with Electrum, it would be the technical specification of the method used) anyway, so what's the point of wanting to get rid of the dictionary?
The number of words is such that there's approx. same number of combinations of 24 words as there is 256-bit numbers. The words were chosen to prevent mix-up, and also for all to have unique 3-letter prefix. We see that 24^1626 is approximately equal to 2^256 so it's possible to encode 256 bits to 24 words (25th is the checksum).
For more details:

Why one word is found two times in each seed?
What is the checksum at the end of a mnemonic seed?
Will Monero mnemonic seeds need to be converted to BIP 39 for standardization reasons?


Can I view seed words of non deterministic wallet?

If you want a seed, you have to make a deterministic wallet. The seed is a representation of your private spend key, and deterministic wallets derive the private view key from it. Therefore, a non deterministic wallet would not be able to restore the private view key from a seed (or it'd have to be twice the size, which is was not done for unknown reasons).


Is this an optimal setup for solo mining XMR?

Is this an optimal solution for solo mining?

Looks reasonable.

As monerod looks a bit slow when syncing...

Then make sure it has a good internet connection, fast disk (SSD) and a decent enough CPU.

I'm not sure if it is the right tool to be used for getting new blocks to be mined.

The only tool right now for getting block data to be mined is monerod. Even if you used a pool, that pool uses monerod, and right now there is only one implementation of a Monero full node and that is monerod.

If monerod gives exactly the same jobs to all 3 miners, XMRig could end up waisting CPU by computing the same hashes in each rig.

Except it doesn't. XMRig calls get_block_template passing in some random bytes, so the resulting block hashing blob will be unique to each miner.

According to RandomX docs...

This has little to do with RandomX or the random nature of it. The data being hashed is already unique to each miner, as outlined above. If the data being hashed wasn't unique, then calling the hashing function with the same data will result in the same hash (which is how others can reproduce a hash and thus verify submitted blocks).

Would it be an improvement connecting the miners to a public full node?

If the public node you chose to use is better maintained and configured than your own node, then yes.

Would then the security for the private full node be compromised?

No.


I struggled to find a good menubar ticker for OS X, and eventually settled on using BitBar with a small plugin I wrote. Just drop this into your BitBar plugins folder and call it xmrrate.30s.sh or something:

#!/bin/bash

# XMR BitBar ticker, by Riccardo Spagni
#
# Shows last trade value for BTC/XMR on Poloniex

XMR=$(curl -s "https://poloniex.com/public?command=returnTicker" | egrep -o '"BTC_XMR":{"id":114,"last":"[0-9]+(\.)?([0-9]{0,5})?' | sed 's/"BTC_XMR":{"id":114,"last":"//' | sed 's/"//')

echo "∙ XMR: $XMR ∙"

Adjust as needed.


Failing unit test for full node. How serious is it?

It is likely to be fine, with a caveat:

core tests have a known failure, which is a problem in the test itself, fixed in https://github.com/monero-project/monero/pull/2036
unit tests failure is interesting, that's the caveat
libwallet tests are known borked, you can totally ignore those

To determine what the failing tests are, you need to run core tests and unit tests manually:

./build/release/tests/unit_tests/unit_tests
./build/release/tests/core_tests/coretests

The unit tests one may be interesting. Or it might be about serialization, which is a known problem in the setup in some cases (Arch Linux IIRC), and not a problem in Monero itself.

The core tests one may be the invalid key image test, fixed in the PR above. If it's just that, all is fine.

If it's anything else, the Monero team wants to know!


Where can I find the Monero transaction specification?

There is no such specification. It's fairly simple though, see src/cryptonote_basic/cryptonote_basic.h, the transaction and block classes.

Most numbers are variable length integers (format in src/common/varint.h), vectors are a number followed by the elements, etc. Fields are concatenated. Hashes, keys, etc, are dumped as is. Objects which can be different types have an identifier determining the type (see VARIANT_TAG at the end of src/cryptonote_basic/cryptonote_basic.h), then the object.

You can find the hex dump of a transaction in the daemon: print_tx SOMETXID


Are there any extant implementations of the groestl that Monero PoW uses that utilize AesNi instructions and byte-slicing?

The powhasher miner uses aesni-accelerated groestl from the groestl-aesni crate, implemented with llvm intrinsics. Small groestl actually parallelizes better than large groestl: the trick is to do the P rounds and Q rounds in tandem. (I am the author of both projects.)


How to Generate monero wallet on server-side(node.js) or locally?

Alright, solved generating monero wallets problem like that (using Meteor.js):

Downloaded this AWESOME repo: https://github.com/mymonero/mymonero-core-js

Unpacked this repo to the node_modules folder.

On client startup entered this code:

const walletUtils = require('mymonero-core-js/monero_utils/monero_wallet_utils')
const wallet = walletUtils.NewlyCreatedWallet('english', 0)
console.log('## Wallet address:', wallet.keys.public_addr)
console.log('## Mnemonic seed:', wallet.mnemonicString)

So I connected mymonero-core-js lib, and used their function " NewlyCreatedWallet " to create new wallet + mnemonic phrase ( second parametr is network, where 0 is mainNet, 1 is testNet and 2 is STAGENET ).

Everything is working, now I can generate monero wallets !


How can I edit a Moneropedia definition or add a new one?

Easy method:

Visit the moneropedia page
Use the open issue link at bottom of page
Login to and/or create a GitHub account
Click new
Input the Moneropedia terms and defintions you would like to add or modify
Click submit new issue
Track your request here

Edit an existing entry yourself method:

Visit the GitHub for the monero website
Login to GitHub
Make a fork of the site
Click knowledge-base
Click moneropedia
Click on the term you wish to edit
Click edit
Make your desired changes to the term definition, consistent with the existing format
Click create a new branch for this commit and start a pull request
Click propose file change
track your pull request

Add a new entry yourself method:

Visit the GitHub for the monero website
Login to GitHub
Make a fork of the site
Click knowledge-base
Click moneropedia
Click create new file
Create a new Moneropedia term and definition, consistent with the formatting for existing terms
Click create a new branch for this commit and start a pull request
Click propose new file
track your pull request


Look, if you don't own the computers then I don't suggest you mine on them. However if you do own them, then look at using xmr-stack https://github.com/fireice-uk/xmr-stak


Monero hashrate falls dramatically on Azure Windows 10 Pro

Mining of cloud based virtual servers will always be poor and susceptible to changes in HR. With virtual servers you are sharing CPU resources, and with CrytoNight, you need 2MB CPU cache per thread for optimal performance. A virtual server will never give you exclusivity over CPU cache, hence you'll see changes. Further, most hosting companies forbid mining, so If they detect it, they'll drop your resources.

TL;DR never mine on cloud virtual servers.


With Monero firmware loaded on a Trezor, how does one create private spend keys from the BIP 39 seed words supplied during a Trezor's configuration?

The initial answer below, doing things the Monero way, originated from How does one convert the Trezor seed to a simplewallet seed and vice versa. I followed this URL's recommendations using the associated V0313 binaries, but was unable to recreate the same Monero address that my Trezor is using for a given prompted "password" and an integer "index" passed via the --hardware-wallet argument index:addr_version that is supplied to the forked V0313 simplewallet.

Here is an example of results for using the V0313 trezorctl with mnemonics_recover assuming a Trezor during its configuration (using the V0313 firmware) resulted in these 24 BIP 39 seed words: honey naive mouse rubber runway fetch rifle enhance unfair undo hood sister dog armed exhibit interest public rib tourist camera mistake claim flat wing.  The index passed to simplwallet was 0 and the password promted by simplewallet is Bad_PASSword.

% ./trezorctl recover_mnemonic 0 Bad_PASSword English honey naive mouse rubber runway fetch rifle enhance unfair undo hood sister dog armed exhibit interest public rib tourist camera mistake claim flat wing

Private key: 7e22a1f766b70f10e88364ac833d8622cebee457eba9f1f4b9826bfe728d1e05
Wallet address: 48iYq4jBs6BZEzGXJZcWC8C85aA3pHSYhF7JE2Dg3iD6Hdd56NVTcfygghHqw66DvAKohATR4DMQsPBtgeQxU3Lp59pwkt8
Mnemonic: agnostic ignore heels update syndrome ultimate vaults tufts mugged picked rudely trash lukewarm enlist observant later suddenly shuffled gleeful stellar soya tudor habitat hire lukewarm

It is worth noting the Private key, Wallet address, and Mnemonic computed above all correlate with results from https://xmr.llcoins.net/ Javascript, which can be confirmed offline. Those using the Monero firmware, might want to independently validate the v0313 trezorctl recover_mnemonic is working properly for them.

More importantly, one can positively confirm they recorded the proper BIP 39 seed words displayed by their Trezor device if they use libbitcoin's bitcoin-explorer (bx) command, which has an extremely good track record for recreating Trezor device results with a relatively simple command line interface. Of course one must use the 24 words that is applicable to their Trezor and not the ones demonstrated below and their appropriate password. Other than that the arguments to the piped processes below remain the same.

% echo "honey naive mouse rubber runway fetch rifle enhance unfair undo hood sister dog armed exhibit interest public rib tourist camera mistake claim flat wing" | bx mnemonic-to-seed -p Bad_PASSword | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 0 | bx hd-public -d -i 0

xpub6C9uhLie5mr2TJ8z27sARKZQf5AL8EA5U5S5NjtjC9sYx1fW6hXC8FZxLRqoBZtk35mC5GCyffx3BKAiv9GwP9utEEtfN5VTw31fYyFfrBD

If the extended public key produced immediately above matches the one available when one digs through https://wallet.mytrezor.com/#/ with their Trezor, then one most definitely recorded the BIP 39 seed words properly.  With the computed Monero address not matching, and the application of bx to properly compute the extended account public key convinced me the trezorctl recover_mnemonics capability is not functioning properly for V0313.

Suggested behavioral improvements for "trezorctl mnemonics_recover" capability:

Below is a candidate test vector recommendation that also uses libbitcoin.  Applying bx to the trezorctl command example above, here is how a future release could work and be consistent with BIPs 32, and 39, and BIP 44 coin registrations to the maximum extent possible for synthesizing the private spend key. The 44 integer below indicates BIP 44 is to be used. The 128 indicates Monero is to be used, see the BIP 44 coin registration table.

% echo "honey naive mouse rubber runway fetch rifle enhance unfair undo hood sister dog armed exhibit interest public rib tourist camera mistake claim flat wing" | bx mnemonic-to-seed -p Bad_PASSword | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 128 | bx hd-private -d -i 0 | bx hd-to-ec

4a06027938fbe584f0c7fad131cdae14c737e53f6f3e9bdec2b382698b384fac

The following produces the Monero private spend key:

% ./sc_reduce32 4a06027938fbe584f0c7fad131cdae14c737e53f6f3e9bdec2b382698b384fac

08bf67d7301c2e1491a74e747f0af943c637e53f6f3e9bdec2b382698b384f0c

The following produces the Electrum seed words used for wallet/(private spend key) recovery:

% ./bytes_to_words 08bf67d7301c2e1491a74e747f0af943c637e53f6f3e9bdec2b382698b384f0c

ascend wedge sorry fiat gone isolated rowboat skydive educated regular amaze fossil heels tagged awakened gables upload sipped lynx anvil kickoff basin does enigma educated

Then using https://xmr.llcoins.net/addresstests.html, the following Monero address results:

4Ak341HR2HnYPgocscZYAaMByPa7rHCj1EhbyCQjLvyWQkcNTG2zbbB1h8iB5sbcDYjUNobgGJn4fjgqMfeYQfEaS6w8HHL

This test vector approach succintly demonstrates how Monero harmonization with BIPs 32/39/44 is possible and desired.  This mindset also leaves open the concept of applying BIP 38 to Monero's deterministic private spend keys.

Update: Created an executable called ./xmr that takes a private secp256k1 key. Results below match results above.

% echo "honey naive mouse rubber runway fetch rifle enhance unfair undo hood sister dog armed exhibit interest public rib tourist camera mistake claim flat wing" | bx mnemonic-to-seed -p Bad_PASSword | bx hd-new | bx hd-private -d -i 44 | bx hd-private -d -i 128 | bx hd-private -d -i 0 | bx hd-to-ec | ./xmr

   Private Spend Key    : 08bf67d7301c2e1491a74e747f0af943c637e53f6f3e9bdec2b382698b384f0c
   Private View Key     : ec69371cc4f7176b3eddb69a1eca4a775909d73b68021aaf5f173eac9d8fd706
   Public Spend Key     : f0a59fa7ee5e71bbace5a9f6a4bdb778b404d54406ffa051e841710e9642f98e
   Public View Key      : 00d7d42cee66de04230aa498f3efb3fdec69c69beceea0ff352775998ad293de
   Monero Address       : 4Ak341HR2HnYPgocscZYAaMByPa7rHCj1EhbyCQjLvyWQkcNTG2zbbB1h8iB5sbcDYjUNobgGJn4fjgqMfeYQfEaS6w8HHL
   Electrum Seed Words  : ascend wedge sorry fiat gone isolated rowboat skydive educated regular amaze fossil heels tagged awakened gables upload sipped lynx anvil kickoff basin does enigma educated

Cheers...


Yes, the core team chose getmonero.org as the best available domain at the time because the owner of monero.org never self identified or otherwise communicated with the core team. According to well known Monero community member Gingeropolous:

  monero.org is owned and operated by an unknown party. They are apparently not part of the community because they haven't spoken up. Monero.org has been benign up to this point, but I wouldn't download anything from that site. My level of distrust stems from the fact that the cryptonote environment is relatively hostile (IMO, no one else could have performed the 201623 attack and, in general, the overall scam is hostile to the entire crypto community)

Based on the above should be no surprise that the domain registration is anonymous

  Raw WHOIS Record
  Domain Name: MONERO.ORG
  Domain ID: D169443173-LROR
  WHOIS Server:
  Referral URL: http://www.godaddy.com
  Updated Date: 2016-07-20T16:33:55Z
  Creation Date: 2013-08-15T21:54:22Z
  Registry Expiry Date: 2017-08-15T21:54:22Z
  Sponsoring Registrar: GoDaddy.com, LLC
  Sponsoring Registrar IANA ID: 146
  Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
  Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited
  Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
  Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
  Registrant ID: CR175374311
  Registrant Name: Registration Private
  Registrant Organization: Domains By Proxy, LLC
  Registrant Street: DomainsByProxy.com
  Registrant Street: 14747 N Northsight Blvd Suite 111, PMB 309
  Registrant City: Scottsdale
  Registrant State/Province: Arizona
  Registrant Postal Code: 85260
  Registrant Country: US
  Registrant Phone: +1.4806242599
  Registrant Phone Ext:
  Registrant Fax: +1.4806242598
  Registrant Fax Ext:
  Registrant Email: MONERO.ORG@domainsbyproxy.com
  Admin ID: CR175374312
  Admin Name: Registration Private
  Admin Organization: Domains By Proxy, LLC
  Admin Street: DomainsByProxy.com
  Admin Street: 14747 N Northsight Blvd Suite 111, PMB 309
  Admin City: Scottsdale
  Admin State/Province: Arizona
  Admin Postal Code: 85260
  Admin Country: US
  Admin Phone: +1.4806242599
  Admin Phone Ext:
  Admin Fax: +1.4806242598
  Admin Fax Ext:
  Admin Email: MONERO.ORG@domainsbyproxy.com
  Tech ID: CR175374314
  Tech Name: Registration Private
  Tech Organization: Domains By Proxy, LLC
  Tech Street: DomainsByProxy.com
  Tech Street: 14747 N Northsight Blvd Suite 111, PMB 309
  Tech City: Scottsdale
  Tech State/Province: Arizona
  Tech Postal Code: 85260
  Tech Country: US
  Tech Phone: +1.4806242599
  Tech Phone Ext:
  Tech Fax: +1.4806242598
  Tech Fax Ext:
  Tech Email: MONERO.ORG@domainsbyproxy.com
  Name Server: NS71.DOMAINCONTROL.COM
  Name Server: NS72.DOMAINCONTROL.COM
  DNSSEC: unsigned

      Last update of WHOIS database: 2016-08-25T05:35:08Z <<<


A way to add to tx_extra with current monero executables

Only the old, long-form, unencrypted payment IDs are obsolete. You can still use the short (8 byte) encrypted payment IDs.

You create/attach encrypted payment IDs by using the command integrated_address:

help integrated_address

Command usage:
  integrated_address [device] [<payment_id> | <address>]

Command description:
  Encode a payment ID into an integrated address for the current wallet public address (no argument uses a random payment ID), or decode an integrated address to standard address and payment ID

Replacing <payment_id> with the 8 hex bytes you want to use. The result will be an integrated address with an embedded encrypted payment ID. E.g.

integrated_address deadbeeffacefeed

More information can be found: https://web.getmonero.org/resources/moneropedia/paymentid.html


I had the same problem, but once I was researching in google y left monerod.exe running for a few minutes, and when I notice monerod.exe was connected. I hope this helps to you.


Understanding payment receiving concepts

The results from a get_bulk_payments call includes a block_height value, is this the first mined block this transaction appears in?

Correct.

  Assume that calling get_bulk_payments with a min_block_height of 1010 returns a payment with block_height 1000. This means there have been 10 confirmations?

If you specify 1010 as min_block_height it will only begin scanning blocks from block 1010. Thus, if a transaction was mined in block 1000 it won't be picked up by this specific command. You'd need to set min_block_height to 1000. As the documentation states:

  The block height at which to start looking for payments

However, you are correct that a transaction mined in block 1000 will have 10 confirmations at block 1010. In other words, confirmations is the current block height minus the block height the transaction was mined in.

  If a payment returned from get_bulk_payments has an unlock_time != 0 does this mean I can't spend this amount immediately?

Correct.

  If so, someone could (say maliciously) put an unlock_time for a year or more.

Correct. If I recall correctly, the maximum lock time currently is 4 years.

  I'm guessing that payments can have an unlock_time not equal to zero, but the time or blockheight value is in the past so it is spendable immediately.

Not sure if I understand this question correctly, but the unlock time is, as far as I know, set from the block the transaction is mined in. Note that by default all transactions are locked for 10 blocks. However, if an unlock time is included in the transactions they could be locked for a longer amount of time.

  If there are 2 or more payments with the same tx_hash is it possible they have different unlock_time values?

Transactions cannot have the same tx hash. In addition, multiple transactions also cannot have the same outputs as that would indicate someone would've successfully performed a double spend.


Why does the Daemon keep flipping about after full loading

On a bit of digging found that the daemon had ignored the /Homedirectory/.bitmonero/lmdb that took 3 days to create. On restarting the gui the daemon began to re-create in total the data in /Homedirectory/Monero/monero-gui-v0.17.1.9/lmdb - it had stuffed 2gig already by time I pulled the plug. I cp'd the .bitmonero/lmdb content to this new location that had magically appeared and was able to resync the gui.  It would help if the daemon had an address or environment variable where to find the data.mdb rather find it chuntering off on it's own. Need more Noddy guide(s) for Newbies.
PS.
even a disk to disk copy of 106 gig takes nearly an hour to complete.
Follow up:- On checking with monerod --help   noted that /Homedirectory/.bitmonero is the default location for the database - hmmm, finger trouble at work - yes I had stupidly in the gui Settings/node section entered the download directory for the Blockchain location - DOH! Deleted my entry such that it was marked as default. Now I can remove the extra 106gig copy of the database. On restart the re-sync took a few minutes to complete and was in the correct location of /HomeDirectory/.binmonero
Time for a cup of coffee now that is fixed!


How does the payment id appear in a transaction?

The txextra field can contain several subfields.

Start by reading a single byte. This is the subfield tag.

Tags:
0 = padding
1 = the next 32 bytes is the transaction public key
2 = a nonce. Read a VarInt[1] to determine the nonce length. Then read a byte to determine the nonce type

Nonce types:
0 = 32 byte unencrypted payment id
1 = 8 byte encrypted payment id

If there is an encrypted payment id, you need to compute the shared secret for the transaction in order to decrypt it.

To decrypt an encrypted payment id, you need to XOR it with the payment id key. Start with the shared secret, by doing scalar multiplication of your private view key with the transaction public key located in the txextra and then multiplying that by 8. Concatenate the byte representation of the shared secret elliptic curve point with the hex "8d". Take a keccak(256) hash of this, and you have the XOR decryption key for the encrypted payment id.

[1] The VarInt integer representation is defined in section 1.2 of https://tukaani.org/xz/xz-file-format.txt

Also see https://cryptonote.org/cns/cns005.txt and https://github.com/monero-project/monero/blob/1a4298685aa9e694bc555ae69be59d14d3790465/src/cryptonote_basic/tx_extra.h


It will get wrapped around because it's later passed through sc_reduce32 function which performs mod l operation on the input.

See below example using silent Matt's big int library which is loaded with llcoins. Easiest to just open the developer tab and type stuff into JS console.

To calculate 2^252 + 27742317777372353535851937790883648493:

l = JSBigInt(2).pow(252).add(JSBigInt.parse("27742317777372353535851937790883648493",10));

To print out the number in base16:

l.toString(16);
"1000000000000000000000000000000014DEF9DEA2F79CD65812631A5CF5D3ED"

That's the l. If you swap byes and feed it as seed to llcoins, you should get 0x0 as seed. Try inputting EDD3F55C1A631258D69CF7A2DEF9DE1400000000000000000000000000000010 (little endian) as seed and you'll get 0000000000000000000000000000000000000000000000000000000000000000 as private key.

Now, we can also do the addition from your example:

a = JSBigInt.parse("0x1111111111111111111111111111111111111111111111111111111111111111");
BigInteger {_d: Array(11), _s: 1}
c = l.add(a);
BigInteger {_d: Array(11), _s: 1}
c.toString(16);
"2111111111111111111111111111111125F00AEFB408ADE76923742B6E06E4FE"

Performing mod l will give you:

c.remainder(l).toString(16);
"1111111111111111111111111111110FC3217326E19743AB8FEADF6B41B3D24"

observe how you don't get the value of a because a itself is bigger than l:

a.remainder(l).toString(16);
"1111111111111111111111111111110FC3217326E19743AB8FEADF6B41B3D24"

so adding l to this will give you the original number:

a.remainder(l).add(l).toString(16);
"1111111111111111111111111111111111111111111111111111111111111111"

If you swap endian of c and feed it as seed to llcoins, you'll get the same remainder but with little endian byte order:

seed=FEE4066E2B742369E7AD08B4EF0AF02511111111111111111111111111111121

privSpend=243d1bb4f6adfeb83a74196e321732fc10111111111111111111111111111101


How many transaction versions in Monero? ... how many different formats of transaction does Monero have? What differences do they include? In what blocks these formats are accepted?

Two. v1 (pre-RingCT, before block 1220517) and v2 (RingCT, from block 1220517).


I now get the message "monero-core" is not responding

The issue was resolved by starting the GUI as follows:
QMLSCENE_DEVICE=softwarecontext ./monero-wallet-gui
QMLSCENE_DEVICE=softwarecontext is basically a fallback mode with respect to graphics. It can be utilized in case the 'default graphics' do not properly support the rendering of the GUI.


How to extract data from local blockchain

Run a local daemon, and then use the daemon RPC API to query it for blocks:

https://getmonero.org/knowledge-base/developer-guides/daemon-rpc


How to generate a Monero wallet address with the API?

You didn't specify any specific language so I'll assume you're using a shell. Even if you don't, it shouldn't be hard to run a shell command using a different language.

Download the latest command-line tools from https://getmonero.org/downloads/

Extract and run the following command

monero-wallet-cli --generate-new-wallet "my_wallet_name" --password "pass123" --mnemonic-language English --create-address-file

This will create and open a new wallet (and keep it open). If you want to create a wallet and immediately close it you could use

echo "exit" | ./monero-wallet-cli --generate-new-wallet "my_wallet_name" --password "pass123" --mnemonic-language English --create-address-file

That's it. A new wallet named my_wallet_name was created with password pass123. You can see your address by running

cat my_wallet_name.address.txt


Multiple CPU miners with low hashrate vs single CPU miner with high hashrate

If all the computers have a good network connectivity, the probability of successfully mining a block is proportional to your total hash rate.

Mining with 10 CPUs doing 200 h/s each and mining with 1 CPU doing 2000 h/s will give the same probability of finding a block.


XMR cpu mining importance of number of threads?

Each thread requires 2MiB of memory. That's because an instance of CryptoNight hash function requires a 2MiB scratchpad. If it can all fit in CPU cache it's way faster since RAM is very slow compared to CPU cache. So, divide your CPU cache with 2 and you'll get the optimal number of threads.

  First, the input is hashed using Keccak [KECCAK] with parameters b =
  1600 and c = 512. The bytes 0..31 of the Keccak final state are
  interpreted as an AES-256 key [AES] and expanded to 10 round keys. A
  scratchpad of 2097152 bytes (2 MiB) is allocated.

i7-6700HQ has 6MB of cache so you should try with 3 threads
i7-4700HQ has 6MB as well

I'd expect you to achieve best results with 2 or 3 threads. If you already tried those, and are still getting better results with more then I don't know. The cache size is a thumb rule, but it could also depend on other low-level stuff which are understood by only a few.

You could also try xmr-stak and compare the results.


If the core Monero daemon gets to a point where it's particularly secure and particularly stable (eg. the code has been formally verified).

Sounds like an idea rather than a particular plan with dates and methods intended for verification. When Monero is particularly secure and particularly stable, then they will probably start discussing methods of verification.


I see in my transaction "From Block" these things:
  Hash IDon'tKnowIfIShouldObscureThis
  Height 1317365 (437 confirmations)

  In my Full node Monero Wallet I see: Synced 1238883/1288639

  Does this mean I have to wait until I get 1317365
  before I can see the money in my balance?

You are correct. Until you have synced up the the block height of your incoming transaction your wallet will be unaware of it.

With Monero there is no way to look up the balance of an address. Instead every block is scanned to see if it contains any outputs which your wallet controls. In your case the block in question will not been seen until you sync to height 1317365


Which is better for Monero mining: AMD Threadripper or Intel i9 7900x?

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

On the second page you will then see the relevant charts

Here are the details from that article

Cache size and optimal number of threads

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

Hashes per Second

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

Power consumption in Watt

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

Hashes per Watt

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


How many Monero is mined in a day on average as of 2020 Jan?

The amount of new Monero created each day gradually reduces until it hits 0.6 XMR per block (the tail emission). A great answer on this subject can be found here.

  Monero blocks are mined every 2 minutes. But how many are mined in a day on average?

One block mined every 2 minutes is 720 blocks per day.

As of this moment, 1.99 XMR are produced for each block (so 1432 XMR per day).


It's the output index. Assuming you just have one output (all the reward to a single output), just use 0. E.g. P=Hs(8rA || 0)G+B.


Tippero contains its own instructions, which can be queries with the !help and !commands commands (send a message to the bot with this command). The latter gives you a list of modules and their commands. To view a one liner description of what each command does, try !commands NAME, replaving NAME with the module you want, eg !commands dice.

The canonical tip command is !tip thisnick 1.1, which tips thisnick 1.1 monero, but Reddit also has a more convenient syntax: +2.5 /u/tippero, which will tip the author of the comment you're replying to.

If you're going to use IRC and Reddit, you may want to link your Freenode and Reddit Tippero accounts, so you can use a single balance: see !linking_accounts, which will explain how to do so.

Last, for each of your specific questions:

Tip someone with !tip NICK AMOUNT
Tip everyone in a channel with !rain AMOUNT
See your balance with !balance
Deposit information is available via !deposit (don't forget to use the payment id this gives you), and withdraw with !withdraw ADDRESS


How do you propose a project with the forum funding system?

One way would be to ask the devs on freenode.org IRC in #monero or #monero-dev , dEBRUYNE should be able to help anyone out with lodging a forum funding bounty.


What are 3 types of Ring CT transactions?

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

Edit - Some clarification:

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


I run a full monero node, is there a way to see my node on the network? Can I mark my node some how?

No. Nodes are just identified by IP addresses.


Is it possible to increase the total supply and how equally distributed is monero among it's early adopers?

Is it possible to change the total supply afterwards, by a Hard Fork for example?

That would be possible, but it would break the social contract. I am quite certain almost all community members and miners would be opposed to it.

  Does is prevent the equal distribution of Moneros?

Not necessarily. Given that Monero has a tail emission of <1% per year (the actual number is approximately 0.85%), the portion of the "early adopters" will somewhat dilute. In addition, Monero has always had high volume trading and furthermore had a fair launch. Therefore, one could argue that the distribution is relatively fair.


Wrong chain, maybe - maybe not - no transaction possible, wrong balance... please help!

You should try to rescan your wallet for spent output with rescan_spent from the cli. It should remove your spent transaction done on the wrong blockchain.

Otherwise you could try to pop the blocks to restart syncing before the transaction:
./monero-blockchain-import --pop-blocks 6500
This will remove the 6500 blocks and when you will restart monerod it will sync again.

Edit: try first option. If it does not help, pop the blocks and scan again.


Is there the equivalent of a BIP38 encrypted private key for Monero private keys?

Monero can be made to be compliant with the spirit of BIPs 32, 38, 39 and 44. The main issue is BIP 32, 39 and 44 public keys and addresses can't be synthesized using traditional Bitcoin methodologies.

BIP 38 has two capabilities. Both are concisely documented at https://github.com/libbitcoin/libbitcoin/wiki/Altcoin-Version-Mappings#bx---key-encryption-commands.

Extended AES256Encrypt and AES256Decrypt most definitely can be supported  for encoding and decoding deterministic Monero private spend keys, only a matter of development and merging into the master branch. The Monero Team will need to decide upon the prefix to be used other than 6P taken by Bitcoin, see https://github.com/libbitcoin/libbitcoin/wiki/Altchain-Encrypted-Private-Keys#sample-map.

A bit more thought needs to be given to the other BIP 38 "EC Multiply Mode", essentially being a Casascius without being a money transmitter. This capability looks promising, but no guarantees without a little further investigation.

Update:  Posted C++ source code on Github for the ./xmr command used used at the end of this piped command sequence.  Not a cross platform developer, but the code compiles on a Mac Homebrew environment using Xcode. With the ./xmr command, both BIP 38 modes can be supported using this. The ./xmr command can also be applied to create Monero brainwallet that can be the foundation for a BIP 38 wallet, even supporting BIP 38 "EC Multiply Mode" for those wanting to mint or print and do not want to be classified as money transmitters.

% echo -n "This brain wallet sucks" | bx base16-encode | bx sha256 | bx mnemonic-new | bx mnemonic-to-seed -p "My Password" |  bx hd-new -v 76066276 | bx hd-private -d -i 44 | bx hd-private -d -i 128 |  bx hd-private -d -i 0 | bx hd-to-ec | ./xmr

Seed                 :
70371fbdba4072dbff8c9350414cf9a903776791792d575557b697cb09952951

Private Spend Key    : cf1352ec36511623d07cbd21e86a9e4103776791792d575557b697cb09952901

Private View Key     : fd38a51dda45a8ff44042525477a572b93d3219d3751ca49f5aeb7f8278cdc0c

Public Spend Key     : ec8cc4f1f0622946bd24a41dc7a4d01964f4f6a878e0e8bf0ce0eb7214174979

Public View Key      : 853a5e0aa455820991cd8801ac7be09dbf347b8be875d208f08d97faf7fefb3b

Monero Address       : 4Ab2kg2ZXrgCqFp3HAnJfy5FMiPKtNaCFYxRnRpkWiG8MKuDfDLo67K2bqX9gXszpfTPLs6ng4YAd2Vj6wthUhk67icBjbC

Electrum Seed Words  :
onward easy cistern puddle giddy ladder foxes ingested morsel vocal glide observant guide among online jargon wonders fudge emails daytime wobbly army jeers jigsaw ladder

% bx ec-to-ek -v 0 "Your BIP38 Password" cf1352ec36511623d07cbd21e86a9e4103776791792d575557b697cb09952901
6PYXHLAR2khgrRd5GgSStNJhYMH5p8Ug52yUzt86CseG2ee3A3z9Mb9EWY

% bx ek-to-ec "Your BIP38 Password" 6PYXHLAR2khgrRd5GgSStNJhYMH5p8Ug52yUzt86CseG2ee3A3z9Mb9EWY
cf1352ec36511623d07cbd21e86a9e4103776791792d575557b697cb09952901


What does the "X" mean in the XMR ticker symbol?

Many exchanges prefer a 3 letter ticker symbol. The X is the result of an ISO 4217 standard common for commodities and currencies that are not specific to a certain country. Bitcoin commonly uses XBT instead of BTC for the same reason


Monero GUI quits within a few seconds after launching

monero-wallet-gui uses Qt, which uses OpenGL by default, and this does not play well with some machines. For this reason, monero-wallet-gui includes a script called start-low-graphics-mode.bat to run in fallback mode, which should be compatible with more machines, but at the cost of (I believe) some graphical glitches.


First, the payment_id field in transfer/transfer_split is the same type as used by integrated addresses, i.e. it's a short encrypted ID. It's therefore restricted to 16 characters.

Second, payment IDs are being deprecated, being replaced by subaddresses.

UPDATE

I double checked the current (0.14.0.2) wallet RPC release code and this still allows long payment IDs (64 characters). The second point above still holds - they are being deprecated.

For completeness, the OP also placed the payment_id parameter in the wrong place in the JSON payload.


Making an address transparent to public view

Publish the address and public view key and anyone can audit the total received, but can't tell what's been spent.

To audit the balance, the non-profit should publish updated key images file every time they receive something new. The process is described here (steps 1 to 6).

The auditor (or general public), could then make a watch wallet from the address and viewkey, scan the blockchain for incoming transfers, and import key images to mark what's been spent and get the correct balance. With the viewkey, they'll be able to see whether something new has been received, and then they'd know they need the updated key images to be able to monitor whether those new outputs have been spent.


The "net" stands for network, ie network hash rate. Now that you mention it, I will go make a PR to change it to be more clear.

The (out) connections are those where your computer initiated the connection with some other node.

The (in) connections are those where other node initiated the connection with your computer.

They're all fully qualified connections, the difference is just in the "who called who?".


Radeon Blockchain Drivers not Installing on Vega 64

I was following this guide and trying to install the Blockchain Drivers.

I realized that my gpus were overheating. I fixed this problem by pointing an external fan at my gpus.


How to use the electrum seed password in monero-wallet-cli?

You can create an encrypted seed by running the encrypted_seed command in monero-wallet-cli. You will be asked for a password, and the encrypted seed will be displayed. This is an extra line of defense to your seed leaking. Old wallets have 24 words, not 12, and this has nothing to do with them.


How can I check if a transaction is mined into the blockchain?

You can paste the txid in a block explorer, or just look at the history in the gui to see if it has started confirming.
In cli I think show_transfer <txid> should do.

No matter the amount, if the network is not overloaded, your transaction should be mined within an average 3 minutes (1 minute average for current block to be mined and then the 2 minutes blocktime for the block including your transaction to be mined).


how to get 'generator point' for Monero transaction


How does one change Monero's block reward for chosen blocks?

Monero does not use the height, but that doesn't mean a fork cannot. Just pass the block height to get_block_reward (in src/cryptonote_basic/cryptonote_basic_impl.cpp) and you're set. Don't forget to update the tests :)


How does Monero privacy and security compare to ZCoin?

1. Can ZCoin protect the privacy of transaction amounts like Monero will do with RingCT
No, it cannot. All transaction amounts are visible on the ZCoin blockchain. As of the block 1,220,517 v4 fork in early January, RingCT transactions will be allowed on the Monero network. RingCT transactions hide all Monero transaction amounts but will not become mandatory until the v5 fork in September, 2017.
ZCoin (formerly known as Moneta) developers are independent from the academics that created the Zerocoin or the more recent Zerocash protocol. Some key distinctions, as clarified by Zcash developer, Daira Hopwood:

BTW, in case anyone is confused, Zcoin is a renaming of Moneta. It would have been much clearer if the article had said that. It's based on development of the original Zerocoin prototype code, and has nothing to do with Zcash.
Zerocoin/Moneta/Zcoin uses RSA-based ZK proofs. Unlike Zcash, separate parameters are needed for each denomination of coin, and there is information leakage about the denominations used. Proofs are about 45 KiB (not even taking into account the need for multiple proofs for the denominated coins) as opposed to 296 bytes for the raw proof in Zcash.

More background can be found in this AMA with Moneta/ZCoin co-founder Gary Le.
2.What are the key security risks associated with each design? Does ZCoin require a trusted setup or is it trustless like Monero?
ZCoin required a trusted setup and relied on the parameters created by the RSA Factoring Challenge in 1991. According to the parameter generation discussion on the ZCoin website:

At projected computing capacity, it will be safe to use for many more decades. By then, Zcoin can port its parameters to a new cryptographic scheme. Admittedly, the RSA has not been a great company in recent years, with revelations of the RSA collaborating with the NSA. But the keys to the RSA Factoring challenge were generated in 1991, early in the RSA days when the creators of the RSA algorithm still had a high amount of control over their company.

When asked why ZCoin relied on this RSA accumulator setup and hoping that the parameter keys created by someone else (RSA Laboratories) where destroyed, instead of creating their trusted setup similar to Zcash, Gary Le said

There is this thing called a trustless RSA setup but it is very inefficient and would lead essentially to blocktimes that are hours long... In order to avoid that and make this actual cryptocurrency that you can send transactions with we had to use this previously generated trustless[ed] setup by RSA
To say the least, its not the best solution, but it is not no worse and no better than Zcash trusless[ed] setup.

The above "trustless" quotes (instead of trusted) is misleading  just like the language on the Zcoin website:

On the other hand, there is a strong mitigating factor in the unlikely scenario of a compromised Zcoin setup: everybody could still see that Zcoin’s money supply checks out.

The above quote seems to falsely imply that a compromised setup could not impact the money supply, like it could with Zcash. A more accurate statement based on the Zcoin whitepaper would be:
"On the other hand, there is a mitigating factor in the scenario of a compromised Zcoin setup: everybody can still check at any time to see whether or not Zcoin’s money supply matches its planned emission curve or if additional Zcoin's have been created as a result of the compromise"
3.How does the PoW algorithm of ZCoin compare to that of Monero?
ZCoin uses Lyra2 and Monero uses CryptoNight both of which are meant to be ASIC resistant.


How do I compile Monero for Raspberry Pi 3 (ARMv8)?

At the present time, nobody ships a 64bit kernel or OS for Raspberry Pi 3. That's why we only provide 32bit binaries for the Pi 3. So no, you cannot leverage the ARMv8 features of the Pi 3 yet. If you want an actual 64 bit ARM device with 64 bit software support, try the Pine A64.

Other devices with good ARM64 support - anything using Rockchip RK3368, Amlogic S912, or Hisilicon Kirin 650, 955, etc. I've tested ARMv8 support on all of these successfully with decent results.


What is the difference between Monero (XMR) and CloakCoin (CLOAK)?

CloakCoin's "Enigma" protocol is essentially a mixing protocol similar to CoinJoin or PrivateSend in Dash. This is very different than Monero.

Here is a diagram provided by Enigma on the mixing process:

The nodes mentioned above get "entropy" from coins provided by the mixers themselves.

Unfortunately, this mixing process has significant shortfalls. Here are some of them:

You place inherent trust in these mixers. The first mixer learns the sender address (you). The last mixer learns the recipient address (especially if stealth addresses are not used, more on the later). There a variety of situations of possible collusion where multiple rounds of "cloaking" can trivially reveal the entire path of a "cloaked" transaction.
Transaction amounts are still visible. If I send 2.34578 CLOAK to someone with "Enigma," it can be relatively trivial to trace the amount transacted. Even if the outputs are split into specific, set denominations, there are still potential issues by counting the number of outputs as is a weakness of PrivateSend.
The entropy is even smaller than PrivateSend and other CoinJoin-based approaches, since the entropy is limited to the money held by the "Cloaker" operators. However, this is a greater incentive to provide coins for cloaking than Dash (similar to the liquidity providers they used a while back).

In their whitepaper, Cloak refers to three more privacy features: 1) Tor onion routing, 2) stealth addresses, and 3) combined "super-transactions." Let's evaluate these in more detail.

Tor is a network-layer of communication, not a consensus layer. While it is important to hide this metadata (including IP address), it is less essential than hiding information recorded in the blockchain. Tor doesn't protect you alone if you make an in-person purchase, for example. Furthermore, there are other ways to hide this metadata, including using WiFi at a coffee shop, a trusted VPN, etc.

Cloak recommends combining an Enigma transaction with stealth addresses, which is actually a good idea. If money is sent from a stealth address with Engima, the sender has more protection from malicious "Cloakers." Likewise, the recipient is better protected if the money is sent to the recipient's stealth addresses. Monero also uses stealth addresses (though by mandate rather than choice), and Enigma seems to closely replicate the "ring signatures" portion of Monero on first glace. Unfortunately, there are also shortfalls with this method:

The entropy set is still smaller. Rather than selecting from the entire output set with Monero, CloakCoin users are still restricted to select outputs controlled by the "Cloakers."
There is still trust. Whereas ring signatures in Monero provide plausible deniability without having to trust nodes ("Cloakers") to provide this plausible deniability, "Cloakers" can collude to remove this plausible deniability. This is especially a concern if these mixing services are run on a handful of providers with access to server logs, including Amazon AWS, Choopa, DigitalOcean, etc.
Stealth addresses are optional, limiting the effectiveness at reducing many forms of blockchain analysis. A merchant may refuse to reimburse to a stealth address, for example.

"Super-transactions" are not a new idea. The intent is to "condense" the history of multiple transactions into one. For example, if money was transferred between addresses A -> B -> C, it could theoretically be condensed to A -> C. Unfortunately, the whitepaper is light on details on how this could be accomplished, so we have no idea how effective (or ineffective) this could be. Other projects like Grin take advantage of a similar idea. Again, this feature needs to be fairly widely-used to be effective.

Monero uses three cryptographic technologies to provide privacy for all transactions. Ring signatures hide the origin of funds spent by hiding the real output among other sources of money. Ring confidential transactions (RingCT) hide the amount. Stealth addresses break the link between sources of funds and addresses (making rich lists impossible). You can learn more about each individually by searching around in StackExchange and watching the linked videos.

Perhaps most importantly, you can use Monero without having to worry about trust. The math is prepared locally without needing to communicate with clients to "mix" anything.

You do not need to pay a percent fee to the "cloaker" nodes to provide their entropy. The standard Monero transaction fee is based on transaction size, not the amount. This makes Monero far more efficient when sending medium or large amounts.

Finally, Monero has the network effect of all its privacy features being supported by all its merchants and wallet providers. If CloakCoin is ever accepted by a service, it is likely they will not support all of CloakCoin's privacy features.

Overall, CloakCoin (CLOAK) uses privacy mechanisms that are inferior to Monero in essentially every way.


Which activity metrics are most highly correlated with transaction volume?

Thanks to the privacy offered by Monero it is hard to know the purpose of most transactions.

It is likely that none of the above suggestions are currently the largest driver in transaction volume.

Based on trading volumes and the number of Monero accepting merchants today, a large percentage of transactions are likely related to trading. This can include:

Sending Monero to exchanges
Sending Monero from exchanges to web wallets, CLI wallets and paper wallets

Trading volume are often the highest around the times of major releases (LMDB release) and major events (ETH/ETH drama when immutability was often discussed).

In addition to major releases, I would expect transaction volume to show big spikes when major privacy focused merchants accept Monero. If many Bitcoin users became aware of xmr.to as a private way to pay Bitcoin merchants anonymously I would expect an immediate spike in Monero transaction volume.

If more trading moves to P2P exchanges such as Bitsquare where XMR is traded on chain (instead of off chain at centralized exchanges) transaction volume should increase substantially.


It is partially possible and will probably be implemented in the future. An interesting post was created about this and a member of the Monero Research Lab stated the following 8 hours ago:

[...]
Currently, the only way to prove your balance to an auditor is to give them your view secret key along with the set of signed key images (i.e. ingredients needed for cold signing using watch-only wallet). This approach has a serious drawback that the auditor knows (and continues to know in the future) about all the funds you received and when those funds (whose key images are disclosed) get spent. If the auditor (i.e. a government) does this for a lot of users, they will acquire a considerable amount of information about which output belongs to who and which is the real spend in each ring signature. This is clearly detrimental to everyone's privacy.
A new feature called "tx proof" (https://github.com/monero-project/monero/pull/2487) was designed to partially address the above issue; instead of disclosing your view key to the auditor, for a given transaction where you received some funds, you can generate a cryptographic proof that proves your having received funds in that tx, and then you can give the proof to the auditor. Importantly, this can be done on a per-tx basis, so the auditor will have no way of knowing the rest of your transactions.
An idea that occurred to me just now inspired by this post, is to augment the above tx proof with the signed key image, so that the auditor can also check if the fund received in the given tx is spent or not. This way, you can easily prove to the auditor that you have at least X amount of funds in your wallet. The major advantage compared to the existing method (giving out the entire key image set) is that you don't need to reveal the entirety of your balance to the auditor.
-/u/stoffu


With a Churn: does it increase privacy more to do 1 TX with RingSize14 or 2 TX with RingSize7 or is it exactly the same?

If you churn twice, and every input you reference came from transactions that used ring size 7 (where one of those transactions would have been your first churn transaction), then your anonymity set would be 7^2 = 49.

You're therefore far better off making two transactions.

If you'd made 3 transactions, your anonymity set would increase fo 7^3 = 343. If some of the transactions referenced had used a ring size lower than 7, then your anonymity set would be smaller. To determine the anonymity set size when ring sizes are not uniform, you'd have to add together the tree of possible outputs that would be formed by the references to past transactions by your transaction.

Note that this technique relies on churn transactions not being easily detectable on the blockchain. If you churned 10 times in a row in quick succession, this might be possible to detect. Churning is a matter of ongoing research at the Monero Research Lab.


Differences between Masari web wallet and Mymonero

Disclaimer: I am the creator of this new wallet

When you use MyMonero, your private view is sent to the server (with your public address), but not the private spend keys.
It means the server is able so see your balance(EDIT: the server is able to see the incomming amounts, not the outgoing amounts. It means the balance will be off), and the server is precomputing everything for your browser and your browser is doing the final work : checking that the tx are really yours basically.

In the wallet i'm working on with the Masari team nothing is sent to the server.
The server is only here to send you the blockchain and that is it. All the decryption is done on your browser. Yes it's using more resources of your computer, but we will never be able to even check your balance.
I'm working on improving the performance, but they are currently more than reasonable. In theory, the website could even connect directly to a RPC daemon (not done due to performance issues, but we could and our first prototype did that).

If you need more clarification, i will follow this post and i'm also available on the main masari discord or reddit/r/masari

Gnock


Failed to update txpool transaction metadata on local Monero daemon

This error is not a problem. While it might happen for several reasons, the most likely is benign: monerod attempted to relay a transaction from the txpool to other peers, but then failed to record the relay time as the transaction was not in the txpool. This happens when the transaction is taken off the txpool when it's mined in a block at the same time it gets relayed.

See https://github.com/monero-project/monero/pull/2971/files for a fix (which doesn't change the way it works, just makes sure there's no error when it's the benign case).


I am a little confused about how I use the block template... Basically what are the function calls I need to perform in order to mine a block template so I can then call submit block.

A block template is just that, a template for a block that a miner can perform work on (repeated hashing) to try and find a solution (a hash that meets the network difficulty) and then submit to the network.
So first a miner obtains a block template, typically using the daemon method get_block_template.
Next the miner relatedly updates the nonce space1 and performs a hash2 (using the RandomX hash function). If / when the resulting hash (which is just a number) meets the network difficulty, they can submit the block to the network using the daemon method submit_block.
Lastly, peer nodes validate that any proposed blocks hash meets the network difficulty. If no other miner submits a valid block (or chain of blocks) with more work done, after 60 blocks the miner gets paid the reward.
1 the nonce space can be any combination of the nonce field in the block header or in any reserved space of the miner transaction.
2 what actually gets hashed is a block hashing blob, which is a concatenation of the block header, a merkle root hash of the blocks transactions and a varint of the count of txs (src). A miner can either directly use the returned block hashing blob from get_block_template or they can construct the block hashing blob themselves using the block template blob. The latter is required if the miner is changing the reserved space of the miner tx.


Mining on an old Radeon 5830 with xmr-stak

For Ubuntu 16.04 LTS and above, the AMD Catalyst or fglrx driver (compatible with your card) is no longer supported by AMD, or in Ubuntu. The AMDGPU-PRO and AMD Blockchain BETA driver aren´t compatible with your card, finally, the opensource ones can´t be used for mining due to OpenCL.

So, one solution could be to try installing the fglrx driver on your system. Here the reference from Ubuntu WIKI.


Level of privacy is a sliding scale and goes far beyond just Monero usage. E.g. you immediately lose some privacy by using a KYC exchange (as per your first step), which has nothing to do with the privacy features you get from Monero. For a higher level of privacy than what you have outlined, buy using a decentralized exchange (such as Bisq for example). Every centralized service you use, you lose some level of privacy.

If you are concerned with traffic analysis (from network providers for example), additionally use tor/i2p. This is because, for some people, they consider even being identified as simply using Monero is an unacceptable privacy loss.

All this said, the path you have outlined is certainly considerably more private than just using Bitcoin. The moment your Bitcoin are converted to Monero, it becomes considerably harder to trace.

It all boils down to your own acceptable risk profile.


What will happen to my wallet during next hard fork?

This answer is assuming you are on any 0.9.x version (lower versions would already have been booted off in the previous hardfork) currently. Note that 0.10 is going to be released soon. In general it is advised to use the latest binaries, because they contain bugfixes and new features.

  What will happen (if anything) to my actual wallet during this hardfork update?

Nothing basically. The only (minor) change is that it will enforce coinbase transactions to be split in denominations. See line 123 of the dev logs.

  Will it change address?

No. Addresses will never change during a fork.

  Do I need to do something to preserve/transfer my balance?

No coins have to be moved. Thus, to answer you question, no you don't have to do anything.


How can I achieve over 1 million hash rates with minergate?

First of all: Please avoid Minergate, since they are stealing some of your hash rate.

You will probably never be able to achieve 1MH/s on Cryptonight with a single machine, but multiple mining rigs or a botnet with dozens of hijacked machines mining into your account. But better avoid that, too.


Monero's initial sync of a full node takes up to few days depending on your internet connectivity and also your hardware, which has to verify all synced blocks.

When you loose your internet connection, close your wallet, switch off your device, for obvious reasons your wallet will not be syncing new blocks. But after you start it again, it will resume syncing from its last position, so only blocks you missed in the meantime have to be synced with the network of nodes and verified by your wallet / daemon.

If it starts syncing from scratch after being fully synced, either your blockchain data got deleted / corrupted on your drive or it is a bug and you should report it on GitHub or discuss in the IRC / Telegram chats how to get it solved.