How will outputs be migrated to RingCT, in the transaction building level? I am aware that a similar question has been asked, but it doesn't go into the details of whether in the wallet level the individual user will be able to send rct and non-rct transactions, and wheather it will be possible to migrate each non-rct output to a rct output in their single transaction, instead of having to visibly mix all the user's non-rct outputs one last time in a sweep_all transaction? Even now I think it is kind of bad that it is not possible for the user to decide explicitly what outputs could go together, and which ones shouldn't, and I realize that after ringCT that concern will be mute, but I was hoping for the most privacy concious transition into rct possible.

If you have unspent outputs from non-rct transactions, they are mixed with other non-rct transaction outputs in the same manner as before (an attempt is made to find a mixin number of other outputs of same amount). Then, the amounts of each output in the new rct-transaction are separately "masked". Each verifier (all other nodes), create an "identity" commitment for the inputs to verify no XMR was created in the process - this is identical to how miner outputs now work.

A picture might help, two unspent transactions with mixin 2:

[input amt: 2]--
                \
[input amt: 2]----[ring signature] --+
                /                    |
[input amt: 2]--                     |
                                     |
                                     +--[proof: (inputs - outputs) == 0]--+
                                     |                                    |
[input amt: 5]--                     |                                    |
                \                    |                                    |
[input amt: 5]----[ring signature] --+                                    |
                /                                                         |
[input amt: 5]--                                  [output amt: ?] ----    |
                                                                      \   |
                                                  [output amt: ?]---------+
                                                                      /
                                                  [output amt: ?] ----

I omitted transaction fees in this diagram (irrelevant for this discussion) - the 3 outputs must add up to 7 but the actual amounts are masked. So basically, the inputs to the transaction behave identical to pre-rct transactions, but the amount in each output is hidden.

So no sweep is necessary, until you have unmixable pre-rct unspent outputs. And even then, it is possible to do a transaction/sweep where the amounts in the input ring do not match (but this has not been implemented AFAIK).


Commitment to zero vs one-time public key signature After reading 5.6.3 in Zero-To-Monero: https://www.getmonero.org/library/Zero-to-Monero-1-0-0.pdf

It seems as if they are saying that we use the commitment to zero to sign the ring with the inputs as message. <- this seems horribly wrong however.

Each input needs the private key associated with it's one-time-pubkey/address in order to unlock it. So does each input have a ring signature with the private key corresponding to the one-time-public key needed to unlock our input?

Then maybe the commitment to zero is used to sign the whole transaction?

If any of the above is correctly assumed. At 5.7.2, they mention that in order to sign each individual input, we generate "a new commitment for the same amount but with a different blinding factor." This new commitment has nothing to do with the output commitment, how can we be sure that it is a commitment to zero?

It seems as if they are saying that we use the commitment to zero to sign the ring with the inputs as message.

Not quite, it does use it, but it is not the actual signing key.

It says:

  Signing m with ko proves  you  are  the owner/recipient of the amount committed to in Ca. Verifiers can be confident that transaction authors are spending their own funds.

And further up says:

  With this observation made we can see the utility of zG.  All commitment terms in R return some EC point, and the πth such term is zG.  This allows us to create an MLSAG signature (Section3.3) on R.

Moving to your next question:

  Each input needs the private key associated with it's one-time-pubkey/address in order to unlock it. So does each input have a ring signature with the private key corresponding to the one-time-public key needed to unlock our input?

Yes. Or to put it more accurately, the receiver of the outputs now being used as inputs (to spend), has derived the private keys (using the tx shared secret from the tx they received these outputs from, and their own wallet private keys).

  Then maybe the commitment to zero is used to sign the whole transaction?

No. I think where you are getting lost is the distinction between proving ownership of inputs being spent and proving that the output amounts balance out the input amounts. The former is the job of the MLSAG signature(s), the latter is the job of the Pedersen commitments and the Range proofs (the commitments hide the amounts and prove the inputs minus outputs balance out, the range proof proves that each amount in an output commitment is within a range, in this case positive, which prevents creating money out of thin air).

The commitment to zero is used in the construction of the MLSAG signature, it is not the signing key itself.


Withdraw XMR from exchange EXMO, and deposit to Monero GUI I want report you my first experience regarding XMR withdrawal from EXMO.
They say:

  (EXMO.com)

  Jun 5, 12:15 BST

  Hello!  We withdraw XMR only to the integrated address, that is, those
  in which the Payment ID is already entered, and if you have an address
  for which you need a separate id, then Monero will not be able to be
  displayed on it.  In order to find out your Payment ID you need to
  follow the link:  https://xmr.llcoins.net/addresstests.html  In the
  line at number 8, enter the number of your XMR wallet on EXMO, click
  Check Address and in the line at number 10 (the 3rd field) will be
  your payment id, and in the line at number 15 the standard wallet
  address.  Thank you for contacting us!

How can I get an integrated address?
I want to withdraw XMR from EXMO to the Monero GUI.
I have to generate a receiving address using the Monero GUI and then insert it on EXMO. Is it right?  Thanks a lot

You can use the command line wallet (monero-wallet-cli) to create an integrated address.

[wallet 45xxxx]: help integrated_address
Command usage:
  integrated_address [<payment_id> | <address>]

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

So launch the cli like:

./monero-wallet-cli --wallet-file path/to/your/wallet

Then run the command:

integrated_address

Which will then print out an integrated address with a random payment ID.

Alternatively, you can use xmr.llcoins.net/addresstests.html to create an integrated address as follows:

In the dropdown at the top left, select 'XMR integrated'
Paste your standard public address in box #8
Click 'Check Address'
Copy the output in the boxes next to 'Decoded:' and paste them into boxes #5 and #6 respectively
Click 'Random' next to the 'Payment ID:' box
Click 'Gen 7.'

You now have an integrated address in box #7. You can double check you have done this all correctly by then clicking 'Sent to 8.' followed by clicking 'Check Address'. The boxes next to 'Decoded:' should not change if you have done all this correctly.

Note that integrated addresses are being phased out in favor of subaddresses. So consider using an exchange that properly supports Monero.


Why does sending Monero coins out once prevent me from sending more of my remaining XMR coins immediately? I wanted to pay 2 people. I sent some Monero to the first person and then I couldn't send any xmr coins to the second one. Why do I have to wait for the first to confirm first? Is there a work around to this? And doesn't this prevent adoption? How does the exchanges handle this problem? And are there proposals to fix this?

It's possible that you have a situation where you don't have enough UTXOs to independently send the second payment.

Monero uses a transactional blockchain, in that every transaction must have exactly one origin/source and one or many destinations/spends. When you either mine a coinbase transaction or have a transaction sent to you it becomes an unspent transaction output (UTXO) with a specific amount of value attached to it. If you want to spend this UTXO for the exact amount of it, you simple submit a new transaction with the chosen transaction destination. But if your UTXO has more value than you want to send, you must split this UTXO into multiple new UTXOs, one of which goes to your chosen destination and another that goes right back to yourself. (You could have chosen multiple destinations for the UTXO so that you can save on transaction fees, but this is normally more complicated and takes planning.) Since a new transaction takes time to be mined and be embedded into the blockchain you cannot spend the new UTXO that you sent to yourself, but must wait for it to be confirmed. (This is to prevent problems such as a 51% attack.)

If you know that you only have 1 UTXO and have tried multiple spends on it in quick succession then you will get the above warning. The easiest solution is to simply wait for the first transaction to timeout and then submit the next one.


Calculate the output amount using MiniNero Referring to the question 11272, I have an experiment with MiniNero:

tx_pub_key = "f6d51a0cabd6a68f2c4960bc06b4132d6b937622b8954ea95851aa5f3b32c1de"
pri_view_key = "89a705a1a6427e7a19fd17a78d4a5c35bcb9ce4af74d6c180d5e39909694ab0a"
aR = MiniNero.mul8(MiniNero.scalarmultKey(tx_pub_key, pri_view_key))
tmp = MiniNero.cn_fast_hash(aR+"00")
res = MiniNero.cn_fast_hash("616d6f756e74"+tmp) #616d6f756e74 is ASCII of "amount"

Then I get the result:

0e37ec1966076a6c5c6f15b1ad32f415b5f3e2426c1dc8c95c73b72cabe02168

The last step is to XOR each first 8-byte data:

amount = MiniNero.xor("54f95f7d7f4d1e2a", "0e37ec1966076a6c")

However, the result is not right. Am I doing something wrong? Please help to solve this, Thanks!

BTW, I get 54f95f7d7f4d1e2a from ecdhInfo (explorer)

You haven't reduced tmp. I.e.

tmp = MiniNero.sc_reduce_key(MiniNero.cn_fast_hash(aR+"00"))

Hs in the referenced question's answer refers to Hash to scalar, not simply hash. Otherwise keccak would have been written in place of Hs.

Thus, following your experiment through with the correction, I calculate 1 XMR:

tx_pub_key = "f6d51a0cabd6a68f2c4960bc06b4132d6b937622b8954ea95851aa5f3b32c1de"
pri_view_key = "89a705a1a6427e7a19fd17a78d4a5c35bcb9ce4af74d6c180d5e39909694ab0a"
aR = MiniNero.mul8(MiniNero.scalarmultKey(tx_pub_key, pri_view_key))
tmp = MiniNero.sc_reduce_key(MiniNero.cn_fast_hash(aR+"00"))
res = MiniNero.cn_fast_hash("616d6f756e74"+tmp) #616d6f756e74 is ASCII of "amount"
amount = MiniNero.xor("54f95f7d7f4d1e2a",res[:16])[:16]
print(MiniNero.hexToInt(amount)*1e-12)

Which yields:

1.0


What infrastructure still needs to be built for Monero that Bitcoin already has? Things like services and various other infrastructure that Monero will need before it goes mainstream?

SPV / Light clients with high level of trustlessness.
Fiat <-> xmr gateways. (sort of encompasses all of the below)
ATM machines.
Billpay-type services
Bitwage type services
Payment processors (so amazon can accept Monero)
Merchant infrastructure (so my local coffee shop can accept monero, kind of similar to payment processors).


