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

On macOS:

Downloading the tar.bz file. I will assume it is located in the normal "Downloads" directory, and it's name is monero-mac-x64-v0.10.3.1.tar.bz2. Other names/locations are fine but you'll have to adjust the process accordingly.
Open Terminal. Easiest way is ⌘+spacebar and type "Terminal", then hit enter.
Change to the Downloads directory. Type cd ~/Downloads and hit enter.
Get the Sha-256 Checksum. Type shasum -a 256 monero-mac-x64-v0.10.3.1.tar.bz2 and hit enter.
Compare it with the checksum on the Monero page.

On Linux (tested on Ubuntu 16.04) the command is sha256sum rather than shasum -a 256.

On Windows, the command is pinch nose, scrunch eyes, and hope everything is good as you unzip the file. Just kidding. I don't know the Windows command though.


Why did Monero choose LMDB over alternative database types? Did the Monero development find LMDB architect and developer Howard Chu because of its interest in LMDB? Or was LMDB introduced to the Monero development team because of Howard Chu's interest in Monero?

Why did Monero choose LMDB over alternatives such as LevelDB RocksDB, HyperLevelDB, Berkeley DB and InfluxDB?

What are the pros and cons of the various database types Monero considered using after the decision was made to stop storing the blockchain in RAM?

I wasn't around when the decision to use LMDB was made, but I can present some obvious reasons why such a decision makes sense:

1) at the time they made their decision, there were only 2 embedded key value stores out there with ACID transaction support: BerkeleyDB and LMDB. (RocksDB has recently added it. I haven't tested it to see if it's actually usable. Given that LevelDB has been plagued with bugs even in their snapshot isolation, I wouldn't expect much from RocksDB.)

2) for something with real monetary value, you really don't want a DB that can irrecoverably lose your data. This is something all the LevelDB-using cryptos still don't seem to understand. If it doesn't do real ACID then it's a non-starter.

3) between the only viable choices of BerkeleyDB and LMDB, LMDB is obviously smaller/faster/more reliable. Faced with a lack of 32bit LMDB support, the Monero team adopted both.

4) As key/value stores go, and ignoring ACID for the moment, LMDB offers a number of features that other k/v stores lack, which boosts its efficiency in a cryptocurrency use case. E.g. support for native integer keys, keys with multiple values, fast bulk loading/importing, etc.

Here are some IRC transcripts from the time the choice of DB was being made. It gives you insight into the range of solutions and what factors were considered:

[2014-06-02T16:40:55+0200] <@fluffyp> tacotime: have you ever played with
  hamsterdb?
[2014-06-02T16:41:19+0200] <@tacotime> nope
[2014-06-02T16:41:46+0200] <@tacotime> but i don't wanna mess with any java
  db systems
[2014-06-02T16:42:02+0200] <@fluffyp> tacotime: not java
[2014-06-02T16:42:06+0200] <@fluffyp> c/c++ embedded db
[2014-06-02T16:42:09+0200] <@tacotime> ah okay
[2014-06-02T16:42:13+0200] <@fluffyp> looks like it outperforms leveldb
[2014-06-02T16:42:19+0200] <@fluffyp> has an open source community edition
[2014-06-02T16:42:22+0200] <@tacotime> i wouldn't be surprised
[2014-06-02T16:42:28+0200] <@tacotime> how mature is the software though?
[2014-06-02T16:42:49+0200] <@tacotime> something slow and bugfree is
  better than something fast and buggy when it comes to financial software
[2014-06-02T16:43:09+0200] <@fluffyp> this has been around for years
[2014-06-02T16:43:12+0200] <@fluffyp> since 2010 or so
[2014-06-02T16:44:45+0200] <@tacotime> yeah
[2014-06-02T16:44:54+0200] <@tacotime> a lot of people are using mongodb
  now i feel like
[2014-06-02T16:45:03+0200] <@tacotime> i'm kinda curious about tokumx too
[2014-06-02T16:45:14+0200] <@fluffyp> there's no embeddable version of mongo
  is there?
[2014-06-02T16:45:25+0200] <@tacotime> i don't think so :/
[2014-06-02T16:45:32+0200] <@tacotime> i'm going through the btcdb stuff right
  now and seeing how a db is implemented too
[2014-06-02T16:45:51+0200] <@tacotime> https://github.com/conformal/btcdb
[2014-06-02T16:46:01+0200] <@tacotime> that's a good example of how to do it
  the quick and easy way in go
[2014-06-02T16:47:12+0200] <@tacotime> if you want a fast db you still need to
  keep a lot of the most recent blocks in memory, though
[2014-06-02T16:47:14+0200] <@fluffyp> tacotime: I'm talking about the embedded
  blockchain keyvalue store - one of the devs I was talking to suggested
  hamsterdb over leveldb because it's faster whilst remaining significantly
  robust
[2014-06-02T16:47:26+0200] <@tacotime> and have to be careful with atomicity
[2014-06-02T16:47:28+0200] <@tacotime> ah, ok
[2014-06-02T16:47:37+0200] <@fluffyp> sorry should've clarified that :-P
[2014-06-02T16:47:49+0200] <@tacotime> I think we're talking about the
  same thing
[2014-06-02T16:47:56+0200] <@tacotime> https://github.com/conformal/btcdb/blob/
  master/ldb/leveldb.go
[2014-06-02T16:48:19+0200] <@tacotime> writing an easy keystore like that
  isn't too cluttered and timeconsuming
[2014-06-02T16:48:52+0200] <@tacotime> but regardless of whether you use
  hamsterdb or leveldb, it'll get slow fast if you aren't on an ssd for monero
[2014-06-02T16:48:58+0200] <@fluffyp> yep

And following up a week later:

[2014-06-09T15:55:19+0200] <pen> What is the selected embedded database for
  Monero? I pointed crypto_zoidberg to Sophia. Just wondered about Monero's
  dev choice
[2014-06-09T15:55:44+0200] <@fluffypony> pen: we're still deciding
[2014-06-09T15:57:09+0200] <@fluffypony> if we abstract it properly then embedded
  database choice becomes an academic exercise (i.e.. which one is best for our
  workloads)
[2014-06-09T15:58:25+0200] <pen> leveldb may be a safe choice. However, leveldb
  is not the fast one out there. Let see if BBR dev choice is. I expect that it
  would be LMDB or Sophia
[2014-06-09T15:58:25+0200] <@fluffypony> so many options between kyotocabinet /
  sparkey / tokutek / hamsterdb / hyperdex / symas lmdb / sophia / and tons of
  leveldb forks
[2014-06-09T15:59:40+0200] <pen> hyperdex is not an embeded one. Actually
  hyperdex devs improve leveldb in term of write scalability in a fork
[2014-06-09T15:59:57+0200] <pen> sophia and lmdb are not leveldb forks
[2014-06-09T16:00:17+0200] <pen> sophia is the db that powers Tarantool
[2014-06-09T16:00:25+0200] <othe> mongodb has the best name, i vote for that
[2014-06-09T16:00:44+0200] <@fluffypony> pen: I wasn't implying those are all
  leveldb forks :)
[2014-06-09T16:01:44+0200] <@fluffypony> hyperdex has an embedded db -
  HyperLevelDB (unsurprisingly a leveldb fork)
[2014-06-09T16:02:26+0200] <pen> @othe mongodb is so hyped. And it is not
  designed for an embedded one
[2014-06-09T16:02:34+0200] <@fluffypony> pen: he was just trolling you

My first contact with the Monero project came two months later:

[2014-08-07T11:34:25] fluffypony: heya
[2014-08-07T11:34:32] fluffypony: plz ping me when you're around
[2014-08-07T11:34:48] hyc: what's up?
[2014-08-07T11:34:54] fluffypony: lol that was fast
[2014-08-07T11:35:00] fluffypony: hokay so
[2014-08-07T11:35:04] fluffypony: LMDB
[2014-08-07T11:35:28] fluffypony: how often do you push from the main openldap
  branch to the lmdb gitorious branch?
[2014-08-07T11:35:47] fluffypony: ie. should I be pulling it from the openldb mdb
  branch instead of there?
[2014-08-07T11:36:31] hyc: we normally push simultaneously
[2014-08-07T11:36:55] fluffypony: ok great
[2014-08-07T11:37:06] fluffypony: I'm one of the core team members on Monero, a
  cryptocurrency (not based on Bitcoin)
[2014-08-07T11:37:16] hyc: you can pull from whichever you like. some folks
  complained that they had to pull the entire openldap git repo just to get LMDB,
  so we set up gitorious
[2014-08-07T11:37:19] fluffypony: and we're in the process of moving from a flat
  file in RAM for the blockchain to an embedded DB
[2014-08-07T11:37:27] fluffypony: and I'm DEAD keen on lmdb
[2014-08-07T11:37:35] fluffypony: as it appears it will be most performant for
  our workload
[2014-08-07T11:37:38] hyc: sounds good
[2014-08-07T11:37:48] fluffypony: and it will provide scalability for larger
  instances
[2014-08-07T11:39:06] hyc: yep
[2014-08-07T11:39:29] hyc: and unlike other embedded DBs, it will never corrupt
  or lose your data...
[2014-08-07T11:39:38] fluffypony: yeah and that's the appeal
[2014-08-07T11:39:49] fluffypony: in a distributed consensus system you really
  want to have solid data on-disk
[2014-08-07T11:39:55] fluffypony: because peers are reliant on that
[2014-08-07T11:40:00] hyc: absolutely


What does CONOP mean and how does it relate to block sizes and scaling? What has Monero done to address CONOP factors?

How does the current Monero implementation compare to other existing cryptocurrency alternatives with regard to blocksize caps?

Is the any research about new adaptive blocksize formulas that may identify areas where Monero can make further scaling improvements?

[C]ost [O]f [N]ode [OP]eration is (theoretically) a way to measure to the cost of running a full node.

