Monero origins - optimized / crippled miner

The following text addresses the the crippled miner story. It has been copied verbatim from the original source, https://da-data.blogspot.com/2014/08/minting-money-with-monero-and-cpu.html

Minting Money with Monero ... and CPU vector intrinsics

August 28, 2014

I woke up on May 28th, 2014, on vacation with my family in the middle of the desert, to find a copy of my private source code plastered across the bitcointalk message board. Announced as a "new optimized version" of the Monero currency miner, it was enthusiastically adopted by cryptocurrency miners across the world. And in the process of doing so, my daily profit from the Monero Mining Project dropped by over five thousand dollars per day.

But let's start at the beginning, when I started getting in to a loose collaboration with three people I've never met---one whose name I'm not even confident I really know---with hundreds of thousands of dollars worth of a nebulous new cryptocurrency at stake.

It started with a cryptic note from someone I'd met online, with a link to a bitcointalk.org message board discussion for a new currency called "bitmonero". His note said only:

"this looks interesting."

From prior collaborations with him, I knew he had a good nose for opportunities in cryptocurrencies. Within an hour or two, he followed up noting:

"Regarding bitmonero it is profitable with aws with the wallet miner. Seem like some people have got optimised miner which is a few times faster as well so there obviously room for improvement..."

AWS, of course, was Amazon Web Services' spot market, which will let you cheaply rent mind-boggling amounts of compute power on short (1 hour) timescales. AWS profitability is a key ingredient for making money on cryptocurrency mining, because it scales: You can rent one machine or 10,000, and the only thing you have to worry about is if you start to use too many, the price will go up.

I was busy with the end of the semester and didn't respond quickly. The next day, I had an email from him offering 1 Bitcoin (about $600) to develop a 5x faster miner, and from chat, we discussed splitting the profits after that 50/50. I was still feeling overwhelmed with real work, but I took a brief look at the code, and something... well, something smelled funny. So funny that I got home, couldn't get it out of my head, and spent the next 6 hours playing around with it -- and got a 3x speedup.

The next day, I dropped my contact a note:

I'm giving it a little go at rewriting the entire thing in SSE for fun. I finally get it - they basically took scrypt as their model but make the whole thing a big long dependent chain. Hard to shave memory but at the cost of slow verification.

Followed a day later by raising that to a 5x speedup, and then an 8x speedup, and within a week, an 11x speedup. That was pretty remarkable, given that a developer had already started trickling optimizations into the codebase.

The more I looked at it, the more clear it became: The original developers deliberately crippled the miner. It wasn't just slow, and it wasn't just naive; it was deliberately obfuscated and made slow by the use of completely superfluous copies, function calls, use of 8 bit pointer types, and accompanied by the most ridiculously slow implementation of the AES encryption algorithm one could imagine.

Now, the history of "Bitmonero" (now called Monero) started to become relevant. In Feb 2014, an anonymous group of developers released a coin called "Bytecoin" based on an entirely new implementation of a bitcoin-like cryptocurrency called Cryptonote, but with much stronger anonymity built in through the use of a clever Diffie-Hellman like mechanism for encrypting destination addresses and the use of Rivest's ring signatures to provide a transaction-level mixnet without the need for realtime mixing. It's not perfect, but it's clever, and the most important thing is that it's new, and fundamentally different from Bitcoin. That attracted a lot of attention.

But when Bytecoin was released, it was presented as though it emerged from two years on the "dark web" (Tor onion sites and the like), during which time, 80% of the possible coins that could ever be minted, had been minted. The reception in the cryptocurrency community was heavily skeptical.

My strong belief is that the skepticism was warranted: Here's the original slow-hash from bytecoin as it was copied into Bitmonero. It has some doozies. For example, on line 100, you might note that for every iteration through an inner loop repeated tens of thousands of times, the AES key is re-imported into the library. The later loop, starting on line 113, is repeated half a million times, and is so abstracted through lots of memcpys and pointer manipulation it's hard to tell that all it really does is one round of AES encryption, a pointer dereference into a random scratchpad, a 64 bit multiplication, and another pointer dereference. Phew. This original code was roughly 50x slower than my final optimized code, and could have easily been used to fake two years of blockchain data on a single computer or a small cluster. I'm pretty sure that's what happened.

Bitmonero was a fork of Bytecoin designed to not have the 80% premine. But its initial developer either didn't know, didn't care, or wanted to profit from the de-optimized hashing. That initial developer was pretty quickly given the boot by the community, and in came an unrelated group of developers who took it over---who were, as far as I can tell, completely unaware of the deoptimization. So things sat there for a few weeks in the same state as Bytecoin.

By the time I got into it, developer "NoodleDoodle" (hey, this is crypto, people can pick whatever names they want -- Satoshi Nakamoto?) had already untwisted the first "de-optimization" with the AES encryption key. But the rest was ripe pickin's. Most importantly, the entire use of AES in the inner loop was one instruction on modern x86 CPUs.

This was a brilliantly designed proof-of-work function targeting the strengths of modern CPUs -- native AES encryption and fast 64 bit multipliers -- tuned to use a scratchpad exactly the size of the per-core L3 cache on Intel CPUs (about 2MB) that someone then wrapped in such a thick blanket of crap it was nearly unrecognizable until you started jumping in, tearing it apart, and putting it back together again.

Here's what it looks like without the crud (diagram shows one round): Some initial 128 bit values are determined by hashing the block state using a Keccak (sha3) variant - call them A and B. The big lookup table is also populated using that same state, mixed around using AES. Then, executed 500,000 times, are rounds of mixing as shown at the right: Use A to determine a pseudorandom location in the scratchpad, take that, mix it in, AES encrypt it (one round), use the result to determine a second location, use that in a 64 bit multiply, store it back, and repeat. Elegantly simple.

I didn't have the AWS account limits (or credit cards!) to really do it right, so I delivered some code to my contact and we went to town.

By the 14th of May, we were 45% of the total hashing power on the coin. Things started to get a little exciting:

I think i should make almost 6 btc in the last 24hr... will send you 3 if i manage to sell all the MRO.

$1500 per day was starting to seem like a very interesting ROI. I gave up on sleep for a while, and begged my family for permission to continue the project for a few hours per day while we were on vacation. Permission granted. I decided we'd made the right decision when on May 21st, we each netted 13 BTC (about $6500 USD), and 17BTC the next day. I think we exceeded 60% of the net hash of the coin at a few points. That's enough to play nasty games, but we weren't interested in that (and doing so would have required me to understand the rest of the code much more deeply than I had), so we just sold as fast as we could mine.

That was eye-opening. Because of the newness of the codebase and its actual, significant technical advances in anonymity (and a lot of growing pains and scalability challenges notwithstanding), a decent bit of Bitcoin money started flowing in to the coin. Some well-known and less well-known folks who'd made millions investing in Bitcoin started viewing Monero as an interesting high-risk hedge for a small percent of their Bitcoin holdings.

By May 16th, I'd squeezed about 90% of the optimizations out of it, and we were running 100x faster than the coin was at its initial release. That didn't stop me from obsessing about speed tweaks for the next week or so, but it gave me a little breathing room to start thinking about the next step.

The natural evolution of cryptocurrencies is that they start out being mined on CPUs, because that's easy. Then someone writes a GPU-optimized miner for them. The big ones jump to FPGA and then ASIC, though as far as the general community knows, only coins using SHA256d (Bitcoin and family) and scrypt (Litecoin, Dogecoin, etc.) have ASIC implementations.

So, why not take the next leap? We needed a GPU miner to keep ahead of the inevitable optimizations that others would release. In fact, the writing was already on the horizon -- NoodleDoodle had released another 2x speedup already, and was talking about getting an even bigger one out. It was only a matter of time until some of the dangerous experts in crypto started getting involved, and yvg1900 had been talking about developing a miner for Monero. The altcoin mining software world is small enough that there aren't too many people out there who can beat my optimizations without help, but yvg is one of them, and I knew that once he was in the game, before too long, I and everyone else would be running his code instead.

(And history showed that this was right - his final release beat my code by about 10%, and he was nice enough to share a few x86/Haswell micro-op optimization ideas with me.)

I've developed some GPU miner software as I blogged about earlier, but I'm not the best out there. Fortunately, in the process of doing so, I met some of the best. I dropped them a note, explained the opportunity, and they signed on. Pretty soon, we had in our arsenal not only a super-fast CPU miner, but also a great little GPU miner.

The beauty of having both was that it reduced our cost basis by a factor of two. While the GPU miner wasn't all that much faster than a CPU miner, due to the way pricing on the spot market often works out, you can rent a machine with a GPU for a similar price to one that only has a CPU. So within a few weeks, we were able to mine on both the GPU and CPU at the same time.

Which was fortunate, because that rock-in-my-guts May 28th incident rolled around sooner than I'd have ever guessed.

From what I can back-patch of it, my contact checked with another developer to see if there was room to further optimize my code on a contract basis. I don't know the details of that contact, so I won't speculate, but something somewhere went very wrong, and the other developer incorporated my optimizations into an open source release. Overnight, our edge started to disappear.

I gave up sleep for another night and eked out one last 5% performance boost to my code, but now we were really depending on having fast GPU code and on minimizing mining cost. We all spent some time benchmarking and running price/performance analyses about the types of instances available at Amazon, and reduced the cost a little through that. But then we got the GPU miner done, and, bogglingly, found ourselves back in business!

Things continued well for a week or two, until on June 4, another GPU developer, Claymore, released his own GPU miner -- but it targeted only AMD GPUs, and Amazon's were Nvidia. It was also more than 2x slower than ours -- three cheers for fast code. We held our breath waiting for an onslaught of new miners, but it never came. My best guess is that the newness of the Cryptonote software, as well as some difficulty getting it running because of a lot of dependencies on Boost and other libraries, scared a lot of people off and kept the technical barriers to entry high.