How are monero wallets generated? I understand that the mnemonic is enough to recover the wallet.
How are the keys and address generated from there? Does one need to have the dictionary of the mnemonic to be able to recover the wallet?

There's a really nice description and address generation tool here:

https://xmr.llcoins.net/addresstests.html

I believe that site is owned and maintained by core dev person luigi1111.

Long quote from luigi's page:

  Cryptonote Public Addresses differ in several ways compared to
  Bitcoin. First, Cryptonote uses two keypairs, known as the spend
  keypair and the view keypair. Furthermore, these keys are EdDSA
  (specifically ed25519) keys, whereas Bitcoin uses ECDSA (specifically
  secp256k1) keys. Finally, Cryptonote Public Addresses are direct
  representations of the pair of public keys, whereas Bitcoin (and
  clones) uses a hash of the single public key. EdDSA keys (both private
  and public) are 256 bits long, or 64 hexadecimal characters. Not every
  256-bit integer is a valid EdDSA scalar (private key); it must be less
  than the "curve order". The function to do this is labeled
  sc_reduce32.

  To add to the confusion, there are presently at least three different
  methods of private key derivation in existence for Monero (and other
  Cryptonotes), though Bitcoin also has many:    Original
  (non-deterministic) Style – The Private Spend Key and Private View Key
  are both independently and randomly chosen to form an account. You can
  simulate this above by pressing the "Random" buttons next to fields 3.
  and 4., then pressing "Gen 5.", "Gen 6.", and "Gen 7.", in that order.
  There is no good way to back up a non-deterministic account other than
  keeping copies of the files; you need to have a copy of both private
  keys, but presently only MyMonero will accept the two keys as input
  instead of a seed/wallet file. For these reasons, it is not
  recommended to use an account of this type.    Mnemonic (Electrum or
  Deterministic) Style – In this style, the Private View Key is derived
  from the Private Spend Key, so you only need to remember one thing:
  the seed, which is actually just a representation of the Private Spend
  Key itself. This 256-bit scalar can be easily converted to a
  "24-digit" Base1626 "number" in the form of a mnemonic seed, which is
  25 words long with the last word being used as a checksum. Mnemonics
  convert on a ratio of 4:3 minimum: four bytes creates three words,
  plus one checksum word; eight bytes creates six words, plus one
  checksum word; and so on. The "seeds" created by this method will
  always be valid scalars as they are sent to sc_reduce32 first. The
  Private View Key is derived by hashing the Private Spend Key with
  Keccak-256, producing a second 256-bit integer, which is then sent to
  sc_reduce32. You can test out this style above by pressing the
  "Random" button on the upper right, or by pressing either of the
  "Random" buttons next to fields 1. and 2., then the various "Gen x."
  buttons. You can backup accounts of this type by writing down or
  otherwise saving the 25 word deterministic seed; you can easily
  restore using both and MyMonero.    MyMonero Style – This is similar
  to 2., but uses a 13 word seed instead of a 25 word seed. The 13 words
  convert to a 128-bit integer that is used for both spend and view key
  derivation, in the following form: the 128-bit integer is hashed with
  Keccak-256 to produce a 256-bit integer, a. a is sent to sc_reduce32,
  which returns the Private Spend Key. a is hashed once more with
  Keccak-256 to produce a second 256-bit integer, b. b is then sent to
  sc_reduce32, which returns the Private View Key. You may have noticed
  a critical difference between this style and the Electrum Style:
  MyMonero's Private View Key derivation is done by hashing random
  integer a, while Electrum Style derivation is done by hashing the
  Private Spend Key. This means that 13 and 25 word seeds are not
  compatible – it is not possible to create an Electrum Style seed (and
  account) that matches a MyMonero Style seed (and account) or vice
  versa; the view keypair will always be different. You can test out
  this style above with the "Random MyMonero" button. To backup MyMonero
  accounts, save the 13 word seed; you can currently "restore" using
  MyMonero only (you're really just logging in) – Simplewallet does not
  currently support 13-word seeds.

  Above we discussed the different ways private keys are derived; the
  rest of the address generation process is the same in all three cases.
  The Private Spend Key and Private View Key are sent to the ed25519
  scalarmult function to create their counterparts, the Public Spend Key
  and Public View Key. To create the actual Public Address, the
  following is performed:   The pair of public keys are prepended with
  one network byte (the number 18, 0x12, for Monero). It looks like
  this: (network byte) + (32-byte public spend key) + (32-byte public
  view key). These 65 bytes are hashed with Keccak-256.   The first four
  bytes of the hash from 2. are appended to 1., creating a 69-byte
  Public Address.   As a last step, this 69-byte string is converted to
  Base58. However, it's not done all at once like a Bitcoin address, but
  rather in 8-byte blocks. This gives us eight full-sized blocks and one
  5-byte block. Eight bytes converts to 11 or less Base58 characters; if
  a particular block converts to <11 characters, the conversion pads it
  with "1"s (1 is 0 in Base58). Likewise, the final 5-byte block can
  convert to 7 or less Base58 digits; the conversion will ensure the
  result is 7 digits. Due to the conditional padding, the 69-byte string
  will always convert to 95 Base58 characters (8 * 11 + 7). This
  95-character result is the (obscenely long) Cryptonote Public Address!
  If you're creating an integrated address, simply append the 64-bit
  payment ID to step 1 and continue; everything else is the same except
  for the lengths (77 bytes total, 106 Base58 digits) and the prepended
  byte (19, 0x13).


How can I manually stop attempting to connect to offline nodes When I start my full node, there are multiple offline nodes that bitmonerod keeps attempting to connect to.

How can I manually stop bitmonerod from trying to connect to nodes that are no longer working? If I do nothing, exactly how long does it take before offline nodes are dropped by the network?

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


Why is it called Monero? Why is Monero called Monero? Shouldn't it have a cool tech-sounding name like Bitcoin or Interslice or Globalcom?

Monero translates to coin in Esperanto. The name of the original project that Monero is based on was called BitMonero, or literally BitCoin in Esperanto.


How does the mixing work? I have been researching Monero, and I think I understand how ring signatures and stealth addresses work mathematically.

However, to create a new ring transaction, you need N peers that want to join your transaction.

If you send the inputs from your own addresses (different ones), it is easy to link the coins to you, that is why I suppose that the mixing process occurs with other peers.

My question is: how does the Monero network find other peers to mix with you?

During the process, if you send a "partial transaction", you are deanonymized. However, if you do not send a transaction, you can't find other peers, and nobody will join your ring.

Monero does not require that "mixing" happens at the same time that other spenders want to "mix" their coins.  Rather, the sender constructs the complete transaction prior to broadcasting it to the network.

The sender's wallet chooses one or more of its own outputs to spend, and then it picks other actual outputs from the blockchain to mix with its own output(s), all of which are included in a ring*.  By attaching a key image and signing the transaction, the sender has (a) proven that it has ownership of an output from the ring, (b) proven that the output has not been previously spent, while (c) not revealing which output is being spent.

*There is one spent output per ring.  If you spend two outputs, that means there will be two rings, each with its own ring members and key image.


How to calculate the achieved difficulty of a mined block How does monero calculate the achieved difficulty of a mined block given a pow hash from randomx. I dont know if this is perhaps the correct place to ask this. If its not is there a better place to pin this?
I looked here: How can I tell what difficulty my solution is?
From that I copied the code to a nodejs scratchpad: https://repl.it/repls/KaleidoscopicLiquidVideogames:
const baseDiff = bignum('FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF', 16);

Buffer.prototype.toByteArray = function () {
    return Array.prototype.slice.call(this, 0);
};

let hex_hash = "9ac67c5a2793861093ffa3f3fbeeffd8e9971fe555f59a0735c2d50500000000";
var hash = new Buffer.from(hex_hash,'hex');
var hashArray = hash.toByteArray().reverse();
var hashNum = bignum.fromBuffer(Buffer.from(hashArray));
var hashDiff = baseDiff.div(hashNum);
console.log(hashDiff.toString());
console.log("done");

I also wrote code in rust, the values match from the rust vs nodejs. But they do not match the difficulty from the block explorers.
The code above results in difficulty achieved: 188434043243
While the block explorer: https://xmrchain.net/block/2196393
results in 159730146809.
Dotting the differences again here for easy viewing:
188434043243
159730146809
Why is there a difference there?

Why is there a difference there?

The difficulty displayed on block explorers is the difficulty the hash has to be greater than, not what difficulty the hash is.


Can I use the same Monero miner on a 32bit and 64bit os? I'm mining Monero with my raspberry pi and everything's working just fine. Now I found out that the original (by the raspberry community/devs) os (Raspbian) is only 32bit... To increase my RPis performance I want to install Pi64 on it (obviously an 64bit os).

At the moment I'm using the xmrig miner for mining Monero...

My questions is if I could install and compile xmrig on a 64bit os just as I did on my 32bit os or could there be some issues?

Compiling and installing xmrig on a 64 bit OS will work fine.


Why does the option "--verify 0" for monero-blockchain-import not work? When I use the command ./monero-blockchain-import --verify 0 --input-file ./blockchain.raw it says "Failed to parse arguments: unrecognised option '--verify'".

People were abusing --verify 0, using it for files they downloaded from the internet, which is a dangerous thing to do. So it got renamed to --dangerous-unverified-import (prior to this it was named --guard-against-pwnage), to make it clear it's a dangerous thing to do. Similar to disabling a malware scanner when downloading some binary off the internet.

Or, sadly, people using third party nodes even though you should run your own for privacy.

Oh well. Maybe that battle is lost. People like overriding safety mechanisms.


What is the total supply of Monero and when will it be finished mining? Is there an end date of when the last monero will be mined? And what is the current supply as of today 2017 May?

From Wiki it says around 18.4 Million at the end of May 2022. However,  tail emission will kick in after that which is 0.6 XMR, so it has no fixed limit.

  Its main emission curve will issue about 18.4 million coins to be mined in approximately 8 years.  (more precisely 18.132 Million coins by ca. end of May 2022[) After that, a constant "tail emission" of 0.6 XMR per 2-minutes block (modified from initially equivalent 0.3 XMR per 1-minute block) will create a sub-1% perpetual inflatio starting with 0.87% yearly inflation around May 2022) to prevent the lack of incentives for miners once a currency is not mineable anymore

From https://moneroblocks.info/, current emisssion is

14,445,846


Does Monero use rfc6979 for signatures? I came across a post stating that Monero uses the Borromean Ring Signature scheme to hide the amounts. So what signature scheme is used to sign the transactions?

Pedersen Commitments of Monero output amounts are published, instead of publishing the actual amounts in the clear. Borromean Ring Signatures are used for range proofs on those Pedersen Commitments, which prove the amounts are not negative.

Monero signs transactions with MLSAG signatures. See https://lab.getmonero.org/pubs/MRL-0005.pdf


Track all rewards issued to a Monero mining pool I am a newbie, running a test pool on Monero mainnet. At 15k hash rate, it yielded a block in approximately 48 hours. Now the pool is running at an average 50k hash rate and has generated no blocks in span of 10 days. I am unable to spot any problem in daemon logs or any APIs.
I am using nodejs-pool. Current block maturity is 5.

Is there a way to track blocks generated by a pool?
What are the possible explanations of such behavior?

Is there a way to track blocks generated by a pool?

The pool implementation you are using includes an API endpoint which reports blocks mined. It's registered at /api/pool/blocks by default. E.g. https://supportxmr.com/api/pool/blocks

  What are the possible explanations of such behavior?

At 15 kh/s, finding a block in 48 hours at current network hashrate is just good luck. With 50 kh/s on current network hashrate (~300 mh/s) you're expecting to mine a block in 8 days. Ref: 300000000/50000*120/(24*60*60). Note this is no guarantee, luck plays a part still, so 10 days should not be unexpected.


Can't create transaction: internal error: Failed to get height I'm using

monero-gui-v0.15.0.2
Ledger Monero App 1.4.2

When I'm trying to do a send operation it fails with:

E result. THROW EXCEPTION: error::wallet_internal_error
E Can't create transaction:  internal error: Failed to get height

I have the same error with the monerujo app on Android:

monerujo 1.12.11

I have the same error when sending to own wallet.
This means for the moment I'm not able to make a transaction from my wallet.

An idea what could be done to solve this?

This was resolved by selecting a different remote node.


Is it impossible to calculate Monero Days Destroyed? Based on my understanding of Bitcoin Days Destroyed its calculation requires knowing how long it has been since Bitcoin was last spent. Monero has inherent privacy that would seem to prevent a similar "Monero Days Destroyed" calculation.

Is my understanding correct that calculating "Monero Days Destroyed" is impossible?

What alternative measures are available to best approximate Monero transaction volume while avoiding the total transaction volume reliance that Bitcoin Days Destroyed tried to improve upon?

  it was realised that total transaction volume per day might be an inappropriate measure of the level of economic activity in Bitcoin

This is indeed impossible, since you'd have to know which input in a ring is being spent, in order to know its age, as well as know which outputs are change and which are not, to know the amount (assuming change would not be counted in that calculation, I'm not super familiar with that metric).