If we peg a blockchain with a 1 MB blocksize as having a CONOP of 1, then doubling the blocksize to 2 MB, would double the CONOP to 2, thus reducing decentralization since increasing CONOP would result in less people running full nodes (higher the price of something, less demand).

Of course, things don't only go up. As the cost of memory, hard drive space, internet speeds, etc. improve, the CONOP can also move down. So if you double the block size, but the cost of internet and hard drive space reduces, you can theoretically get an even lower CONOP than the original.

Monero can't really do much to affect the hardware aspects of CONOP, but it's adaptive blocksize algorithm attempts to keep blocks from becoming overly large, thus keeping the space component of CONOP within some reasonable range.


Why would you need multiple daemons using one LMDB database? From the release notes of the latest monero 0.10.2 version:

  added support for multiple daemons using the same LMDB database

What sensible use case should that cover? From my understanding, LMDB databases are meant to be used locally, so for what reason should multiple deamons run locally?

The use case I had in mind when I wrote this code is to run daemons on different network interfaces, or on different network protocols, using the same database. E.g., if you want to use different bandwidth limits on one interface vs another, or if you want to run a daemon on TOR simultaneously with a daemon on clearnet. Or, you want to run a public node (with --restricted-rpc) and also want to run a daemon that mines at the same time.

You can run as many daemons as you want on the same database without the DB taking up any additional memory.


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

Find the correct download on the official Monero website and go to your downloads folder. Open the terminal and use this command:

sha256sum monero-linux-x64-v0.10.3.0.tar.bz2

If you receive the following output you will know that the hash matches the GPG signed message listing the correct SHA256 sums

  f164112bea75dfd3eaaa905d21129820a996bbe6e5d65cb194609c672a71c3fe  monero-linux-x64-v0.10.3.0.tar.bz2


Is it possible to tell apart real and testnet Integrated Address Real address has network byte 0x12, testnet address has 0x35 and integrated addresses all have 0x13. At least this is what I learned from different resources online.

Is it possible to tell whether the address behind IA is a real or testnet one? Or the IAs for addresses with the same pubkeys are indistinguishable?

Testnet integrated addresses have 0x36 as prefix.

See src/cryptonote_config.h


How to uninstall ccminer? I installed the ancient tsiv version of ccminer and I want to switch to one that's maintained. When I check which ccminer I see that it lives in /usr/local/bin/ccminer. There are no uninstall directions-- what's the correct way to uninstall it? sudo rm /usr/local/bin/ccminer?

yes that will work. if you have the source code still, you can try

  make uninstall

or

  sudo make uninstall

from inside the source code directory. check out https://askubuntu.com/a/87112/610029


Format of QR code URI scheme to add a Payment ID and do monero mobile wallets read it? What is the proper URI format when making a QR code with a payment ID integrated? And do the monero mobile wallets read this format properly?

The URI format is described in https://github.com/monero-project/monero/wiki/URI-Formatting.

In particular, a monero payment URI with a payment ID would use the tx_payment_id parameter, like this:

monero:4xxxxxx?tx_payment_id=1234567812345678123456781234567812345678123456781234567812345678

If you want to try things, out, the Monero GUI wallet allows you to autoamtically generate QR codes based on the payment ID and amount you give.

The Monero GUI wallet supports reading those, but I don't have information on which other wallets currently support them. I suspect most do. monero-wallet-cli, while not a mobile wallet, has a patch to handle them which is soon to be merged.

Note that Monero now supports subaddresses, which allow you to have an address per customer without having to deal with separate payment IDs (however, not all wallets support sending to these yet).


Is there a way to export the output of the command `show_transfers`? When entering show_transfers into monero-wallet-cli, one is provided a list of in- and out- transactions related to that wallet.  Is there a way to use that command to export the data into a txt, csv, or other type of file?

https://askubuntu.com/questions/420981/how-do-i-save-terminal-output-to-a-file

To write the output of a command to a file, there are basically 8 commonly used ways.

Overview:

         || visible in terminal ||   visible in file   || existing
 Syntax  ||  StdOut  |  StdErr  ||  StdOut  |  StdErr  ||   file
=========++==========+==========++==========+==========++===========
   >     ||    no    |   yes    ||   yes    |    no    || overwrite
   >>    ||    no    |   yes    ||   yes    |    no    ||  append
         ||          |          ||          |          ||
  2>     ||   yes    |    no    ||    no    |   yes    || overwrite
  2>>    ||   yes    |    no    ||    no    |   yes    ||  append
         ||          |          ||          |          ||
  &>     ||    no    |    no    ||   yes    |   yes    || overwrite
  &>>    ||    no    |    no    ||   yes    |   yes    ||  append
         ||          |          ||          |          ||
| tee    ||   yes    |   yes    ||   yes    |    no    || overwrite
| tee -a ||   yes    |   yes    ||   yes    |    no    ||  append

List:

command > output.txt

The standard output stream will be redirected to the file only, it will not be visible in the terminal. If the file already exists, it gets overwritten.
command >> output.txt

The standard output stream will be redirected to the file only, it will not be visible in the terminal. If the file already exists, the new data will get appended to the end of the file.
command 2> output.txt

The standard error stream will be redirected to the file only, it will not be visible in the terminal. If the file already exists, it gets overwritten.
command 2>> output.txt

The standard error stream will be redirected to the file only, it will not be visible in the terminal. If the file already exists, the new data will get appended to the end of the file.
command &> output.txt

Both the standard output and standard error stream will be redirected to the file only, nothing will be visible in the terminal. If the file already exists, it gets overwritten.
command &>> output.txt

Both the standard output and standard error stream will be redirected to the file only, nothing will be visible in the terminal. If the file already exists, the new data will get appended to the end of the file..
command | tee output.txt

The standard output stream will be copied to the file, it will still be visible in the terminal. If the file already exists, it gets overwritten.
command | tee -a output.txt

The standard output stream will be copied to the file only, it will still be visible in the terminal. If the file already exists, the new data will get appended to the end of the file.


How to implement a java script version of monero CPU miner Coin-hive.com implements a java-script version of monero cpu miner. Which we can insert on our website to mine monero through the users CPU power. Can Someone provide me leads on how this works on the backend. Does this works on C++ or java-script solely and how can i implement my own version of this?

The site itself says they've used WebAssembly to compile C code to Javascript. This means you'd need to be competent in C in order to attempt this feat.

If you work through the numbers though, the revenue you'd get from asking your visitors to mine Monero will be tiny compared to the advertising revenue you could get instead. I'd also imagine Google will soon start blacklisting sites that do this.


Clarification on the Monero Trezor binaries 'passphrase' I presume that the 'passphrase' in the Monero Trezor binaries mentioned here, is the same thing as the Trezor passphrase mentioned here? Just want to be absolutely sure.


How will the implementation of Kovri work from a user perspective? This is really a multi-part question that I'm happy to trim/change/delete if it's too broad and/or speculative.

Part A - Assuming an average, not-particularly-tech-savvy user is excited about Kovri implementation, what can they expect when it is rolled out?  That is, can they expect to double-click on an installation file they ordinarily would (an installation file that includes the daemon, the wallet, probably the GUI wallet by that time, and Kovri), and the installation/setup will just ask clearnet/i2p/both?  And then, once it's set up, the node just runs like usual, and they won't need to increase their technical prowess to make it work or maintain it?

Part B - For the more experienced user who wants to route their internet traffic in such a way that they can browse eep sites, will selecting "i2p" in the installation/setup allow for routing any i2p traffic (not just monero), as though they had set up a dedicated i2p relay?

Part C - Will the i2p relay be able to filter the traffic to only pass through monero-related traffic, or is i2p implementation more of an off/on switch?

what can they expect when it is rolled out?

The Kovri router will be baked in to the Monero code, so all a user will need to do is select an option indicating whether they want to use the Kovri routing feature or not. I think its still up in the air whether it will be on by default or not. I think it will be on by default.

  as though they had set up a dedicated i2p relay?

Yes, I believe that is the idea. In addition to routing the Monero transaction traffic, the Kovri router will also provide a gateway into i2p and will serve to support the i2p network.

  Will the i2p relay be able to filter the traffic to only pass through monero-related traffic

This will probably be an option, considering that running a full i2p router can use lots of bandwidth per month. This is similar to how a user can throttle their Monerod with a download and upload rate cap.


Where is the line for solo mining? In the reddit thread, they discussed if 15Kh/s is good hashrate.
Someone argues that he wouldn't solomine below 50kh.
But gingeropolous finds its enough to solo mine.
And the post was 9 months ago.

On pool list I see few pools with 2.85 KH/s and I think isn't that already too low?

I am considering to switch from Ethereum mining to Monero Mining. But instead of joining a big pool to run a own small pool. I estimate that my rigs will bring about 4.4 KH/s.

Question: Is it worth to start own pool with 4.4 KH/s ?

Or rather should I join a small existing pool with small fee ?

It's up to personal preference, really.  On average, block reward is generally evenly distributed according to hashing power.  If you're okay with mining for months at a time without receiving a payout, then perhaps you're better off.  If you win a block while solo mining, you don't have to share the block reward with anyone, nor do you have to pay the fee to the mining pool.


dual wallet confusion Newbie mistake. I created a view-only wallet from within a spend wallet (Ledger enabled) and gave it the same password as the spend wallet. Now both wallets appear under the view-only name and the password won't open either. So should I trash both wallets and recover 'a wallet' using my Ledger seed?  I tried to recover from the failed password prompt but the seed failed the Electrum verification screen? Any help would be appreciated.

Before scrapping those wallets, change one (or, maybe better, both) of their names to something different.  Once they have different names, try to open again.


How to set up xmr-stak-nvidia to solo mining I tried to point it in config.txt to my localhost monerod but fails with

  2017-09-07 00:52:32.560 [RPC0]  ERROR   net.http        contrib/epee/include/net/http_protocol_handler.inl:357  simple_http_connection_handler::handle_invoke_query_line(): Failed to match first line: {"method":"login","params":"login":"4AQSkERTh6MPyUaoqCvwkdLQ19TZ7fgExJf9FWGTmYhrUjo9hWJzrQARzCJwrYxjgfgS7Kp1DWSwQHwzWwzABzF8L4PC2fa","pass":"","agent":"xmr-stak-nvidia/1.4.0"},"id":1}

