Remotely connect to my full node with a Jaxx mobile wallet?

I think initially you will not have a choice of node, but that's more of a question you should ask directly to jaxx. As the wallet is not out yet, we cannot look at it and tell you. Only Jaxx can tell you for sure at this point.

Being able to select your node would be a very important option on their wallet for us so I suggest we campaign for that.


Where can I find the selection of the decoys (stealthy addresses) when constructing a transaction?

The fake outputs are selected by the wallet in the wallet2::get_outs function, in src/wallet/wallet2.cpp.

https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp, currently starting at line 6411.


Mining intermittently throughout the day

at that hash rate even running 24/7 you'll be lucky to make .5 coins in a year depending on your pool

if you're just having fun testing then go ahead

if you actually want to make coin you need a lot more hashing power - try adding at least one GPU

there should be no issue leaving your CPU (and GPU) running 24/7 running as long as you have enough cooling and airflow


Is using a remote node more private than using Electrum on Tails

When using Tails (so Tor for your internet traffic) it is "safer", from an IP tracking perspective, than using clearnet. From an IP tracking perspective there is really no difference in safety between using an SPV wallet such as Electrum or the Monero wallets with a remote node, they both work in a similar fashion and what you are doing by using Tails (so Tor) is trying to make tracking your internet traffic difficult. Of course, using Monero instead of Bitcoin has significant privacy advantages.

So in summation, yes, using a remote node (Monero) is more private than using Electrum (Bitcoin), because Monero uses stealth addresses (so hides your address) and hides the amounts (Confidential Transactions). Using via tor/i2p adds further privacy by hiding your IP address (whichever you use, Monero or Bitcoin).


How do I connect an AppVM running the CLI to a separate AppVM running monerod in Qubes?

You need to setup your firewall to allow connections between the two VMs.

Run this on startup (some script linked from /rw/config/rc.local):

/usr/sbin/iptables -I INPUT 5 -p tcp --dport 18081 -m conntrack --ctstate new -j ACCEPT

This allows incoming RPC calls.

In the firewall VM, allow the two VMs to talk to each other (again, from /rw/config/rc.local):

/usr/bin/iptables -I FORWARD 2 -s a.b.c.d -d e.f.g.h -j ACCEPT

/usr/bin/iptables -I FORWARD 2 -s e.f.g.h -d a.b.c.d -j ACCEPT

Rule numbers kinda arbitrary here, especially for your setup.


Creating multiple XMR addresses in a single XMR GUI wallet

Subaddresses have now been merged but not yet included in a tagged release. If you build from master, you can use them with the CLI now.

GUI support is still being worked on. Anyone with Qt experienced is encouraged to help!

Depending on your reason for wanting to use more than one address, the account command may be a helpful option for you.


Monero inception and history. How did monero get started, what are its origins and which are important historical events of its development?

This is an edited version of the excellent investigation of the bytecoin scam performed by user "rethink-your-strategy" on the bitcointalk forums written August 15, 2014. It is the best available account of the bytecoin scam, and covers the following areas from the original question:

  the original cryptonote developers, and the veil of secrecy around them + the bytecoin pre-mine.

  the creation of bitmonero, about which I don't know much, really

  community taking over and bitmonero became monero
  attack on the network, as documented by relevant MRL paper

It has been edited due to the (entertaining) vulgarity of the original report and to fit in the 30k character limit of answers.

The Alleged CryptoNote/Bytecoin Story

CryptoNote is a new cryptocurrency protocol. It builds on some of the Bitcoin founding principles, but it adds to them. There are aspects of it that are truly well thought through and, in a sense, quite revolutionary. CryptoNote claim to have started working on their project years ago after Bitcoin's release, and I do not doubt the validity of this claim...clearly there's a lot of work and effort that went into this. The story as Bytecoin and CryptoNote claim it to be is as follows:

They developed the code for the principles expressed in their whitepaper, and in April, 2012, they released Bytecoin. All of the copyright messages in Bytecoin's code are "copyright the CryptoNote Developers", so clearly they are one and the same as the Bytecoin developers. In December 2012, they released their CryptoNote v1 whitepaper. In September 2013, they released their CryptoNote v2 whitepaper. In November 2013, the first piece of the Bytecoin code was first pushed to Github by "amjuarez", with a "Copyright (c) 2013 amjuarez" copyright notice. This was changed to "Copyright (c) 2013 Antonio Juarez" on March 3rd, 2014. By this juncture only the crypto libraries had been pushed up to github. Then, on March 4th, 2014, "amjuarez" pushed the rest of the code up to github, with the README strangely referring to "cybernote", even though the code referred to "Cryptonote". The copyrights all pointed to "the Cryptonote developers", and the "Antonio Juarez" copyright and license file was removed. Within a few days, "DStrange" stumbled across the bytecoin.org website when trying to mine on the bte.minefor.co.in pool (a pool for the-other-Bytecoin, BTE, not the-new-Bytecoin, BCN), and the rest is history as we know it. By this time Bytecoin had had a little over 80% of its total emission mined.

Immediate Red Flags