Once RingCT is enabled, you wouldn't see amounts at all, so not even a range could be calculated.

Your best bet would be to trust the main exchanges to properly report their volume (but then you only get volume, not age of outputs).

Edit: in fact, I'm thinking another metric might actually be a not-so-bad replacement: Monero has per kB fees which are not trivial compared to bitcoin (0.01 monero per kB). Once RingCT is merged, most transactions will be 1 or 2 inputs and two outputs (payment + change). Assuming nobody will move money just for the fun of it, due to the fees, maybe counting cumulative transaction sizes would give a good idea of the actual amount of use. That'd be closer to "users" rather than "capital", since the amounts will be hidden, but that might not be a bad thing altogether, just different.


Is there a list of active monero full nodes? Is there a list of active Monero full nodes?

Something like Bitnodes for Bitcoin that maintains a list of IP addresses for currently active Monero nodes.

Nodes are aware of the nodes that they are connected to and can request a list of peers from those nodes. These lists can identify a many nodes, but a significant number will always be missed. Some nodes are only online part time, may have closed ports, or frequently change IP addresses, making accurate tracking more difficult. Monero Hash attempts to track Monero nodes but is not aware of all of them as explained by Riccardo Spagni in a recent interview on Bitcoin Uncensored:

  Monero Hash tracks nodes, but they don't track every single node. Its not like they are plowing through nodes like chain analysis would, trying to enumerate them. As an example they track 1 node in South Africa, but I am running two and I know two other people that are running full nodes here. So the fact that are only tracking one South African node means they are not tracking everything. They are tracking like 400+ full time nodes that are instantly accessible with open ports. Probably 2-3 months ago we were sitting on 100-125 nodes.


Why will the v5 fork raise the min block size to 300,000 bytes? Why will the v5 fork raise the min block size to 300,000 bytes?

  v5 is now used for an increased minimum block size (from 60000
  to 300000) to cater for larger typical/minimum transaction size.

I know that there have been some transaction waiting in the txpool recently but they are eventually confirmed and Monero dynamic block sizes gradually increase with network transaction volumes. Why not leave that portion of the code as is and let dynamic block sizes adjust on their own?

@Jollymort will probably answer this better but the current dynamic size algorithm didn't work well with RingCT transactions. It worked well with non RingCT transactions, which were smaller.

Once a miner has put enough transactions in a block to reach the median size of the last 100 blocks she faces this decision:

add one more transaction, which, in case of RingCT, is about 13kB, get the associated fee and pay a penalty
push the block without going above the median block size

The only situations where option 1 makes sense are when:

the fee of the additional block is at least as much as the penalty, or
the daemon that the miner is running is altruistic

At the moment, the first situation is rare and the penalty is generally much more than a typical fee.

And the network can't really count on miners being altruistic to grow (note that the algorithm of some daemons is in that situation and will grow the size even if it costs money, due to a bug - that possibly explains why the median size grew to 100 kB or so a few days ago).

Hence the idea to grow the block size limit to 300kB, point at which the penalty of adding one transaction is offset by a typical fee and miners have an incentive to slowly grow block sizes.


Roadmap after RingCT and Kovri After RingCT and Kovri, which new features are on the road-map to be implemented?

The design and development goals are on the website: https://getmonero.org/design-goals/

RingCT still needs performance and efficiency improvements, but more than that it opens up a way to do multisignature transactions, so that has to be built.

Beyond that, there are loads of critical features and improvements, and lots more that will have to fleshed out on the research side of things before we could even attempt to write code.


Why can I not choose my own custom transaction fee? Does this affect privacy in anyway? I was just wondering why users do not have the ability to have their own custom fees and if by allowing users to choose their own fees would this badly affect privacy in anyway?

You can choose a multiplier. Choosing a custom fee could give away certain pattern and enable clustering of transactions matching the pattern.

When choosing a multiplier, you can still give priority to the TX, but your TX wouldn't stand out as 'special', since everyone is using multipliers.

Choosing some other fee smaller than the minimum fee would be pointless as it wouldn't get mined and it would get stuck in the mempool.

The minimum fee has been designed to keep the 'status quo' of the blocksize. Using the minimum is ok for 'normal' times, as miners wouldn't earn more if they should increase the block size. In case of increased use, users would use a multiplier to 'bribe' the miners to bump the block size. After the new median has been established, miners would stop losing part of block reward and users could go back to minimum fee (which would be lower than what we started with!), but the blocksize cap will remain as long as there's actual network use to sustain it.

Some ideal cycle would be like this:

Steady state, block size cap sufficient to let everyone get in the first block
Increased use, some delays experienced, impatient users paying more fee and making it economically viable for miners to increase the block size cap
Bigger blocks make the median larger
After 100 blocks, a new median is set and miners stop losing block reward, but increased cap is 'won'.
If the cap is enough and blocks are again not getting full, everyone can go back to the minimum fee and continue to use the network as usual, but now with smaller minimum fee and more capacity!
If there's no use, we go back to bigger min. fee and smaller blocks
If there comes more use, we repeat the cycle to get bigger blocks and smaller min. fee!

At the new steady state, users get cheaper TX-es and it's all the same for the miners (they're not penalized anymore, but the fees go back to min.). However, if they would drop some TX-es, they would lose out fee revenue so there's always incentive to keep the status-quo, until some fee pressure builds up...


Is it private pool mining efficient? I have several machines ready to mine. Is it more efficient to setup one machine as the central "pool"(e.g. with a software like this) and connect other machines/miners to it or is it more efficient to "solo" mine on each machine without a central pool. I'm aware of the pro/cons of public pools but I'm not interested(due the lack of trust).

Private pool pros:

You need only 1 copy of the blockchain and one node instance versus n copies for independent solo mining on each machine. You can help bandwidth by hooking 1 node to the outside network, and rest of them to this one "main" but you'd still have n copies of the blockchain on each machine.
You have more versatility with regards to mining software as some of them work only with pools
You can set worker IDs and monitor each miner stats from one single place

Private pool cons:

Involves more time to learn how to set up and maintain a private pool.

There shouldn't be any measurable performance differences, and you could even set up each machine to solo-mine to the pool but you get the benefits of optimizing your network / storage requirements.

Also, you might want to consider this pool software as well. For that one, if you get stuck with it I believe you could find help rather quick in #monero-pools channel on IRC


What is Monero's mechanism for defending against a double-spend attack? The title says it all, but I want to frame the issue two ways, in hopes of a slightly more in-depth answer.

With Bitcoin, the blockchain is transparent.  In the "ordinary course of business" in the world of Bitcoin, it's rather simple for miners to quickly prove whether or not an output is available to be spent.  But how does it work with Monero?

What made me think to ask this is that when recovering a wallet, it took my computer hours to scan the blockchain, presumably using my private send key and private view key all along the way, while it determined which outputs were in my address and which of those outputs I had spent as inputs in new 'send' transactions.  If my computer has to work so hard to prove that it has legitimate outputs to spend, how can blocks be mined so quickly (in minutes) without double-spends sneaking by?