You can use monero-stratum for solo mining:

https://github.com/sammy007/monero-stratum


Why aren't there any miners written in assembly for x86 / x64 etc? I've seen ethereum miner written in go, monero miners written in C, javascript. I wonder why wouldn't anyone write assembly code for a miner? At least for the hashing part.

The following was taken from here and expanded upon

C is easier to program in, compared to Assembly. There are obvious reasons not worth rehashing.
Being easier to use, C allows you to write programs faster. Generally these programs are           also easier to debug and easier to maintain. Furthermore, it's easier to manage large, complex programs in C.
Often times, code generated by a compiler is equally as good (in terms of speed and efficiency) as hand-written assembler - if not better.
C is pretty darn low-level, and it's rare that you'll want to go much lower. Having an added layer of abstraction is rarely a bad thing.
When you do need to go lower, you can use Assembly, otherwise you can use C.
You can write Assembly in C-code, but not C in Assembly-code.
A C compiler applies optimisations reliably and systematically - not just when it notices the opportunity
Creating a miner is often done in a collaboration and there are far less assembly programmers out there
C++ (which extends C) and is popular with miner development further improves development time, organization, and collaboration


Monero Research Lab - Talent Acquisition. Whom would/do they want? The MRL, to my knowledge, is made up of four anonymous/pseudonymous academics, who primarily specialize in mathematics (mathematical sciences and algebraic geometry).  Are there other specialties that would be useful to the MRL now?  Are just mathematicians needed?  Are there tentative plans for work/research that may more specifically require cryptographers or computer scientists of particular disciplines?

Those follow-up questions are rhetorical, of course.  But I'm asking about "now" on purpose (say, in the first five or so years of the project).  This question would be too general and open-ended to ask what attributes an aspiring MRL member might possess.  Anyone could provide a "good enough" answer to that general question.

What I'm getting at is, for example, I'd like to know (and I especially want others who are more highly-skilled than me to know) what a fly on the wall would hear if that fly were in the room with an MRL researcher as he/she thinks out loud and says, "I would like to complete this research and get on to several other Monero research projects.  If only I had the assistance of some individual who _________________."

I don't mean to speculate.  There may be very few people who actually have specific insights that may enable them to answer this question.  In truth, I'm trying to ask about something way, way above my pay grade (well, well outside my area of expertise), in hopes that an individual with a suitable skill set will come across it and want to contribute (plus it's very interesting and I'm super curious).

I think that anyone who has the abilities and intent to do formal research on crypto/monero related subjects would be welcomed. Of course, this does not mean "limited abilities" and "wishy washy intent". I think we can all apply some common sense to this. However, I don't think there is any particular requirement of academic specialization. If you do, you're in, as in most open source and free software. You might have to show your worth first though, as in most open source and free software.

The legend says you should contact the "Fluffy Pony" if you're interested in becoming part of the MRL, and strange and magical things may happen from there.


How to see that the RingCT commitment parameter H is in fact a multiple of the base point G On the last paragraph of page 7 of Monero Research Lab's paper about RingCT, the author makes some statements to the effect that it is possible to pick a random point on the base curve ED25519 that is on the subgroup generated by its base point G, for example by computing H(G) or H(123456*G), and checking somehow that those points do indeed belong to this group; that is, checking that those points are of the form Q = q*G for some unknown q.

Question: How is it possible to check that a random point belongs to the group generated by the base point, and how costly is this process?

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

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

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

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

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

There are really two answers:

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

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

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

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

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

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

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

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

Remarks:

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

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

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


How does one change Monero's block reward for chosen blocks? For what I mean, see this example in bitcoin-based coins.

We can do this:

CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 2 * COIN;
              if(nHeight == 1)
              {
              nSubsidy = 5 * COIN;
              }
              else if (nHeight == 3339)
              {
              nSubsidy = 10 * COIN;
              }
              else if (nHeight == 3340)
              {
              nSubsidy = 10 * COIN;
              }
              else if (nHeight == 3341)
              {
              nSubsidy = 20 * COIN;
              }
              else if (nHeight == 3342)
              {
              nSubsidy = 30 * COIN;
              }
    nSubsidy >>= halvings;
    return nSubsidy;
}

But how do I do the same with Monero?  I understand Monero does not use nHeight, so the same trick can't be used with Monero, correct?  Or maybe I don't understand something.

I cannot find where even to change the reward setting.

On what setting is it based?

Monero does not use the height, but that doesn't mean a fork cannot. Just pass the block height to get_block_reward (in src/cryptonote_basic/cryptonote_basic_impl.cpp) and you're set. Don't forget to update the tests :)


What is the difference between CryptoNote and CryptoNight? I saw some mining software labelled as CryptoNight miners and they have XMR (Monero) in their list. Many other CryptoNote mining software also has XMR in their list. What is the case? And while adding some tags below I saw CryptoNight-Lite. What are all of these and what are the differences between them?

CryptoNote is the name of the cryptocurrency technology that Monero (and Aeon, and various others) is based on. CryptoNight is the name of the hash function that is used in the CryptoNote Proof-of-Work algorithm. CryptoNight-Lite is a modification of CryptoNight that uses half as much memory and fewer hash rounds, used in Aeon.


Issues starting Oxen Node after installing debs package on a fresh server I'm trying to setup a Monero forked project: Oxen and doing a fresh install of its node on a new ubuntu 20.4 machine.
I'm following these instructions https://docs.loki.network/ServiceNodes/DebianPackageGuide/
sudo curl -s https://deb.loki.network/public.gpg | sudo apt-key add -

echo "deb https://deb.loki.network $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/loki.list

sudo apt update

sudo apt install loki-service-node

After install and I tried to start it, I get the following errors in the log file /var/log/oxen/oxen.log:

This is a fresh install, what is causing this issue?

Make sure /var/lib/oxen/lmdb files are owned by _loki user otherwise you would get this error. This happens when users download the Oxen blockchain manually and then start oxen. Just change ownership of all files to _loki in that directory.


Are Monero hashes generated based off of the block header? Are miners generating POW hashes based off of the block header or is it just guess and check?

Partially. A block hashing blob is constructed which includes the block header, a miner coinbase transaction, a merkle tree root hash of the blocks transaction hashes, and a count of the transactions. This is updated with a nonce and only then hashed and checked.


ed25519 point structs What do each of these structs represent?
What is the difference between them?

typedef struct {
  fe X;
  fe Y;
  fe Z;
} ge_p2;

typedef struct {
  fe X;
  fe Y;
  fe Z;
  fe T;
} ge_p3;

typedef struct {
  fe X;
  fe Y;
  fe Z;
  fe T;
} ge_p1p1;

typedef struct {
  fe yplusx;
  fe yminusx;
  fe xy2d;
} ge_precomp;

typedef struct {
  fe YplusX;
  fe YminusX;
  fe Z;
  fe T2d;
} ge_cached;

They are all group elements (hence the ge_ prefix) and are different representations.

From some ed25519 source:

ge means group element.

Here the group is the set of pairs (x,y) of field elements (see fe.h)
satisfying -x^2 + y^2 = 1 + d x^2y^2
where d = -121665/121666.

Representations:
  ge_p2 (projective): (X:Y:Z) satisfying x=X/Z, y=Y/Z
  ge_p3 (extended): (X:Y:Z:T) satisfying x=X/Z, y=Y/Z, XY=ZT
  ge_p1p1 (completed): ((X:Z),(Y:T)) satisfying x=X/Z, y=Y/T
  ge_precomp (Duif): (y+x,y-x,2dxy)


Hardfork - Pool Failed to parse block I run a small pool with some friends on a fork of the cryptonote pool. I continue to receive "failed to parse block" errors after the hardfork and I cannot seem to figure out what to do. Last time I had this issue I changed the cryptonote-util library to the lucas jones one. However that doesn't seem to have updated or no longer works.

Error: Failed to parse block
at Object.BlockTemplate.nextBlob (/opt/pool2/lib/pool.js:120:23)
at Object.Miner.getJob (/opt/pool2/lib/pool.js:297:41)
at handleMinerMethod (/opt/pool2/lib/pool.js:497:28)
at handleMessage (/opt/pool2/lib/pool.js:611:13)
at Socket.socket.on.on.on.pushMessage (/opt/pool2/lib/pool.js:665:25)
at Socket.emit (events.js:95:17)
at Socket.<anonymous> (_stream_readable.js:765:14)
at Socket.emit (events.js:92:17)
at emitReadable_ (_stream_readable.js:427:10)
at emitReadable (_stream_readable.js:423:5)

I have uninstalled and reinstalled everything, run npm update, etc and I'm at a loss. I have the Wolfram Warptangent version of the node (full node!) and the wallet is also up-to-date.

Thanks!

EDIT
This GitHub link will show repos that have implemented the Ring CT changes. Scroll to the right. It isn't necessary to manually make the changes like I did.

A pool update is needed for the last fork.
The patch is at https://paste.fedoraproject.org/506116/17116821/
There are updated trees which include this patch, but I do not have URLs handy.

After applying to the node-cryptonote-util tree, I think "npm rebuild" will be enough to get you going.


What's the maximum amount of transactions returned by the get_transfer RPC method? I'm using the get_transfer RPC method.

I'd like to know what the maximum amount of transactions this API can return? Can I filter it using timestamp or pagination instead of block height?

As per the documentation you linked to, you can filter by min_height/max_height and account_index/subaddr_indices, not timestamp. As Monero blocks are mined roughly every 2 minutes, you can use heights as an approximation of time.

There is no restriction imposed as to the amount of transactions returned other than by the filter options.


Is there a way to know how many people are using my public remote node? I am running a public remote node along with a network crawler (xmr.be) and I would like to know how many people are using my node to sync their wallet.

