How do full nodes vs miners secure the network differently?

If I run a full node I am supposedly contributing to network security by keeping a copy of the blockchain

That's right, but by running a node, you're most importantly securing yourself. I will get back to this statement further down.
The network doesn't really need infinite nodes for security, but just enough so that TX-data can propagate fast enough to all corners of the network. A small number of strategic nodes with big bandwidth could achieve this. There must be some redundancy to prevent a scenario where adversary could take down some % of them and cause trouble for part of the network. These nodes will belong to big services, exchanges, pools and enthusiasts.
Smaller nodes surely help by reducing the load on existing nodes. Anyway, it's not an easy task to map nodes and determine the topology, and you don't really know the capacity of random nodes you connect to.

If I mine (via pool or solo) I contribute to the network through verification of blocks

You verify blocks by running a node, not by mining. Mining is the process of producing a valid block. Nodes do the final verification. By solo mining, you're also running a node and thus contributing to network verification of blocks. By pool mining, the pool is running a node so you're not really contributing directly. You might be contributing indirectly, since the pool will have a cash-flow from users which will enable it to upgrade internet speed and run a stronger node (or a whole network of them).
The security is really achieved by nodes and miners together.

Nodes check validity of TX-es, i.e., that they come with a valid signature otherwise anyone could spend your funds. They "define" the rules and that the double-spend problem will be solved by delegating POW to miners.
Miners provide the POW, and give resilience to the network. Thanks to them, nodes can tell what came first and it's very hard to cancel a TX once it made its way into a block. Miners help achieve both security and immutability.

Note that Bitcoin has another kind of nodes which don't check blocks for validity. Those are "dumb nodes" which only relay data. They don't really secure anything, and rely on other nodes giving them good data. I'd just title these "network relays" instead of nodes to prevent confusion.
To understand better all of this, we must understand how the whole system works.
So, how does a decentralized cryptocurrency work?
A blockchain is a shared database to which records can only be added. When you run a node, you're saying "I will accept only entries to my copy of the blockchain which followed these rules". That's all. With a node, you define what will be the currency you accept and what those rules mean. By having lots of others following the same rules, an economic ecosystem where participants can freely transact with each other is created. If someone changes the rules in a way that's not compatible with the rest, then he can no longer transact with the same people, but if there are others using the new rules he can transact with them instead - another currency is created. Depending on context, the split can be called a hard fork (when 2 different coins have a shared history). If you don't run a node, but use a light wallet, then you delegate the choice of rules to the node operator. If you don't agree, you should change the service.
The main thing which enabled the first decentralized cryptocurrency was the way it used POW (proof-of-work) to solve the double-spend problem without having to rely on some trusted authority. The POW is what enables your node to tell the order of transactions and ensures that history can't be changed or re-written. I.e., I can't take back my Bitcoins once I sent them to you and I can't spend them again at another place since the whole network sees them as spent.
So, what are the rules? Something like:

A blockchain is a collection of blocks

Every block is a collection of transactions + the block header. Every block must reference the previous one, making a "chain".

A transaction is nothing but a statement like "I hereby prove I have rights to spend X,Y,Z outputs, and create A,B,C outputs of the same total amount. For this I offer a fee of M"

A block can have any number of transactions

Once transactions are aggregated into a block, it must be "hashed". A hash is a way of getting an one-way result from some data. Like, if you hash "abc" you get "ba7816..." and if you hash "abd" you get "a52d15..", try it out here. The result looks random, and if it's a good hash function it will always look random. Point is, you can't know what the hash of "abc" will be, without actually performing the hash computation and seeing what you get. To hash a block, instead of using "abc" as in the example, you feed the entire data of the block and see what you get. If what you get matches a pre-determined pattern, it will be a valid hash. Thing is, what if it's not? Then, you need to change just a little bit of data (there's a "slot" for this, called a nonce) in the block, and try again. The process is repeated until a matching hash is found and only then the block will be valid. The pattern can be more or less restrictive. An "easy" pattern would be to get the first letters of a hash to be "aa...", this would take only a few attempts to match. When we increase difficulty it means that the pattern is harder and harder to guess. Like increasing the number of numbers from your lottery ticket you need to get right to win.

Every block will have a special, "coinbase" transaction which creates new coins according to pre-determined schedule agreed by the rules. The one who makes the block, gets to choose where these new coins (and fees) will go to. (Collecting TX-es in a block is done by either solo miners or pool operators)

A block will only be accepted by nodes if it it's following all the rules and comes with a valid POW (this part is done by miners). Miners take the block template (basically, entire block which is only missing the valid hash), and change just that one small bit (nonce) to keep "rolling" the hashes until a match is found. If anything else changes (transaction, reference to previous block, coinbase address) the hash will also change. This is what makes it secure, because changing anything in the block would make it invalid because hash would change in an unpredictable way.

In case there are 2 different blocks arriving at the same time the one with a bigger difficulty will "win" and kick out the other one, and everyone will build upon the accepted one. If a part of the network builds on one, and other part on the other then the competing chains could be 2 blocks deep. The biggest cumulative "work" wins and kicks the alternative chain. This happens occasionally due to network propagation times and is called a re-org. Note that both chains must be following the same rules otherwise nodes would reject it straight-away. The POW is there just to make sure nobody can cheat on the ordering of valid transactions. For example to replace 10 blocks and re-arrange order of transactions or simply cancel some, you'd need to re-do all the hashes for all 10 of them before someone else adds the 11-th one. Thing is, you'd need 10x more computing power than the entire network to do it and that makes it an impossible task. Even if you manage it, you can only reorder or cancel transactions. You can't ever cheat the rules agreed by the nodes. A miner is always working within those rules.


Thanks to Jolly Mort's comment, I can answer this question now.

Running it with monerod --log-level=1 is much more verbose in both terminal and the log file at C:\ProgramData\bitmonero\bitmonero.log

The logs explain the process a bit more in depth:
2017-Jan-02 04:24:09.636702 Migrating blockchain from DB version 0 to 1 - this may take a while:
2017-Jan-02 04:24:09.636702 updating blocks, hf_versions, outputs, txs, and spent_keys tables...
2017-Jan-02 04:24:09.636702 Total number of blocks: 1142544
2017-Jan-02 04:24:09.636702 block migration will update block_heights, block_info, and hf_versions...
2017-Jan-02 04:24:09.636702 migrating block_heights:
2017-Jan-02 04:24:09.636702   block_heights already migrated
2017-Jan-02 04:24:09.636702 migrating block info:
2017-Jan-02 04:24:09.636702   block_info already migrated
2017-Jan-02 04:24:09.636702 migrating hf_versions:
2017-Jan-02 04:24:09.636702   hf_versions already migrated
2017-Jan-02 04:24:09.636702 deleting old indices:
2017-Jan-02 04:24:09.636702   old indices already deleted
2017-Jan-02 04:24:09.636702 migrating txs and outputs:
2017-Jan-02 04:24:09.652302 [check_and_resize_for_batch] checking DB size
2017-Jan-02 04:24:09.652302 [get_estimated_batch_size] m_height: 1142544  block_start: 1142044  block_stop: 1142543
2017-Jan-02 04:24:09.823902 average block size across recent 500 blocks: 5814
2017-Jan-02 04:24:09.823902 estimated average block size for batch: 5814
2017-Jan-02 04:24:09.823902 calculated batch size: 130815000
2017-Jan-02 04:24:09.823902 increase size: 536870912
2017-Jan-02 04:24:09.823902 DB map size:     12884901888
2017-Jan-02 04:24:09.823902 Space used:      10393010176
2017-Jan-02 04:24:09.839502 Space remaining: 2491891712
2017-Jan-02 04:24:09.839502 Size threshold:  130815000
2017-Jan-02 04:24:09.855102 Percent used: 0.8066  Percent threshold: 0.8000

At the bottom of the terminal, though not in the log file, it displays 827000 / 1142544 which I am assuming is the number of blocks migrated out of the total number of blocks in my database. This is exactly what I was looking for and it means that the migration process is much faster for me than trying to sync the blockchain all over again. I can see it updating and it's currently at 830000 / 1142544.

It looks something like this:

Side note: If you shut down by pressing Ctrl+c and then X out the window, it will say
2017-Jan-02 04:48:05.138644 [node] Stop signal sent
2017-Jan-02 04:56:25.103922 Got control signal 2. Exiting without saving...

Ignore this as it does appear to save and resume where it left off. I've tested and confirmed that this is the case.