Double spends are prevented by the use of key images, which are sent along with each output being spent in a transaction, and which are checked for uniqueness before allowing the transaction.

In the Cryptonote protocol, an output's private key can be used to uniquely generate a key image in such a way that a miner can check a purported key image really is correct. When spending an output, its key image is calculated by the sender, and included in the transaction. Miners then check these key images are real, and check whether they were already seen in the blockchain. If they were, it means the output being spent was already spent in a previous transaction, which is then discarded.

Since a miner can verify a purported key image, but not create one without the private key (similar to a cryptographic signature), only the owner of the output may spend it - just once.

The set of key images must then be kept for lookup by miners and other nodes. This is the "unbounded TXO set" that is often mentioned as a cons of using Monero/Cryptonote. Each key image is 32 bytes long.

Once RingCT is enabled, this system will not change, as RingCT includes that system as well. However, since transactions will not have to split amounts anymore, that TXO set growth will substantially decrease.

UPDATE: RingCT is now enabled.  You can read more about it here: What is RingCT and how does it make Monero private?


Remote Node, Full Nodes, etc Q1: My first question surrounds wallets for Monero. I have come to understand that remote nodes can be tracking your IP address and hence are not secure. Would light weight wallets like MyMonero APP be considered a remote node?

Q2: When activating my full node wallet from getmonero.org should I be using a VPN/TOR to do this? Whilst using my full node wallet could anyone be tracking my IP or viewing my transactions and stuff?

Q3: I don't currently have my full node wallet setup yet, but I would like to buy an item with Monero without the payment chain being traceable back to an exchange with my ID. So, this is what I had in mind.

1.Buy Bitcoin from coinbase with my ID attached.

Using Tor, I will access an exchange that will allow me to buy Monero for Bitcoin. This exchange will be one without KYC.
I will have the exchange send the Monero to a website wallet that has a .onion site. Such as XMRWallet.
Finally, I will access the website XMR.to (the Tor .onion version) which is a site that allows you to send it Monero and in return it will send Bitcoin to any recipient address. Using XMR.to, I will have them purchase the item that I wanted with Bitcoin, whilst I cover the costs with Monero from my XMRWallet.

I would like to emphasise, Steps 2-4 inclusive were all done using Tor. Would this be traceable back to my coinbase account?

Same question, same answer

Yes. Remote nodes can track your IP address, in which case your privacy could be lessened.
If you feel, if someone might knowing your IP address, as a security issue, don't use remote nodes, or use VPN.
Yes. MyMonero is using a remote node. Anything not connecting to a local node, is using a remote node.
Note that communication between a local wallet and a remote node is encrypted, and nobody will know what you are doing.
When connecting your wallet to a local node, that traffic is, well, local.
Your local node will connect to remote nodes, and they will know that a node is running on that IP address.
Using TOR/VPN will mask that.
If you want to buy something, using Monero, why not just get XMR from an exchange?
As soon as those XMR leaves the exchange, they are gone.
The exchange will know that you got some XMR, but that's where the the trail ends.
If you go The Bitcoin route, your your trail will lead all the way to the No KYC exchange.
Using a remote XMR wallet, onion or not, will not give you more privacy, than using your local wallet.
Your transactions can not be tracked on a local wallet. They might be, on a remote web-wallet.
So, instead of all that bouncing around, you could just:
VPN=>KYC Exchange=>(clearnet) XMR => Your wallet=>(Onion) XMR=>XMR.to=>Bitcoin=>Vendor


Will the RingCT fork make it harder for other CryptoNote coins to merge improvements made to Monero? Monero has already made substantial changes to its codebase. Will the RingCT fork make it harder for other CryptoNote coins to merge improvements made to Monero?

Does every major fork make it more difficult for downstream Monero forks (like Aeon) to merge improvements made to Monero (such as LMDB now and soon RingCT)?

Will upstream merges (such as pruning or PoW changes made by Aeon) become more difficult for Monero to implement in the future as its codebase becomes more and more different?

Yes, it will. Every time a substantial change is made in one fork, the other forks will find it more difficult to port anything they might want where it conflicts.

I'd say the main change from the point of view of mergeability between forks was the LMDB change, which rewrote a large part of the blockchain handling.

Cryptonote has also changed a lot since Monero forked, and it would also be difficult for Monero to merge code from newer forks.

I don't think there's been a particular desire from other CN projects to merge code from Monero, however. Some things were merged (payment id related code, some fixes), but I don't think it was that much. Same as Monero did not merge XDN's messaging, for instance.


With the Monero Wallet GUI is it suppose to start synchronizing every time you open it even after it completed synchronizing the 1st time i opened it? Even though my question(according to stackexchange) appears subjective and is likely to be closed, Im still asking it because its driving me crazy and i just want someone to help me PLEASE.

When I first downloaded Monero for windows(windows 10) and finally opened Monero GUI wallet for for first time it said "waiting on Daemon to finish synchronizing" and at the bottom left showed how many blocks were remaining and finally after leaving my laptop on over night and 12 more hours it was finally finished and the monero that i had sent to the wallet finally showed up. So I was excited and thought that was it. So after being on my laptop for a few more hours i closed the wallet and shutdown the laptop. The next day when I turned my laptop on I opened my Monero GUI wallet only to find it saying AGAIN "waiting on Daemon to finish synchronizing" and the thousands of blocks remaining. So is this normal? Every time you open your wallet it has to start synchronizing all over again?! If so that is just absolutely ridiculous. Can someone FOR THE LOVE OF GOD PLEASE help me fix this problem if it even can be fixed. If it cant can someone point me in the direction of a different desktop monero wallet thats closer and more like Electrum or Exodus? Please can someone help me?!?!?!?!

You need to sync only the amount that was not synced since the last time you used it.

If, for example, you used Monero on Monday and then used it again on Wednesday, you would only need to sync the difference. You should not need to start over each time you open the wallet.


How would I exploit the fact that I knew the scalar used for H in the Pedersons Commitment w.r.t G? If H was badly chosen for the Pederson Commitment, such that the attacker knew a k where H = kG (1)

What damage could be done to the system?

We know that C = aH + bG

If I commit a = 10 and b = 2

We have C = 10H + 2G

Substituting k:

C = 10kG + 2G

C = (10k + 2)G

How does this help the attacker create the same C value with different a and b values? As I see it, the discrete log problem has not been broken, just a bad H value was chosen.

My guess is that:

Any commitment can now be broken down into C = akG + bG. From this, we can take a value c and d.

where C2 = cH + dG

C2 = ckG + dG

We can then choose different values e and f, in order to make e and f map to the same commitment C2. We do:

x = e - ck

y = f - d

We can then form C2 with e and f by doing:

C2 = eG + xG + fG + yG

C2 = eG + (eG - ckG) + fG + (fG - dG)

C2 = 2eG - cH + 2fG - dG

C2 = -cH + (2e+2f-d)G

The point of a commitment is that it prevents you from later claiming that you'd committed to a different value.

To use the usual algebraic letters, a commitment is C = xG + aH where the value a is being committed to and the value x is the mask (a.k.a. blinding factor).

Revealing x and a after you've created the commitment C will prove that you had committed to that particular value of a afterwards, if h is unknowable.

If the discrete logarithm of H w.r.t. G was known, we'll call it h, then C = xG + ahG == (x+ah)G.

This means you could later on decide to pretend you'd committed to a different value a' of your choice, and calculate the alternative mask you'd need to claim as x' = x + h(a-a').

Therefore knowledge of h means that commitments can't be trusted. It also means you know the private key of the commitment as c = (x+ah). This breaks a useful property of a Pedersen Commitment used in RingCT, which is that only commitments to zero have knowable private keys. This means that if h is unknowable, providing a valid signature for the public key C will prove the amount you'd committed to was zero.

H is chosen arbitrarily, which prevents anyone from being able to figure out h. If you could figure it out, you'd have broken the elliptic curve discrete logarithm problem.

To answer the question as to how knowledge of h could be exploited specifically in Monero:

When you receive an output in a transaction, the transaction publicly declares a commitment to the value of that output. When you create new outputs in a transaction that spends the aforementioned output, you also declare commitments to the values of the outputs you're creating.

A verifier will check that the sum of input commitments - output commitments - fee commitment is a commitment to zero, because you will provide a RingCT signature using the private key of that commitment to zero (which is simply the mask of that commitment to zero). Verifiers will be satisfied that the signature is only possible if that private key is known, and that private key is only knowable for commitments to zero ordinarily. Since you know h though, you will be able to sign commitments to non-zero values, and so can produce a RingCT signature even when the outputs you're creating in the transaction are greater in value than the outputs you're spending. Therefore you could create XMR out of thin air, and no one would know.


GUI wallet stopped syncing I opened the gui wallet after a month of not using it.
It started syncing for a day but then just stopped.
It says it is connected and syncing but stays at the same last block.
I have restarted it several times but it stays the same.
I'm not sure what to do.
Any help would be appreciated.
Thanks!!
Don

I'm very new at this, but I think that particular block was the fork.  This means you have to be running the newest Monero software, and the first version will not sync past that point.  (I'm having a similar problem, with a different block.)


Which password limitations do exist? I refer with my question primary to length, based on bytes because a sign in UTF-8 can have 1-4 bytes.
Furthermore some special signs like control-signs might not be allowed.
This question is related to bulk-creation of wallets, so it's not about my personal desire or needs but only about technical limitations.
Please, if you've any information about limited field-lengths in databases of exchange- or trading-platforms, that's welcome too as it's indirectly related to my question.
Also password limitations of any monero-related software are welcome.

I read the question beside answer related to "are there certain-characters unsuitable for passwords" but think that this question is no duplicate as it's more detailed.

UPDATE:
The following related issues I found on github:

https://github.com/monero-project/monero-gui/issues/653
https://github.com/monero-project/monero-gui/issues/883
https://github.com/monero-project/monero/issues/938