The only metric that the daemon is giving me is the number of incoming/outgoing connections, without differentiating between wallet connections and P2P connections.

Is there a way to know the number of wallet connections?

The only metric that the daemon is giving me is the number of incoming/outgoing connections, without differentiating between wallet connections and P2P connections.

That's not correct, the daemon does differentiate: those are all P2P connections.

Recent daemons do report the number of RPC connections in the getinfo RPC, in the rpc_connections_count field. This includes nodes syncing, but also nodes using the RPC for other business, such as sending a one off transaction.


Can view-only wallet create unsigned tx via RPC call? Can I use RPC to get back a string representing the unsigned tx file?

I'd like to split an unsigned tx into QR codes, and I'd like my app to run the process instead of parallel user interaction with wallet terminal.

Also, can my cold app counterpart sign the file via RPC?

The documentation on getmonero.org said no outputs for transfer command...

I have been trying to accomplish exactly what you are describing for the past few weeks and I have come to the conclusion that this is not possible via RPC. You can only do this via the CLI. I am in the process of writing a RPC wrapper around the CLI so that I can make programmatic RPC calls that issue the proper CLI commands. A step-by-step guide around the CLI process can be found here: How do I use cold transaction signing? but you've probably seen this already. I am using this as a guide for the RPC wrapper.


Monero still in my wallet as unmixable I can't get monero out of my wallet, It looks like it was old dust accumulated, but it sums out to 8xmr, then I added more fresh monero but now I cant get it out, I've tried sweep unmixable and sweep all in both cli and gui with no luck, always return some other error, any help would be appreciated, thanks.

Actually making smaller transfers fix it, I had 20.9 xmr total and started by making 5.2xmr transfers, then the cli itself break it in 3 or 4 even smaller payments with fees each, but it all when tru at the end, Thank You all for your help!


Meaning of "62 days ahead" message after full node has finished synchronizing What does the message "62 days ahead" message mean?

My full node has finished synchronizing (I confirmed this by comparing my block height with both moneroblocks.info and Explore.MoneroWorld.com)

The message means that your block height is 62 days ahead of a block which you just were told was mined (on top of a block way back in history).

As you verified your block height was correct (as of the time of that image)

The blocks that you are "62 days ahead" of were created by miners that remained on Monero chain(s) that we hard-forked away from.

Monero's PoW algorithm (CryptoNight), by closing the performance gap between CPUs, GPUs, and ASICs, has become one of the more profitable coins to mine with a botnet. There are a number of infected computers believed to still be mining on the old chain(s) without knowing it.

Botnet operators may or may not choose to attempt to upgrade Monero botnet miners (assuming they retain sufficient control to do so which is not always the case) depending on profitability calculations vs increased risk of detection (when making the upgrade) and other factors.

Not every miner on the wrong chain is part of a botnet. Some miners choose not to move to a new fork (see ETC vs ETH mining today) on purpose and others do not follow Monero closely enough to upgrade in time.


If I exposed my public view key and public spend keys, what gets compromised? If I expose my public view key and public spend key, what can someone do with it?

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


What is the difference between Monero (XMR) and Nav Coin (NAV)? Can someone please compare the privacy differences comparing Monero vs Nav Coin? I have heard that each addresses privacy using different methods, and I am interested in what they do differently.

Despite both being advertised as privacy-focused cryptocurrencies, they are very different.

Monero uses ring signatures, RingCT, and stealth addresses to hide information on the blockchain. For every transaction, there is no way for an outside observer to determine the sending address, the amount sent, or the receiving address. Optional transparency can be provided off-chain by giving the desired person(s) the view key. Monero can be used with Tor or I2P manually, and Kovri is being worked on to provide native anonymous routing functionality.

Nav Coin uses trusted clustered servers to process transactions. When the "anonymous" option is selected, transactions are sent to these servers, which conceal the recipient address from others. It does not protect the sender, it does not hide the amount, and there is a trusted party that is omniscient in this process.

In summary, Monero protects significantly more information about all transactions (not just a select few) without using a trusted party.


Why is syncing Monero using a regular rotating disk drive so slow on a VPS? I managed to find a decent deal on a large 200GB vps for $5, but the only issue is that its on a regular rotating disk and not an SSD. I tried syncing ./monerod and its so slow to sync even 2%. It took over 24 hours. It's a 2 core cpu with 1GB of ram. Why is it so slow and how can I improve its sync speed?

Why is it so slow

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

and how can I improve its sync speed?

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


Can you make a send transaction with a monero remote node setup? Setting up a remote node requires access to a full node that has the entire blockchain downloaded right?
So does this mean my remote node can do everything as if it had the
full blockchain downloaded?
What are some cons about this setup?
Can I make a send transaction using a remote node setup? Currently the remote node is setup to node.moneroworld.com port 18089

Yes, you can.
First of all, a "remote node" simply means a full node which is not running on the same machine as your wallet software. Any remote node is a full node. Maybe you control it, maybe you don't. If you connect to some node on node.moneroworld.com then those will belong to other people who're running a full node and have opened them to remote wallets.

In the diagram above, we can say the following:

Network 2 is probably the most common set-up. One machine, one node, one wallet. Node N5 is a localhost node to wallet W4 because they're on the same computer as the node. The node N5 is not accepting wallet connections from outside, so it can not be used as a remote node. This is the default set-up for people running a full node. Of course, the user can add more wallets easily, they will all connect to N5 automatically.

Node N1 is a localhost node to wallets W1 and W2 because they're on the same machine as the node.
The node is also accepting wallet connections from local network and because of that N1 is a remote node to wallet W3 since N1 and W3 are running on different machines. Since N1 is not accepting wallet connections from the internet but just from local network, we could say it's a private remote node.

Machine PC4 runs only the wallet W5 and no node. It must connect to some remote node to be able to refresh the wallet and send transactions. It's connected to a public remote node N2. If owner of machine PC4 wants to sync another wallet, he must connect it to a remote node as well. Since every new wallet refresh requires sending some data between the wallet and the node, it's not efficient to use remote nodes for many wallets. Would be better to download the whole blockchain by running a node and then you're much faster to sync each wallet.

Setting up a remote node requires access to a full node that has the entire blockchain downloaded right?

"Setting up a remote node" just means that you run your node with a few extra parameters, and that you allow your firewall to accept incoming connections, as explained on the same site you linked. So, a remote node is a full node and it also has the full blockchain downloaded - just like any node.

How To Include Your Node On Moneroworld
If you would like to offer your node up for inclusion in the Moneroworld Network of Open Nodes, you can simply add the code bellow to the launch of your daemon (and open your firewall), and the MoneroWorld script will sniff you out and add your node to the random list.

--rpc-bind-ip YOUR.EXTERNAL_IP.GOES.HERE --rpc-bind-port 18089 --restricted-rpc --confirm-external-bind

So does this mean my remote node can do everything as if it had the full blockchain downloaded?

"as if it had the full blockchain downloaded" doesn't make sense. Any node has the full blockchain downloaded by definition. If you mean whether your wallet connected to a remote node can do everything then yes, it mostly can. You can refresh and send, but can't mine or control the node in other ways.

What are some cons about this setup?