The first thing that is a red flag in all of this is that nobody, and I mean no--body, is a known entity. "Antonio Juarez" is not a known entity, "DStrange" is not a known entity, none of the made up names on the Bytecoin website exist (they've since removed their "team" page, see below), none of the made up names on the CryptoNote website exist (Johannes Meier, Maurice Planck, Max Jameson, Brandon Hawking, Catherine Erwin, Albert Werner, Marec Plíškov). If they're pseudonyms, then say so. If they're real names, then who are they??? Cryptographers, mathematicians, and computer scientists are well known - they have published papers or at least have commented on articles of interest. Many of them have their own github repos and Twitter feeds, and are a presence in the cryptocurrency community.

The other immediate red flag is that nobody, and I mean no--body, had heard of Bytecoin. Those that had heard of it thought it was the crummy SHA-256 Bitcoin clone that was a flop in the market. Bytecoin's claim that it had existed "on the deep web" for 2 years was not well received, because not a single vendor, user, miner, drug addict, drug seller, porn broker, fake ID card manufacturer, student who bought a fake ID card to get into bars, libertarian, libertard, cryptographer, Tor developer, Freenet developer, i2p developer, pedophile, or anyone else that is a known person - even just known on the Internet - had ever encountered "Bytecoin" on Tor. Ever. Nobody.

Indisputable Facts

Before I start with some conjecture and educated guesswork, I'd like to focus on an indisputable fact that obliterates any trust in both Bytecoin's and CryptoNote's bullshit story. Note, again, that I do not doubt the efficacy of the mathematics and cryptography behind CryptoNote, nor do I think there are backdoors in the code. What I do know for a fact is that the people behind CryptoNote and Bytecoin have actively deceived the Bitcoin and cryptocurrency community, and that makes them untrustworthy now and in the future. If you believe in the fundamentals in CryptoNote, then you need simply use a CryptoNote-derived cryptocurrency that is demonstrably independent of CryptoNote and Bytecoin's influence. Don't worry, I go into this a little later.

So as discussed, there were these two whitepapers that I linked to earlier. Just in case they try remove them, here is the v1 whitepaper and the v2 whitepaper mirrored on Archive.org. This v1/v2 whitepaper thing has been discussed at length on the Bytecoin forum thread, and the PGP signature on the files has been confirmed as being valid. When you open the respective PDFs you'll notice the valid signatures in them:

signature in the v1 whitepaper

signature in the v2 whitepaper

These are valid Adobe signatures, signed on 15/12/2012 and 17/10/2013 respectively. Here's where it gets interesting. When we inspect this file in Adobe Acrobat we get a little more information on the signature:

Notice the bit that says "Signing time is from the clock on the signer's computer"? Now normally you would use a Timestamp Authority (TSA) to validate your system time. There are enough public, free, RFC 3161 compatible TSAs that this is not a difficult thing. CryptoNote chose not do this. But we have no reason to doubt the time on the signature, right guys? crickets

See these references from the v1 whitepaper footnotes? Those two also appear in the v2 whitepaper. Neither of those two footnotes refer to anything in the main body of the v1 whitepaper's text, they're non-existent (in the v2 whitepaper they are used in text). The problem, though, is that the Bitcointalk post linked in the footnote is not from early 2012.

May 5, 2013. The footnote is referencing a post that did not exist until then. And yet we are to believe that the whitepaper was signed on 12/12/2012! What sort of  fools do they take us for?

A little bit of extra digging validates this further. The document properties for both the v1 whitepaper as well as the v2 whitepaper confirms they were made in TeX Live 2013, which did not exist on 12/12/2012. The XMP properties are also quite revealing:

XMP properties for the v1 whitepaper

XMP properties for the v2 whitepaper

According to that, the v1 whitepaper PDF was created on 10/04/2014, and the v2 whitepaper was created on 13/03/2014. And yet both of these documents were then modified in the past (when they were signed). Clearly the CryptoNote/Bytecoin developers are so advanced they also have a time machine, right?

Final confirmation that these creation dates are correct are revealed those XMP properties. The properties on both documents confirm that the PDF itself was generated from the LaTeX source using pdfTeX-1.40.14 (the pdf:Producer property). Now pdfTeX is a very old piece of software that isn't updated very often, so the minor version (the .14 part) is important.

pdfTeX 1.40.14 pushed to source repo on Feb 14, 2014

This version of pdfTeX was only pushed to the pdfTeX source repository on February 14, 2014, although it was included in a very early version of TeX Live 2013 (version 2013.20130523-1) that was released on May 23, 2013. The earliest mentions on the Internet of this version of pdfTeX are in two Stack Exchange comments that confirm its general availability at the end of May 2013 (here and here).

The conclusion we draw from this is that the CryptoNote developers, as clever as they were, intentionally deceived everyone into believing that the CryptoNote whitepapers were signed in 2012 and 2013, when the reality is that the v2 whitepaper was created in March, 2014, and the v1 whitepaper haphazardly created a month later by stripping bits out of the v2 whitepaper (accidentally leaving dead footnotes in).

Why would they create this fake v2 whitepaper in the first place? Why not just create a v1 whitepaper, or not even version it at all? The answer is simple: they wanted to lend credence and validity to the Bytecoin "2 years on the darkweb" claim so that everyone involved in CryptoNote and Bytecoin could profit from the 2 year fake mine of 82% of Bytecoin. What they didn't expect is the market to say "no thank you" to their premine scam.

And Now for Some Conjecture

As I mentioned earlier, the Bytecoin "team" page disappeared. I know it exists, because "AtomicDoge" referred to it as saying that one of the Bytecoin developers is a professor at Princeton. I called them out on it, and within a week the page had disappeared.  cowards.

That was the event that triggered my desire to dig deeper and uncover the scam. As I discovered more and more oddities, fake accounts, trolling, and outright falsehoods, I wondered how deep the rabbit hole went. My starting point was DStrange. This is the account on Bitcointalk that "discovered" Bytecoin accidentally a mere 6 days after the first working iteration of the code was pushed to Github, purely by chance when mining a nearly dead currency on a tiny and virtually unheard of mining pool. He has subsequently appointed himself the representative of Bytecoin, or something similar.

At the same time as DStrange made his "accidental discovery", another Bitcointalk account flared up to also "accidentally discover this weird thing that has randomly been discovered": Rias. What's interesting about both the "Rias" and "DStrange" accounts are their late 2013 creation date (October 31, 2013, and December 23, 2013, respectively), and yet they lay dormant until suddenly, out of the blue, on January 20th/21st they started posting. If you look at their early posts side by side you can even see the clustering: Rias, DStrange.

At any rate, the DStrange account "discovering" Bytecoin is beyond hilarious, especially with the Rias account chiming in to make the discovery seem natural. Knowing what we unmistakably do about the fake CryptoNote PDF dates lets us see this in a whole new light.

Of course, as has been pointed out before, the Bytecoin website did not exist in its "discovered" form until sometime between November 13, 2013 (when it was last captured as this random picture of a college girl) and February 25, 2014 (when it suddenly had the website on it as "discovered"). This can be confirmed by looking at the captures on Wayback Machine: https://web.archive.org/web/*/http://bytecoin.org

The CryptoNote website, too, did not exist in its current form until after October 20, 2013, at which time it was still the home of an encrypted message project by Alain Meier, a founding member of the Stanford Bitcoin Group and co-founder of BlockScore. This, too, can be confirmed on Wayback Machine: https://web.archive.org/web/*/http://cryptonote.org

~~ It's hard to ascertain whether Alain had anything to do with CryptoNote or Bytecoin. It's certainly conceivable that the whitepaper was put together by him and other members of the Stanford Bitcoin Group, and the timeline fits, given that the group only formed around March 2013. More info on the people in the group can be found on their site, and determining if they played a role is something you can do in your own time.~~

Update: Alain Meier posted in this thread, and followed it up with a Tweet, confirming that he has nothing to do with CryptoNote and all the related...stuff.

Batshit Insane

The Bytecoin guys revel in creating and using sockpuppet accounts. Remember that conversation where "Rias" asked who would put v1 on a whitepaper with no v2 out, and AlexGR said "a forward looking individual"? The conversation took place on May 30, and was repeated verbatim by shill accounts on Reddit on August 4 (also, screenshot in case they take it down).

Those two obvious sockpuppet/shill accounts also take delight in bashing Monero in the Monero sub-reddit (here are snippets from WhiteDynomite and cheri0). Literally the only thing these sockpuppets do, day in and day out, is make the Bytecoin sub-reddit look like it's trafficked, and spew angry bullshit all over the Monero sub-reddit.  Clearly they're pissy that nobody has fallen for their scam. Oh, and did I mention that all of these sockpuppets have a late January/early February creation date? Because that's not  obvious at all.

And let's not forget that most recently the sockpuppets claimed that multi-sig is "a new revolutionary technology, it was discovered a short time ago and Bytecoin already implemented it". If you think that's bad, you're missing out on the best part of all: the Bytecoin shills claim that Bytecoin is actually Satoshi Nakamoto's work. I'm not  kidding you. For your viewing pleasure...I present to you...the Bytecoin Batshit Insane Circus:

Seriously. Not only is this insulting to Satoshi Nakamoto, but it's insulting to our intelligence. And yet the fun doesn't stop there, folks! I present to you...the centerpiece of this Bytecoin Batshit Insane Circus exhibit...

Of course! How could we have missed it! The clues were there all along! The CryptoNote/Bytecoin developers are actually aliens!

One last thing: without doing too much language analysis (which is mostly supposition and bullshit), it's easy to see common grammar and spelling errors. My personal favorite is the "Is it true?" question. You can see it in the Bytecoin thread asking if it's Satoshi's second project, in the Monero thread asking if the Monero devs use a botnet to fake demand, and in the Dashcoin thread confirming the donation address.


You are mining in a pool when you are running a pool miner. If you mine directly from the daemon or wallet, you are solo mining, not pool mining.

Solo mining, which is your case, means you will take a long time to find a block. However, when you do find one, you will get to keep the entire block reward (currently about 8 monero, I believe) instead of it being distributed among all pool miners and getting a pittance.

Note that solo mining is done by the deamon. Starting mining in the wallet merely instructs the daemon to do so. If you want to double check you are actually mining, run status in the daemon itself. If you restart the daemon, mining will be automatically off on restart, for instance, though you would not have told the wallet to stop mining.


Can I confirm that someone payed me only by transaction ID?

(Most common) You could give out a unique payment ID to the buyer. This is easily done using an integrated address, which automatically instructs the buyer's wallet to use that particular payment ID. You'd then wait for an incoming payment that specifies that payment ID. This is easiest for a seller, because they don't have to chase the buyer later to ask for additional information.
You could ask the buyer to use a random payment ID and tell you what it was.
You could ask the buyer to tell you the transaction ID after they've made payment.


Dandelion works by setting a flag in the transaction message. If the flag is set, nodes should perform the dandelion steps (ie, decide whether to continue dandelion routing or send to all peers), otherwise not. The existing transaction message format is unchanged.
An old node will not know of that flag, so will understand that message as it used to, and will proceed to send that transaction to all its peers as usual.
This means that if Dandelion supporting nodes are few and far between, the network as a whole will behave much like previously: most txes will get relayed to all peers in short order. Only when most nodes support Dandelion will the effectiveness of Dandelion reach its peak. However, in all cases it will "just work".


How do I use long payment IDs in CLI v0.14 / GUI v0.14?

We're slowly trying to phase out long payment IDs, because they are (i) detrimental to user experience and (ii) privacy. Therefore, in CLI & GUI v0.14, it will be more difficult to make use of a long payment ID. You can, however, still use them (although, please ask your service to phase them out too). This is done as follows:

In case you are using the GUI:

Go to the Settings page of the GUI.
Go to the Layout tab.
Check the Enable transfer with payment ID (OBSOLETE) box.

You should now be able to utilize long payment IDs (thanks to sgp for the image!).

In case you are using the CLI:

Basically you have to launch the CLI with the --long-payment-id-support flag. This is done as follows:

Windows:

Close monero-wallet-cli.exe by typing exit
Make sure you are in the folder where monero-wallet-cli.exe is located.
Make sure your cursor is not on any of the files.
Right click, an option to open the command prompt should appear.
Now type -> monero-wallet-cli.exe --long-payment-id-support

Linux:

Close monero-wallet-cli by typing exit
Make sure you are in the folder where monero-wallet-cli is located.
Make sure your cursor is not on any of the files.
Right click, an option to open the terminal should appear.
Now type -> ./monero-wallet-cli --long-payment-id-support

Mac OS X

Close monero-wallet-cli by typing exit
Check in which directory monero-wallet-cli v0.14 is located. An easy way of finding the full path of monero-wallet-cli is as follows (source):

  If you really want the full path to a file in a copyable form, you can drag and drop the file or its proxy icon onto a Terminal window. From there, you can then copy and paste it.

Thus, drag and subsequently drop monero-wallet-cli in the terminal and you should see its full path.

Go to your desktop.
Open a new terminal (if don't know how to open a terminal, see here).
Now type -> cd full/path/to/monero-wallet-cli/directory
For example, if monero-wallet-cli is located in say ~/Applications/Monero, type:

cd ~/Applications/Monero
Once the terminal is in the right directory (note that you can type ls -a to get a list of all files in the directory. If the list includes monero-wallet-cli, you are in the right directory).

./monero-wallet-cli --long-payment-id-support


Monero blockchain explorer compilation not working ubuntu 16.04

From the readme:

# altearnatively can use: cmake -DMONERO_DIR=/path/to/monero_folder ..

Note the .. at the end.

This is also assuming you have followed all the preceding instructions (including changing directories):

git clone https://github.com/moneroexamples/onion-monero-blockchain-explorer.git

# enter the downloaded sourced code folder
cd onion-monero-blockchain-explorer

# make a build folder and enter it
mkdir build && cd build


How to install CryptoNote-Lite pool mining software on macOS?

I know it's been a while since you asked this, but in case anyone else is wondering, you can easily install xmrig on MacOS by following the build instructions on Github.

First you need to install Xcode from the App Store, and then you have to install Homebrew.

Once you have those dependencies, you need to run the commands given on the xmrig OS X Build instructions page (from a Terminal window):

brew install cmake libuv
git clone https://github.com/xmrig/xmrig.git
cd xmrig
mkdir build
cd build
cmake ..
make

Once the compile process finishes successfully, there will be a binary executable in the build directory named xmrig.  You can verify that it is there by running this command in the build directory:

ls -lah | grep xmrig

Run xmrig in OS X the same way you would in Linux.  From the build directory, run the following command (I've included my preferred pool... feel free to replace it with whatever you use):

./xmrig -a cryptonight-lite -o "mine.aeon-pool.com:3333" - u YOUR_WALLET_ADDRESS -p x

You can optionally specify a donation level. By default, xmrig donates 5% of your mining time to the developer, but you can set it as low as 1%, depending on your generosity preferences.

Note: If you have a good CPU (hashrates over 300 H/s), you might want to mine on port 5555 instead of 3333, since it will start you at a higher difficulty (better earnings). Check your pool's "Getting Started" page for more details about what port numbers and difficulties are available.


For newcomers to the Monero community, what can we do to help the project?

Documenting (helping here on stack exchange is actually quite helpful, but helping to write tutorials to do stuff is also useful)
Testing (know how to compile some code? then it helps for others to test out builds, or run software on various version so catch any errors that sliup through)
Donations (not just to monero devs, but also for bounties in the forum funding section, or if theres a feature you're passionate about, you could get it posted)
Run a node (secure the network, help keep Monero decentralised, it's simple to do, and only requires some bandwidth)
Mine (it's still possible to mine, even on a cpu, it you have some spare hardware, you are actively adding to it's decentralisation)
If you have an IT or CS background and can code, go to #monero-dev on freenode and ask around to see if anything needs doing, or simply go to the official repo and see what issues need help.


How secure is connecting the monero wallet via SSH tunneling to a self run remote server?

The wallet password is never transmitted. Tunneling through ssh should be safe, assuming you have a good ssh key.


How vulnerable is Monero to Quantum Computing?

From Monero developer Smooth:

  “Yes it would be more vulnerable (with regard to public keys) but the protection it affords if uncertain and fragile. If QC can crack keys "slowly" then you can safely move coins from an address that hasn't been spent before to a new quantum-resistant output (assuming such a thing is implemented). But if QC can crack keys "quickly" (before any spend attempt is deeply buried in the blockchain) then any attempt becomes a race to securely move your coins before an attacker can steal them. I doubt Bitcoin would survive the latter.”

Source: Reddit

From Monero developer/researcher (Monero Research Lab) NobleSir:

  “Once the current round of improvements is finished (apps/ guis/multisig/etc) the attention will likely move to quantum secure, and hopefully by then there will be more signature implementations available to choose from. Hopefully a Bernstein type will have coded the new ref for quantum. Note that a lot of the necessary math (i.e. ring sigs / one time keys) has been studied already in the literature.”

Source: Reddit

One possible replacement for more conventional schemes like RSA and ECDSA is Sphincs. See: https://github.com/jedisct1/libsodium/issues/371


Since Monero moved to LMDB in January, RAM requirements are now quite low. It is possible to run a full node with 1GB of RAM
The amount of hard drive space needed will vary by OS. I have not yet seen a blockchain over 20GB. The blockchain continues to grow, but pruning options (such as provided by Aeon a Monero fork) will likely become available eventually
A SSD is not required but will significantly decrease sync time. Depending on your setup sync time for the entire blockchain can vary between 10 minutes (on powerful systems) to several days. The current master in GitHub has LMDB improvements over the tagged release.
Yes, multiple users have been running Monero on Raspberry Pi for over a year at this point: https://forum.getmonero.org/20/general-discussion/267/a-step-by-step-guide-to-running-a-full-node-on-raspberry-pi-2


I sent a transaction and it gave me an error then went through

I guess this could happen if your transaction got into a block that was lost due to a chain reorg.


How is monero different from byteball with being anonymous?

Monero is private by default with published academic research analyzing RingCT and funded PhDs that continue to review and improve upon Monero privacy and security.
Byteball is public by default with claims of optional privacy via "Blackbytes" which AFAIK has received no scrutiny from academics.
According to their wiki

Blackbytes are defined as a private asset, meaning its never posted to the public Byteball database, it is ever only transferred when Byteball wallets have paired, private assets are sent encrypted through the Byteball network from device address to device address.
If blackbytes are traded on a centralized exchange, the exchange would have enough information to reveal the origin and destination of blackbytes, and amounts traded, which defeats their purpose.
Blackbytes hence can only be traded on decentralized exchanges, with conditional payments in the Byteball wallet. Peer discovery has to happen outside the Byteball wallet. Such an exchange is yet to appear (2017-May).

Monero is traded on many exchanges with all transactions private by default. Just like Byteball, Monero can optionally be used with Tor. Meanwhile Kovri development continues with plans for an eventual native Monero integration


Would having two separate proof of work algorithms for Monero be more secure?

To evaluate whether one alternative is more secure than the other we have to answer the question: Which alternative makes an attack more costly?

In the Cryptonight-only case the cost of an attack is that of gaining a 51% advantage over all mining nodes on the network.

In the Cryptonight+ASIC case you'd need to get some combination of regular miners and ASIC miners.

It gets a little "handwavy" at this point, because a true estimate would be impossible.  But by definition an ASIC can only be used for mining, whereas a general purpose computer can be used for mining or other things.  Therefore, it stands to reason that the capital investment in the general computer category will be much larger than the capital investment into ASICs.

Another way to think about this is that the general purpose computer has mining value + entertainment value + productivity value + ..., whereas the ASIC only has the mining value.  Because of this regular users are willing to spend more to pay for a 'miner', whereas an attacker isn't, as he's only motivated by profit.

Furthermore, enthusiasts might mine at a loss (they want to secure the network and the computer is otherwise idle) with their general computer, but nobody is going to buy an ASIC (and pay for power) to run it at a loss.

For these reasons I think the capital investment required to attack a mining algorithm targeting a general purpose compute node will always be greater than a mining algorithm targeting ASICs only, or some combination of ASICs and general purpose compute nodes.


There are several possible reasons for this:

your are being consistently lucky and finding more shares that you'd expect
you have another computer mining to the same address, which you forgot
you're mining to a public address (eg, an exchange), and someone else is also mining to that address
the pool's buggy

As Steve Pazitka said, the pool can only infer your hash rate by looking at the timing and difficulty of the shares you submit, so reported hash rate typically varies with a long term average being at your actual hash rate, or maybe a bit lower due to network overheads.


Difficulty in integrating and supporting Monero

Yes, there are further reasons.

For instance, Monero RPC does not have equivalents of events for new block or transaction received. This means one has to poll (though this is not overly complicated, see eg https://github.com/tippero/python-monero/ for an example).

There is also the fact that the node and wallet are separate binaries. Also, RPC is unauthenticated and unencrypted. This may be a problem if some are already using RPC across machines (not recommended, but still).

Last, there are some bits and pieces that could be better, like this or that RPC could be returning also this bit of info, or in this format, etc. These are the things that become apparent with usage. Some are fixed already, and more will be fixed as feedback is made.

All of these (or pretty much all of them, I think) will be fixed once the 0MQ branch is merged.

In the past, the main issue was the inordinate RAM usage, but this got fixed by the switch to LMDB.


It looks like the daemons claiming to be 79 days behind have found a peer (or peers) which are running a modified version of the monero stagenet protocol, and are therefore unable to sync. They'll only be able to once they find a peer on the correct chain.

Alternatively, it might be a monero fork (since the P2P comms appear to be compatible) and they incompetently failed to modify the network ID.

To try to get out of this mess, you can try manually banning those peers that claim v9:

ban 1.2.3.4

The IPs are in the messages.

One thing isnot clear: what makes you think some of the logs are not real ?


Difference between --rpc-bind-ip 0.0.0.0, or loopback, or actual IP

This is a basic networking question, not specific to Monero.

0.0.0.0 means "any address" - it will bind to every network interface on the machine. So it will listen to requests from anywhere.

Using a specific address means it will only bind to that single address.

Using 127.0.0.1 is the loopback address, so it will only listen to requests originating on the same machine.


How to do MLSAG signatures with vin of type 0 (miner)?

There is no MLSAG signature on tx type gen.


Im not an expert about miners, but taking a quick look to xmrminer in github site, its says that its a CUDA-based miner for xmr. CUDA is the platform used by Nvidia cards, so dont expect it to work properly with your Rx.

Being said that, you have plenty of options about choosing a proper miner.

Do you have only amd or mixed amd-nvidia cards? you can try the new xmr-stak which will recognize both platforms (CUDA for Nvidia and Opencl for amd).
https://github.com/fireice-uk/xmr-stak/releases
If you are willing to try it, i recomend you to try both 2.0 and 2.1 releases, and use the one which gives you better results.

Also, there is claymore cryptonote miner, xmr-stak-amd, and others, but i think those are the most popular.

If you are using windows and will try the new xmr-stak, and dont want to use CPU for mining, make a batch file "xmr-stak.exe --noCPU". I hope this helps. Kind regards...


Win10 64-bit - Wallet not restored after upgrade to 0.11.0 Hydra GUI

Restored two wallets associated with the GUI on my PC. $XMR was in the second. Upgrade to 0.11.0 seemed to have defaulted a previously unused wallet.


Can a One-Time public key be used for more than one payment?

However, could a one-time public key receive Monero more than once (as in thousands of times)

Yes, but it is certainly not practical. There are basically two reasons as two why. First, sending Monero to the same one-time public key (stealth address) will be detrimental to unlinkability, i.e., it will create linkability between payments. In addition, sending to the same stealth address is basically similar to a stealth address collision. From Luigi1111's article:

  The chance of a collision (two stealth addresses being the same) is cryptographically negligible. Using the Birthday Paradox we can roughly estimate it would take sqrt(l), or about 2^126, stealth addresses being created before having a 50% chance of a collision. The result would be that the colliding addresses become publicly linkable to each other, but not to any others.

Secondly, and this is even worse in my opinion, sending to the same stealth address will "burn" all outputs except one. More specifically, an output is accompanied by a key image (I = xHp(P)), where I = the key image, x = a private key, Hp = a hash to point function, and P = one-time public key. As you can see from aforementioned function, sending Monero to the same stealth address will result in multiple key images that are exactly the same. Note that the network will reject a key image if it's already present in the blockchain, because it will be seen as an attempt to double spend. Thus, you will only be able to spend from this stealth address once and the remainder of the outputs will be unspendable.

More practically speaking, let's say you sent 1 XMR twice to P1 and 2 XMR twice to P2. Subsequently, you create a transaction that combines P1 and P2 and broadcast it to the network. Now, if you want to create another transaction that again combines P1 and P2, it will be rejected by the network, because the key images are already present in the blockchain and it will be seen as a double spend attempt. Thus, effectively you burned 1+2 = 3 XMR by sending to the same stealth address.

Some more information:

What is a key image?

What are the "ingredients" of a key image?

Constructing a Stealth Monero Address?


Monero transaction from kraken to bitfinex stucks in status confidential transaction

If you sent to an address owned by someone else (Bitfinex), then you cannot use a wallet to recover the funds.  It is the responsibility of the address owner (the exchange, Bitfinex) to credit you with those funds, as long as you can prove that they were sent by you or on your behalf.


Why would a candidate transfer be sitting in the memory pool after 3 days?

I checked the 56c5e5f2a7f6ab97a0c589731278a7d4ef0516484cde1376e213b5b160af548b tx hash at each of the other block explorers mentioned in this answer with the following results:

Moneroblocks

  Uh-oh Shame on you! There is no such thing as 56c5e5f2a7f6ab97a0c589731278a7d4ef0516484cde1376e213b5b160af548b in Monero's blockchain!

Chain Radar

  Not Found (#404) Unable to resolve the request "xmr/search/ 56c5e5f2a7f6ab97a0c589731278a7d4ef0516484cde1376e213b5b160af548b".

Onion Monero Blockchain Explorer

  Search results for: 56c5e5f2a7f6ab97a0c589731278a7d4ef0516484cde1376e213b5b160af548b
  Nothing in the blockchain has been found that matches the search term :-(

Monero Explorer currently displays a message at the top of its screen

  Info! We are updating the site with new features, some function are temporarily disabled.

The payment ID contained in the tx hash you found has been used in over 2,000 transactions. These factors point to a possibility that this issue could be an error related to testing of the feature updates now being conducted by that particular block explorer.


Should Monero use ElGamal commitments instead of Pedersen commitments?

Let's first recap the concept of input and output spaces. In our Pedersen
commitments, we are perfectly hidden because the input space is larger than the
output space - we have a many-to-one relationship. For our binding, the spaces
are the same size, the relationship is one-to-one, so can only be
computationally bound. The inverse of these relationships flips the properties of the scheme. The way ElGamal commitments flip these properties is by
publishing an extra point in the commitment (so the commitment now consists of 2
points). As an example:

C1 = xG + aH
C2 = xH
C = (C1, C2)

Here, our input space is the tuple x,a (two 253 bit scalars) and our output space is the same size, a tuple of two points C1,C2 (two 253 bit points). This is guaranteed distinct because of the mapping of x to xH and the fact there can only be one input tuple that maps to a single output tuple. It is only computationally hidden because x can theoretically be extracted from C2 and then xG can be subtracted from C1 leaving aH, from which a can be theoretically extracted. Thus a is computationally hidden.

Importantly, it is perfectly bound because an
adversary cannot open a commitment to a different amount a to that which
was originally committed. Or in layman terms, change a, x will have to
change, verification of the original commitment fails. Or to put another way,
changing a or x, one cannot construct a matching commitment to that of the
original commitment. It's perfectly bound and computationally hidden.

So there is nothing stopping us switch to using perfectly bound and computationally hidden commitments. However, these come with a serious drawback,
size. In a Monero transaction, there are a lot of commitments (they are used
in both the ring signatures and range-proofs), and ElGamal commitments require
an extra 32 bytes each (the extra point). So given that both properties are
important to not be broken (the hiding of amounts and the binding of the
commitments), and that the computationally strength is considered sufficiently
strong for the foreseeable future (we are some way off being able to solve the
discrete logarithm problem), and that even when the DLP can be effectively
solved, there would be far more pressing problems to face. Therefore deciding on
whether to use computationally/perfectly hidden/bound commitments right now,
boils down to other factors, and in our case this is predominantly the size factor.

Therefore, it's fine for now to use either scheme, though preferable to use the smaller
of the two. By the time the DLP is solvable, and we have implemented a
replacement, all past Pedersen committed amounts will still remain hidden, but
there will have to be a new binding & hiding scheme to protect against hidden
inflation.  Which brings us to another subtle reason why the Pedersen
commitments (perfectly hiding and computationally binding) are preferable.
Assuming a replacement is found before the DLP is easily solvable, a migration
to a new hiding and binding scheme could be done such that the older, weakened,
bound commitments could be phased out (e.g. marked as untrusted from a certain
point in time) and only the newer scheme trusted for subsequent transactions.
Flipping the scenario, if we used computationally hidden and perfectly bound
commitments now, and the DLP assumption becomes broken, all past amounts would
become known with no migration plan possible that could be used to avert this.
And of course in the worst case scenario, of not having a replacement to the
broken DLP assumption (regardless of perfectly/computationally hidden/bound
commitments), there are far more problems than just Monero commitments!
Everyone's coins for any cryptocurrency could be stolen for one thing (e.g. it
would be possible to obtain the private wallet key for a given public wallet
key). SSH/PGP/SSL, all breakable. Thus, one can tend to assume we will have
alternative cryptographic schemes before the DLP is easily solvable - it's more
than just our silly [tic] cryptocurrencies that would be affected.

Hopefully these two posts have helped educate that the phrase "perfectly hiding
and computationally binding" is not some weakness in Monero, but rather refers
to specific properties of commitment schemes. No scheme can be both perfectly
binding and hiding and the computational strength is as strong as we rely on for
all other modern day cryptography applications.


Does change appear as an output in a transaction?

A transaction has inputs and outputs. All inputs must be spent.

So in your example of Alice wanting to send Bob 10 of her 15 XMR, assuming Alice has all her 15 XMR in 1 UTXO, she would have 1 input and 2 outputs. The 2 outputs would be a stealth address for Bob with a value of 10 XMR and a stealth address for Alice with a value of 5 (minus the tx fee) XMR.

Search for create_transaction in https://github.com/monero-project/monero/blob/master/src/wallet/wallet2.cpp to see code for how transactions are constructed.


Cloud storing wallet.keys encrypted files

Your wallet.keys file should be perfectly safe in the cloud as long as your passphrase to unlock it remains secure.

You are correct about the use of Chacha8 to protect the file.

As long as the file remains encrypted, wallet.keys will not leak any data. Renaming it should not be a problem, but to be safe I would keep a backup of the original file (prior to the name change) until you confirm the renamed file still opens properly with your passphrase.


Where can I learn about the cryptography used in Monero?

An excellent overview of most aspects of Monero (excluding subaddresses and bulletproofs) is here: https://github.com/kurtmagnus/Monero-RCT-report/blob/master/main.pdf

Learn about Elliptic Curve Cryptography here: https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-introduction

Learn about Monero's proof of work algorithm, stealth addresses and Monero's original ring signatures (LSAG) in the cryptonote white paper https://cryptonote.org/whitepaper.pdf

Learn about how confidential transactions hide transaction amounts (including what range proofs are) here: https://people.xiph.org/~greg/confidential_values.txt

Learn about blockchain transaction structures here: https://cryptonote.org/standards/

Learn about the MLSAG upgrade to Monero's ring signatures here: https://lab.getmonero.org/pubs/MRL-0005.pdf

Learn about Bulletproofs, which will be replacing Monero's existing range proofs, here: https://github.com/AdamISZ/from0k2bp/blob/master/testzkp.pdf and here: https://eprint.iacr.org/2017/1066.pdf

Learn about ring signatures in a more general sense here: http://diyhpl.us/~bryan/papers2/bitcoin/Borromean%20ring%20signatures.pdf

Learn about subaddresses here: https://lab.getmonero.org/pubs/MRL-0006.pdf

See all of the Monero Research Lab publications here: https://lab.getmonero.org/


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

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

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

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


What happens to XMR sent to an unexisting address? Is it sent back?

An 'unexisting address', probably due to a typo, would mean that there would be no known private keys corresponding to the address that funds were sent to. This should be protected against to some degree, because every Monero public address has an in-built checksum to help prevent typos. Since it's impossible to determine private keys from a Monero address, the private keys for this 'unexisting address' will never be able to be determined.

Funds can be sent to any valid address, and it's impossible for the sender or any observer to know the difference between an existing and an 'unexisting' valid address. If funds were sent to such an address, they would still show up on the blockchain as arriving at a fresh "one-time" address. Under normal circumstances, the owner of the destination Monero wallet address would then be able to scan for the presence of any such one-time addresses that are destined for them. They would then be able to determine the private keys necessary to take control of these funds destined for them, and spend the funds when desired.

However, since no such person would exist, the funds would just sit on the blockchain unspent. Since it's impossible to know when funds on the blockchain have been spent or not (due to Monero's privacy mechanisms), no one would know the funds are sitting there forever in limbo. It would not be possible for the sender to recall the transaction, since Monero transactions are irreversible.


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

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

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

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

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

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


How to know when I would get any profit by Monero mining program?

The current difficulty of the network is approximately 125 billion, meaning that on average you need to calculate 125 billion hashes to find a block. At 200 hashes per second, you can expect to find a block in 125,000,000,000 / 200 = 625 million seconds. That's 20 years.

Now of course you could get lucky and find a block on your first hash but the probability of that happening is extremely low.

You would probably be better off mining to a pool - if you find a pool with a minimum payment of 0.01 XMR, you could expect to receive 0.01 XMR in about 15 days (your difficulty for that payment will be 125 billion x 0.01 XMR / 5.15 XMR, where 5.15 is the average current block reward).


From the XWallet website:

  Recovery
  A standard 25 word mnemonic format means you can recover directly into the Monero reference client.

So just download the official Monero client (GUI or CLI), sync the blockchain and recover wallet from seed.


Monero 'Helium Hydra' (v0.11.1.0-release)

You're running an outdated version of monerod. Download and run the latest version (currently v0.12.3).


Kovri appears to be dead. However, there are two other projects that have been active w.r.t. Monero+i2p ambitions: i2p-zero and tini2p.

There is also now i2p support merged into the Monero master code and will be in the upcoming point release. Details on the new flags are in ANONYMITY_NETWORKS. Once released, you can immediately make use of i2p-zero and Monero (or if you build master, you can make use of this now).

There is no relationship between Sekreta and Monero currently. Note that Sekreta is not an alternative to an i2p implementation, it still relies upon secure networks such as i2p/tor; more information of which can be found in the project details.

UPDATE Jan 2020

So Anonimal has still been working on Sekreta (and Kovri to a lesser extent) - there is now a Monero pull request currently open for review.


It got to over 99% but is stuck at 2889 blocks remaining (not sure how to figure which block that is) Do I need to update my wallet, it was downloaded from the getmonero site in Aug

Based on the above and the approximate timing of your question it sounds like you are stuck on block 1,400,000 which was the block height of the 0.11.0.0 "Helium Hydra" fork. You will need to update using these instructions

  If I update, does it keep the original keys etc. so I keep the transactions?

Yes, if you follow the instructions in this link all of that data will be retained


https://www.getmonero.org/downloads/ uses HTTPS. The links on that page going to the actual downloads appear to be HTTPS as well. If there is one or several which is/are not, post the actual links as well as where they appear.
The site uses HSTS:

Strict-Transport-Security: max-age=15552000; includeSubDomains; preload

So your browser should not access it via HTTP if it's already accessed it and spotted the HSTS header.
You might be using the wrong website, such as monero.org, a well known squatter.


How do I convert my old v0.13 node to a v0.14 pruned node when I already have the full 65gb downloaded?

Upgrade to v0.14.x and after you have upgraded and run, the database will be migrated to the latest version. You can then exit the daemon and run monero-blockchain-prune, which will prune the database.

Note that pruning is not scheduled for release until 0.14.0.1.


Can you view the payment id in a monero block explorer?

There are two kinds of payment ids: plaintext ones, and encrypted ones.

Plaintext ones can be viewed in a block explorer, and one such example is found in block 1412534, transaction 2fbf1e227847b9bf604aee0e567531196214f8dae9dbc687f1e70bef4cf4ea67:

http://moneroblocks.info/tx/2fbf1e227847b9bf604aee0e567531196214f8dae9dbc687f1e70bef4cf4ea67

You can see this transaction included a plaintext payment id: dc4a15c532e88c5dd8411b6f9b41ec42b2c9f64e8c583c98feba2073116910d4

How these are interpreted is up to the receiver. It could be a key in a database, a hash of some information, a simple counter, etc. Some payment IDs have also been used to embedded "funny comments" in transactions. See for example https://xmrchain.net/search?value=19ee085a00ee7fd642709a14bbf74f36de5a890c32eff75fdacb8ff26a826b93 found by JollyMort below (666c75666679706f6e7920697320746865206265737420706f6e792065766572 is the hexadecimal representation of "fluffypony is the best pony ever", fluffypony being the Monero maintainer at this time).

As for encrypted payment ids, only the recipient can decrypt them. These are short form, and are mostly used along with integrated addresses, which are a convenient "bundle" carrying both the address and such a payment id.


Reasons for the way the mask/amount is calculated?

I'll restate the algebra (if the same key was used each time) so it's a bit clearer:

mask = encrypted mask + key
amount = encrypted amount + key

Therefore key = amount - encrypted amount

This means that if you could guess the amount of the output being sent to someone (perhaps you have knowledge that someone owed someone else exactly 5 XMR), then you could determine the key and then determine the mask. So to protect the mask, a different key is used to encrypt it.


How does one burn and provide a proof-of-burn in Monero?

There is a tradition in Monero that when you want to come up with a public key for which there is no known private key, you calculate that public key as H = hash_to_point(G), which in hex is 8b655970153799af2aeadc9ff1add0ea6c7251d54154cfa92c173a0dd39c1f94.

Therefore providing proof of payment to any wallet with H as the public spend key would be proof of burn.

If we set the private view key of that wallet to the number 1, then the public view key of the wallet will be G, which in hex is 5866666666666666666666666666666666666666666666666666666666666666

The wallet address for that combination of public view and spend keys is: 46uVWiE1d4kWJM3aAoCpHVgDCm5higshGVJBb4ZNpTYARp8rLcCdcA1J8QgRfFWTzmJ8QgRfFWTzmJ8QgRfFWTzmCag5CXT

The stagenet equivalent address is 577XbZ8yGfrWJM3aAoCpHVgDCm5higshGVJBb4ZNpTYARp8rLcCdcA1J8QgRfFWTzmJ8QgRfFWTzmJ8QgRfFWTzmCbXF9hd

The private view key, if you'd like to monitor that wallet, would be 0100000000000000000000000000000000000000000000000000000000000000.

You can use the "prove" feature in the Monero GUI to produce a proof (that will start with the string "OutProofV1") which will prove that you've sent a certain amount of funds to the address.

Of course, this solution means that anyone can monitor that account for incoming funds because the private view key is known.

You can burn funds to a wallet that also has no known private view key by using "H" for both the private view and private spend keys.

The mainnet wallet address for that would be: 46uVWiE1d4kWJM3aAoCpHVgDCm5higshGVJBb4ZNpTYARr4wKeg8fqzWJM3aAoCpHVgDCm5higshGVJBb4ZNpTYAHiN5zud

and the equivalent stagenet address would be:

577XbZ8yGfrWJM3aAoCpHVgDCm5higshGVJBb4ZNpTYARr4wKeg8fqzWJM3aAoCpHVgDCm5higshGVJBb4ZNpTYAHo2TYq6

Note: For historical reasons, Monero has defined H using a slightly different hash_to_point function than is currently used in RingCT. The hash_to_point used for the calculation of H historically has been hash_to_point_simple(G) = 8 * (the bytes of keccak(G) interpreted as an EC point). See How was the generator H for the RingCT scheme chosen?


Why isn't monero mining a widespread method to earn money on websites?

The short answer: Monero's RandomX PoW algorithm, is using low level functionality of your CPU, which can not be utilized from a web browser.


Are RingCT transaction bigger than an average ring signature transaction?

Yes, they are a bit in practice, but according to the RingCT paper of Shen Noether on http://eprint.iacr.org/2015/1098 it seems it cannot be much:


Which wallets or services currently support OpenAlias?

Official CLI and GUI IIRC, and latest monerujo 1.7.3 beta.


Monero Wallet RPC: tx_blob is always empty

If you are using the relay_tx method, you're supposed to pass the tx_metadata to it.

See the method here.

I can confirm it works fine.


What is the blobdata txs within the block_complete_entry struct?

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

A serialized transaction is made of:

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

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


What is long-term consequence of "lost" coins?

The question is not really suited for this StackExchange as it incites debate, however...

  Suppose some billionaire buys a huge amount of Monero coins, then dies and nobody can recover his keys. Doesn't this mean those coins are effectively lost for eternity?

The lost coins are effectively removed from circulation if "nobody can recover his keys", yes.

  It's a different situation than say, somebody that accidentally loses or destroys millions/billions of dollars in fiat cash, since the issuing government can just reprint it.

Centrals banks have a habit of creating money out of thin air, yes.

  Bitcoin... the coins become forever unrecoverable, but you would at least know...

Exactly how would you know if someone lost their private keys? You simply cannot, transparent ledger or not.

  Over thousands of years, wouldn't this eventually start to significantly drain the supply?

So supply goes down, value goes up, people start using smaller denominations.

  But I wonder if anyone has thought about the problem with "lost" coins that seem inherent to any obfuscated blockchain.

Per above, obfuscated or not, you have no way of knowing if anyone has lost their private keys.

  Is there any known solution to this?

If there is no problem, no solution is needed.


I believe the daemon automatically bans peers for a day or so if they try to connect with an out of date client (pre hardfork), or possibly if they're just on the wrong chain for some other reason.


Is there any enforcement on a transaction output being associated with an address?

Is this key creation process enforced?

There is no protocol level enforcement beyond P and R being points on the curve.

  For example, could Alice send money to a different P that is in no way associated with an address A and B, and is instead an arbitrary P = xG and simply generating a random unassociated R?

So yes, in theory at least, Alice could manually construct a transaction with output key P and transaction key R as you described.


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


How would I exploit the fact that I knew the scalar used for H in the Pedersons Commitment w.r.t G?

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

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

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

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

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

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

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

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

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

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


How do I operate the Monero GUI as a 'cold' wallet from an air-gapped computer?

I read the other question posted as possibly similar but it doesn't address the airgapped computer aspect of my question

An air-gapped computer cold signs. That's the point here.

  Can the Monero GUI run in an airgapped computer without connecting to the network?

Yes. This is cold signing. Cold as in "not connected to the internet".

  From what I understand, all three modes (Simple, Simple+Bootstrap, and Advanced) need to connect to the network.

No. The official wallets (GUI and command-line), both support cold signing transactions. In the GUI version, you have to use the wallet in "advanced" mode. They do not need to be connected to the internet/network to do this.

Annotating/expanding the duplicate questions answer for you:

First create your offline cold wallet, in the GUI, on your offline (air-gapped) computer. Use "advanced mode". Cold-signing transactions is after all an "advanced" thing to be doing.

  Create a view only wallet (settings page)

You do this on your offline (air-gapped) computer.

  Open view wallet and create a transfer, save with "Save tx" button

You do this on your online computer.

  In original wallet, click "Sign tx" on send page and select the file

You do this on your offline (air-gapped) computer.

  in view wallet, click "Submit tx" and select the signed tx file

You do this on your online computer.


How can I check if a Monero address is valid?

I believe that you will find an answer here, although the question was asked in a different way.

Practically, you'd verify the network byte, length, address encoding and checksum. For implementation details, I suppose you could inspect source of this page (javascript), or go to the monero github repo.


Does the Monero wallet distribute the blockchain?

Yes, the official Monero app (monerod) also helps the network by distributing the blockchain. This can be turned off by starting monerod with the --hide-my-port argument.

If you haven't set up port-forwarding in your router, most likely you will not distribute the blockchain. You can check how many nodes are connected to your daemon by issuing the following command inside the monerod prompt: status.
This shows something like this:

Height: [...], 8(out)+30(in) connections [...]

The number in front of (in) indicates the number of incoming connections. If this is 0 for you, nobody is connected to your node which means you're not distributing the blockchain.


How to setup autostart of monerod in Ubuntu 16.04?

In the dev's conf there was mentioned that the 'GuessMainPID=no' of the service file is necessary. The sample service file is here.


Transaction fees are very high for small transactions

Transaction fee are currently fixed (around 0.002 XMR/kB) which is penalising for small transaction (0.026 XMR/TX). Buying an item for 0.2 XMR incurs a transaction fee of 13% which I would call confiscatory.

Still cheaper than Bitcoin :) But yeah, they're high.

  A transaction fee that is a percentage of the transaction (say 0.1%) would go a long way to improve user-friendliness.

Please no. Why should someone with more pay more fee? He costs the network the same in terms of bandwidth / storage, and the only difference is the value of some bits in a transaction. Also, you can't really enforce this because you don't know the amount being transacted in the first place. If you just set it as default an trust the sender to follow it, it would kind of leak the amount being transacted, which we really don't really want.

  Is there no method to prevent spamming other than setting a minimum absolute amount of fee?

Some PoW just to submit a TX could work as well, but then why would miners bother to include TX-es in a block? Might as well mine empty ones. But, our problem with fees has other causes, and needs some adjustments, I believe. We have dynamic block size and dynamic minimum fee. Now, this is a dynamic minimum fee, so you expect it to be cheap, but at the present it's not really, so why is this?

Non-RCT TX-es could be 1-2kB, so that means 12x to 6x lower fee/TX. For those, both formulas worked well. You could squeeze 30 TX-es in a block, if there's demand in the mempool you could make it 31 and have a 3.3% increase which would easily be covered by even the min. fee. However, a 20% increase in block size would not be economic for the miner, unless people paid multipliers of min. fee. This is designed only for peak times. If there's organic growth, that cheap 3.3% increase could make block size slowly creep up. If you study the 2 formulas, you will find that this would also make the min. fee you pay per TX slowly decrease.

However, introducing RCT made a one-time bump in TX sizes, but the formulas were not changed together with this. Now, you can squeeze only 5 TX-es in a block, and if there's some demand, adding just 1 more TX means an increase of 20% in block size, which comes with a big penalty! It acts as a kind of wall which makes it hard to kick-off block size dynamics. This is the source of the problem. There was one proposal to address this by tweaking some parameters in the dynamic formulas, which ought to bring the min. fees down and fix the relations.

Edit 2017-06: The above problem was fixed in the April HF by increasing the min. penalty-free blocksize to 300kB, and it will be further alleviated by reducing TX size (estimated to 50%) with range proofs optimizations bringing TX size/penalty-free blocksize down to 2.3% from the above 20% which was the root cause of issues.


Does it make sense to run two nodes in order to disguise your identifiable information?

There is a small amount of metadata leaked if you broadcast transactions from the same IP address. Luckily, if you are using a VPN, you should be safe from the attacker connecting these transactions to your real IP. However, the transactions may still be connected to each other.

To mitigate this risk (which I would consider already very small), you need to break the link between these IP addresses being correlated to each other. It's probably not worth your time to run different nodes for this, but you can connect your node to a different VPN for each transaction you make.

Once Kovri is fully-implemented, then you would no longer need to be concerned about this potential risk.


simpleminer has been removed.

You can either use the miner in the daemon/wallet or any of the mining programs found on https://monerohash.com/#getting_started


You obviously have to find a block on your pool. Afterward, wait for the 60 blocks confirmation of the coinbase transaction.


What is MoneroV, and how is it different than Monero?

MoneroV is a chain split off Monero. It will inherit Monero's history going forward. MoneroV is widely regarded as an attack on the Monero network.

Any initial transactions made on MoneroV will be directly linked to their Monero counterpart. For instance, suppose I have money in Monero address A at the time of the chain split. I then spend my MoneroV and Monero. Both of these transactions will return the same key image, which means they will be linked.

Furthermore, this negatively impacts other transactions on the network. If they include the output my funds are stored in as decoys in their ring signature, then everyone knows this is a decoy instead of a real input.

Watch more about the impact of chain splits on Monero here.

Though MoneroV poses a threat to the Monero network, MoneroV itself will incur the greatest burden. Do not rely on MoneroV for privacy, since it is highly likely that a large proportion of their outputs are traceable.

Monero has made it clear that they are not affiliated with MoneroV, and that they strongly recommend against key image reuse:

  It is important to realize that the security of the Monero network and your own Monero is dependent on the security of your Monero keys. Your Monero keys are MONERO keys. Do NOT use them for any other purpose, including claiming coins from a Monero fork. Using your keys to spend the same outputs twice on different forked blockchains will damage your privacy, and others', as both spends will bear the same key image, but different rings, with only your spent output in common (this does not impact stealth addresses nor confidential transactions, just ring signatures). Moreover, by using such a "same keys" fork, the security of your Monero private keys now depends on those third parties.


Why are empty blocks not all the same size?

Usually, empty blocks can vary within a couple bytes, as monero amounts (present in the coinbase transaction even in "empty" blocks) are stored in a varying length encoding.

1157856, however, is a lot larger because it's got extra info in the extra field. It's probably been mined by MinerGate, who tends to add their own private information in blocks.


Is monero worth mining in 2021?

It's "worth it" profitability wise if your cost of running is less than the revenue you can make. Thus you need cheap electricity / low power consumption system. This is why many people mine using AMD Ryzen 3000 series CPUs; the hash/watt ratio is high.

So my question is, am I doing something wrong in this calculation...?

If you're going to use some random online calculator, make sure you put in accurate values and double check the calculations yourself. For example, your system power consumption is probably not 1200W, unless you also have a couple of power hungry GPUs in it. Your electricity cost probably also isn't 30c kw/h as that's higher than even NYC; if that really is your power cost, then mining Monero almost certainly will be unprofitable for you.


You can type the following command in the monerod, it is the black square box with many text named "monerod".

flush_txpool

This should clear all your pending transactions. However, if there is a backlogged or your transaction is already in the mempool it may not work, so just try it.


Firstly, the market price of Monero in EUR has little bearing on any of this.

Secondly, mined or transferred? The question is not clear. Regardless...

There is no cap on the value amount you can transfer (so long as you obviously own that amount) and the amount of Monero that can be mined is dictated by the emission schedule.

However, when considering large transfer value amounts, you presumably own a lot of separate outputs (thus inputs funding the transfer), and whilst there is no cap on the value amounts, the more outputs you spend (so tx inputs) the larger the tx storage size becomes. Therefore the constraint becomes the tx storage size, which can currently be no larger than 1000000 bytes (src). Furthermore, there is a maximum number of transactions that can be mined in a block, 268435456 (src).

Putting this all together, if you owned one output with one Monero and the market price for 1 XMR was 1m EUR, nothing whatsoever would prevent that transfer or it being mined in a block. If you owned 1m individual outputs you wanted to spend, you would have to send them in many transactions because of the tx size constraint; a miner can still mine 1m transactions in a block though.


Is there a list of active monero full nodes?

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

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


Why does monerod allow mining from a pruned blockchain?

My understanding is that one of the main tradeoffs on running a pruned node is that it is not possible to mine from such a node; that mining requires the full blockchain.

That is simply not true.
The tradeoff running a pruned node is for the network as a whole, i.e. other people wont be able to sync certain blocks (i.e. the ones you've already pruned), from your node. This is why when running a pruned node, a percentage of blocks are left unpruned. This means, assuming everyone was running pruned nodes, a new user needs to sync from many other peers.
A simplified example: Imagine a network of only 3 people, Bob, Carole and Ted. And let's say the blockchain is 60 blocks deep. Bob, Carole and Ted have all synced, verified and pruned their chains and each left a different 3rd unpruned. Bob didn't prune 1-20, Carole didn't prune 21-40 and Ted didn't prune 41-60. Now, when new user Alice decides to start using Monero, she needs to sync and verify the whole chain (as a new user does). To do so however, she needs to sync each of these separate unpruned sections from Bob, Carole and Ted. After syncing and verifying, Carole may also prune.


Unfortunately, this looks like a corrupt blockchain database.

With 0.11.0.0, monerod has a --db-salvage option which might be able to recover your database. Exit monerod, and run it again with that option appended, eg: ./monerod --db-salvage.

Otherwise, the only fix for tis is to exit monerod, delete the blockchain (~/.bitmonero/lmdb/data.mdb) and start monerod again. It will then sync the blockchain again. Nothing needs to be done with the wallet, the GUI, etc. Just the blockchain.


Will future GUI and CLI releases remain seperate?

The current intent is to keep them separate for size reasons. The GUI binaries take a lot of space due to the extra libraries needed (Qt, etc), and so there is an advantage to keeping a separate download with just the CLI tools. Those are incldued in the GUI download because (1) it does not add too much space to the Qt/etc size, and (2) they are needed, and so bundling them ensures the GUI gets to use the matching version.


It depends on the pool payment schedule. If you go over the threshold it doesn't mean the pool will immediately make the payment, but it should be part of the next batch, whenever that may be. Some pools make payments once per day, so you'd have to wait a bit. Maybe you've already received your payment :)


Mining directly in the wallet or daemon you don't earn anything until you actually mine a block. With your exceptionally low hashrate (101 H/s), that would be sometime in the next ~75 years.


I think the main purpose is to just prevent you from trying to spend a tx output that gets re-orged out of existence. At any point a block, or the last several blocks, or a lot of blocks can get orphaned, and the transactions included in them will be invalidated. However, the probability of a block getting orphaned decreases exponentially as more blocks are built on top of it (see the frequency of orphaned blocks here). So, it is really just a judgment call by the client software that after 'x' number of blocks there is an extremely low probability that the block containing that tx will get orphaned. In Monero the coins are "locked" for ten blocks, or what is now about 20 minutes, while in Bitcoin the core client software recommends waiting six blocks, or about 60 minutes (although the Bitcoin software refers to these coins as unconfirmed, not locked).


monero-miner.com "minimum withdrawal amount"

First of all, regarding this particular website, I can't say one way or another whether it's "legit" or not.  Do as much research as necessary to determine whether it is.  Considering you're not risking any coins in your wallet - that is, you're only risking not receiving the coins to which you are entitled from mining - the risk of loss is at least low.

Regarding minimum payout, you'll find that they vary from service to service.  Some mining pools allow one to set a minimum payout to 0.3 Monero, or sometimes less.  The default tends to be 1.0 Monero.  Many miners probably increase the payout threshold beyond that.

Transaction fees are related to the size of the transaction (in kB).  If you need to spend 1.0 Monero, and you have a 1.0 Monero output to spend, the fee to send that transaction will be much cheaper than if you had to use four 0.3 Monero outputs.  Keep this relationship in mind when choosing your payout threshold, assuming you're able to choose it.


How are the various tx-extra types/formats used?

Padding is for adding freeform data of arbitrary length. It can be used to embed any data, for example a human readable mesage.

Pubkey is for the transaction public key (R in the Cryptonote whitepaper).

Nonce is for extra data, currently only used for the payment ID. Classic style payment IDs are 256 bits and unencrypted, while integrated address payment IDs are 64 bits and encrypted.

Merge mining tag is meant to be used for merge mining. Only Fantomcoin can be merged mined to my knowledge.

Minergate's tag's use is unknown. Minergate started using it a few months ago.


What advantages does Monero offer that are not provided by other cryptocurrencies?

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

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

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

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

Other things that are worth highlighting are:

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


Calling MyMonero API with generated parameters

To get the kind of information that API method returns would require scanning the whole blockchain, hence why it is not returning data for an arbitrary address.

If you want to scan the blockchain using an arbitrary address and keys, you will need to use the Monero tools to first restore a wallet from keys and then, assuming you want to do this as an RPC call, open the wallet using monero-wallet-rpc and calling it's methods, such as get_transfers.


Where are the signatures of a ring coming from?

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

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


This is a minor bug due to the dust threshold (0.01 XMR) being higher than the current fee (0.002 XMR per kB). This is fixed in this pull request.

  What does that mean, is it that the fees would have been only 0.004 (or 0.006) but the client wants to round that up to 0.01?

Basically yes.


It will not. As of now, it doesn't monitor heat.


Difference between disposable address, integrated address and subaddress?

Has disposable address been removed from the wallet, since I can't find how to generate one in monero-wallet-cli's help message? (wallet version Helium Hydra v0.11.0.0).

Disposable address was never added to the official Monero wallet. It was originally proposed in PR-1345 which inspired an improved version called subaddress in PR-1753. Disposable address was ultimately dropped in the final version PR-2056 due to the severe limitation that the address reuse will cause privacy leak.

  Since integrated address combines payment id and standard address in an encrypted way, why do we still need subaddress?

The payment ID embedded inside the integrated address is NOT encrypted. The payment ID gets encrypted when the sender constructs the transaction and the transaction is recorded on the blockchain, which can be decrypted only by the receiver.

The purpose of subaddress was to hide the fact from the sender (or anyone other than the receiver, for that matter) that multiple seemingly unrelated addresses actually belong to the same receiver. The only traditional way to achieve this goal was to simply generate multiple wallets (i.e. multiple seeds), which was not only tedious but also highly inefficient.


What is the monero-wallet-rpc/deamon-rpc?

monero-wallet-rpc is one of the command-line applications that ships with Monero. It enables developers to make HTTP based requests to interact with a Monero wallet. An example could be to implement the receiving of payments in XMR on an ecommerce site.

The other RPC is the daemon RPC which is part of the main monerod application. This enables developers to make HTTP based requests to interact with a node. An example could be someone wishing to develop a Monero blockchain explorer website.

In simplistic terms, you can think of both these apps as web servers, but instead of serving a web page (like a normal web server does), they return data that can be parsed and used in another application. The data they return is JSON data. Both of these RPC interfaces are only of any use to developers and are not relevant to normal users of Monero.

If you are interested in learning more, here are some documentation links:

Monero Daemon RPC - https://ww.getmonero.org/resources/developer-guides/daemon-rpc.html
Monero Wallet RPC - https://ww.getmonero.org/resources/developer-guides/wallet-rpc.html
JSON - https://en.wikipedia.org/wiki/JSON
RPC - https://en.wikipedia.org/wiki/Remote_procedure_call
HTTP - https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol


How to run Monero-wallet-rpc on windows?

When starting your monero-wallet-rpc you need to specify which wallet file to use along with a password and a port.

run monero-wallet-rpc -h to see arguments to start the wallet rpc server.


It will need more and more as adoption grows, but you don't really need to store the entire thing (although if you can, it's generally better for you), you can connect to somoene else's node instead: How can I use Monero without syncing the blockchain?

Last time I checked my disk it was about 32GB, could be a few more right now. Note that the database on disk will always be bigger than the .raw file. This is because database stores some additional info computed from raw data to enable fast searches etc.


What is the difference between RCTTypeBulletproof and RCTTypeBulletProof2?

RCTTypeBulletproof2 adds some additional data (beyond the RCTTypeBulletproof type):

It changes the field nbp to a varint field, which has the count of Bulletproof signatures [source]
It adds the encrypted amount to each output [source]


What is "aes_round" in the Monero hashing algorithm?

An AES round uses the three functions (SubBytes, ShiftRows and MixColumns).

The Wikipedia article on AES has a high-level description of the algorithm and links to the AES standard, reference source code, etc.


How do I restore / recreate my Trezor Monero wallet?

I've noticed some confusion lately on how to restore one's Trezor Monero wallet. I have therefore written this guide.
In case you have also lost (access to) your Trezor device, you first have to restore the 12 or 24 word Trezor mnemonic seed in another Trezor device.
Restoring / recreating a Trezor Monero wallet is fortunately fairly trivial thereafter.
GUI:

Basically you ought to follow this guide with one minor tweak to recreate / restore the Trezor Monero wallet. That is, the Restore a wallet from device option has to be selected (in step 8). This allows you to set a Restore height that is in advance of the first transaction to your Trezor Monero wallet. A detailed explanation about the Restore height parameter can be found here. For convenience, I've added a table with restore heights to the appendix.

Note: Use this work around if you cannot access the Restore height box:

There is a fix for the time being: You can access the restore height window by selecting the wallet location and pressing tab once.

CLI:

Basically you ought to follow this guide with one minor tweak to recreate / restore the Trezor Monero wallet. That is, you have to append the --restore-height flag (with a proper block height as value) to the command that is used / executed to recreate / restore the Trezor Monero wallet. A proper restore height is set by choosing a value (block height) that is in advance of the first transaction to your wallet. A detailed explanation about the Restore height parameter can be found here. For convenience, I've added a table with restore heights to the appendix.

Appendix:
My wallet was created in | Restore Height I should use
November  2020           | 2175000
October   2020           | 2155000
September 2020           | 2135000
August    2020           | 2115000
July      2020           | 2095000
June      2020           | 2075000
May       2020           | 2055000
April     2020           | 2035000
March     2020           | 2015000
February  2020           | 1995000
January   2020           | 1975000
December  2019           | 1955000
November  2019           | 1935000
October   2019           | 1915000
September 2019           | 1895000
August    2019           | 1875000
July      2019           | 1855000
June      2019           | 1835000
May       2019           | 1815000
April     2019           | 1795000
March     2019           | 1775000
February  2019           | 1755000
January   2019           | 1735000
December  2018           | 1715000
November  2018           | 1690000
October   2018           | 1665000
September 2018           | 1640000
August    2018           | 1615000
July      2018           | 1590000
June      2018           | 1565000
May       2018           | 1540000
April     2018           | 1515000


Monero 11.0 worked now I can't get 12.0 to load it crashes

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


Syncronisation problem on Geekbox running node from SD card

It sounds like your 32 bit Monero build is invalid, it is computing incorrect hashes and failing to accept valid blocks. If you got this from the official download site, please submit an issue on Github about this.

You are wasting power running a 32 bit OS. I'm currently using this 64 bit Debian install: http://forum.geekbox.tv/viewtopic.php?f=12&t=3284


The transaction ID is based on the hash of everything in the transaction, and the MLSAGs sign everything in the transaction except the MLSAGs themselves.

Therefore, changing anything in the transaction will change the tx hash and thus the ID.


How to keep lots of Monero wallets in sync?

Seeing as you have custody of the wallets, it would seem to make a whole lot more sense to track the funds via subaddresses in a single RPC wallet. Should you still want to dish out individual wallets, you can provide a means to move funds between the master RPC wallet and any other wallet at that time of need.

However, I would question any service creating full wallets for end-users as it's essentially promoting a false sense of security - you (the provider) still have the custody even if you dish out private keys.

Lastly, as you are finding, holding (and maintaining) hundreds of independent full wallets is never going to scale well because each wallet independently needs to scan blocks for transactions. Using subaddresses solves this problem.

In summary, I suggest rethinking the design.


It's a field in the rpc call to send a transaction, see here:
https://github.com/monero-project/monero/blob/0edcbf6716cdfd2ea5439a7788cca0041b40a2e2/src/wallet/wallet_rpc_server_commands_defs.h#L124

I think the way it works is if you pass that field a number that is less than the start of UNIX time in seconds, then it is interpreted as a block height that the output will be unlocked after, and if you pass it a number greater than the beginning of UNIX time in seconds, then it is interpreted as a UNIX time that the outputs will unlock after.


Try to enable http digest authentication:

curl --digest
     -u user:password
     -X post
     -d '{"jsonrpc":"2.0", "id":"0", "method":"getbalance"}'
     -H 'content-type: application/json'
     http://127.0.0.1:8082/json_rpc


Is i2p-zero integration accessible from monerod cli in 0.15?

The i2p (and tor) integration is purposely implementation agnostic - i.e. it is designed to work with any i2p/tor router implementation. There has not yet been any agreement I'm aware of for packaging a specific router implementation with the core CLI tools.

The GUI however has slightly different nuances / needs when it comes to i2p/tor integration in that typical GUI users just need / want single-click style integration / activation. Hence the first work planned for GUI (if I recall correctly) is to offer the option of downloading and auto-configuration of i2p-zero from within the GUI, not actually packaging i2p-zero alongside the GUI binaries.

The first step was getting the daemon able to use any i2p/tor router, and this was released in v0.14. After this work was completed, then work could begin on the GUI (as outlined above). This was tentatively aimed for the v0.15 release, but unfortunately other priorities got in the way.

So to answer your specific questions:

  Is i2p-zero integration accessible from the monerod cli in 0.15?

Yes, the integration options have been in place since v0.14.

  Is i2p-zero now built into Monero?

No, i2p-zero is not "built into" Monero. See detailed answer above.

  If so, what are the flags to access it? Can you point me to the documentation for those flags, or a tutorial?

The flags are detailed in the document you linked to: ANONYMITY_NETWORKS.


How are the other inputs chosen with MyMonero?

Note: I am currently maintaining the Mymonero backend.

Mymonero currently selects outputs at random over the complete set of possible outputs. So guessing the real output is not necessarily trivial. The wallets try to select dummy outputs with a bias towards newer outputs, based on research indicating that there is a bias towards the real output being spent shortly after receival. Mymonero uses this alternative algorithm primarily due to historical significance (i.e. some past maintainer implemented it that way). I honestly did not think about this portion of the code until someone pointed it out to me ~2-3 months ago - it was in the "if it ain't broke, don't fix it" category previously.

More recently it has not changed because the required APIs from the daemon are binary and the web-facing client is written in GO. So grabbing the information is not "dead-simple". I was hoping the ZeroMQ patches would make it into v0.11 so that all calls into the daemon could be updated at the same time. But that patch didn't make it into the last release, so an interim solution may have to be applied now.

UPDATE: mymonero now uses the get_random_outs RPC from a monerod daemon.


Please advise if it's safe to share my Monero Wallet Address with them.

Yes. It is safe to share a wallet address with someone who wants to send you money. If you don't give them a wallet address they cannot send you money.

...can they withdraw funds from my account with my address?

No. They would need your private keys (or your seed to restore) to spend your money. Your wallet address (or a subaddress) is only good for sending funds to.