Own verifications still include much more signs which make some problems but due to the large amount of UTF-8 signs it's hard to make a list especially related to languages like Arabic, but others too.

Since your question is not a duplicate of that other one as it's more detailed, my answer will just be a part of the the answer to that other one:

There is no length requirement (within reason - don't go using 4 billion character password or you'll run out of memory, and there might be a standard C++ library string limit, but if there is, it's likely pretty high).


Best method to query address balance of 10,000+ monero private keys and store it in a mysql database? I'm looking to write up a PHP script that can query 10,000 monero private keys to get its balance. Once the balance is updated, it will be stored in a mysql database. I know scanning the monero blockchain can take quite some time for each address. Each of my users have a shared monero "private key" where they have access to the funds as do I. I want to create a website that keeps track of the balances in these addresses.

I was thinking of scanning each address initially even if it takes awhile. Then keep track of the last scanned height and start from there again on a 5-10 minute cron run. I'm not sure if this is the best method and would like to know if there are other good solutions to this problem?

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

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

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

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


Answer to pool request For educational purposes I wrote a program which performs the Cryptonight hash on some input. I verified my results using this "online-hasher" https://xmr.llcoins.net/slowhash.html .

Since I had some fun with this project I wanted to go one step further and try to let my program connect to a pool and do some work there. From the pool I get "id", "blob", "job_id" and "target". My superior packet-inspection skills suggest that the pool wants a "nonce" and a "result". However, I fail to fully understand how exactly these values are calculated.

I appreciate any help.

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

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


Why can I not recover my Monero wallet? The Monero GUI wallet does not accept my password and I do not have the mnemonic seed or written down keys. I have attempted to recover it using the .keys file, but after choosing "Open wallet from file", it still asks for the password, that it does not accept. I have downloaded the official wallet from getmonero.org and I'm using a Ledger Nano.

How can I recover the wallet?

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

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


Is it possible to see the number of confirmations and source address using Monero wallet CLI? GUI version provides number of confirmations and address from which coins were sent.
But I don't know how to see it using CLI version of wallet.
I tried to use show_transactions and show_transaction <txid>, but it didn't help.
show_transaction <txid> shows number of confirmations only for received coins, but not for sent coins. Why? And how to see the source address?
Hope for your help!

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


I want to mine Monero but I do not have money for a better GPU / equipment I have a notebook.

I want to mine with my GPU, but in the GUI, no GPU appears. My CPU is an i3 4th generation series U. How long can I be mining without damaging my CPU?

My notebook has a GPU: AMD R5 M330 2 GB, which I think should be more powerful.

Firstly, if you are trying to mine for profit, that wont happen with a notebook of your spec.

Next, you cannot mine with a GPU using the Monero GUI. Only the CPU. If you want to mine with a GPU you will need to use a dedicated miner application. This said, mining with your GPU is again pointless, as the spec is very low (even if you can find a miner that supports it).

If you really want to get into mining, you are going to have to do lots more research and invest in better equipment to mine with.


Transaction rejected by daemon with status: Failed Error: Reason: fee too low Recently I sent several transactions in a short period of time but my available balance was always more than enough for each transaction, so I did not think that chained payments should have been a problem. Because I use the set always-confirm-transfers 1 command I am able to see the fee information before each transaction.

I thought I remembered a message telling me I was about to send xxxx Monero with a fee of xxxx Monero of which xxxx Monero contains unconfirmed outputs. However because of the log level I was using, I cannot confirm (from my log file) this message as fact. If my memory is wrong, the correct message was likely:

  The transaction fee is 0.02xxxxxxxxxx, of which 0.00xxxxxxxxxx is dust from change.
  Is this okay?  (Y/Yes/N/No)

My available balance was far greater than the amount I was sending and the message seemed to be talking about the tiny quantity of unconfirmed outputs being used in the transaction fee itself. Out of curiosity, I selected Y to confirm the transaction and received the following error message:

  Error: transaction < xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > was rejected by daemon with status: Failed

  Error: Reason: fee too low

My logs provide additional details:

  date,time ERROR /DISTRIBUTION-BUILD/src/wallet/wallet2.cpp:2506 daemon_send_resp.status != CORE_RPC_STATUS_OK. THROW EXCEPTION: error::tx_rejected

  date,time /DISTRIBUTION-BUILD/src/wallet/wallet2.cpp:2506:N5tools5error11tx_rejectedE: transaction was rejected by daemon, status = Failed, tx:

  key offets, key images, etc xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

  signatures xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

  Error: transaction < xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > was rejected by daemon with status: Failed

  Error: Reason: fee too low

I tried sending the same transaction less than 10 seconds later (no block confirmations in between) and it went through with no error. It appears as if the second time random outputs were chosen again for transaction fees and based on the always-confirm-transfers option, this time no unconfirmed outputs were being used for the tx fee.

I am certain that I had plenty of available outputs for each transaction I sent.

Are outputs used for transaction fees selected at random (including from unconfirmed outputs) so occasionally a transaction can be rejected for the reason above even when there are plenty of available Monero outputs for the transaction itself?

This has nothing to do with unconfirmed outputs. What likely happened is that, due to varint encoding, a slight post creation change to the tx caused it to jump to a high size threshold, and since the fee is per kB, the fee was suddenly not enough. This is a bug in transaction creation. This is pretty rare, since it needs the change to cause a size increase, and the original size to be just a byte (or two, if unlucky) from the next kB limit.

There was a bug about this which got fixed a while ago, but there apparently is another one still, assuming you're using a recent master. The good news is that it is transient and doesn't break anything apart from needing to send again.

Chained payments do not exist in Monero. Since any output on the chain may be used by others as fake outputs, the owner is not allowed to use them either, for privacy reasons.


Help needed with calculating a key image I am working on monero synchronization on an ARM cortex m4 microcontroller and I got stuck with computing key image.
As a testing data I created a fresh wallet A and a fresh wallet B. I funded wallet A with some amount, then I did a swipe_all and sent all funds to wallet B. Now am trying to compute the same key image as I got from the swipe_all transaction.

Key image should be computed like this:

I = x * Hp(P)

where x is output's private key, Hp is a hash_to_point function and P is an output.

This is a mininero's implementation of hash_to_ec, which I m trying to rewrite in C:

def hash_to_ec(key):
    #takes a hash and turns into a point on the curve
    #In MININERO, I'm not using the byte representation
    #So this function is superfluous
    h = hash_to_scalar(key, len(key))
    point = ge_scalarmult_base(h)
    return ge_mul8(point)

My testing data, I have tx's privkey x and output P (I know this P is mine):

x:  39f60ab67a49c086d5c31a37cd503fdf0867b57410e7df370a981a1828b0790e
P:  dbf2922ecf49468ab09cf70fc4294de5036f2befaaaa14e0a108a0f5dd13128a

I want to compute a key image out of that. I divided it into two steps, [1] hash_to_point and [2] multiply with x:

[1] hash_to_point function:
   [1.1] At first  I take P and compute hash_to_scalar (keccak256 and
         then reduce32, this looks working well), output is here:
         5845a60b165d38e30a7af2232069333d9b5b5305632a6b004fce31ad708b1b05

   [1.2] After that I multiply it on a curve with a base point G,
         output is here:
         c886e669ea11a42317797b008fd053717887505c59a2dd26c4d2ca12efe3ac77

   [1.3] Now I multiply it with 8, then do a modulo with a prime
         p25519p25519 = (2**255 - 19), output is here:
         c02a325db0e8c21957d0931f01499be9d9dc9a2a1853590378728e69855bdc28

[2] Now I should get a keyImage by taking an output from [1.3],
    treating it as an Y-coordinate of a point on a curve, and
    multiplying this point with x. Output is here (Y-coordinate):
    322af4d8e6250d3f4a2de39462569bc43d88701d810aeb531871045dd858f8b7

[3] But the keyImage of this output which I later spent and found
    on a blockchain is this:
    40c13470bce4d81ab1d7a38d78e0d73daee6f26d206891bbe6bf9efedabc1a62

Please, could somebody run a working code on my data and help me to find the point of failure? I am quite lost here.. Many thanks in advance!

The hash_to_ec function in Mininero is not the same as the one used in the Monero C codebase. You need to use hashToPointCN from Mininero instead. See https://github.com/monero-project/mininero/blob/master/mininero.py#L238

If you're looking for the C version of this, you can find it named hash_to_ec here: https://github.com/monero-project/monero/blob/8f6f674753bae7494e1ee4569004947d47a4e983/src/crypto/crypto.cpp#L481 (and also see the generate_key_image function below it)

Also note that x is the output private key of the output P, and not the transaction private key. The transaction private key is not something that the recipient will have visibility of or will ever need to know, as it is something normally kept secret by the sender. I checked the x and P values you stated, and P does equal xG, so you are using the correct value of x.


Are there any games which use Monero as money? Are there any popular community games which are using Monero as money for its economy?

Not explicitly, no.

The closest example would be CryptoKingdom.  They use their own in-game currency, but I believe it's directly proportional to Monero supply and/or is easy to cash out with and transform into Monero.


Will 2 minute block times discourage retail merchant adoption? Waiting an average of two minutes for a transaction confirmation is a long time when there is a line of people at a checkout counter. This is particularly true when compared to nearly instant Visa/Mastercard confirmations.

Monero confirmations are 5x faster than Bitcoin on average. How do some retail merchants accept Bitcoin without waiting for a transaction confirmation (I have been to a bar for example and paid with Bitcoin without being required to wait for a block confirmation)?

Can retail merchants accepting Monero use the same method(s) that these Bitcoin retail merchants use to safely accept transactions without waiting for block confirmation?

Is scanning the mempool for transactions that have not yet been confirmed easier of more difficult for Monero compared to Bitcoin? If a Monero payment processor is used and is a victim of a double spend (after accepting a 0 conf transaction at a coffee shop) will the loss be eaten by the payment processor or the coffee shop?

Actually, instant (well, speed of information) payment channels are possible with monero, even now (no protocol changes to monero necessary).

First we will just start with one way payment channels. The merchant and buyer set up a some sort of multisig wallet. They mutually sign a transaction that sends the its contents back to the sender. The signature is sealed in time-release crypto using steps 2 through 2 through 4 here which forms the expiration date of the channel (which can be updated). The merchant will want to not accept transactions after or even near the expiration date. The time release crypto only needs to be released if the merchant is dishonest; an honest merchant can help the buyer recover his funds without it.

Now, to send funds to the merchant, such that the merchant instantly knows he cannot be cheated, the merchant and buyer simply mutually sign a transaction to the merchant's personal monero address. This can not be double spent, since the merchant would need to sign a transaction to double spend it. Additionally, they need to create a new expiration transaction, since it will have the wrong input. This also gives them an opportunity to set up a new release date.

You can also encrypt the transactions with the merchant's public key. This means that if the buyer sends them X monero, but then wants to send them Y, the merchant and buyer can simply create a new X+Y monero transfer, without the merchant fearing that the X monero transaction would override it (as long as he didn't publish it). The merchant could, say, publish these transactions once day, making this system ideal for micropayments.