It's slower and wasteful if you need to sync multiple wallets
It's putting extra load on people who volunteer to run their remote nodes
It doesn't help the network
It allows your TX-es and IP to be linked by the node
Maybe some other privacy loss (because the node provides you with the decoy outputs as well but I'm not sure if the wallet or the node decides the block heights)

Can I make a send transaction using a remote node setup? Currently the remote node is setup to node.moneroworld.com port 18089

Yes.


How to synchronize the GUI wallet using the blockchain bootstrap I'm having trouble trying to sync the GUI wallet with the blockchain. I'm trying to use an old 2008 Macbook which I had lying around, with OS X El Capitan (HDD, 8gb RAM, 200gb free storage). I've tried several times now but the furthest I have got is about 50% before it freezes and will not continue (even after restarting all processes). I suspect the Macbook is a bit too old to cope.

So instead, I've now downloaded the blockchain bootstrap from https://downloads.getmonero.org/blockchain.raw

How do I now use this with the GUI wallet? Can I drag and drop it into one of the folders in /Users/your username/.bitmonero ? If so, where? Is there anything else I need to do?

(I'm not very familiar with the CLI I'm afraid).

I have a working Monero (internal) node running on a 2010 Mac mini with 8 GB RAM and a slow 5400 rpm disk (which is the bottleneck I have read), so probably quite similar specs as your 2008 MacBook.

If you've installed the GUI in the Applications folder, then you should be able to import that raw blockchain into the daemon's LMDB database with the commands below.

However, you'll need to open the Terminal for that. Once in there, I suggest you first remove any failed earlier attempt, and then start the import:

# Clean-up first.
rm -r ~/.bitmonero

# Import the file.
/Applications/monero-wallet-gui.app/Contents/MacOS/monero-blockchain-import --input-file ~/Downloads/blockchain.raw --verify 0 --database lmdb#fastest

Note that this import took about 10 hours on my system. You'll end up with a ± 11 GB data.mdb file in the directory ~/.bitmonero/data.

Once that is complete, you can restart the GUI and the daemon. Hopefully, it should be able to continue for the last few blocks since the blockchain snapshot was made, and stay up-to-date.


Does recipient of monero see wallet address? I want send some Monero coins to someone else's address. Will the the receiving wallet see my wallet address or not?

I am using full client with GUI.

No they will not see your address.

In the transaction recorded on the public blockchain, some of the inputs will reference outputs (belonging to you) of a previous transaction. Knowledge of those outputs alone will not be enough to find your public address.

Even if someone knew your wallet address, without your private view key, they will not be able to know which transactions are yours and how much monero you have.


How to Generate a Blob for PoW Hashing The Cryptonight PoW hash function (cns008) expects an input (a blob on which to mine a new block).

I know that a mining blob can easily be obtained via the monerod daemon's JSON-RPC interface by calling getblocktemplate. However,  for a mining pool project I am investigating whether or not I can generate the blob myself and reproduce Monero project's logic.

From the Monero project's source, I traced the above RPC call to this:

  blobdata get_block_hashing_blob(const block& b)
  {
    blobdata blob = t_serializable_object_to_blob(static_cast<block_header>(b));
    crypto::hash tree_root_hash = get_tx_tree_hash(b);
    blob.append(reinterpret_cast<const char*>(&tree_root_hash), sizeof(tree_root_hash));
    blob.append(tools::get_varint_data(b.tx_hashes.size()+1));
    return blob;
  }

Here, they:

initialize a blob with a block header, then
append the root of some tree data-structure that stores transactions (presumably a Merkle tree) to the blob, and finally they
append the number of transactions in this tree to the blob.

Unfortunately, the rest of logic is refactored into so many fragments in their codebase that I gave up trying...

So once, again my question is how can I generate the blob needed, and more specifically could somebody explain in pseudo-code terms what get_block_hashing_blob is doing under the hood?

The process to compute the mining blob can be described by the following pseudo-code:

miner_transaction = build_miner_transaction(...)
miner_transaction_id = compute_transaction_id(miner_transaction)
header = serialize(build_block_header(...))

transaction_ids = append(miner_transaction_id, other_transaction_ids...)
count = serialize_varint(number_of_transactions)  // miner transaction included
tree_root_hash = compute_merkle_tree_root_hash(transaction_ids)

blob = append(header, tree_root_hash, count)

Then the blob is hashed using the Cryptonight function.

Some details about the formats of block headers and miner transactions can be found in What is the format of a block in the Monero Blockchain.


Can a full Monero node be restricted to run only at specific times? I have an ISP that provides 5000GB of data to use between 1am and 7am. Is there any way to run the full node, but run it only during that time period? I don't have any data to spare during the day, but the 5000GB is barely touched, except for a few linux torrents.

You can use cron to start and stop monerod at the times you want.
Best is to run monerod with the --detach flag to run as daemon, then run without it but the exit command when you want to stop it:

monerod --detach
monerod exit

The second line will exit the first one.

In a crontab specification:

0 1 * * *    monerod --detach
0 7 * * *    monerod exit

This will start monerod at 1am, and stop it at 7am. See man 5 crontab for more info about crontab. Add any further arguments to the above.


Monero OpenAlias vs Boolberry blockchain aliasing system How does Monero OpenAlias compare with the Boolberry blockchain aliasing system?

Is the main difference that a domain name is needed for Monero and mining an available alias is required for Boolberry?

What are the other primary differences?

BBR aliasing system has many problems, being linked to your address what happens if you lose your private key? There is no way to recover your alias that you could have shared with your friends and family, there is also another problem with the variants, you will run out of simple aliases at some point and it will starting becoming confusing (Alice1, Alice2, Alice3, therealAlice...) at some point its simpler to have a personal address book with Alice's BBR address next to her name. OpenAlias does not requires mining, its a simple system that requires only a few extra settings in your Domain Name Registrar and you could use any cryptocurrency with it even Boolberry. You could maintain any domain and add/remove a Monero address associated with it at any time, all the person sending Monero to you need is the domain name. It already works within the simplewallet through the transfer command.


Why are there 4 types of range proofs in the Monero code base? In the code, there is this:

enum RangeProofType { RangeProofBorromean, RangeProofBulletproof, RangeProofMultiOutputBulletproof, RangeProofPaddedBulletproof };

[source]

I believe:

RangeProofBorromean is to prove a value is within a range, using Borromean.
RangeProofBulletproof is to prove one value is within a range
RangeProofMultiOutputBulletproof is to prove multiple values are within a range
RangeProofPaddedBulletproof is to prove multiple values are within a range, but the number of values needs to be padded.

My confusion is why are all of these distinctions needed? If I call bulletproofProve([]values) Proof and then just pad inside of the prove function if I need to, then this would account for all possibilities, unless I'm missing something

They all essentially do the same thing, prove a value falls within a range, but have speed/optimization differences. The latter two allow aggregating multiple proofs into a single proof for example. Again for optimization purposes.

  My confusion is why are all of these distinctions needed?

Every time a new type of signature is added to Monero (or an existing type modified/improved), a new type is obviously created and the old ones remain so that past transactions (using those older types) can still be validated. If they were removed, you wouldn't be able to verify the entire blockchain all the way back to the first block.


Payment received with old wallet not shown in new one I was mining (slowly) on xmrpool.eu since 2017 and finally received a payment. The problem is that when I open my wallet with the GUI, it doesn't show the address I was mining with neither the payment.

How can I solve it ?

Thanks in advance.

You might be using a payment id with your address which could be why you might not see the same address. To verify you can tell if the address is an integrated payment id, by see if the address looks similar. If it is, then you have it in your wallet. Also make sure you have your wallet fully synced too.


Trouble compiling aeon node on ubuntu 16.10 I have a question, following the instructions on here:

How do I install Aeon on Ubuntu?

I cannot get the node to compile on ubuntu 16.10. Here is what shows in the terminal:

make mkdir -p build/release cd build/release && cmake -D CMAKE_BUILD_TYPE=Release ../.. -- Boost version: 1.61.0 -- Found the following Boost libraries: -- system -- filesystem -- thread -- date_time -- chrono -- regex -- serialization -- program_options -- atomic -- Found Git: /usr/bin/git -- Configuring done -- Generating done -- Build files have been written to: /home/bioniix/git/aeon/build/release cd build/release && make make[1]: Entering directory '/home/bioniix/git/aeon/build/release' make[2]: Entering directory '/home/bioniix/git/aeon/build/release' make[3]: Entering directory '/home/bioniix/git/aeon/build/release' make[3]: Leaving directory '/home/bioniix/git/aeon/build/release' make[3]: Entering directory '/home/bioniix/git/aeon/build/release' fatal: No names found, cannot describe anything. CMake Warning at src/version.cmake:3 (message): Cannot determine current revision. Make sure that you are building either from a Git working tree or from a source archive.
make[3]: Leaving directory '/home/bioniix/git/aeon/build/release' [ 0%] Built target version make[3]: Entering directory '/home/bioniix/git/aeon/build/release' make[3]: Leaving directory '/home/bioniix/git/aeon/build/release' make[3]: Entering directory '/home/bioniix/git/aeon/build/release' [ 1%] Building C object external/miniupnpc/CMakeFiles/upnpc-static.dir/igd_desc_parse.c.o In file included from /usr/include/stdio.h:27:0, from /home/bioniix/git/aeon/external/miniupnpc/igd_desc_parse.c:10: /usr/include/features.h:148:3: error: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Werror=cpp] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" ~~~~~~ cc1: all warnings being treated as errors external/miniupnpc/CMakeFiles/upnpc-static.dir/build.make:62: recipe for target 'external/miniupnpc/CMakeFiles/upnpc-static.dir/igd_desc_parse.c.o' failed make[3]: * [external/miniupnpc/CMakeFiles/upnpc-static.dir/igd_desc_parse.c.o] Error 1 make[3]: Leaving directory '/home/bioniix/git/aeon/build/release' CMakeFiles/Makefile2:140: recipe for target 'external/miniupnpc/CMakeFiles/upnpc-static.dir/all' failed make[2]:  [external/miniupnpc/CMakeFiles/upnpc-static.dir/all] Error 2 make[2]: Leaving directory '/home/bioniix/git/aeon/build/release' Makefile:138: recipe for target 'all' failed make[1]:  [all] Error 2 make[1]: Leaving directory '/home/bioniix/git/aeon/build/release' Makefile:20: recipe for target 'build-release' failed make: * [build-release] Error 2

Interesting. I added a single argument this time:

git clone --single-branch https://github.com/aeonix/aeon.git

By default this clones from the master, which I needed to do for macOS (to include some last-minute fixes), and I just reused the same syntax on Ubuntu MATE. Maybe regular Ubuntu behaves slightly differently. Please retest with that --single-branch flag. If it still fails, I suggest to ask on Bitcointalk, and relay your findings here.


How to configure my computer to mine when not in use in Windows? I have an older gaming computer with an AMD R7 370 that I would like to mine Monero with when not in use. I am using Wolf's open-source AMD miner. What steps can I take, in Windows 10, to have the computer mine when I am not using it? Can the script automatically start up on boot so that I don't have to manually tell this script to start each time I restart my computer?

Can I set it to mine with either a CLI or in the background (no interface)?

That's easy on a windows machine by adding it as a windows-service and the solution can be tailored for different systems.


How to change the standard port for monero on linux and windows? Where can I change the standard port for monero core wallet when installing on linux and windows?

The monerod daemon listens to RPC commands on port 18081 by default (28081 for testnet). Wallets such as monero-wallet-cli will connect to this port by default to interact with the daemon. This default can be changed with the following monero-wallet-cli command line options:

--daemon-address a.b.c.d:N
 --daemon-port N

These will will use port N. For instance, if yo're running your webserver with a 1.2.3.4 external IP, and want to use port 8080, you'd use:

--daemon-address 1.2.3.4:8080