In the end, our game continued into July -- almost two months of mining at an advantage large enough to make a profit on Amazon. We spent over a quarter of a million dollars renting cloud compute time, to the point where I had a great phone call with the manager of the Spot instance program at Amazon who was trying to figure out how they could improve usability for weirdos like us.

It was a wild experience, and while I was, ahh, financially inconvenienced by the code leak, I'm also obliquely glad my optimizations made their way into the public (I'd have released them eventually, but hadn't planned on doing it quite so early). It's informative that throughout the many ways I've explored of getting paid to improve the state of the art in cryptocurrency software, the most profitable by over an order of magnitude was the most greedy approach of keeping the software entirely private. That's something the developers of future currencies should ponder -- it's probably worth up-front investment to pay someone to release an optimized CPU and GPU optimized miner for your coin, because if they're making a profit afterwords, it could be very hard to convince them to give up the margin.

25 lines mixing C, one instruction of inline assembly, and some AVX intrinsics -- one of the most fun, exciting, and profitable side projects I've ever been involved in. Like everything in crypto, it moved at the speed of light -- it was like launching and then folding up a small startup in the course of two months. And that's why I now have 6 high-end GPU mining rigs in my basement to heat the house through winter and some fun war stories about the importance of operational security and paying attention to low-level programming tricks in school.

(As a note: I make some positive statements about Monero in here, and I really do admire the technical advance it represents in anonymous cryptocurrencies. But please don't read anything I'm writing here as suggesting I think you should buy it -- I view all cryptocurrencies as exceptionally high risk, on a spectrum from "eek" to "stay the heck away!" There's an enormous amount of risk in all of the currencies, and while I talked about the technical positives of Monero here, it also has some very significant technical challenges. I don't personally own any, nor do I hold any Bitcoin - I mine and sell for the most part, to minimize my risk exposure.)


Ubuntu 16.04 LTS 64bit systemctl doesn't work

Try the following:

Type=forking
ExecStart=/opt/monero/monerod --detach


0 - 100 % GPU spikes when mining [NVIDIA GTX 750 TI]

You must open nvidia.txt (a file that xmr-stak creates after running for the first time) and set bsleep and bfactor to something other than the default "0". Try "bfactor" : 8, "bsleep" :  25, then restart xmr-stak.


How do I obtain a wallet address and pool password for my config file?

Usually you don't need a Payment ID anymore nowadays for new Wallet addresses. The Payment ID is now included in your Wallet address.

Worker ID is a label you can assign freely. Like MyWorker1.

Pool password is usally just x

So the whole string should look like:

"pool_address" : "xmr-eu1.nanopool.org:14444",
"wallet_address" : "46bNjyPKJU4hjT4xJTjzALb6Ck8xZjDBcewwKBp8Uk3P4WE6F21t2gTi5P58WQwJ6dHPUNicGWx6N9fjH55DCBkz4g3S9eQ.MyWorker1/your@email.com",
"pool_password" : "x",

Some pools may have different configurations tho. Some - like XMRPool.net - require you to append a fixed difficulty level to your wallet address. Like your_wallet_address.workerId+difficulty/your@email.com

Please also look at the examples on the page you linked. Scroll down to The moment.

The Login is usually Your_Wallet_Address and the password is your@email.com.


When did Monero convert from a 24 to a 25 mnemonic seed standard?

Which release (name and date) of the official monero-wallet-cli wallet changed the Monero mnemonic seed standard from 24 to 25 words?

Wordlist

Seems like the wordlist was introduced in 2014 (v0.8.8.5) and didn't change until the 2 minor fixes in 2015 (v0.9.0). That is the same one used at the present.

commit c01069f35253586ac2fbc3d507c7ed3ccdd900ce

Author: Riccardo Spagni <ric@spagni.net>
Date:   Wed Mar 4 15:31:24 2015 +0200

    fixed English word list issue: 'launchpad' should be 'ourselves'

commit 10e4132e22ccc0f1a41763adee74699ebedb5ffc

Author: Riccardo Spagni <ric@spagni.net>
Date:   Wed Mar 4 15:29:20 2015 +0200

    fixed English word list issue: 'incline' should have remained 'inline'

commit 010bfcfd18497b5f77cef62d60a56a556dfeadd4

Author: Riccardo Spagni <ric@spagni.net>
Date:   Mon Oct 6 08:47:04 2014 +0200

    minor English wordlist tweaks

Checksum

The 25th checksum word checksum was also introduced even before the above wordlist.

commit 8f587ba1c8044ed6face883d8f50cd43e27484e3

Author: Oran Juice <oranjuices@hotmail.com>
Date:   Sun Sep 28 02:29:25 2014 +0530

    CRC Checksum for word seed. Gives a new 25 word seed with checksum if one without checksum is passed. Doxygen comment fix.

  Without recovering my wallet from cold storage, is there any way to tell from my looking at my mnemonic seed if it was created with the old 24 word standard or if it was created with the new 25 word standard (and I forgot to record one word)?

Check against the dictionaries, should be either english or english-old. The latter one doesn't use the 25th word AFAIK.


How sophisticated will Monero's multisig capability be once RingCT is implemented and it's future plans afterwards?

