How does commitment to zero work? Given two inputs each with their respective committed amounts; P1, P2.

Then given two outputs each with their own respective committed amounts; P3, P4.

We want to prove that the inputs - outputs - fee * G = 0

P1 = a1 * G + r1 * H
P2 = a2 * G + r2 * H

P3 = a3 * G + r3 * H
P4 = a4 * G + r4 * H

C = zG = (P1 + P2) - (P3 + P4)

if amounts are balanced, which means that (a1 + a2) - (a3 + a4) = 0

We then have zH = (r1 + r2 - r3 - r4)H

The sender should know z because it is the blinding factors, r1, r2, r3, r4.

r1, r2 are given to the sender from his previous transactions.
r3, r4 are created by the sender to blind the new output amounts.

--- While writing this I have come up with a possible answer. Please check.

If the amounts do not balance out, for example, let's say the sender decides to not include P4.

Then we would have C2 = P1 + P2 - P3 = (a1 + a2 - a3)G - (r1 + r2 - r3)H

Since we do not know the relationship between G and H, the prover cannot sign unless he solves the DLP.

This brings up another question brought up by a friend:

What if the sender decides to cancel out the blinding factors part of the commitment instead by cleverly choosing the blinding factor?

Clarification on cancelling the blinding factors:

Let C = (a1 + a2 - b1 - b2)G + (r1 + r2 - r3 - r4)H

Assuming the amounts do not cancel out, so a1 + a2 - b1 - b2 does not equal zero.

What is stopping the sender from choosing r3 and r4 in such a way that r1 + r2 - r3 - r4 = 0 , then singing with the key as (a1 + a2 - b1 - b2) ?

Example of cancelling out:

For clarity we will say that C = xG = aH, where a is amount and x is blinder.
Bob wants to send 10 Monero to Alice.
Bob has two inputs one with 8XMR and the other with 2XMR.
Bob also has their commitments C1 = 10G + 8H and C2 = 12G + 2H.

He creates the output to be Alice, but being dishonest he sends her 8XMR and creates the commitment to the output like so: C3 = 22G + 8H

Calculating Sum(in) - Sum(out) we get:

C1 + C2 - C3 = 0G + 2H

Bob then signs with his key as "2"

My question is why is this impossible?

Firstly, your G and H are the wrong way round. Each Pedersen commitment is actually xG + aH where x is the blinding factor and a is the amount. So where you are writing P1 = a1 * G + r1 * H, I would write: C1 = x1G + a1H.

  If the amounts do not balance out, for example, let's say the sender decides to not include P4.

A transaction is invalid if it has more outputs than there are commitments for. It will get rejected.

  What if the sender decides to cancel out the blinding factors part of the commitment instead by cleverly choosing the blinding factor?

This makes no sense without defining how they "cancel out the blinding factors". You are suggesting a way the underlying math could be broken without defining how / a way.

Update now you have tried to explain

You cannot arbitrarily change the blinding factors. Quoting from Zero to Monero, 5.6.2:

  Indeed, z follows from the blinding factors if and only if input
  amounts equal output amounts (recalling Section 4.1, we don’t know γ
  in H = γG).

Given you cannot change the input commitments, the only thing you can do to create a valid commitment to zero, is by having your output commitment balance against the input commitments. In simple terms, if the input commitment is 5, only an output of 5 gives a commitment to 0.

Update based on question edited again

Your new edit just shows Bob burn 2 XMR. He spends input amounts 8 and 2, but only has one output, 8. Thus 2 burnt.

Further,

  C1 + C2 - C3 = 0G + 2H

  Bob then signs with his key as "2"

No, Bob would be signing with 0. Recall the number next to H is an amount, not a blinding factor.

With respect to the title question:

  How does commitment to zero work?

The commitment to zero is a point, zG. This is the sum of all the input commitments blinding factors x, minus the sum of all the output commitments blinding factors y, multiplied by G.

See section: 5.6.2 Commitments to zero.

All of the details are covered extremely well in the Zero to Monero paper. Refer to sections 4.1, 4.2, 5.6.1 and 5.6.2.


Pregenerate 1000 subaddresses from your monero private key? Is there a way to pre-generate 1000 subaddresses from your monero private key? And then say I sent some xmr to the 979th subaddress, would the wallet see it or do I need to do something first?

Is there a way to pre-generate 1000 subaddresses from your monero private key?

Generating subaddresses from a private view key explained in this answer and on the monerodocs site here.

  And then say I sent some xmr to the 979th subaddress, would the wallet see it or do I need to do something first?

The default wallet lookahead indices are set to 50:200 (50 accounts, 200 subaddresses). So if you are creating the subaddresses outside of the wallet (so manually constructing them from the wallet private view key), you will need to tell the wallet about them. You can do this in the monero-wallet-cli via the set command: set subaddress-lookahead 50:1000


Mining a custom coin based on Monero I am creating a custom coin based on Forking Monero.

Once the build process has been completed, how do I go about actually mining the coin?

Is it possible to modify XMRIG to do this?
https://github.com/xmrig/xmrig

Im going to assume you've setup a mining pool for your "custom coin", just set the correct algo perimeters on xmrig and point it to your mining pool. Nothing needs to be modified in XMRig


Can I cancel a transaction? I sent a transfer but the transaction is still in the transaction pool. Can I cancel it?

No, not really. If you didn't include a big enough fee or something it will fall out of the mempool after a day or so, but there's no way to ask all the nodes that have your TX in their mempool to kindly forget about it, afaik.


Can you use an integrated address when withdrawing from bittrex or other exchnages? Currently bittrex can find out if you reused a monero address if you used the same one. Can one use an integrated for bittrex withdraws? integrated addresses is the public key and the payment id combined. But is it still a "real" address where you can use it in replacement of giving out your main monero address?

An integrated address is a valid address, and if the exchange has implemented the support for integrated addresses, you can use them as destination when withdrawing from the exchange.

However, the basic monero address and the payment ID can be recovered from an integrated address (integrated addresses are just a way to pack an address and a payment ID together, nothing is encrypted). Therefore whether you use a basic address or an integrated address (for that basic address) to withdraw, the exchange will know that these withdrawals have the same wallet as destination.

Using different sub-addresses for each withdrawal can hide the fact that they have the same wallet as destination.


How can I choose addresses to create a ring signature for a transaction I am doing a project based on blockchain, and I found that Monero is a good candidate for my project because of its ring signature scheme.

The scenario is that I would like to create a transaction and choose a group of addresses to produce a ring signature for this transaction. However, I cannot find the method to produce a ring signature of addresses I choosed.

I am wondering is there any convenient way to achieve this goal?

The code that currently randomly selects inputs is here:

https://github.com/monero-project/monero/blob/ebbd001a89ddbe0de1d1af297a04db8911f15e09/src/cryptonote_core/blockchain.cpp#L1666

You can modify this code to instead specify your own choice of inputs.


Why is the number of total block confirmations different in different pools? I visited https://monerohash.com/#pool_blocks. It confirms every block 50 times
while  http://minexmr.com/#pool_blocks uses 20 confirmation only. Can anyone explain to me why this is happening?

This is arbitrary, and the pool chooses what they are confident with.

Some number of confirmations are needed to ensure the pool really has the mined monero before they pay miners. If a pool were to pay miners as soon as it mines a block, it would risk that block being orphaned (ie, another block takes its place on the chain), and it would have paid money that it does not, in fact, have, causing monetary loss to the pool. Since it becomes harder and harder to orphan a block as it gains confirmations, waiting fixes that problem.

Another reason for most pools to wait for 60 confirmations is that coinbase tx outputs are locked for 60 blocks, so those new monero are unusable for 60 blocks after mining. If a pool wishes to pay miners before 60 blocks, that pool has to have enough other monero to cover those young blocks.


How many new Monero are mined every day? If there are 720 blocks mined and the amount of coins that are made for each  block is 10.88, but let's just say it's 10.5 coins per block, do we not just multiply 720 by 10.5?

720 x 10.5 = 7560

At time of writing, emission (new Monero) is 1.085279 per block. Block target time is 120 seconds, so that's an approximate 781 XMR per day (1.085279 * 720), which is constantly decreasing until it hits 0.6 XMR per block (tail emission, ~432 per day).


How do I re-enable incoming connections? Over the course of several upgrades, I have been running monerod for many months now, and I have always connected to incoming peers.  For the last few months, it was always 8+37.

After running git pull, then backing up my wallet and keys file, then running make clean, and then make, now when I run monerod, my connections are always 8+0.  It's been like this for over 24 hours now.  Nothing changed with my router, so what might I need to do with my monerod config/settings to start accepting incoming connections?

If it helps to know, I run monerod --rpc-bind-ip my.comp's.homenet.ip --confirm-external-bind (which is the same as I've always run it, though I suppose the --confirm-external-bind wasn't needed before) on Ubuntu 16.04.2 LTS, on version v0.10.2.1-1dfed89.

I was suffering from something similar yesterday. When I turned my OS X firewall off, I got the incoming connections back. When I turned it back on, I got 0 incoming connections again.

To fix it, I ended up forcing port 18080 open using this guide. Scroll down to the 10th comment if you need help using Vim (I did). I turned the firewall back on and I got the incoming connections back.


Which is the best way to integrate Monero in a e-commerce website? I'm a big supporter of Monero and I would like to use it on an e-commerce website as a payment method, but I don't understand the best way to implement it.

Should I use a payment provider?

This really depends on your level of technical expertise and website requirements.

If you can run your own node on the host, running that and the monero-wallet-rpc yields an easy to use JSON RPC interface you can make use of to process Monero payments.

If not, there are payment providers like GloBee, which help accepting multiple currencies and offer support etc.