Note that if you allow your daemon RPC to be reachable from the Internet, you may want to set a user/password, using the --rpc-login username:password option to monerod (optional, since the daemon doesn't know your keys, only the wallet does), and use --restricted-rpc to avoid people doing things like mining on your daemon.


XMR-STAK [CUDA] Error: the launch timed out and was terminated I'm using Ubuntu 16.04 and xmr-stak-portbin-linux.tar.gz

The miner when run manually with Nvidia GPU, runs without error, but gives error when run as a startup service.

Earlier, I was doing only CPU mining. I created a startup service xmr-service to run the miner at startup, which worked fine

[Unit]
Description=xmr-stak

[Service]
ExecStart=/usr/local/tmp/xmr-stak.sh -c "/usr/local/tmp/config.txt"
User=root

[Install]
WantedBy=multi-user.target
This was working fine at startup for CPU mining.

Now the system also had Nvidia Quadro K620 GPU but with no installed drivers. So I installed Nvidia drivers 384.81 and Cuda 9.0.176

Then I ran xmr-stak.sh manually.
Following is the nvidia.txt that the miner generated.

"gpu_threads_conf" :
[
  // gpu: Quadro K620 architecture: 50
  //      memory: 1781/1995 MiB
  //      smx: 3
  { "index" : 0,
    "threads" : 90, "blocks" : 9,
    "bfactor" : 0, "bsleep" :  0,
    "affine_to_cpu" : false,
  },

],

The miner crashed, so I changed the parameters to following:

"gpu_threads_conf" :
[
  // gpu: Quadro K620 architecture: 50
  //      memory: 1781/1995 MiB
  //      smx: 3
  { "index" : 0,
    "threads" : 1, "blocks" : 1,
    "bfactor" : 8, "bsleep" :  25,
    "affine_to_cpu" : false,
  },

],

On again running the miner manually, the miner was running with these parameters.

Then I did

sudo systemctl daemon-reload
and restarted the system

On sudo systemctl status xmr-service , it shows following:

workstation xmr-stak.sh[795]: [2017-12-12 18:16:37] : Result accepted by the pool.
workstation xmr-stak.sh[795]: [2017-12-12 18:16:39] : Result accepted by the pool.
workstation xmr-stak.sh[795]: [2017-12-12 18:16:42] : Result accepted by the pool.
workstation xmr-stak.sh[795]: [CUDA] Error gpu 0: </home/fireice/xmr-stak/xmrstak/backend/nvidia/nvcc_code/cuda_extra.cu>:244
workstation xmr-stak.sh[795]: terminate called after throwing an Instance of 'std::runttme_error'
workstation xmr-stak.sh[795]: what(): [CUDA] Error: the launch timed out and was terminated
workstation xmr-stak.sh[795]: /usr/local/tmp/xmr-stak.sh: line 3: 824 Aborted (core dumped) $SCRIPT_PATH/stak/ld-linux-x86-64.so.2 --library-path $SCRIPT_PATH/stak $SCRIPT_PATH/stak/xmr-stak $*
workstation systemd[1]: xmr-stak.service: Main process exited, code=exited, status=134/n/a
workstation systemd[1]: xmr-stak.service: Unit entered failed state.
workstation systemd[1]: xmr-stak.service: Failed with result 'exit-code'.

The miner when run manually with Nvidia GPU, runs without error, but gives error when run as a startup service. Also the startup service worked fine with only CPU.

What could be the problem?

I haven't played with my systemctl script in a while, but here are my notes. They are close to yours, except for my file name is xmr.service and there are two additional commands at the end. Hope this helps.

Create systemd startup script
Create new file xmr.service in /etc/systemd/system

Add the following snippet:

[Unit]
Description=XMRig
After=network-online.target

[Service]
ExecStart=/PATH/TO/MINER

[Install]
WantedBy=multi-user.target

Perform these commands:

systemctl daemon-reload

systemctl start xmr.service

systemctl enable xmr.service


Where are the input keys stored for a transaction (understanding vin field) I am currently implementing the heuristic 1 algorithm from this paper https://eprint.iacr.org/2017/338.pdf for a university project. (pretty interesting btw worth reading :) ).

My problem currently is, I don't fully understand the vin field, which I need for the algorithm.

So what I know:

The vin field contains all input transactions for the whole transaction.

Example would be a vin field containing 3 inputs, this 3 inputs represent the denominations of the full transaction amount.

Each of this 3 inputs has also a key_image field. It is there for double spending reasons. Each key_image exists only once on the blockchain. For simplicity we say key_image = HASH(key_offset), where key_offset is the public key of the real spender in this vin input.

The values in key_offsets are: The public key of the spender + the mixins used. So key_offsets_size = spender_key + N * mixin_key.

I also know that key_offsets are stored differentially, meaning key_offsets = [1,1,1] => real index of inkeys: [1,2,3].

So I am pretty confused how it can be that the same index in key_offsets can be more than once on the blockchain.

For example I querried block X and I had key_offsets = [ 1 ], then I querried block Y (Y > X) and got the same key_offsets.

What am I missing here? Where are "the real" input keys stored and how can I acquire them? Would be awesome if someone could point me on the correct API call.

UPDATE:

For example I queried block 345 and 1247. Got tx
9ecdadf8b95aa0a7b754559f5fd7a9bb0f5014c4107b3dc6b3331430b5ea984d in 345
and ed4717dd86e5b033c36df3b41a3a5296f392e3524651c79792e9b39674c7f1ef in 1247.

When I get all the denominations from 345:

{
  "key":
  {
    "amount": 458444,
    "k_image": "2c03aa742e881a41588827ea8680f68ea3e6988917c832767e951f3ff7457b17",
    "key_offsets": [
      0
    ]
  }
},

and for 1247:

{
  "key":
  {
    "amount": 307304,
    "k_image": "fca0574448356fedf7493310fba22a717c0c7bd7f4acca03fb17bb8d582eb5ef",
    "key_offsets": [
      0
    ]
  }
},

  So for each output you spend, you provide a set of key offsets, one of which will be yours...

This should mean that both txs use the tx with the index 0 as mixin. But there is only 1 offset present in the transactions meaning that the index 0 is the transaction itself.

So I am pretty confused how it can be that the same index in key_offsets can be more than once on the blockchain.

Let's take a step back.

Every output created (i.e. once mined, added to the blockchain), has a global index (its key offset).

Every transaction spends previously created outputs - it uses outputs as inputs to fund the transaction.

Now, when you create a transaction, for each output you own and are spending (so using as an input), you mix with other decoy outputs (other outputs on the blockchain, not owned by yourself). Collectively this is a set of key offsets (the global index of each output on the blockchain that is a member of this collection).

So for each output you spend, you provide a set of key offsets, one of which will be yours, the rest other peoples. This of course means other people creating transactions can also include your owned output indices in their set of key offsets.

As an observer, you can look at any given set of key offsets in a transaction, but have no idea which is the one actually being spent. Therefore, the fact you may see a particular output index in several different transactions, you have no way of knowing which, if any, of the transactions, are actually spending it.

  Where are "the real" input keys stored and how can I acquire them?

If this is not clear from above, the input keys are stored on the blockchain. Each actual key is a previously created output and can be referenced (looked up), using its global index (key offset). You can use the daemon RPC command get_outs to obtain the actual key for an index. E.g. (on testnet here):

$ curl -X POST http://127.0.0.1:28081/get_outs -H 'Content-Type: application/json' \
       -d '{"outputs":[{"index":127232}]}'
{
  "outs": [{
    "height": 877775,
    "key": "3ab3f615dc7ee403d753f3c3604afe57af3bff62f2d95ae74c3ca5603295811c",
    "mask": "843ade9a400589ea368e639aec54a7627d06180eed9fbc5d3149f44bf452f3d9",
    "txid": "0000000000000000000000000000000000000000000000000000000000000000",
    "unlocked": true
  }],
  "status": "OK",
  "untrusted": false
}

UPDATE

Everything above relates to the current transaction version, v2 (i.e. RingCT), which covers the vast majority of Monero transactions. The question however has since been been updated to include references to pre-RingCT transactions as it now mentions heights 345 and 1247, so it's worth noting the following from the v1 transaction spec, section 3.2.2:

  - key_offsets: The list of offsets in the global array of outputs
  of type txout_to_key having the same amount as the input. The
  first value is the ordinal number of the first referenced output
  among those having the same amount. Each of the following values
  is the offset of the next referenced output relative to the
  previous one. One of the outputs referenced is the actual output
  being spent, but only the sender known which one it is. The array
  of the corresponding public keys is a part of one-time ring
  signature verification algorithm input [CNS002].

To lookup a v1 key from its offset, you must also provide the amount field, because as the spec states:

  The first value is the ordinal number of the first referenced output
  among those having the same amount.

And therefore the RPC command to lookup, includes the amount:

$ curl -X POST http://127.0.0.1:18081/get_outs -H 'Content-Type: application/json' \
       -d '{"outputs":[{"index":0,"amount":307304}]}'
{
  "outs": [{
    "height": 1123,
    "key": "45519224a687ec4fbb2675de996d4e3d8e8de8f32b7d6a57d6372f2f96908794",
    "mask": "8de5816e54e57d4c722e905aa5f9931da525ee351c29bb346aa1131f14937a9b",
    "txid": "0000000000000000000000000000000000000000000000000000000000000000",
    "unlocked": true
  }],
  "status": "OK",
  "untrusted": false
}

Therefore:

  This should mean that both txs use the tx with the index 0 as mixin.

As you referenced txs in blocks 345 and 1247, these are v1 transactions. The output at index 0 for amount 307304, is not the same as the output at index 0 for amount 458444. They are different outputs.


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

Beam authored a similar piece on a comparison between Beam, Monero, and Zcash that I recommend you read here to get a different perspective. I personally disagree with some points, but the high-level details are more or less correct.

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

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

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

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

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


What is a valid public key in Monero? I know that it's important to run sc_reduce() first to filter some invalid scalar when I need a private key.

How about public keys in Monero? How can I ensure its format is right?

Please help to answer it, many thanks!

sc_reduce just takes a 256 bit number and reduces it mod 𝑙 to yield a scalar of the correct curve order. Nothing special. Any number between 0 and 𝑙 is a valid scalar.

For a point (which is what a public key is) however, the bytes need to first decode to a point and this can vary based on what format has been used to store the point. Assuming it's a compressed 32 byte point, this will consist of the y coordinate (a scalar) combined with a 1 bit sign (used during recovery). Thus after taking the binary of the y coordinate, one must recover the x coordinate. This is a little more involved but covered perfectly well in [ref]. Having recovered x one can then check the resulting  x,y point is actually on the curve with a check such as: (-x*x + y*y - 1 - d*x*x*y*y) % q == 0. In practice, you will be using a tried-and-tested library to do any decoding / point operations.


Will Monero mnemonic seeds need to be converted to BIP 39 for standardization reasons? According to this answer it was suggested that Monero will likely eventually need convert Electrum Wallet compliant mnemonic seeds to BIP 39 compliant mnemonic seeds for compatibility/integration reasons.

Are there any currently efforts to replicate this wallet generation standard in a BIP 39 standard?

Have there been any payment processors, merchants, or hardware wallet companies that are known to have requested this change in order to ease Monero integration?

To answer if it will be converted is really opinion-based as I'm not aware of anybody working on it.

To answer if there's an actual need is a harder one, but let's try.

Trezor support is on the way, despite Monero being a deviant child and daring to go its own way. If there's a real need for a BIP-39 variant, it will be done by whomever finds it important enough to do it. It's an open-source project after all so no permission is needed to come up with a scheme which would enable Monero wallet generation from the same word-list as used by Bitcoin. There shouldn't be any obstructions for adding such an option to the current wallet software, if someone was to code it and make a pull request.

But, let's consider few things. Just because something has a BIP number, and is presented in a clear and concise way, doesn't mean it's a standard, or a good solution for that matter. See also here for some considerations.

Current scheme used by Monero has some neat features which may be seen as advantageous over BIP-39:

It's fairly simple and is a reversible conversion between any integer and a mnemonic. This means you can also find the mnemonic from your seed, even if your seed was generated by other means. BIP-39 uses hashing, so there's no way back - you can't work out the mnemonic from the seed.
The above enables having different dictionaries / languages all encoding the same seed and you can freely transform from one to the other. I could even make my custom secret dictionary and use it without telling anybody, so nobody would even know what my mnemonic is actually used for. As long as I don't lose the dictionary myself, I'm safe.
The scheme uses a wordlist prefix where every word has a unique first n letters. This allows for some optimizations. For example the dictionary storage requirement of some software used just to restore a seed could be reduced. It also allows users to mistype the remaining letters or even use alternative words which have the same first n letters.

Yes, you'd have to keep the dictionary around otherwise you lose the way to recover the seed. I'd argue you always need to keep something, even if it's a piece of software or a print-out of BIP-39 paper. What if in 10 years you can't google BIP-39, or the dictionary used in 2016?

Considering the above, what would be the advantage of moving to BIP-39 scheme? Which problem would it solve? Adding support is a non-issue, but why would one want to replace the current scheme by BIP-39? Chances are that it hasn't been adapted by Monero simply because there's no apparent benefit to it. To do anything, there needs to be a motivation. So, before talking about implementing it, one would have to ask first the question - which is the benefit? There are no standards in this space, and just because someone came up with a scheme which gained some traction doesn't make it a standard which everyone needs to follow.

If by convert you meant: take the Monero wallet, and generate a BIP-39 mnemonic from it - it's practically impossible. This is because BIP-39 is a one-way function, as mentioned above.

Let's consider the purpose of BIP-39,

  It consists of two parts: generating the mnemonic, and converting it
  into a binary seed. This seed can be later used to generate
  deterministic wallets using BIP-0032 or similar methods.

and how it works.

  To create a binary seed from the mnemonic, we use the PBKDF2 function
  with a mnemonic sentence (in UTF-8 NFKD) used as the password and the
  string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt.
  The iteration count is set to 2048 and HMAC-SHA512 is used as the
  pseudo-random function. The length of the derived key is 512 bits (=
  64 bytes).

So, we have a way of going from "anything" to 512 bits. In Bitcoin, these are used to further derive address keypairs using some HD scheme, like BIP-32, which uses secp256k1 curve to derive the keypairs, so for sure there would have to be some major changes done to it to be able to generate Monero keypairs.

Now, if we want to go from 512 bits to a Monero wallet, what are the options?

You could use the first 256 bits as the private spend key and 2nd 256 bits as the private view key. This would make the 2 keys independent, so it would break compatibility with Monero seed scheme.
You could use the first 256 bits (or hash the 512 bits to 256 bits) as the monero seed, and go from there. This would let you keep the compatibility with the current Monero scheme as you could also generate a Monero mnemonic from it, if you would want to do so.
Something else.

On another note, Monero doesn't really need HD wallets, as there is no problem it would be fixing, unlike with Bitcoin where you're supposed to use a different address each time. There's a saying: "To a hammer, everything looks like a nail." For some cases there could be an use, but then the above point of being open-source would apply again.


Who owns and operates monero.org? Who owns and operates monero.org?

Has there been any attempt by the Monero core team to gain control of that domain name?  Has there been any evidence of malicious behavior from its owner or operator so far? Was getmonero.org chosen as the official domain only because monero.org was already registered?

Yes, the core team chose getmonero.org as the best available domain at the time because the owner of monero.org never self identified or otherwise communicated with the core team. According to well known Monero community member Gingeropolous:

  monero.org is owned and operated by an unknown party. They are apparently not part of the community because they haven't spoken up. Monero.org has been benign up to this point, but I wouldn't download anything from that site. My level of distrust stems from the fact that the cryptonote environment is relatively hostile (IMO, no one else could have performed the 201623 attack and, in general, the overall scam is hostile to the entire crypto community)

Based on the above should be no surprise that the domain registration is anonymous

  Raw WHOIS Record
  Domain Name: MONERO.ORG
  Domain ID: D169443173-LROR
  WHOIS Server:
  Referral URL: http://www.godaddy.com
  Updated Date: 2016-07-20T16:33:55Z
  Creation Date: 2013-08-15T21:54:22Z
  Registry Expiry Date: 2017-08-15T21:54:22Z
  Sponsoring Registrar: GoDaddy.com, LLC
  Sponsoring Registrar IANA ID: 146
  Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
  Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited
  Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
  Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited
  Registrant ID: CR175374311
  Registrant Name: Registration Private
  Registrant Organization: Domains By Proxy, LLC
  Registrant Street: DomainsByProxy.com
  Registrant Street: 14747 N Northsight Blvd Suite 111, PMB 309
  Registrant City: Scottsdale
  Registrant State/Province: Arizona
  Registrant Postal Code: 85260
  Registrant Country: US
  Registrant Phone: +1.4806242599
  Registrant Phone Ext:
  Registrant Fax: +1.4806242598
  Registrant Fax Ext:
  Registrant Email: MONERO.ORG@domainsbyproxy.com
  Admin ID: CR175374312
  Admin Name: Registration Private
  Admin Organization: Domains By Proxy, LLC
  Admin Street: DomainsByProxy.com
  Admin Street: 14747 N Northsight Blvd Suite 111, PMB 309
  Admin City: Scottsdale
  Admin State/Province: Arizona
  Admin Postal Code: 85260
  Admin Country: US
  Admin Phone: +1.4806242599
  Admin Phone Ext:
  Admin Fax: +1.4806242598
  Admin Fax Ext:
  Admin Email: MONERO.ORG@domainsbyproxy.com
  Tech ID: CR175374314
  Tech Name: Registration Private
  Tech Organization: Domains By Proxy, LLC
  Tech Street: DomainsByProxy.com
  Tech Street: 14747 N Northsight Blvd Suite 111, PMB 309
  Tech City: Scottsdale
  Tech State/Province: Arizona
  Tech Postal Code: 85260
  Tech Country: US
  Tech Phone: +1.4806242599
  Tech Phone Ext:
  Tech Fax: +1.4806242598
  Tech Fax Ext:
  Tech Email: MONERO.ORG@domainsbyproxy.com
  Name Server: NS71.DOMAINCONTROL.COM
  Name Server: NS72.DOMAINCONTROL.COM
  DNSSEC: unsigned

      Last update of WHOIS database: 2016-08-25T05:35:08Z <<<


Setting XMR-STAK as startup service in Ubuntu 16.04 I'm running Ubuntu 16.04 as VMWare Virtual Machine. Downloaded xmr-stak-portbin-linux.tar.gz.

I created a xmr.service file in /lib/systemd/system/

[Unit]
Description=xmr
After=network.target

[Service]
ExecStart=/home/aniket/xmr-stak.sh
User=root

[Install]
WantedBy=multi-user.target

Ran following commands in terminal:

sudo systemctl daemon-reload
sudo systemctl enable xmr.service
sudo systemctl start xmr.service
sudo systemctl stop xmr.service
sudo systemctl restart xmr.service

Restarted computer.

After Ubuntu restarted, I did systemctl status xmr, and could see status as active.

But in supportxmr dashboard, I cannot see the worker. On manually running the .sh file, I can see the worker in the dashboard. What might be going wrong?

You're likely running into the same problem as me.
It seems that xmr-stak.sh only reads the config file if you start it manually.
Apply the following change:

ExecStart=/home/aniket/xmr-stak.sh -c YOURCONFIGFILELOCATION

After that do a systemctl daemon-reload and try it again - should work now with the correct config file.


Is more cores or more RAM better for mining? I'm trying to optimize CPU mining on a VPS. I'm wondering if you have any clue about this? Is it better to have more cores as RAM is not important (so just keep 1 RAM but not more), the other way around, or improve both with a ratio like 1 core 2 RAM?

Cheers

Neither. Mining on a VPS is worthless because the CPU(s) are shared. Use a dedicated server.


How can I run a node with fluffy blocks enabled? Now that fluffy blocks (compact blocks) are enabled with release 0.11.0.0, how can I enable them on my node?

Simply run monerod with the --fluffy-blocks option.

Windows

Open a command prompt in the folder of monerod.exe, or create a .bat file. Type in the following:

monerod.exe --fluffy-blocks

Press enter (in the command prompt), or run the .bat file.

Linux/Mac

Open a terminal in the folder of monerod. Type the following and press enter:

monerod --fluffy-blocks


VIRT 100G usage of monerod; Is this expected? monerod is (seems) literally hogging up the memory.

Is this expected?

If it's not, what can I do to fix this behavior?

The vast majority of the virtual memory usage is memory mapped I/O backed by the blockchain database on disk. A minority corresponds the process memory.

The monero database file is something like 70 GB, very roughly, and some extra space is reserved for expansion, so 103 GB seems totally plausible.

As a point of comparison, typical x86_64 has 256 TB of virtual address space, so 104 GB is 0.04% of it.


Monero fork: block creation time fluctuation I am running a Monero fork(v7) for the past 4 days. I have set the block creation time as 2 minutes but sometimes the blockchain takes more than 30 minutes to create a block. Is this normal behavior?

Below are my network details

Difficulty: 79447867
Network Hash: 662.065 kH/s
Hard Fork: v7

Yes, it is normal. Block creation is random. Sometimes it'll take more time than your target, and sometimes less.

Think of it as flipping a coin. You can expect tails in... hmm... a bit more than 1.5 tries I think. But if you try it, sometimes you'll get tails in just one try, and sometimes it'll take 20 tries. But the average will converge to about the expected if you try for long enough.

By the way: I see you are forking with the existing Monero chain. If you do not start your own chain, you are a bad person. See How can individuals safeguard themselves and the community against a key reusing fork? for details. I misread the hash rate, this looks like a new chain, all good :)