Multisig will not be directly available once RingCT is merged. It will need further changes, which will build upon the RingtCT work. It is intended to allow typical N of M threshold signatures, in a way that is not visible from the blockchain (ie, you can't tell whether a transaction was made with multisig, or not).

See https://web.archive.org/web/20161023005318/https://shnoe.wordpress.com/2016/03/22/ring-multisignature/ for a description by Shen Noether, the author of RingCT.


A mining proxy is similar to how you describe. Yes it allows you to have a bunch of miners appear as one miner to a pool, but just because you have a high amount of users being proxied to the pool, does not however mean:

  doing almost all the mining job and sharing equally among all the users in the pool

Firstly, high user count does not necessarily mean high hashrate. It's very much hardware dependent. Secondly, there is no equal sharing. Miners get rewarded for the hashrate/difficulty of the jobs they submit - the more work you do, the higher percentage of any block rewards you get. Therefore your proxy only gets rewarded for the work it does (and thats the combined work of all your proxied miners).

Now onto pools.

  users join to help mine faster unifying the power of all the pool.

is not really an accurate description of how pool mining works. A pool allows a group of miners to all agree that whoever in the pool mines a block, they will share the reward proportionally with all miners of the pool, based on how much work each miner does. The pool server just facilitates this and its operator takes a cut for running it.

Now, because a pool has many miners (thus higher hashrate), it will find blocks faster than any of the individual miners could find a block alone.

This brings us to one of the reasons miners use pools: to get regular payments. Total paid out over time will be roughly the same as if solo mined - the difference is frequent small payments vs infrequent large payments.

Another reason to join a 3rd party pool is ease. To mine to an existing pool, you literally just download and run a miner program pointed at the pool. True solo mining requires running a node.

Another reason is coin hopping. If you don't care which cryptocurrency you mine, many pools offer automatic switching to the most profitable coin at any given time.

So back to your core question:

  Pool vs proxy for 1000 users?

Because a proxy is in effect, one pool miner, all payouts go to that one miner wallet. Therefore, how you intend to reimburse your users comes into play - how you (fairly) distribute the earnings. If one of your users has a lot of hashrate, surely they will want more rewards than a user with less hashrate. If all users have exactly the same hardware, this is less of an issue.

However, assuming your combined hashrate of all users is significant enough to get payouts at a frequency they are happy with, and you have the required experience to setup and run a pool, a private pool would make more sense. You are then not having to trust or rely on a 3rd party pool.

I'd suggest gaining more experience and understanding the subject matter better though. Start small and build your way up. It's one thing mining with your own time and hardware, but using your clients is another matter.


Is there any way to put non AES-NI processors to use for mining?

It is possible. You just have to set ./configure --disable-aes-ni when building  the cpu miner.
There is a memory leak when built without aes-ni. So you will have to restart it regularly (for me, that was at least once every 2 days).

With a pretty good core 2 duo, i get ~30 h/s (both core running) for ~100 Watt. So, unless you have a little army of them and free electricity, it is not worth it.


If you think about all the reasons why privacy matters for a crypto currency, almost all the same cases apply to any side-chain or smart-contract.


What would be the minimum mixin for full privacy?

It will always be a sliding scale, much like how many confirmations will give me full security? The answer is neither can give you "full" security, but they can make it so that it's enough to thwart even the most determined attacker.

Right now RingCT hasn't been rolled out so privacy is "OK", but once it is in effect it will not only obfuscate better, but also allow users to use much higher mixins without having the transaction size explode.

Really at the end of the day it all depends on your needs, if you send round numbers, a mixin of 3-4 will be fine for a regular user. It you are actively trying to hide your tracks, say from a person you are sending money to so that they can't trace the funds back to your previous transactions, then maybe a mixin of 8 to 10. It all depends on how imminent the intent of unveiling you is and how sensitive the context of the transaction is.


Without commenting on the idea... MyMonero is a web wallet which makes it easier for someone to have Monero. It is not a payment processor, which seems to be what you're after. So MyMonero isn't suitable.

Anything touching fiat money tends to be hard to get to due to regulations: most countries demand thorough spying on your customers, so many companies aren't able to withstand the costs of doing so. Something like https://bitpay.com may be close to what you're looking for, though they do settle in Bitcoin, not Monero. https://globee.com/ settles in Monero, but does not accept credit cards as far as I know. Maybe a combination of Bitpay and the API from https://shapeshift.io (to convert Bitcoin to Monero) might work for you ?


Are Cryptonight lite and Cryptonight lite v1 the same?

No, they are not.

Cryptonight lite is a derivative of Cryptonight with two changes: a smaller memory usage (1 MB vs 2 MB) and half the loop iterations.

Cryptonight lite variant 1 is a modification of Cryptonight lite which adds a few operations to the main loop and the setup phase. The intent is to break existing ASICs to fight mining centralization. It is expected that Aeon will soon switch from Cryptonight lite to Cryptonight lite variant 1.


Linking transactions when using XMR.to to send bitcoins?

I am not sure if XMR.TO uses the same address, but honestly it wouldn't matter. It would be relatively trivial to correlate all of XMR.TO's Bitcoin addresses.

Your more important concern regarding any links back to you is not something you should worry about.

When you connect to XMR.To, the only link to you is your IP address. If you connect to the site with Tor or I2P (as is recommended), then the site has no strong link to you.

The Bitcoin transactions you make with XMR.TO would look the same as the transactions from every other XMR.TO user. All transactions made from XMR.TO could be known as such, but that would not create any connections to the users of these services.


Why is Monero GUI stuck when it says it's syncing?

This issue was resolved by simply adding --block-sync-size 20 as daemon startup flag. You can do this on the Settings page of the GUI. In addition, a full guide to getting your blockchain "unstuck" can be found here.


Is it possible to create infinite coins in Monero since Monero is completely anonymous now?

The coinbase transactions are not anonymised (as they don't need to be), so no, situations like what you describe won't happen. The coinbase transactions will ensure the integrity of the coin supply can be verified.


How does the back-end of the upcoming MyMonero app look like?

See here for one working open-source implementation.

As understood, it is planned to release "official" open-source backend as well:

  In fact, in the near future, even the above trade-off will be eliminated as we're presently working to open-source a version of the back-end, which anybody can run as their own server at home.

There's a plan for some back-end overhaul as well:

  In progress by vtnerd Complete overhaul of back-end, and replacement of polling with sweet push-based synchronization (Issue #46)

So yeah, the plan is to let everyone run their own back-end, as indicated here. Quoting fluffypony:

  He's done excellent, excellent work - we've spent months on this, and hopefully it'll make MyMonero a significantly safer service to use, especially when you use it with your own node.


This is more of a generic Python question. And the docs are wrong. The last line should be .venv/bin/pytest. I'll correct that.

Also you may just install pysha3 (and other required modules) system-wide from packages that come with your OS. Then you may disregard all lines referencing to .venv


How to fix "Exception in main! locale::facet::_S_create_c_locale name not valid" when starting monerod?

Simply add
LANG=C LC_ALL=C

infront of the ./monerod command...
The entire command could look something like this:
LANG=C LC_ALL=C /home/$USER/monero-x86_64-linux-gnu-v0.17.1.0/monerod


How to see that the RingCT commitment parameter H is in fact a multiple of the base point G

You can check if a point is on the curve by attempting to decode it (it is checked as part of that).
In c this is here, but that doesn't make a lot of sense.

In python (ctrl+f "isoncurve", which is called by "decodepoint"), it's laid out pretty succinctly. It doesn't cost much.

Now, I realize this isn't the answer to your question, but I think it might be useful for other readers.

Now, to answer your question: (...why did this get so long?)

After doing some research and playing around with things, I believe there is only one subgroup of curve Ed25519 of size l (2^252 + 27742317777372353535851937790883648493).

There are really two answers:

1. How it is done in practice: take any valid curve point (via the above) and multiply it by 8 (3 doubles). As long as your starting point isn't a member of one of the small subgroups, you will end up with a point in the G subgroup. Now, note that this doesn't actually check whether your point is in the G subgroup, it only returns a point in G subgroup. Since 3 doublings is cheap, and knowing the subgroup of the point you started with isn't very useful, this is the usual method.

2. How to actually check: Multiply your point by l. If the result is the identity point ("0100000000000000000000000000000000000000000000000000000000000000"), your point is in the G subgroup. The reason for this is multiplying a point by its subgroup order (or a multiple since they are inclusive, or 0) always returns the identity element. I think of it as if the starting point is "1", and you are multiplying it by the modular order, meaning of course that you end up at 0.

To try to illustrate this, I made up some stuff:

Of course the real curve looks nothing like this; that's not the point.
Ed25519's l subgroup has a cofactor of 8. That means l * 8 is the total number of points on the curve (57896044618658097711785492504343953926856930875039260848015607506283634007912).

Entering "divisors of 57896044618658097711785492504343953926856930875039260848015607506283634007912" into WolphramAlpha, I get:

1
2
4
8
7237005577332262213973186563042994240857116359379907606001950938285454250989 <- "l"
14474011154664524427946373126085988481714232718759815212003901876570908501978 <- "l" * 2
28948022309329048855892746252171976963428465437519630424007803753141817003956 <- "l" * 4
57896044618658097711785492504343953926856930875039260848015607506283634007912 <- "l" * 8

There is (I believe) one cyclical subgroup for each of these divisors. The above image has 40 "points" listed. The construction logic was something like this:

Small subgroup points (divisors 1-8; all points are listed) are shown as numbers 0-7. 0 denotes the identity element, which is a member of every subgroup.
32 other points are shown as x,y,z, or G in increasing exclusivity as an example of the large subgroups.
Pipe symbols show what points are in what subgroup.
The list "wraps" around at the end (though it might make more modular sense if 0 was at the end, but whatever).

Remarks:

You can superimpose the small subgroups on top of the large ones, with the corresponding large group having all small points as members.
The points in the small and large subgroups are all members of the next larger subgroup, with a demarcation between 8 and l (the superimposition above).
A "generator point" chosen from any subgroup will only produce points in that subgroup, never points exclusive to a larger one (remember that they are inclusive of smaller subgroups).
For example, choose the first x in the above picture as a generator. Doubling it once gets us a point in the second subgroup (which is also of course in the subgroup). Adding x to that y will get us a point back exclusively in the big group, but if we instead start to double y (choose it as our new generator point), we can never return to an exclusively big group point. So if we choose a generator in subgroup G, we'll never "break out" of that group, as it's the smallest (big one) there is (the only "bad point" in it is the identity point, of subgroup size 1). Any point in subgroup G multiplied by any integer is guaranteed to be another point in subgroup G. While this is also true for the "upstream" subgroups, landing on a particular point and using that as a new generator (i.e., ECDH) would cause...inconsistent results.
The numbered points are the only ones that really make math sense (mod 8). If you select point 1 as your generator, you are in the small order subgroup 8, and will generate all points: 1->2->3->4->5->6->7->0->1. Number 2 will generate points in subgroup 4: 2->4->6->0->2. Number 3 will generate all points again: 3->6->1->4->5->0->3. Number 4 will only generate two points: 4->0->4. Number 0 will only generate one: 0->0->0, and so on.
The smallest large subgroup has order l, which is a prime number. This basically means that any point (except identity) will be able to generate every other point, whereas in the other subgroups this isn't true.
This graphic doesn't show it (it's a crappy illustration), but basically
every 8th point is a member of l subgroup, and you can't "break out" of your subgroup, so multiplying by 8 guarantees you are in l subgroup, no matter which one your point started in (unless it's one of the small subgroup points, in which case you'll end up at the identity point). Of course in roughly half the cases, you would only need to multiply by 4, in 1/4th the cases by 2, and in 1/8th the cases by 1 (your point is already in subgroup G), but multiplying it by 8 ensures it in "all" cases.

P.S. I don't know if this answer makes any sense, but it's been a fun study for me. I'm sure it's technically not correct in many places, but I think it's still educational. Playing around with points in Python or the Javascript at my site has been interesting.

P.P.S. Note hash_to_ec (for creating key images) includes a "mul_8" to ensure the point is in the right subgroup.


Install latest Monero GUI before fixing corrupted blockchain

The daemon and the wallet run independently of one another.  The daemon is in charge of the blockchain, and it'll look up information for a wallet.  The wallet doesn't have a copy of the blockchain.  It manages your keys and transaction history.

With that said, it doesn't matter when you delete the blockchain.  It will be semi-painful, since the IBD (initial block download) will take up to a couple days or more.  Once you're caught up, though, you'll be fine.

In other words, the deleting of the blockchain doesn't affect your wallet.  In fact, the GUI has a new feature called "Bootstrap daemon" which means you can connect to a remote node, while your daemon syncs in the background.


In short, someone managed to exploit a bug in the code, which produced a block that couldn't be validated by the nodes, there's a full analysis of the attack here, https://lab.getmonero.org/pubs/MRL-0002.pdf

Fluffy explained it well, so I'll just paste his abbreviated comment from here: https://www.reddit.com/r/Monero/comments/30jp2n/alright_devs_own_up_whats_the_deal_with_magic/cpte8lk:

The long and the short of it is: the tree-hash.c code that is responsible for transaction hashes within a block had a bug in it whereby any hashes for more than 512 transactions would be computed using uninitialised memory (ie. with garbage). So the attacker slowly built up the dynamic block size limit until they were able to create a 72kb block with 514 transactions in it. Because the hash on transaction 513 and 514 in that block was computed using some random bits of memory on the mining pool's node at the time, a fork occurred. The network eventually chose one of the forks.

We could have patched the bug and carried on, as the network resolved the fork and was fine within 30 minutes of it occurring, but there was a problem with that: nodes stuck on the old fork still existed (in fact I spotted one still around the other day, and this attack occurred in September, 2014). When syncing up and receiving blocks from peers these "stuck" nodes are fine, until you get to block 202612, when suddenly it sends you a block that you cannot verify. We also found that there were some instances of nodes on the correct fork, but their transaction hashes for transactions 513/514 on block 202612 disagreed. This opened up the possibility for the attacker to spend those funds later on (or even for them to be used in a ring signature) which would cause another explosion.

Thus we had to add in a checkpoint for 202612, except that the block hash is over the block header only (ie. disregarding the actual transaction hashes), so we created an exception that uses a blob hash (ie. based on the raw block). We're actually busy refactoring that out into a more general purpose blob hash checkpoint system, partly for legibility, but also so we can use it in future if there is ever a need.


I'm mining with HD 6950 in Windows 7 x64 and xmr-stak 2.1.0 using the drivers 14.1 beta, download drivers here: http://www.guru3d.com/files-details/amd-catalyst-14-1-beta-1-6-(13-350-1005-january-31).html

Remember to use an app like MSI Afterbuner to regulate the fan and clocks (I don't recommend to OC), my card is hot and is the reference card so I have to set the fan to 55% and the card does not reach 65°

I get: ~300 h/s

EDIT:

You can download here the binary that I compiled with VS 2017, I didn't modify anything, I just compiled using the guide provided in xmr-stak github, I think it works because I installed the latest AMD APP SDK, with the binary provided from the official github I also get 90 h/s


Why does the option "--verify 0" for monero-blockchain-import not work?

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

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

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


Why is syncing Monero using a regular rotating disk drive so slow on a VPS?

Why is it so slow

Spinning hard drives are terribly slow compared to solid-state drives. Spinning hard drives you are sharing with multiple other workloads (i.e. in a shared environment, i.e. a VPS), are slow. Machines with low RAM and limited CPU cores are slow.

and how can I improve its sync speed?

Using a server with a SSD is the simplest way to improve your sync speed. Further improvements can be gained by having more RAM and more CPU cores.


Sending a Monero tip that if unclaimed reverts back to the donor

At the moment there is no multisig, and there is no way to time limit Tippero tips. I'm not exactly sure what happens to Tippero tips that are never moved by the recipient, but I'd imagine at this point (only a year or 18 months after launch) they're just sitting there as entries in the redis database. Maybe eventually moneromooo or fluffypony will sweep out accounts that haven't been active in x years to the dev donation address or something, but as far as I know no decision has been made in that regard.


Replay attacks and address differentiation after a hard fork?

1) The blockchain can fork at any time. From what I've observed, it only gets as far as 1-2 blocks down a branch before a chain reorganization occurs and the canonical longest branch is restored. Meanwhile, as noted here Why does Monero prevent transactions from being spent without 10 confirmations? it takes 10 blocks before any output is spendable. I believe this is the mechanism that you're asking for.

2) Wallet addresses are their own separate entity, they aren't dependent on a particular chain.

3) Non-valid addresses (with an invalid checksum) are rejected.


