Coudn't connect to daemon Wallet do not synchronizing because he couldn't connect to daemon. Win 10. Restore height is 2150000.
I tried:

Reinstall GUI (I had used latest version (17.4) before, but anyway)
Start monerod
Resync whole blockchain (I nearly download it, but it stopped at 7k blocks before syncing and don't want to sync again).
Start monerod x2 (it automatically closes after "initizatiling core" after 1 second)

Bitmonero says:

2020-11-23 18:02:57.625   8732    INFO    logging contrib/epee/src/mlog.cpp:273   New log categories: *:WARNING,net:FATAL,net.http:FATAL,net.ssl:FATAL,net.p2p:FATAL,net.cn:FATAL,daemon.rpc:FATAL,global:INFO,verify:FATAL,serialization:FATAL,daemon.rpc.payment:ERROR,stacktrace:INFO,logging:INFO,msgwriter:INFO
2020-11-23 18:02:57.626 8732    INFO    global  src/daemon/main.cpp:293 Monero 'Oxygen Orion' (v0.17.1.3-release)
2020-11-23 18:02:57.626 8732    INFO    global  src/daemon/protocol.h:53    Initializing cryptonote protocol...
2020-11-23 18:02:57.627 8732    INFO    global  src/daemon/protocol.h:58    Cryptonote protocol initialized OK
2020-11-23 18:02:57.628 8732    INFO    global  src/daemon/core.h:63    Initializing core...
2020-11-23 18:02:57.629 8732    INFO    global  src/cryptonote_core/cryptonote_core.cpp:515 Loading blockchain from folder C:\Games\MoneroBlockchain\lmdb ...
2020-11-23 18:02:57.762 8732    INFO    global  src/cryptonote_core/cryptonote_core.cpp:690 Loading checkpoints
2020-11-23 18:02:57.763 8732    INFO    global  src/daemon/core.h:73    Core initialized OK
2020-11-23 18:02:57.764 8732    INFO    global  src/daemon/p2p.h:63 Initializing p2p server...
2020-11-23 18:02:58.030 8732    FATAL   net contrib/epee/include/net/abstract_tcp_server2.inl:1072  Error starting server: Failed to bind IPv4 (set to required)
2020-11-23 18:02:58.031 8732    INFO    global  src/daemon/core.h:94    Deinitializing core...
2020-11-23 18:02:58.369 8732    INFO    global  src/daemon/protocol.h:75    Stopping cryptonote protocol...
2020-11-23 18:02:58.370 8732    INFO    global  src/daemon/protocol.h:79    Cryptonote protocol stopped successfully
2020-11-23 18:02:58.371 8732    ERROR   daemon  src/daemon/main.cpp:361 Exception in main! Failed to initialize p2p server.

It happens every time after this:

2020-11-23 15:55:26.475   [P2P9]  INFO    global  src/cryptonote_protocol/cryptonote_protocol_handler.inl:1600    Synced 2229820/2236981 (99%, 7161 left)
2020-11-23 16:11:57.270 [P2P6]  WARNING global  src/p2p/net_node.inl:1989   No incoming connections - check firewalls/routers allow port 18080
2020-11-23 17:11:58.097 [P2P0]  WARNING global  src/p2p/net_node.inl:1989   No incoming connections - check firewalls/routers allow port 18080
2020-11-23 17:49:22.980 [SRV_MAIN]  INFO    global  src/daemon/p2p.h:80 p2p net loop stopped
2020-11-23 17:49:23.150 [SRV_MAIN]  INFO    global  src/daemon/rpc.h:84 Stopping core RPC server...
2020-11-23 17:49:28.152 [SRV_MAIN]  INFO    global  src/daemon/daemon.cpp:227   Node stopped.
2020-11-23 17:49:28.178 [SRV_MAIN]  INFO    global  src/daemon/rpc.h:96 Deinitializing core RPC server...

It could be two things.

Your firewall is blocking the daemon from working. Try allowing a new firewall for monerod.exe

There is something that is using port 18080. If you know what program uses this port, close it before starting monerod.exe


Can you determine the change transaction sent back to you? Continuing off of this question, Does change appear as an output in a transaction?, can you determine that Alice's change transaction really is a change transaction? Or to put it a different way, can you tell change transactions apart from regular transactions if you have the view key?

There is no such thing as a "change transaction". A transaction has inputs and outputs. When a user sends funds to someone, any change is just destined to one of the transaction outputs. Only the sender can derive which output has any change and how much that output has, and yes, they would be using their view key.

Remember though, there may not actually be any "change". A user could spend all the input(s) to one or more destinations (outputs) that are not theirs, and thus no change output needs creating by the wallet.


How to mix correctly? I have noticed that Monero mixes are usually a bunch of very small txs and then a much larger one that accounts for almost the whole amount sent. I also hear talk that one should not be sending "unique" amounts. How does one correctly mix their transactions for larger amounts? I don't mean huge amounts, but a couple thousand xmrs.

Output selection is random, which accounts for the prevalance of outcomes such as the one you mention. Outputs are picked, until the accumulated sum reaches the amount to send plus the fee, and this target is a lot more likely to happen when adding a large output.

The unique amounts you speak of are the dusty complex amounts such as 0.000468709491, which are very specific (not split below 0.01), and are unlikely to have other amounts of the same value to mix with on the blockchain. Monero does not produce those anymore, but if you have any in an existing wallet, your best bet is to run sweep_unmixable, which will consolidate them into nicer outputs which can mix.

There is no way to manually select outputs, so you can't change this without writing your own selection code, which is not recommended.


What would be the fastest way to implement Dominant Assurance Contracts (which depend on multisignature transactions) with Monero? I think that dominant assurance contracts are a significantly overlooked or poorly explored idea for the entire cypherpunk and cryptocurrency community.

I'd like for all of us to do more exploration with it, but before that's possible there needs to be some implementation of it.  So, what's the quickest, cheapest way to get a script that allows for a dominant assurance contract to be executed using Monero?

https://en.m.wikipedia.org/wiki/Assurance_contract#Dominant_assurance_contracts

https://en.bitcoin.it/wiki/Dominant_Assurance_Contracts

https://mason.gmu.edu/~atabarro/PrivateProvision.pdf

There is no simple built-in multisig option for now with Monero, we'll have to wait for RingCT and the multisig extension built on it.

So for now, probably there is no option to implement it at all.


How to send XMR from Minergate to Poloniex? sorry total newb here.  I've been mining Monero after seeing the talk at Coinbase.  Really like what you guys are doing.  Now I'm trying to send my XMR from Minergate to Poloniex.  My Deposit address only shows a "Monero Payment ID" but Minergate is asking for both a Monero address and an "optional" Payment ID.  Where do I find the Poloniex deposit address?  Or what are the steps to send from Minergate to Poloniex?  Thanks,

To see your Monero deposit address on Poloniex click Show me the Deposit Address when viewing your payment ID.


Offline transaction signing. What are the details? This offline transaction signing feature was PR'ed to master in early October.  I generally know how this is supposed to work, as many others no doubt do as well.  But what are the details?

On the internet-facing computer:

Can I have a regular hot wallet, in addition to a cold view-only wallet that requires transactions to be signed by the air-gapped computer?  (I would think cold wallet would be separate with its own mnemonic seed.)
Is there something about the wallet that requires cold transaction-signing that is different than a typical view-only wallet?
How does the view-only version of the wallet get set up, so that it knows there is an air-gapped computer required for signing?  (Maybe it doesn't "need to know."  Maybe it's just a matter of having the ability to create an unsigned transaction, and then broadcast a signed transaction?)

On the air-gapped (not internet-facing) computer:

How recent does the version of the blockchain need to be in order to sign transactions?  Will it always be able to sign transactions that spend deposits occurring at or the latest block on its copy of the blockchain?
When a more recent copy of the blockchain is pasted/moved to the air-gapped computer, what is the rescan/refresh procedure?  That is, for example, will I need to recall the latest block from the prior copy, in order to scan only the applicable new blocks?  Or perhaps this is automated somehow?

On the internet-facing computer:

You can have a hot wallet (or many) in addition to your cold signing wallet. You will need to have a watch only wallet matching the cold wallet (ie, same keys, the view wallet just didn't get told about the spend private key).
The "cold transaction-signing wallet" is not on the internet facing computer. The view wallet is. The difference between the two is the lack of a spend private key in the view wallet. There is no difference between a view wallet with a corresponding signing wallet and a view wallet without one. The view wallet does not know whether it will ever receive signed transasctions to relay.
The hot wallet does not know to know per se. If you try to transfer from a view wallet, it will save the file for cold signing, since it cannot sign itself. You can either create it with monero-wallet-cli --generate-from-view-key (you will be prompted for data, which you can obtain from the full wallet via commands such as spendkey, viewkey, seed), or use save_watch_only in the main wallet, which will save a keys file withouth the private spend key, which you can then copy to your internet facing computer and name appropriately.

On the air-gapped (not internet-facing) computer:

The cold wallet does not need to have a blockchain. It will get the necessary data in the file the view wallet generates.
n/a, due to the previous point.

See How do I use cold transaction signing? for the list of steps involved in signing a transaction on the cold wallet.


What would we call Monero users in Esperanto? What would we call Monero users in Esperanto? I have seen the term "moneranoj" mentioned on Reddit. Is this correct? Does there exist a word for a single Monero user?

The 'j' at the end is for the plural, so a single user should be a "monerano,"  I think.  I've just picked up a little Esperanto in recent weeks.

Thanks to

https://www.reddit.com/user/lethos3


Would an attacker knowing the block-heights of my wallet's transactions weaken my privacy/security? Let's say I'd go through all the transactions in my wallet, write down their block-heights and store this list somewhere insecure.

Could my privacy or security be compromised by this in any way (assuming an attacker knows it is a list of block-heights for all of my wallet's transactions)?

Yes, it would weaken your privacy. By knowing when you transacted, an attacker can narrow down the field of which possible outputs you own, thus increasing their capability to trace your past and future transactions.


How do I change input selection after my wallet provides an unfavorable choice? I had 5 monero (XMR) in my wallet yesterday, made up a single 5 XMR output.  This morning I sent this wallet 20.5 XMR, so now I have 25.5 XMR total.

Now I want to "churn" the recently received 20.5 XMR input (whether needed or not), so I created a transfer transaction to send 20 XMR to myself.  monero-wallet-cli asked me if it was okay to use the 20.5 XMR output and the 5 XMR output as inputs to the transaction.

It asked me if this was okay, and I said it was not, so the transaction canceled.  I retried several times, and it always gives me the same mix.  I don't want a mix of outputs at all.  I want to just send the 20.5 output only.  Is there a way to do this?  I would expect that a second try or third try would change the output selection, but it didn't.

(I'm wondering if there will be a way in the future, but it's just not yet coded.  Would I create a github issue in that case?)

For your particular case: use the latest version of monero-wallet-cli, and set min-outputs-count 1000. This will tell the wallet to not include a second unneeded input. However, your transaction will look different from the majority of other transactions, which tend to have 2 inputs. As this new code gets used more and more though, there will be a good mix of 1 and 2 input transactions.

In the general case, though, it is more complicated, and depends on the amount sent and your particular owned output set (and I won't go into details because it's complicated, not really relevant, and subject to change). Sometimes there will be a random selection, and sometimes not.


How to check whether monero-wallet-rpc is running? I installed monero-wallet-gui on mac. I can't run curl commands to Wallet RPC because it needs digest authentication. How do I check if monero-wallet-rpc is running so I can configure it(input my user/password).

If you know the port monero-wallet-rpc listens on, you can connect to that port to see whether something is listening. This is what the python RPC layer does.
From utils/python-rpc/console.py in the Monero tree:
  # check for open port
  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.settimeout(1)
  if s.connect_ex((host, port)) != 0:
    raise Exception('No wallet or daemon RPC on port ' + str(port))
  s.close()


How to get the transaction public key and outputs from get_transactions? I'm trying to get the outputs and tx public key according to this answer.

I know that the transaction public key must be in the "extra" section.
When I ran the get_transactions command, I got this response
(displaying only the "extra" part):

"extra": [ 1, 108, 109, 63, 78, 182, 147, 31, 13, 63, 251, 116, 213, 150, 92, 35, 157, 53, 55, 182, 160, 24, 206, 159, 131, 96, 160, 20, 147, 162, 61, 159, 75, 2, 9, 1, 214, 209, 43, 119, 113, 218, 18, 237  ]

This is how documentation defines "extra":

  extra - Usually called the "payment ID" but can be used to include any random 32 bytes.

According to the pseudo-code mentioned above, what parts of the response given by get_transactions do I need to process the incoming transfer?

How to get the transaction public key and outputs from get_transactions?

Parse the field named extra to get the public key. The 32 bytes after the byte 0x01 is the tx public key.

The output keys are in txs[].as_json.vout[].target[].key if you used the parameter decode_as_json:true.


What happens if a very large transaction is over 2x the median block size? The dynamic block size limit 2x the median block size over the last 100 blocks.

What happens if a transaction containing an extremely large numbers of outputs and a very large mixin exceeds the current dynamic blocksize limit?

Will the daemon reject the transaction?

The 2x the median block size cap is directed at the blocks themselves not individual transactions.

In my example below I will ignore the small coinbase transaction.

Assume during a single block interval there are 5 very large transactions each one being approximately .53 of the median block size. Collectively the would total 2.65 times the median block size (which is not allowed). 3 of the transactions (totaling 1.59 of median block size) would could be included in the block and the other two (1.06 times the median block size) would remain in the mempool until being confirmed in the next block.

In your example, if a single transaction is created that exceeds 2x the median block size by itself the transaction could be submitted to the network. However it would not be confirmed (unless they median blocksize grew just enough during the time the tx was sitting in the mempool such that the tx size was no longer 2x the median blocksize).


If I need to send a bunch of transactions, how can I stop the wallet from using my entire balance as change during the first transaction? Say I want to send a number of payments. Sometimes the wallet will use up my entire balance with change just to send some small amount, and this stops me from being able to send additional payments for fifteen minutes or however long it takes to get my full balance back.

Is there any way to avoid this in order to send a bunch of payments in succession? And if not, won't this be a big issue for average people's usage when the GUI is released?

There's no direct way, but there could be a workaround.

The protocol doesn't limit the number of inputs/outputs. So, you could split the first transaction into many outputs where some (or all) of them are going back to yourself. This way, you'd do all your payments at once, and get more than one change output. Yes, you'd pay more fees but you'd then continue with enough unspent outputs to avoid the experience of having most funds locked on every transaction. You could do it with the CLI wallet, too! The transfer command allows for many destinations.

transfer [<mixin_count>] <addr_1> <amount_1> [<addr_2> <amount_2> ... <addr_N> <amount_N>] [payment_id] - Transfer <amount_1>,... <amount_N> to <address_1>,... <address_N>, respectively. <mixin_count> is the number of extra inputs to include for untraceability (from 2 to maximum available)"


Meaning of monerod status command output I use Monero 'Lithium Luna' (v0.12.3.0-release) CLI only.

I would really like to know the meaning of a status command output line like this:
Height: 146124/146124 (100.0%) on stagenet, mining at 36 H/s, net hash 268 H/s, v7, up to date, 8(out)+0(in) connections, uptime 0d 0h 11m 57s

I could not find anything specific.

In fact everything is clear to me but the following:

V7
8(out)+0(in) connections

What I am really interested in is the meaning of V7, since I also have daemons running (same monero release) which show V1 instead and they continuously produce lines like these:

[94.19.172.18:51393 INC] Sync data returned a new top block candidate: 136994 -> 250777 [Your node is 113783 blocks (79 days) behind]

or

[207.180.196.236:57862 INC]  peer claims higher version that we think (9 for 232290 instead of 7) - we may be forked from the network and a software upgrade may be needed

v1 means the blockchain is currently at version 1. v7 means it's at version 7. If the blockchain is syncing (as shown by monerod telling you it's currently 79 days behind), it'll show the version at the point it's reached so far. At this time, the network should be at version 7.

The "peer claims higher version that we think" message is telling you that a peer on the network is running a later version. Normally, this means that the Monero network updated, and you will need to also update your software in order to be able to sync past that point. However, since the current version on stagenet is v7, it looks like it's just someone having made local modifications, making your node see the new version and thinking it's late, where in fact it's not.

"8(out)+0(in) connections" tells you the number of peer to peer connections your node currently has, sorted by whether your node initiated them, or whether a peer initiated them. If the second number is 0, it mean peers cannot find your node, so your connections to the Monero network is more fragile. You may want to check your router and/or firewall to allow peers to connect to the P2P port (in this case, for stagenet, it is 38081, and it'd be 18081 for mainnet).


Static compiling dependencies Currently I have a limited server with small memory and capacity. I need to compile Monero on a local Linux system then copy the binary to the server. However I don't see the dependencies.

When I tried to static compile using make static-lib, make SHARED=0 cc='gcc-staic' or using cmake set (cmake-find-library-suffixes ".a") and set (build-shared-libs off) set (cmake-exe-linker-flags "-static"), I keep suffering from a libboost update mismatch and many other libraries libcrypto libssl libhidapi-libusb.

I need to find out the dependencies of the binary to copy them at once? How can I do this?

Also, I need to correctly static link the binary?

The correct build command to build Monero statically is make release-static. Before doing this, you will have needed to have installed all the dependencies on the system you are building on (you local Linux machine) and these dependencies will need to have static versions of the libraries. Dependencies required and build instructions are detailed in the projects README. Per the documentation, on Ubuntu the dependencies can be installed like:

sudo apt update && sudo apt install build-essential cmake pkg-config libboost-all-dev libssl-dev libzmq3-dev libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev libldns-dev libexpat1-dev doxygen graphviz libpgm-dev

It's worth noting that once you succeed in building a static release, none of these libraries will need to be present on your server. Static builds are the same as the actual release binaries available from https://web.getmonero.org/downloads/#linux, so you could of course not even bother building from source and just use those.

Lastly, if your server is the exact same version of Linux as your local machine, you could perform a dynamic build locally and copy the compiled binaries to your server. Then you would just install the same library dependencies detailed above on the server.


Multiprocessing vs multithreading for mining Which one is better (higher hash rate)?

Multiple xmrig processes with single threads

Single xmrig process with multiple threads

XMRig is designed to run as a single process with multiple threads – if it were faster the other way round, it would have been changed to run easily that way instead.
In any case, the maximum hashrate possible with either #1 or #2 is likely the same.


Is a mnemonic for view only wallet possible? It occurred to me that one may wish to restore a wallet on a compromised computer.  Perhaps they need to prove that a payment was received.

Regardless of whether this is a good idea, is it possible to use a mnemonic to restore a view-only wallet, in terms of:

the required math to create a mnemonic for a deterministic viewkey, and
the code currently in place that parses and processes a mnemonic to create a wallet.

Monero's existing mnemonic scheme simply translates back and forth between a 32 byte scalar and a 25-word checksummed mnemonic.

At the moment, that's used to store the 32 byte seed. There is no reason it can't be used to produce a mnemonic from the 32 byte private view key.

However, you need to know both your private view key and your public spend key in order to create a view-only wallet.

Therefore you'd have to store both the mnemonic and your public spend key (or your wallet address, which contains your public spend key). If stored separately, your public spend key could be represented as base-58, hex, or as a second 25-word mnemonic.


pool updated payment is not normal Here are my logs:

2017-01-11 16:35:11 Error with transfer RPC request to wallet daemon {"code":-4,"message":"Transaction would be too large.  try /transfer_split."}
2017-01-11 16:35:11 Payments failed to send to

What happened to the transaction?

The transfer RPC call will by design try to create one transaction. If the transaction is too big to be included in a block, it will fail. This is what happened in your case, and is why the message tells you to use transfer_split instead, which can create several transactions for your transfer.

If you change the RPC from transfer to transfer_split, note that the return will not be a txid, but a list of txids. This has relevance when handling the return value, if you do so.


How does RingCT prevent doublespend ? For what I know about RingCT it use fake outputs to mask the amount that is transaction between address's, how do we know that the fakeoutputs are correct and that is noone messing with them?

RingCT does not create fake outputs. Here is a good dumbed-down explanation of its principle: ELI5: How does RingCT work?

Therefore there is no difference between "normal" transactions and RingCT ones in terms of double-spend prevention: it is handled in the exact same way using key images.


Is it possible to remove unlock_time for a transaction? Is there any way to remove unlock_time for a sent transaction?

Yes. You need overwrite the transaction with another transaction sans unlock_time. If the transaction in question is already in a block, then you'll need to reorganize the blockchain to the depth where this transaction was first added, removing it and adding your replacement.

The short version: "no". This is part of the immutability property of blockchains (unless you are ETH).


How to autostart monerod in Windows 10? I would like some assistance starting monerod.exe when starting Windows from boot. Can someone please walk me through this?

Preparation

Make sure you have the latest binaries from the official website. Download and extract these. Make a shortcut of monerod.exe. If you would like to run the daemon with certain parameters, create a .bat file and then create a shortcut of the .bat file instead. You can create a shortcut of a file by right clicking a file and then clicking Create a shortcut.

Adding the Shortcut to the Startup Folder

Windows has several startup folders. You can either put it in a folder that runs when a certain user logs in, or in a folder that runs for all users.

Specific User

Go to C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup, replacing Username with your actual username. Copy the shortcut here.

Alternatively, you can open Run and type shell:startup to get to this folder.

All Users

Go to C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp. Copy the shortcut here.

Alternatively, you can open Run and type shell:common startup to get to this folder.


How do key images really work? I have the following questions regarding the equation I=xHp(P):

What is the hash function Hp?
How can we know that Hp(P) is a point on the Ed25519 curve? Or is it not?
Is the value I published with the transaction?
How can an external person verify that the key image has been produced by the owner of one of the transactions, without revealing the identity but at the same time providing double spending resistance (even when the signer chooses two different rings)?

I've found very fragmented information at different places but none of them has an in-depth explanation of how double spends are avoided in monero while preserving privacy.

1. What is the hash function Hp?

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

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

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

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

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

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

3. Is the value I published with the transaction?

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

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

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

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

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

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

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

Some more info can be found here in the comments.


Can Monero in its current state handle the amount of daily transactions bitcoin does, and if so how long would a confirmation take? We can all see the Bitcoin network is struggling with very long waiting times for confirmations and this is of course due to the massive amount of transactions it has to deal with (greater than all other altcoins combined).
My question is could Monero currently handle the volume of transactions Bitcoin does with a faster confirmation time?

The reason bitcoin network is struggling is that there are too many transactions trying to get in a block, but the maximum allowed block size is hardcoded into the protocol rules. Nothing that can't be fixed - the amount of transactions is by no means massive. See here for some historical background on the subject.

Monero, on the other hand, never had such a hardcoded limit, but has a dynamic block size limit, where miners are allowed to expand the block size cap to accomodate more transactions. In fact, this was already proven to work in practice when the Monero network was tested during a spam attack (another relevant link) because the attacker needed bigger blocks to execute another attack, which was later analyzed by the MRL. Note that a prolonged spam attack is unsustainable, because the miner inflating blocks with his own transactions doesn't get any transaction fee, and will be penalized by losing the block reward. Idea is that when the network grows organically, miners would be giving up some block reward to get more transaction fees.

So yes, Monero would probably do just fine and no delays should be expected.


Where can I exchange GBP to Monero (XMR)? Does anyone know where can I exchange GBP to Monero (XMR)?

Thank you.

Regards,

Chris

You could try localmonero: https://localmonero.co

But there aren't many GBP sellers there with very high sell records or reputations, so you may be better off buying bitcoin first, as suggested already, then send those to an exchange (such as Poloniex, Kraken, Bitfinex, or one of many others) and then exchange them for Monero there.


Unable to send amount below one (.x) in Mac OS and Windows OS GUI (Primary enviornment Mac OS 10.13.6, running local node, completly synced)
I updated my GUI after the fork and successfully completed one transaction.
Two weeks later, I attempt to open the GUI and it wont load.  I found an update which was downloaded and installed. I kept all previous blockchain headers, wallet info, etc, opened the new GUI, wallet and daemon proceeded to sync quickly. My previous balance was visible.  I was sent more XMR and it was recived and unlocked.

I attempted to make a small test transaction (.1) to a known working address (friend's address), and the send button is greyed out.  The box around the address shows it is a valid address (no red box).

I installed the GUI on a bootcamp partition of the same mac running Windows 10,(imported blockchain headers from Mac OS) same exact issue.

I tried running a remote node

Am I missing something implimented in the new update?  Anyone else have this issue?  I've spent at least 4 hours so far troubleshooting and researching.  I don't have access to a non-Mac to try running the GUI on.

An amount below 1 has to be entered as 0.x and not as .x in the GUI. Put differently, the GUI will not accept amounts that are stated as .x

Note that we (the GUI contributors) are working on making improvements in this regard.


Hangs on "Forking to background..." ( `monero-gui-v0.13.0.3` on Ubuntu 18.04 LTS ) Using monero-gui-v0.13.0.3 on Ubuntu 18.04 LTS (all up to date), starting this way:  ./start-gui.sh, and with the Nano Ledger S (up to date: Firmware version 1.4.2), all is well (I allow the viewing of the keys from the Ledger when prompted, and I can see my wallet balance number on the gui) until the daemon starts.

The terminal shows:

2018-10-27 17:42:35,350 INFO  [default] Page size: 4096
2018-10-27 17:42:36.354     7f98cc6b3780    INFO    global  src/daemon/main.cpp:287 Monero 'Beryllium Bullet' (v0.13.0.2-release)
Forking to background...

And it just hangs from there.  The gui is frozen.

(Earlier, I had to do sudo apt-get install libhidapi-libusb0, as noted elsewhere, to even get the gui to start).

Additionally, when I try to clean up the monerod processes with ./monerod exit, that hangs as well.

How can I run the new gui on Ubuntu 18.04 LTS?

When a process hangs, you can use gdb to work out where it is hanging:

  gdb /path/to/binary PID

Replace /path/to/binary with the filename (and path if needed) of the binary you're running, and PID with the PID of the running process (you can get it via ps).

Then, when in gdb:

  thread apply all bt

This will print a list of all the threads and what they are doing. If any of those threads are stuck somewhere, this should expose it.


ELI5: How is Multisig going to work in Monero? From what I understand Monero multisig will likely be a special Monero address, similar to something like a p2sh address to address specific use cases. Will it work like a traditional multisig system where you simply just distribute n number of public keys?

OK, here's my attempt at an ELI5 on this. Please help to correct any errors in the usual manner.

A multisig is a special requirement put on to a transaction so that it cannot be spent unless a certain number of signatures are present. This threshold is set something like "3 out of 5" or more generally "t of n".

Multisig transactions are useful because they prevent just one key having control over the funds which helps businesses to reduce theft (perhaps through multiple people signing) or multiple device ownership (2 factor authentication).

In Monero we have "Ring Signatures" where a transaction can be signed but the actual single signing key is unknown to preserve anonymity. We can extend this to introduce multiple signing keys and a threshold using "Ring Multisignature".

We'll gloss over the technical details of setting up the shared key except to say that everyone involved makes sure that all their communications are securely signed to prevent anyone messing with the component keys in transit and that the outcome is control of a particular agreed address. This is covered in the Ring Multisignature protocol laid out in Section 4.4 of MRL-005 (pdf).

This address looks no different to a normal Monero address because of the way the mathematics works when applying additional signing keys and a threshold. This helps with fungibility since there is nothing special about it to indicate it as different from anything else. Funds can be spent to the address in the usual manner.

When the time comes to spend the funds held in the address the owners of the signing keys collaborate to produce a number of signatures that satisfy the threshold.


How is Monero development funded? What is the funding model for Monero development?

What incentives are in place to retain existing talent and attract additional developers?

Monero is an open source project, and is no different than most in that respect. There is no company or similar organization providing funding, and most developers contribute pro bono.

That said, there is an optional funding system called the "Forum Funding System" which allows a person to request funding for any particular reason. This is wholly voluntary, and not connected to the consensus rules in any way. This allows monero holders to decide to fund people if they think that the proposed task is likely to be good for monero, and thus increase the value of their own monero.

Several such funds have been successful, some are still ongoing, and some failed.

In addition "smart mining" (if your CPU is idle and you are not running on just battery power it will begin mining) once released will help with development funding (via optional donations) in addition to network decentralization.

Some developers also build Monero related services (such as xmr.to) that will financially benefit from the growth of the Monero network.

Some services also donate to Monero core development - for instance, most (if not all) mining pools include a small percentage donation to core development.

Finally, some individuals donate directly to core development. For instance, on the Community Hall of Fame, it can be seen that some members have donated 20k xmr to core development. Though it should be noted that the hall of fame includes funding routed through the forum funding system as well as direct donations.


How to create more outputs? I forked aeon/monero for fun and to learn. I have seed nodes running, pools running, miners running. The blockchain syncs, nodes connect to eachother. I can send transactions from the cli wallet only using mixin 1.

The only problem I have now is with Nodejs-pool and miner payments. I have set the pool db to mixin 1, the coins config mixin is 1.

From the start the pool does not make payments.
How do I create more outputs?

Anyone know what might be wrong or how to get more outputs some how?

I tried sweep_unmixable but that didnt work.

https://github.com/MoneroOcean/nodejs-pool/issues/36

I can send coins from my wallet cli using mixin 1 but nothing else?

It doesn't work from the pool if I enter mixin 1 in the pool db still not enough outputs for tx.

2018-06-18 13:58:45.853 [RPC0] ERROR wallet.wallet2 src/wallet/wallet2.cpp:6315 !scanty_outs.empty(). THROW EXCEPTION: error::not_enough_outs_to_mix

2018-06-18 13:58:45.868 [RPC0] WARN net.http src/wallet/wallet_errors.h:794 /home/pooldaemon/durinscoin/src/wallet/wallet2.cpp:6315:N5tools5error22not_enough_outs_to_mixE: not enough outputs to use, ring size = 2, scanty_outs:

9.000000000000 - 1

0.800000000000 - 1

0.600000000000 - 1

70.000000000000 - 1

0.020000000000 - 1

Payments module error

payments > 2018-06-19 13:00 +00:00: Issue making payments{"code":-19,"message":"not enough outputs to use Please use sweep_dust."}

payments > Will not make more payments until the payment daemon is restarted!

Some go out if I 0 the balances of miners and they get small payments.

I tried moving coins around and that didnt help.

https://www.reddit.com/r/MoneroMining/comments/8s9fym/how_to_create_more_outputs/

Can anyone explain how outputs are created?

Outputs are only ever created as part of transactions. There are two types of transaction:

Coinbase transactions, a special type of transaction created with every block that is mined, which rewards the miner according to the emission schedule and any transaction fees paid.
Regular transactions, which spend existing outputs and create new ones.

So just keep mining more blocks and more outputs will be created.


Are there any plans to make monero addresses shorter? Monero addresses are quite long. Are there any plans to make them shorter?

No. The 2 keys from which the address is made are 256-bits each, and that's how it is. You can't put 2 cups of water in 1 cup. Not using "hex" but base58 for the encoding already made them shorter, but there's only so many letters in the alphabet. If you used a bigger alphabet it would make them shorter, but probably impractical.


What potential security risks are associated with sharing my view key? Is it safe to share my view key with my accountant or business partner? Can a view key be used to steal my funds?

A view key can NOT be used to steal your funds.  Think of it as a way of granting someone "Look, but don't touch" access.

It is important to remember that the viewkey allows you to see only incoming transactions, not outgoing, so it cannot grant you what would be considered a "live" view of the address' holdings.

Therefore a viewkey could safely be shared with your accountant or business partner, but they may also be aware that what they see may not necessarily reflect a true count of what the address contains.


Formula to calculate mining earnings (PPLNS/PPS) I'm looking for a formula to calculate my pool earnings (PPLNS pool) like this website... Their calculation is based on:

network hashrate
pool hashrate
exchange rate (1XMR = ~130$)
fixed block reward
block time

and obviously:

hashrateobviously
power consumption (W)
power cost
pool fee

So is there is a function to calculate my monero earnings in a PPLNS pool? (and PPS also but not so important to me...)
Thanks in advance!!

Calculate earnings specifically for PPS or for PPLNS is pointless as the divergence is based on how often the pool find a block. If you are trying to find an average, then both payment methods equals.

So the formula you found is the best you may have to estimate your earnings.

If you want to calculate the expected earnings from a past day where you know the time window (the N * blocktime from PPLNS) and the number of block found you have to calculate earning from each block based on your average hashrate divided by the average pool hashrate on the same time window.

A basic formula would be ((your hashrate) / (the network hashrate)) * (720 blocks per day) * (block reward) = XMR/day then - (wattage cost per day)


Does the network benefit more from a local full node than through a VPS? Not having much technical background, I was wondering if there is an actual difference running it locally (99% uptime) or on a VPS, on terms of how much benefit the network gains from it?
(Considering the recommended vps is located in the USA, while i'm located in central europe in a country that hasn't got much nodes according to the nodes-map)

A VPS would likely have more uptime than a personal computer.  Also, if you were running a business to accept Monero, you could scale up your capabilities.
You would also not use any local bandwidth with a VPS.

As to node efficiency, there would be no difference between a VPS and a local installation.


is this how (address new) is supposed to work? So I ran (address new) 5 times creating 5 subaddresses and sent some money to subaddress 3.
In this session I could run (address new) again and it would return a subaddress in index 6.
Running (address all) returns all addresses up to index 6.
close wallet

On reopening wallet running (address all) only returns the primary address and subaddresses up to the last used subaddress (in this example 3) and on running (address new) it returns the same subaddress at index 4 instead of a new subaddress at index 7.

Is this how it is supposed to work? Is this on purpose?

Is it because wallets wont save subaddresses that arent used, but since each one is created from the previous that once one is used, all previous are saved?

Subaddresses are deterministic, so the "new" command is revealing each next subaddress in the sequence to you.

The wallet is supposed to remember how many subaddresses you've asked to see. If you terminate the wallet process instead of shutting it down gracefully, it may not write this count to disk.

Therefore when you reopened the wallet, it observed the incoming funds at subaddress 3 and then had to assume that you had not issued any further subaddresses since it had not managed to properly store that information previously.


What significance does the wallet public spendkey and public viewkey have in a transaction? I was just wondering what function does the public keys in a wallet address have in creating a transaction or receiving a transaction from someone?

You have a public and private spend key, and a public and private view key.

The public spend and view keys are used to create an output that only you can see that exists, and that only you can spend.

You use your private view key and public spend key to detect the existence of that output.

You use your private view key and private spend key to spend the output.

In algebra, your public view and spend keys are A and B.

Your private view and spend keys are a and b.

The output created for you is P = Hs(rA)G+B, where r is a random value known only to the sender.

You detect it by calculating P' = Hs(aR)G+B, and checking if P'==P. (Where R is a value published with the transaction, and is calculated as rG. Note that just as R=rG, A=aG and B=bG. Hs() is a hashing function that returns a type of number called a scalar).

The reason that P'==P is because rA==arG==aR, and this is called an Elliptic Curve Diffie Hellman Exchange.

The output P is actually a public key, for which you need the corresponding output private key to spend.

The corresponding output private key is x = Hs(aR) + b, according to the laws of Elliptic Curve Cryptography algebra.

Note: P is also known as a stealth address, because it is a one-time value written into the blockchain instead of your wallet address being written into the blockchain (as it would be in Bitcoin). An observer cannot determine that P is linked to your public view or spend keys, because this can only be determined if your private view key a is known.


What are some ways I can disguise my mnemonic seed? I'm thinking of storing my mnemonic seed on a few pieces of paper in secure locations, but I'm worried other people might find one of them and steal my funds. What are assume ways I can disguise this mnemonic seed so that people don't realize what it is if they find it?

From fluffyponyza here:

  Due to the nature of the key you can write it as part of something else - eg. write a fake love letter to your wife so that the 24 words on the left hand side are your key or whatever. Then write a bunch of extra love letters. That way, if your deposit box is ever discovered, it'll be disregarded as unimportant love letters".

Also, only the 3 or 4 first letters (3 for english, 4 for other languages)  of each word matters


What factors are influenced by ring size selection? What factors are influenced by the ring size (mixin) selection?

Does choosing a higher mixin always lead to better privacy?
Does choosing a very high mixin contribute to blockchain bloat?
How does the mixin selection impact transaction fees?
Is the minimum mixin also the recommended mixin for most use cases?

Answers below:)

Yes, except if you're consistently using some weird number like 103, in which case you're leaking the fact that every transaction using that mixin might be yours.
In a way, yes, but you're paying for the physical size of the transaction, so if you can afford to stuff the Monero blockchain you can afford to stuff all the others.
Linearly; if a mixin of 3 takes up exactly 1kb in signatures, then a mixin of 6 will take up exactly 2kb in signatures. The actual numbers are a little different, and will be further different with the addition of RingCT, but Monero fees are low enough that you can consistently use higher mixins without concern.
The minimum enforced mixin is 2 (ie. your signature plus 2 others). We will likely raise this with RingCT, as transactions will tend towards 1 or 2 inputs. I'm of the opinion that the minimum mixin for typical cases is around 5, and around 20 for higher threat models.


How do I check the process of mining, ie the percentage of a block to be finished? How do I check the process of mining, ie the percentage of a block to be finished ?
I have started the mining process, and the CPU is always 100%, I'm just wondering how far along that CPU work brought me to the goal of finding a block.
Where could I check the progress?
Thank you.

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

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


Hardware and Monero Mining I was wondering if anyone has built a monster super rig or heard of anyone doing so? I've just been doing research by browsing the Internet and was looking for a motherboard that would hold as many CPU's and GPU's possible. I found this:

http://www.supermicro.com/products/motherboard/Xeon/C600/X10QBI.cfm

Although, I'm not certain if it would fit the application of mining. It will hold up to 24 cores and has 11 PCI-E slots. I was imagining putting 11 R9 295X2's in it. From what I understand the 11 dual core GPUs would bring around 16.5Kh/s and I'm unsure about the combined 24 cores of the CPUs, but I'm guessing maybe another 1Kh/s? Totaling 17.5Kh/s for a current value of ~2.5BTC a month. I understand that we would be dealing with bleeding edge everything so that would = mucho $$ for considering such a build which = insanity, but I'm just in the mood for speculation and I want to start a real discussion about mining Monero. I simply don't see an in depth thread anywhere that explores many options, so why not start a discussion on the Monero stack exchange? I, occasionally win substantial amounts of BTC gambling and I want to build a computer next time I hit it big. I, not only, want to mine Monero, but possibly other cryptos that may rear their heads. I thought about also adding a significant hard drive to rent out memory on for one of the cloud service cryptos out there, possibly use for some gaming, and anything else that may emerge that piques my interest. So, for me personally, I would like to have a well rounded rig. I hope that there will be people who are very tech savvy that will help me and any others brainstorm on what hardware to use for their Monero mining build. And, yes, what I'm looking to do, primarily, is mine Monero. With both CPU and GPU at the same time. Possibly dedicate some of the hashing power to running a full node. I just want to have options for whatever else may come along. I want to run Ubuntu on Lenux as well which would be a first for me. I have previously only used Windows. The i7 I'm using now doesn't support aes-ni so I can't find any way to mine other than using... ... ... Minergatecringe and I get absolute diddly squat. I only have 0.09XMR after five days of mining. I'm sure others are in similar situations. I am inclined to think that it would be more cost efficient to built two separate rigs, each with 8 cores and 6 PCI-E slots, allowing for slightly more GPU power and and 2/3's the CPU power that the above build would have. Probably being more profitable. Please advise... also, feel free to suggest edits or add to this thread with more questions about hardware for mining Monero. Hopefully this will be a nice resource for anyone looking to start mining Monero and crypto in general.

The "24-Core" supported by the motherboard you linked to is per-CPU, (e.g., E7-8890 v4 has 24 cores), so per quad-socket motherboard that would be 96 cores. However, these CPUs cost >$7K each yet you won't benefit much from the n-way architecture when mining. Compare that with less than half that price for a 20-Core, 2-way CPU. Those n-way motherboards are very expensive too, you pay a premium for the ability to to have 4 CPUs in the same machine. In addition, if at some point you'll want to use the rig with Windows after all, take into account that for anything above 2-way you must use a Windows Server, another premium-priced component. Bottom line, although you "waste" a core per rig for the miner, several 1 or 2-way rigs will likely yield better mining power per $$$ than a single 4- or 8- way rig.

The above discussion doesn't take into account the cost of hosting, if you intend to host the rigs in a data center then the form factor can have a significant impact on the overall cost.

As for GPU mining, for that you don't need much CPU power, you can use your current machine and just add a strong graphics card. Before you invest in multiple graphics cards make sure the mining software you intend to use can support your configuration.


What's are the details of the Monero burning bug? There is an official news here.here

Practically speaking this bug is exploited as follows. An attacker first generates a random private transaction key. Thereafter, they modify the code to merely use this particular private transaction key, which ensures multiple transactions to the same public address (e.g. an exchange's hot wallet) are sent to the same stealth address.

How are random private transaction keys generated, and how can I reproduce this?

Comprehensively detailed here: https://src.getmonero.org/2018/09/25/a-post-mortum-of-the-burning-bug.html

  Practically speaking this bug is exploited as follows. An attacker first generates a random private transaction key. Thereafter, they modify the code to merely use this particular private transaction key, which ensures multiple transactions to the same public address (e.g. an exchange's hot wallet) are sent to the same stealth address. Subsequently, they send, say, a thousand transactions of 1 XMR to an exchange. Because the exchange's wallet does not warn for this particular abnormality (i.e. funds being received on the same stealth address), the exchange will, as usual, credit the attacker with 1000 XMR. The attacker then sells his XMR for BTC and lastly withdraws this BTC. The result of the hacker's action(s) is that the exchange is left with 999 unspendable / burnt outputs of 1 XMR

To answer your comments:

  I want to know how to generate a random private transaction key

Key generation happens here.

  Also insert the key into the detailed source code? I want to reproduce it.

It cannot be reproduced as the bug was patched.


What is the easiest way to setup a new public Oxen service node? What is the easiest and fastest way to setup a public Oxen service node?

Follow the guide here as of May 2021:
https://docs.oxen.io/using-the-oxen-blockchain/oxen-service-node-guides/full-service-node-setup-guide
If setting up a brand new Ubuntu 20.04 server, you just need the following commands:
sudo curl -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg

echo "deb https://deb.oxen.io focal main" | sudo tee /etc/apt/sources.list.d/oxen.list

sudo apt update

sudo apt install oxen-service-node

oxend status

If you want to skip the downloading of the entire blockchain, you can always fetch the entire blockchain from:
https://public.loki.foundation
Just download and replace it directly to: /var/lib/oxen/lmdb
Another alternative is put this in a bash script and run it on a fresh install of Ubuntu 20.4:
#!/bin/sh
sudo curl -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg
echo "deb https://deb.oxen.io focal main" | sudo tee /etc/apt/sources.list.d/oxen.list
sudo apt update -y
sudo apt upgrade -y
apt install fail2ban magic-wormhole ack-grep oxen-service-node -y
systemctl stop oxen-node
cd /var/lib/oxen/lmdb
rm data.mdb
wget https://public.loki.foundation/loki/data.mdb
chown _loki: data.mdb
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile swap swap defaults 0 0" >> /etc/fstab


Problem Restoring Wallet from the Monero GUI, Right Arrow Greyed Out My Monero wallet shows 0 XMR. I'm trying to recover it by restoring it from the GUI.  After inputting my address and keys, the right arrow is greyed out so I'm unable to get to the next screen to continue my wallet restore.  It happens on both options--"restore from seed" and "restore from keys".  Does anyone know why? I don't know the restore height but that says it's optional anyway. I'm using the Windows 64 bit version 0.11.1.0 Helium Hydra.

I had this same problem. When I unclicked both "stagenet" and "testnet" the arrow became available.


How can individuals safeguard themselves and the community against a key reusing fork? Regardless of the true intention behind the MoneroV developers, it forking off the existing Monero blockchain poses danger to the privacy of Monero users. While the MoneroV forking date has been put off, it may (un)surprisingly occur punctually next month. And we definitely cannot be sure whether a State Sponsored Agency may be planning a similar attack in the near future.

I am concerned about what I, as an individual, can do to safeguard (1) my funds; (2) my privacy; (3) other Monero users' funds; and (4) other users' privacy.

Question: What can I do before and after the "fork attack" to mitigate its risks?

From what I've read in the linked QA and elsewhere, some people suggested the following, though I am not sure about their effectiveness, or whether these methods will actually expose me or others to greater danger.

Don't claim coins in fork
Churn after fork

Preferably to a new wallet
Preferably multiple times
Preferably using either (1) all key images being after fork, or (2) a good mix of pre- and post-fork key images
Preferably with a higher-than-default ringsize, and when others are also churning with the same ringsize. Note that the upcoming hard fork... I mean network upgrade... will increase minimum ring size to 7.
Preferably not right after the fork

Any non-technical measures e.g. redirect newcomers interested in the forked coin to original Monero; discourage exchanges to list fork coin...

First, there is no stealing possible, so your funds are safe ASSUMING THE MONEROV (OR OTHER KEY REUSING FORK) SOFTWARE IS NOT A TROJAN. If it is not, then the key reuse only affects one of the privacy layers Monero offers, and does not allow either double spending nor stealing. Of course, since monerov is currently closed source, it may be that the binaries are a trojan to steal keys.

The main danger by far is the unravelling of ring signatures caused by using the same pre-fork output on two different chains with different rings: since the key image on both rings is the same, an attacker can deduce the real input is on both rings, and using random rings means only one input will usually match. This can be prevented by reusing the same ring on all chains, in order for the intersection to be the whole set. This will be done automatically if both forks use the shared ring database which Monero included in response to this threat. The shared ring database ("ringdb") will store the rings used for your outputs, so they can be reused when spending the same output again. It will be included in Monero 0.12, which will be released in the next few days. Hopefully the monerov people will include this feature too. If they do, then its use will be automatic.

If they do not include it, or include a broken version of it, then it's only half automatic (on the Monero side), and you will have to be more careful:

spend on the key reusing fork
check the rings used by your key reusing fork transaction by running print_tx TXID on that fork's node dameon (the rings are near the top of the transaction printout)
use the set_ring command in Monero's monero-wallet-cli to save those rings to the ringdb, eg:

set_ring KEY_IMAGE_HERE relative A B C D E F

A B C D E F should be the ring printed by print_tx TXID. Those are encoded as relative offsets. If you obtain the rings as absolute instead (maybe from a block explorer), then replace "relative" with "absolute" in the command above.

then spend monero, and any ring will be reused as required.

Now, some people may not use this, and thus will strip themselves of privacy in the process. For these cases, Monero includes a second line of defense, to allow your rings to avoid using outputs which are known spent (since using one of those decreases the privacy ring signatures offer). This is the blackball database. This can be created locally if you have both chains using the monero-blockchain-blackball tool, eg: monero-blockchain-blackball ~/.bitmonero/lmdb /path/to/monerov/database. This will take a while to scan the databases. Once this is done, the wallet will automatically avoid the inputs which were found to be unsuitable.

Note that since this process takes time, the blacklist database will be made available on the getmonero.org website, and can be imported (using blackball FILENAME in monero-wallet-cli, or from the "Shared ringdb" page in monero-wallet-gui). It will be updated on the site from time to time, so can be imported regularly.

Last, a third line of defense is to alter the fake output selection algorithm:

The first one, called either segregate-pre-fork-outputs in monero-wallet-cli or "I will spend on a key reusing fork" in monero-wallet-gui, ensures that spending a pre-fork output only uses pre-fork fake outputs, since spending on both blockchains will moot post-fork outputs.

The second one, called either key-reuse-mitigation2 in monero-wallet-cli or "I might spend on a key reusing fork" in monero-wallet-gui, uses a selection of pre and post fork fake outputs to avoid special degenerate cases.

In any case, a key reusing fork will only affect ring signatures, and will not do anything against stealth addresses nor confidential transactions, the other two layers of protection in Monero.

As a last warning, be very wary of using your secret keys with other software, especially closed source. These are called secret for a reason.


How do I run a remote node on windows (so I can connect mobile wallets to my own node) I couldn't find a detailed answer specifically for Windows users.  What is the simplest way to get a Windows 10 full node able to accept a connection from a mobile wallet so I can connect to a node I am in control of?

I extracted the Monero files to monero folder in C:

Right click on monerod and create a shortcut.

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

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

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

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

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


Are any of the exchanges posted on site checked by anyone are any exchange sites on https://www.getmonero.org/community/merchants/#exchanges page verified

Please take notice of the disclaimer:

"Please note: these links are being provided as a convenience and for informational purposes only; they do not constitute an endorsement by the Monero community of any products, services or opinions of the corporations or organizations or individuals listed. The Monero community bears no responsibility for the accuracy, legality, or content of these external sites. Contact the external site for answers to questions regarding its content. As always, caveat emptor ('buyer beware'); you are responsible for doing your own research. Always use judgement when making online purchases."


Should one disable the Windows firewall for the Monero Wallet GUI? I have read a report on Reddit for this YouTube video that some users apparently need to disable their Windows firewall in order to be able to use the Monero Wallet GUI. Is that really needed?

I'm asking because I have tested a fresh Windows 7 system in VirtualBox, and I didn't need to disable the Windows firewall for the GUI to connect to one of the moneroworld.com nodes.

To connect to one of moneroworld nodes, one has to establish an outgoing connection. Default firewall policy is to allow outgoing connections and block incomming connections. So you don't need to tweak the firewall to connect to these remote nodes.

For your own full node, that would be the opposite. This SE explains how to remotely access your own full node.


I forgot to enter a payment ID I just entered the wallet ID but not entered a payment ID. How can I recover my payment ? Please help me.

If you omit a payment id, the monero still reaches the destination wallet owner, but that wallet owner does not have the information needed to know what the incoming monero is intended for (ie, for which of my clients is it). You then have to ask the recipient to do the manual work of checking they received the monero, and credit them to your account specifically. For this, you will need at least the transaction id, but more info (such as amount) is better, as anyone else could otherwise claim this txid and "brute force" the recipient.
The recipient could also ask you to prove your transaction. This is done using the get_tx_key command in monero-wallet-cli. This prevents any spoofing. In any case, this is manual work for the recipient, so please try to remember to include any payment id that's requested next time.


Is the code freeze affecting mining? Is the code freeze preventing xmr-stak from running correctly? I have been away for a little bit and just tried to boot up my miner, but I keep getting "result rejected by the pool" displayed.

A code freeze wont prevent you from mining correctly. I suggest ensuring you are using a miner and pool that supports the current Monero hashing algorithm and ensure you have configured the miner correctly, as if you are getting shares rejected, this is the first place to look. But no, nothing to do with a code freeze would cause this.


What is a mixin, and how does it work? What actually is a mixin, and how does it work?

Is it similar to mixing services that Bitcoin and DASH provide?

The mixin count refers to the number of other signatures (aside from yours) in the ring signature that authorizes the transaction. A default mixin of 4 means that there are 5 total signatures. Someone looking at a transaction with a mixin of 4 has no way of knowing which of the five signers is the true sender (source).

"Mixin" as a term used in Monero is different than how the term may be used for Bitcoin or DASH mixing services. In Monero, new transactions "mix" with other previous transactions in the blockchain in the way the protocol itself dictates. In other services, you "mix" your coins with other users' coins to make one transaction with many inputs and outputs. The verb used here is the same, but they are referring to two very different things.

To try and reduce confusion, some community members have advocated changing the name "mixin" to something that will differentiate it from traditional mixing services. You can see some discussions here on StackExchange, on Reddit, and on the Monero forum.

A higher mixin number will typically provide more privacy than a lower mixin number because it will provide a greater amount of plausible deniability. However, reusing an odd, recognizable mixin for your transactions will make your transactions stand out. To see more about what mixins provide the greatest level of privacy, see this post.

The GUI allows users to select a mixin between 4 and 25. The CLI allows users to select any value permitted by the network.


Is there anyway to calculate how much privacy is gained by increasing the ring size of a transaction? The default for wallets right now is 4 but is there a large benefit say using 15 or 20 over 4? Can this be measured? Bigger ring size will help obviously but after a while is it not kind of a waste of transaction size?

A mixin of 4 means there are 4 decoys in addition to the real input, which means the ring size is 5.

No ring would be needed at all if your output could never be associated with you. However, the exchange or person that gave you the output does know you control it  if you told them who you are.

Therefore a ring size of 5 means that when the person that gave you your output sees that the output has been used in a transaction, then when you spend it they can see there is a 1 in 5 chance it was actually you that spent the output. That's until someone else uses the output you were given as a decoy in their own transaction. Then the chances it was you is 1 in (total number of outputs that exist in ring signatures that include your output as a possibility).

Of course, due to stealth addressing, the person that gave you the output in the first place gains nothing from knowing there is a possibility you spent it, because they can't tell whom you spent it with.

So increasing the ring size beyond the default only really matters if someone knows which outputs you were given, and the vendor you spend your outputs with is hacked or otherwise leaks information about what outputs they've received.

If someone that gave you an output can see that you could have spent that output with a compromised vendor because the vendor has been hacked, then they know that the probability that it really was you that transacted with that vendor is 1 / 5, or more generally, 1 / ring size.

Bottom line: I don't see any reason to not use the default ring size.


How do ring signatures work when there are multiple UTXOs from which you have to collect monero coin? User A has 3 UTXOs which sum up to 10 XMR. How does the Key Image ensure that all three utxos cannot be double spent?

First, in Monero, each output has a unique corresponding key image. Therefore, if a transaction includes three (or multiple for that matter) outputs (that are used as inputs), there will be three (multiple) corresponding unique key images included in the transaction. This ensures none of the outputs can be spent twice. In addition, for each output that is used as input in the transaction, there will be a "ring" with decoy outputs to obfuscate the real input. Put differently, the ring is created to not reveal which output is being spent.

Practically speaking this works as follows. Alice has received, say, two outputs of 3 XMR and one output of 4 XMR. She subsequently creates a transaction for 10 XMR. Now, all three outputs and their corresponding key images will be included in the transaction. If she chose a ring size of 7, each input will be "surrounded" by six decoy outputs to create a ring of seven inputs.

Note that an example of a ring size 7 transaction with three inputs can be found here. As you can see, there are three key images included:

d215c7c214b5cf6e3d2ee5ddf10275054356081f278419801cd711ebe3ba37b7
8c7c48a9ee209f5da3542ee27e70451f9673731b876b6168adc67ca78ae844ad
795b529ca0625f2a045b99ccd404bb9e3c8811ef30b63dd1a1acac7ad0b74593

In addition, each input has a ring of seven inputs.

Sources / Notes:

More information about the key image can be found here.
Technically Monero does not have UTXOs. All outputs are TXOs, because a blockchain observer is technically not able to determine whether an output has been spent or not.


Backward compatibility and updates The current plan is for bi-annual updates (hard forks) "for the forseeable future".  What is the policy or plan for:

Backward compatibility for existing daemons and wallet versions? For how
long will previous versions be supported after a new release?
Introducing auto-updating software, or end-user notification of new versions being available?

Can users rely on their software being up-to-date without having to keep checking the reddit or github sites? Is the current policy documented anywhere?

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

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


How do I multiply 2 public keys? I want to make DH-like key exchange calculating something like this:

b = H(b0B1B2)

But the problem is multiplication between two ec-points is not defined on ec-curve.

I know monero makes some transformations like public key -> secret key here https://github.com/monero-project/monero/blob/4b728d7dd48584987f53995a141baac4f886f017/src/multisig/multisig.cpp#L77:

  rct::key sk = rct::scalarmultKey(rct::pk2rct(k), rct::sk2rct(blinded_skey));
  crypto::secret_key msk = get_multisig_blinded_secret_key(rct::rct2sk(sk));

Can I use the same trick? Is it secure?

knacc is right - there's no way no just multiply to ec-points. I solved my problem by making key exchange:

b = b0b1B2


Wallet RPC transaction notification I am trying to use the --tx-notify feature of monero-wallet-rpc with curl.

--tx-notify 'curl http:xxxxxx/sample/%s'

But this isn't triggering my function at http:xxxxx/sample/%s.

Is there something wrong with my argument code?

Thank you

Is seems to be a bug: monero-wallet-rpc should have printed an error message in RED telling you that it could not find curl, because you did not give the path to it. Surely, since you would have obviously read such an error message if one had been present, it must have been missing.


Features and security of new GUI compared to the command line wallet For those that like the official command line wallet and are comfortable using it, is there any reason to switch to the GUI once released? Does the GUI contain any new features that the command line wallet does not?

For those that prefer to use graphical interfaces, are there any new security concerns associated with the GUI that do not exist with the command line interface alternative?

The GUI has a QR code display, and a "tracking" mode, where a merchant can setup a transaction (new payment id, a particular amount), let a customer scan the QR code, and detect when the matching payment is seen on the pool or the chain. This still needs software on the customer side which can read the QR code and automatically present a tx to send, which the GUI can't do yet.

The GUI can also start/stop the daemon, saving you a few keystrokes.

It doesn't have anything about cold wallet signing, however.


Can miners choose to accept lower fees? Currently, transactions cost at least 0.002 XMR per kB.

If a miner includes a transaction with a lower fee, will his block be rejected by the network?

The block will not be rejected if it's included in a block mined by another miner who accepted it. See src/cryptonote_core/tx_pool.cpp, line 137 (or just after FEE_PER_KB).

This implies a miner is free to mine transactions with a fee lower than this, and any block found with such transactions will be accepted.


Running monero in its own virtualbox, performance issues? I'm looking to run monero inside a ubuntu virtualbox vs having it run in the open with other apps around. From a security perspective, this should be safer. Since I'm not mining, what performance issues would I run into? I can see the vbox image would be over 30gb due to the blockchain size. Any way to reduce this aswell?

Running any program inside a VM comes with a slight-to-moderate hit in performance. It really depends on how you set things up both on the host computer and inside the client OS. You say you want to use VirtualBox so I am going to assume you're going to run and configure the VM via the GUI and not do anything special with it.

If you're going to run Ubuntu (Desktop I'm assuming again) you're going to need at least 2 CPU cores and 2GBs of RAM for a decent user experience. On top of that you will need to have a big virtual hard drive to contain the blockchain. As of 20 september 2017 my chain is 28.5GB and still growing (I was a bit late with updating the daemon). You would need at least another 10GB for Ubuntu itself. That number includes spare space for future updates/patches and a small swap space). I would recommend to make a virtual disk file of at least a 100GB so that you won't have to do anything complicated to grow your disk file soon. I know from personal experience that writing and reading to this disk file is pretty much on par with that of a real drive.

As far as performance goes you won't really notice the two shared CPU cores. You will notice the 2GBs of always allocated RAM, or rather the lack thereof, as that's a big chunk of RAM for most computers. It will cause more swap usage on the host as less RAM is available for buffering files and such. The disk space is gone either way, whether the chain is stored inside the VM or on the host it does not matter: 28GB is 28GB. Ubuntu itself pales in comparison to the size of the blockchain so I just leave that out of the equation. The disk IO for the blockchain is small enough that you won't really notice it. Especially not if you're using an SSD. You probably would notice some delays in the host if you use a regular hard drive and if the host itself also does a lot of disk IO.

Now monerod itself uses (very) roughly around 20% of the Athlon X4 620 I'm using to power my miner. This will be much less on more modern CPUs. It also uses around a 100MB of RAM and the combined reads/writes are less than 2MB per second from/to the drive. That's nowhere near breaking point for any recent hardware.

So, running a monero node inside a VM is perfectly possible. The VM itself is absolute overkill though and you could save a lot of CPU power and RAM by using a container solution like LXC. If you do want to stick to VirtualBox use Ubuntu Server to ditch the heavy GUI and strip out any unneeded parts. You could probably get away with using a single core and 512MB of RAM then.

And lastly. Don't forget to turn on Intel-VTx/VTd or AMD-V (hardware virtualization) in the BIOS/UEFI. This is the single biggest performance booster for any kind of virtualization. Some computers (like the laptop I'm typing this answer on did) might need a BIOS update for the option to show up. Consult the manual of your motherboard for more information regarding this option.


Is there any way to turn a payment id into a readable message and not randomness? Is there a way to set a payment id as a regular message instead of random characters? What format does it have to follow?

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


Monero Testnet Faucet How to run monero node in testnet mode for testing purpose and how to get testnet coin? Is there any testnet online portal for testing?

Start the daemon: monerod --testnet and then once sync'ed...
Start the wallet in another window: monero-wallet-cli --testnet to create a testnet wallet, then...
Back in the running daemon type: start_mining <your-wallet-address-here>
Wait to mine a block. You'll then have testnet coins.


Transaction structure: Question about ecdhInfo This question by kenshi84 shows how the pseudoOuts and outPk fields can be validated by anyone (without knowing any of the private keys involved), by checking that sumIn === sumOut:

> var H = ge_scalarmult(cn_fast_hash(ge_scalarmult_base("0100000000000000000000000000000000000000000000000000000000000000")), "0800000000000000000000000000000000000000000000000000000000000000");
undefined
> H
"8b655970153799af2aeadc9ff1add0ea6c7251d54154cfa92c173a0dd39c1f94"
> var fee = swapEndian(d2h256("30000000000"));
undefined
> fee
"00AC23FC06000000000000000000000000000000000000000000000000000000"
> var feeH = ge_scalarmult(H, fee);
undefined
> feeH
"527e4c0b6e34f948fb59ab014ec8eedf9eccfda4930a0b30d12790a0ec0d91f2"
> var pseudoOuts = ["276f03ba8c7852cb545830f7fedcdcd08789675d2a6c265bea236d0de90f6b11", "c611cc551db3b05ad6e5dba4ce89a8eeeb18317d8b565031941e98b6b9b8db4f", "8a088f1ccd11dd1633a663538faa9cb18c157b4fd37c421697a6356b4d7a98f6", "9e1238add1c1a4712904e5d5d8913482dcd6d31af166bc73918fd8148a42f22b"];
undefined
> var outPk = [ "f9cabc6b0fd32822feb3e13c70b54b2cdc2a3ce7c88ac661c29ab20732e2974f", "cfb010382648e11d7d5744fe8051c8606f31c901f9ede5b7e392f73790f9e7f8"]
undefined
> var sumIn = ge_add(ge_add(ge_add(pseudoOuts[0], pseudoOuts[1]), pseudoOuts[2]), pseudoOuts[3]);
undefined
> var sumOut = ge_add(ge_add(outPk[0], outPk[1]), feeH);
undefined
> sumIn
"a340fb56b64d831d4f06079f1fc4d507a7a2d1b0107ea7814c626c7394190da6"
> sumOut
"a340fb56b64d831d4f06079f1fc4d507a7a2d1b0107ea7814c626c7394190da6"

It's nice to have working javascript code (you can try by opening a browser console here), and I wonder if my question can be answered in a similar way.

I've noticed that the ecdhInfo field wasn't used in the above javascript code. Is there a way to validate ecdhInfo too, without knowing any private keys? Or is this not necessary?

For reference, here's rct_signatures from kenshi84's question again:

{
    "type": 2,
    "txnFee": 30000000000,
    "pseudoOuts":["276f03ba8c7852cb545830f7fedcdcd08789675d2a6c265bea236d0de90f6b11", "c611cc551db3b05ad6e5dba4ce89a8eeeb18317d8b565031941e98b6b9b8db4f", "8a088f1ccd11dd1633a663538faa9cb18c157b4fd37c421697a6356b4d7a98f6", "9e1238add1c1a4712904e5d5d8913482dcd6d31af166bc73918fd8148a42f22b"],
    "ecdhInfo": [ {
        "mask": "c626b75f726e88a26fc74c1bb508fa9358c0896a7635d0f1256c7f43f0217706",
        "amount": "63c1d97047ff515ccd5ca271f4e5013b9c1092c25307207a0ff037b13f492c00"
      }, {
        "mask": "73b4367f9b143c0a453598f85761698c4548e890fa52a05b4e28183126525008",
        "amount": "81b48b46e79b458a234ad36d3d0890f89e30d50cc18a687dd94fd0ef3417da0f"
      }],
    "outPk": [ "f9cabc6b0fd32822feb3e13c70b54b2cdc2a3ce7c88ac661c29ab20732e2974f", "cfb010382648e11d7d5744fe8051c8606f31c901f9ede5b7e392f73790f9e7f8"]
 }

Both the ecdhInfo mask and amount are encrypted by the sender of the transaction.

Both are encrypted (each in a slightly different way) using the transaction's shared secret (aR).

Therefore both encrypted values will be randomly distributed, and thus cannot be validated by a third party.

If the sender of the transaction had somehow written faulty values into the transaction, the only consequence would be that the outputs created by the transaction would be unspendable.

The code that encrypts and decrypts the ecdhInfo values is here: https://github.com/monero-project/monero/blob/2b00899bb28e09f0c44813689acc0add73832215/src/ringct/rctOps.cpp#L447


Monero coins locked after sending money My whole balance locked after sending money. I have read about monero locking balance on the internet.
Balance blocking is only monero blockchain feature or all cryptocurrencies? Bitcoin locks money too?
I want to ask about solutions.
What if I received one transaction 1000 XMR once and I want to send coins to several different wallets? Do I have to wait about 25 minutes between transactions?
Is there a way to make it more comfortable and faster?
Hooe for your help!

New outputs are locked for 10 blocks (unless the sender selects more), which is about 20 minutes on average. If all your monero is in a single output, then sending it will lock your entire balance for that number of blocks. There are two ways to avoid having to wait when sending to multiple recipients:

ensure your wallet is made up of several outputs, so only what you send gets locked
send to several recipients in the same transaction

For the first case, you can send to yourself, ie:

transfer MYADDRESS 10 MYADDRESS 10 MYADDRESS 10 MYADDRESS 10 MYADDRESS 10

This will send 50 monero to yourself, and you'll end up with 5 outputs of 10 monero each.
For the second case, something similar:

transfer ADDRESS1 10 ADDRESS2 5 ADDRESS3 2

The change will still be locked for 10 blocks, but you've paid the three recipients already.


How can I change the wallet password? I'm curious if there is a way to change the official CLI or GUI wallet password.

CLI: The new version (v0.11.0.0 at the time of writing) has an option to change your password. Simply type password and it'll provide you with an option to change your password. As a general remark, you can type help to obtain a list of commands and their options.

GUI: Currently aforementioned option isn't implemented (yet). You'd have to create a new wallet by restoring from the 25 word mnemonic seed, which allows you to set a new, different password as well.


Monerujo deamon adress I just downloaded the Monerujo wallet and trying to figure it out. Is there an instructions page? I don't know what to put in for a deamon address.

I just downloaded the Monerujo wallet and trying to figure it out. Is there an instructions page?

Yes. Read the README, FAQ. As this app is still in APK form and not released to the app store, use caution and read the disclaimer:

You may lose all your Moneroj if you use this App. Be cautious when spending on the mainnet.

For maximum privacy, connect to a daemon that you run yourself. You can also choose to use a remote node such as those listed by MoneroWorld:

node.moneroworld.com at port 18089
node.xmrbackb.one at port 18081
node.xmr.be at port 18081

In order to fit the format required by the Monerujo app use (example from above list): node.moneroworld.com:18089


Monero 11.0 worked now I can't get 12.0 to load it crashes I'm a Windows 10 user. I had a working GUI in 11.0 (it took forever to get it working but yes it worked) and now I don't in 12.0. I've sent money after the fork using 11.0 (ignorant to the fork) and not only can I not get that back but I can't get the 12.0 GUI to load it at all. It works in the low-graphics mode but not the regular mode. How to resolve this?

Your funds are not gone as long as you kept your keys and know your passphrase. Have you tried running the GUI using a different computer?


How to get the time at which a transaction was added to the pool? Can we get information about when a transaction was added to the pool and also when it was mined into a block?

Is there a demon RPC to get that. Or is it generally stored in the block header?

The get_transaction_pool daemon RPC returns the current state of the txpool. The transactions field in the reply is an array of data for each transaction currently in the pool, and includes a id_hash field (the txid) and a receive_time field (the time it was received). Reminder that since the txpool is a local thing, different clients will receive transactions at different times.

The time a transaction was mined into a block is that block's timestamp. Daemon RPCs like get_block_header_by_height and others give you data which includes a timestamp field, which is that time. Note that this timestamp is miner controlled, and thus can deviate about two hours from the real time.

Both of these times are UNIX timestamps, which means they're seconds since the epoch (1970/01/01).


How to run a local daemon with GUI? I downloaded 0.10.3.1 GUI, made a new wallet and just finished synchronizing. I went to start solo mining and am getting an error message saying that it, "Couldn't start mining. Mining is only available on local daemons. Run a local daemon to be able to mine (screenshot: https://i.imgur.com/agrWr73.png)".

I am super new to all of this, but couldn't find the answer searching around so any advice setting this up would be super helpful.

If you get this error, then you probably altered the default daemon settings to point to a different daemon. If you did not, then this appears to be a bug. If you did, then you need to undo those changes. Then, starting the GUI will ask you whether to start the daemon, and you can then accept. After some time spent  syncing the blockchain, you will then be able to start mining.

Note that solo mining in this way, while you get an equivalent long term expected gain, means you get a LOT of time with nothing, and get a whole block reward very infrequently. It does however help the network more than pool mining.

If you've not yet synced a local daemon, I recommend upgrading to the latest version (0.11.0.0), which has substantial improvement on the sync time and download size. Replacing your binaries with the updated ones is the only thing that's needed to upgrade.


Buy with Address instead of integrated address - monero wallet GUI I ve used my address instead of an integrated address to buy monero coins via an online plateform and now the balance of my wallet is not updating. Does anyone know what I should do in this case?

When verifying with xmrchain.net, I get this:

the balance of my GUI is still set to zero, while via the CLI I get a balance that corresponds to the Monero I bought

How can I get the balance to sync on my GUI, I really have to update my node because it is time consuming?

Your screenshot proves that the transaction was sent. By using your view key and address in the decode outputs section of that page you can also see the amounts (currently hidden thanks to RingCT).

The fact that you are attempting to connect to a remote node (based on your comments about connecting to the moneroworld node) seems to indicate that you have not synced your own node yet. If your node is stuck, please try this

Alternatively you CAN connect to a remote node (until you have the time to sync your own node). Follow the instructions on this page again. A list of available nodes is available here


Is there a way to set ask-password 0 as the default when opening up any monero wallet file? I have a bunch of wallet files and when I do a refresh via the command line, it hits me with the password. I can set ask-password to 0, but is there a global setting that I can put somewhere for all future wallet files I create?


Can known spent outputs be pruned? In Monero's early history, many transactions did not include any decoys. It was extremely clear that these outputs were spent.

Could Monero prune these known spent outputs?

Here is an example transaction from block 100000: 9c3c0086ef9aa98f370dac303c5dca109678bf95c9e4252e103dab16dce46fa8

It has a ringsize of 1 and 5 inputs:

2192316b89c7a120a57f24f1d87fac4ad1b39df70c861fe8ec16dad8e9038f61

b255b6c7ae1a10a4673320f32599cb972f1acc63f00abb02d331d6482fcea8c2

5dffd991c54e38a7374d6e54a0be5b6c6c98cae0fa00558b57a0c878f7f258e1

2c74d3187d7576f469928cead3a80e0c855784fea05d086aae3e83a72d56e25f

b41f74b78aaf1c07bda9926d630e06187b5ca1f90e00d3dd23d41f26cc10b598

Since all of these outputs are known to be spent in this transaction, is it possible to prune/delete all record of these outputs and their key images? Are there any significant downsides to doing so?

In theory, yes. In practice, this might be a bit harder, depending on how the data is laid out in the on-disk blockchain database. Typically, for access speed, data is laid out in a fixed size vector, like this:

A B C D

Now if you want to prune C, you end up with

A B _ D

The space used by C is now unused, but you may not necessarily be able to reclaim that space easily. It is a similar problem to memory fragmentation. Somtimes you can compress this to

A B D

But if you have fast index based access to elements, you have to keep D at offset 4. So it depends on how the database is structured.

Nevertheless, some of that data can be pruned without such problems. You do lose the ability to query the database for those outputs, though.

In any case, you do not want to delete their key images, or they'd be spendable again.


Why is the function open_tx executed twice for each transfer command? I built a private testnet with reference to this guide.

In order to understand how the secret transaction key is generated, I examined how many times the open_tx function (in device_default.cpp) was executed with a transfer command from the monero-wallet-cli. open_tx is the function used in construct_tx_and_get_tx_key function (in cryptonote_tx_utils.cpp) to generate a secret transaction key.

It turned out that open_tx was executed twice per one transfer command. Why is open_tx executed twice instead of once?

In short, tests.

You can see this by following the path taken by the CLI wallet when doing a transfer, as you essentially end up in create_transactions_2. If you follow through that, you will see transfer_selected_rct gets called from various places (1/2 & 3), and it's that which makes calls through to open_tx via construct_tx_and_get_tx_key. Thus a test tx performed in create_transactions_2 will call through to open_tx, as will the final real one.


What altcoins do you see as competitors to XMR in the privacy space? XMR is obviously king of  anonymity, but there will be plenty of innovation in the crypto sector and I think there is room for multiple privacy coins.

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


What takes the most computing time in a monero wallet? What functions take up most of the time for a new or restored simplewallet?

Is it the scanning for its own inputs?

What code line does the most heavy lifting in the simplewallet codebase?

Lets say I restore a wallet from a block  14 days ago, what checks are performed, after I get all the blocks and pruned tx data, that take most of the time.

The two main operations in terms of CPU usage are determining if an output is sent to you (is_out_to_acc_precomp, defined in src/cryptonote_basic/cryptonote_format_utils.cpp) and generating the key derivations that is_out_to_acc_precomp acts on (generate_key_derivation, defined in src/crypto/crypto.cpp). There is some threading there, but it could still be sped up.

Both of those end up calling low level crypto functions, such that a profile looks like this:

  18.00%  monero-wallet-cli          [.] fe_sq
  17.54%  monero-wallet-cli          [.] fe_cmov
   3.21%  monero-wallet-cli          [.] fe_invert
   3.08%  monero-wallet-cli          [.] fe_divpowm1
   2.86%  monero-wallet-cli          [.] fe_sq2
   2.35%  monero-wallet-cli          [.] fe_add
   1.75%  monero-wallet-cli          [.] select
   1.62%  monero-wallet-cli          [.] keccakf
   1.16%  monero-wallet-cli          [.] ge_p2_dbl
   0.97%  monero-wallet-cli          [.] ge_scalarmult_base
   0.80%  monero-wallet-cli          [.] ge_scalarmult

There are a couple asm versions of those, which proved to give some substantial speedup too, see https://github.com/monero-project/monero/pull/2317


How can I slow down or disable cli wallet's automatic locking due to inactivity? While using monero-wallet-cli, I am frequently getting this message:

 ____________________________________________
/ I locked your Monero wallet to protect you \
\ while you were away                        /
 --------------------------------------------
        \   (__)
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Locked due to inactivity. The wallet password is required to unlock the console.

How can I disable this behavior or increase the timeout?

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


Which ASIC manufacturer (if any) made ASICs for XMR in the past? I checked out the medium post by MoneroCrusher over at medium.com which indicates that at one point in time, ASICs were most likely operating on the monero network.
Has anyone figured out who was behind it?

There may have been others, but at least Baikalminer[archive] and Bitmain[archive] launched Monero ASIC miners in 2018.

It's worth noting Bitmain allowed people to buy the ASICs, but didn't actually ship them until after the Monero hardfork - meaning only Bitmain themselves were able to mine XMR on their own ASICs, and knowingly scammed their customers thereafter.


Relation between monero jobs (blob) and new blocks When you are mining in a Monero pool (e.g.,https://minexmr.com/) you keep on receiving jobs from it. These contain the blob which, after some processing, is mined by the miners.

Different jobs received from the pool can refer to the same previous block. In fact, the prev_id of the block header (first part of the blob) across different jobs received from the pool could be the same. I couldn't find as specific answer to the following questions:

When does the pool decide to send out a new job also with the same prev_id (which should mean that no new block has been mined yet)?
Does each miner already connected receive the same job message?
If a miner is working on an job that has the same prev_id of the one received does him stop and starts to work on the new one immediately? I know this is true if a new block has been mined but in this case the prev_id changes.

Thank you

Pools send a new job when they see a new blockchain height, in response to a getjob request, in response to a login request or sending a job to a miner with a new difficulty. prev_id will stay the same so long as the blockchain height is the same.
Almost exactly the same job. Each miners job is identical except for the jobs extra field in the blob which makes each job unique for each miner. The pool updates this field for each miner before sending.
This is up to the miner implementation. A miner should ideally stop mining a previous job when they are notified of a new job, but there's no harm in finishing the existing one before starting the new one as most pools will still accept shares from recent jobs.


Do regular Monero users need to update after hard fork? I use Monero for my own purposes. Do I have to update the client after the hard fork or I can use my current one?

Yes, you will need to upgrade.

For the particular HF of 2016-09, maybe not immediately. Note that if you keep the funds in cold storage your funds will still be safe even if you don't do anything now so just holding is safe. However, if you should want to spend them, you would need to use upgraded software.

For example, if you keep them in cold storage for a long time you might skip a few hard forks. Then, to spend, you would just need to install the latest software and import the backup to start spending.

Hard Fork 2016-09 Notes

quoting dEBRUYNE's reddit post:

  Not that much will change with the upcoming hardfork, but I figured
  this thread would be helpful anyway. If you didn't know yet, there
  will be a hardfork on the 21st of September. Currently, we are on
  version v2 blocks and with the hardfork we will switch to version v3
  blocks. The only (minor) change is that this fork will enforce
  coinbase transactions to be split in denominations.

...

  Assuming you are on version 0.9.4, you won't have to upgrade your
  wallet for this fork. That is, no preparation have to be taken for
  this fork. Note, however, that 0.10 is going to be released soon and
  in general it is advised to use the latest binaries, because they
  contain bug fixes and new features. In addition, to prepare for the v4
  fork you will have to update to 0.10, because v4 will allow both
  conventional transactions and Ring CT transactions.


How is the one time address generated from the public address? Given the public address, how is the one time address generated. Also, cryptographically, what links them?

A one time address for Bob is generated by taking a random r, multiply by Bob's public spend key, hash the result and multiply it by the curve base point, adding (in ECC terms) Bob's public view key.

The private key can be derived from this public key without further information.

See 4.3 in https://cryptonote.org/whitepaper.pdf for the details.