Transaction from GUI wallet to bittrex account never arrived. PLEASE HELP On April 11th 22:37 a friend of mine transferred 78.0 XMR from his GUI wallet v.11 to my Bittrex account.

in his GUI wallet on the history page it shows successful transaction and 78 xmr haven been deducted from main balance on GUI. In GUI under check payment it shows transaction successful with more than 10k confirmations.
Now, on April 26th I still don’t have received the 78 XMR on bittrex.
I can not find the transaction on the blockchain either (using tx ID or payment ID)
All addresses are 100 percent correct as I double and triple checked everything.
I have now updated the GUI to v12 and changed the wallet file name which caused the GUI to resync but the balance still shows zero.
If its not on the wallet and not in the blockchain, then where can it be?
I have made several transactions before with this wallet and everything always was fine.

Can you please help me, I don’t know what else to do.

Monero had a hard fork on the 6th you sent a transaction on the 11th after the hardfork had occurred. You have sent Monero Original to your Bittrex account and not Monero. Try using this guide to re-sync to the correct chain with your old balance.


How is the G constant calculated in the cryptonote protocol? The cryptonote whitepaper uses a G constant, as a base point, to calculate various operations, but I don't understand where this constant actually comes from. Is it just a random point on an elliptical curve?

G is defined in the definition of the signature scheme, Edwards-curve Digital Signature Algorithm (EdDSA)in the case of Cryptonote and Monero.