Your objective is to have a unique genesis block.

You could achieve this by altering the genesis transaction, for example by altering the output key and transaction public key so that your own wallet can be the beneficiary of the funds created in the genesis transaction. An easy way to do this would be to create a wallet address and then create a transaction destined for your wallet on the main Monero network. You could then use a blockchain explorer to inspect the tx public key and output one-time public key, and copy/paste that into the genesis transaction.

But if you don't care about getting access to the funds mined in the genesis transaction, you can leave the genesis transaction alone and simply change the nonce that is assigned to the genesis block.

If you're getting errors then please copy and paste the actual error messages into your question so that someone might be able to better understand specifically what you are doing wrong. My guess would be that your genesis block is fine and that the issue is related to aspects of setting up the daemon that are unrelated to the validity of your new genesis block. Therefore please document what you've tried, other than simply changing the contents of the genesis block.


If I exposed my public view key and public spend keys, what gets compromised?

Your public view and spend keys are already disclosed - they are parts of your standard, public address. All someone can do with your address is send you funds. Of course, anyone you disclose your address to will know you use Monero, they will not however be able to view any of your transactions.


How to get a Monero Transaction Hash to check incoming deposit on MoneroAddress.org generated address - without CLI or GUI wallet?

A transaction hash is a way of uniquely identifying a transaction.

If you have a transaction hash, you can use xmrchain.net to locate and examine the transaction, and then decrypt it to see the amount of incoming funds and verify those funds were destined for your wallet address. Here is an example transaction, where you can enter your Monero address and private view key to decrypt it: https://xmrchain.net/tx/f733590f7c139d512be0237f81e420a1ad07b19f264e74ad2c599606e61b5a6d

There are only two ways to determine the transaction hash for an incoming transaction. Either the person that sent you the funds tells you the hash, or you need to scan every transaction on the blockchain to check if any of them are destined for you.

Therefore if you aren't told the transaction hash, you're going to need to use some kind of wallet software that can scan the blockchain. You may not want to use the official Monero CLI or GUI, and may not be able to use mymonero.org, but you're going to have to use some kind of wallet. I don't know of any other trustworthy mymonero.org alternative, which means you'll have to download and install some other kind of Monero wallet software. If you're going to have to do that, you might as well use the official Monero GUI or CLI.

If the reason you don't want to download and install software is because you don't want to download the entire blockchain, then you can install the Monero GUI and connect to a remote node. You can find a list of remote nodes here: https://moneroworld.com/#nodes This means you won't have to download the entire blockchain, and your wallet will instead simply scan the blockchain for transactions destined for you.


Which is the most efficient way to run a Monero full node on a bare-metal hypervisor?

The term "efficiency" can have a couple of meanings in this context. Efficient usage of resources, efficient time to install etc.

  I was wondering what was the best solution (virtual server, LXC container or docker container on top of a VM)

In the context of efficient usage of system resources, LXC containers are light-weight, making use of the host OS. KVM by contrast is essentially running a whole separate OS. Therefore you could say LXC is more "efficient" than KVM. More answers here though.

What is the "best solution" is very much determined by your intended use-case and what else needs to run on the hardware. However, in the case of simply running a single Monero daemon, I can't immediately see the case for a full-on KVM solution.

  and if there were already available pre-settled / trusted solutions

Trust is a sliding scale. I would say the most trusted setup is to build the daemon from source and install that on whatever system/setup you choose. Failing that, there is also the option of downloading pre-compiled releases from the official GitHub repository and lastly there is a Docker file, should prefer running Docker.


Why are hard forks planned every 6 months?

Every single piece of security software you run has to try force security updates, otherwise you could be running a trivially compromised piece of software. Most closed-source software, and even open-source software that isn't as sensitive to tampering as Monero, use things like mailing lists to notify you of a new major version. Lots of them also use in-app notifications, which users have become adept at ignoring or clicking away.

Having regular, timed hard forks forces users to update the very sensitive piece of security software they're running, and benefit from all the patches, bug fixes, and reduced exploit vectors in newer versions. Being able to add functionality, and know that the whole network has access to it in-step with each other, is just icing on the cake.

In future when Monero is more stable we'll go down to annual hard forks, as mentioned elsewhere in these answers. If the core Monero daemon gets to a point where it's particularly secure and particularly stable (eg. the code has been formally verified, and been in production for years with little or no incidences) we can even go stretch them out further.


Transfer monero to another subaddress you control without copying the address itself

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.


Do stealth address only work with elliptic curve cryptography ?

Monero's stealth addressing works like this:

You start with a destination wallet address, which is a pair of public keys A, B which have corresponding private keys a, b known only to the recipient.
A Diffie-Hellman exchange is performed, resulting in a shared secret which can be transformed to produce a private key s.
A public key S corresponding to the private key s is determined.
A homomorphic encryption scheme is used to combine S with B. Homomorphic means that the private key corresponding to the public key S+B can be determined only by someone (i.e. the recipient) that knows s and b. S+B is published as the one-time output public key, and only the recipient (and not the sender or anyone else) can determine the private key for this one-time output. This means the sender can't spend the newly created output themselves.

Steps 1-3 can be done using any asymmetric encryption scheme, such as RSA.

To achieve step 4, you need an asymmetric encryption scheme which is homomorphic. I'm not an expert, but it's possible that the RSA unpadded scheme may work for this: https://en.wikipedia.org/wiki/Homomorphic_encryption#Unpadded_RSA

I don't know if any PQC asymmetric encryption schemes exist which support homomorphic encryption.


Transfer stuck for 2 days with "Unconfirmed incoming transaction found in the txpool" message. Why and what can I do?

The solution was to use rescan_bc then save_bc once completed.


Can the Trezor Model T wallet store both Monero and Bitcoin at the same time?

You can safely use and store Bitcoin and Monero simultaneously with your Trezor model T device.

If I try to install the Monero GUI using the 'Create a new wallet from hardware' option, will that somehow overwrite my Bitcoins?

No. The Trezor Model T, upon initializing the device, essentially provides a 'master' mnemonic seed that is valid for both Monero and Bitcoin.

Will I still be able to see/access both my Bitcoins and Moneros once I have the Monero GUI set up?

Yes. Setting up the Monero GUI in conjunction with the Trezor Model T will not affect your Bitcoin (or any other coin for that matter) holdings on the Trezor device.

Are there any other related issues or hazards I should be aware of?

It is advised to diligently read the guide:
How do I generate a Trezor Monero wallet with the GUI (monero-wallet-gui)?
And evidently, it is imperative to properly and safely back up your Trezor mnemonic seed.


What is stored inside them? Does the wallet store the public and private keys and nothing else? Or does it contain the list of transactions related to the wallet as well and their location on the blockchain?

The wallet-name.address.txt stores only the address. It is just for convenience if you want to know your address without having to open the wallet. In my opinion it presents a security risk as it could be easily replaced with a .txt file containing a different address, by malware or someone accessing your computer.
The wallet-name.keys stores your private keys. If it's a watch-only-wallet, it will store only your private view key. Important information inside of it can be recovered from the seed mnemonic. It is stored encrypted with your wallet password. The keys file also contains user options like "always-confirm-transfers", etc, plus the refresh height (to skip old blocks from before the wallet was first created)
The wallet-name stores all other wallet data (also encrypted with your wallet password), such as:

All the outputs belonging to the wallet, which are found by scanning the blockchain when you're refreshing the wallet. To avoid having to do the scanning every time, the wallet stores them once found.
A key image for each signed output. This information is required to be able to check whether an output was spent or not. Without this information, the wallet will not display the correct balance.