Exercise for the reader: generalize the above into lightning network (hint: even more Secure multi-party computation will be needed).


Ring signatures and the long view Imagine the Monero blockchain has been around for decades. It is incredibly massive and the total number of outputs far exceeds the rate of new outputs being created. Can obfuscation acquired by the ring signature technique decline to useless levels? In other words, can the rate of recent new possible outputs being included in forthcoming transactions fall to near zero, because the probability of inclusion falls toward zero? The probability of a new output being obscured by x amount of signatures after time t would always fall as the chain extends.

Someone on reddit https://www.reddit.com/r/Monero/comments/7k4lwx/question_longterm_ring_signatures/ mentioned 25% of signatures on new transactions are selected from the last 5 days of blocks. This seems like a fatal flaw, because blockchain analysis can just ignore that 5 day spike and treat subsequent appearances of an output with a lot of significance. Am I misunderstanding something?

If this is a problem, the solution seems to simply make output selection a probability distribution decaying from more recent to more distant blocks. Old outputs reappearing would be significant, but observers would have much less confidence than if they could ignore most of their obfuscation.

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

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


Can a transaction signed by a cold wallet be broadcast sometime far in the future? Could someone sign a transaction, encrypt it with a (2,3) Shamir's Secret Sharing scheme with one key to signer, one to trustee and one to beneficiary?

Then after death sometime years from now could the trustee and beneficiary transmit the previously signed transaction per the instructions of the deceased signor?

If some future transaction fee increase would prevent the above scheme from working could the signor voluntarily pay an exorbitant transaction fee in the original signed transaction in order to future proof against future network fee increases?

It is possible but would likely fail, I wouldn't do this. Not only can transaction fees change as you mentioned, but so can the transaction protocol. If a new transaction field is made mandatory, then your transaction would be rejected by the network. The longer you wait the greater the chance it will fail.

My only suggestion is to use the (2,3) Shamir's Secret Sharing scheme on the signer's private key, so a transaction can be signed when two people agree on decrypting the private key. This isn't the same or as secure as multi-sig, but for your use case it seems reasonable.


How do I constrain memory usage during initial blockchain sync I'm trying to get monerod up and running on a VPS with 1gb of RAM.  My understanding is that once the chain is synced, monerod's memory usage should be quite reasonable.  However, during the initial blockchain sync process, it is outgrowing the 1gb limit.

A search on here and on reddit turned up a recommendation to use ulimit.  However, when I type:
ulimit -v 1000000 to constrain the virtual memory to 1gb of RAM, monerod won't even start, complaining that there isn't enough memory to do its initial allocation.

1gb of RAM is supposed to be within the minimal requirements for Monero, so what is the correct way to constrain memory usage?

During sync, Monero will add chunks of 200 blocks at a time. The speedup gained from this quickly goes into diminishing returns as the chunk size grows, but the memory usage grows linearly, so it's possible to decrease that chunk size with the --block-sync-size N parameter. A plausible value for N is 20 instead of 200, and the speed will be similar (if you're memory starved, it could even be faster since your machine might stop swapping if it was doing so with the defaults).


What are the threats against I2P? Threat modeling is a process by which potential threats can be identified, enumerated, and prioritized

What are the considered attacks in I2P's threat model ?

I2P's threat model consists of :

Brute force attacks

  A brute force attack can be mounted by a global passive or active adversary, watching all the messages pass between all of the nodes and attempting to correlate which message follows which path

Timing attacks

  I2P's messages are unidirectional and do not necessarily imply that a reply will be sent. However, applications on top of I2P will most likely have recognizable patterns within the frequency of their messages - for instance, an HTTP request will be a small message with a large sequence of reply messages containing the HTTP response. Using this data as well as a broad view of the network topology, an attacker may be able to disqualify some links as being too slow to have passed the message along

Intersection attacks

  Periodically make contact with the target and keep track of what peers are on the network. Over time, as node churn occurs the attacker will gain significant information about the target by simply intersecting the sets of peers that are online when a message successfully goes throug

Denial of service attacks

Greedy user attack

  people trying to consume significantly more resources than they are willing to contribute

Starvation attack

  harm the network by creating a significant number of peers in the network who [...] then decide not to provide any resources to the network

Flooding attack

  standard IP layer flooding

CPU load attack

  request that a peer perform some cryptographically expensive operation

Floodfill DOS attack

  becoming a floodfill router [...] and provide bad or no response to lookups, and it may also interfere with inter-floodfill communication

Tagging attacks

  modifying a message so that it can later be identified further along the path

Partitioning attacks

  finding ways to segregate (technically or analytically) the peers in a network

Predecessor attacks

  passively gathering statistics in an attempt to see what peers are 'close' to the destination

Harvesting attacks

  compiling a list of users running I2P

Identification Through Traffic Analysis

  By inspecting the traffic into and out of a router, a malicious ISP or state-level firewall could identify that a computer is running I2P

Sybil attacks

  category of attacks where the adversary creates arbitrarily large numbers of colluding nodes and uses the increased numbers to help mounting other attacks

Buddy Exhaustion attacks

  By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure that a tunnel is formed wholly from its set of colluding routers

Cryptographic attacks

  I2P was not designed with easy mechanisms to lengthen keys or change shared secret values while maintaining backward compatibility

Floodfill Anonymity attacks

  floodfill routers are uniquely positioned to learn about network participants

Other Network Database attacks

  attempt to harm the network by creating one or more floodfill routers and crafting them to offer bad, slow, or no response

Central Resource Attacks

  centralized resources in the development and operation of the I2P network,

Development attacks

  go after its development team by either introducing legal hurdles on anyone contributing to the development of the software, or by using whatever means are available to get the developers to subvert the software

Implementation attacks (bugs)

  errors in the design or implementation

Source here (also describe defenses against these threats)


What was the problem with ASNL forgery? For background there is https://nickler.ninja/blog/2016/12/17/a-problem-with-ringct/ and this problem had been fixed before this post was made by changing ASNL to borromean signature. For background on what borromean signature is here is this question for background on what borromean signatures are What are Borromean signatures? Now obviously it has already been fixed but what was the exact problem with ASNL that could have been exploited in more simple terms?

The problem was exactly that - possible forgery. In the RCT paper, there was a proof that you can't forge ASNL range proof which later turned out to have an error. See here for more details.

Why do we need these proofs / signatures? From the RCT paper (emphasis mine):

  ... as -1 is a very large number modulo the curve group order, free
  money has been created. It is therefore necessary to prove that the
  C_out,i are commitments to values which are positive and lie in a
  restricted range [0,2^n] for some n.

These signatures are used to prove that one is not using just anything to hide the amounts, ie to prove what I've highlighted above. It's important because allowing just anything would make it possible to cheat the sum(ins) == sum(outs) part of transaction verification. It's important that the proof be airtight, otherwise you could make a transaction where sum(ins) != sum(outs) but which would be validated as if both sides were equal.

The ASNL proof was not good, so it was replaced with Borromean. With ASNL it would have been possible to create an exploit (as the author of your linked post did) which could create or destroy monero, and bypassing the intended coin supply. A scary thought indeed.


Generating a new wallet, locally, from your android wallet app Has anyone tried implementing a wrapper between a wallet generator written in C/C++, like wallet2.cpp, using NDK (android native development kit) to communicate back to an android app?

Does anyone have a better idea to generate a new wallet from an android phone (locally)?

monero-wallet-gui can be seen as a "wrapper" for wallet2.cpp, and it can be built for android with NDK.

Alternatively, monero-wallet-cli can also be built with android NDK, but you would need a terminal emulator to run it (except if you use adb ), so better to  just use the provided arm binaries.

Finally, if it's only about generating keys, you can use a web page, like moneromooo's wallet generator but stored locally.

Edit: i may have misread the question

Android java apps can use JNI to have an instance of  WalletManager and call WalletManager::createWallet.


How to conduct E-commerce transactions, XMR to GBP and conversion to fiat without KYC registration documents I'd be grateful for some advice and help. I’m not a web developer and have basic knowledge of html and even less of crypto language.

What I want to do is sell items on a website where customers pay in Monero. But I want the amount to show in GBP for example customers, click an item and the price shows £10. I then want the XMR sent to my wallet, and eventually exchanged for GBP.

I want the whole setup to be as private as possible, with no KYC or other documents needed to register.

There is Vigla but it doesn’t convert to fiat it only accepts Monero.  There is Globee but it requires KYC and extensive registration documents.

so in essence I need to know:

1. Is there a fiat to XMR convertor an ecommerce site owner can use? The customer should be able to click a button to buyan item priced £10, and be presented with the converted amount in XMR to pay from their XMR wallet.

2. Is there an exchange that can do an XMR to GBP fiat conversion that
    doesn’t require KYC registration?

Thanks in advance.

curl -s 'https://api.coingecko.com/api/v3/coins/markets?vs_currency=gbp&ids=monero'  | jq . | grep current_price | cut -d':' -f2 | cut -d',' -f1

in bash will return the current GBP of Monero.  You can do your math on price from there.