As explained in this answer in crypo.SE :

  the base point is chosen pretty arbitrarily. As described in the Ed25519 paper, it arises from the choice u=9 in the original Curve25519 paper

The details of this choice are probably out of the scope of Monero.SE and more suited to crypto.SE.


Is my wallet really valid? I am really new to this world so please apologies if that's a stupid question.
I have generated my monero wallet with this tool: https://moneroaddress.org/
And kept al the information somewhere in a file I encrypted.
I have started using xmr-stack to "mine".
When I started xmr-stack it asked me for the pool address (I'm mining on monerohash) and my wallet I wanted to use. things seems to be working (at least I can see no errors) but to be very honest, I have no idea what I'm really doing here.
From What I read I can check my wallet using monero-wallet-cli. So I installed and sync'd monerod and then tried to use the wallet cli. but It seems it's willing to created a new wallet.

Can I import the wallet I created before? If yes, then how?
Am I doing anything stupid here?

Thanks

You need to run:

monero-wallet-cli --restore-deterministic-wallet

You will be asked for the seed you created earlier.

You will need a running daemon (monerod), which may be one of the public ones or your own, in order to download the blocks to see your transactions. When asked for a refresh height or date, make sure you put one that's when you created your wallet originally.


Approximate cost of developing Cryptonight ASICs I have already seen reasons why Cryptonight is more resistant to ASICs as compared to SHA256 for example:

Cryptonight takes advantage of the AES-NI instruction set available on most modern machines
Cryptonight limits parallelizing hashes due to uses requirement of 2MB of fast memory

Acknowledging the above (largely focused on the lesser relative advantage Cryptonight ASICs would over CPUs/GPUs not the impossibility of creating ASICs) what are the range of cost estimates for ASIC creation?

If low end estimates are easier to make, please share estimates for FPGA creation and FPGA Conversions instead.

Even FPGA would be expensive for CryptoNight because most standard FPGA have close to zero memory. Your second point will, therefore, not only decrease the relative advantage of ASICs or FPGA over GPUs and CPUs but greatly increase their cost.

Even a basic FPGA mining board would be an expensive custom job because of this memory requirement.

I would estimate a minimum of $100,000 for the most basic FPGA board with minimum order requirements that will unlikely allow it to be profitable over GPUs and CPUs unless Monero prices rise dramatically.

ASICs creation might cost anywhere from a few hundred thousand to several million dollars depending on the specs. Again, there would be no guarantee of profitability.

ASICs for CryptoNight remains pretty unlikely until/unless XMR prices rise dramatically. There is also always a threat that Monero could eventually change its PoW to Cuckoo PoW or something else. Eventually a more Quantum resistant PoW might become attractive. If Monero changes PoW all previously produced CryptoNight ASICs would become close to worthless because there are not any other CryptoNight coins with the market cap to justify their expense.


Exchange for Monero Fork Once a custom Fork of Monero has been created, what are the steps for allowing "people" to be able to buy the currency online?

Does an exchange need to be created or is it a case of approaching an existing exchange and "working with them"?

If you create a coin, people will mine it. Once they mine it, they will get coins as a reward. You then have to negotiate with exchanges to list your coin or in a best case scenario they will list the coin for free.

After they list the coin, people can buy / sell them.


How do you create a watch only wallet in simplewallet with the viewkey? We all know that the viewkey can be used to verify transactions you've made, and has been covered to a certain extent in other questions, but how is this employed using the simplewallet client? What steps need to be undertaken to create a watchonly wallet so that you can keep the private key offline, but still monitor any funds being sent to your address with simplewallet?

With your account's standard public address and private view key handy:

Start simplewallet from the command line with ./simplewallet --generate-from-view-key <wallet name> (Linux/OSX) or simplewallet --generate-from-view-key <wallet name> (Windows) where <wallet name> is the name of your new "watch-only" wallet.
simplewallet will prompt for an optional password (this wallet can't spend funds after all). Enter one if desired.
simplewallet will prompt for an optional blockchain height to begin scanning from. If you know the approximate creation date of the wallet, you can save a lot of time for first startup by entering a height near (but for sure before) that date.
simplewallet will prompt for a "Standard address:". Enter it.
simlewallet will prompt for a "View key:". Enter it also.
You are done! simpewallet will immediately begin "refreshing" from the height you chose until it has caught up to the current chain height. This can take some time, depending on your computer speed and the age of your wallet, but when it's done you should see all incoming outputs to that account.


How much information is passed from the daemon to simplewallet when scanning for a wallet's transactions? When simplewallet is connected to a local daemon, the data throughput is mostly irrelevant because communication is done completely locally. But I am curious about how much data/information is transferred between a remote node and simplewallet?

For example: Let's say simplewallet needs to update your wallet for the last 720 blocks (1 day). Let's also say that over that span blocks are averaging 10 txs/block and 1.5 kB/tx, or 15 kB/block. Finally, let's say that 10 txs belong to your wallet over that span. How much data would be used by simplewallet? Is any block information not shared with simplewallet?

Edit 16 Sept 2016:

I'm going to be a little more specific in my question, and also add a bounty, as I'd like to know the specifics but also recognize that this will require a bit of work.

In general, the following information is available in a block (I may be missing some info and am happy to add/correct this list):

blob
block header

depth
difficulty
hash
height
major_version
minor_version
nonce
orphan_status
prev_hash
reward
timestamp

miner_tx

version
unlock_time
vin / gen / height
vout w/ each output (amount, target key)

extra
signatures
all transactions in block

all details of transactions (hashes, key amounts, key offsets, key images, tx extra, siganatures, etc)

Questions:

Does simplewallet receive all of this information from the daemon for every block (and all transactions in the block) or only a subset of this information?

2. In either case, is there information that simplewallet does currently receive that it does not always need (for example, if the transaction does not belong to a wallet) and therefore sending that information could have been avoided if designed to minimize data transfer?

EDIT 17 Oct 2016: I've decided to spin off the last part of this question into a new question as it is fairly different in scope.

Follow-up question for those keeping track: Is it possible to create a lighter wallet than simplewallet without giving up a view key?

I captured the stream of RPC requests and answers between monero-wallet-cli and monerod (v0.10) with wireshark to see how much data is transferred during a synchronization.

It was a synchronization of 658 blocks (blocks 1159032 to 1159659), and the total amount of data exchanged was:

7662 bytes from the wallet to the daemon (get_version, getblocks.bin, get_transaction_pool and gettransactions requests)
5912493 bytes from the daemon to the wallet (almost all of which was answers to the getblocks.bin requests)

It means that on average the daemon sent between 8 kB and 9 kB of data per block to synchronize (RPC headers and JSON formatting included). I looked at the last 20 blocks of the synchronization and their average size is around 6 kB. In fact, the daemon sends the complete blocks to the wallet, and the wallet checks all the transactions in the received blocks to find its own.


How do you propose a project with the forum funding system? The Forum Funding system is a way of funding Monero projects. Its the way the GUI was funded, for example.

How do you set up a project to use the forum funding system?

One way would be to ask the devs on freenode.org IRC in #monero or #monero-dev , dEBRUYNE should be able to help anyone out with lodging a forum funding bounty.


What are the risks of using a remote node through the Tor and a node hidden service? How insecure is the use of remote nodes, but through the Tor and tor hidden services(remote node with .onion domain)?
What are the possible attacks?
How much damage can it do?
Hope for your answer!

Similar question and answer.
Using Tor only lessens the risks associated with using a 3rd party remote node. If the node is not yours, you are trusting the data it gives you.