Each signed output will always generate the same key image, which is then compared against all the key images on the blockchain. If found, it means that the output was already spent.
The key images are a mechanism used to prevent double-spends.
If it's a watch-only wallet, it will not have this, as it can't sign the outputs (for which the private spend key is needed).
However, you can import key images produced by the full-wallet counterpart, and have the correct balance displayed.

Metadata for each outgoing transaction (personal notes, tx keys, transaction history)
A set of block hashes, to detect blockchain reorgs

  In other words, if I copy my cold wallet to a connected PC, and this
  connected PC has downloaded the blockchain as well, do I need to
  rescan the whole blockchain or will the wallet immediately know the
  list of blocks where my coins are stored?

Yes, if you've restored your cold wallet from keys. It is true that your copy of the blockchain has all the information, but to know the balance, wallet needs to scan it with wallet-specific private view key to find outputs belonging to it. Then, it needs to sign them, generate key images, and compare against those found on the blockchain so it can mark each output as spent or unspent.

After you refresh your cold wallet for the first time, and if you don't discard the wallet files but choose to keep them saved on your cold PC, next time you transfer a fresh copy of the blockchain over to your cold PC you won't have to do it from scratch as it will already be refreshed up to a certain block height.

For more details about cold spending process, see here.


How can I get the public tx key on private testnet?

The public tx key is contained in the extra field. You can use monero-utils-deserialize to decode it from the transaction's hexadecimal representation, which you can get from the daemon, like this:

In monerod:

  print_tx TXID +hex