Is Monero the only CryptoNote based coin with a public testnet? To the best of my knowledge Monero only has two forks, AEON and BipCoin

AEON was forked from Monero prior to the introduction of its testnet function although its lead developer plans to change that as part of the AEON roadmap

  There is not a testnet because the work that was done to create a testnet function in Monero was after the AEON fork. We'll have one once we switch over to the newer code base.

I can find no mention of a public testnet for Bipcoin.

Are there any Monero forks or other CryptoNote coins with a public testnet or is Monero unique in that regard?

I am not aware of any other Monero forks besides the two that you mentioned.

There are other CryptoNote currencies but I am not aware of any that have a public testnet. The level of community and developer interest in most other CryptoNote projects is minuscule compared to Monero. Most CryptoNote coins were originally forked from Bytecoin with development severely lagging behind Monero. It would surprise me if any of them had a public testnet with much use.


Peers often report unknown top blocks. How can I find more reliable peers? The daemon regularly reports top blocks that are years in the past.

For example (IP addresses are anonymized):

2016-Oct-23 06:13:27.789171 [P2P2][123.45.67.89:18080 OUT] SYNCHRONIZED OK
2016-Oct-23 07:13:00.252292 [P2P2]WARNING: no two valid MoneroPulse DNS checkpoint records were received
2016-Oct-23 07:46:18.650151 [P2P6][89.123.45.67:18080 OUT]Sync data returned unknown top block: 1163525 -> 227082 [936443 blocks (756 days) ahead]
SYNCHRONIZATION started
2016-Oct-23 08:16:10.241713 [P2P0]WARNING: no two valid MoneroPulse DNS checkpoint records were received
2016-Oct-23 08:16:14.973720 [P2P6][234.56.78.90:18080 OUT]Sync data returned unknown top block: 1163542 -> 1134708 [28834 blocks (40 days) ahead]
SYNCHRONIZATION started
2016-Oct-23 08:16:17.184723 [P2P6][234.56.78.90:18080 OUT] SYNCHRONIZED OK
2016-Oct-23 08:16:52.855773 [P2P6][76.54.32.109:18080 OUT]Sync data returned unknown top block: 1163542 -> 89742 [1073800 blocks (851 days) ahead]
SYNCHRONIZATION started
2016-Oct-23 09:18:35.376071 [P2P2][111.222.33.44:18080 OUT]Sync data returned unknown top block: 1163582 -> 1009827 [153755 blocks (213 days) ahead]
SYNCHRONIZATION started
2016-Oct-23 09:19:53.890182 [P2P1][109.87.65.43:18080 OUT]Sync data returned unknown top block: 1163584 -> 211310 [952274 blocks (767 days) ahead]
SYNCHRONIZATION started
2016-Oct-23 09:20:21.270223 [P2P9]WARNING: no two valid MoneroPulse DNS checkpoint records were received
2016-Oct-23 09:20:24.152227 [P2P9][222.111.0.99:18080 OUT]Sync data returned unknown top block: 1163585 -> 1148462 [15123 blocks (21 days) ahead]
SYNCHRONIZATION started
2016-Oct-23 09:20:26.717231 [P2P6][222.111.0.99:18080 OUT] SYNCHRONIZED OK
2016-Oct-23 09:20:29.281235 [P2P9][56.78.90.123:18080 OUT]Sync data returned unknown top block: 1163585 -> 399859 [763726 blocks (636 days) ahead]
SYNCHRONIZATION started
2016-Oct-23 09:22:34.896279 [P2P9][222.111.0.99:18080 OUT] SYNCHRONIZED OK

According to this answer, this is not my problem; it just means that a peer has a different top block. It might be running behind, or it might be on a forked chain.

Usually this is not a problem. The 'status' command will return that I reached the top block on my chain. But shortly after the latest hard fork I did end up on the wrong chain. I made payments that didn't arrive and were not recorded on the valid chain. How can I find more reliable peers? Or fewer unreliable peers, to be precise. I have a long peer list, and always 8+0 connections.

Having a partially synced chain does not mean unreliability. It might be that these nodes are syncing the chain, as you presumably did at some point too. Banning these nodes would mean noone can start using Monero, and would cause the network to die off from attrition.

In order to get incoming connections (currently none, as the 8+0 shows), you need to allow port 18080 through your router, to connect to the machine running the daemon. Firewalls and such must also allow this port. You will then get more peers (and thus a higher likelihood to get one that's got a full chain).


Difference between kovri tunnel types In Stunnel, there is only 2 types of tunnels : client and server.

Why is there more types in kovri tunnels ?

What is the difference between types server  and http ? and between client and irc ?

Conceptually speaking, there are still only 2 types of tunnels : client and server.

But the idea is that we can do "better" for a specific application/protocol by leveraging some of its characteristics.

So http is a specialization of a server tunnel for the HTTP protocol, and likewise, irc is a specialization of a client tunnel for the IRC protocol.

Currently, there is no distinction between irc and client. There is this open ticket for this task.

AFAICT, here is the only distinction between http and server : it looks like it's used to dynamically change the Host parameter in the header of an HTTP request.


Miner is waiting a long time for new jobs I have implemented a custom RandomX Pool miner with C++ which even outperforms XMRig. However after submitting a share the miner does not always get a new job instantly. Sometimes it takes several seconds to get a new job. Even calling the RPC method getjob the miner is still waiting several seconds for new jobs. In this time the processor is doing nothing and just wasting time while waiting for a job...
I don‘t think that this issue is related to network latency because after the rpc method login a job is dispatched pretty instantly.
Is there anything I can do to reduce the waiting time for new jobs?

after submitting a share the miner does not always get a new job instantly

The pool will not send you a new job for each share you submit. You keep working on the same job until the pool sends you a new one.


Lithium Luna CLI no connection to Daemon unable to transfer monero-wallet-cli v0.12.0.0 Lithium Luna

OS: Linux 64bit Ubuntu 16.04

Transfer via CLI no longer works.  A couple days ago this worked fine.  I run the transfer command.

[wallet 4xxxxx]: transfer unimportant 13 4xxxxxx 1
No payment id is included with this transaction. Is this okay?  (Y/Yes/N/No): Y
Error: no connection to daemon. Please make sure daemon is running.
[wallet 4xxxxx]: status
Refreshed 1566204/1566204, synced, daemon RPC v1.19
[wallet 4xxxxx]: status
Refreshed 1566208/1566208, synced, daemon RPC v1.19

I see that monerod is running fine on my local machine when executing the status command.

What else can I try?

Thanks to dEBRUYNE.  This is what worked for me.

Stop monerod
Delete p2pstate.bin
Pop the last 8000 blocks (~800 blocks / day)

  ./monero-blockchain-import --data-dir path/to/data/directory --pop-blocks 8000

Start monerod

  ./monerod

Start monero wallet CLI

  ./monero-wallet-cli --data-dir path/to/data/directory


What happens to transactions sent via old software after hard fork? If I am using Monero binaries v0.10.3, and try to send transactions after the hard fork on September 15, 2017, will those transactions just be ignored by miners?

It all depends on the transaction. After the coming hard fork, ring sizes 3 and 4 will be forbidden on the network (bar certain special cases), but that is the main change. If you were to send a transaction with a 0.10.3.1 wallet with a ring size equal or greater to 5, it'd be accepted by a 0.11.0.0 daemon.


What is the best way to implement a deposit system with Monero's RPC calls? I'm currently building up a service where the user can deposit multiple cryptos. One of them is Monero, and that is where I'm stuck at the moment.

I use PHP for this and the following project: https://github.com/monero-integrations/monerophp

I tried to play around and thought the best way would be the following:
- generate an address
- check for incoming transfers of the given address

The problem is, that I can generate the address but anyway, when I'm using incoming_transfers or get_transfers, neither I get the needed transactions. I get all of the transactions belonging to the wallet.

Maybe I misunderstood the concept (accounts, addresses, subadresses) as Monero is rather new to me. Can somebody give me a hint what would be the best way to archive the result I want?

I don't need any code, just point me into the right direction, so I can have a look at it! :)

Thanks in advance guys!

I would suggest creating a subaddress per customer. Therefore, you will be calling the RPC method create_address (if using the monero-wallet-rpc directly), or the equivalent method in your referenced PHP wrapper library.

To check for incoming payments, you can use incoming_transfers (or the equivalent library method). Depending on your use case, you can request all subaddress incoming payments (e.g. don't supply the optional subaddr_indices parameter), or specific subbaddresses by specififying their respective indices in the subaddr_indices array parameter. An even better approach is to make use of the monero-wallet-rpc parameter --tx-notify which will execute a program each time you receive a payment, thus preventing the need for polling.

monero-wallet-rpc --help
...
  --tx-notify arg                   Run a program for each new incoming
                                    transaction, '%s' will be replaced by
                                    the transaction hash

You can then check which subaddress was deposited to by using get_transfer_by_txid.

A good overview of accounts and subaddresses can be found at https://monerodocs.org/public-address/subaddress/.


How do I upgrade my software to v0.11.1.0? I've been running CLI v0.11.0.0 and GUI v0.11.0.0. How do I update these to v0.11.1.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.11.0.0 binaries).

Note that a blockchain resync is not needed. If you open monerod-v.0.11.1.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.


Where can I find the random public key R=rG in a Tx? I've read the white paper of Monero(CryptoNote v2.0) and a problem confuses me.

This paper says that when Alice sends coin to Bob, she uses P = Hs(rA)G + B as a destination key and packs value R = rG "somewhere" into the Tx.

Since Bob needs R for checking whether this transaction goes to himself. Where can I find this R = rG in the public Monero blockchain data?

Or maybe the payment ID is actually this R?

The transaction public key, R, is in the tx_extra part of the transaction data structure. If you look at a block explorer, you'll see the transaction public key listed, e.g. it is e90bea66d774232033ef86684f17e756641dc7ba11bd23b7c3605d8387f2cf3c
 for this transaction: https://xmrchain.net/tx/a1ebbf1c50665e8ccf26d920b1df9e81ab7ffd8edec52c83709b4582656daa2b

The tx_extra data structure is defined here: https://cryptonote.org/cns/cns005.txt

The payment ID also happens to be communicated in the tx_extra, but is entirely unrelated and is optional for each transaction.


Benefits of running a Monero GUI and full node over Raspberry PI with Tails rather than on home PC I am setting up a Monero GUI on TAILS on a home PC or laptop and will run a full node with cold wallet but need some info about setting up on a Raspberry PI which I may do instead. I've seen the term 'raspberry pi' bandied about. Never used one of these. I'm not a comuputer code literate so don't get all the terms that geeks use. I will only use my node for synching and making transactions. No mining. The transactions will be payments from websites on clearnet, small sums. So I need a compatible system to set up.

When setting up a Monero GUI node on a home PC or laptop without
TAILS or TOR or WHONIX what is the IP and is it broadcasted when you
do transactions? I don't understand how running your own node is
better for privacy when the transaction has to be broadcast to the
other monero nodes somehow? doesn't your home IP address which your ISP gives you get broadcasted
Is it necessary to leave your Windows PC or laptop on if running a
full node from home? What happens if you cannot and you just synch
it now and then?
How is running a full Monero node from home on a Raspberry PI better
than doing so on a Windows laptop or PC? I'm assuming you can get a
Raspberry PI with Windows?
Is there a ready to use Raspberry PI with Monero installed? I have
only ever used Windows. I'm not familiar with coding language or
Command line prompts or know how to build from a motherboard. so
would it be better for me to stick to a Windows PC or can you buy a
Raspberry with Windows and use it with TAILS installed?
can anyone recommend which Raspberry PI would be ideal for the latest Monero release? Where to buy?

1)

  what is the IP and is it broadcasted when you do transactions?

The IP is whatever IP your ISP assigned to you. If you use a remote public node when transacting, it is leaked. It is not however "broadcast" in the tx.

  I don't understand how running your own node is better for privacy when the transaction has to be broadcast

Because when you create a tx and let your own full node broadcast it, other nodes have no way of knowing whether your node is the original node sending the tx (i.e. nodes just relay transactions to their connected peers).

Contrast this to using a public remote node instead of your own node. That public node knows you are the source of the tx. A malicious operator could log your IP address alongside the tx ID.

  doesn't your home IP address which your ISP gives you get broadcasted

See previous point. Your node leaks your IP to other connected peers, but when you relay a tx, the other nodes have no idea if your node was the first/original node (i.e. whether you created the tx). So using your own node, all you are essentially leaking is the fact you are using Monero.

2) No you do not need to keep your node running 24/7. Every time you start it, it will sync up from where it was last.