You may now start monero-wallet-cli. What should do I next? My monero says  "You are now synchronized with the network. You may now start monero-wallet-cli" then I started "monero-wallet-cli" but it shows Starting Refresh...
I tried to start mining with 'start_mining' command but it says insert wallet address <addr> [<threads>]
I have my wallet address, I tried to copy and paste but it doesn't work, and what is THREADS? How check my wallet is correct to mined?
What commands need to do next?

I was need to start my wallet 1st and then typed: 'start_mining 4'
It solved my problem started mining with using 4 CPUs, don't need add command from 'monerod'


Monero wallet code base dependencies and APIs? I would like to know what dependencies the Monero wallet application for Linux or Android code base has, such as Chromium or Google APIs?  Is there a list of them somewhere without having to dig through the source code?

Thanks

For compiling, the dependencies are all listed in the project's README file. When built as static binaries though (the way the releases are built), there are no runtime dependencies, but if you compiled as dynamic, the libraries listed as dependencies are then required to be installed on the target system.

For any Android/iOS wallets, you will need to consult with those particular projects.


How do bulletproofs work? There are lots of questions on this SE about how RingCT works, but not on Bulletproof. I would like to know the algorithm (Proof of correctness not necessary, since I can work that out), but the whitepaper uses notation that I fail to understand. I'm looking for something akin to the answer here, but for Bulletproofs.

RingCT consists of two parts: traceable ring signatures for inputs and range proofs for outputs. Bulletproofs are an alternative form of range proofs that replaces the Borromean scheme. Bulletproofs themselves consist of two parts:

expressing the binary encoding of the committed amount in the form of vector dot product, and
compressing the vector dot product argument to logarithmic size which builds on Bootle et al.'s EUROCRYPT 2016 paper.

Bulletproofs are much more complex than the Borromean scheme, and I don't think it's suitable for being briefly explained in this StackExchange format; directly consulting with the original paper seems to be the most effective way of understanding it. Or one could look for someone else's attempts at trying to decipher it (still not quite brief yet, though):

https://doc-internal.dalek.rs/bulletproofs/notes/index.html


Please Help! -- GUI wallet Daemon failed to start and can't find log or monerod I'm running the GUI wallet v0.15.0.2 with a Ledger Nano S (the Ledger is updated as of yesterday) on a mac. When I open the wallet I keep getting this message "Daemon failed to start. Please check your wallet and daemon log for errors. You can also try to start monerod manually."

I've scoured the monero guide and the internet and can't seem to solve this. I can't find monerod or monerod.exe on my computer and my firewall is completely turned off, so that's not the issue. I've re-downloaded the GUI app and still no monerod.exe.

How/where can I check the daemon log or run monerod manually? I'm really at a loss. Any help would be greatly appreciated!

monerod.exe is not applicable, it is a Windows program.   You can find monerod inside the monero GUI app folder. It would be located here normally: /Applications/monero-wallet-gui.app/Contents/MacOS/monerod.  The GUI would be in the same folder.

It sounds like you are still very new to all of this, so you might consider connecting to someone else's remote monero node initially, then setup your own full node once you have more experience.


Is it possible to send from integrated to standard address? i just tried to send Monero, but got an error. apparently the site i want to send from uses a 64-bit integrated address, and the site i want to sent to uses a standard address

is it possible to add a payment ID, and would it work then?

Is it possible to send from integrated to standard address?

Yes, of course. You simply send from the wallet you created the integrated address. This is because funds aren't technically sent from an address, they are set from a wallet that previously received funds.

  ...the site i want to send from uses a 64-bit integrated address

Integrated addresses are not 64-bit. An integrated address is just a standard address with an encrypted 64-bit payment ID embedded in it. This is why integrated addresses are longer than normal addresses.


How to construct a transaction with multiple inputs (joint payments)? I sometimes encounter Monero transactions with more than two inputs. If I have access to multiple wallets, how do I construct a transaction with multiple inputs from different wallets?

I sometimes encounter Monero transactions with more than two inputs.

This is very common and happens automatically. Your wallet uses outputs it receives, as inputs to fund a transaction. Sometimes your wallet will need to use multiple outputs (as inputs), to fund a transaction. This however is different from your question:

  If I have access to multiple wallets, how do I construct a transaction with multiple inputs from different wallets?

To send/join funds from different wallets you need to first send funds from each of the wallets in question to a single wallet that will do the ultimate spending. This could also be a multisig wallet if there are more wallet owners than just yourself.

A couple of guides:

https://monerodocs.org/multisignature/
https://monero.stackexchange.com/a/5647/7493


Is there a way to force sync on Monero GUI? I'm using the Monero GUI to download the Monero blockchain; but most of the time, after I open the GUI and start daemon, the "network status" at the lower left bit shows only the "connected" text. Ocassionally, it will shows it's syncing and how many blocks there are left; but I don't know what actually triggers it. Sometimes, even though the GUI doesn't show it, the daemon appears to be syncing as I witness the blockchain size rising.

At any rate, I'd like to be able to know and see that the daemon is syncing and not just running on the background doing nothing. Is there a way to do that on the GUI?

Under the Settings tab you can click the Show Status box.  If you want to leave this open, it will intermittently post the daemon status(I am not sure how often it updates though), or if you prefer, you can type a few commands to activate info manually(the command box is to the right of the Close box; this is your CLI interface for the GUI).

Commands to see status of daemon: status or sync_info

You can also type help to see the rest of the commands and what they do.


Is there a way to get the latest blocks from monero rpc I'm looking at the documentation (https://getmonero.org/resources/developer-guides/daemon-rpc.html), I see there is a way to get the information of a single block, but I can't find the method to get the list.

The only way I can think of is:
- Get the latest block.
- With the "prev_hash" get the previous block, and get his "prev_hash" and look for the next one.

Is there another way?

You can use the getblocksbyheight, which is a binary call for speed. Or getblockheadersrange, getblockheaderbyheight. You get current height with get_info.


Couldn't connect to daemon: 127.0.0.1:18081 I have not used the Monero Wallet GUI (v.0.12.0.0) for MAC OS (10.13.6) for about 3 months. I try to connect -

"Error: Couldn't connect to daemon: 127.0.0.1:18081

Height: 1548149/1548149 (100.0%) on mainnet, not mining, net hash 857.62 MH/s, v7, up to date, 0(out)+0(in) connections, uptime 0d 0h 0m 0s

2018-08-20 15:06:06.095      0x7fffa05e2380    ERROR   net.http    contrib/epee/include/net/http_client.h:456  Unexpected recv fail
Error: Problem fetching info-- rpc_request:

2018-08-20 15:12:52.899      0x7fffa05e2380    ERROR   net.http    contrib/epee/include/net/http_client.h:456  Unexpected recv fail
Error: Problem fetching info-- rpc_request:

Error: Couldn't connect to daemon: 127.0.0.1:18081"

I downloaded the new version the Monero GUI - v.0.12.3.0. When I try to connect I get "Please check your wallet and daemon log for errors. You can also try to start monerod manually." After I go to the daemon settings,  I see the same " Error: Couldn't connect to daemon: 127.0.0.1:18081"

I try to stop_daemon through the command:

What should I do with this error?

"Unexpected recv fail" is typical of a timeout. There were a few relevant issues that got fixed since then, you should update to 0.12.3.0 and try with that. Or 0.12.4.0 if it gets released before you get to update, as it should be soon.


Clarification with cryptonote-utils BEGIN_SERIALIZE() macros I am making some modifications to cryptonote-utils for a cryptonote with a different block format than what it is built for.  I've never done serialization before so I am just now learning about the concept.  Let's take this as our example from cryptonote_basic.h:

BEGIN_SERIALIZE()
VARINT_FIELD_N("major_version", major_version);
VARINT_FIELD(timestamp);
FIELD_N("nonce", nonce);
FIELD(nonce);
END_SERIALIZE()

I understand that we are essentially converting all of our fields to hex (EDIT:binary not hex) and lining them up against each other to be efficient and create our block, but I don't understand how that order is defined?  Is it defined by the order that I write them within the BEGIN_SERIALIZE() macro or is the order based off of their tags (or something else maybe I am missing)?  I would imagine they get serialized in the order I serialize them within the macro, but then I wonder why some fields have tags and others do not?  Is the tag name important?

I'm not the best with templates, so looking through serialization.h is quite tough for me.  I am also not quite sure when to use BEGIN_SERIALIZE_OBJECT vs BEGIN_SERIALIZE.  Thanks for helping with my noob questions!

Those marcos were written by a Russian who had too much vodka =). I have done C++ since I was 11 and I needed two hours to make sense of what they do.

First of all they are generic. They are used thought the code, and the resulting structures can be converted to a binary (network) format or json, so what you are doing here is only setting out the names of the fields and what you want the serialiser to spit out.

I don't understand how that order is defined?

Unless you create a data structure, it will just be a dictionary (key-value list) in the order of the macros.

Is the tag name important?

It will be the key in the dictionary. By default it will be the variable name in the code, but you can set it to something else.

I am also not quite sure when to use BEGIN_SERIALIZE_OBJECT vs BEGIN_SERIALIZE

Unless you know what you are doing use BEGIN_SERIALIZE_OBJECT


How can I check my solo mining hash rate? I need to find the command that lets me check my hash rate from monero-wallet-cli.  Further, what is considered a good hash rate?  I am running 2 threads.

The daemon mines, the wallet does not. The command to start mining from the wallet is a convenience function, which merely asks the daemon to start mining, and there is no convenience function to ask for hash rate reporting.

In the daemon, you can check hash rate either with show_hr as Guest said, or status. show_hr will continuously log hash rate, while status is a one off.