Edit: This took somewhere under two days to complete (I didn't pay attention to the exact time, which could have been a day and a half) and my blockchain data was about 102 days behind the ledger after migrating. As of today, the ledger has a total of over 991 days on it. So I'm guessing this was faster in my case than synchronizing the entire blockchain. I'm on a 2.10Ghz laptop running Win64 with 4GB RAM and, perhaps most relevant, HDD (specs) not SSD.

Edit 2: It may be better to just download the blockchain again after updating because it eventually got stuck on a blockchain around 23 days behind with a bunch of errors that it just would not get past for some reason. It ended up costing me a lot more time than it was worth.


If I wanted to run a Monero node would I be able to limit the number of inbound connections?

monerod currently can only be set to limit outgoing connections with the parameter --out-peers where the default is 8.

So if you setup your node to be reachable for the public, you can't limit incoming connections. However, you could use a firewall like iptables to limit incoming connections on your public port.


Does anyone know what this message means

You are stuck at the height of the most recent fork.  It appears you have not upgraded to v.0.11.0.0 or after.  Please download new binaries from https://getmonero.org/downloads/.


Monero was represented by the incredible lawyers at the Software Freedom Law Center, completely pro bono. They dealt with the Moneero counsel and indicated that we were all ready for a fight. Shortly thereafter Moneero closed up shop, much to our great collective dismay:-P


Solo mining Monero without downloading blockchain

No, definetley not worth the time required to set them up for solo mining, if that's even possible. If it is possible, you'll probably never win a block.

As for pool mining, I guess it depends on the hashrate you can get out of one board but for comparison my i7 does about 90H/s, where a single 1070 will do about 500-600H/s using less juice. If there is software for an ARM board to do pool mining, and if you connect them all to the same address I'd say you'd probably be able to make a very small withdrawal every couple of days if you choose a pool with a low withdrawal limit.

Even so, considering the time spend setting it up you'd be better of mowing your next doors neighboor's lawn once a month for some pocket money and wouldn't surprise me if you'd be making a more money for a LOT less time.


Remote peers and mining question with playground network

the nodes should have been running isolated from the outside world

What you are describing is called a private network. See this answer which includes a link describing describing how to run a private testnet network. The key parameters to use are --add-exclusive-node ... and --hide-my-port when starting each of your nodes, as this ensures your nodes only connect to each other and do not get announced.

So from the information you provided in the question, it appears you are not actually running a private network. This is why #1, you have received a peer list from a remote node and #2, someone else on the network being used has mined a block, not on your node, but on the their node and relayed to the connected network.

Lastly, when running your own private network, #3, no it is not imperative to run as stagenet. It is certainly more common to run a private testnet.


How long do I have to wait for monero-wallet-cli to be synchronized again?

If you use exit in simplewallet the last refreshed block will be saved in the wallet cache, i.e., the wallet's memory. Thus, the next time you will refresh the wallet, it will start refreshing from the last block it has saved. In addition, in simplewallet you can find, and reiterating what mwdddgcs said:

  Always use "exit" command when closing simplewallet to save current session's state. Otherwise, you will possibly need to synchronize your wallet again. Your wallet key is NOT under risk anyway.

Autorefresh simply refreshes the wallet automatically (if it is opened) when the daemon retrieves a new block (or every few blocks). Autorefresh is set to 1 for new wallets, i.e., wallets that were created after 0.9.4 was released. For wallets that were created before 0.9.4 was released, you have to set autorefresh to 1 manually with the following command:

set auto-refresh 1

  if yes can i somehow see the progress?

Simplewallet depicts the process in numbers. That is, it will state 1100000/1116137 if it has 16137 more blocks to go.


Can the expected reward from the block template differ from a actual one after mining?

1) So long as you don't edit the block template returned (i.e. you don't add a load more data or change the transactions included), expected_reward is what you would receive if you mined a block based on that template.

If you added or removed transactions, the fees collected would obviously change. If you changed the overall size of the block (added more data to extra for example), the reward calculation could be affected (e.g. the penalty fee could kick-in).

2) The links you referenced are both outdated (2017). Please see this answer, which references newer information.


Yes, it's less secure because it's 128bits of entropy in the 13-word seed vs 256bits of entropy in the 25-word seed. However, it's considered safe enough as it would again take an impossible* amount of time to generate a collision.

The process for mymonero is:
mnemonic -> seed -> private spend & private view keys

The process for simplewallet is:
mnemonic -> seed -> private spend key -> private view key

Technical details on the implementation can be found here, at the bottom of the page.

Note that the mnemonics are not part of the protocol. They're just a way to conveniently generate the actual cryptographic keys used at the protocol level (private spend and private view key).

Considering that you can always restore a wallet from the actual keys, you are never locked into any system in particular.

And yes, it is the same wordset.