(replace TXID with your transaction's txid)

Then, in a shell:

  monero-utils-deserialize --input DATA

(replace data with the output from the previous monerod command)

If the transaction contains a tx public key (and the vast majority do), it will be printed out.

Note that monero-utils-deserialize is only built for debug builds.


LINUX - GUI v0.12 does not connect to local or remote node (std::bad_cast error)

This particular issue is resolved in GUI v0.13.

 This bad_cast issue is currently being investigated. In the meantime, there are two (temporary) workarounds, namely (i) using CLI v0.12 and (ii) using GUI v0.11 (with monerod v0.12 if you're using a local node).

Local node

Workaround 1:

Exit the GUI.
Browse to the directory your wallet files are located (~/Monero/<wallet-name>)
Copy the wallet files to the same directory as v0.12 CLI (monero-wallet-cli).
Open a new terminal from the same directory as v0.12 CLI.
If you specified a custom data directory (or, in other words, if you specified a Blockchain location in the GUI), skip this step and proceed to step 5. If you did not specify a custom data directory, type:

./monerod
If you specified a custom data directory, we have to add the --data-dir flag. That is:

./monerod --data-dir path/to/data/directory

For instance, if you used Monero as data directory on an external drive, your command would be:

./monerod  --data-dir /Volumes/externaldrive/Monero

Note that the --data-dir flag has to be applied every time you start the daemon (monerod).

Open another terminal from the same directory as v0.12 CLI.
Type -> ./monero-wallet-cli
Enter your wallet name.
Enter your password.
The wallet should now open in the CLI and perform a refresh.
Once it's fully refreshed, you can transact. I'd advise to use this guide for assistance:

https://getmonero.org/resources/user-guides/monero-wallet-cli.html

Workaround 2:

Exit GUI v0.12.
Replace monerod in the v0.11 directory with the v0.12 monerod
Browse to the directory your wallet files are located (~/Monero/<wallet-name>)
Rename <wallet-name> (the file without extension) to <wallet-name>-old
Open GUI v0.11. It should now work properly with monerod v0.12.

There is, unfortunately, one salient caveat with this workaround. That is, input sorting is required for v7 and GUI v0.11 is not able to sort inputs. As a result, creating a 2 input 2 output transaction will, on average, fail 50% of the time. Similarly, creating a 3 input 2 output transaction will, on average, fail 33% of the time. Creating a 1 input 2 output transaction, however, should not fail.

Remote node

Workaround 1:

Exit the GUI.
Browse to the directory your wallet files are located (~/Monero/<wallet-name>)
Copy the wallet files to the same directory as v0.12 CLI (monero-wallet-cli).
Open a new terminal from the same directory as v0.12 CLI.
Type -> ./monero-wallet-cli --daemon-address <remote-node-address>:<remote-node-port>
For instance, if you used node.moneroworld.com with port 18089 as remote node, the command would be -> ./monero-wallet-cli --daemon-address node.moneroworld.com:18089
Enter your wallet name.
Enter your password.
The wallet should now open in the CLI and perform a refresh.
Once it's fully refreshed, you can transact. I'd advise to use this guide for assistance:

https://getmonero.org/resources/user-guides/monero-wallet-cli.html

Workaround 2:

Exit GUI v0.12.
Browse to the directory your wallet files are located (~/Monero/<wallet-name>)
Rename <wallet-name> (the file without extension) to <wallet-name>-old
Open GUI v0.11. It should now work properly.

There is, unfortunately, one salient caveat with this workaround. That is, input sorting is required for v7 and GUI v0.11 is not able to sort inputs. As a result, creating a 2 input 2 output transaction will, on average, fail 50% of the time. Similarly, creating a 3 input 2 output transaction will, on average, fail 33% of the time. Creating a 1 input 2 output transaction, however, should not fail.


How to access Monero GUI desktop wallet in MyMonero web wallet?

Even though MyMonero generates a 13 word mnemonic seed by default, it will accept a 25 word mnemonic seed (generated by either the CLI or the GUI) as well. There are basically two options:

You import the 25 word mnemonic seed generated by the CLI/GUI before any transactions are sent to the corresponding address. In this case you won't have to pay an import fee.
You import the 25 word mnemonic seed generated by the CLI/GUI after any transactions are sent to the corresponding address. In this case you will have to pay an import fee (of 0.1 XMR), because MyMonero has to scan the blockchain looking for transactions that belong to your wallet / address, which can be quite resource intensive.


What software is included in the Monero Core?

There are several programs the most important being simplewallet and bitmonerod

There is also a simpleminer a blockchain_import and blockchain_converter tool.

For each account that you create with simplewallet an address, wallet and keys file will be created


Is Monero more or less complicated than Bitcoin to integrate into exchanges?

As I understand it, right now it's slightly harder due to the interface that Monero uses, but this is in the process of being standardised so it can be seamlessly integrated with exchanges just like Bitcoin.

This may be the reason that Monero hasn't been integrated with other exchanges, but in the near future this should be one less hurdle.


Can I manually check consistency of Pedersen Commitments in RingCT?

As in my post to MRL Issue #6, I now figured out what pseudoOuts mean. Assuming the outPk means the output commitments, what I'd like to know (assuming the ring signature is valid), would be to see the following hold:

sum_j{pseudoOuts[j]} = sum_i{outPk[i]} + fee*H

What I'm missing in Luigi's JS code is a way to get fee*H.

Edit:
Luigi kindly answered my question!
Here's the full JS code you can try at: https://xmr.llcoins.net/

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


Just change :

ssh XXXXXXX

with :

ssh -L18081:127.0.0.1:18081 XXXXXXX

This means : open a local port 18081, and redirect all messages to 127.0.0.1:18081 in the remote host.

This will be exactly like running monerod in your local computer. So just use the default host in monero-wallet-gui, which is 127.0.0.1


Why is the dynamic blocksize relying on the median blocksize rather than another metric?

The dynamic block size limit is inherited from CryptoNote, and is described in the whitepaper:

Users pay for storing the blockchain and shall be entitled to vote for its size. Every miner deals with the trade-off between balancing the costs and profit from the fees and sets his own “soft-limit” for creating blocks. Also the core rule for the maximum block size is necessary for preventing the blockchain from being flooded with bogus transaction, however this value should not be hard-coded.
Let M_N be the median value of the last N blocks sizes. Then the “hard-limit” for the size of accepting blocks is 2*M_N . It averts the blockchain from bloating but still allows the limit to slowly grow with time if necessary.
Transaction size does not need to be limited explicitly. It is bounded by the size of a block; and if somebody wants to create a huge transaction with hundreds of inputs/outputs (or with the high ambiguity degree in ring signatures), he can do so by paying sufficient fee.

The median window is not mentioned at all, so it was likely just inherited from the source. I'm not sure whether Monero changed this. In any case - it's arbitrary.
Changing it to a smaller value would make the system more responsive in case of increased transaction pressure and it could clear the backlog faster & cheaper (fee-wise).
Changing it to a bigger value would make the system less responsive and any queue would likely take longer to clear but the system would be more resistant to manipulation - like if someone is willing pay higher fees just to inflate the block size, it would cost them more with a bigger window.
While the choice of median is not explained in too much detail, it is convenient because it means that a single actor can't move the blocksize. You will always need more than 50% of blocks to be bigger (or smaller) than median to actually affect the median. So, users have to first "bribe" the miners for an increase (enough to compensate for the penalty) but it's no guarantee - the miners don't have to mine a bigger block even though it'd be more economic, so 51% miners could block any increase regardless of the fee - if they see it as a risk for their operations due to bandwith requirements etc.


How can I mine Monero on a cloud service?

I have tried mining on AWS, Azure and Google Cloud so trust me when I say you might never break even. I used their 30 days trial to setup mining using minergate cli mining client, which is easy to setup. To setup, use the following command;

wget https://minergate.com/download/deb-cli
mv deb-cli minergate-cli-release.deb
chmod u+x minergate-cli-release.deb
sudo apt install libpcre16 ./minergate-cli-release.deb && sudo apt-get install -f
minergate-cli --user xxxx@yyy.com --xmr 1

The last command (minergate-cli -user xxxx@yyy.com –xmr 1) starts mining. xxxx@yyy.com is your registered email on minergate.
-xmr is the currency to mine (Monero) while 1 is the number of CPU cores to use, if ommitted it will use all available cores.

It might be better for you to use screen command to run the mining instruction so that it does not stop when your ssh session closes.

LESSONS LEARNT

Google frown at mining with their 30 days trial cloud server. I am
not sure if it is allowed with the paid version
None of the providers proof profitable. The average Hashpower of
most of the servers is around 30-40H/s. AWS even drops to 3-5H/s at times. You might never be able to break even.


How can I get the right Keccak-256 tools. The online tool seems wrong...?

The online tool works perfectly, but the form accepts text and you were pasting in hex. The ASCII string "198584347013dd91832be3d82529437db7cc8e1850e559cdd3872b29ca819601" is 31393835383433343730313364643931383332626533643832353239343337646237636338653138353065353539636464333837326232396361383139363031 in hex, and the online tool correctly produced a keccak256 hash of the hex of what you pasted in.

The result of your keccak -256 command is also correct.


getmonero.org have some kind of language system?

I'm not entirely sure how the translations are being handled, but I recommend going to the official Monero forum and maybe posting it in the 'Ideas' section and seeing what the response is.

That being said, I have read once or twice about someone wanting to redesign the website. So if that is the case then it may be better to wait.

Or if you want a more immediate answer you can try the #monero or #monero-dev channel on Freenode.


When using a foreign remote node does the transaction signing happen on my wallet or on the node?

The wallet does the signing. The node never gets access to the the keys.

The node's purpose is to keep a local copy of the blockchain in sync with the network at large, and relay transactions made by the wallet. The wallet's purpose is to find incoming transactions and make outgoing transactions using the node. By the time the node sees a transaction, it's fully created, and bitwise the exact same as it will be stored in the chain [1].

[1] Later on, some nodes may elect to prune some parts of transactions, but this is a local storage choice.


unable to see wallet balance using simplewallet restore

You should be able to see your balance when it is fully synced, i.e 1123555/1123555


Can Ring Confidential Transactions Range Proofs be pruned?

Full nodes cannot prune the range proofs entirely in a trustless manner. SPV nodes and those relying on checkpoints could benefit in the manner described by
Monero Research Labs below:

  While the range proofs are large, using a transaction hashing scheme that signs
  the transaction "prefix" (both input indices and outputs) and stores the range
  proof, along with ring signatures, separately enables large amounts of space saving when syncing to a checkpoint or operating as an SPV node. Similar to Sidechains Elements, we would store H(H(pref ix)||H(signatures)) in the merkle tree.Then, nodes syncing to and trusting a checkpoint need only download the prefix and a hash of the signatures, effectively reducing the amount of bandwidth require to sync dramatically. Because the transaction prefix uses a variant for the outputs it references in its ring signatures and outputs funds to single public keys, they are minuscule in comparison to the ring signature data in the inputs and range proofs. Later, the ring signatures may even be pruned from the database by some nodes to further save space, storing instead only the comparatively small UTXO set.


ring size three transactions in txpool after v6 fork

As you can see, these transactions are no longer appearing in the mempool or anywhere else in the block explorer. Thus, they were dropped.


Is there a Javascript implementation of the CryptoNight algorithm?

Sure there is.

Do a npm search cryptonight-hashing and take a pick :)

NAME                      | DESCRIPTION          | AUTHOR          | DATE       | VERSION  | KEYWORD
cryptonight-hashing       | node-cryptonight-ha… | =moneroocean    | 2018-10-04 | 3.0.5    | crypton
node-cryptonight-lite     | node bindings for…   | =excitableaard… | 2018-02-01 | 1.0.1    | crypton
node-cryptonight          | node bindings for…   | =excitableaard… | 2018-10-08 | 1.2.0    | crypton
node-cryptonight-old-hard | node bindings for…   | =adaxi          | 2018-10-14 | 1.1.0    | cryptonware                      |                      |                 |            |          |
turtlecoin-multi-hashing  | ![image](https://us… | =brandonlehmann | 2018-12-11 | 0.0.18   | scrypt
multi-hashing-bbscoin     | multi-hashing-bbsco… | =randing89      | 2018-09-23 | 1.0.2    | scrypt
cryptonight-hash          | JavaScript…          | =andrehrf       | 2018-03-30 | 0.0.4    |


Monero RPC over SSL for client and server

Once you have setup the tunnel, it is equivalent to having monerod running in localhost. It is transparent for monero-wallet-cli and monero-wallet-gui.

The only difference, that i noticed so far, is that it doesn't accurately detect network failures, as the connexion with the tunnel manager stays up.

You can see here an example of setup using stunnel.


What would happen to the Monero network if a significant part would be isolated?

The isolated North American nodes would continue communicating, transacting, and mining among themselves. The world set of nodes would do the same.

At this point you have two possible chains. If communication is ever re-established the fork would resolve itself with the longest chain winning.

Depending on the time-span this could be catastrophic economically because one chain is basically going to be refunded. So if the North American chain fails, everyone that made purchases on that chain would have received goods and services, but then would get all their Monero back once the chain resolves.


Is it possible to create a Monero miner in Python?

It is certainly possible to make a miner using Python. There are several ways this can be accomplished and depends on what you want to achieve.

At it's bare minimum you would need to have the hashing algorithm, cn_slow_hash, implemented in Python. An example library that exposes this is here. The rest will boil down to what kind of miner you want to create. You could create a stratum based miner to work with a pool or you could create a solo miner talking directly with a Monero node via it's RPC interface.

I suggest first learning about the actual process of mining and then look at the source code of existing miner implementations.


Monero GUI - Is Daemon blocks remaining accurate when using --prune-blockchain?

Is Daemon blocks remaining accurate when using --prune-blockchain?

Yes. The amount of blocks you must sync, verify and scan is the same regardless if pruning or not.
Pruning just affects how much data is stored.

The number of blocks remaining linearly decreases over time, but perhaps we are still skipping over some blocks aka pruning?

Per above. We are not skipping downloading, verifying or scanning, we just don't save all the block data when pruning.

Is this normal?

Yes.


From Coinhive's front page:

Will This Work On My Site?
Technically yes, economically probably not. If you run a blog that gets 10 visits/day, the payout will be miniscule. For the captcha and shortlinks with a sensible hash goal (1024–16384) you'll need to have a whole lot of users to make this worthwhile.
Implementing a reward system for your site or game where users have to keep mining for longer durations is far more feasible. With just 10–20 active miners on your site, you can expect a monthly revenue of about 0.3 XMR (~$95).
If you run a streaming video site, a community site, an online game or anything else where you can give your users an incentive to run the miner for longer durations, then by all means: try it.

For the miner to generate a lot of revenue, you either need a lot of traffic (in which case, it might be more efficient to just use traditional ads anyway) or need to keep the user engaged with your application (so that you can keep using their CPU). 2 minutes doesn't look like sufficient engagement to me.
By the way, since the application want to keep you glued to the computer screen so you're willing to let the application sap your spare CPU, your attention is being sold (though your private data probably isn't).


Does the kovri pre-alpha build already work for running a monero node?

From the Kovri FAQ:

What is the current state of Kovri?
Kovri is in active development and currently pre-alpha. Kovri is not yet integrated with monero but, in addition to several core features, we are developing a client and core API for monero and other applications to use.
Currently, you can use the Kovri to connect to (and partake in) the I2P network: browse eepsites, connect to IRC, and run client and server tunnels.

Is Kovri usable, partially usable, or recommended to not be used for actual privacy at the moment?
Kovri is usable to the extent of what ./kovri --help has to offer. Kovri currently has no interaction with Monero. With regard to privacy, we have fixed many security issues since inception but we are still in pre-alpha.
There is still much code to cover so don't expect a strong guarantee of anonymity like with Tor or even java I2P. Those projects have 10+ years of research and implementation experience - and we are just getting started.
Feel free to play the role of developer and experiment/play with Kovri but only if not being anonymous doesn't put you in danger - as there is always the risk of possible de-anonymization due to being in pre-alpha (this is not unique to Kovri).


How do I install the Monero GUI on PureOS?

PureOS is based on Debian, so you can follow the instructions on this page (follow the Ubuntu and Mint path):

https://github.com/monero-project/monero-gui

Install Monero dependencies
For Ubuntu and Mint

sudo apt install build-essential cmake libboost-all-dev miniupnpc libunbound-dev graphviz doxygen libunwind8-dev pkg-config libssl-dev libzmq3-dev

Grab an up-to-date copy of the monero-gui repository

git clone https://github.com/monero-project/monero-gui.git

Go into the repository

cd monero-gui

Install the GUI Dependencies

For Ubuntu 16.04+ x64

sudo apt install qtbase5-dev qt5-default qtdeclarative5-dev qml-module-qtquick-controls qml-module-qtquick-xmllistmodel qttools5-dev-tools qml-module-qtquick-dialogs qml-module-qt-labs-settings libqt5qml-graphicaleffects

Optional : To build the flag WITH_SCANNER

For Ubuntu and Mint

sudo apt install qtmultimedia5-dev qml-module-qtmultimedia libzbar-dev

Build the GUI

For Ubuntu and Mint

./build.sh

The executable can be found in the build/release/bin folder.

Hope it helps!


Is there a way to search the blockchain by mixin?

You'll have to write some code for this.

There is a BlockchainDB::for_all_transactions function which can run a callback through all the transactions in the db. See the blockchain_dump.cpp file for an example. The callback can simply output the hash for all the transactions with a mixin of 10 (mixin being one less than the number of inputs in each vin array element). Note that those elements don't necessarily have to have the same size (ie, inputs can have different mixins).


How do I re-enable incoming connections?

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

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


Do cryptonight hash speeds mirror scrypt and SHA-256 hash speeds?

AFAIK, there is strictly no correlation between the hash speed of different hashing algorithms.

I guess it can possibly make sense for hardware that are capable of dual mining.

But, currently, hardware for SHA-256 & scrypt are ASICs, so they won't work for others hashing algorithms


--add-peer xmrtolujkxnlinre.onion:18081... that is the known onion node for xmr.to

Here is your misunderstanding: --add-peer is for adding peer nodes, nodes that will talk to each other on the Monero P2P network. It is not for using another nodes JSON RPC interface (which is all that xmrtolujkxnlinre.onion is offering up [ref]).

Thus if you want a full node to relay transactions to other nodes over Tor/i2p, you need to add a peer node that is listening for P2P traffic over an anonymity network via their usage of --anonymous-inbound ....


What plans are there to lower the monero fees to under 10 cents?

Fees are variable, based on the current moving average of the block size, and the block reward. It is thus expected to go down as time goes on, assuming constant usage. Since usage is also expected to increase in the long run, this adds another downward pressure. If you're measuring in dollars, then the exchange rate adds another variable which the consensus can't take into account as it's extrinsic. I suppose if the fees become too low or too high, they might be scaled, but there are no such plans at the moment.


Monitoring an address for activity if you have the private view key

This is all correct.

To create a view wallet from the private view key, you can use the --generate-from-view-key option:

monero-wallet-cli --generate-from-view-key sample-view-wallet

You will be asked for address and view key, and will end up with a wallet from which you cannot spend. Note that you will not see outgoing monero, so when you see incoming funds, it might be change.


How are subaddresses and account addresses generated from master wallet keys?

how can I compute subaddress Sa(a,i) where a is the account index and
  i is the subaddress index within the account?

You're right, it is not fully explained in either of those links.

Take a look at get_subaddress_spend_public_keys and get_subaddress_secret_key in the source code.

You'll see in the code that subaddress_index is a struct containing "major" and "minor", where major means the account index and minor means the subaddress index within that account. You'll also see the in second link that the string "SubAddr" is added into the mix.

Bringing it all together:

m = Hs("SubAddr" || a || account_index || subaddress_index_within_account)

Where a is a 32 byte scalar (the private view key), and account_index and subaddress_index_within_account are both 32 bit little endian unsigned integers.

Note that "SubAddr" needs to be a null terminated string, i.e. will be 8 bytes and not 7.

Finally, to get the wallet address for a subaddress, you need to follow the usual base58 procedure (which involves adding an identifier for the type of wallet address and adding a checksum) on the public view and spend keys (C, D), calculated as:

D = B + m*G
C = a*D

Also note that there is a special case, where the first subaddress of the first account is not calculated using the formula above, and instead is simply the ordinary main wallet address (A, B).

Edit: See an example Javascript implementation of a subaddress generator here: https://github.com/knaccc/subaddress-js


Build/Install Instructions for MyMonero App on Android using node/npm

There are instructions in the Github repo:

https://github.com/mymonero/mymonero-app-js/blob/master/docs/PRODUCTION_BUILDS.md


How to get a block reward from a block template?

1) How can I get the amount for transaction fees in a potential block?