3) The Raspberry Pi is a poor choice to run Monero on. It has no hardware AES. There are better equivalent SBCs such as Rock64/Rock64Pro, Odroid and others. Some obvious reasons people may prefer these to a full on Windows PC are because they the are low power, small size, cheap and silent - ideal to just setup, switch-on and leave running.

4) Probably, but why not just buy (but not an RPi, see previous point) and install your own? You're asking all the questions after all.

5) Answered in point 3.


How does inner key generation work? As far as I know electrum-words generate private spend key.
private view key is Keccak_256(private spend key). So how is it possible that if I calculate library function Keccak_256 (Crypto++) on my private spend key, I get something different then my actual private view key?

There's an additional step performed, called "normalization". It's just a modulo operation with l. See sc_reduce32 ... is it really supposed to be that complicated?

Oh and note that mnemonic is decoded to seed and then:

spendkey = sc_reduce(seed)

viewkey = sc_reduce(keccak(spendkey))

New versions of wallets roll a random 256bits, normalize it and use that as seed so the below holds true:

seed == sc_reduce(seed)

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


Transfers from 3 days ago still "locked" in Monero GUI wallet Two 100 XMR transfers from Poloniex to my Monero GUI wallet (Windows 64) were still locked after 2 days, and rebooting. Day 3, still locked, I shut it down, turned it on again, and now unlocked. Any thoughts?

eg, Tx ID: 9b9cb99c0359ab267bb253505d358f13b57c0600c9903cf490af581ddbc497c6

Normally, transfers are locked for 10 blocks. If yours were still locked, it means either node node was failing to sync to the chain, or the wallet failed to refresh from the node. You'd see that if the wallet was claiming the same height for a few days, though I'm not sure if it displays that promoinently.

Of course, it could also be a bug in the GUI or the monero code it uses. You may want to check the logs for the daemon (~/.bitmonero/bitmonero.log) and the GUI wallet (on the console, I'm not sure it logs to a file, but check for a monero-wallet-gui.log wherever the binary is) for errors or suspicious messages which may give a lead.


What will Enable monero to scale where Bitcoin failed? Bitcoin is failing below its own success and the inability of the core team to make it scales.

What are the main  resources explaining what differentiate Monero from bit coin regarding scalability of the network?

Monero will scale where bitcoin failed because Monero is hardcoded to scale to the network infrastructure (a real variable), whereas Bitcoin is hardcoded to scale to a decision made by humans (the 1 MB block cap).


Why are the last 4 trxs in the mempool stuck? They have been there for days and do not clear. All the newer trxs seem to jump over them. Their size and fees paid are no greater than other trxs that are getting confirmed immediately. So I was wondering why they got stuck so I can avoid making the same mistake.

From what I have heard those tx's were created with the 0.10.0 wallet and therefore used the deprecated ASNL signatures. After the ringCT hardfork the 0.10.1 software is a minimum requirement. Tx's created with older versions will not be included in blocks.


Generating wallet from private key I see that there is a flag --generate-from-keys for monero-wallet-cli that requires an argument, so I tried the hexadecimal seed, which was the same as the private key I generated here https://xmr.llcoins.net/addresstests.html. (Maybe the argument is for the file name, but that is not clear from the --help documentation.)

After I enter the seed though, I am prompted monero-wallet-cli to provide other information, like the standard address, then the spend key, and then the view key! I thought that the hexadecimal key should be just as good as the mnemonic seed to recover all that information. Am I mistaken? And is there a way to do that in monero-wallet-cli at all?

Also, I wanted to test various things in testnet, but couldn't find an equivalent web page for generating addresses in testnet... Does anyone know one? EDIT: That is already implemented in the website provided above. Just use the toggle on the upper left corner to change Standard XMR --> XMR Testnet.

The generate from keys switch requires the private spend key, view key, and public address in order to recreate the wallet. The first piece of info it requested was probably a filename to save to, not the seed. It is what you use when you have all the raw information, but not the seed.

It you want to restore from seed, you need to use the

--restore-deterministic-wallet

switch.


With RingCT on, can I lower mixin safely to save on tx fees? Now that RingCT is on and transactions are many times bigger, would a mixin of 1, for example, be safe enough to keep a good level of privacy? I'm mainly asking because many pool operators have decided to opt out of RingCT (and usually have a mixin of 3). Some of them are loosing money on each block found.

Lowering mixin lowers tx fees, so I'm trying to know if it's a better solution than opting out of RingCT. Thanks!

As in my comment:

  The transaction size is mainly determined by the number of outputs. The number of inputs and mixin have smaller impact on the tx size. To be more precise, each output comes with a range proof using Borromean ring signature containing 64 pubkeys (representing commitments of all digits) and 2*64+1 scalars. This amounts to 193 instances of 32byte data, i.e. 6kB per output.

Smaller mixin won't help in reducing the signature size. For example, see these two transactions with mixin 6 and 2, respectively:

ae199fd5a6869be3d3b0de5334bba3d33c8579ffaae8ce8add3b05fa82a84b0c
ba734dcdb78a98c1fb369252c5dd3ce388cedd1bf1c432d5a70705de8fbc992d

The fees are exactly the same.

Also note that the protocol required minimum mixin is 2; mixin 1 is not allowed.


Where are the signatures of a ring coming from? In a Monero transaction, according to explanation videos:

  The non-signers are past transaction outputs pulled from the blockchain, which act as decoys. These outputs together make the inputs of a transaction.

To make a transaction (like Bitcoin), you need to sign all inputs, to prove that you can spend them. Not a big deal. All input addresses have a public and private key, and you must prove that you have the private key of all inputs to spend them (you are the owner of all the coins being sent). So, you sign the transaction with all the input private keys.

But, in Monero, my understanding is that inputs are made from other past outputs. These outputs are unsigned (have not been spent), so, you do not own the private key of those outputs. And if they are spent, the signature would not be valid because the transaction is using other users outputs.

So, my question is:

Where are the signatures of a ring coming from? You don't own the private keys of the outputs pulled from the blockchain, and therefore, you can't sign the new transaction.

A ring-signature is a group of output keys signed using one of the outputs private keys. An observer can verify that one of the outputs was the real signer, but importantly not which one. A key image is also bundled with the transaction. This is used to ensure an output is not spent more than once.

A little more detail on key images can be found in this answer.


Why do I have to export the private view key every time I use my Ledger? I currently use the Monero GUI v0.13.0.4 with my Ledger Nano S and I'm confused by a few things:

What is saved in the .keys file generated when I create my wallet using the Ledger?

I would assume that the private view key is what's saved, but then why am I asked to export the private view key (using the Ledger) every time I open the GUI?

The Ledger wallet device does not have the ability to scan the entire blockchain, as it's small and limited in computation and memory. Instead, it authorizes the computer/smartphone it's connected to to act as a proxy and process the blockchain and send the relevant information on new transactions to the device. Without the view key the proxy would not know which transactions to send to the device and so the device will just assume that it never has any transaction history at all, and thus no value.

An air-gaped computer with a downloaded copy of the blockchain would work more securely, but at the cost of being non-transportable, and thus unusable. Ledger allows for a compromise of this security while retaining usability.

Everything has a trade-off.

Edit: Upon reviewing the linked document, I've learned that the exposure of the view key is optional. You can have the improved privacy but at the cost of taking more time to synchronize your balance. (The device is rather short on computation and memory so I suspect that this would take a significant amount of time. I don't have the specifics at hand and so will only leave this as suspicion.)

So I think the device is likely a good option in that you have selective security models available and can choose between the trade-offs.