Upon running monerod, I get two errors "cryptonote_protocol_handler.h:94 Unkonown command:1007" and "net_node.h:150 Unkonown command:1007" I have never seen these errors. Is it safe to use cli-wallet to transfer funds? Should I be concerned? Using Monero 'Wolfram Warptangent' (v0.10.0.0-release) and macOS Sierra 10.12 (16A323).

Someone is running a node that supports fluffy blocks and running on mainnet. In handshake, it's sending a request to find out if you support fluffy blocks, but current release nodes don't know about that command.

https://github.com/monero-project/monero/pull/1263


How to restore a wallet on the Monero GUI using the Monero GUI app, am I able to restore a wallet that I didn't create on the Monero GUI app? For example, can I restore a wallet that i made on mymonero.com onto the Monero GUI?

I'm getting at a larger question: if my computer crashes and was not backed up, will I no longer be able to access any wallet that I had saved on the Monero GUI app (even if i have the public key, private key, mneumonic seed, etc.)?

Thanks

You just need to back up your mnemonic seed and you can restore your wallet through the Monero GUI or Monero CLI using any computer anytime.

However, if you are using a 13-word seed from mymonero you can use the following guide to restore it to the GUI since the GUI does not accept a 13 word seed. How do I use my MyMonero wallet via the Monero Core GUI?

Just an additional information: You can use the 25 mnemonic seed as login in mymonero but you have to pay 1XMR to synchronize your past transactions.

Edit:

Monero GUI Beta 2 was just released. So it is easier to restore your wallet using the keys.

Download Monero GUI Beta 2
https://getmonero.org/2017/03/29/monero-gui-beta-2-released.html


Colored Coins on Monero As a followup to this question, I'm curious as to whether an OMNI/Mastercoin-like colored coin protocol could be used on top of Monero, in a private manner. Colored coins are fundamentally different from a Counterparty-style system, (which sits on top of the protocol), while colored coins are literally the tokens transferred on the platform.

My first instinct was to think that this was impossible (as it breaks fungibility), but thinking about it further, I imagine (with an infinite-size TX_Extra) you could provide a chain of proofs signed off on by all prior owners of the colored coin, decryptable only by the receiver - but questions of how to prevent double spends, and the case of what happens if the coin is transferred without the provided proof, are still unresolved in my mind.

Based on Nate's understanding of Cryptonote's ring signature implementation: No, it cannot be used with colored coins:

With Bitcoin, there is a one-to-one correspondence between inputs and outputs of transactions. Suppose there is a transaction X with an output X1 that sends 1 satoshi to Alice's address A, and everyone agrees that output X1 is coloured so that it grants title to Alice's 1977 Chevy Nova. If Alice decides to give the car to Bob, she creates a new transaction Y, with an input pointing to X1, and whose sole output Y1 sends 1 satoshi to Bob's address B. Now Bob can prove, by creating a signature corresponding to his address B, that he is the rightful owner of the car. If Mallory tries to claim the car by creating a different transaction with input X1, he will be found out, because he can't sign that transaction with Alice's private key, so it won't verify. If Alice tries to give the car to someone else by creating a second properly signed transaction Z with input X1, it will be detected as a double spend because another transaction spending X1 precedes it in the block chain.
With ring signatures, this correspondence is broken. When creating a transaction, in addition to the one output (of a previous transaction) that you really want to spend, you can list many others. You create a signature that proves that you are authorized to spend one of the outputs you listed, but doesn't give any information about which one it was. However, a linking algorithm ensures that any future attempt to spend that output again will be noticed and rejected.
In the above scenario, if Alice uses a ring signature on her transaction Y, including not only X1 but another output Z1, then her signature will not prove that she is entitled to spend X1 (and therefore is the rightful owner of the car and can give it away); it only proves that she is entitled to either X1 or Z1.
Furthermore, Mallory could create a transaction M that includes X1 and another output K1 that he is entitled to spend. Since he has the private key corresponding to K1, he can properly sign the transaction M, but it won't be clear whether it is spending X1 (which would convey title to the car) or K1 (which won't).
Now, ring signatures are an optional feature in Cryptonote. If you want, you can create a transaction with only a single input, which will make it unambiguous which previous output you are spending. To avoid confusion such as Mallory's transaction above, a coloured coin protocol for Cryptonote would probably specify that to convey title, you have to use a transaction with a single input; then Mallory's multiple-input transaction above would still be a legal Cryptonote transaction, but the community would agree it doesn't grant him title to the car.
In short, the whole point of coloured coins is to create an unbroken chain of transactions that traces the title of the car, and the whole point of ring signatures is to avoid creating such a chain. So if you want coloured coins, you have to avoid using ring signatures in this way.


How do I start the monerod daemon as a remote node with a username and password requirement to connect to it? I'd like to restrict my remote node so that only certain people can connect to it when they'd like to sync their wallet. How can I set up a username and password with my monerod daemon, so that people can't connect without the correct credentials?

When starting your node monerod daemon, use the following start-up flag:

--rpc-login username:password

Answer supplied by @glv


Using the wallet RPC method create_wallet, how do we find our wallet address? Using the method create_wallet, gives a blank result json object (result:{}), so how do we get the newly created wallet address and related key for it?

If the response from a call to create_wallet has an empty result object, no error object and has HTTP status code of 200, the wallet has been successfully created and opened.

You can then simply call the wallet RPC method get_address to obtain the wallet address.


What is the XMR Withdrawal field for when there is another address field on top for Binance? On the binance withdraw website, there is an xmr address field and then below it there is another xmr withdrawal field. What is that field for?

This really is kind of misleading at Binance and i think they do it on purpose.

The field XMR Withdrawal Address is the wallet. The field XMR Withdrawal is the payment ID.

If you want to transfer XMR to your own wallet, you don't need to enter anything into the XMR Withdrawal field aka payment ID. But if you want to transfer XMR to a wallet at an exchange, then you often need to add a payment ID that you get together with your wallet address from the exchange you want to transfer XMR to.

Now the interesting part: If you don't get a payment ID along with the wallet address from an exchange, then most of the time you got an integrated wallet. An integrated wallet is a wallet that already includes the payment ID inside of the wallet address string.

So if you don't get any payment ID, don't worry, just enter the integrated wallet address into field XMR Withdrawal Address, check the No checkbox to indicate that you don't want to add a separate payment ID and hit the button!

I had the same problem while transferring XMR from Binance to Kraken. Worked flawlessly the way i described it.

If you want to know more about integrated wallet addresses, take a look here


Transfer monero to another subaddress you control without copying the address itself Is there a way to transfer your monero in your own wallet to another subaddress you control? I mainly use the monero cli transfer command. Is there a way to reference your own internal subaddress by the index number?

transfer 100 < subaddress_2 >

It sounds like you're asking this question because you think that because XMR was sent to a subaddress that the XMR is sitting "in" that subaddress.

My understanding of subaddresses is that they exist solely for the purpose of classifying deposits when they arrive.  They are not intended to act like separate wallets (or like separate bank accounts).

An important point is that the wallet is going to strategically choose which outputs to spend to minimize transaction linkability, so making on-chain transfers from subaddress to subaddress is probably unwise.

I know I didn't answer the question directly, but I'm not sure it should be.


Why are rich lists impossible to create for Monero? What technical challenges prevent the creation of Monero rich lists?

Without a rich list or transparent blockchain how can a business or charity publish proof of XMR reserves?

Using a combination of ring signatures (collections of cryptographic signatures with at least one real participant in each group) and stealth addresses (requiring the sender to create one-time addresses for every transaction they make), Monero effectively obfuscates transactions and account balances on the blockchain thus eliminating any possibility of "rich lists".

RingCT, which is currently under active development, will add further layers of anonymity to Monero transactions.  Here is a link to the RingCT whitepaper: https://eprint.iacr.org/2015/1098.pdf

To respond to your second question, Monero's viewkey (a private key that shows all incoming account transactions) allows for optional transparency, thus allowing organizations to publish proof of their XMR holdings (but not grant spend access since the viewkey is more of a "look, but don't touch" tool).

In this sense, Monero is private by default due to its ring signatures and stealth addresses, and it is optionally transparent by way of the viewkey.


What is a stealth address? Canonical question on stealth addresses: They are mentioned in the context of privacy of Bitcoin transactions but are also implemented in Cryptonote based currencies. What are they and how would they work? Can they provide 100% anonymity?

Stealth addresses take care of the receiver's privacy, not the sender's.

In cryptocurrency, the ability to spend a certain amount of coins is the same as the knowledge of the private key to the public key associated with the coins.

So (simplifying a bit), in Bitcoin if there is 1 bitcoin associated to the public key P and if Bob knows the corresponding private key x such that P = xG, then he can spend the Bitcoin by submitting a message (transaction) to the network signed with x.

There is one privacy issue, though: if Bob keeps using the same P to receive bitcoins, then any observer will be able to see all payments were made to the same entity that controls P (Bob). This is the problem that stealth addresses solve.

In the context of stealth addresses, addresses are now composed of two public keys, and the coins sent to Bob will not be sent to his stealth address on the blockchain, rather the stealth address will be used by the sender to produce fresh new bitcoin addresses for every new transaction. These new addresses, even though generated by the sender (Alice) and unknown to Bob until the transaction is made, will nonetheless be controlled by Bob! Here is how it works:

Bob creates two pairs of private and public keys. Let's denote them by (a,A) and (b,B), where by definition A = aG and B = bG. Bob makes the pair of public keys (A,B) available to the network; this will be his stealth address.

Alice wishes to send 1 bitcoin to Bob; that is, she wants to assign 1 bitcoin to a public key P such that Bob knows x and P = xG. She will construct such P using Bob's stealth address by using a hashing function H, choosing a random big number r, and setting P = H(rA)G + B. Then Alice sends the bitcoin to P, the transaction is broadcast along with R = rG (but not r, which can't be recovered from R).

Now how does Bob get the money? Well he has to keep listening on the network for all new transactions in the hopes that they are for him. When he sees Alice's transaction, he performs x := H(aR)+b and realizes that:

xG = (H(aR)+b)G = H(aR)G+bG = H(arG)G+B = H(raG)G+B = H(rA)G+B = P,

that is, Bob can reconstruct x such that P = xG and is therefore the owner of the bitcoin! Notice that neither Alice nor any observer has the ability to derive x (because they don't know a and b), and that besides Alice and Bob no one knows that (x,P) was generated from Bob's stealth address (because they don't know r).

Note that, as mentioned, this protects Bob privacy, but it is still visible to the network that Alice, the entity that used to control that bitcoin, made a transaction. In order to obfuscate that action, Monero implements the use of Ring Signatures, which will allow Alice to, instead of directly signing the transaction, produce a proof that her, or several other people, did send a coin to Bob. The math behind Ring Signatures is not as simple as in Stealth Addresses, but it is still very approachable.

So, in a nutshell:

Stealth addresses take care of recipient's privacy.

Ring Signatures take care of sender's privacy.


How to check a detached daemon without a wallet? I have set a Monero node as a service on a virtual machine with --detach option to run it in the background. I can check the service status through Linux command or connect to the node with a wallet.

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

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

You can also use the daemons RPC get_info.

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

A node does not have a wallet attached to it.


How does the Coin Selection work in Monero? I'm interested in improving Coin Selection for Bitcoin, and I saw that the wallet implementation has significantly changed in Monero compared to Bitcoin. I was wondering whether the Coin Selection algorithm has also been changed.

When creating a transaction in Bitmonero, what is the algorithm used to determine which unspent outputs will be used as inputs?

Does the client consider the resulting transaction size, transaction fees, and global UTXO Set growth in its selection?

Does the client make any attempt to optimize which 'coins' are used based on minimizing the transaction size, the resulting fragmentation, or the 'age' of the coins (value/transactions) used as the source?

The coin selection in Monero is very simple and naive, so I'm afraid you're not going to find much to take inspiration from.

Currently, the selection is random, with an equiprobable distribution.

There is a patch that will be merged along with RingCT (https://github.com/moneromooo-monero/bitmonero/commit/90fb5e411307a949779c65a1931f3462ee3a564d) which improves this, but only to avoid correlation attacks on the inputs.

As such, there is no attempt made to favor small fees, or transaction size, or number of outputs.

Fees are per kB in Monero, so small fees and transaction size are the same metric (down to quantization at 1 kB). Once Ring CT is merged, each transaction will typically have two outputs, growing the TXO set by the same amount. The vast majority of outputs on the blockchain are not known to be spent/unspent, due to the use of ring signatures (but this does not hold for dust, which is typically consolidated at mixin 0), therefore using up many inputs does not actually decrease the TXO set (and this is why it's a TXO set and not a UTXO set).

Additionally, and I add this since you're using "changed [...] compared to Bitcoin" wording: Monero is not a Bitcoin clone. It is a Bytecoin clone. So the algorithm hasn't really changed, it's just a new one. Not sure if you know this or not, but I thought it worth a mention.


Can view keys differentiate between payments and change? Considering they track incoming payments as well as change, how do they know which one is which? If an organization wants to audit my account, and I've been sending a large number of transfers, won't they see a bunch of incoming transactions that are really just the change of the money I sent?

And will any of this change with RingCT?

If you think about it, change comes back in the same transaction as the money you sent. If you receive X monero as change, you will have sent Y monero in the same transaction, with Y > X.

The answer to your question boils down to the key images. You give a signed set of key images to the auditor, who can now see money going in and out.

See How to prove my Monero balance to a world? for the procedure.

Nothing about this will change with RingCT.


How can I increase the database cache size? I'm running a full node on Windows and have plenty of RAM, is there a switch I can use to allocate a larger cache size? (Similar to -dbcache=X in Bitcoin/Litecoin core)

The Monero synchronization process was almost an order of magnitude faster (according to logs) when I put the database into a RAM drive (ImDisk) versus on the hard disk drive, but as the database grows in size this approach may not always be possible.

No.

If you mean disk cache, assuming your OS isn't too dire, it should cache what's needed, and take it back when needed.

If you mean another type of cache, then the answer is still no, but with no extra comment :)


Need a payment ID - using Monero GUI 0.12 The exchange that I'm attempting to transfer Monero out of requires a Payment ID.
But Monero GUI 0.12 doesn't have Payment ID's anymore.

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

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

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


Which directory does monero-blockchain-import, by default, use to store the imported blockchain? I am not sure if this makes sense or not.  I was using an old version of the Monero GUI and I was stuck at block 140001.  I thought it was a sycning problem so I downloaded the raw blockchain from getmonero.  Then I followed these instructions

When I followed those instructions, my terminal gave me an error (after loading most of the blockchain) that there wasn't enough space to load the block chain on my computer. I check my HD and I had 9GB left.  I started with 32GB.   My GUI program was on my 32GB HD and the blockchain was located on a 2TB HD.

So now that I've updated my GUI to the newest version, it's syncing fine, but I still only have 9GB left on my Mac HD.  Where do delete the files that were created during the failed bootstrapping?

Thanks for any help

This question basically pertains to where monero-blockchain-import stores the imported blockchain by default. monero-blockchain-import uses the following default directories to store the imported blockchain:

Windows:

C:\ProgramData\bitmonero\lmdb

Linux and Mac OS X:

~/.bitmonero/lmdb

Note that, by default, both C:\ProgramData\bitmonero\lmdb and ~/.bitmonero/lmdb are hidden directories. On Windows, you have to use the explorer to manually navigate to aforementioned directory. On Mac OS X, you can typically use cmd+shift+. to unhide directories. On Linux, you can typically use ctrl+H to unhide directories.

  Where do delete the files that were created during the failed bootstrapping?

Thus, to delete redundant data, you should delete aforementioned directory.

monero-blockchain-import also allows one to import the blockchain to a custom data directory. This is done as follows:

Windows:

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

Subsequently, type the following command in the command prompt:

monero-blockchain-import.exe --input-file path\to\blockchain.raw --data-dir path\to\preferred\data\directory

If that doesn't work in the Powershell, type:

.\monero-blockchain-import.exe --input-file path\to\blockchain.raw --data-dir path\to\preferred\data\directory

If that doesn't work either in the Powershell, type:

./monero-blockchain-import.exe --input-file path\to\blockchain.raw --data-dir path\to\preferred\data\directory

Linux and Mac OS X:

Open a new terminal from the same directory as monero-blockchain-import.

Sidenote: On Mac OS X, you probably can only open a terminal from the desktop. As a result, you have to use cd to navigate to the directory of monero-blockchain-import first. For example, if monero-blockchain-import is located in ~/Applications/monero-wallet-gui.app/Contents/MacOS you'd have to type cd ~/Applications/monero-wallet-gui.app/Contents/MacOS to ensure the terminal is in the proper directory.

Subsequently, type the following command in the terminal.

./monero-blockchain-import --input-file path/to/blockchain.raw --data-dir path/to/preferred/data/directory

  Where do delete the files that were created during the failed bootstrapping?

Thus, if you used the --data-dir flag, you should delete the directory you specified to delete redundant data.


Multiplication over an elliptic curve using the monero cryptographic libraries I am trying to implement a PoC of some variant of monero.
Currently for start, I want to generate the expression G*a*i^2 given all the scalars (a,i,2).

I've lost my way while looking at Monero libraries since the structs and the names of the functions and their inputs/outputs are not clear and well documented.

Assuming G is the base point and i is a scalar (the convention is to write points in capital letters and scalars in lowercase letters):

  rct::key tmp;
  sc_mul(i.bytes, i.bytes, i.bytes); // i = i^2
  sc_mul(tmp.bytes, a.bytes, i.bytes); // tmp = a * i^2
  rct::scalarmultBase(tmp, tmp); // tmp = a * i^2 * G

The rct API is easier to use than the fe/ge API, but it has a single type for points and scalars, which make it more error prone. sc_mul (scalar multiplication) is the fe API, and scalarmultBase is the rct API.


How do full nodes vs miners secure the network differently? If I run a full node I am supposedly contributing to network security by keeping a copy of the blockchain
If I mine (via pool or solo) I contribute to the network through verification of blocks

How do these two ways of contributing to the network differ? Is there an "ideal mix" in terms of miners to full nodes ratio for a secure network?

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

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

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

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

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

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

A blockchain is a collection of blocks

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

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

A block can have any number of transactions

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

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

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

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


Can't generate new wallet using Ledger Nano S on Mac OS 10.13 I've built the 0.12.1 Monero Core release and tried to create the wallet from my Ledger Nano S on device, but get the following error:

Error: failed to generate new wallet: Fail SCard API : (-2146435069) Invalid handle. Device=0, hCard=0, hContext=1

Things I have done:

Set up the SmartCard service as much as I could from the instructions from Ledger Github instructions. I was able to carry out steps 1 to 3 successfully (the file existed for me to ultimately edit). However, note that I am using Mac OS 10.13 and there is no SmartCard installer for 10.13 from the link supplied in the instructions. The 10.12 installer didn't work. Maybe I don't have SmartCard service installed?
had the Ledger Nano S on Beta 0.12.4 installed.
had the Monero app active on the Ledger Nano S on before trying to create the wallet.

Any ideas?

I have written a more descriptive guide to this part of the system configuration

After some help from IRC (thanks selsta), they discovered it was my user error.

In this part of the instructions supplied by Ledger, I didn't add the 2nd string because it already existed and I didn't think I needed to duplicate it. When I did add it, it worked.

In <key>ifdVendorID</key> add the entry <string>0x2C97</string>
In <key>ifdProductID</key> add the entry <string>0x0001</string>
In <key>ifdFriendlyName</key> add the entry <string>Ledger Token</string>


Code a mining pool from scratch I'm looking for resources to get me started on coding a mining pool from scratch. I know there are several mining pool implementations and it's reinventing the wheel, but I want to do it so I can learn and also it's kinda fun for me. I tried to reverse engineer some source code but I think I'll be better off having some sorta guide instead. What I'm looking for is :

what information is exchanged between pool and miners
Detailed explanation on what this information means
If possible some pseudo code to generate that information

Any help is appreciated because I've been searching for a while and can't seem to find any good sources.

See this answer for the messages used.
The same above linked answer should be self explanatory apart from maybe the job blob, which is a block hashing blob, e.g. the data to hash. This and this should help on that front.
The same above linked answer also has a link to an example bare-bones Python miner using the stratum protocol.


How to get decimal number out of a decrypted ecdhInfo field? I have a known amount encoded in ecdhInfo. I can decrypt ecdhInfo according to this formula:

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

How can I get a decimal value out of this decrypted 64bit field? Or, what type of variable is it after decrypting? I am working in C and want to avoid floats.

It is a 64 bit little endian unsigned integer.

If you're asking "how do I get a human amount out of an atomic unit number", divide by 1e12. cryptonote::print_money in the Monero source does this without using floating point operations (print the number, then manipulate the string).


Monero daemon with --rpc-bind-ip parameter After installation of the new version v0.10.2.1, I have started monerod with the parameter "--rpc-bind-ip 192.168.1.2" and got this error:

"ERROR   default src/rpc/rpc_args.cpp:76 --rpc-bind-ip permits inbound unencrypted external connections. Consider SSH tunnel or SSL proxy instead. Override with --confirm-external-bind"

Could somebody explain this ? Previous version 10.1.0 doesn't show this error.

This error is due to an abundance of caution in preventing the daemon RPC from being accessible from the outside without the user really understanding the consequences.

Here, if you really intend the RPC to be accessible from other machines, you can just add --confirm-external-bind to your command line, as the message says. Adding this option serves as a confirmation from the user that they really underand that (unencrypted) external access will be enabled.

Alternatively, if you know how set up an SSH tunnel, you could do that instead, which would allow listening only on 127.0.0.1, while allowing tunneled access to the external machine you want to use it from, with the advantage of encryption and authentication (and I don't know how to do that offhand, but looking for ssh tunnel on duckduckgo should give good pointers).


Danger of using a very long unlock time The answer to this question says transactions with an unlock_time are mined right away but outputs will not be able to be used as inputs in another transaction until the unlock_time is met.

Based on the above would there be any danger in sending (or receiving) a transaction now with a 2 year unlock_time? Assume that planned hard forks continue every 6 months and that RingCT transactions are mandatory long before the 2 year unlock_time is reached.

There is no danger. The answer you quoted states that the transaction would be mined and confirmed like any other transaction. The sender can prove this with the same methods (payment IDs, etc) as any other transaction
The recipient would have the exact same ability to spend outputs from a 2 year unlock_time transaction as a recipient of a non unlock_time transaction today that left the received coins in cold storage for two years.
Just like no hardfork will harm the ability of anyone to spend coins stored in cold storage during multiple forks, no hardfork will harm the ability to spend funds from an unlock_time transaction once the unlock_time requirement has passed.
Measures will be taken to ensure there will always be a way spend funds in your wallet:

When someone uses a rct transaction, the outputs are necessarily rct.
From hard fork 5 (expected in or around september 2017), non rct transasctions will be permitted only if they are spending unmixable outputs (ie, the rules for allowing mixin 0 now).
If you want to make all your outputs rct, you should be able to use sweep_unmixable first, then sweep_all. Assuming you do not have a large amount of tiny inputs, that should make your whole balance only in rct outputs.


Regular expression to reduce mnemonic to first 3 letters only Since only the first 3 characters for the English-language mnemonic matter, I prefer to reduce the words to just the first 3 letters only, for cold storage purposes. I would like to do this with a regular expression, to avoid manual errors.

What would be the shortest regular expression to do this? Note that I want a newline at the end. I will post my current solution, looking forward to see a shorter one.

What I currently have:

echo $(echo "${MNEMONIC}" | tr " " "\n" | sed 's/^\(...\).*$/\1/' | tr "\n" " ")


monero-stratum Error When Compiling Hi I seem to be getting an error during compiling of monero-stratum.

[ 60%] Linking CXX shared library libcnutil.so
[ 60%] Built target cnutil
Scanning dependencies of target hashing
[ 60%] Building C object hashing/CMakeFiles/hashing.dir/src/hashing.c.o
/home/miner/monero-stratum/hashing/src/hashing.c: In function
‘cryptonight_hash’:
/home/miner/monero-stratum/hashing/src/hashing.c:5:5: error: too many arguments to function ‘cn_slow_hash’
 cn_slow_hash(input, len, output, variant, 0);
 ^
In file included from /home/miner/monero-stratum/hashing/src/hashing.c:1:0:
/home/miner/monero/src/crypto/hash-ops.h:82:6: note: declared here
void cn_slow_hash(const void *data, size_t length, char *hash);
  ^
hashing/CMakeFiles/hashing.dir/build.make:62: recipe for target
'hashing/CMakeFiles/hashing.dir/src/hashing.c.o' failed
make[2]: *** [hashing/CMakeFiles/hashing.dir/src/hashing.c.o] Error 1
CMakeFiles/Makefile2:123: recipe for target 'hashing/CMakeFiles/hashing.dir/all' failed
make[1]: *** [hashing/CMakeFiles/hashing.dir/all] Error 2
Makefile:83: recipe for target 'all' failed

I followed the Ubuntu 16.04 directions.

Perhaps the recent update to the Monero Daemon caused this.

Please Help.

install latest go from https://golang.org/dl/

create home/go/scr Add /usr/local/go/bin to the PATH environment variable. You can do this by adding this line to your /etc/profile (for a system-wide installation) or $HOME/.profile:

export PATH=$PATH:/usr/local/go/bin

create home/go/scr

follow https://github.com/sammy007/monero-stratum until error then

edit monero-stratum/hashing/src/hashing.c to looklike this

#include "crypto/hash-ops.h"

void cryptonight_hash(const char* input, char* output, uint32_t len) {
    const int variant = input[0] >= 7 ? input[0] - 6 : 0;
    cn_slow_hash(input, len, output);
}

void cryptonight_fast_hash(const char* input, char* output, uint32_t len) {
    cn_fast_hash(input, len, output);
}

then

cmake .

then

make


Why is there no P2Pool for miners? Is there no interest in having a p2pool? I think it would be pretty cool to have something like this.

Why is there no P2Pool for miners?

Because no one has developed it yet.

Additionally, a 2 minute block time is very difficult to work with for a p2pool system. AFAIK, the p2pool system works because there are 30 second blocks in the p2ool sharechain, while there are 10 minute blocks in the bitcoin main chain. So, every 30 seconds there is an agreement amongst all the miners in the "pool" regarding how much work everyone has done.

So essentially, in monero, if the same p2pool architecture is used, there would need to be a secondary chain that is capable of reaching consensus in between the time when the real Monero chain reaches consensus.


When receiving funds, does the recipient know the address of the sender? When someone sends funds he knows the address of the recipient. Is it the same for the one receiving the transaction?

No. Ring signatures provide sender privacy, stealth addresses provide receiver privacy and Confidential Transactions hide the amount being sent. Nobody's wallet address appears on-chain.


How to ask a running monerod instance for mining hashrate when restricted-rpc is enabled? I'm running monerod as service, mining with 3 threads. How can I get the hashrate info?

monerod status fails to connect:

$ monerod status
Error: Couldn't connect to daemon: 127.0.0.1:18081
Height: 1480810/1480810 (100.0%) on mainnet, mining info unavailable, net hash 644.80 MH/s, v6, up to date, 9(out)+36(in) connections, uptime 1d 1h 47m 55s
$ netstat -nap | grep 18081
tcp        0      0 0.0.0.0:18081           0.0.0.0:*               LISTEN      -

The port is open (telnet 127.0.0.1 18081 connects properly).

edit: I noticed the restricted-rpc option blocks mining info from being accessed. The node is public and I need to keep that option. So, the question is how can I check hashrate in such setup?

You probably started monerod with --restricted-rpc. This will deny access to the mining information, as it is private (ie, none of any third party's business).

You can now start a daemon with two RPC ports, one with restricted RPC (presumably exposed to the internet) and one not. See this in monerod --help:

  --rpc-bind-port arg (=18081)          Port for RPC server
  --rpc-restricted-bind-port arg        Port for restricted RPC server

Another way is to ask the JSON RPC directly:

curl -v -X POST http://127.0.0.1:18081/mining_status -d '{}' -H 'Content-Type: application/json'

You then get the hash rate in the speed field.


What is the reserve_size parameter in getblocktemplate? The getblocktemplate RPC method accepts a parameter, reserve_size. What does it do and what are its valid values?

The reserve_size is the amount of data to reserve in the block template for the extra nonce (arbitrary data which may be embedded in a transaction). The maximum amount is 255 bytes. This is used by the pool code to place a nonce which will be incremented to try to find a block hash below the current difficulty target.


How to create and sign a monero transaction by hand As the title states... what I mean is what does the json/rpc command look like and can someone give an example and explain it? I would like to use RPC to get blockchain information, then manually construct a transaction and sign it from that returned information. I understand this would involve a lot of work

Thanks in advance.

The wallet RPC has a method transfer which you can call with parameters do_not_relay:true and get_tx_metadata:true which will allow you to create a transaction but not relay to the network immediately. When you are ready to send, you can call the method relay_tx.


Can you reverse a payment without receiving a public key from the original sender? So lets say Alice sends XMR to Bob and maybe even uses a payment ID so that Bob knows that it was Alice. Can Bob send Alice XMR in the future with only the information in the original transaction or does Bob need to get Alices public key?

There is no way for Bob to know which of the one-time public keys was actually spent, which isn't even relevant.  Even if there were a way to know which public key she spent, he still wouldn't know the address that controls the spent key; so, no, he would have to ask Alice for her address (public key).


Question about incoming/outgoing merging of transaction identity I have a few more questions about sub-addresses, sorry to bother you guys with it, but it's just a bit new to me to get used to the new features.

People said that "accounts" are just user selected groupings of addresses, and have also said that there is no link between individual addresses without any common transactions first.

Now I have a question about 2 possible scenarios:
1) Incoming merger

Suppose you put A,B,C,D in account 1, which represents 1 contextual identity. I assume there is no link here between a secondary account that has no common transactions with it. Althought people have pointed out that there can be linkage between A,B,C,D if we repeatedly receive from the same trading partner multiple transactions on A or B. Obviously if we give them both A,B on the same IP address ,that already links the two, but from what I understood, even if they don't know that A,B are owned by the same person, by repeatedly receiving money to both addresses from the same person, can decode the missing puzzle pieces and see that the 2 accounts are correlated.
2) Outgoing merger

Now suppose there is a 2nd account also owned by the same person, but represending a different contetual identity with addresses E,F,G,H.

Now if we sweep all balances from account 1 and account 2, would that link the 2 accounts together?

What about sweeping just account 1, would that link A,B,C,D together?

( this question was copied from a reddit q&a)

Accounts are groupings of subaddresses for presentation purposes. There is also the side effect that when you spend out of an account, any outputs received at any subaddresses within that account may be combined. This is purely wallet logic.

Funds cannot usually be spent across subaddresses which span multiple accounts because of wallet logic. The wallet requires you transfer funds between accounts (which automatically gives you one level of churn if you do so).

Note that neither subaddresses nor accounts ever appear on the blockchain, because outputs simply appear to have random one-time public keys. You only need to worry about linkage if the same person (or colluding parties) gave outputs to you via many of those subaddresses, and are now observing the blockchain to see if those outputs are ever referenced together in a transaction. Third parties cannot make sense of anything.

Any kind of combination of outputs across subaddresses (whether from the same account or different accounts) will risk linking those subaddresses together, only in the eyes of someone that knows about outputs given to you at those particular subaddresses. There is no such thing as linking accounts together, only linking particular subaddresses together.

So the bottom line is, if you spend outputs together in the same transaction, and those outputs spanned several subaddresses, then those subaddresses are at risk of being linked regardless of whether those subaddresses were all from the same account or from multiple accounts. And again, the risk is only there if someone knows of outputs sent to each of those subaddresses, because only one-time output public keys are written into the blockchain, and addresses/subaddresses are never written into the blockchain.

Finally, if there is no prior suspicion that subaddresses may be linked, then someone is going to have to send multiple outputs per subaddress to you on multiple occasions in order to know whether they're observing random references to outputs or a real pattern. This greatly reduces the threat.

Think of it like this: every time there is a transaction, fresh notes with fresh random serial numbers are given to the recipient. Any time someone spends notes in a transaction, the whole world (via the blockchain) is told about the new random serial numbers generated, as well as the serial numbers of notes that are spent together in that transaction. In addition to the serial numbers of the actual notes being spent, the transaction also includes the serial numbers of lots of other notes that are randomly chosen from the blockchain as decoys. This means no one can be sure which notes are really being spent, but coincidences can be spotted under very particular circumstances by people that gave out particular notes to a particular person whose real identity they know. That's pretty much all the knowledge you need to be able to directly reason about the threat involved.

( answer originally provided by knaccc )


What advantages does Monero offer that are not provided by other cryptocurrencies? What are the advantages provided by using Monero compared with other popular cryptocurrencies such as Bitcoin?

Specifically, what unique features does Monero have relating to privacy, PoW security and scalability that is not provided by other leading cryptocurrencies?

It is the only private cryptocurrency in use today which is truly fungible as all transactions are private and created equal.

It satisfies the 3 important properties of electronic cash: decentralized, private, digital.

These are the major features that distinguish it from all the rest, on a protocol level:

Nobody inspecting the blockchain can tell from where the funds came (untraceability). This even includes the recipient (you). Just by opening your wallet, even you don't know from where your funds came, unless you provided the sender with a paymentID unique to the transaction, or you kept track yourself by some other means (ie if you send from an exchange you can match a transaction just from the timestamp, unless you receive a lot of transactions regularly). This is achieved by utilizing one-time ring signatures. While commonly referred to as "mixing outputs", it works a bit different than what the name suggest. When spending, the sender can pick any random output to use as decoys which hide the real one getting spent. This takes care of the sender's privacy.
Nobody inspecting the blockchain can tell to where the funds went (unlinkability). This even includes the sender (you). Just by opening your wallet, even you don't know to where you sent some funds in the past, unless you (or your wallet) kept track locally. This is achieved by utilizing stealth addresses, where the sender generates a one-time destination from the recipient's address. As opposed to Bitcoin, no monero are actually sent to the address itself, but are sent to something derived from it (the one-time destination). All one-time destinations look the same and this takes care of the recipient's privacy. The owner of an address is the only one able to know which one-time destinations "belong" to him, by means of a private view key.
Since introducion of ring confidential transactions (RCT), amounts involved in transactions are hidden. Nobody inspecting the blockchain, except the sender and the recipient, is able to tell the amounts involved in RCT transactions. Amounts of mined monero are still seen so the total supply can be verified, but they are hidden once a first RCT transaction uses them as input. It is still possible to use old pre-RCT transactions, and starting September 2017 RCT transactions will become the only kind possible.
Dynamic blocksize and tail emission. I'm putting the 2 together because the latter is needed for the former to work. Miners are free to increase the blocksize, but: if they will increase it for too much too fast, they will lose the coinbase reward (but they will get more transaction fees). The tail emission (of a fixed 0.6 Monero per 2-minute block) is there to ensure there is always something you can take away as a penalty. This will result in some residual inflation of <0.87% which will reduce each block towards 0% as time goes on. This has the added benefit of compensating for "lost" coins forever (someone dies, loses the wallet etc.) and providing a minimum incentive to maintain security of the network by mining. Also note that it has a smooth emission curve, avoiding shocks like "The Halving".
It's auditable. By giving your private view key to an auditor, he would be able to see all the your incoming transactions. However, to know the correct balance he would also need to know if you spent any of those (which he can't just with the view key). For this, you'd have to compute a key image for your every incoming transaction, and send those to the auditor. With this, the auditor could establish your current balance. Nice part is, that if you receive something new, the auditor can't know if you spent this new output without kindly asking for the matching key image. This gives the user certain control over how he's being audited and who can know what.
Dynamic fees. The fees are dynamically adjusted to scale with the network. As the network grows and block sizes expand to take in more transactions, the fees are designed to decrease. Combined with dynamic block sizes, the objective is to create a situation where both miners and users are rewarded for increasing capacity of the network: miners get more total fees and users get cheaper fees.

Other things that are worth highlighting are:

A healthy, mature community and dev. team working towards a common goal of transacting freely.
Scheduled hard forks. At the current schedule, every 6 months (with the ringCT getting a one-time push for January instead of March). In the future, the frequency will likely be reduced to 12 months as the project grows more mature. Monero already had 3 successful HFs (1st, 2nd, 3rd). As per advice by MRL, the first HF set a minimum requirement on the number of outputs to "mix" with, ensuring privacy of the network. The 2nd one ensured that coinbase transactions amounts are rounded as to prevent "random" non-mixable outputs appearing on the blockchain, and the 3rd one introduced ring confidential transactions.
Separation of the wallet and node software, which makes it a much better foundation to build upon.
Utilization of LMDB for blockchain storage, which is cutting-edge technology with significant performance advantage over anything else, and is used for many other high performance applications.
The cryptography has even been looked at by academics (Monero Research Lab), one of which devised the ring CT scheme. The RCT paper recently got published in the Ledger journal where it was subject to peer-reviewed as well.
CryptoNight PoW, which is an ASIC-resistant algorithm and to this day no known ASICs exist. It's not specific to Monero as there are other CryptoNote currencies out there, but it gives an advantage over some other ones.
(future) Kovri integration. This will enable node communication over I2P (The Invisible Internet Project), further increasing privacy by hiding user's IP addresses. It's worth mentioning even though it's not in production, as it is being heavily worked on and is not just some idea floating in the air.
(future) Implementation of 0MQ protocol for improving the way the node communicates with other processes, which is being actively developed. Currently, RPC is used, which will still be supported for backwards-compatibility. This will be very important as a building block for future development of APIs, payment processors, exchanges etc.


create a coinhive fork I want to create my own coinhive clone. What do I need to start my own service like coinhive?
I know that I need the following:
-blockchain (serverside)
-javascript miner (clientside)
-pool

what else do I need for my coinhive fork and does anyone know a tutorial that explains how to program a miner?

thanks so much

I did exactly this recently. Take a look at:

https://github.com/jtgrassie/xmr-wasm


Can't create transaction: failed to get random outputs to mix: failed to get random outs I'm using monero-wallet-gui (monero-gui-0.10.3.1-beta2). I'm connecting to remote node node.moneroworld.com : 18089

Network Status at bottom shows Connected.

I'm trying to send XMR to Binance exchange.

I tried sending upto 2.4 XMR and transactions are getting created for amounts less than 2.4. But when I enter anything more than 2.5, it gives me the following error: "Can't create transaction: failed to get random outputs to mix: failed to get random outs"

What could be the problem?

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

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

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


What are the chances of discovering a block solo mining with my current hashrate? Just for the fun of it I setup the Gingeropolus pool software on my VPS. I have 5 GTX 1050ti, 2 RX470,1 R9 390x, 1 R9 270, and 3 HD7950s. This is roughly bring me 4kh/s hashing power.

What are my chances of discovering a block at this hashrate and current difficulty?

tl;dr

Solo mining is a lottery unless you have a few dozen GPUs

Explanation

Target block time in Monero is 2 minutes, based on that and your share in the network hashrate you can calculate how frequently you will find blocks.

Let H be the network hashrate, and h be your own hashrate. Then on average you will find a block every

t = 120 / (h / H) = 120 * (H / h) (seconds) = (H / h) / 720 (days)

Now let t and t' be your "substantial enough" target, in seconds and days accordingly. You can find minimum h / H ratio to achieve it, i.e. a proportion of the net hashrate you must own:

h / H = 120 / t = 1 / (720 * t')

If H is known, your minimum hashrate to achieve that is

h = H * 120 / t = H / (720 * t')

Current network hashrate is ~125 MH/s (Jul 19, 2017), so with 4 KH/s you'll have to wait for 43 days on average to find a block, meaning that you can easily have zero payouts during a month or two.

Finally, let's calculate how much hashrate you currently need to get payouts at least once a week on average (bear in mind that H tends to grow over time):

h = 125000 / (720 * 7) = 24.8 KH/s


List of things that were proposed and rejected for bitcoin but implemented in Monero This is a follow-up question based on this answer: https://monero.stackexchange.com/a/12600/

Many things proposed and rejected for Bitcoin have found a place in Monero (privacy for starters). That said, it's worth noting that it was Dandelion, not Dandelion++, that was originally proposed for Bitcoin and there were various objections, most unrelated to possible DoS attack vectors.

What are other things apart from 'Dandelion' that were proposed and rejected for bitcoin but implemented in Monero?

I don't have an exhaustive list to hand for you, but a few things that spring to mind: "one-CPU-one-vote" (Satoshi), Confidential Transactions (Maxwell), privacy (many aspects proposed by many people), Schnorr signatures (although it's looking like this will get implemented at some point) and of course Dandelion.


When constructing a change output, must it be destined for the main public address? I was thinking about how the behavior of spending Monero from the same wallet over time induces the risk of eventually linking change outputs when they are later combined and spent.  Can this be avoided?

It occurred to me that the wallet will prefer to spend from within particular subaddresses (citation could be useful here), so I was thinking that one way to prevent future linking of change outputs would be to address them to various subaddresses.

Back to the title, is it possible for change outputs to be addressed to subaddresses?  Does the functionality exist in the code now? Ignoring the obvious downside where an actively used wallet would quickly have an issue with a plethora of difficult-to-manage subaddresses, is it possible and does the idea have merit?

It's possible to send change to any subaddress/account inside any wallet where you know the private view key and public spend key for that wallet. (If you were not sending to a subaddress destination, then you could send change to any wallet where you only knew the public view and spend keys).

The wallet rule is currently that outputs can be spent together if they are received to any subaddress within the same account. Therefore to achieve what you're talking about, you'd need to send change to a different account within your wallet.

Now, however, you have a new problem. If change outputs from that new account were spent together, you'd have the same kinds of traceability problems.

If churning is deemed effective, the solution is probably to have a 'high privacy' wallet mode, where every change output is kept track of by the wallet, and churned several times before becoming available for spending. You'd not need to bother with sending change to different subaddresses, because the wallet would be easily capable of keeping track of which outputs are change and how many times each change output has been churned.

Alternatively, you could reason that as long as outputs in a particular account are always churned before entering that account, and if that account is only used to spend funds with entities that are not aware of your real-world identity, then it doesn't matter if change outputs are churned. You'd simply have an account for spending with people that know your real identity, and another account for people that don't. This has the benefit of it not being necessary to churn every single change output. You'd only need to churn prior to filling the high-privacy account with funds, and prior to withdrawing funds from that account to an exchange or real-world-identity account.


Is it safe to make backup of wallet? If so, is there a reference procedure somewhere? For example, to prevent problems if my dog eat my usb stick with my wallet, is it safe to make backup of wallet ?

If so, what would be a correct procedure to make (i.e, what are the important part to backup, the ones to write down and lock in a safe, the ones that can be safely erased, etc ?)

You can use any of those methods:

backup the mnemonic seed, a 25 word list of words that encode your private keys. This is the simplest way, and you can then restore your wallet with monero-wallet-cli --restore-deterministic-wallet later. After creating a wallet, you can obtain its seed with the seed command in monero-wallet-cli.
backup the keys file and the password you saved it with.
backup the private spend and view keys. You can then restore your wallet with monero-wallet-cli --restore-from-keys.  After creating a wallet, you can obtain its keys with the spendkey and viewkey commands in monero-wallet-cli.

Note that when you restore a wallet, you lose all information about tx keys (needed if you want to prove payment later), any tx notes you saved in monero-wallet-cli, and extra information on outgoing transactions (such as the destinations addresses).


How to send a raw transaction directly without sanity checks Would be possible to create a transaction without doing sanity checks? In GUI/CLI normally it would check if there are enough monero in the wallet or it has been unlocked. Is there a way to broadcast a transaction without this checks and its up to the peers/miners to double check that your transaction is valid or has enough monero in it.

Look into /sendrawtransaction API call. Dev Guide


Longest block time and standard deviation Monero blocks are on average 2 minutes apart, but how much is the variation?

What is the standard deviation of block times generation time?

Can the above question be modeled as an exponential distribution?

What has been the longest period between two blocks so far?

Yes an an exponential distribution can be used but it will require some assumptions:

No propagation delays of block discoveries
Constant difficulty
Accurate time stamps

With those assumptions and an exponential distribution the standard deviation equal to the expected block time (expectancy value) which is currently 120 seconds (2 minute blocks).

Assumptions #1 and #2 above will never be completely true. Monero Research Labs is now researching Difficulty Adjustment Algorithms in Cryptocurrency Protocols and is considering such factors as dishonestly reporting time stamps.

I am not sure about the longest time between blocks, but here is my best guess which occurred about 28 and a half minutes after this block. This was the time period just following the hard fork that moved Monero from 1 minute to 2 minute blocks.


Making an address transparent to public view What methods are there to make a monero address transparent to be viewable publicly on the blockchain? Say your a non-profit and you want your address viewable publicly, how can this be done?

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

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

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


Kovri modularity and I2P compatibility If Monero were to cease development, how would Kovri I2P keep up with changes to the I2P protocol?  Would use of Kovri be able to be routed around?

Kovri and Monero are 2 distinct stand-alone projects that does not share any source code in common. Even if developers are not the same, it is still the same community (they are both under https://github.com/monero-project, same funding system ). So while there is nothing technically that would prevent Kovri to continue if Monero were to cease, it is highly unlikely that it will happen in the current state of things.

However, the goal IS to build a project and a community that can sustain itself.


Which entities are related to Bytecoin and Minergate? After reading the answer to this question I would like to learn which entities are connected to Bytecoin and or Minergate. Although Bytecoin development has ground to a halt according to GitHub activity, affiliated entities (mostly CryptoNote related) live on, often with mysterious intent.

In particular, how are Bytecoin and Minergate related to CoinTelegraph, Freewallet, Changelly, ChainRadar, HitBTC and Fairproof? Are there any more notable entities worth mentioning?

I am not looking for speculative answers. Please provide sources to demonstrate any connections in terms of funding, ownership, leadership teams or shared objectives.

There is a lot of evidence connecting all of the companies mentioned in your question. There may be more connected companies that we are not yet aware of. From Wikipedia:

The first Changelly prototype was created as a startup in 2013 by the enthusiastic team of MinerGate, a mining pool, that has one of the longest track record in the crypto industry.

More evidence for the Changelly/Minergate connection has been reported by Monero users on Reddit:

There is a reason why you are not listed on getmonero.org. You are never responsive to questions and getting support is almost impossible unless you are willing to beg mods in the Minergate troll box.

Bytecoin, publicly launched in 2014 contrary to false claims of a 2012 launch but significant effort was expended prior to that time to develop the CryptoNote protocol, which is not based on Bitcoin. Due to their proven high familiarity with the complex CryptoNote protocol (at the time) nobody aside from the Bytecoin creators could be behind Minergate.

MinerGate was founded on 24th of March, 2014. It was the first mining pool for CryptoNote based currencies

Readers of Cointelegraph were surprised to learn that according to a former writer, they were funded by Bytecoin:

While some have cast doubt on my assertion, I have no doubt that CoinTelegraph was funded by Bytecoin from at least when I started and continues to get funding from the stable of CryptoNote coins, among other clients.
My suspicion is that someone close to the Bytecoin team, perhaps the Bytecoin team itself, owns CoinTelegraph. But it could be as CryptoCoinNews P. H. Madore proposed, that they are simply funded by MinerGate, which they certainly have connections to.

More details on the connections can be found in this interview with Ian  DeMartino, the writer quoted above. CoinTelegraph has partnerships with a number of companies which you did not mention, which could help explain why HitBTC is still listed on CMC, and why BCN no longer has a premine flag.
According to this 2014 Bitcointalk advertising opportunity announcement Coinmarketcap is part of "The CoinTelegraph Media Group"
Freewallet uses the Changelly API to facilitate cryptocurrency exchanges. They also introduce serious security risks typical of other Bytecoin and closed source Minergate affiliated services:

Also, they implement XMR wallets with your own unique address but they are holding the private key (from you), under the incredible justification of doing it so for "security" of the user.

Chainradar was launched in 2014 by imready2rock and shares data with Minergate. On Chainradar you will find price quotes "powered by HitBTC" and on Minergate you will find many banner adds for HitBTC. Both focus on CryptoNote coins and sometimes offer gimmicks to encourage users to download closed source software.
Read this answer about the failed attempt to force XMR/BCN merge mining shortly after launch. Combine that with more recent plans to promote merge mining with XDN. Only one Monero mining pool supports XMR/XDN merge mining. By this point which one should be obvious. The Minergate mining pool is also the one one that adds strange things to tx extra:

01c4230d59c83b3042fd82999cfda5be6b77c1673d9442d1f21c7ab9215bdc6c18021198414900000000000000000000000000000321004bff195014248ae22838853bcf293b8945f9baaac693c2d05bafe2f0f3e6c69e

The above test means that by mining on minergate you are "spamming the blockchain with whatever that crap is".
In addition to popular coins, BTC, XMR and DOGE, Fairproof supports the scarcely used XDN and BCN, which coincidentally were discussed above in the context of merged mining proposals. Minergate denied an official connection to fairproof when asked about running fairproof banner ads. However there is a lot of circumstantial evidence to counter than claim including website design and FairProof advertising in both the BCN and XDN Bitcointalk threads. Supporting hardly used coins when trying to run a successful business makes little sense, unless you have ulterior motives such as using them to promote merge mining with Monero, which is only offered if users download and use closed source Minergate software.
Based on similar circumstantial evidence such as design and an "Exchange rate provided by HitBTC" BTCLevels could also possibly be connected.


Monero GUI Crash on Launch "api-ms-win-core-libraryloader-l1-2-0.dll is missing" When I copy over/unzip/run a fresh copy of v0.13.0.4 GUI on my spare laptop, the program fails to open and says "api-ms-win-core-libraryloader-l1-2-0.dll" is missing. The window keeps popping back up after hitting OK and the Monero GUI fails to load.

This computer is running Windows 7 with all latest updates, but I'm assuming it's missing a library from Microsoft somewhere. Google searching talks about Win 10 upgrades, but I've never done that. I've ran the same zip file on several other computers with no issue.

I've already tried installing x64 C++ redistributable packages which finish in successful installation but the problem persists.

Following links contains solution:

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

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

Linux & OS-X:

QMLSCENE_DEVICE=softwarecontext

./monero-wallet-gui

Windows:

Add User Environment Variable.

Name=QMLSCENE_DEVICE

Value=softwarecontext

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


MyMonero architecture question: blockchain scanning put into backend mainly to save CPU in the app, or to save bandwidth? This is a follow-up to my question on the mymonero backend here

Just had a quick look at the openmonero implementation of the mymonero backend (pretty well readable btw given that I'm not familiar with the monero code base). Looks to me like the main point the mymonero backend adds is that the blockchain scanning, which in monero-wallet-cli is part of the wallet is put into the mymonero backend, which makes it kind of an intermediate layer between the regular full node in the background and the mymonero app. Is that to make the mymonero app even less computationally intensive than monero-wallet-cli and monero-wallet-gui? Or is it more in order to keep the bandwidth usage of the mymonero app low, because only the transactions for my address are sent from the mymonero backend to the app, instead of the whole blockchain?

MyMonero saves both Bandwidth and CPU in the expense of giving up your view key.

Monero has no light wallet that is comparable to Bitcoin & other similar Altcoins because monero requires the whole Blockchain for both receiving/sending transactions.  Having the whole blockchain is resource intensive specifically when starting to synchronize.

Thus, the only way to have a light wallet that is both less compute/bandwidth is to use a third party server where it will listen for your incoming transactions. In addition, this is not an ideal solution since it will not scale compared to P2P and you have to give up your view key.

In the future a light/hardware wallet maybe implemented.


Why is monero mined coins called tail emissions? Why not just call it "mined coins"? Coming from bitcoin, its confusing to use new terminology sometimes. Why is it called tail-emissions vs just calling it coins mined?

Tail emission specifically refers to newly mined coins after Monero is mostly mined out. With Monero, the block reward slowly decreases with each block. When it eventually gets to 0.6 XMR per two minute block, it stops decreasing and flattens out at that rate. This is referred to as the tail emission, and is a characteristic of Monero that Bitcoin does not have.


How does address recovery work? I have a secret key pair (from a wallet.keys file or derived from a seed-phrase).

I'm researching the subaddress recovery process from those keys.

I heard about BIP32-similar methods in Bitcoin. I know the gap-limit concept.

How does the Monero recovery process work? Does my Monero node go over every subaddress until it found N empty (without transaction) addresses in a row?

How does it work if I have 10000 empty addresses and use the 10001-th?
How does it work if I use multiple accounts? Should I save anything else for backing up my wallet in this scenario?

First off, the node does not do anything about addresses, the wallet does. The node never gets your secret keys.

Next, the Monero wallet will always cache/calculate the next 200 addresses for the next 50 accounts. Every time you receive monero in one of these, the Monero wallet will cache/calculate more of these to always keep a buffer of 200/50 beyond the "furthest" you've used.

For this reason, if you decide to use a subaddress more than 200 away from the highest you've currently precached, it will not be seen. To prevent this, either use a larger lookahead (that option you've found already), or generate them manually in monero-wallet-cli by creating new addresses until you get in range.

Those addresses are deterministic, so you don't need to back them up. They can always be restored in the same way from your seed.


Dual (merged) mining (no additional hashpower) by guessing? http://fantomcoin.org/ allows dual mining.

Their https://bitcointalk.org/index.php?topic=598823.0 page says:

  merged mining with Bytecoin (BCN), Monero (XMR), QuazarCoin (QCN), duckNote (duck) or any CN based coin. New blockchain needs no additional hashpower

hmmm... needs no additional hashpower

  Question 1: Are the miners hashing fantomcoin's last blocks 'nonce'?

Coinbase says hashing is done by:

"solving a complex mathematical puzzle that is part of the bitcoin program, and including the answer in the block. The puzzle that needs solving is to find a number that, when combined with the data in the block and passed through a hash function, produces a result that is within a certain range. This is much harder than it sounds.

(For trivia lovers, this number is called a "nonce", which is a concatenation of "number used once." In the case of bitcoin, the nonce is an integer between 0 and 4,294,967,296.)

Solving the puzzle

How do they find this number? By guessing at random. The hash function makes it impossible to predict what the output will be. So, miners guess the mystery number and apply the hash function to the combination of that guessed number and the data in the block. The resulting hash has to start with a pre-established number of zeroes. There's no way of knowing which number will work, because two consecutive integers will give wildly varying results. What's more, there may be several nonces that produce the desired result, or there may be none (in which case the miners keep trying, but with a different block configuration)."

  Question 2: how can fantomcoin do this with no additional hashpower?

Is fantomcoin just guessing and submitting the same result (for it's own mathematical problem) to other cryptonote networks, hoping that it strikes it lucky!?

Tari university has a great explanation about what merge mining is here. I strongly recommend you to read it.


Is it possible to mine on your CPU and GPU at the same time? I was wondering if it was possible to mine on both the CPU and the GPU at the same time on the same computer?

I have an Intel i9 7900X and an Nvidia 1080Ti, so I was hoping to get reasonable performance.


Most efficent AMD CPU for XMR mining? I'm looking for the best AMD CPU for XMR mining which must be efficient in terms of power consumption per hash. And what is the best combination of threads, core and cache memory size to get maximum hash rate with most suitable OS. Also if I have 4 CPU do I really need 4 motherboards for each CPU?

This verges on an opinion based question that should be closed as such. However, it's generally acknowledged that the AMD Ryzen 3000 series CPUs are probably the best overall in terms of efficiency (hash/watt) and price (which you overlooked). What clock settings, RAM and everything else that goes into the PC have a huge bearing on overall efficiency.

  And what is the best combination of threads, core and cache memory size to get maximum hash rate with most suitable OS

More threads and more cores gives more hashes. What OS depends on what you are most comfortable configuring.

Also, from the RandomX readme w.r.t. cache (amongst other things): "16 KiB of L1 cache, 256 KiB of L2 cache and 2 MiB of L3 cache per mining thread".

  Also if I have 4 CPU do I really need 4 motherboards for each CPU?

If you use Ryzen 3000 series CPUs you need one motherboard per CPU - they do not support multi socket motherboards.


Remote peers and mining question with playground network I am running a stagenet with 2 nodes for playing / learning Monero. First, the nodes should have been running isolated from the outside world. What I don't understand from the following logs:

What is this (95.115.74.43) IP? Is it a stagenet or Monero node IP?
Second, I am not mining, and thus I wonder how could a block be found (12:55:00.179)? Does it mean that somebody is mining on my playground node?
Does a block found means there is a new coin being transferred to a wallet?
Is it a must to use stagenet?

2019-06-08 12:55:00.177 T dbg <<< global-IN: speed is A=  64.339 vs Max=8.38861e+06  so sleep: D=-9.65191 sec E=     621 (Enow=    1242) M=8.38861e+06 W=   9.652 R=8.09662e+07 Wgood      11 History: [621 0 0 0 0 0 0 0 0 0 ] m_last_sample_time= 44951.7
2019-06-08 12:55:00.177 D [xxx.xxx.xxx.xxx:8080 OUT] LEVIN_PACKET_RECEIVED. [len=588, flags2, r?=0, cmd = 1002, v=1
2019-06-08 12:55:00.178 D [xxx.xxx.xxx.xxx:8080 OUT] REMOTE PEERLIST: TIME_DELTA: 0, remote peerlist size=3
2019-06-08 12:55:00.178 D [xxx.xxx.xxx.xxx:8080 OUT] REMOTE PEERLIST: 88ebe20ef4fa7c68  **95.115.74.43**:xxxx   rpc port -  pruning seed 0  last_seen: never
69e17fad298bb67 xxx.xxx.xxx.xxx:xxxx    rpc port -  pruning seed 0  last_seen: never
f4068cf7ba6d1fcb    xxx.xxx.xxx.xxx:xxxx    rpc port -  pruning seed 0  last_seen: never

2019-06-08 12:55:00.178 T Blockchain::get_current_blockchain_height
2019-06-08 12:55:00.178 T BlockchainLMDB::height
2019-06-08 12:55:00.178 T BlockchainLMDB::block_rtxn_start
2019-06-08 12:55:00.178 T mdb_txn_safe: destructor
2019-06-08 12:55:00.179 T Blockchain::have_block
2019-06-08 12:55:00.179 T BlockchainLMDB::block_exists
2019-06-08 12:55:00.179 T BlockchainLMDB::block_rtxn_start
2019-06-08 12:55:00.179 T mdb_txn_safe: destructor
**2019-06-08 12:55:00.179   D block <95e3b029806384fe898d8efc53da37c2273369e114932fd21b6438e24fd8897b> found in main chain**
2019-06-08 12:55:00.179 T [xxx.xxx.xxx.xxx:xxxx OUT] [levin_protocol] <<-- finish_outer_call

the nodes should have been running isolated from the outside world

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

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

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


What exactly are bulletproofs replacing in monero? I am stuck on these questions in understanding bulletproofs:

Are bulletproofs a way to hide the sender and the amount?

What is the difference between bulletproofs, RingCT and Ring signatures?

Edit:

Confidential txs just hide the amount.

RingCT is based upon this, but also hides the sender using stealth address, ring signatures and range/bullet proofs?

Bulletproofs are used to prove that the amounts in confidential transactions are in range, so you can't do underhanded things like creating negative amounts. They replace Borromean range proofs. They are smaller in size, and faster to verify, though slower to generate. As used in Monero, they are unrelated to ring signatures, but are part of RingCT, since RingCT uses confidential transactions, and thus range proofs.

Amounts are hidden by Pedersen commitments.

Senders are hidden by ring signatures.

Recipients are hidden by stealth addresses.


Do any Monero wallets have the ability to create a transaction without broadcasting it, and then broadcast it later? Let's say I'm concerned with privacy, so I prefer to run a whole node, and I do.  One day, I find that I'm required to pull my node offline, perhaps due to maintenance issues.  During that downtime, I find it important that I spend some Monero.  To use my wallet while my daemon is offline, I know I can connect my wallet to a remote node, but I would like to mitigate some of the potential privacy loss in doing so.

Is it possible to use a remote node as my wallet's daemon-host in order to create a transaction, but then later broadcast it through a different node?  That is, can the wallet create a transaction without simultaneously broadcasting it?  How?

Perhaps this additional step would only provide for a questionable amount of additional privacy over clearnet, but a broadcast over Kovri (when it's available) would sure be an improvement.

You can use a watch-only wallet to create the TX. When executing transfer command, it'll just save the TX to a file. You can then later open a full wallet and sign & send the TX. It's the same process as described here, only simpler, because you're not using a cold set-up. If you have both wallets in the same folder, you can just have them both opened and execute the commands without having to move the files around.

It's really a work-around because there's no option to have the full wallet make a TX to a file.


How to switch the algorithm according to hard fork height? When a hard fork is scheduled, how does the program recognize the hard fork? And how to make the whole network recognize the new algorithm?

Every hard fork introduces a new version that is programmed to "handle" the fork. Something like "Up until block height XXX do this, starting from block height XXX+1 do that".

Older versions will not be able to do that, because when they were released, no one knew what will the requirements be for the next hard fork. This is the reason that before every hard fork people are being told over and over to update their version.

Every hard fork relies on the hope that most of the network will upgrade to the new version - something that goes pretty well so far.


Is there anyway monero can be investigated I am tasked with an assignment on monero cryptocurrency and one of the points I need to cover is “how can the currency be investigated”. Can anyone help? Thanks

Monero is a cryptocurrency for which the reference implementation is open source, available at https://github.com/monero-project/monero. Anyone may read the source, and modify it to suit their own ends, provided the (BSD) license is respected (which basically means don't be an asshole and pretend you wrote it all yourself).

You will need some basic competency in C++ to read and understand the source.


How can a business or charity publish proof of XMR reserves? Is Monero too private to allow auditing?

Without a rich list or transparent blockchain how can a business or charity publish proof of XMR reserves?

Currently, this is not possible. There is however a patch that allows just this ready to be merged:

https://github.com/moneromooo-monero/bitmonero/tree/signed-key-images

This is possible:

Two new commands are added that allow proof of reserves:

export_key_images will generate a file containing a dump of all an acocunt's key images, sign with the corresponding output private keys.
import_key_images will load such a file on a wallet with only the matching view key, which will allow simplewallet to determine which of the outputs received by the wallet are spent, and which are not, deducing the resulting balance.

The steps needed for party A to prove reserves to party B would then be:

A discloses their private view key to B
B can then see incoming transactions to A's wallet, but can't spend them (as A did not share the spend key, just the view key)
A generates a signed key images file with export_key_images and gives it to B
B runs import_key_images to determine the wallet balance

Note that B can be "the public at large" if A wants to, by making public the view key and the signed key images.

A may then supply an updated key images list whenever required. For example, a tax auditor may require a yearly update, made on tax day. A charity may decide to update that list daily on their website. It also means that A can decide at any moment to stop supplying this data, which will make A's subsequent spends private again from that point.

There are also RPC commands that will return the same data as a string for automation.

Note that this patch set was not merged yet, and is thus unreviewed, and may yet change before it is merged.


What is the base 58 monero alphabet used to create an address? Is it identical to bitcoin? I know ripple uses a different set of characters, but the same checksum.

Monero has its own variant of Base58.
In Monero the Base58 encoding is performed in 8-byte blocks, except the last block which is the remaining (8 or less) bytes .

The 8-byte block converts to 11 or less Base58 characters. If the block converted to less then 11 characters, the output is padded with "1"s (0 in Base58). The final block is padded as well to whatever would be the maximum size of this number of bytes encoded in Base58.

The advantage of Monero implementation is that output is of a fixed size which is not the case with plain Base58. The disadvantage is that default libraries won't work.

The alphabet for the variant of Base58 is

123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz

For details, see  https://github.com/monero-project/monero/blob/master/src/common/base58.cpp


How will users be notified of future updates to the beta GUI wallet? Is the GUI wallet able to automatically check for updates and advise users to download the latest version, or will future updates be announced elsewhere?

New releases get tagged on the github page, which is currently the freshest source of info on development progress.

Shortly after, downloads would be found on the "official" project site https://getmonero.org

Also, the Monero sub-reddit usually has important information stickied as the first post.

With this kind of software, it is probably not a good idea to implement auto-check as it could become a security vulnerability.


How can I verify the SHA256 hash of 0.10.3 “Wolfram Warptangent” on Windows? How can I verify the SHA256 hash published for the official 0.10.3 release matches the file that I downloaded for Windows, 64-bit?

Windows also has a built-in command-line tool to check hashes.

First, using Windows Explorer, navigate to the folder to which you downloaded monero-win-x64-v0.10.3.0.zip.

Then, shift + right-click somewhere on the background (don't select any files) and select Open command window here.

You'll be presented with the console which will start in the same working folder so it'll make the following steps easier.

Then, command:

certutil -hashfile monero-win-x64-v0.10.3.0.zip SHA256

You'll see an output like:

SHA256 hash of file monero-win-x64-v0.10.3.0.zip:
37 a5 7d 1b e8 1b 61 19 ac 06 d3 f6 37 b4 c5 6f c6 25 f3 e7 90 f3 49 1c 1b dc a4 d6 29 02 bf 13
CertUtil: -hashfile command completed successfully.

which you can compare against the one published on getmonero.org


How long of an encrypted payment ID hex message can be sent after the v0.15 fork? With the recent v0.15 upgrade, as of 2019-Dec long payment IDs have been removed. The only one remaining now is an encrypted payment ID. If I wanted to convert this payment ID as an alphanumeric message, using hex, how long of a text message can I use?

Encrypted payment IDs are 8 bytes (16 hex chars).


Monero RPC command for getting global index of one-time public key I know there is a Monero RPC command /get_outs for getting one-time output (stealth address) information, including the public key, from the global index of the output. Is there a reverse command? In other words, in there a command that lets me find the global index of a one-time output from its public key? Thank you, and have a good day!

In other words, in there a command that lets me find the global index of a one-time output from its public key?

If you know (which it sounds like you do) the txid that created the output, you can just use /get_transactions, which reports the global output indices in the response field output_indices.
If you didn't know the txid, there isn't an RPC method that takes as input an output public key and returns its global index. That said, it wouldn't take rocket science to write something to search the LMDB database directly.


Alternative Monero implementations Considering the hardforks planned in Monero, it seems that having several implementations of the daemon is a difficult task as they would need to be kept in sync.

I wondered however:

Have there been projects to produce alternative implementations of the Monero daemon (I only know of the official c++ version)?
Would it be useful for the community to have more than one implementation?

An old experiment of alternative implementation of Monero can be https://github.com/monero-project/mininero

It's not an alternative for Monero but an alternative for RingCT transactions.


Can I store the Monero local blockchain on a Ledger Nano S? So all I know about Ledger or Trezor is that you can make wallets from any cryptocurrency.
I want to import my local blockchain once and forever, instead of getting an external SSD disk (for fast synchronization), I am wondering if I could just import my local node to the Ledger Nano S device.
Thank you!

No.  There is only a few MB, not 100's of GB on the device for apps and key stores.


How do I, on Mac OS X, generate a Ledger Monero wallet with the CLI and subsequently use it in the GUI? According to the release notes v0.12.x.0 includes Ledger support. How do I, on Mac OS X, generate a Ledger Monero wallet with the CLI and subsequently use it in the GUI?

The GUI is now able to directly generate a Ledger Monero wallet. Thus, please see this Q&A:

How do I generate a Ledger Monero wallet with the GUI (monero-wallet-gui)?

We first have to ensure that we're sufficiently prepared. This entails the following:

This guide assumes you have already initialized your Ledger wallet and thus generated a 24 word mnemonic seed.
You need to run / use GUI v0.12.3.0, which can be found here. You can, if you're still running an older version, use the instructions in aforementioned Reddit post to upgrade.
You need to install the Ledger Monero app and configure your system. Instructions can be found here (sections 3.1.1 and 3.2.2 in particular).
Note that the instructions for system configuration (section 3.2.2) on Mac OS X are quite elaborate and can be perceived as slightly convoluted. Fortunately, tficharmers has created a guide here that you can use for assistance.
All Monero related processes need to be closed.
Your Ledger needs to be plugged in and the Ledger Monero app should be running.

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

Use Finder to browse to the directory / folder monero-wallet-gui.app (GUI v0.12.3.0) is located.
Right click on monero-wallet-gui.app -> Show contents
You should now see monero-wallet-cli
Go to your desktop.
Open a new terminal (if don't know how to open a terminal, see here).
Drag monero-wallet-cli in the terminal. It should add the full path to the terminal. Do not hit enter.
Now type:

--generate-from-device <new-wallet-name> --restore-height 1585000 --subaddress-lookahead 3:200

Note that  is simply a placeholder for the actual wallet name. If you, for instance, want to name your wallet MoneroWallet, the command would be as follows:

--generate-from-device MoneroWallet --restore-height 1585000 --subaddress-lookahead 3:200

Note that aforementioned text will be appended to the path of monero-wallet-cli. Thus, before you hit enter, your terminal should look like:

/full/path/to/monero-wallet-cli --generate-from-device <new-wallet-name> --restore-height 1585000 --subaddress-lookahead 3:200

Where the full path is, intuitively, the actual path on your Mac OS X.

The CLI will, after executing aforementioned command, prompt your for a password. Make sure to set a strong password and confirm it thereafter.
The Ledger will ask whether you want to export the private view key or not. First and foremost, your funds cannot be compromised with merely the private view key. Exporting the private view key enables the client (on the computer - Monero v0.12.3.0) to scan blocks looking for transactions that belong to your wallet / address. If this option is not utilized, the device (Ledger) will scan blocks, which will be significantly slower. There is, however, one cavaet. That is, if your system gets compromised, the adversary will potentially be able to compromise your private view key as well, which is detrimental to privacy. This is virtually impossible when the private view key is not exported.
You may have to hit confirm twice before it proceeds.
Your Ledger Monero wallet will now be generated. Note that this may take up to 5-10 minutes. Furthermore, there will be no immediate feedback in the CLI nor on the Ledger.
You may, after the CLI has generated your wallet, get an error about the wallet not being connected to the daemon. You can ignore that for now.
Type exit into monero-wallet-cli to close the CLI.
Note that your wallet files will, most likely, be stored in ~, which is short for /Users/<username> on Mac OS X. This may be a bit inconvenient. Fortunately, however, you can simply copy the wallet files to a different preferred directory / folder.
Open GUI v0.12.3.0. If you have already created a wallet in the GUI, click Cancel when it prompts you for the password of your current wallet. This should bring you back to the wizard. If you haven't already created a wallet, you should automatically start in the wizard.
The first page of the wizard is language selection, which looks like this. Select your desired language to proceed.
On the second page of the wizard, which looks like this, select Open a wallet from file.
Select the wallet file (the .keys file, which, to reiterate, is stored in either Users/<username> or in your preferred directory / folder) you just created with the CLI.
Congratulations, you can now use your Ledger Monero wallet with the GUI! If you need any general assistance with the GUI, please see this guide.

A few final notes:

I'd strongly advise to test the full process first. That is, send a small amount to the wallet and subsequently restore it (using aforementioned guide) to verify that you can recover the wallet.
If desired, you can manually tweak the --subaddress-lookahead value. The first value is the number of accounts and the second value is the number of subaddresses per account. Thus, if you, for instance, want to pregenerate 5 accounts with 100 subaddresses each, use --subaddress-lookahead 5:100. Bear in mind that, the more subaddresses you pregenerate, the longer it takes for the Ledger to create your wallet.
You only have to use the --generate-from-device flag once (i.e. upon wallet creation). Thereafter, you'd basically use it similar to how you normally use the GUI. That is:

[1] Make sure your Ledger is plugged in and the Monero app is running.

[2] Open monero-wallet-gui

[3] Enter the password to open the wallet.

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