*A note regarding collisions, quoting Luigi

  Note that generating random collisions of 128 bit values is well
  within the realm of "possible" nowadays. The key is that you're still
  mostly fine, as generating a collision (birthday paradox) isn't very
  useful for finding actual accounts with value (unless there are a
  "lot" of existing accounts--even then, it's very unlikely someone
  finds yours, just more likely they find someone's.

As far as the history of decision is concerned, here's a quote from fluffypony:

  When we first decided to create a mnemonic system the spec we came up
  with was: take the seed from the mnemonic, hash it for the spend key,
  hash it twice for the view key. Somewhere during the simplewallet
  implementation we forgot about that, and just used the mnemonic seed
  as the spendkey directly.

  This proved to be a blessing in disguise, though, as we'd not realized
  that people might want to retrieve their seed. Using our original
  design this wouldn't have been possible, as we didn't store the seed
  in the wallet file.

  Much later on when we were creating MyMonero (a different group of
  developers, I'm the only common link between the two) we decided that
  a 13 word seed would be much easier for people to remember, but
  because we wanted it to match simplewallet's implementation we made
  sure that we followed the spec as it was originally.

  At some point in the future we'll add support in the command-line
  wallet for four types of derivation and let advanced users choose
  derivations with a command-line switch:

  short mnemonic, spendkey is seed

  short mnemonic, spendkey is hashed seed (MyMonero)

  long mnemonic, spendkey is seed (current simplewallet)

  long mnemonic, spendkey is hashed seed


Calculating the circulating supply using daemon RPC

There is the get_coinbase_tx_sum RPC call which takes height and count parameters, and returns how many moneros were created between block height and block height + count.

So by setting height to zero and count to the current block height, you get the current money supply (the daemon might take some time to compute everything at once though).


How can I build the fastest mining XMR rig?

In addition to the answer provided, just one note on this:

  I did get the monerod software running but will I get a decent
  hashrate with the the AMD cards? I was getting like 40 with my Zotac
  Amp Extreme 980ti which is just atrocious.

This is because the monerod is using only the CPU, as far as I'm aware. For GPU, there is dedicated mining software like Wolf's, Claymore, or sgminer-gm.

Once set up, please use one of the smaller pools to help decentralize mining. Also, feel free to ask for help on IRC channel #monero-mining on freenode, or on Monero mining sub-Reddit.


When will Kovri be launched (approximately)?

Alpha version should be presented at DefCon, so 9 - 12 August.

Edit:
alpha release on August the 1st
Workshop at defcon on August the 11th.

Source: github issue


CryptoNight detail. Why this kind of multiplication?

Choices made date back to the original goal of having a hash function that favored modern CPUs (vs GPU/ASIC/FPGAs). Requiring a scratchpad of 2MB fits nicely into a modern CPU L3 cache and thus the required read and writes from that cache are fast. The choice for the 64 bit multiply is again that the operation is fast on modern CPUs.

Of course, history has shown us that todays GPUs can work comfortably with the hashing algorithm, and with enough effort (and money) even ASICs can be built to run as fast or faster - hence the recent tweaks to the algorithm which again, chose operations that are fast/easy on CPUs but harder to (re)implement in ASICs.


Does Monero/the CryptoNote Protocol support multi signature wallets?

Monero does not support multisig at the moment. It will at some point, probably not very long after RingCT is merged, since that work relies on RingCT building blocks.

Cryptonote itself does not support multisig either, but Bytecoin (Cryptonote's first actual currency) does support it for mixin 0 (ie, without ring signatures involving other outputs). Monero's implementation will support ring signatures (which is the point of Cryptonote currencies).


What is the deterministic hash to EC function used to construct the key image?

Looking at the code, we can see how it's generated.

void crypto_ops::generate_key_image(const public_key &pub, const secret_key &sec, key_image &image) {
    ge_p3 point;
    ge_p2 point2;
    assert(sc_check(&sec) == 0);
    hash_to_ec(pub, point);
    ge_scalarmult(&point2, &sec, &point);
    ge_tobytes(&image, &point2);
  }

The hash_to_ec function is called to hash pub (which is your P) into point, giving us your H(P). Then, scalar multiplication is performed and result passed into point2, which would be your x*H(P). Some transfromation ge_tobytes is applied and the result is passed into image which is your I.

I'm not sure what this ge_tobytes transformation does, though. It could be just changing the format of I in memory. Implementation specific, I suppose.

The hash_to_ec function is presented below.

static void hash_to_ec(const public_key &key, ge_p3 &res) {
    hash h;
    ge_p2 point;
    ge_p1p1 point2;
    cn_fast_hash(std::addressof(key), sizeof(public_key), h);
    ge_fromfe_frombytes_vartime(&point, reinterpret_cast<const unsigned char *>(&h));
    ge_mul8(&point2, &point);
    ge_p1p1_to_p3(&res, &point2);
  }

We see that the cn_fast_hash function is called, which would be the Keccak hash function.
After getting the hash h, it is passed through some functions, which I suspect perform scalar multiplication of h with something, but my understanding stops here. This ge_fromfe_frombytes_vartime might be of interest as Shen Noether did a dedicated write-up on it. Also, here we see the importance of using a secure hash function for the key images. Apparently, to do this something after the Keccak is quite important.

Shen Noether's implementation in Python could provide some insights as well, but I'm not sure if it's up to date.


You have to choose between having a little chance to find your own block with a high reward if you mine on your own, or having a high chance of finding a block but with a low reward as it is shared if you mine in a pool.

This being said, if your objective is to make "profit" I would use a pool.


This issue is a known problem. A solution is discussed here: https://github.com/monero-project/monero/issues/1673.
A solution hasn't been created yet but the general plan is, as you suggested, to use some kind of probability distrubtion to selected inputs. In  the edit in the first message of the above github issue, olarks mentions he is using data from Bitcoin to get a better idea of how transaction are distributed, because we lack that kind of data for Monero.

edit based on comments: As pointed out in the comment it appears that this has been implemented.
First, it guarentees 1/4 of the fake outputs (min of 1) are selected from a pool of recent outputs using a triangle distribution (code comments says equiprobable distribution, but the code doesn't reflect this).
Second, older outputs are then selected from the whole pool of outputs using a triangle distribution


This python script should work fine with python2.

If you want to use it with python3, you will have to increase the recursion limit (e.g. sys.setrecursionlimit(2000)), and some code fixes might be necessary...


Required confirmations before newly received Monero can be spent

Received monero can be respent after 10 blocks (see CRYPTONOTE_DEFAULT_TX_SPENDABLE_AGE). At two minutes a block targetted, that means approximately 20 minutes.


How does one go about setting up a mining pool?

The Monerodo OS from gingeropolous is a customized version of Ubuntu that includes Monero Core, Monero Pool Server, Nvidia mining software, various CPU mining software, and the MiniNodo Wallet server, already preinstalled and is easily configured with a simple text menu interface.

Step by step Monerodo OS instructions

Alternatively this CryptoNote pool mining software is free and open source

git clone https://github.com/zone117x/node-cryptonote-pool.git pool
cd pool
npm update

Configuration instructions can be found here


What does this p2p info mean from the daemon log?

Not sure random debug log questions are on topic for stack exchange, but...

Field 2 is the thread logging this message.

Hop is the (untrusted) number of peers forwarding the object.

COMMAND_TIMED_SYNC is one of the P2P traffic messages.


There is no RPC to create an address.
If there would be one, it would be one that would also "forget" the current one, so it would have limited usefulness.

If you want to have your own code to create addresses, you can either take code from wallet2.cpp and the cryptonote libraries, or use the Javascript version as a base: https://moneroaddress.org/


Running a Monero node from a home PC with Broadband unlimited download over TOR. Doable?

Yes. Given your computer spec/storage-space, you will probably want to run it as a pruned node though.
Yes. Instructions.
Regardless of Tor usage or not, you decide if others can connect to your node. Tor is not a firewall.
Yes. You can start the daemon with flags --no-igd --hide-my-port --in-peers 0 (these can also be applied in the GUI via daemon startup flags in the settings).
"best" is subjective and not really a suitable question for StackExchange. You can use either a Trezor or Ledger.


Hello and welcome to mining. Since this is monero-based Q & A i will try to guide you abut monero mining.

1) Indeed, You can use that Rx 560 for mining xmr and zec. I can tell you that you will get around 300-400H in xmr, and not sure about zec, would be like something between 80-130 sols.

2) There is not a card capable of doing 5000H in xmr. Instead, you can get about 15 Rx 560s to achieve that hasharate. That is, building minining rigs (2 rigs of 8 GPUs each for example).

You can get your Rx 560 into mining, but dont expect high rewards. Instead, use that card to learn how to mine properly. Once you manage to max out the perfomance of that card, you can add more later. Take it as a hobbie at the beginning, if you end up liking it so much, get serious and build a rig. You got the basics somehow covered, that is, mining rewards depend of variables like difficulty, luck, latency to the pool you are mining, and so on.

4) You can check out the Monero reddit, at the right sidebar you will find some wallet options. As for mining software, there is xmr-stak, claymore cryptonote (most popular).

Feel free to navigate the stackexchange to get more info about Monero.

P.S. If you want to mine zec, you should consider getting Nvidia cards, the big Rx brothers (x70-x80) or even a R9 390 which is a very nice card (but really expensive and power hungry). I hope this helps a bit. Kind regards...


Is there a Blockchain-like hub for Monero to manage wallets with an easy interface?

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


How to compute ringct multisignature key images? (Disambiguation of MRL005)

1 & 2 - Pe | Pj is concatenation of the keys.
3 - Keccak, although as @knaccc comments, H() is not simply a hash function, it's hash-to-point, so should read Hp().


Where can I download the pruned Monero blockchain that is 25+ GB instead of the full blockchain

It helps to better understand first how pruning works.

When pruning, your blockchain gets split into stripes. These start from a random point chosen when you first decide to prune. If you are pruning, only your pruning stripes get pruned (non-essential data gets removed after validation). The non-pruning stripes will have full data. So every node that prunes, their stripes of unpruned data will be different to other pruned nodes, based on the random starting point mentioned earlier. Your pruned node still participates on the network sharing blocks to other nodes that need to sync - but you are obviously only able to share blocks that you have not pruned.

Armed with this information, you can see it would be extremely harmful to the network if every node had the exact same stripes of pruned/unpruned data. This is why it makes no sense to have a pruned blockchain file available for downloading.

Also, when you run a node, you want your node to have fully validated every block. A pruned node still does this - it only prunes data for blocks that fall into a pruned stripe after it has validated it. This is another reason why you wouldn't want to download a pruned blockchain file - you'd have no way to validate it.

I'll also add, the full blockchain.raw download file is pretty much redundant nowadays anyway. The syncing speed of the blockchain directly from the daemon, on the network, has been greatly improved over the years.

To wrap up, if you wish to run a pruned node, start the daemon with --prune-blockchain. It will download and validate every block from the network but not save everything to disk. It will continue to participate on the network in sharing blocks it has not pruned to other nodes.


There are 2 different start-up options:

--daemon-address arg                Use daemon instance at <host>:<port>
--daemon-host arg                   Use daemon instance at host <arg> instead

You're using the one for hostname so it's expecting localhost:18080 or similar.

To make it recognize the IP, use the --daemon-address option, like:

./monero-wallet-gui --daemon-address 127.0.0.1:18080


Beginner: Monero mining in a rented student bedroom with free electricity

I would suggest to take a look at the CoinFoundry Pool. It's a new pool based in Germany that will give you a very good starting point so that you understand how to start mining.

Also the support is good there and they have a very good "Get Started" section: go here and select the "Get Started" tab. The fees are also very low.

If you provide the following info

Operating system (you use)
Mining hardware (for a laptop that would be 'CPU')
Hashpower (for a laptop 'Standard')
Wallet (you need one so that coins will be send there)

they will pre-generate the configuration file for you for the appropriate mining software and you can download the config-file and the software directly on their website.

They support a lot of coins. You can mine Monero but that will in no way be profitable because you need a really high hash rate nowadays. If you still want to do it, you of course can.

If you want to mine something that will give you a visible balance, you could go with Electroneum. It's also based on the CryptoNote protocol like Monero, so you kind of support the base protocol :)


Is there any pre build nvidia - cpu miner for Centos

If you don't have root access on the server, sounds sketchy to me.


The nonce is a 32 bit counter in the hashed data, situated at offset 39. The miner will increment that nonce until the hash of the resulting data is less than the requested target (from a pool, that target will be well below the network difficulty). In the miner's reply to the pool, the nonce is the value which leads to a hash below target.

The result is the hash of the original data, modified by the nonce. While you'd expect this is redundant, since the pool can calculate the hash given the initial data and the nonce returned by the miner, pools typically only check some of the results miners supply, for efficiency reasons. Thus, sometimes the pool checks the claimed hash corresponds to the claimed result, and sometimes not.


What is the default behavior of monerod concerning the --max-concurrency flag?

By default, the value will be set to the hardware concurrency reported by boost. This is usually the number of CPU "threads" available. If this returns 0, no extra worker threads will be used (not sure if that got tested). I do not think monero logs what Boost claims, but you can use that function yourself in a test program:

http://www.boost.org/doc/libs/1_66_0/doc/html/thread/thread_management.html#thread.thread_management.thread.hardware_concurrency

Monero code needs threads, and will not function if threading is not available. This setting is designed for short lived CPU intensive operations such as signature verification, etc.


Monero GUI app v0.14.0 not showing mnemonic seed and secret keys may have 'filler' values

The mnemonic field is empty because your Ledger 24 word mnemonic seed (which was generated upon initializing the Ledger device and is essentially your Monero seed for a Ledger Monero wallet) is retained on the device. Similarly, the private spend key (note that the 24 word Ledger mnemonic seed is simply a representation in words of your private spend key) and the private view key values are also not obtainable in the GUI.

In sum, essentially, the notion of a hardware device is to provide security by retaining your private spend key (the 24 word mnemonic seed) on the device. Therefore, the GUI cannot show your keys or mnemonic seed.

  I found this out when I pasted the see into the 'https://xmr.llcoins.net' website.

Entering your 24 word Ledger mnemonic seed into your system basically renders the security provided by the hardware device obsolete.


Failed to start Monero Full Node : Ubuntu 18 > Boron Butterfly

walletnotify=/mnt/monero/notifysitestx.sh %s
  blocknotify=/mnt/monero/notifysitesblock.sh %s

There are no options walletnotify or blocknotify, you probably want block-notify.

See monerod --help for all the available options and syntax.

  Running the daemon with the --config flag I get...

There is no option called --config, it's --config-file.

  PIDFile=/run/monero/monerod.pid

Have you created the directory /run/monero/ though?

  –pidfile /run/monero/monerod.pid

The parameter is wrong. It should be --pidfile /run/monero/monerod.pid. Note the double hyphen --. You make this same mistake with other parameters also.

  I am not binding p2p for now, only RPC

p2p automatically binds.

  Compiling Monero alone on a box, I had to up it to 8GB of RAM.

Monero can be compiled on a Raspberry Pi, so if you needed to increase your RAM to 8GB, you must have been seriously exhausting the RAM on other things.

UPDATE

After you rewriting your question, you now specify PIDFile=... in the service file, but you removed the parameter --pidfile .... So you're telling systemd there will be a PID file, but don't tell monerod where to create it.


You can check this block explorer (according to this reddit post) :

http://xmrtestbbzl275vy.onion/

tor2web proxy: http://xmrtestbbzl275vy.onion.link/


Shamir's Secret Sharing for cold storage of a Monero wallet

There is no support for SSS in simplewallet. This would require some amount of new modexp code to be added (unless a variant of it can be made using EC cryptography, but I'm not aware of any).

So the best you can do is use a standalone SSS tool such as ssss (see http://point-at-infinity.org/ssss/). It may already be in your distribution's packages.

Example, with the words "shamir secret sharing":

$ ssss-split -t 2 -n 3
Generating shares using a (2,3) scheme with dynamic security level.
Enter the secret, at most 128 ASCII characters: Using a 168 bit security level.
1-b52fb8b2fc481023c708c25c798a45e349951e9af8
2-6191ac079ef7624a72ffce0da2372d6a24fe2e530c
3-d2045f94bf624c6d1e52ca3d14a3f512ffd8c19459

and:

$ ssss-combine -t 2
Enter 2 shares separated by newlines:
Share [1/2]: 2-6191ac079ef7624a72ffce0da2372d6a24fe2e530c
Share [2/2]: 3-d2045f94bf624c6d1e52ca3d14a3f512ffd8c19459
Resulting secret: shamir secret sharing

For more info, man ssss.


I have repaid XMR to OKEX trading platform for 3 months. I haven't arrived. Please help me

I cannot see how anyone on StackExchange can help you. You sent XMR to an exchange and that exchange is not crediting your exchange account. Only the exchange can help (if it's not a scam at least). If they are legit, they would either credit your account or refund you the money.


Its 2017-09 the monero blockchain is 21 GB, what proposed ways are there to reduce this size?

You can't simply discard all of the older parts of the blockchain, because you need to be able to verify that every new transaction you encounter references valid outputs created in the past.

The vast majority of a Monero transaction is the ring signature and output range proofs. It may be possible to prune these from the blockchain after a certain period of time, which would dramatically reduce the size of the blockchain.

This is a matter of ongoing research at the Monero Research Lab, which has two full time PhDs working on it. They will report back in the coming months.


I believe the documentation maybe slightly outdated / misleading. Looking at the source code, the vector of block hashes, block_ids, would have the hashes (in binary form) starting with your local most recent few block hashes and ending with the genesis block's hash (so in reverse chronological order). start_height is used to specify the height of your most recent block hash.

Let's assume you have the block hashes in block_ids of [B10, B9, B8, B0] and start_height set to the height of B10 (where Bn is the hash of block n).

If the remote node you are calling the method on has blocks B0 through B2000, it would return, in m_block_ids, the hashes for blocks B1010 through B10 and return start_height as the height of block hash B1010. As you see, only a maximum of 1000 hashes are returned (think of it like a page of hashes), so you can then call the method again but this time with block_ids of hashes [B1010, B0] and start_height as returned from the last call's response start_height (so the height of block hash B1010).

Note, this method, and the other .bin methods, are binary encoded, not JSON.


Its dificult to tell what is the longest, I personaly believe that should be the one created on the 4 september 2014 attack at block 122051, that block is hardcoded on the code so the daemon never sync for the orphan blockchain...

Still, I believe that some botnets keep mining on old block versions, thats the reason why on the daemon some times show messages pointing that we are X blocks haead

At the momment I dont think any explorer show that chains


Use payment ids/integrated wallets in web applications

I'm not clear about your web app, like will the user be sending XMR or receiving XMR?  I'm assuming they will be sending, so maybe just have one exchange address that your backend service uses and then assign payment Id to each user.  Then they don't have to see any address, just a payment Id. A stable exchange like Bittrix are up 24x7 and pretty secure.  A drawback is paying an extra fee if/when you move it to your own wallet. But if/when you cash out you need an exchange so keeping it there would be a wash then (fee wise).


Fix "[P2P0]WARNING: no two valid MoneroPulse DNS checkpoint records were received" in systemd file

Just add Environment=DNS_PUBLIC=tcp://1.1.1.1 before the ExecStart line.


What is the miners parameter for?

How many threads to use for dataset initialization. Also it signals the intent to use full memory mode (for fast mining).

  Can I start several processes that will use the rx_slow_hash function?

Of course.

  How exactly does verification work?

Verification is just that, verification. Supply the same data, height and seed hash, create the hash, does it equal the same as the hash you are verifying. For verifying, you are only creating one hash (per verification required); mining you are repeatedly creating lots of hashes until you find one that meets the current network difficulty (i.e. you are mining). So unless you are trying to perform lots of different verifications, miners=0 will be fine. This would then limit memory requirements to 256 MiB (light mode). If you need to do lots of fast verifications you can use miners=<number of processors> which will attempt to use full memory, 2080 MiB, fast mode.

  For example, I have one process in which I will run verification with rx_slow_hash function with miners=1. Will this process create a separate thread for verification or will execution be blocked until verification is completed?

It will create 1 thread for the dataset initialization. After initialization, your calling thread will block whilst creating the hash.


Could a DDoS attack on the hardcoded seed nodes bring down the Monero network?

It would not bring the monero network down. At most, it would prevent new nodes from adding to the network.

The seed nodes are "well known" nodes which act as the first port of call for newly setup nodes. Once a node is already in the network, it does not need the seed nodes. If a node stops and is then restarted after a delay, the list of known peers is kept in the p2pstate.bin file, so seed nodes are not needed either (though they are still contacted).

If a DDoS happens, new nodes still have the ability to connect to the Monero network from scratch with the --add-peer argument to monerod, eg:

./monerod --add-peer 1.2.3.4:18080


How to execute HTTP request to daemon's *.bin endpoint like http://localhost/getblocks.bin

Firstly, all of the .bin methods are binary methods (as the suffix alludes to). The input and output parameters are binary, serialized objects as defined in this file

These methods are generally for more specialized use cases. In almost all normal use cases, the JSON methods should suffice.

For getblocks.bin, there is some documentation here which details the input and output parameters.


Does the miner transaction (of a block reward) get sent to a miner's stealth address?

It is still a stealth address but the amount is not hidden.


Will Monero have wallet clients similar to SPV so that a fully validated node is less necessary?

The lightwallet by jwinterm is probably most similar thing to an SPV wallet so far https://getmonero.org/getting-started/choose

shen-noether is working on a mobile wallet that will connect to a remote node
https://hellomonero.com/tags/shen-noether

Using an SPV wallet can have privacy concerns because the node that you use to relay your transactions needs to be trusted not to log and correlate your IP address with your transaction activity. These concerns can be eliminated by connecting to your own full node. Tools such as Monerodo OS (http://nodebox.link/) should make this process easier.

A framework is in place to support SPV wallets and more wallets are now being developed by Exodus and others. More focus  may return to this area after RingCT is complete.


You'll get about ~10H/s in my experience.

I use https://github.com/tpruvot/cpuminer-multi

(You may need to switch to the ARM fork on the repo).
You should be able to compile it once then scp it to your devices.

Here's another thread that may be helpful:
Could I use a Raspberry Pi to mine Monero?

Also with this number of devices, you may want to add proxy:
https://github.com/xmrig/xmrig-proxy

Simplifies your management greatly.


Does the block effort matter when mining in a pool? How does it impact earnings?

The effort is just an educated guess based on the total pool hashrate.

At X Hashes/s, a block should be found in Y time.

I basically ignore it, its it a guess and not factual.


Fixed the issue.

Delete all your .sst files. Launch wallet, yes, erase and re-sync. Took 45 minutes.


What is the difference between Monero (XMR) and Ryo (RYO)?

History

Ryo is a fork of Sumokoin (SUMO), which itself is a fork of Monero (XMR).

Sumokoin (SUMO) launched with the following statement:

  Sumokoin is forked from the source code of Monero cryptocurreny, one of the most innovative digital coins which is well-known for security, privacy, untraceability and active development, therefore, naturally inheriting all of those great features, yet without the burden of its past.

Sumokoin (SUMO) launched following the initial release of the "An Empirical Analysis of Traceability in the Monero Blockchain" paper released on 13 April 2017. While this paper introduced a number of Monero privacy limitations, the majority of them were limited to pre-RingCT outputs, ones that Monero had not used in meaningful numbers since January 2017. Future transactions were subject to the "guess-newest" heuristic for some time after, but Sumokoin (SUMO) did not change the selection algorithm. Thus, the claim that the fork removes the "burden of [Monero's] past" is dubious, since there was no practical benefit to Sumokoin (SUMO) transactions at the time of launch.

According to the Ryo roadmap, the following occurred in June 2018:

  Sumokoin hardforked to ASIC friendly POW and Ryo continued on with the original chain.

Ryo forked following accusations that the Sumokoin (SUMO) team had printed additional funds for the founders than was publicly claimed. The Ryo team that resulted felt that the Sumokoin (SUMO) team was not knowledgeable enough to maintain a Monero fork.

Code Changes

Ryo began on a largely Monero codebase and merged a number of upstream features, including multisig, fluffy (compact) blocks, and bulletproofs.

Monero and Ryo use their own custom Proof of Work (PoW) algorithms.

Payment IDs

Monero has slowly been deprecating payment IDs, working on removing both forms completely and eventual subaddress adoption. Monero currently supports legacy payment IDs and short payment IDs. Ryo removed support for legacy payment IDs. Ryo and Monero automatically include a short payment ID in all transactions. Ryo developers argue that removing long payment IDs is good for privacy, which is true. However, it is incorrect to say that Ryo transactions are necessarily less identifiable as a result, since Ryo has fewer transactions.

I haven't found a good resource that reports the number of Ryo transactions per day, but I estimate there are less than 500. Monero typically has >4000, so there is a greater total number of other transactions that match various spend behaviors. Of course, users should reduce their exposure by avoiding payment IDs whenever possible.

Note that Monero and RYO now offer equal payment ID protections.

Ringsize

Monero uses ringsize 11. Ryo uses ringsize 25. Ryo proponents argue that larger ringsizes are better, which is strictly true. I have included a graph below indicating the proportion of rings that would be compromised (y-axis) if attackers had knowledge over a certain proportion of outputs (x-axis). Both cryptocurrencies provide essentially the same protection until 65% compromised. The larger ringsize protects similarly until about 82% compromised. This buffer of protection is useful.

However, it is simpler to have visibility over the same proportion of outputs for a smaller cryptocurrency than a larger one. Suppose I create 500 transactions in perpetuity on both Monero and Ryo, and I have no access to any other information. I would have visibility over about 500/(500+500) = 50% of Ryo outputs, while I would have visibility of only 500/(4000+500) = 11% of Monero outputs.

Put another way, let's compare the number of perpetual transactions I would need to have visibility over to compromise 1 ring per day. With Monero, I would need to create approximately 3100 transactions. With Ryo, I would need approximately 575. Ryo would need ringsize ~42 to provide the same protection as Monero against someone creating 3100 transactions.

Larger ringsizes may be better for privacy if you compare a small vs. large ringsize for a single network. However, large networks naturally have better protection from the other transactions and their entropy. Small cryptocurrencies need larger ringsizes to provide the same privacy level according to this one metric. There are many other metrics of assessing relative privacy levels, but this is one for a basic form of attack.

Relative Pool Information

The number of pool-related transactions do not scale proportionally to network size. Small networks have a higher proportion of pool-related transactions than large ones. While transactions paid to miners may partially scale, blocks mined don't scale the same way.

Public mining pools often provide a lot of public information that observers can use to have visibility over outputs. At the time of writing, https://ryo.miner.rocks controls ~60% of the hashrate, and they publish lists of blocks mined and transactions paid. Observers can use this information to construct a list of outputs that can only be spent by the pool, not by other network participants. Many Monero pools also publish this information, but the total impact of this information is lower for Monero since the mining pools are a smaller proportion of network activity.

Fees

Monero uses 3 main preset fee values. Ryo uses 1 main fee value. Single fees are better for privacy, but there are some usability tradeoffs when network congestion is high.

Transaction Structure

Ryo imposes some stricter transaction restrictions on the consensus layer in some cases, which prevents malicious or oblivious wallets from sending some types of revealing transactions.

Summary

Monero and Ryo are very similar, since they share most of the same code. Only a few parameters are changed between them. However, any changes to the code are relatively minor if the network is significantly smaller. Ryo has some strict improvements, but they need to weighed against Monero's larger network size. Comparing certain parameters in a vacuum without considering the wider network situation leads to false conclusions.


The Monerodo OS (sometimes referred to as MOS, at least, in the system itself) is a text-user interface and customized Ubuntu Linux distribution that is maintained and developed by Gingeropolous (and yes, that's me). The operating system is designed to give individuals with no Linux knowledge the ability to operate a fully dedicated node device in their home using any spare hardware available at minimal cost (because they don't have to buy a new operating system).

Monerodo is a portmanteau of the word Monero and the esperanto word for node, "nodo".

There is no official relationship to Monero core team and it is only as safe as the Ubuntu operating system on which it is built.


Why is Monero address reuse not discouraged?

Monero/Cryptonote addresses are conceptually similar to Bitcoin's stealth addresses. The Cryptonote Whitepaper describes Cryptonote addresses in the following way:

  We propose a solution allowing a user to publish a single address and receive unconditional
  unlinkable payments. The destination of each CryptoNote output (by default) is a public key,
  derived from recipient’s address and sender’s random data. The main advantage against Bitcoin
  is that every destination key is unique by default (unless the sender uses the same data for each
  of his transactions to the same recipient). Hence, there is no such issue as “address reuse” by
  design and no observer can determine if any transactions were sent to a specific address or link
  two addresses together.

The key thing to note is that no observer can link two addresses together. However, it is possible for the sender to link payments together if the receiver re-uses addresses.

For example, if you withdraw from ExchangeA using AddressA, and then go on to issue another withdrawal from ExchangeA using AddressA, the exchange will easily be able to link these two withdrawals together by simply comparing the withdrawal addresses (even if you used different accounts). Furthermore, if ExchangeA is cooperating with ExchangeB, it would be possible for both exchanges to link address-reusing withdrawals together.

Additionally, even if the sender is not cooperating with other entities in order to link transactions together, it is still possible for the sender to unwittingly link transactions together if their software is poorly implemented and erroneously re-uses the same random data for multiple transactions. Basically, the receiver is relying on the sender to generate good random data in order to generate a one-time key. If the sender fails to use good random data, then the "one-time" key isn't "one-time", and transactions can possibly be linked.

So, for maximum protection against linkability, it's a good idea to generate a new addresses for transactions that you don't want linked.


Monero daemon causes 100% disk utilization on Windows with new wallet install.

While syncing the blockchain, the Monero daemon generates a lot of disk IO calls to create its database, and HDDs are pretty slow at that compared to SSDs.

I'm not sure if there's a reliable way to limit the disk IO rate per process on Windows, but you could try to open the Task Manager and set the priority of the monerod process to "Low". It might improve the usability of the other applications running with a "Normal" priority.


Can I avoid Javascript poisoning when using MyMonero.com?

Yes. In the mean time, a Chrome application have been released to largely reduce the security limits of MyMonero (that come from the concept of a web wallet rather than errors from the developer).
https://chrome.google.com/webstore/detail/safer-mymonero/hcgliilmeggjhmpkfglnekbegacockei

It protects you from "JS modifications, HTML injections, HTTP downgrading and Google Tracking".

Keep in mind that it is just "Safer MyMonero" and that there still are some risks, in particular local malware as mentioned by fluffyponyza.


What is the minimum number of nodes for a private I2P testnet?

I do not know the absolute minimum, but I expect you should need ~10 nodes to have most operations function smoothly.


How are outPk, mask and amount fields created when spending RignCT coinbase transactions?

The person(s) mining would need to provide these fields. They are normally created by the sender of a normal transaction whereby a new private / public key pair and corresponding shared ECDH secret is created. In this case the person(s) who successfully mined a block gets to "send" themselves the block reward. But instead of sending it as RingCT type 0 (more on this below), they'll need to split the coinbase into multiple inputs can adopt RingCT type 1. It is not yet mandatory that coinbase transactions do this, but I believe the next hard fork will make this a requirement.

Also pay attention to the RingCT/type: yes/0 field in the first link you provided. There are three types of RingCT, and a 0 indicates NULL:

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

In your second link you'll notice RingCT/type: yes/1, with type 1 indicating Simple:

  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.

Source

This accounts for the missing fields.

This may also be of interest to you: RING CONFIDENTIAL TRANSACTIONS


This look like you have a balance on subaddresses but not on main address.
While the GUI aggregates all accounts addresses in a single balance, the CLI does not.

You could do a show_balance all on the CLI (IIRC) and check if the balance is on one or many subaddresses.


...how mining software works on Monero with nodejs?

Mining "works" the same irrespective of the platform the pool/miner is built on.
Documentation of a nodejs based pool can be found at nodejs-pool.


Spam attack to gain control of many outputs and undermine privacy

We can get a rough idea of a cost lower bound by doing the following:

This command looks at the tx_outputs database, which lists all the outputs on the blockchain:

mdb_stat -s tx_outputs ~/.bitmonerod/lmdb

We see that this database holds 17896556 entries. In order to get 20% of the entries, an attacker would have to create about 4.5 million new outputs (100 * 4.5 / (17.9+4.5) == 20). An output requires at least a 32 byte public key on the blockchain, so that'd mean a total of 144 MB to be added. At a cost of 0.01 monero/kB, that gives you a lower bound of 1406 monero in tx fees.

Now, this is a lower bound. You'd need more data. Each transaction needs at least one input (at least one 64 byte signature). The 32 byte public key is not the only thing that is needed per vout (at least 2 extra bytes).

In order to get 40%, you'd need 12 million extra outputs (3750 monero lower bound), and in order to get 60%, you'd need 27 million extra outputs (8437 monero lower bound).

If you want to concentrate on a given denomination, the same reasoning applies, with a twist: there are currently 812877 outputs of size 10 monero. But in that case, you will need to include change (or waste a lot of monero, or have a lot of monero in the first place). In the original case, I took the best case: you take an input of yours, and you divide it into as many outputs as the transaction will allow, quantize, and throw away the rest. I assumed you could perfectly quantize (the varint encoding takes just a byte) and you threw away nothing (otherwise it adds up to the tx fees). Now, if you want all your outputs to be a useful size (for instance, 10 monero), then you need to recover the remainders after splitting, in order to use them as inputs to a subsequent tx, as that remainder is now a significant amount of monero. As example: a 60 kB transaction can hold at most 1875 outputs (using 32 byte per output again, so an overestimate). If you have a single 20000 monero input, you can make 1875 new outputs of size 10, and you have 1250 monero left. You don't want to lose them, so you pay them as change, and then need to consolidate them with other change as inputs for a later tx. All that adds overhead to the amount of data you have to pay for.

Now, the chain is not going to wait, so an adversary will need to get more than that, especially if they want to keep that threshold. If the outputs are created as a one off, the adversary will own less and less of the total outputs are the chain grows.

If such a sustained attack were to happen, transaction fees would most likely be temporarily increased, which would make the cost go up by as much.

RingCT will indeed avoid the need to split amounts by denominations, and any RingCT input will be able to mix with any other. RingCT transaction size will also get larger per output (but also need less inputs). So creating a lot of outputs will cost more, too.


Is Nvidia GPU mining software available for OSX?

You might use Tsiv's miner here: https://github.com/tsiv/ccminer-cryptonight/releases but you will have to build it from source. I don't see any OSX binaries available.


How to check balance of Cold Storage Monero Wallet, easily, when privacy of balance is not an issue?

The view key detects incoming funds, and that is not enough to determine balance.

There is an easy way to do so, however: import your account on mymonero.com. There is a (currently) 1 monero fee for the blockchain scanning, but this will end up showing you your final balance. Of course, your wallet isn't cold anymore by that time.

A less easy solution, which keeps your wallet cold, is to export key images from your cold wallet, so the matching hot wallet can compute the final balance. See Can the import\export key images command can be used to check the balance of a paperwallet? for the details.


Daemon sync never starting - can't receive my funds

Your wallet version is up to date. Your wallet is telling you it can't reach the daemon.
To see why the demon fails to start, check the $HOME/.bitmonero/bitmonero.log, you should have information about any error at the end of it. You might have to add "--log-level 1" in the wallet settings page as daemon parameters to get more verbosity in the daemon logs.


Need a payment ID - using Monero GUI 0.12

It sounds like the exchange is asking for a 256-bit payment ID.

If you are sending funds to your own GUI wallet, you will have no problem figuring out who sent you the payment. Therefore you don't need to use a unique payment ID.

If the exchange does not let you leave it blank, you simply enter any 64-character hex sequence, such as just 64 zeroes.


Do I need to redownload the Aeon blockchain for the rebased software?

There's currently no way to convert the existing blockchain to LMDB format. Technically, you have to re-download. However, since you already have that legacy blockchain, there's a faster way by using that as the exclusive source for your synchronization.

As a first step, relocate the blockchain directory and start up the legacy aeond daemon using the --data-dir parameter:

mv ${HOME}/.aeon ${HOME}/.aeon-legacy
${PATH_TO_LEGACY}/aeond --data-dir ${HOME}/.aeon-legacy

Next, start up the rebased aeond daemon using the --add-exclusive-node parameter and – temporarily – different TCP ports, e.g.:

${PATH_TO_REBASE}/aeond --add-exclusive-node 127.0.0.1 \
    --p2p-bind-port 11190 --rpc-bind-port 11191

Once the blockchain is fully synchronized, you should see the message SYNCHRONIZED OK. After that, you can stop the legacy aeond daemon with the exit command, and restart the rebased aeond daemon without the extra parameters.

  Note: Optionally, you can remove the legacy blockchain directory ${HOME}/.aeon-legacy if you don't intend to start that up anymore.


How does the difficulty adjustment for monero work?

The difficulty adjusts with each block.

The adjustment algorithm examines 720 prior blocks, starting from 15 blocks ago.

Of those 720 blocks, the 60 highest and lowest block times are excluded from the analysis, which leaves 600 blocks.

Out of those 600 blocks, the average block time is determined. This average is then used to adjust the difficulty proportionally in order to target a 120 second block time. Difficulty is defined as the number of hash attempts required, on average, to find a valid hash for the block every 120 seconds. The unit of difficulty is therefore "hashes".

When there is a large and sudden change in hashrate, e.g. due to the April 6th 2018 PoW change, it will therefore take 15+60=75 blocks before the change in hashrate starts to affect the difficulty. The change to difficulty when adjusting to the new hashrate will be gradual, and after 15+60+600=675 blocks the new hashrate will have been fully taken into account by the algorithm.

When you see web sites display a "network hash rate" statistic, what those sites are actually doing is inferring the network hash rate from the current difficulty. The actual current network hash rate can only be indirectly inferred by observing how quickly blocks are being mined.

Credit for this answer goes to smooth from his comment here: https://www.reddit.com/r/Monero/comments/8a9wof/the_actual_drop_on_hash_power/dwxxiek/


Is Monero compatible with Windows Subsystem for Linux

Monero has native support for Windows, so I doubt any of the developers would want to waste time trying to support WSL (and there are no developers I'm aware of that are interested in working on this).

Running Monero natively on Windows is always going to have far better performance than running through something like WSL.

There is one aspect that is mentioned in the README however, and that is the depends build system, which produces reproducible builds:

  Using depends might also be easier to compile Monero on Windows than
  using MSYS. Activate Windows Subsystem for Linux (WSL) with a distro
  (for example Ubuntu), install the apt build-essentials and follow the
  depends steps as depicted above.

Worth taking note of the word "might" from the above quote and also that the Monero releases do not currently use the depends builds (though hopefully will soon).


Is there any PHP script for mining monero on webserver?

If you have access to the sever to run PHP code then you can just use a cpu or gpu monero miner anyway which are much faster and readily available for download and use.

As far as mining on a web client (not clear if that is what you're asking about):

Web based client side miners (such as javascript miners) use the web browsers or video streamers etc of the client machine to perform mining.

It is being done with platforms like coinhive as a monitization strategy (ethically questionable imo) where one would alert the user about it and ask for permission
but it is usually done by malware illegally in what is called Cryptohjacking. Essentially this is taking advantage of people's computers for ones own personal gain without any regard for those people or their devices


After extracting, you can either run the binaries directly from where you extracted them, or copy/move them to some other location (such as /usr/local/bin). Where you choose to install (i.e. copy/move), them is really up to you as the admin/user of your Linux box.

A nice overview of the binaries can be found at: https://monerodocs.org/interacting/overview/


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

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


monerod v0.13.0.4 being killed / crashed randomly it seems

To quote @moneromooo-monero:

  That's the OOM killer. Free more memory.


Hi I'm a new monero user here ( I was waiting for the gui) , I've managed to run successfully Monero GUI on Ubuntu 16.04.1 and Lubuntu 16.04.1 from a full installation on an usb stick on a very old laptop (and using an external daemon), hence why I switched to lubuntu which runs much better.

I encountered the problem you describe I did the following to solve it:

  sudo apt-get install qml-module-qt-labs-settings qml-module-qt-labs-folderlistmodel

  sudo apt-get install qml-module-qtquick-controls
  qml-module-qtquick-dialogs qml-module-qtquick-xmllistmodel

  sudo apt-get install qml-module-qtgraphicaleffects

If you want to speed up even more I tried the following on lubuntu after ditching ubuntu

You'll need

  sudo apt-get install libunbound2

and then do:

  set QMLSCENE_DEVICE=softwarecontext ./monero-core

  set QMLSCENE_DEVICE=softwarecontext ./monero-wallet-gui

and then start

  ./start-gui.sh

If the above command will not start the GUI try

  QMLSCENE_DEVICE=softwarecontext ./monero-wallet-gui

Be aware that I think there is a bug when you create a wallet from a seed it just sometimes does not led pass to the next screen, the right arrow control is not activated but if you start typing on the name of the wallet, the right arrow control activates and then you can click to the next screen with the  wallet recreated.

Hope it helps.


How to sweep coins from an existing monero address if you have all the keys?

You can't. Need to restore each wallet separately and sweep one by one.

How do I restore a wallet with seed?

If I saved my view key and spend key can I recover my wallet if my mnemonic seed is lost?


Two main reasons:

The block reward is going to decrease over time, and even in Monero where there is a tail emission (i.e. the emission rate bottoms out at a nonzero value) the block reward isn't guaranteed to be greater than electricity costs.
Transaction fees allow miners to prioritize more important transactions if the network is congested, because people will generally be willing to pay more for more important transactions. Transaction fees also will reduce demand for block space during such periods of congestion, because the transaction fees will increase in response as users have to out-bid each other to get included in a block.

EDIT: It's also important to note that if posting a transaction has no cost, the demand for transactions has no hard limit. Eventually, people will find more uses for the blockchain (or spam the network with transactions that don't do anything), until the system reaches its limits. When that happens, transaction fees will be necessary to keep demand under control.


What is the purpose of enforcing a minimum mixin?

For any particular person, maybe not. But in general, a miner might want to hide the fact that he or she may be mining (or even mining a particular block). For instance, if a third party knows you mined block B, and they see coinbase from block B moving, then they know it must be you.

The minimum mixin is imposed to prevent a tragedy of the commons scenario where people sending with mixin 0 would degrade the privacy of others who use (either before or after) those outputs as fake outputs. If outputs A, B, and C are used in a ring signature, then outputs A and B get spent with mixin 0, then C has no privacy added from the use of ring signatures.

The problem is described in https://lab.getmonero.org/pubs/MRL-0004.pdf, which recommends a minimum mixin value.


I fixed it changing this line from 1 to 0.

your_coin/CMakeLists.txt:102
 # set this to 0 if per-block checkpoint needs to be disabled
 set(PER_BLOCK_CHECKPOINT 0)

It means that before I was running my coin with checkpoints when it does not should have because is a new blockchain.


528 hex characters is 264 bytes.

The format is:

threshold of signers required - 8 byte uint32
number of total signers - 8 byte uint32
multisig signing secret key of this wallet - 32 byte scalar
public spend key of the overall multisig wallet - 32 byte EC point
secret view key of the overall multisig wallet - 32 byte scalar
public view key of the overall multisig wallet - 32 byte EC point
multisig keys - 3x 32 byte scalars. One of these is your own blinded multisig signing
  secret key, the others are blinded versions of the other signers' multisig
  signing secret keys
multisig signing public key of this wallet - 32 byte EC point

Note that the multisig secret signing keys are blinded as follows:

blinded multisig secret key = hash_to_scalar(multisig secret key || salt)

where salt is a 32 byte sequence starting with the ASCII "Multisig", right-padded with zeros.

Thanks to jtgrassie for the link to the source code where this is written.


Is there a stratum like protocol for Monero mining pools?

Stratum can be used for monero mining. Stratum is the protocol for communication between miner and mining pool server. getworktemplate is being replaced by stratum.
Here is a monero miner which uses stratum: https://github.com/sammy007/monero-stratum


How do I save the Monero blockchain to another hard drive?

In addition to pebx's answer, note that the default directory on Windows is %programdata%\bitmonero at least in v10.0. Move this entire directory to drive of your choosing and then run the command described:

  monerod.exe --data-dir D:\desired\path\to\your\blockchain

If you ran Monero v.9.4 or prior, you can also save space by deleting the entire LMDB directory and re-syncing from scratch which typically takes a few hours on a fast connection with a modern computer. Monero v10.0 uses less space for the database.


What determine the transaction size of Monero?

Both, and more. TX public key, TX extra data (usually payment ID), output one-time public key(s), input ring signature(s) and key image(s), ring confidential transactions (RCT) range proofs and commitments.


MyMonero Import fee - payment from import?

It's not a fee for importing moneros. It's a fee for importing your address's transaction history. A wallet cannot import moneros because moneros are not stored in wallets. They're stored at addresses on the blockchain.

Your address could have a history associated with it, if someone has previously sent moneros to it, or if you you have previously used some other wallet software to spend moneros from it. If you pay the fee, MyMonero will trawl through a copy of the blockchain (kept on a mymonero.com server) and figure out your transaction history.


How to check a detached daemon without a wallet?

You just run commands like monerod status which connects to the detached process and runs the command (status in this example).

You can also use the daemons RPC get_info.

  But, how can I check the detached daemon status without a wallet?

A node does not have a wallet attached to it.


What is the difference between v7 and v8?

Biggest change is Bulletproofs:

  Bulletproofs is a highly anticipated form of cryptography that increases the privacy of digital currency transactions while at the same time significantly decreasing their size.

Source

Another change is, globally setting ring size to 11:

  Previously the minimum ring size was set at 7 and optionally users could also choose larger ring sizes. Now for better anonymity the size of the ring signature is globally fixed to 11. With static ring size the transactions cannot be differentiated and this increased ring size increases privacy level.

Source

And finally, changing PoW algorithm from CNv1 to CNv2 to render every known ASIC useless and make it even harder for possible ASICs to be developed.

There are of course other smaller changes but the mentioned ones are the most significant.


I have found the best way to deal with this is just to start them all up at once. Monero RPC methods that are dependent on a fully synchronized blockchain will return with a relevant status code if the chain is not fully synced, and thus code can deal with this scenario as and when this happens.

If you find a situation it's imperative the blockchain is fully synchronized before starting some other tool/service, you could call the daemon RPC method get_info which shows you the daemon's current height in the height field and the blockchain target height in the target_height field. Therefore, you are syncing whilst height is less than target_height.


How do I find the value behind the pederson commitment?

It's impossible to reverse the Pedersen Commitment if you don't know the mask.

The commitment is amount*H + mask*G, so if you were told the secret mask, it would be possible to brute force all likely amount values to discover the amount.

But then if the mask can be securely communicated to you, so can the amount. So this is what Monero does. It encrypts the amount using the transaction shared secret, and bundles that encrypted amount as part of the transaction.

The decryption math is: decrypted amount = encrypted amount - Hs(Hs(8aR||i)) where a is the private view key, R is the tx public key and i is the index of the output whose amount we're decrypting.


Monero privacy features different from coin shuffling used in nxt/ardor?

CoinShuffle is a form of decentralized mixing. For simplicity's sake, you can consider it similar to CoinJoin. You can read the academic paper on CoinShuffle here.

A mixing approach has significant shortfalls compared to Monero's ring signature scheme:

Users must communicate with each other. With Monero, you can include other users' outputs in your ring signature without any active communication.
You must wait for these mixing transactions to be completed. This may take a while for a large number of funds.
It is voluntary, so the entropy set of people participating in CoinShuffle is small. With Monero, every transaction contributes to the entropy set.
Transacted amounts are still visible. With Monero, transaction amounts are hidden.


Private key - implications of sharing and relationship to public address

The public address is basically your public spendkey and public viewkey.  When you provide your public address to someone, they use the public spendkey and public viewkey to create outputs which only your private viewkey will identify as belonging to it and only your private spendkey will be able to spend.

Here's a partial quote from a reddit thread by core team member cloud10again:

  Secret (Private) spendkey: a 256-bit integer - only used in Monero transactions to compute the one-time "output private keys", which are actually used to sign transactions; however with current deterministic key derivation, the spend key also allows deriving everything else.
  Secret (Private) viewkey: another 256-bit integer - used in Monero to "decode" which outputs on the blockchain actually belong to your account. Can be given to an auditor or 3rd party, allowing them to discover your outputs as well.
  Public viewkey: a 256-bit representation of an elliptic curve point, svk*G. Used by a sender to compute a shared secret for stealth address creation.
  Public spendkey: a 256-bit representation of an elliptic curve point, ssk*G. Used by a sender to compute the actual output public keys from the shared secret, ensuring that only the private spend key can compute the key necessary to spend those outputs.

  Added "(Private)" by me, for clarity.

You can choose to share your private viewkey, or you can choose not to.  Monero has privacy by default, and the ability to be open is optional.  If a person or organization is okay with sharing a tool that allows for all deposits in their account/address/wallet to be verified in real-time, then that's their perogative.  In some cases, it may even be desirable, possibly such as in the case of a public charity or a government entity.  Many end-users value Monero for its privacy, so sharing the private viewkey in their case would not be desirable.


As a general rule of thumb: Cryptonight, the PoW hash Monero uses, needs a 2 MB scratchpad in fast memory, so you will want to have all your mining threads able to keep their scratchpad in cache. So the optimal number is likely to be your cache size divided by 2 MB (eg, if your cache size is 4 MB, then 2 threads). If that number happens to be higher of equal to the number of cores you have, then keep it to the number of cores minus one.

If you use the machine for other things at the same time, you will need to decrease that number, and by how much will have to be determined by testing.

In any case, you may want to test a number of configurations, testing is quick and easy, and will uncover any deviation your hardware may have from that rule of thumb.


What altcoins do you see as competitors to XMR in the privacy space?

There is no legitimate competitor in this space, IRL I would say it's comparable to US minted coins; as they are unserialized and untraceable currency. But USD will eventually be inflated to such a degree that coinage will be irrelevant (we're already there but prices can't adjust due to artificial pressures like interest modulation and QE).


Who receives the change from stealth addresses?

How does the reference wallet choose which of my stealth addresses will be used to have 35 XMR as input? S1 and S3, or S2 and S3? Why?

The wallet prefers older outputs (though someone can give you a better, code-based answer, I'm sure).  It does this because of the common heuristic that the newest ring member often indicates the true spender.

  To which address does the reference client send the change? To one of my stealth addresses (S1, S2, or S3) or to a new stealth address S4?

The client will construct a new S4 stealth address.  S3 and S1 and/or S2 are fully spent/exhausted when used.  Outputs cannot be partially spent.  They are fully spent and change is returned.


Are there any plans to add Hardware Wallet support to the core Monero software?

I think this depends in large part on what kind of changes would be required. That said, as a first approximation, adding support would seem like a good thing. If the driver program ends up totally separate, it can be a different binary too.

No current plans though. Plans can only be made when we know what the hardware is, what it needs in order to work with the host computer, etc.


Look up the transaction ID on a block explorer like this one.  If it's found, then you'll know the transaction went through.  Then it's just a matter of making sure your node is fully synced and your wallet has synced to the daemon (node).


How to calculate exact Monero transaction fee?

The fee calculator that you have linked gives you the exact formula, with one exception. Every transaction contains a list of "vins", meaning a list of varint offsets that reference the inputs used in the ring signature.

Depending on the spacing of the inputs that are randomly chosen as ring decoys, the length of the vin list will vary a little.

In practice though, this won't matter, because of the "KB boundary". In Monero, the size of a transaction is rounded up to the nearest KB. The fee then applies to the rounded up KB amount. Therefore a little bit of uncertainty about the vin list will mostly not affect the final fee, since you'd have to be unlucky to find that the variation in transaction size will leave you just over or just under the KB boundary.


Is there a javascript implementation to generate your Monero subaddresses without giving out your private-spend key?

Yes, you can use this Javascript NPM package to generate subaddresses: https://www.npmjs.com/package/subaddress


How can I slow down or disable cli wallet's automatic locking due to inactivity?

By default, the wallet will ask for the password after 90 seconds of inactivity.  You can see this by loading the wallet, then running this command:

set

Look for the entry for inactivity-lock-timeout.

You can increase the timeout to say 10 minutes like so:

set inactivity-lock-timeout 600

Or disable this functionality like so:

set inactivity-lock-timeout 0


How can I enable smart mining in my daemon?

There are two new optional parameters for the  start_mining command.

Before:
start_mining [address] [threads]

Now:
start_mining [address] [threads] [do_smart_mining] [ignore_battery]

If you pass the value "true" to the do_smart_mining parameter, then mining will only be activated when you're computer is idle AND plugged into a power source, and will only mine to a certain CPU threshold (40% I believe).

The ignore_battery parameter was added since there's no unified way to get power stats for every system, so on some systems determining if your computer is plugged in fails. If you set this parameter to "true" AND the code fails to query whether you're plugged in or not, then it will perform the smart mining as above, but ignoring the battery requirement.


Is there a formal plan in place for the transition to Quantum Computing? If so, what is it?

The obvious answer: when we have proof that "QC-resistant" algorithms are actually resistant, we can adopt a new algorithm and roll it out in the next scheduled hard fork. At present, everything written about quantum computing and weaknesses of current cryptographic algorithms is purely speculative. The world's most powerful quantum computer hasn't actually proven to be usable for cracking any crypto algorithms yet. http://www.wired.com/2015/09/googles-quantum-computer-just-got-a-big-upgrade-1000-qubits/


From the title of your post, specifically the part where it says "xmr-stak-amd" leads me to believe that you are trying to use an AMD GPU miner instead of xmr-stak-cpu.

The hardware you posted: "AMD A10-7860K Radeon R7 CPU" is a CPU

You will need to use xmr-stak-cpu: https://github.com/fireice-uk/xmr-stak-cpu
I know it says -amd, but thats actually referring to GPUs, AMD makes both, but that miner you're trying to use is not meant for CPUs


How will the implementation of Kovri work from a user perspective?

what can they expect when it is rolled out?

The Kovri router will be baked in to the Monero code, so all a user will need to do is select an option indicating whether they want to use the Kovri routing feature or not. I think its still up in the air whether it will be on by default or not. I think it will be on by default.

  as though they had set up a dedicated i2p relay?

Yes, I believe that is the idea. In addition to routing the Monero transaction traffic, the Kovri router will also provide a gateway into i2p and will serve to support the i2p network.

  Will the i2p relay be able to filter the traffic to only pass through monero-related traffic

This will probably be an option, considering that running a full i2p router can use lots of bandwidth per month. This is similar to how a user can throttle their Monerod with a download and upload rate cap.


How are the Monero ARMv7 CLI binaries built?

Monero's build instruction suggests that the swap size needs to be increased:

sudo /etc/init.d/dphys-swapfile stop
sudo nano /etc/dphys-swapfile
CONF_SWAPSIZE=1024
sudo /etc/init.d/dphys-swapfile start

https://github.com/monero-project/monero#on-the-raspberry-pi


No, not by itself. See Tari for a secondary layer example.


How will Monero core developers get funded?

There is a lot of interesting info on the monero site. Specific to your question is this page.


Anyone know if CoinHive uses the new Monero hashing algorithm?

They announced support on Twitter back in April:
https://twitter.com/coinhive_com/status/981102585460543489


How to create spend key and view key from public address

No. You can obtain them from the seed mnemonic (25 words) if you saved those. If it was possible from the address, then anyone could steal anyone's money.

If you already created the wallet from the keys/seed, you can get them from the wallet. If you just made the address, and closed the window without saving the mnemonic words or keys - that wallet is gone forever.


Why did monero-wallet-cli restore the same wallet with different mnemonic seeds?

TL;DR first is completely random seed, 2nd is the "normalized" seed, and they're both valid and resolve to the same wallet. As long as you know the method to go from mnemonic to the actual private key, you're safe to keep it as it is.

The first is a just some random 256 bits, probably generated by other means and the second is the "normalized" seed, meaning it's a number smaller than l (a parameter specific to the elliptic curve used in monero cryptography scheme). Both seeds resolve to the same private spend key and are equally valid. The private spend key is the important piece of data which is used on the protocol level. You could even use your own, custom, mnemonic scheme to get from mnemonic/seed to private spend key. The protocol doesn't care about the mnemonic/seed, only about the 4 keys (spend keypair and view keypair)

If you restore the wallet with the first seed, and after restoring use the "seed" command, the wallet will print the second seed. This is because it automatically normalizes the seed. Let me elaborate.

First of all, your mnemonic is a representation of a 256 bit integer, ie a very very big number. This number is your seed, and from it the keys are derived and those are actually used in cryptography on the protocol level. There is a function which converts between the number (seed) and the mnemonic. How the conversion works, is explained here.

To get the private spend key, the seed is passed through sc_reduce32 function:

privSpend = sc_reduce32(seed)

if the seed is a random 256bit integer, then it can happen that:

seed != sc_reduce32(seed)

however, if your seed has already been passed through sc_reduce32 function, then it's what we call a "normalized seed" and both the seed and privSpend will be the same, i.e. passing a normalized seed through sc_reduce32 results in the exact same number.

n_seed = privSpend = sc_reduce32(seed)
n_seed == sc_reduce32(n_seed)

Since n_seed != seed, the mnemonic corresponding to each of them will also be different.

You could easily produce the normalized seed yourself, by playing with this page:

Type in your first seed into box 1.
Click "Gen 2." and "Gen 3. & 4.", notice that 2. & 3. are different.
Copy the value from box 3. into box 2.
Click "Gen 1." and "Gen 3. & 4.", you will notice 3. and 4. didn't change and 2. & 3. are now the same.


Does Monero still use the Cryptonight algorithm since the fork?

Broadly speaking, it is still using the Cryptonight design, but the v7 hardfork included some modifications to the algorithm to brick the current generation of ASICs.

See https://github.com/monero-project/monero/pull/3253/files

All v6 mining software, including pools, have had to upgrade to match the new algorithm.


multiple watch-only wallet management: suggestions?

One daemon instance is enough. It can service multiple wallets simultaneously. The data stored by the daemon in the .mdb is all public knowledge (the blockchain), anyway.

Wallet-specific data is stored in the cache file. See here for more details. So really, you can keep the daemon running and have few instances of the wallet running and talking to the same daemon. Each wallet stores only some data relevant to it, while the daemon stores the entire public ledger (blockchain).


This happens if you're trying to spend outputs which are already spent.
The cold wallet has no access to the blockchain, so you have to tell it which outputs are spent, in this order:

"export_outputs filename" in the hot wallet
"import_outputs filename" in the cold wallet
"export_key_images filename" in the cold wallet
"import_key_images filename" in the hot wallet

Normally this is done automatically as part of the transaction creation system, but if you make any transaction otherwise (or fail to save your wallet after doing something), then it'll go out of sync and you have to do it manually.


According to the following link the beta is just around the corner as this was posted 1 month ago.

https://www.reddit.com/r/Monero/comments/50ixic/first_gui_beta_coming_by_mbg033_%E8%B7%AF_pull_request_6/

Slightly off topic, but still surprisingly on topic,
Exodus and Jaxx are amazing professional GUI wallets that include Monero, and for most people it will be enough, and potentially even better than the official GUI for simple functions like storing and sending XMR. Perhaps one unified interface that connects many coins is better than one for each coin although having an official GUI would go a long way to making a coin look more mature and complete. Even so, I foresee most people using a multi-coin wallet in the future.


How strong is Monero cryptography against brute-force attacks?

This image says that all the energy of the sun would not be enough to try all the Bitcoin private keys (256-bit keys).

The elliptic curve that Monero uses works with 255-bit private keys, and trying all of them would not be feasible either.


Will command line daemon/wallet still be available after the release of the official GUI?

Will command line still be available after the release of the official GUI?

Yes, it will. As far as I know, there will be support for both in the future. Thus, you will have monero-wallet-cli, which is the command line wallet, and monero-wallet-gui, which will be the GUI wallet.

  Will Monerod will be blended in similarly of what bitcoin core node/wallet is?

In the future, yes, see the feature request opened here. For now, however, monero-wallet-gui will be a separate binary that has to run alongside monerod. However, the GUI has a progress bar that shows the syncing status of monerod. Thus, new users would only have to open monerod and let it sync. They can monitor the progress in monero-wallet-gui.

Note that monero-wallet-gui might not be the official naming, but I used it in this answer for convenience.


wallet cli v0.12 : " Error : Failed to import Key images"

Ok, finally i've got it, I did not remember to export output first from my cold wallet (synchronized with the network)

For those who want to create a watch-only wallet, you can find the good tutorial here ==>

https://monero.stackexchange.com/a/2916


Are there any disadvantages to using a mining pool with I2P?

There is significant (and variable) lag in the i2p network - try visiting any i2p website. As mentioned on MoneroWorld.com, this could cause an increase in stale shares (you submit a solution for a block that already has been solved).

i2p lag will only decrease if more and more people run i2p nodes. (and by i2p nodes I mean running the i2p server).


Is it normal that the daemon log in the GUI shows 290 days AHEAD?

Yes. That is normal. Some of the nodes you connect to will be running old versions of Monero with outdated blokchains. Your daemon should eventually block some of these automatically. As long as it can reach a peer with a current copy of the blockchain, then there are no problems.

See here for more details.


You need to use a vanity address generator. As far as I know, this one written in Go is the best/only available one:

https://github.com/ehmry/monero-vanity

Edit: there is another one here implemented in JavaScript, see generate address with prefix:

https://moneroaddress.org


Send monero with Payment ID but public address, not intergated address

If you are sending funds to your own wallet, you do not need to specify a payment ID. Payment IDs and integrated addresses are only there to help differentiate senders, and do not affect whether you receive funds to your wallet. Therefore regardless of whether you used an integrated address, a payment ID, or no payment ID, you'll still receive the funds.

The reason exchanges need you to use payment IDs is because they receive funds from lots of different people, and in the absence of payment IDs, Monero's privacy mechanisms prevent them from knowing who sent what.


How to filter all transactions with a payment id that converts to a message?

There is a function in BlockchainDB which iterates through all transactions: for_all_transactions. Call this with a function which extracts the payment id (see find_tx_extra_field_by_type and get_payment_id_from_tx_extra_nonce), and scan its bytes for suitability (isprint).


Which is more profitable if I have big hashrate?

You'll get a little more with solo mining as you won't have to pay the pool fee, but your income will be much less regular because of the higher variance.


You’l need an Authenticator installed on new device. You can use your back up code/ recovery key to restore your account access.
Get your back-up code that you saved at the time of setting up 2FA with your older phone. This document has the recovery key that you can now use to restore Poloniex account on your Authenticator app.

P.S found it with a simple search on google ;)


Monero GUI on Linux Mint - how to open wallet file from a separate device / USB stick

When opening the GUI, select "Open a wallet from file"

After that, in the file picker you can go to any directory.

You could navigate to /media/yourusb/yourwallet.keys by clicking through the different directories (you might have to go to / first by clicking Computer on the left), or you could just directly type the path /media/yourusb into the File name box and press open.


Can I sweep funds in mymonero to another wallet?

You cannot transfer to another wallet with different address without a transfer fee. However, if you want to use a CLI or GUI wallet you can do so.

If using a GUI follow this guide:

How do I use my MyMonero wallet via the Monero Core GUI?

or using a CLI:

If I saved my view key and spend key can I recover my wallet if my mnemonic seed is lost?

FYI. Transfer fee has decreased since the last hard forked in April 15.


Good that you ask. Actually, a
coordinated test is ongoing and you could join in: https://www.reddit.com/r/Monero/comments/6eef96/fluffynet_update_please_move_some_to_tier_3_4_and/

And yes, you can use existing blockchain, the change is in networking part so interest is in blocks / TX propagation etc.


tx-notify being triggered 2 times per transaction

When the tx is seen, whether in the txpool or a block.

So if the tx is seen in the txpool, then tx-notify is triggered.
And the same with a block


Do checkpoints make initial blockchain sync faster?

Yes. The daemon doesn't check transaction signatures when under a checkpoint.

There are other possible optimizations, but I think that's the only one active right now.


GUI MMS - a graphical monero multisig app

Would it be possible to perform all the process automatically?

Not completely automatic no. Any UI would still need to prompt for user confirmations for example.

Imagine a GUI app where ... and then the rest is done in background. MMS isn't accessible from Monero RPC so I guess the GUI app would need to integrate the static wallet library somehow and talk to PyBitmessage.

MMS is supported in the wallet RPC so anyone wanting to create a more user friendly experience could absolutely make use of the wallet RPC to do so. The Monero GUI uses the wallet library, so can use the MMS functions directly.
I suspect the main reason it's not exposed in the GUI is simply to do with the dependance on PyBitmessage. Whatever the reason, as far as I'm aware there's no technical roadblock preventing it being added, rather it just requires someone to care enough about MMS in the GUI to add it there.


What is the fastest way to synchronize the daemon?

The fastest way to achieve this, is to download the current blockchain and import it into the daemon:

Step 1: Move into the folder where you downloaded the Monero Gui Wallet, e.g:
cd ~/Downloads/monero-gui-0.10.3.1-beta2

Step 2: Download the raw block chain from a trusted source, e.g:
wget -c --progress=bar https://downloads.getmonero.org/blockchain.raw

If it fails half-way, just re-run it. The above command will continue where it left off.

Step 3: Import the downloaded blockchain into the daemon:
./monero-blockchain-import --dangerous-unverified-import 0 --input-file ./blockchain.raw

Do remember though, run with --dangerous-unverified-import 0 only from a trusted source like the above. The option was previously called either --guard-against-pwnage and --verify

Step 4: You can now remove the raw blockchain to free up disk space:
rm -rf ./blockchain.raw

Step 5: You can now start the Monero daemon, either from Settings in Monero Gui Wallet, or directly from the terminal in detached/background mode with:
./monerod --detach