The easiest method (and just using the RPC interface) to get the block emission separate to the tx fees is probably to subtract the last mined blocks emission (emission_amount of get_coinbase_tx_sum) from the expected_reward (of get_block_template). It's not perfectly accurate but probably accurate enough for most needs.

If you need something more accurate, you would have to calculate the emission for a given block height. An example of calculating emission can be found here, which could easily be rewritten to output the emission for a given height.

As you are wanting to do this from the block template, another approach is simply  parsing the block and adding up the tx fees. That obviously requires code to parse a block and transactions though.

  2) Am I moving in the right way to get a block reward without the transaction fees in it? Maybe there are easier ways?

I can't speak to why you want to know the emission and tx fees separately, but the above methods are ways to achieve it.

  3) ... There are many formulas for calculation block rewards using a value of coins emission. Should I move in that direction?

Again, this is difficult to answer without knowing precisely why you want to split the block reward.


Why Monero address is converted to base 58 in blocks, instead of all at once?

The base58 encoding used in Bitcoin converts all the data to an integer, and then encodes it using divisions by 58. If there is a lot of data, the integer will get very big, which requires having a library dealing with bignums. And usually bignum operations (in this case bignum divisions) are not very fast.

Encoding the data by blocks of 8 bytes at most is much faster because you only have to manage 64-bit integer (a 64-bit integer division will be a single instruction on a 64-bit CPU).

It also allows knowing easily what the size of the encoded string or decoded data will be:

8 bytes of data <=> 11 base58 characters
7 bytes of data <=> 10 base58 characters
6 bytes of data <=> 9 base58 characters
5 bytes of data <=> 7 base58 characters
4 bytes of data <=> 6 base58 characters
3 bytes of data <=> 5 base58 characters
2 bytes of data <=> 3 base58 characters
1 byte of data <=> 2 base58 characters


Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT

Yes, the pseudoOuts are new commitments calculated for your real inputs. Each pseudoOut is calculated as pseudoOut = aG + bH where a is a newly generated mask (also known as a blinding factor) and b is the input amount.

If the existing commitments for inputs were used in transactions spending multiple inputs (known as RCTTypeSimple transactions), if one real input ring position was revealed, this would reveal all real input ring positions in the transaction.

Because OutPk and PseudoOut are both commitments to the same amount, this means that OutPk - PseudoOut = Commitment to Zero. You can therefore prove that your OutPk and PseudoOut are commitments to the same amount by signing for the commitment to zero. You can sign because you will know the private key, which is the difference between the mask used for the OutPk and the newly generated mask used for the PseudoOut. The original mask used for the OutPk of your input is communicated to you via the EcdhInfos in the transaction that created the input for you.

The codebase is the real documentation for figuring out how this stuff works, as the full procedure is not currently documented in an MRL paper.


You are now synchronized with the network.

The reason you see that the blockchain is synchronized is because one (or more) of the nodes you are connected to say that you are up to date. Just because one node says you are does not mean that you are actually up to date.

Some nodes you are connected to may be running an old version of Monero, and these do not have the new elements of the blockchain stored. From their perspective, your node is fully synced (57 days ahead!). From everyone else on the current network, you still have some way to go.

You can start simplewallet/command-wallet-cli, but it will not have the information from the latest transactions. You should wait until is is completely synchronized with all of the nodes.


Mining with XMRig, what are "expired" shares?

Those messages are coming from the pool.

An accepted share is just that; you have worked on a job the pool sent you and submitted the result, which has been accepted. You will be rewarded for it.

An expired share is when you took too long on the job and you will not be rewarded for it.

If you're getting many expired shares, it's typically because the difficulty level of the jobs you are getting from the pool is too high for your hardware. You ideally want jobs that will take no longer than 2 minutes to complete.

Pools usually have different ports for different starting difficulty targets, so ensure you are connecting to the most appropriate pool port for your hardware.

In almost all cases, regardless of the pool port used (thus your starting difficulty target), the pool will automatically adjust the difficulty of the jobs it sends you based on your prior submitted shares. Thus even if you start with a few expired shares, after a few minutes of mining, the pool should start sending you more appropriate difficulty targets.


I cannot start monero-wallet-rpc. I receive the error: no connection to daemon

Firstly, you have to be running monerod for monero-wallet-rpc to work.

Next, if you start monerod with --stagenet, you have to start the wallet with --stagenet also. If you create a wallet for mainnet, it won't open on stagenet, same as for testnet. You cannot mix networks / daemons / wallets.

Next, you only need specify a rpc-bind-ip if you will be connecting remotely to the wallet RPC or daemon RPC. By default they listen on localhost so if you want to allow remote connections, you must specify an IP address they will bind to.

So, with all this understood, a setup with locally accessible only daemon and remotely accessible wallet RPC running from the same host, and both with their RPC's requiring login, you could start like:

monerod --rpc-login daemon-user:daemon-pass --detach

monero-wallet-rpc --rpc-bind-port 18089 --rpc-bind-ip 0.0.0.0 --confirm-external-bind \
  --rpc-login rpc-user:rpc-pass --daemon-login daemon-user:daemon-pass \
  --prompt-for-password --wallet-file my-wallet

If you add --stagenet to one, add it to the other too.

Here's a variation which will allow both of these RPC servers to be externally accessible and using non-standard ports for demonstration:

monerod --rpc-bind-ip 0.0.0.0 --rpc-bind-port 18088 --confirm-external-bind \
  --rpc-login daemon-user:daemon-pass --detach

monero-wallet-rpc --rpc-bind-ip 0.0.0.0 --rpc-bind-port 18089 --confirm-external-bind \
  --rpc-login rpc-user:rpc-pass --daemon-login daemon-user:daemon-pass \
  --daemon-port 18088 --prompt-for-password --wallet-file my-wallet

Lastly, all these flags are documented:

monerod --help
monero-wallet-rpc --help


What are the chances of Monero having a marketplace similar to Openbazaar?

That's exactly right, OpenBazaar isn't opposed to other integrations and all PRs will be reviewed. And while multisig is definitely an important part of another cryptocurrency getting accepted, adding in support at all would be a significant undertaking. We've tried to make the code more modular in the 2.0 server version, but Bitcoin is a core aspect of the code and any attempts to add Monero or any other currency shouldn't be taken lightly. If anyone is serious about such an effort, we recommend contacting the devs first in our Slack: http://slack.openbazaar.org"


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

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


How can I have Monero historic price (USD) to download?

See the accepted answer here:
https://opendata.stackexchange.com/questions/6884/cryptocurrency-historical-prices

You would have to slightly modify it to get XMR rather than ETH, and then get a BTC v. USD data set over the same time period and figure it out, but I'm not sure there is a better way.

There's really not much price history pre-poloniex, except smooth's OTC thread on bitcointalk and TheKoziTwo's short-lived cryptonote exchange.


Is there any way to force someone to rescan their wallet?

Not that I know of, but failed transactions and reorgs can get the wallet's idea of what outputs are spent to get out of sync with the blockchain. This does not require a rescan of the blockchain (just rescan_spent is enough, and it is a lot faster), but it is not widely known, and some people tend to go for the nuclear option first (rescan_spent also did not exist until a few months ago).