When using the GUI wallet, the daemon hash rate is reported in the "Mining" tab.


Boolberry's Transaction identification by prefix Boolberry has a feature named transaction identification by prefix, which allows to "cut ring signatures from the blockchain reducing block chain size by 60-90%, depending on mixin usage." Is this compatible with every CN coin? Does it have any disadvantages?

For more information on transaction identificiation by prefix

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

The comments in the code indicate:

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

The 3 parts of v2 transactions are:

prefix
base rct
prunable rct

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

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


Why not have Torsocks on by default while we wait for Kovri? Recently, funding has been allocated to pay for Kovri's development and integration into Monero. Kovri is a re-implementation of I2P, an anonymity tool similar to Tor in its goals, but with a lot of improvements, different protocol, and broader range. Following Monero's philosophy of privacy by default, Kovri will be on by default, effectively disconnecting user's IPs from the transactions they broadcast. That is all great news, but it sounds like it will take a year to be implemented. Meanwhile, Monero's nodes can already connect to the network using Torsocks.

By searching SE, I find only three threads mentioning Torsocks, and only five on /r/monero. So that tells me that even though that improvement in one's anonymity is only a Tor install and a terminal command away, maybe a lot of users are not doing it, or are even unaware that that is possible at all.

Why doesn't Monero already include Torsocks by default, and makes it so that whenever the user starts the daemon, it does so through Torsocks, without it even asking? As superior as Kovri might be, and as flawed as Tor might be, surely having nodes running through Tor beats running them in the clear, and nothing prevents that setup to be changed when Kovi is ready to go. What am I missing?

If the majority of monerod instances were wrapped with torsocks, but otherwise not Tor-aware, then the network would end up having to concentrate all of its traffic through the few nodes that weren't using torsocks. And I don't know the details of the P2P protocol, but in a lot of designs the discovery system could end up degraded or inefficient as well.

The basic problem is that you can't receive incoming connections to clearnet addresses when you're running through Tor. If you want to set up a web of connections, SOMETHING has to receive incoming ones.

You could use Tor hidden services, but that's a lot more complicated than just wrapping the client in torsocks, and you'd have to actually change the Monero P2P protocol to pass around .onion names instead of IP addresses. And any nodes that weren't Tor-aware couldn't connect to those at all... so in practice you would either have to either switch the whole thing over to Tor, or think very hard about how you were going to properly manage a divided network.

Basically you're talking about something almost as disruptive as the I2P transition, with at least some changes to the actual P2P protocol... and then doing it again when it's time to move to I2P. That doesn't make a lot of sense.


Why was I2P chosen over Tor for native Monero integration? Tor is currently much more popular than I2P. Why was I2P chosen (Kovri project) over Tor for native Monero integration?

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

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

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


Historical significance of FEE_PER_KB_OLD I discovered this term FEE_PER_KB_OLD in the code base, but it seems unused. What is the historical context around it? Was it ever used? I know in v3 of protocol the FEE_PER_KB was used, then in v4 it changed to the first iteration of the current dynamic fee algorithm. Was FEE_PER_KB used from the beginning?

Also, it sounds like the minimum fee is not enforced at the protocol level, just by node consensus (won't relay transactions with fees below the minimum). Was there a time where fees were ignored?

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

It is unused.

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

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

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

  Was FEE_PER_KB used from the beginning?

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

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

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

  Was there a time where fees were ignored?

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


Is there the equivalent of a BIP38 encrypted private key for Monero private keys? I would like to create plain text private keys for Monero that can be encrypted/decrypted using a process similar to BIP38. (https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki)

Is such a thing possible with Monero today, or would it need to be developed further?

Simplewallet may also need the ability to import these types of keys without having the mnemonic seed.

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

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

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

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

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

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

Seed                 :
70371fbdba4072dbff8c9350414cf9a903776791792d575557b697cb09952951

Private Spend Key    : cf1352ec36511623d07cbd21e86a9e4103776791792d575557b697cb09952901

Private View Key     : fd38a51dda45a8ff44042525477a572b93d3219d3751ca49f5aeb7f8278cdc0c

Public Spend Key     : ec8cc4f1f0622946bd24a41dc7a4d01964f4f6a878e0e8bf0ce0eb7214174979

Public View Key      : 853a5e0aa455820991cd8801ac7be09dbf347b8be875d208f08d97faf7fefb3b

Monero Address       : 4Ab2kg2ZXrgCqFp3HAnJfy5FMiPKtNaCFYxRnRpkWiG8MKuDfDLo67K2bqX9gXszpfTPLs6ng4YAd2Vj6wthUhk67icBjbC

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

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

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


Changing IP tables for Monero on Tails returns error When setting up Monero on Tails I get an error (Bad argument 'DNS_PUBLIC=tcp') when following the instructions given on the Monero Github site to change the IP tables with the below command:

Using Tor on Tails:

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

sudo iptables -I OUTPUT 2 -p tcp -d 127.0.0.1 -m tcp --dport 18081 -j ACCEPT
DNS_PUBLIC=tcp torsocks ./monerod --p2p-bind-ip 127.0.0.1 --no-igd --rpc-bind-ip 127.0.0.1 \
    --data-dir /home/amnesia/Persistent/your/directory/to/the/blockchain

You are missing a newline character between ACCEPT and DNS_PUBLIC.

The iptables rule addition is the command:

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

And the subsequent command:

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


0 XMR after mining for 30 hours I have been mining monero on my computer with 3 cpu cores and my NVidia 1060 gpu for around 30 hours, but when I check my wallet, it still says, that I have XMR 0.000000000000.
I am on arch linux, if that maes a difference.
Am I missing something really obvious?

Am I missing something really obvious?

Yes.
Now, you don't state whether you are solo mining or pool mining so I'll cover both. You also don't state your hashrate, but given your stated hardware of only 3 CPU cores and a mid-range GPU we can use 1.5 KH/s as a modest example - i.e. very low hashrate.
Solo mining: you don't earn any XMR till you mine a block. Given your low hashrate, you're looking at years before you mine a block, not hours or days.
Pool mining: you don't get paid anything until 1) the pool mines a block in a period you were mining and 2) you have reached the pool's minimum payout threshold. So even assuming #1 (the pool has mined in a block in the last 30 hours), again given your low hashrate, you undoubtedly haven't reached any payout minimum.


How can I get my hashrate and stats from my mining pool? How can I grab from monero pool my own hashrate speed? its dynamic page so I need some help:) I would like to create my own chart for my speed of hashrate when is up or down. Any idea?

Go to your pools config file ../config.js
i.e. moneropool.com/config.js
Get the your pools api variable:  var api="https://api.moneropool.com"
i.e. api.moneropool.com
to get pool stats add "/stats" to the api url
i.e. api.moneropool.com/stats
to get your stats add "/stats_address" and send parameters longpool and address
i.e. https://api.moneropool.com/stats_address?longpool=false&address=YOURADDRESS


After a fork, if a user opens an incompatible GUI/CLI, what information is presented to the user which says they are using old software? Now we are on 0.14.x software, what would happen if someone opens a 0.11.x, 0.12.x or 0.13.x GUI/CLI?

Also, when Monero forks again later in 2019, what will the 0.14.x GUI/CLI present to the user?

When starting the daemon, monerod, or one of the command line wallets (monero-wallet-cli, monero-wallet-rpc), if you are running an old version, it prints a warning message telling you an update is needed. It's worth noting that it does this by checking your blockchain height against the hard-coded fork heights, not by calling some remote update server.

I'm not as familiar with the GUI, but presumably it warns you also.


What is the difference between Monero (XMR) and Grin (GRIN)? I would like to have a comparison between the privacy and scalability features of Monero vs Grin. I have heard some people say that these are privacy-oriented coins, and I would like to learn more. What are the meaningful privacy and scaling differences?

Pardon the image, but there is no way to create tables in StackExchange.

Grin's privacy is best characterized as "Monero with aggressive pruning and no ring signatures." Users who are unable to get access to old information cannot pull up past transaction information by looking at the current ledger state. However, those who receive transactions as they are broadcast can see the inputs and outputs for individual transactions. This effectively indicates whether outputs are spent, something that is not possible with Monero. Grin uses "confidential transactions," a technology that hides transaction amounts, nothing else. The output transaction graph is hidden through obscurity of information, not anything committed on-chain.

Monero's scalability has improved significantly over recent years. Transaction sizes fell from ~13 kB to ~1.5kB. Monero now supports pruning, allowing users to ignore most of the information for old transactions. Still, Grin allows more information to be pruned, and they prune it much faster.

I did not include network privacy on this chart, since both Monero and Grin provide network privacy. Monero provides support for Tor and i2p, and it later will provide support for Dandelion++. Grin supports Dandelion++, and users can use Tor or i2p if they configure it manually. Transaction network obfuscation is important, but it's less important for most people than graph protection.

I like to think of Monero and Grin as projects that are pushing the privacy and scalability boundaries, each beginning in different positions. Monero is focused on a privacy angle with scalability second, whereas Grin has the opposite focus.


connecting wolf`s miner to monero daemon I want to start solo-gpu mining with wolf`s amd miner. in the config file i put daemon+tcp://localhost:18781 and so far its connecting to the daemon but I'm getting following message:

"Setting up GPU(s)"

"Successfully connected to daemon"

"Invalid username / wallet address"

how do I tell the daemon the username and pass to start with to accept the connection from wolfs miner, or maybe I'm wrong with the config file of wolfs miner?

thanks

This is my config:

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


How can I improve performance of my pool? I've been running a small pool with friends for several days with few blocks mined (yay!). I am running Clintar's fork of the pool code: https://github.com/clintar/cryptonote-xmr-pool