This out of sync problem is fixed in the rct branch, too.


How do I move the Monero blockchain files safely?

First of all, make sure your daemon (monerod) is stopped. Then navigate to

C:\ProgramData\bitmonero (ProgramData is a hidden folder)

and copy the contents to a folder on your D drive, e.g. D:\monero\blockchain. After that you can start your GUI wallet but be carefull not to start the daemon automatically. Say no and navigate to the advanced options for the daemon and specify custom startup settings (command line arguments). Put this there:

--data-dir D:\monero\blockchain (or the directory that you used)

After this start the daemon manually (there is a button) in the same window. Now check that the files in D:\monero\blockchain are updated (timestamp, growing filesizes) so you know it worked. After this you can delete the data in C:\ProgramData\bitmonero to free up space.


Where can I find the "help set" of commands with examples for the monero cli wallet?

Monero cli wallet output of the "help set" settings is below since its not found anywhere in cyberspace. Updated as of 2021-Jan-21.
Command usage:
  set <option> [<value>]

Command description:
  Available options:
   seed language
     Set the wallet's seed language.

   always-confirm-transfers <1|0>
     Whether to confirm unsplit txes.

   print-ring-members <1|0>
     Whether to print detailed information about ring members during confirmation.

   store-tx-info <1|0>
     Whether to store outgoing tx info (destination address, payment ID, tx secret key) for future reference.

   default-ring-size <n>
     Set the default ring size (obsolete).

   auto-refresh <1|0>
     Whether to automatically synchronize new blocks from the daemon.

   refresh-type <full|optimize-coinbase|no-coinbase|default>
     Set the wallet's refresh behaviour.

   priority [0|1|2|3|4]
     Set the fee to default/unimportant/normal/elevated/priority.

   confirm-missing-payment-id <1|0> (obsolete)
   ask-password <0|1|2   (or never|action|decrypt)>
     action: ask the password before many actions such as transfer, etc
     decrypt: same as action, but keeps the spend key encrypted in memory when not needed

   unit <monero|millinero|micronero|nanonero|piconero>
     Set the default monero (sub-)unit.

   min-outputs-count [n]
     Try to keep at least that many outputs of value at least min-outputs-value.

   min-outputs-value [n]
     Try to keep at least min-outputs-count outputs of at least that value.

   merge-destinations <1|0>
     Whether to merge multiple payments to the same destination address.

   confirm-backlog <1|0>
     Whether to warn if there is transaction backlog.

   confirm-backlog-threshold [n]
     Set a threshold for confirm-backlog to only warn if the transaction backlog is greater than n blocks.

   confirm-export-overwrite <1|0>
     Whether to warn if the file to be exported already exists.

   refresh-from-block-height [n]
     Set the height before which to ignore blocks.

   auto-low-priority <1|0>
     Whether to automatically use the low priority fee level when it's safe to do so.

   segregate-pre-fork-outputs <1|0>
     Set this if you intend to spend outputs on both Monero AND a key reusing fork.

   key-reuse-mitigation2 <1|0>
     Set this if you are not sure whether you will spend on a key reusing Monero fork later.

   subaddress-lookahead <major>:<minor>
     Set the lookahead sizes for the subaddress hash table.

   segregation-height <n>
     Set to the height of a key reusing fork you want to use, 0 to use default.

   ignore-fractional-outputs <1|0>
     Whether to ignore fractional outputs that result in net loss when spending due to fee.

   ignore-outputs-above <amount>
     Ignore outputs of amount above this threshold when spending. Value 0 is translated to the maximum value (18 million) which disables this filter.

   ignore-outputs-below <amount>
     Ignore outputs of amount below this threshold when spending.

   track-uses <1|0>
     Whether to keep track of owned outputs uses.

   setup-background-mining <1|0>
     Whether to enable background mining. Set this to support the network and to get a chance to receive new monero.

   device-name <device_name[:device_spec]>
     Device name for hardware wallet.

   export-format <"binary"|"ascii">
     Save all exported files as binary (cannot be copied and pasted) or ascii (can be).

   persistent-rpc-client-id <1|0>
     Whether to keep using the same client id for RPC payment over wallet restarts.

   auto-mine-for-rpc-payment-threshold <float>
     Whether to automatically start mining for RPC payment if the daemon requires it.

   credits-target <unsigned int>
    The RPC payment credits balance to target (0 for default).

   inactivity-lock-timeout <unsigned int>
     How many seconds to wait before locking the wallet (0 to disable).


(The Janus attack referred to in this question is documented here: https://web.getmonero.org/2019/10/18/subaddress-janus.html)

We were looking for a character from Greek mythology that had multiple identities. This is because the Janus attack allows an incoming transaction to appear to be addressed to one wallet subaddress, while having actually been addressed to a different wallet subaddress during transaction construction. Sarang Noether of the Monero Research Lab suggested Janus, who was a "two-faced god".
No, they can only attempt to trick the recipient into revealing control of two different subaddresses.
The link at the top of this answer documents the elliptic curve algebra. In plain English, the subaddress system is designed to allow a wallet to efficiently scan for incoming outputs to multiple subaddresses within the same wallet (i.e. where the subaddresses share the same private view key). A side-effect of the way in which the subaddress system was designed to allow this efficient scanning is that the wallet will trust the sender to inform the wallet of the particular destination subaddress. This trust was an oversight during the design of the subaddress system.
Yes, there are several ways to mitigate it, but these have not been decided upon yet. One way is for an update to the transaction construction to include a signature that proves the transaction was properly constructed for a particular subaddress destination. Since this modification will add perhaps 64 bytes to the size of a transaction, there will be careful consideration of a mitigation to ensure it is done in the most space-efficient way possible.


Why is there a fee to import old transactions when using mymonero web wallet?

Re-scanning the blockchain from 0 consumes server resources and takes time. The fee is there to discourage this use case, but providing the utility if it's really required for some users.

If a new wallet is generated, the server doesn't need to re-scan the blockchain as it knows that the wallet has not been used before.


As far as I know there are currently no faucets available for Monero. If I recall correctly though, MoneroDice is going to implmenent one in the foreseeable future.

Alternatively, if you want some spare change to play around with, people on IRC will generally give you some (there's a tipbot in #monero). The channel is #monero on freenode. To join this channel, simply connect to the freenode server in your client and join #monero. If you don't have a client, you can use this. Pick a nickname and set the channel to #monero.


How does the recent patched key image exploit work in practice?

Looks like it was being exploited on Bytecoin

For example, these 2 transactions spend the output 26e8958fc2b227b045c3f489f2ef98f0d5dfac05d3c63339b13802886d53fc05 twice!

http://chainradar.com/bcn/transaction/cef289d7fab6e35ac123db8a3f06f7675b48067e0dff185c72b140845b8b3b23

http://chainradar.com/bcn/transaction/7e418cc77935cc349f007cd5409d2b6908e4130321fa6f97ee0fee64b000ff85

Notice how the key image differs only in last 2 digits! That's because it's forged - ie 2 slighthly different key images for 1 output, allowing you to spend it twice by tricking the pre-patch node into thinking that both key images are valid for the given output. There can really be only 1 which can be checked only with a patched node, and one of those TX-es would become invalid.

Note that it's later patched in the code, but the patch applies only after Bytecoin block 1267000, so those double-spend transactions are still in the Bytecoin blockchain and have artificially inflated the supply.

Note that while I was writing this, there were some problems with chainradar block explorer and those transactions disappeared for a while! That doesn't mean that they're not in the blockchain (really, the only way to be sure is to run a Bytecoin node and check yourself if they're still there), but only that chainradar was not showing them (seem to be back now).
Just in case, they can also be seen here:

https://minergate.com/blockchain/bcn/transaction/cef289d7fab6e35ac123db8a3f06f7675b48067e0dff185c72b140845b8b3b23

https://minergate.com/blockchain/bcn/transaction/7e418cc77935cc349f007cd5409d2b6908e4130321fa6f97ee0fee64b000ff85


You need to install OpenSSL v1.1.x, a requirement it seems now in Monero v17.2.0.


Monero wallet not working with Ledger on Mac High Sierra (was working previously)

The predominant reason for a properly working Ledger & Monero setup to stop working is that the USB cable is either broken or slightly damaged (and therefore unable to function properly). Fortunately, this particular issue is easily resolved by buying a new USB cable. Alternatively, it could be that the USB port is not functioning properly anymore. You can easily check whether this is the culprit of your issue by using a different USB port.


Questions about tx_description field in URI

A monero: URI is not a transaction, it is a descriptor for how to create a transaction with some particular parameters.

The description is not stored in the blockchain. Of course, some software might decide to put this in a transaction, but that's on it.

It is not encrypted.

There is no defined maximum length, but some parsers might have limits.


Could Monero implement zk-SNARKS in the future?

Riccardo has mentioned that zk-SNARKs could be used in temporary sidechains. There is no official plan laid out yet to my knowledge.


Creating a wallet in non-interactive mode using monero-wallet-cli?

Looks like you can't provide all arguments in the command, but you can pass them via stdin, and "simulate" the interactive process.

If you use ./monero-wallet-cli --generate-from-spend-key walletName
The cli will ask you for the following arguments in this order:

private-spend-key
wallet-password (twice)
seed-language
blockchain-height-to-restore-from

You can create a file will all these arguments, each on a new line and tell the cli to read input from this file:

$ cat commands
8106ca36c4206caba03b463e42ba7bf87fd212789c719fd180666d0d9bec230b
myPassword
myPassword
1
0

Create wallet:

./monero-wallet-cli --generate-from-spend-key walletName < commands


Do private remote nodes save any wallet related data to disk?

No. The only "related" data is the blockchain.


Outputs on xmrchain.net show that I have a balance but command line says no balance

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

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

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

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

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

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

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

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