Now I know the code is open so I can start digging. I'm a professional software developer, so this is something I intend to do at some point, but I need to improve my general knowledge of Monero first.

Are there "standard" configurations I could set the improve my pool's performance without changing the actual code? Like connecting it to several nodes in a hope to receive chain updates possibly faster?

I know my question is a bit vague, but I don't exactly know where to start. Thank you in advance for any advice you can give me!

It is possible to run several nodes, in a load balancing way. I know of at least one pool which does this (crypto-pool.fr). The specifics, however, I can't say.

The usual suspects: faster CPU, faster network connection. For the latter, this may come in handy if you end up DDoSed. Unfortunately, there are DDoS campaigns from time to time on pools. Whether this comes from competing pools or just generic jerk kids, I don't know. But they come and go.

I see two ways you might improve performance if you want to change the code (first one is an already available change):

improve the performance of the daemon which supplies the pool with the block templates. There is a patch that exists (https://github.com/moneromooo-monero/bitmonero/tree/cache-block-template) which does this, and is said to reduce the CPU load a lot
improve the performance of checking miner shares. There are two ways to do this: skip some (there is a "trusted shares" setting in the pool config.json which you can tweak, it's a tuning where the more you trust miners, the less the CPU load on checking), and using AES-NI for the Cryptonight calculation (I'm not aware of a public patch for this though).

I'm sure there are other things you could look at, but these are two of the main ones that come to mind.


Wallet Portuguese seed words? How are the words for the seed chosen?

For e.g.

togoles doesn't exist its togolês and even that its a very odd word

again oigale its oigalê and still nobody uses this

Probably its supposed to avoid easier bruteforcing of a seed?

I'm asking because Portuguese words for the seed are very unusual and some are even wrong...

I would be glad to contribute for a seed Portuguese dictionary if there's a way to do so.

Thanks !

You can see the list of Portugese words Monero uses here.

Only the first 4 letters of each word matters (for Portugese). For other languages, it may be 3 or 4. You can test this by restoring from your mnemonic seed, changing 'togoles' to 'togoabc'. It should still restore.

If there is a better word you feel should be used instead of togoles that begins with togo-, then feel free to suggest changes on the Monero Github.


Will Monero host CryptoNote.org? It seems cryptonote.org is offline.
Will Monero community bring it back?
While Monero is a variant of CryptoNote.

Monero is not some entity
Welcome to the world of domain name ownership

I'm sure there are many people involved with Monero that would host a site at that domain name, getting control of the domain name is another matter entirely.


Why does my Monero wallet refresh so slowly? Refreshing a wallet generated from MyMonero private keys, it is refreshing at a rate that will take hours to complete. I use CTRL-c to stop the refresh and it helps by then moving to a higher block height, but this doesn't change the slow refresh rate.

Monerod (on Win10 laptop with 4 GB and SSD drive) is up and synced.

I find this curious. Wallets created at the same time are refreshing as per my normal experiences, a few minutes.

Any suggestions?

Latest Monero software has improved a lot the speed of refresh, be sure to have the right version from GetMonero.Org installed.

Also, if you're using a remote node, try to check if another node is faster.


Outputs on xmrchain.net show that I have a balance but command line says no balance I created a wallet with monero-wallet-gui, then sent my monero from bittrex to the address provided by the monero wallet.  The gui showed a zero balance.  So I checked for the outputs on xmrchain.net:

  Outputs (2)

  output public key  amount  output match?

  00: d509fe3dc481125d2962680d69bb89cd27d09dcf81e1f17cdccaa71602f83184
  ?
  false

  01: 0b6cfd6dbc3b3d0afc3854eb49857b401f00691c70c8773260580283f4565772   >2.571535700000
  true

So I checked the command line:
>

  [wallet 42ozcw]: balance
  Balance: 0.000000000000, unlocked balance: 0.000000000000

What should I do next?  What am I doing wrong?

I do have an address and a txId.

Chances are your node isn't synced with the blockchain or your wallet isn't refreshed with blockchain data. You can refresh your wallet against either your own node or some open remote node.

There are several options to refresh your wallet. If you want to run a full node note that it requires 32GB storage at the moment but has the advantage that you can later quickly refresh many wallets.

Open the GUI and keep it open until it shows "Connected" in the bottom left corner. If it's still catching up, you will see a progress bar and you need to let it finish by keeping it open.

When it says "Connected" then you should see your balance as well. Note that by default, the GUI also runs a node in the background. You can check its status by clicking on the "Settings" tab, and then on "Show status" button.
Start monerod manually and keep it open until you see "SYNCHRONIZED OK" message. You can check the status by commanding status while it's running and you'll see something like:

Height: 1424168/1424168 (100.0%) on mainnet, not mining, net hash 242.08 MH/s, v6, up to date, 8(out)+0(in) connections, uptime 0d 18h 46m 58s

If it doesn't say 100.0%, means your node has some catching up to do. Then, keep the monerod open and start your monero-wallet-cli in another window and it should start the refresh automatically. If not, just type refresh and it will start. As it finds transactions it will print some lines and at the end show you the final balance.
You can skip running a node by telling GUI or CLI to connect to a remote node instead of your own which saves you disk space but wallet refresh is a bit slower compared to a fully synced local node, especially if you have multiple wallets to refresh. You can follow instructions linked below:

How do I connect monero-wallet-cli to a remote node?

https://getmonero.org/resources/user-guides/remote_node_gui.html


Which currencies will be supported by GloBee? Besides Monero which currencies are currently supported by GloBee?

In addition to cryptocurrency acceptance does GloBee allow merchants to convert payments into fiat, like BitPay? If conversion are possible, which fiat currencies are supported?

Since PayBee is still in private beta, please specify if you know the answer will change after public launch.

GloBee is out from beta. Check http://globee.com website

GloBee will support Monero, Bitcoin, Bitcoin Cash, Litecoin, Dogecoin and Decred cryptocurrency payments. Merchant settlements will be handled in any combination of Monero, Bitcoin and fiat currency


Keccak vs Keccak-f permutation in cns008 Keccak is mentioned in cns008 (the cryptonight hash description) in two ways: First in section 3 (Scratchpad Initialization) as Keccak, and another time in section 5 (Result Calculation) as Keccak-f (the Keccak permutation).

It seems to suggest that the modified state from the original Keccak function is used as the whole input to another unique Keccak calculation, but the change to Keccak-f makes it seem like there is something special about it.

What is the difference between these two references, if any?

https://cryptonote.org/cns/cns008.txt

There is a difference between keccak and keccak-f in the spec.

In monero's cryptonight implementation, keccakf is a function that is used by keccak in a loop. It is the function that performs a single hash permutation on the keccak state and modifies it.

Because it accepts the existing keccak state (a 25 member collection of 64 bit integers, or 1600 bits), it is able to use the existing state object of the previous full keccak function. By this point in the process, the existing keccak state has been modified between bytes 64 and 191. The new version of the state object is used as the input to the keccakf function rather than as input to the full keccak function. This is why it is phrased differently in the spec.


Problem: Daemon failed to start. Timed out, local node is not responding after 120 seconds Unable to sync Monero GUI version 0.17.1.9  and Ledger nano s ver 1.6.1. wallet
I'm trying to sync GUI version: 0.17.1.9-release, in Advanced mode (Local node).
These are the steps taken to sync GUI wallet:

Launch Monero Desktop app
Put in 8 PIN to Ledger Nano s running firmware version 1.6.1
Typed in Monero wallet password
Get message "Opening Wallet" and
answer Export View key question on Nano s
Get message "Starting Local Node"
Network Status: Starting the node
Then I get "Daemon Failed to start
Timed out, local node is not responding after 120 secs

I upgraded from GUI version: 0.17.1.7 to GUI version: 0.17.1.8 to version: 0.17.1.9. "--enable-dns-blocklist" was typed in Daemon Startup flags a few attempts ago.
The app has not worked since about 30 December, at GUI version: 0.17.1.7.
The daemon log shows.....:
Error: Couldn't connect to daemon: 127.0.0.1:18081
[06/01/2021 15:34] 2021-01-06 15:34:43.853 I Monero 'Oxygen Orion' (v0.17.1.8-release)
Error: Couldn't connect to daemon: 127.0.0.1:18081
[06/01/2021 15:34] 2021-01-06 15:34:49.681 I Monero 'Oxygen Orion' (v0.17.1.8-release)
Error: Couldn't connect to daemon: 127.0.0.1:18081
[06/01/2021 15:35] 2021-01-06 15:35:01.367 I Monero 'Oxygen Orion' (v0.17.1.8-release) Error: Couldn't connect to daemon: 127.0.0.1:18081 ......... and so on
Suspecting the Wallet is corrupt I followed the CLI manual monerod process in an earlier answer to another user who couldn't sync. The process started to sync manually. After 10 hours I typed in EXIT  in CLI and tried the GUI wallet assuming corruption had been fixed. Still unable to sync GUI wallet and getting same error message:  Daemon failed to start. Timed out, local node is not responding after 120 seconds. Please advise how to fix my Windows desktop wallet.

Update to the new version 0.17.1.8 and use —enable-dns-blocklist


Monerod crashes on startup - Failed to create SSL certificate I am attempting to run a Monero daemon on my Ubuntu 16.04 machine. I followed these steps to compile monero, and have successfully compiled the binaries required to run a Monero daemon.

When I run sudo ./monerod in my ~/monero/build/Linux/master/release/bin folder, the daemon starts, but when it attempts to generate an SSL certificate after initializing the core RPC server, I receive the error:

ERROR net.ssl contrib/epee/include/net/abstract_tcp_server2.inl:970 Error starting server: Failed to create certificate

My daemon then shuts down. What step have I missed?

Fixed in PR#5257 https://github.com/monero-project/monero/pull/5257

Skipping extra unnecessary cruft.


Using same blockchain with more OSs Is it possible to use same synced blockchain with more wallets, deamons from different operating systems, eg. Windows and Linux?
Of course, not in the same time.

Well, it depends on what you're asking.

I run my node on Ubuntu Linux.  I have connected wallets from Linux, Mac, and Windows to the node running on Linux.  Connecting at the same time shouldn't matter.

If you're asking about having some network drive that is just connected to your router, and you want to run monerod from various computers around the house by using the --data-dir flag, and the computers will basically take turns at syncing the blockchain, that would probably work, as long as you don't mix chip architectures (x86 vs ARM).  It may or may not work across 32 vs 64 bit computers.  In general, I'm sure there are reasons why this is not a good idea, like how LMDB would behave, so hopefully someone can provide a more technical response to address that aspect.


Help please wallet seed restoration I accidentally deleted my monero wallet.

I was having trouble restoring the wallet via the GUI 12.3 using the mnemonic seed.  My seed is recognised when I attempt to restore the wallet. I previously used the seed to restore my wallet successfully post the change to version 12 of the GUI.

I know approximately the time I created the wallet and have set the block height  restore point 1 day prior.  I have also tried setting the restore point to the start of the blockchain without success.  I even tried creating the wallet on a different PC.

I have checked the settings of the GUI and the current block matches https://xmrchain.net/.

I don't really know what to do next.  I am not sure where I have gone wrong.  Am i correct in thinking that the mnemonic seed corresponds to a private key and would not change? Or is it possible I am using an old seed and I should have written down a new seed post the upgrade to version 12 or I could have changed this accidentally while using the wallet?

I would be very appreciative of any help that anyone could provide.

The Mnemonic seed is imutable. It does not change upon a version upgrade.
If your seed is recognized by the GUI or CLI, then it is valid.
Did you checked your balance before deleting your wallet file? Was it accurate?
You should see the incomming and outgoing transaction in your history after the wallet is synced. Check if nothing's missing here.


In Monero RandomX, What is the condition for a hash result to be considered the winner and be rewarded? I read RandomX design and specs from https://github.com/tevador/RandomX/tree/master/doc to understand the mining process.
At step 14 of the algorithn description it ends up with a result hash: R = Hash256(RegisterFile). In modern CPUs it takes around 1.6ms to calculate a single hash result in fast mode, so hundreds of hashes are calculated per second.
My question here is: How a miner knows which hash result among all other been calculated is a winner to be rewarded? What is the condition for the result hash to be a winner?
It is not in that docs and I couldn't find it Googling.

What is the condition for a hash result to be considered the winner and be rewarded?

The result (a hash), is just a 256 bit number. Every time you change the data you are hashing, you'll get a new, different and unpredictable 256 bit number. If it's smaller than another number (which is a representation of difficulty), you've can submit the block data used to create that hash to the network, and hopefully earn Monero.
A simplified example:
Let's say the maximum possible difficulty is 32, your hash function returns numbers between 1 and 32, and the current network difficulty is 2. You need to find a number (the hash), that when multiplied by the network difficulty (2 in this case), doesn't exceed 32, so you're looking for a number that's 16 or less – you have a 50% chance of finding a winner on each attempt, so you should find a hash that meets the difficulty requirement pretty quickly.
But when the network difficulty rises to say 5, your range of possible winning numbers is smaller; you're now looking for a number that's 6 or less – each attempt you now only have ~18% chance of finding a "winner". So, as the network difficulty increases, the range of "winning" numbers get's smaller.

How a miner knows which hash result among all other been calculated is a winner to be rewarded?

A "winner" is not the quite the right term to use here. Rather, does the hash (of the block data), meet the network difficulty requirement, as explained above. The reason I say this is because multiple miners may find results that meet the current network difficulty requirement. How quickly you advertise your "winning" block data and how well it meets the difficulty (how small the hash is), will help determine if you ultimately earn the block reward. As blocks are advertised and propagated across the network, multiple chains can form. Consensus as to which chain of blocks forms the main chain is reached based on most work done in any given chain. "Most work" here meaning the cumulative difficulty of blocks in a given chain. So long as your block ends up on the chain with the most work done, you'll earn Monero.
If it's not obvious, the block data itself (and thus the transactions it contains also), have to be valid – you can't just submit any old random data that produces a hash which meets network difficulty.


What does ‘divide CPU cache by 2’ mean? Ok. So I’m thinking about starting to mine some Monero. It will be my first time cryptocurrency mining experience, although I have been trading BTCs for 6 months now.

I have looked over Monero’s website and found a way to mine on my own using its GUI. I have a high-end MacBook Pro (Core I7 3.3GHz) and thought, why not? In this same section, I have came accross something called “threads” and “CPU division for better performance”. I do not want to fry my computer, so given my specs and the picture above, what should I type there where it says “CPU threads”, and then a number “1”? What should be the number?

Thanks!

Cryptonight, the Proof-of-Work (PoW) algorithm used by Monero, uses a 2 MB buffer to do its calculations. Mining speed is heavily influenced by whether this buffer can fit in your CPU's cache. If it can't, some reads and writes will hit RAM, and slow it down. Therefore, to determine the optimal number of mining threads (at least as far as cache is concerned), you work out how many such buffers can fit in your cache. If your cache is 4 MB, then 2 buffers can fit. This is where the "divide by 2" comes from. Note that if you use your computer at the same time as mining, you may want to go with fewer threads, so your normal workload does not get slowed down.

So, you'll have to check your system's specs to see how much cache it has. It's probably between 2 and 6 MB, giving 1 to 3 threads. In any case, it's safe to experiment with small number of threads, and see how your hash rate varies, then use the setting which seems to get you the best performance.

Note that mining using the GUI like this is called solo mining, as opposed to pool mining. In the long run, solo and pool mining give about the same expected mining gains. However, solo mining will be very much more unpredictable in the timing of the gains. It is like a lottery: you can play for a very long time without winning, but when you win, you win BIG. With pool mining, you win often, but only tiny sums. In the long run, it works out about equal, but make sure you are OK with this before choosing between pool and solo mining. Note that solo mining is also better for the network as a whole, as it avoids centralizing mining to the pools.

Good luck!


If I'm running a full node and wallet on my local network can someone get my wallet information? If someone connected to my WIFI could they get information about my wallet or steal from me?

Just getting connection to your WIFI would not instantly allow someone to see your wallet information, gaining access to your WIFI is only allowing first and foremost access to your internet connection.

However, someone with access to your WIFI could essential hyjack your information, if a few other things fall into place first.

If your WIFI router is set up as a Home/Work Network and Network sharing is turned on, then a hyjacker, could potentially view any files/ documents shared on your network. Your computer would have to also be set-up, to share files with the Home/Work Network, therefore, if for whatever reason you stored your wallet information on a non-encrypted file, then the hyjacker would aslo be able to access this information.
Another method to gain access to your wallet data is through: packet-data sniffing; if a hyjacker has gained access to your WIFI, and they have hacking knowledge (pretty basic hacking knowledge in all honesty) then it is possible for the hacker to "sniff packets" of data that you send over your WIFI, if at any point you send your private wallet data over the WIFI, then it is highly likely that the hacker will be able to see your private wallet information that you have sent through the WIFI.

To ensure your WIFI is secure:

Ensure your router has a Strong and Unique WIFI password.
Ensure your router firmware is upto date.
Enable WIFI encryption WPA2 if your router is newer than 2006, else WPA should be adequate but less secure
Change your WIFI SSID (Name) to make it less easy for the hacker to directly relate the network to yourself and/or allow the user to identify the brand of router that your network uses.


JS implementation of ge_fromfe_frombytes_vartime I'm working on JS implementation of Monero wallet. I got stuck with the ge_fromfe_frombytes_vartime method.

Original code: https://github.com/monero-project/monero/blob/v0.17.1.9/src/crypto/crypto-ops.c#L2310-L2424
Shen Noether's paper:  https://github.com/monero-project/research-lab/blob/master/whitepaper/ge_fromfe_writeup/ge_fromfe.pdf
monero-agent code https://github.com/ph4r05/monero-agent/blob/21e53a4dcbc6d6aab6ade6262de523223bce1b11/monero_glue/xmr/core/ec_py.py#L842
mininero code: https://github.com/monero-project/mininero/blob/c5fcee9d8ec8c302bca7fda8ce79b68e20d31c34/mininero.py#L238

Maybe somebody knows any JS implementation or more details explanation logic behind the ge_fromfe_frombytes_vartime method.

According to the CryptoNote Whitepaper, the hash-to-point algorithm is based on this paper.


Ledger and Monero GUI v0.14 transaction problem I'm using a Ledger Nano S with the Monero GUI wallet v0.14. It looks like the wallet is synced to the latest block. So I sent myself a small test transaction from an exchange but it shows in the wallet as 0 XMR received. I'm not sure what I'm doing wrong, maybe I'm on the wrong chain or something.

Any help would be greatly appreciated. Thanks everyone.

This appears to be a bug with v1.1.3 of the Ledger code.  It should just be a parsing bug.  You just can't see your funds for the moment.  You'll want to download v1.2 when Ledger releases it (maybe today), and then rescan the wallet.

If you have trouble getting it to rescan, you can rename the wallet file and open it again, and that will trigger a rescan.


How to set up password on xmrpool.net mining pool? I'm new to mining and I don't know how to set up a password and a username on xmrpool.net mining pool.

Can anyone help me to do this?

Username - your wallet id

Password - workerId:your@email

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


How to increase CPU cache on Raspberry Pi? I'm mining some Monero on my raspberry pi (Of course only for educational purposes). In order to increase my hashrate I'd like to increase my CPU cache. I already searched SE but haven't found a solution/tutorial so far...

Do you know how to increase my CPU cache?

Any help would be very appreciated!!
Thanks in advance!

You can't increase the CPU cache... For faster CPU performance a better CPU should be used.

Using a higher swapsize could be interesting but doesn't affect the CPU cache nor the hashrate...


Are alternate Monero full nodes possible? I know that Bitcoin has at least one alternate full node implementation, btcd. From what I've heard the Conformal developers spent years on this, and have had to emulate everything (even bugs), and there's still a risk of a fork between btcd and bitcoind.

So are alternate full nodes even possible with Monero? And are there any plans to make this easier for developers?

Generally speaking, yes, it's possible. All a developer has to do is to carefully implement the protocol specification in her programming language of choice.

However, a formal monero protocol specification does not exist at the time of writing. It means hard times for 3rd party client implementations as they would have to have deep knowledge of the existing monero client and protocol.

Finally, I'd like to mention that btcd is not the only full node implementation for Bitcoin, apart from bitcoin-core there is also libbitcoin, another full node implementation. And to compare, other blockchain platforms also offer different full clients, e.g., Ethereum has seven different implementations as far as I am aware of. All you need is a well-written protocol specification.


Size requirements for different "pieces" of a Monero transaction What are the different pieces of a transaction that take up precious bytes on the blockchain (range proof, MLSAG, inputs, outputs, ECDH, keys, TX extra, other)?
How much space do they take up (in bytes or kb)?
Which items' sizes may change in the future?

The transaction structure is:

Transaction version: 1 VarInt

Unlock time: 1 VarInt

Per Input: 1 byte (type: either coinbase or regular spend) + 1 VarInt (pre-ringct amount) + 1 VarInt (the ring size) + Ring_Size VarInts (input offsets) + 32 bytes (key image)

Per Output: 1 VarInt (pre-ringct amount) + 1 byte (type: only regular spend type currently implemented) + 32 bytes (output one-time public key)

Tx extra: Includes 32 bytes for the txpubkey, may contain an encrypted or unencrypted payment id, a nonce if a coinbase tx, and can contain other arbitrary user defined information

Tx type: 1 byte (Version 2 transactions only)

Tx fee: VarInt

Version 1 transactions only: 1 LSAG ring signature per input, each ring signature is 32 bytes * Ring_Size

Version 1 transactions end here. The remainder of the transaction structure applies to Version 2 (RingCT) transactions only:

PsuedoOuts (newly generated commitments for the real input amounts, so that if one real input ring position is revealed, all real input ring positions in the transaction are not also revealed): Per input: 32 bytes (PseudoOuts are present for tx type 2 RCTType2Simple transactions only)

EcdhInfos (encrypted output amounts and OutPk commitment masks): 64 bytes per output

OutPks (output amount commitments): 32 bytes per output

Range proofs: 6176 bytes per output (Dec 2018 update: range proofs have now been replaced with bulletproofs, which are smaller).

MLSAG ring signatures: Per Input: (64 bytes * Ring_Size) + 32 bytes

Therefore, transaction size is most sensitive to increasing the number of outputs, because of the large range proof size requirements. The transaction is also sensitive to increasing the ring size and increasing the number of inputs.

It is expected that later in 2018, a new bulletproof scheme will replace Monero's existing range proofs. This will significantly lower the size of transactions.

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


How do I upgrade my software to v0.11.0.0? I've been running CLI v0.10.3.1 and GUI Beta 2. How do I update these to v0.11.0.0?

CLI:

If you are using the CLI you ought to perform the following steps:

Download the new binaries from here.
Extract the new binaries to a new directory of your liking.
Copy over the wallet files from the old directory (the one that contains the v0.10.3.1 binaries).

Note that a blockchain resync is not needed. If you open monerod-v.0.11.0.0 it simply picks up where it left off.

GUI:

If you are using the GUI you ought to perform the following steps:

Download the new binaries from here.
Extract the new binaries to a new directory of your liking.
Open monero-wallet-gui^1. It should automatically load your "old" wallet.

(1) On Linux you ought to start the GUI with the start-gui.sh script.


How long does it take for the coins to go from cold storage into a hot wallet? I have some monero in a Cold Wallet (paper wallet), I downloaded the Wallet GUI. The wallet is now fully synched...  And filled in the 25 word seed, and the block-height (one day before I sent the coins).

About 2 hours have passed but the balance hasn't change yet. How long does it take for the coins to go from cold storage into a hot wallet?

Greetings, robert

Making a paper wallet "hot" by restoring your mnemonic seed in the GUI or CLI it needs scan all blocks for outputs that match your keys. You can speed up this process if you know approximately when you first created your wallet / sent the first transaction to it and check Monero's block height at that date, so your wallet doesn't have to scan the entire blockchain any more but only from that date on.

However, the scanning process is computationally intensive and it may take several hours depending on your hardware. A fast SSD with the synced blockchain and a modern CPU will speed it up. You only have to do this once when importing your seed, next time your hot wallet will know up to which block height it already scanned the blockchain and will only scan new blocks for your outputs.


What is the blobdata txs within the block_complete_entry struct? In cryptonote_protocol_defs.h block_complete_entry is declare that is used within the monero code right?

The block_complete_entry has a blobdata txs.
How does the txs blobdata looks like and what structure does it have?

Bonus question why are tx_output_indices needed within a COMMAND_RPC_GET_BLOCKS_FAST Response. Are the indices not part of the txs blobdata from block_complete_entry ?

The txs field of the block_comptete_entry structure is a list of serialized transactions. When you get it from the getblocks.bin or getblocks_by_height.bin RPCs, it will appear as a serialized array of serialized transactions (i.e. an array of data strings).

A serialized transaction is made of:

version (varint)
unlock time (varint)
inputs (vector of transaction input targets)
outputs (vector of transaction outputs)
extra (vector of bytes)
signature (ring signature if transaction version is 1, and ringct signature if it is 2)

The outputs' indices are not part of the transactions. The daemon builds a table of output indices in chronological order in its database when it processes blocks (c.f. Where is the global array of outputs of type txout_to_key?).


How do you lock X amount of monero for 200 blocks using the cli wallet? Using the monero cli wallet, what is the command and options to lock 10 monero for 200 blocks?

You can use the locked_transfer command:

locked_transfer 4xxx... 10 200

It will look something like this:


CryptoNight Miner in Python? Is there a Crypto Night Miner in Python?

If not, Please Write one, with pool support.

Reward: 0.1 XMR;

Thanks A Million!

No, and no, respectively.

A python miner would likely be pretty slow. At a push, you could maybe use a python main calling C code for the crypto parts.


Is there a secure way to boostrap a node? It seems the sync process is tediously slow with it's verification. I do know of the bootstrap file, but I'm not sure how secure this is (How to synchronize the GUI wallet using the blockchain bootstrap seems to state that verification is disabled for this)? There isn't even a known hash given for the bootstrap file?

Is there a known state of the blockchain that is hashed / verified somewhere?

You are probably looking for bootstrap node

monerod --help

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


How to do a lookup on a Loki Name Service (LNS) record? When a loki name service record is created, how does one query the loki blockchain to see where does the LNS resolve to?

The loki cli wallet has a new command titled lns_print_name_to_owners

lns_print_name_to_owners lnsname


How could Monero be transmit under the purview of a hostile state actor? Say Monero gets big in COUNTRY_X.

Say COUNTRY_X doesn't like that for whatever reason and decides to stop it from both being mined and propagating throughout their country.

Say COUNTRY_X cranks up their firewall specifically targeting Monero.

What happens then? Do we have any options at all?

China is already able to block tor for example.

And the tor project hasn't even made a post about China in over 2 years which seems to say that they are currently defeated and without any hope or suggestions as to how they might move forward.

Does this mean that a hostile state actor could effectively block any cryptocurrency of their choosing from being transmitted either outside of or within their own borders?

I suppose, given the nature of the internet, especially privacy enhancing tools like TOR or I2P networks that even if a government would try to block a specific service - users would always find one way or another to use it anyway. (See TOR bridges for example: https://www.torproject.org/docs/bridges)

Consider firewalling for example - how would a 'anti-crypto' state block you from using it? - blocking the crypto's RPC port? -> One could proxy it through ports 80 or 443 (http/https) so the blocking party could not easily determine whether its legit and simple web-traffic or being used for crypto transactions.
(That's what TOR relay operators often do, they advertise their TOR-Port as 80/443 so when users connect to it - their ISP/Government/Employer would need to do way more than fire-walling).

So the only thing I see happening if a government would outlaw a crypto is, that the users who are really determined will almost always be able to use it - users however would need to compromise on comfortability, ease of use and sadly (let's hope not) risk prosecution by such (imho) stupid laws.


How would someone premine a direct fork of monero ( can it be done ) I am wondering if it is possible to 100% premine a fork of monero.

I also want to set the block reward to 0.

I have looked at cryptonote genesis block creation notes around the web, but I do not know if this would be the same as premining. I also do not know if it applied to monero anymore.

I have successfully compiled many crypto's but I am starting to realize that there is much more to learn about them!

It should be easy to emit all the coins in the first block:

Look for get_block_reward in cryptonote_basic_impl.cpp. You see how you're given the number of already generated coins. For the first block, it will be zero. In that case, you can return a large amount. For the second block, that value will be equal to the first block's reward. You can then return 0 if the number of already generated coins is not 0.

Note that there might be other bits and bobs needing some updating, mostly in tests.


Can I mine with an Intel Celeron R 1820? I just started getting the into Monero and it took for about 14 days to sync (it still has some remaining blocks and I use the GUI wallet created by community), though my question is this, can I even mine any?

The system as I mentioned before is an Intel Celeron 1820 (2.7 GHz) with NVIDIA GeForce 8500 GT.

You can, but don't expect to mine a block any time soon with such a low powered CPU.


I'm looking for a Monero miner written in Java I'm looking for a Monero miner written in Java. Can anyone link me one?

I've not come across a Java Monero miner. Closest I can find is a slightly outdated set of JNI bindings for the hash functions: https://github.com/trudly/cryptonight

Honestly though, you're not going to get a miner written in Java coming close to the performance of the existing C/C++ miners, in part due to the fact these do CPU and GPU hashing.


CPU does not have AES-NI, which is required I have a problem. I made it with this tutorial http://fucking-it.com/articles/bitcoin/771-monero-cpu-mining-on-linux

In the last step I get this message CPU does not have AES-NI, which is required.

What do I do with this?

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

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

grep -m1 -o aes /proc/cpuinfo

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


ViaXMR payouts time length I've been mining on ViaXMR.com for nearly a month now and still no payout, is this because its a small pool or something else? Hobbyist miner using one GPU/CPU

The ViaXMR pool hasn't found a block since Dec 3: https://www.viaxmr.com/#/blocks  So no one has been paid out in a while.  It's been a really unlucky streak.

Also, the minimum payment is 0.4 XMR. Look at the Pool Config here: https://www.viaxmr.com/#/home

So you will have to mine long enough to accrue 0.4XMR before the pool will pay you at all.

You won't see any XMR for a long time in that pool.

MoneroOcean (or some other http://moneropools.com/) may be a better pool for you: 0.03 XMR minimum payouts: https://moneroocean.stream/#/dashboard


How do I generate a Trezor Monero wallet with the CLI (monero-wallet-cli)? According to the release notes v0.14.1.0 includes Trezor support. How do I generate a Trezor Monero wallet with the CLI (monero-wallet-cli)?

Note that Monero support is currently only available for the model T.
Windows / Linux / Mac OS X
We first have to ensure that we're sufficiently prepared. This entails the following:

This guide assumes you have already initialized your Trezor device and thus generated a 12 or 24 word mnemonic seed.

You need to run / use CLI v0.17.1.3, which can be found here, on the downloads page of the official website, or on Github.

Make sure your firmware is up to date.

Your Trezor needs to be plugged in.

Either your daemon (monerod.exe (Windows) or monerod (Linux and Mac OS X)) should be running and preferably be fully synced or you should connect to a remote node.

Now that we're sufficiently prepared, let's start!
Windows

Go to the directory / folder v0.17.1.3 monerod.exe and monero-wallet-cli.exe are located.

Open a new command prompt / powershell. This is done by first making sure your cursor isn't located on any of the files and subsequently doing SHIFT + right click. It will give you an option to "Open command window here". If you're using Windows 10, it'll, most likely, give you an option to open the Powershell.

Now type:
monero-wallet-cli.exe --hw-device Trezor --generate-from-device <new-wallet-name>
(Win 7 + 8)
.\monero-wallet-cli.exe --hw-device Trezor --generate-from-device <new-wallet-name> (Win 10)

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
monero-wallet-cli.exe --hw-device Trezor --generate-from-device MoneroWallet (Win 7 + 8)
.\monero-wallet-cli.exe --hw-device Trezor --generate-from-device MoneroWallet (Win 10)

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

If you enabled the passphrase feature on the Trezor device (skip this step if not), a Device requires attention will now be displayed. The device will ask you whether you want to enter your password on the host (your system) or the Trezor device. Choose your desired option.

A Device requires attention will now be displayed. The device will ask you whether to export the watch-only credentials. Proceed with Yes.

Your Trezor Monero wallet will now be generated. This should be almost instantly and definitely not take longer than a minute.

The CLI will now display a No restore height is specified. message. Use Y or Yes to proceed.

The CLI may now display a Restore height x is not yet reached message. Use Y or Yes to proceed.

The CLI will, if using your own (local) node, display a message about background mining. Proceed with your desired answer (i.e. Yes or No).

The Trezor device will now ask you to confirm the start of the wallet refresh. After confirmation, monero-wallet-cli.exe will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Trezor Monero wallet in conjunction with the CLI.

Mac OS X

Use Finder to browse to the directory / folder monero-wallet-cli (CLI v0.17.1.3) is located.

Go to your desktop.

Open a new terminal (if don't know how to open a terminal, see here).

Drag monero-wallet-cli in the terminal. It should add the full path to the terminal. Do not hit enter.

Now type:
--hw-device Trezor --generate-from-device <new-wallet-name>

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
--hw-device Trezor --generate-from-device MoneroWallet
Note that aforementioned text will be appended to the path of monero-wallet-cli. Thus, before you hit enter, your terminal should look like:
/full/path/to/monero-wallet-cli --hw-device Trezor --generate-from-device <new-wallet-name>
Where the full path is, intuitively, the actual path on your Mac OS X.

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

If you enabled the passphrase feature on the Trezor device (skip this step if not), a Device requires attention will now be displayed. The device will ask you whether you want to enter your password on the host (your system) or the Trezor device. Choose your desired option.

A Device requires attention will now be displayed. The device will ask you whether to export the watch-only credentials. Proceed with Yes.

Your Trezor Monero wallet will now be generated. This should be almost instantly and definitely not take longer than a minute.

The CLI will now display a No restore height is specified. message. Use Y or Yes to proceed.

The CLI may now display a Restore height x is not yet reached message. Use Y or Yes to proceed.

The CLI will, if using your own (local) node, display a message about background mining. Proceed with your desired answer (i.e. Yes or No).

The Trezor device will now ask you to confirm the start of the wallet refresh. After confirmation, monero-wallet-cli will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Trezor Monero wallet in conjunction with the CLI.

Linux

Go to the directory / folder v0.17.1.3 monero-wallet-cli and monerod are located.

Open a new terminal

Now type:
./monero-wallet-cli --hw-device Trezor --generate-from-device <new-wallet-name>

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:
./monero-wallet-cli --hw-device Trezor --generate-from-device MoneroWallet

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.

If you enabled the passphrase feature on the Trezor device (skip this step if not), a Device requires attention will now be displayed. The device will ask you whether you want to enter your password on the host (your system) or the Trezor device. Choose your desired option.

A Device requires attention will now be displayed. The device will ask you whether to export the watch-only credentials. Proceed with Yes.

Your Trezor Monero wallet will now be generated. This should be almost instantly and definitely not take longer than a minute.

The CLI will now display a No restore height is specified. message. Use Y or Yes to proceed.

The CLI may now display a Restore height x is not yet reached message. Use Y or Yes to proceed.

The CLI will, if using your own (local) node, display a message about background mining. Proceed with your desired answer (i.e. Yes or No).

The Trezor device will now ask you to confirm the start of the wallet refresh. After confirmation, monero-wallet-cli will start refreshing. Wait until it has fully refreshed.

Congratulations, you can now use your Trezor Monero wallet in conjunction with the CLI.

A few final notes:

I'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet. Note that, upon recreating / restoring the wallet, you ought to append the --restore-height flag (with a block height before the height of your first transaction to the wallet) to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux). More information about the restore height and how to approximate it can be found here.

If you use a remote node, append the --daemon-address host:port flag to the command in step 3 (Windows), step 5 (Mac OS X), or step 3 (Linux).

You only have to use the --generate-from-device flag once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the CLI. That is:

[1] Make sure your Trezor device is plugged in.
[2] Open monero-wallet-cli
[3] Enter the wallet name of your Trezor Monero wallet.
[4] Enter the password to open the wallet.
If the Trezor Monero wallet files are not in the same directory as monero-wallet-cli, you ought to open monero-wallet-cli with the --wallet-file /path/to/wallet.keys/file flag. Alternatively, you can copy the Trezor Monero wallet files to the same directory as monero-wallet-cli.

Upon closing the wallet, make sure to exit monero-wallet-cli first by typing exit. You can, thereafter, remove / unplug the Trezor device.

If you have any further questions or need assistance, please leave a comment in this thread.


Is there any way to construct a transaction manually? With Bitcoin you can create an unsigned transaction, sign that transaction and then broadcast it. Is there anyway to do that with Monero? With all the fancy JSON, etc.

Yes, there is. It works a bit different than in Bitcoin due to Monero specifics involving scanning for outputs with the view-key and checking the spent status by using key images.

First, we assume you have a fully-synced node and fully-refreshed watch-only wallet on the hot computer. Also, we assume you have wallet software on the cold computer (don't need the node, just monero-wallet-cli).

Using watch-only wallet, command export_outputs <filename>. There will be a file with <filename> created in the working folder*.
Copy the file to the cold wallet computer.
Using cold wallet, command import_outputs <filename>*. The cold wallet now has all the outputs and can prepare a signed key image for every one of them (unless something new was received after step 1. It won't display the correct balance because it can't check the spent status of the key images, as it is offline.

--- Stop here if you only want to monitor incoming transfers and don't care to see the correct balance and when something has been spent ---

Using cold wallet, command export_key_images <filename>. There will be a file with <filename> created in the working folder*.
Copy the file to the hot wallet computer.
Using watch only wallet, command import_key_images <filename>*. The watch wallet is now aware of spent status for each output and it shows the correct balance (unless something new was received in the meantime, after step 1.

--- Stop here if you only want to monitor the balance with the watch only wallet. Goto 1. after each newly received funds. Continue for cold spending. ---

Using watch only wallet and transfer command as you would normally, prepare an unsigned transaction. The syntax is the same as if it was a full wallet, but in this case the watch wallet will automatically save the TX to the unsigned_monero_tx file* and a message Unsigned transaction(s) successfully written to file: unsigned_monero_tx will be displayed.
Copy the file to the cold wallet computer.
Using cold wallet, command sign_transfer, to sign and export the transaction. Note that the wallet will look for the file to sign in the working folder*. The signed transaction will be automatically saved to the file* signed_monero_tx and a message Transaction successfully signed to file signed_monero_tx, txid ... will be displayed.
Copy the file to the hot wallet computer.
Using the watch wallet, command submit_transfer and the transaction will be sent to the network. The signed_monero_tx file* must be located in the working folder so it can be found by the wallet. A message Money successfully sent, transaction: ... will be displayed.
Goto 1. because you need the signed key image for the change output.

*Note on folders and file locations, as it could create some confusions. The wallet will look for the files and export them to the folder from where it was started, ie where your command prompt / shell was when you called monero-wallet-cli. It may or may not be the same folder as your actual wallet files or monero-wallet-cli, depending on how you go about it.

For example, your wallet could be on some USB drive like f:\temp\, and your wallet software on c:\monero\ and your shell working folder could be c:\.

If you remain in c:\ with the shell, you could start the wallet by its full path and specify the wallet file location: c:\monero\monero-wallet-cli.exe --wallet-file f:\temp\mywallet. In this case, all the import/export stuff would be read/written to c:\ because that's still your shell's working folder.

It would be probably feel more natural to cd into the wallet folder. Do f: to change drive and then cd f:\temp\. Then, simply start the wallet from that location by its full path again: c:\monero\monero-wallet-cli.exe --wallet-file mywallet. Notice how you don't have to write the full wallet path now as you're already there with your shell. In this case, all the files mentioned above would be written or read from the same folder as the wallet files.


How does key images work when you create a transaction using two or more of your previously unspent transaction outputs? I've read key images are the critical element in Monero to avoid double spends.

I think I understand how it works when you are using only one of your previously unspent transaction outputs to create a new transaction.

Let's say you have a previously unspent transaction output TXO_A.

In that case you create a ring signature joining your TXO_A with 4 other TXOs (TXO_B, TXO_C, TXO_D and TXO_E). The ring signature is formed in a way that everybody can validate that someone in the ring has signed it, but no one can tell who was the signer. Also, you have to attach a key image derived from TXO_A to the transaction so the protocol would never accept using the same TXO_A in a different transaction.

Here come my doubts:
How is a transaction formed when you need to use 2 or more of your TXOs?

Imagine you have to pay 15 XMR and you don't have a single TXO with enough XMR. You'll have to use 2 different TXOs, for example: TXO_A1 with 10 XMR and TXO_A2 with 8 XMR.

In that case, the ring signature would be formed from TXO_A1, TXO_A2, TXO_B, TXO_C and TXO_D?

Evidently the protocol could not let you use again TXO_A1 nor TXO_A2, so there has to be a way to include key images from both TXO_A1 and TXO_A2.

But if you add explicitly 2 key images to the transaction, it leaks that you used 2 TXOs instead of just one, and everybody knows the number of decoy TXOs has been reduced by one.

The worst case would be if you'll need to use 5 TXOs owned by you, then there would be no decoys!!

As it can't be that way, I would like an explanation of how is this done in Monero.

Monero's ring signatures typically use a ring size of 7, which means 1 real output and 6 decoy outputs.

However, there are several rings if you spend several outputs. Therefore if you spend 5 outputs, there will be 6*5=30 decoys.


What is the normal rate of failing to submit a block from pool mining Electroneum We have a node-cryptonote-pool mining Electroneum, and sometimes it even finds a block.

However, due to many factors, most of which are obscure for me, it fails to submit it, fails with error like this:

Error submitting block at height 141295 from here-goes-wallet-address@127.0.0.1, share type: "trusted" - {"code":-7,"message":"Block not accepted"}`

Sometimes it just does not have this {"code":-7,"message":"Block not accepted"} block.

The electroneumd (fork of monerod) shows error Transaction not found in pool at the same time.

We lose ~50% of mined blocks with such errors.
The question is, what is the normal rate for such errors? Is 50% indeed normal and what we can do is just to give up and live with it, or there is a room for improvement?

I ask here on Monero stackexchange because I did not find Electroneum-related site, and Electroneum is a fork of Monero. Also, Monero had the similar block time of 1 minute as ETN has now, so maybe some "older" pool owners mining Monero might help.

I'm not sure what the normal rate is but since i started mining a week ago, i rarely get a rejected-messages. Not sure if that has todo with your mining software, your hardware or the pool but to at least exclude the pool, see if another pool works better for you.

Currently i mine at Coinfoundry which is a really new pool that supports also Electroneum and has a fee of 0.15% (it will never have a higher fee then 0.6%) and no other costs. Try it. If that doesn't help you, then you at least know that that's not the problem.


dynamic block size drawbacks What are potential long term drawbacks of dynamic block size ? I mean bitcoin for some reason doesn't want to increase and\or make it dynamic. If scaling could be solved with just implementing dynamic block size then why do we have this long bitcoin block size debate?

We could scale to having very large blocks which could lead to it being prohibitively expensive to run a node.  We might be left with a situation of concentration of nodes/ mining.


API call for ring members Is there any way that we can do an API call to the Monero daemon RPC to get all the ring members for a given transaction hash?

After calling get_transactions, you will have a list of the ring members in the vin.key_offsets field. You can then lookup these outputs using a call to get_outs.

An example of both calls:

curl -X POST http://127.0.0.1:18081/get_transactions -d '{"txs_hashes":["a6eb34ec1893ce43630efc2f2dfa98cde2d5e7f37c18d1d8303f3a6436a4cc9f"],"decode_as_json":true}' -H 'Content-Type: application/json

Returns 5164903, 2019770, 392759, 121787, 5621, 4659, 833, 1353, 6326, 487, 682 as the key_offsets (the ring members).

Each output after the first is incremented by the sum of the previous indexes. So the first member is at index 5164903, the 2nd at 7184673 and so on.

So translated, these outputs are then:

5164903, 7184673, 7577432, 7699219, 7704840, 7709499, 7710332, 7711685, 7718011, 7718498, 7719180

To get further information on each ring member, you can then call get_outs like following (which gets the first and last):

curl -X POST http://127.0.0.1:18081/get_outs -d '{"outputs":[{"index":5164903},{"index":7719180}]}' -H 'Content-Type: application/json'

Which returns:

{
  "outs": [{
    "height": 1545783,
    "key": "6dcc42839619ea4e1b1cb1b28d45659916207a445ec00e06ece45a7b7bfc1264",
    "mask": "449ce062721cbde5f282eeb292eb27636539b29c81a396fddeede73c72d0a66e",
    "txid": "124f70eb30ace64d577d82f193e0057b07fc4bdb053bf228dfc00b4e1099b1f1",
    "unlocked": true
  },{
    "height": 1694891,
    "key": "1089839b83fd45f7ab87a64398aad45176be4e6ee44872cf37c544358904d61c",
    "mask": "3f22409779524a01dc998e58fbccb58a02ca37e6e6be784f11d7b67dbdaf87e3",
    "txid": "4b1580e241b5499dd19faebc6c3c2dbf9bbb8a6c8144f538863fb3e71db10bd1",
    "unlocked": true
  }],
  "status": "OK",
  "untrusted": false
}


What is a "Low Difficulty Share" error? I am trying to mine on an old AMD Radeon HD 57xx GPU with Catalyst version 15.7.1 on a Windows10 x64 machine.
Claymore's CryptoNote GPU Miner v9.4 receives the following error from the pool

{"id":1,"jsonrpc":2.0","error":{"code":-1,"message":"Lowdifficultyshare"}}

This topic on bitcointalk suggests to use a particular algorithm for such card (-a 3 switch).

What does "Low Difficulty Share" error mean in this context?

Usually that error means the share your miner submitted was garbage, and didn't actually verify on the pool. Sometimes it means the share was submitted too late, and the pool has already moved on to the next block. But if you keep getting it over and over, then your miner code is broken (or you're using the wrong algorithm).


Where is the encrypted mask value? Checked this link: https://moneroblocks.info/api/get_transaction_data/4adb55cde1ffcc0ea639b6718355c48c0e574000306d95ef857e55d91ddabcf2

I could not find the encrypted mask value.

I believe the encrypted amount is in the ecdh part:

     "ecdhInfo": [
        {
          "amount": "f350bbedb3a4a93b"
        },
        {
          "amount": "c2005984b560da47"
        },
        {
          "amount": "6a2a649c8322d6e1"
        },
        {
          "amount": "0e0c6e72d16779c7"
        }
      ],

As of the March 2019 hard fork, commitment masks are deterministically derived from the per-output shared secret. This means the ECDHinfo part of the transaction will no longer store the encrypted mask.

See the commit here: https://github.com/monero-project/monero/commit/7d375981584e5ddac4ea6ad8879e2211d465b79d

Therefore, to determine the commitment mask, calculate:

commitment mask = Hs("commitment_mask" || Hs(8aR||i))

To reduce the storage requirement for the amount from 32 bytes to 8 bytes, the 8 byte amount is now XOR encrypted using an 8 byte key deterministically derived from the shared secret.

To encrypt the amount, calculate:

encrypted amount = 8 byte amount XOR first 8 bytes of keccak("amount" || Hs(8rA||i))

To decrypt the amount, calculate:

amount = 8 byte encrypted amount XOR first 8 bytes of keccak("amount" || Hs(8aR||i))