Mining with xmrig on monero.hashvault - I want to understand what I see on the command line I am just dipping my toes into LUbuntu/Monero/mining in general, all at the same time. I think I have set up mining configuration properly by now. But I don't understand what I see as output.
Here is a snippet of what I get:

[2018-01-13 21:27:17] new job from pool.monero.hashvault.pro:3334 diff 78947

[2018-01-13 21:27:35] accepted (2/0) diff 78947 (56 ms)

[2018-01-13 21:27:38] accepted (3/0) diff 78947 (63 ms)

[2018-01-13 21:27:41] speed 2.5s/60s/15m 1195.5 1162.8 n/a H/s max: 1219.3 H/s

What are the "accepted" lines? Why multiple lines 2/0, 3/0, etc.
I get that the diff is difficulty. Should I use this to tune xmrig?
What is the speed line telling me. Looking at it, I can't intuit anything from that line.
Is a speed line an indicator of a successful hash?

I am mining on port 3334, the web page doc on hashvault tells me that this is for "High-End Hardware (1.5-2 kh/s)" Looking at the above statistics, am I in the right pool?

Oh, and here are the first few lines when I start the xmrig:

VERSIONS:     XMRig/2.4.4 libuv/1.8.0 gcc/5.4.0
HUGE PAGES:   available, disabled
CPU:          AMD Ryzen Threadripper 1950X 16-Core Processor  (1) x64 AES-
NI
CPU L2/L3:    8.0 MB/32.0 MB
THREADS:      16, cryptonight, av=1, donate=5%
POOL #1:      pool.monero.hashvault.pro:3334
COMMANDS:     hashrate, pause, resume

Maybe I've overlooked some documentation which spells all of this out?

The "new job" line means the pool just sent your miner some work. Your miner will then repeatedly hash this data to find hashes below the requested target (which comes as part of that job). The last number of that line is the difficulty for that job. The higher it is, the harder it is to find a qualifying hash, but the more any solution counts towards your share of the block reward when the pool finds a block next.

The "accepted" line means the pool acknowledged receipt of a hash your miner found. 3/0 means this is the third accepted hash, and none were rejected (which can happen for various reasons, such as being for a previous job, below the requested difficulty, or otherwise invalid).

The "speed" line tells you your miner's hash rate. As far as I can tell, this shows three hash rates over three different rolling windows of 2.5 seconds, a minute, and 15 minutes. The hash rate stays fairly constant at close to 1200 H/s. Your miner hasn't been running for 15 minutes yet.

Huge pages are larger than default pages (usually 2 MB, while pages are normally 4 kB). Using huge pages for mining decreases TLB overhead, and gives a good hash rate boost. In your case, the hardware supports huge pages, but they're disabled. Enable by writing the number of huge pages you want in /proc/sys/vm/nr_hugepages. I think a good default is three per mining thread. With 32 MB L3 cache, you can run 16 threads (a thread needs 2 MB cache to be efficient), so 48 huge pages seems like a good one to try.

Lastly, your hash rate more or less matches the low end of the recommendation. You're fine there. Difficulty is variable anyway, so the pool will decrease it a bit once it works out you're near the low end of that range.


What are daughter-chains? I've been reading the design goals and I see they refer to "daughter-chains". What are these, and are they different to side chains?

The esperanto term for daughter chains is Moneridos. Daughter chains are pegged side-chains which can be merged mined. They are designed to process microtransactions and other stuff that would just spam the main chain, like on-chain betting or gambling.

The differences to side chains are that they are deeply anchored into the Monero Core and will be enabled on any Monero node. Also, the plan is that they do not have any coinbase transactions. According to @fluffyponyza, tokens on daughter chains are only to be created on-demand when there are pegged transactions into the sub chain.

Read more at this reddit scalability discussion.


How to save wallet after create_address? If I create a new address (create_address from rpc), the state of the wallet is not saved while rpc daemon is running. If the daemon crashes, will I lose the generated keys? What are possible solutions?

p.s. Beryllium Bullet 0.13.0.2-release, OS Ubuntu 16.04

create_address does not generate wallet key files, it creates a subaddress. Therefore even if the wallet RPC crashed, you would not lose anything. The wallet can still receive funds sent to that subaddress also.


What is the next big step in Monero's future? What is the next big step in Monero's future development that could emulate the buzz generated when monero was accepted onto Alphabay?

The 2 important things coming soon are ringCT and Kovri.

In fact, ringCT is already coded into the last client software and the hard fork allowing such transactions will activate somewhere in January. RingCT is important because it's the last piece of the blockchain privacy puzzle:

Currently, you can't know from where the funds came, thanks to ring signatures.
Currently, you can't know where the funds went, thanx to stealth addresses. This holds true even if you sent those funds yourself and lost your local transaction history! It's interesting to know that you can't recover the destination address from the blockchain.
Soon, you won't know how many Monero were moved, thanks to ringCT.

Kovri is in the works, and it's important because it could be baked into nodes, allowing them to communicate anonymously over I2P. This way, any attempt to track users by using IP addresses would be futile.

Further on, we can look forward to multisig, which should come some time after ringCT. For long-term plans, there are the Monero design goals.

There's also payb.ee coming soon, which is a payment processor developed specifically for Monero.
Oh yes, and GUI coming soon as well, which is what will make it more appealing for the end-user.

I believe that in the future we'll see clever ways to make and improve light wallets, as well. In fact, the Monero CLI wallet is a light wallet already as it can use a remote node to perform transactions. The mymonero.com is a light wallet as well since the client-side javascript could be coded as a stand-alone program and provide security, while the model sacrifices privacy to take the load off the client (the server keeps your view key to be able to monitor incoming transactions while you're away).

What would be the one to push a wave of adoption, I can't tell. But I'd expect some major exchange adding it to be an important step. As confidence grows and the ecosystem develops, we could expect organic growth, and few more smaller waves as people "click" with the tech.


Transactions without outputs When crunching blockchain data, my script tripped up on transactions without any outputs (vouts). Is this Monero's equivalent of OP_RETURN script, or am I missing something?

After looking at some examples in a blockchain viewer, it appears that the value of the outputs goes to the miner, I will leave the question open for good suggestions as to what is going on there:

Block 761388 Block 782656 Block 844741 Whole block 1006680

Monero has no scripting language. Even though the Cryptonote paper describes a simple lightweight one, the code did not implement it at the time Monero forked.


Monero and Tor onion service Is it possible to run Monero completely over and as a Tor onion service?

Yes. There are two guides:

https://www.getmonero.org/resources/user-guides/tor_wallet.html and
https://github.com/monero-project/monero#using-tor


How can I verify the SHA256 hash of 0.10.3 “Wolfram Warptangent” on FreeBSD? How can I verify the SHA256 listed in this GPG-signed message for the official Monero 0.10.3 release matches the file that I downloaded for FreeBSD, 64-bit?

The process for Linux and FreeBSD is similar to that for macOS, described here: How can I verify the SHA256 hash of 0.10.3 “Wolfram Warptangent” on macOS?

For FreeBSD, use the command sha256sum <filename> in the terminal and compare the output to the checksums on the Monero webpage.


Error Message: "Can't bind socket"? I'm getting the above error message when I try and run the daemon. It also states "error read in tcp s". Can anyone explain how to fix this? Thanks.

There are two main reasons a program can not bind to a socket:

the port is already used: typically, for the Monero daemon, this means another monerod is already running. You can check whether monerod is running by looking at the process list (ps, top, or other tool), or whether monerod or another program is already bound on that socket using netstat -ntpa (flags may vary based on netstat variant used). The fix for this is to stop the program currently using that port, and try again (or, if it's already monerod, do nothing, since it's already running)
the kernel or other software controls binding and denies the attempt: this happens on Windows, where firewall and/or antivirus software can be set to prevent software (or unprivileged users) from setting up a server process on the machine, or on Linux (and maybe Windows) when trying to find to a privileged port (below 1024). monerod's default P2P port is not privileged, however, but Windows might have different rules for this. The fix for this is to configure the kernel/firewall/antivirus to allow such access.


Validate the result of a job sent by a miner I'm implementing my own mining pool and I need to know how the result of a job obtained from a miner is validated. I looked at the snipa22's code but have a small doubt.
When sending a job to miner:
1. From bytes 0-3 ( 4 bytes ) in the reserve location of block template blob an extraNonce is put.
2. From 4-8 some random bytes are put. This blob is sent to miner to compute

When the result is obtained from miner, this result is of the format :

{
    "method":"submit",
    "params": {
        "id": "req.result.id",
        "job_id": "job-id",
        "nonce": "deadbeef",
        "result": "block hex"
    },
    "id":1
}

A new blob is constructed from the blocktemplateblob. Which uses extraNonce and the nonce obtained from miner in place of bytes 4-8 in the reserve location if I understand correctly. What's the point of putting random bytes in 4-8 bytes of blocktemplate. Can someone explain what's happening here?

The pool adds unique data into a block template (in the reserved space) and creates a hashing blob so that it sends each miner unique data (a unique hashing blob) for each miner to hash. Note here that the pool stores the block template it used to create the miners hashing blob.
The miner adds unique data (the nonce) to the supplied hashing blob and then hashes it repeatedly (changing the nonce each time), until it finds a nonce that creates a resulting hash that meets the required jobs difficulty target.
The result sent back from the miner is the result hash, not "block hex". The pool verifies the result hash by:

Taking the block template from step 1 above, the stored template
Adding the submitted nonce into this template (and note, this is not added to the reserved space, the block template has its own location/field for a nonce)
Getting the hashing blob and then hashing it
Comparing the resulting hash to the miner supplied result hash

Verification then involves the several steps:

Do the hashes match?
Does the hash meet the jobs difficulty target?
Is this the first time this miner submitted this hash and nonce?

If these all pass, it's a verified job/share submission.

Lastly, if the hash meets the network difficulty target, the pool can submit the block template (from steps 3.1 & 3.2) to the network.

  A new blob is constructed from the blocktemplateblob. Which uses
  extraNonce and the nonce obtained from miner in place of bytes 4-8 in
  the reserve location if I understand correctly.

The nonce from the miner is not placed in "bytes 4-8 in the reserve location". It's placed in the part of the block that holds the block nonce. Blocks have a specific field for the nonce.

  What's the point of putting random bytes in 4-8 bytes of blocktemplate.
  Can someone explain what's happening here?

This is specific to the nodejs-pool implementation. Recall, the pool can use the reserved space in any way it needs to. For nodejs-pool, which is a multi-process pool, it needs to add extra randomness into the reserved space. It calls this extra randomness variable "instanceId". When a pool instance starts, it instantiates a specific "Coin". The "Coin" constructor sets the "instanceId" to a random 4 byte number. This ensures that multiple pool processes/instances always set something unique in the reserved space. It has to do this because the other unique(ish) data it writes to the reserved space (the variable they call "extraNonce"), starts at 0 and increments for each blob created. Therefore multiple instances of the pool all start with "extraNonce" the same, 0. But you don't need to get hung up on the way that nodejs-pool uses the reserved space - all you need to know is: you have to ensure your miners aren't hashing the same hashing blob and you can use the reserved space any way that works best for your implementation.


How to download the monero blockchain testnet? I want to download the entire monero blockchain on my local node. Where can I find the guide or documentation to download the entire blockchain? Will it run on the bitcore like zcash, litecoin etc...?

To download the Monero testnet blockchain, you run monerod with the --testnet flag, ie monerod --testnet. The blockchain will start downloading. Note that you will need a current version of the Monero code: either master from github, or the release-v0.12 branch, as of now. The Monero software in 0.11.1.0 is not recent enough to use the current testnet chain.

I'm not sure what you mean by running on the bitcore, but it will run on most machines. If you can run the mainnet, you can run the testnet, and the mainnet and testnet chains are independent. Since Monero is not a Bitcoin descendent, it will handle differently from Zcash and Litecoin, but the principles should be similar.


Any Monero projects in Python? I'm curious if there are any interesting projects in Python for Monero. I have to write some big long explanation here so I can post this simple question. Good job SE!

there is MiniNero and RingCT-Python as simple implementations of the the math behind Monero

there is also the GUI lightwallet which is implemented in python.


How will the range proof size reduction be accomplished? According to this answer

Range proofs are currently 6304 bytes (per output) and will drop in the future by at least 1024 bytes.

How will the future 1024 byte reduction per output be accomplished?
Assuming proper implementation will there be any security or privacy concessions associated with that byte size reduction?

This is a bit speculative, as I do not know exactly what is planned.

1024+ bytes is quite a reduction, so my guess is that the range will be reduced. Currently the spender must prove the output is in the range [0, 2^64), and if the upper limit were reduced it would reduce the size of the signature. This would not alter security, but would decrease the amount that could be sent in a single output. Amounts larger than the upper range could still be sent to a single address in one transaction, but would require multiple outputs to do so.


Can the 750Ti and HD 5450 be used for mining? What software do you suggest. I am currently mining with an R9 380 and I am trying to expand. I have an 5450 and I think I can get a 750ti for about 30 dollars. What software should work nicely with 750Ti and/or the HD 5450. Does anyone have any idea what kind of hashrate I could get out of the 5450? Thanks for reading.

That depends on your operating system. For all mining questions, I would suggest starting with the Monero mining wiki.

For Windows, there are two options for NVIDIA (ccminer-cryptonight and xmrMiner). The second is much newer.

For CPU, there are many options. The easiest is Monero Spelunker, but the best is probably XMR-STAK-CPU.

I'm not sure what hashrate you can get out of the 5450.


Forgot Monero Private Key and Spend Key I logged out of MyMonero.com and I never recorded "View Key (Private)" and "Spend Key (Private)", but I once noted "Account Address (Public)". How is the solution ?, I have XMR amount in MyMonero.com Wallet. Thanks.

When you create an account on mymonero.com, you are given a "Private key login" which is a list of 13 words. You are also given your private spend key (the private view key can be recovered from the private spend key).

In practice, they are the same thing, represented differently. So if you have one of the two you will be able to recover your wallet.

Because Mymonero.com doesn't store your private keys or private key login, if you have lost both you will not be able to access your wallet.

Also note that your public address is something you can share with other people so they can pay you with monero and can not be used to access your funds.


Is there any way to lower the difficulty in order to mine faster on a testnet? I'm searching for a way to mine 60 blocks without the waiting time (or at least significantly reduce the time) on a testnet.
Can it be done or will it affect other operations in the blockchain?

If you're using a local testnet (that is, you don't need to accept blocks from other peers, nor get peers to accept your blocks), then you can hardcode a fixed difficulty in src/cryptonote_basic/difficulty.cpp, returning a small value in next_difficulty. A value equal to your hash rate will get you a block every 2 minutes on average. A value equal to your hash rate divided by 20 will get you a block every 6 second on average, etc.


Block reward penalties and dynamic block size Block reward penalties begin if a block gets beyond 60kb in size.

What is the reason why this limit is not dynamically re-calculated to follow a ratio of the blocksize limit instead of a constant?

This limit is based on the median of the last 100 blocks' size, after removing outliers, with a 60 kB lower limit (so blocks can't get TOO small, or you could have a hard time "restarting"). This allows the block size to grow and contract based on transaction volume. The size at which the block reward penalty kicks in is between 100% and 200% of the block size for this coinbase. It follows a continuous function, which I think is quadratic.

See get_block_reward in src/cryptonote_core/cryptonote_basic_impl.cpp for the details of the code.


When using integrated_address, does the sender HAVE to include the random payment ID? Will a transaction still execute successfully if the sender does not include the random payment ID that is given when integrated_address is used by the receiver?

The network will absolutely accept it just fine; it doesn't know if a Tx is supposed to have a payment ID or not.

However, if a receiver is giving you an integrated address, they are probably expecting to receive a payment with that ID attached. If that ID isn't included, the transaction might not be properly recognized by them.


Which country operates the most Monero nodes per capita? Which country operates the most Monero nodes per capita?

Do miners in countries with the most nodes have an advantage due to better average network propagation times?

The distribution of nodes varies over time and not all nodes are visible

https://monerohash.com/nodes-distribution.html
Currently the United States has more publicly visible nodes than any other country. However that does not mean that US residents control the most nodes. Since nodes can be hosted remotely and run on VPS, nodes with an IP located in one country can be controlled by someone living in another country across the world.
Network latency can be influenced by geography but there are other factors involved. The increase from 1 to 2 minute blocks helped to level the playing field for miners with slightly worse network latency (and also has helped decrease the frequency of orphaned blocks). It is also worth noting that not every node is a miner.


Monero/Bitcoin proxy for JSON RPC Is there any script available for Monero to convert its JSON RPC commands to bitcoin JSON RPC commands like https://github.com/DeV1doR/ethereumd-proxy.git? If it is already available can you give me the details?

As Monero is not a Bitcoin fork and uses its own RPC API, I'm convinced there is no such thing as a RPC proxy converter out there.
However, you could read the wallet RPC guide (pending refresh) to build your own, with the methods that are actually convertible.


For newcomers to the Monero community, what can we do to help the project? There are a lot of newcomers into the Monero community and I am sure many are interested in helping out where they can.

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


What happened at Monero difficulty from Nov 2017 to Jan 2018? During latest days of November 2017 Monero difficulty, according to this chart, was around 30G and now is around 80G.

What happened to it?

And what should we expect for the near future?

It means that the network is used by more powerful miners. Difficulty adjusts to the network hashrate (after every block, unlike Bitcoin which adjusts difficulty only every 2016 blocks, around two weeks for 1 block / 10 minutes), meaning it will be more difficult to mine a block the more miners will join the network (if the overall hashrate goes up).

I expect the hashrate to rise over time, as I believe Monero to be more profitable to mine in the future. The more profitabel Monero will be to mine in the future, the more miners will join, causing the hashrate and difficulty to rise. This is so new blocks are still mined roughly every 2 minutes, even if computational power increases.

The reason for the increase lately could be (but doesn't have to be) because of a botnet mining Monero. But that alone wouldn't increase difficulty so much.

This is not financial advice and only reflects my own opinions.


How to create a 12 word brain wallet seed that is compatible with monero-wallet-cli? I know there is https://xmr.llcoins.net/addresstests.html and https://moneroaddress.org/ but are these good enough rng for creating seed? I hear you could do roll a 6 sided dice 100 times for good randomness, but how would that translate into a seed? lastly how would you restore that 12 word seed in monero-wallet-cli? thanks a lot

I understand you want to generate a truly random seed and memorize it, which is good as this would avoid the inherent weakness in human brain's capability to produce randomness.

  I know there is https://xmr.llcoins.net/addresstests.html and
  https://moneroaddress.org/ but are these good enough rng for creating
  seed?

Probably yes. See here for some details on how the RNG used works.

  I hear you could do roll a 6 sided dice 100 times for good randomness,
  but how would that translate into a seed?

If you want to use dice rolls, you could use this generator, which is a modded version of moneroaddress.org and gives you the option to use dice rolls practically directly as the seed. Details on how it works can be found here. It's reversible, so in theory it's possible to calculate which dice rolls would give a certain seed. Essentially it's just converting between base6 and base16 number representations. Considering it's hosted at a simple site with no https, if you're going to use it, better check the signature or get it straight from github.

The original one could be used but you'd enter dice rolls in the custom entropy field. I think the way it works is that it hashes whatever is inputted there with some rounds of Keccak hash function and uses the result as seed. You could enter anything you want in the custom entropy field. As long as the input has enough entropy, it should be ok.

Now, the result of either of above would be a 256-bit seed, resulting in a 25-word mnemonic. In lieu of a better solution, you could take the first (or last, or middle, or randomly picked) 128-bits of your resulting seed and feed them here to generate the mnemonic, keys and address. I'd still use 256-bits of entropy to generate it though, just in case.

  lastly how would you restore that 12 word seed in monero-wallet-cli?
  thanks a lot

To restore, you could always start your wallet like this monero-wallet-cli --generate-from-keys <filename> and you will be prompted for address, keys and password. If you know the block height when it was created, you could speed up the initial sync by starting it with additional --restore-height <height> argument. Need to be sure of the correct  because if you had anything sent to the wallet before the  it will not show it.


How is there no key image for the commitment to zero in MLSAG? zero to monero 5.7.2 mentions there not being a key image for the commitment to zero. How is this possible?

Quote: "Recalling Section 5.6.3, there is no key image for the commitments to zero zjG, and consequently..."

I was under the impression that there is a keyImage for each key in the ring. So if the ring has 10 users and each user has 4 keys, then the MLSAG will output 4 key images, 1 challenge value, 40 response values and 40 public keys

Edit:

It seems it is done by not including that section in the calculation of the challenge. So to sign for an input(CommToZero, OneTimePubKey) we will have one keyImage, two private keys and two public keys.

An MLSAG is a generalized version of the bLSAG ring signature, that says:

Build a ring, where each ring 'member' is a key vector.

A key vector is a list of public keys.

To build a ring that successfully verifies, you must know the private keys corresponding to each of the public keys in a certain key vector.

As a matter of agreement between the signers and verifiers, it is decided which base points apply to each of the public keys in the key vector.

As a matter of agreement between the signers and verifiers, it is decided whether any particular public keys are also required to have key images proven.

If it is agreed that any particular public keys require key images, then this will prevent anyone from signing with the private keys for those particular public keys twice.

  I was under the impression that there is a keyImage for each key in
  the ring.

The Monero agreement is that you need a key image only for certain public keys listed in the key vector. The input public keys require a key image, but not the commitment public keys. This is because it would be unnecessary and more demanding both in terms of computation and storage to enforce that a certain commitment is never signed for twice.

  It seems it is done by not including that section in the calculation
  of the challenge. So to sign for an input(CommToZero, OneTimePubKey)
  we will have one keyImage, two private keys and two public keys.

Yes, that is how it's done.

  I was under the impression that there is a keyImage for each key in
  the ring. So if the ring has 10 users and each user has 4 keys, then
  the MLSAG will output 4 key images, 1 challenge value, 40 response
  values and 40 public keys

I'm interpreting this as a ring size of 10, where someone is attempting to spend 4 inputs.

This is done using the RCTTypeSimple method in Monero, which creates 4 MLSAGs, one for each input being spent. Each of those MLSAGs would declare a key image for the input, there will be 10 key vectors, each with 2 public keys (the input public key and the commitment subtraction).

Therefore there would be a total of 4 key images, 40 key vectors, 80 public keys being signed for, and 80 response values.

You can double check this from the calculation in the answer here: What would the space saving difference be if MLSAG was applied over all inputs?

The space requirement for an RCTTypeSimple MLSAG signature is:  32*m*(2*n+3) bytes of storage. In your example, m=4 and n=1, therefore 2944 bytes of storage is required, which is a total of 2944/32=92 EC points and scalars that need to be stored (both EC points and scalars are represented using 32 bytes each). 92 = 4 key images + 4 challenges + 80 responses + 4 pseudo outs.


Can monerod run stable on a Raspberry Pi 3 with microSD as storage? I have a Raspberry Pi 3 and a microSD card (Samsung EVO+ 256 GB with advertised 95 Mb/s read and 90 Mb/s write). I'm using Ubuntu Mate 16.04, pretty much default setup (just added x11vnc for convenience). I have a 228 GB file system dedicated to the Monero blockchain (symbolic to it from ~/.bitmonero so I don't need to pass --data-dir on the command-line):

I managed to get the Monero blockchain synced by:

Copying the entire ~/.bitmonero directory from my macOS node.
Letting the Raspberry Pi 3 catch up with the latest blocks.

After that, I was able to synchronze my Monero wallet from another computer using my internal Raspberry Pi 3 node, and could successfully send a transaction to someone.

Unfortunately, after a day, I noticed my Raspberry Pi 3 node had freezed up. Rebooting and restarting monerod wouldn't succeed anymore catching up with the newer blocks. After a minute or so, the system would again become completely unresponsive. I tried it a couple of times, but to no avail.

The command I used to start my daemon was (tried all kind of sync sizes):

monerod --rpc-bind-ip \`ip route get 8.8.8.8 | awk '{ print $NF; exit }'\` --confirm-external-bind --fluffy-blocks --block-sync-size 100 --detach

No my question(s) are:

Is it überhaupt possible to maintain a stable Raspberry Pi 3 node with an internal microSD card as storage? I don't want to resort to an external disk, as for me that nullifies the attractiveness of the form factor.
What is the recommended software setup to do this (OS, such as Raspbian and configuration)?

After reading some of the instructions over at http://pinode.co.uk, I think I found the culprit. Turned out Ubuntu MATE for Raspberry Pi doesn't install with swap space out-of-the-box. I wasn't aware of this.

I have now added a 1024 MB linux-swap partition on my microSD card with GParted. I won't be very fast, but at least it's there.

Therefore, I also reduced the "swappiness" from the default 60 down to 0, which should reduce the tendency to use swap, unless absolutely required:

$ cat /proc/sys/vm/swappiness
60
$ sudo sysctl vm.swappiness=0
$ cat /proc/sys/vm/swappiness
0

To make the change permanent, edit /etc/sysctl.conf as root:

sudo vi /etc/sysctl.conf

And add the following line:

vm.swappiness = 0

Output of the free command when starting up monerod shows free memory takes a nose dive from ± 710 KB:

              total        used        free      shared  buff/cache   available
Mem:         949580       40424      710540        6760      198616      841848
Swap:       1048572           0     1048572

to roughly ± 35 KB

              total        used        free      shared  buff/cache   available
Mem:         949580       60428       36532        6760      852620      818640
Swap:       1048572           0     1048572

After monerod was fully synchronized again, it seems my Raspberry Pi 3 system is using just a little bit of swap space:

              total        used        free      shared  buff/cache   available
Mem:         949580      133652       33256        3768      782672      748508
Swap:       1048572        2988     1045584

That's probably why it system crashed previously without that swap ability.

I don't know exactly how to configure these newer Linux systems in "runlevel 3", if that still exists, to even consume less RAM. As a workaround, I have stopped some unnecessary services:

for SERVICE in x11vnc lightdm bluetooth cups
do
    sudo systemctl stop ${SERVICE}.service
done

If anyone has a better suggestion for that, feel free to comment or edit.


Making non-native tokens private by using RingCT (This is a research oriented question)

Is it possible to leverage the CT primitive and use it in order to transfer non-native and non-fungible tokens such as ERC721 (in another blockchain of course, since Monero doesn't support a token that is different from XMR)?

Stealth addresses and ring signatures should work, but I don't quite know how to perform the adaption to RingCT (though its value might be necessary cause its non-fungible feature).

Any comments to what I want to do or examples that someone else may have made a POC for would be appreciated!

Thanks.

RingCT is basically the combination of three things: ring signatures, stealth addresses (one-time output keys) and CT (Confidential Transactions).

The ring signature provides sender ambiguity, the stealth addresses (one-time output keys) hide the recipient address from the blockchain and CT is used in hiding the amount. Combined, you have the properties needed for a private fungible asset because the asset has no history to follow - 1 XMR will always be worth 1 XMR - they are indistinguishable.

ERC721 is for non-fungible assets, so I'm not quite following why you would want to use RingCT. That said, if you just wanted to make use of CT, to hide the value (or any other integer for that matter), it is not a particularly difficult construct to grasp.

CT requires two generators, a binding factor and the amount. A Pedersen commitment is then created like xG + aH (x and a being the binding factor and amount, G and H being the generators). Note you cannot recover the amount from the commitment - its a commitment to a value, not encryption of a value. Therefore in Monero, ECDH is employed to pass the amount encrypted separately (within the tx), which also means you need some mechanism to have a shared secret, for which Monero neatly places in the tx extra field. Also note, if you are using CT for a tx amount on a blockchain, you will also want to employ a range proof to prove the amounts in the commitments fall within a positive range (to prevent inflation).

For reference, the original CT paper can be found here: Confidential Transactions

When I think of non-fungible assets, provenance springs to mind - you want a transparent history of that asset - which is contradictory to what you get with RingCT.


How many lines of source code does Monero have? How many lines of source code does Monero have? How does that number compare with the amount of Bitcoin source code?

I do not know the exact number of lines of Monero source code, but there are a few methods to calculate it, which are described here.

Monero is not based on the Bitcoin code base and is rather complex. Because of this there has been a major effort to document and cleanup Monero source code:

  There are over 70,000 lines of source in the src/ folder alone, and there is code in other folders that brings the total to over 100k, so this is no small task!

The Bitcoin source code has grown dramatically since its inception. In early years Bitcoin only had about 3k lines of source code, as described by Greg Maxwell. Currently, the Bitcoin Core source code contains more 100k lines of code which is roughly equivalent to Monero.

Documentation for Bitcoin is far better than it is for Monero making it much easier for developers to understand.  This was the motivating factor for the Monero source code cleanup effort and is far more important than the number of lines of source code.


What level of peer review is required for Monero website updates? On 17 August 2016 0.13.0 Cobra was able to bypass peer review and issue a Binary Safety Warning on Bitcoin.org.

  The contributor who uploaded the alert, “Cobra-Bitcoin,” is understood to be in control of Bitcoin.org, Core developer Peter Todd told me in an encrypted message, and so they were able to bypass the peer review process for posts to the site.

How many people currently have a similar level of permission to update getmonero.org without any peer review? For pull requests to update the website from those without any special permissions, how much peer review is conducted before they are merged?

I believe that fluffyponyza controls getmonero.org and ultimately has the power to update the website on his own or by merging pull requests of others. This does not seem like the type of thing that could be easily and safely delegated.

There is a formal procedure for developer contributions to Monero addressed in this question. However the procedure is likely much less formal for the website. My guess is that most relatively "harmless" pull requests such as merchant or moneropedia updates receive an eyeball review and critical updates such as links to new binaries or security alerts similar to the "Cobra" update to Bitcoin.org are carefully reviewed by fluffyponyza.


Solomining if not fully synced yet? I have an active daemon but get the message 'status-not mining' yet the sync progress seems to be upticking.  Very slowly.  Is there a sync routine before a mining routine in Monero?

You have to be fully synced in order to solo mine. More specifically, you mine on top of the last (consensus) block, which is only possible if you are fully synced or, in other words, in sync with the network.

If, however, you're mining on a pool, you don't have to be fully synced (nor have to run monerod technically). Furthermore, you'd need one of the miners listed here:

https://www.reddit.com/r/MoneroMining/wiki/index

  Very slowly

The initial sync can take quite some time. However, thereafter, catching up every few days (or every few weeks) only takes an insignificant amount of time.


Suspicious connections - Having issues with the GUI under Debian by connection to a public remote node - PC hangs Having a Windows client with local node - works perfect.

When trying to connect with the Debian client to a remote node (eu.node.moneroworld.com at port 18089) the pc hangs immediately and cinnamon isn't reacting anymore and the cpu fan goes to full speed.

Checked the network connections for seconds in another terminal and found these suspicous ones:
https://s33.postimg.cc/twpk1iw67/IMG1.jpg
This happened three times. Every time the same addresses.
Googled it, but couldn't find anything monero related - only old spam mail addresses.

I directly cut the network connection physically and shutdown the pc via terminal.

Any suggestions? And just for your info, if you find out that your Debian pc hangs with the gui/monerod client.

I am going to use a local node in Debian too, but wanted to checkout how I can get a fast look into my wallet, when I am on a new PC/VM/in hurry.

node.moneroworld.com (in your case, the eu regional) connect to random nodes registered by gentle users on monerowold.com.
Looking at your capture, it seems the node you are forwarded to is based in Russia (which could be correct for eu location if west Russia).
Is it a legitimate node with a small bandwidth, or a scamy node you should not trust, no one could say.
Nevertheless, i do not know any security flaws in daemon RPC which could compromise your wallet using it.
You are just requesting block headers, parse them, and then requests full transactions when your wallet find your addresses while parsing the tx_keys in headers.

My guess is your computer freeze because the node is slow and the bandwidth tiny. If you look at a top while syncing, you should see if your cpu is stuck with I/O waits.

But, as you have a full node on your windows computer, why don't you connect your debian wallet to this windows node? Aren't they available at the same time?


Hardening a mining pool I have setup a mining pool for a smaller project that uses Cryptonight variant 1.
I have been running into problems with ddos attacks when other people started launching other mining pools.

At first it was layer7 attacks which hammered my webserver and i managed to successfully mitigate them.
However attacks are still inbound on my actual pool ports 3333/5555/7777/8888 and my server rejects shares every now and then because of that.

Cloudflare can't help because i would need an enterprise package for that which is way to expensive.
Blocking ip's manually is also a no go since source Ip's are spoofed.

I followed this guide to get some more layer4 based protection
https://javapipe.com/ddos/blog/iptables-ddos-protection/

However i feel like there is more i can do.
Suggestions are very welcome.

It baffles me why pools attack each other, but that asside, there are other providers that offer DDoS services (sometimes for free) on top of their servers.

As per comment thread above, if you intend to stay with the same hosting company which is capping the protection, one way round this is to make use of another provider as a proxy.

N.b. your linked iptables article is pretty good too. I would use that on the proxy too.


How can I check the balance of a Monero paper wallet? If I securely generate a paper wallet address and mnemonic seed, for example using www.moneroaddress.org, and I send a bunch of funds to this paper wallet, how can I check the balance to ensure everything arrived safely? For example, Bitcoin has a transparent blockchain, so I can look up my public key and my balance will display. Does Monero have a similar functionality?

The procedure is a bit more involved for Monero, but you can do this in two ways:

The easy one off solution is to gather the standard address you sent to, the txkey for the transaction (you said you sent the monero, so you should have it: the txkey is the private key of a random keypair generated when you send a monero transaction: you can get it with get_tx_key TXIDGOESHERE in monero-wallet-cli), and the transaction id for the transfer. Then you run this in monero-wallet-cli again:

check_tx_key TXID  TXKEY  ADDRESS

This will check how much monero was transfered to that address in that transaction. The txkey is what allows you to unscramble the data on the blockchain for that particular transaction.

If you want to send repeatedly to your cold wallet as well as spend, the hot wallet can keep track of these, though for it to work well, you will have to process all spends via that hot wallet, for things not to get out of sync. The current commands for creating, signing, and relaying a transaction signed by a cold wallet transparently handle all of this. However, the interesting case happens when your cold wallet receives a transaction, which you want to detect spend of. You will then have to do the following:

in the hot wallet: export_outputs OUTPUTS
copy the OUTPUTS file to the cold wallet computer
in the cold wallet: import_outputs OUTPUTS
in the cold wallet: export_key_images KEYIMAGES
copy the KEYIMAGES flie to the hot wallet computer
in the hot wallet: import_key_images KEYIMAGES

From then on, the hot wallet should be able to detect a spend of those monero.

As said above, those outputs and key images import/export functions are transparently updated while doing a cold signed transfer, so you only need to do the manual version if you receive in the cold wallet, and want to detect spending of that monero without making an intervening spend.


What are Ring Members? So as I understand, ring members are decoy outputs on the XMR Blockchain. Are these outputs originially public addresses (like in the BTC Chain) but have been hidden somehow? How have they been hidden? Are ring members hashes?

Furthermore, I can track where these decoys originally came from (XMR Chain shows their block height), but even then they may be pulling from another exactly the same decoy output ? (i.e. can I have a decoy of a decoy?)

Thanks.

When you create a transaction, you consume existing outputs and create new outputs. Each output has its own unique public and private key. This means outputs are not associated with a wallet address on the blockchain, like they are in Bitcoin.

In Bitcoin, when an output is created, the output is associated with a hash of the wallet address that is authorized to then spend it. In Monero, nothing is associated with a wallet address. The recipient directly spends the output that they have received in a transaction when it is time to spend it, using their sole knowledge of the private key of the output that was created for them when someone else sent them funds.

In Bitcoin, you specifically identify the outputs you are spending in a transaction.

In Monero, a ring signature hides the information about the actual outputs being spent. Let's say you want to spend an output you own. You then select 4 other random outputs on the blockchain, and create a 'ring' with 5 members. Therefore the ring consists of one output you do own and four outputs you don't.

You then create a ring signature which proves to the world that you definitely own one of the 5 outputs, but it will be mathematically ambiguous as to which output that is.

No outputs are 'hidden'. What is hidden is the reference to the output being spent. You reference a ring of possible outputs being spent, instead of directly referencing the actual output being spent.

There is therefore no such thing as a decoy of a decoy. A decoy is a real output that isn't the output you are actually spending. All outputs that exist on the blockchain are real outputs. All references to outputs are references to real outputs.

To put it another way, the blockchain does not consist of real and decoy outputs. The blockchain only consists of real outputs. 'Decoy' is a term that solely applies to references.

Note that the block explorer does not call the ring members 'decoys'. This is because one of the ring members is not a decoy. The block explorer does not know which is not a decoy reference. Therefore it simply states that the outputs are all 'ring members', because that is all that can be known as an outside observer.

You can look up any output on the blockchain that is referenced as a ring member in a transaction. The specific block explorer you have been using may not allow you to search for it directly, but that's only a limitation of that particular block explorer. The 64 character representation of each ring member is a hex representation of the public key of the output being referenced, and is not a hash.


How to use my 13 word MyMonero mnemonic seed with the GUI/CLI without accessing MyMonero? It seems that MyMonero.com has been hacked and a lot of XMRs are gone. Mine probably included. I want to check my wallet and send out everything as soon as possible.

I setup full node, synced blockchain but when it comes to seed recovery, it needs 25 words recovery seed or keys. I have only 13 words recovery seed from mymonero (from hopefully not hacked version) and no keys.

I cannot get keys from mymonero.com (i will never login there anymore).

How can i solve this situation?

Thank you and DO NOT LOG INTO MYMONERO.COM (never) again!

This is done as follows:

Go to this page: https://github.com/luigi1111/xmr.llcoins.net/
Click on Clone or download and download the ZIP file. This ZIP file can be used offline if needed.
In addition, you can verify the files by following the steps in the README: https://github.com/luigi1111/xmr.llcoins.net/#xmrllcoinsnet
Open addresstests.html
Put the 13 word MyMonero seed in box 1. Mnemonic Seed
Click on Gen 2.
Click on Gen 3 & 4.
Click on Gen 5.
Click on Gen 6.
Click on Gen 7.
Now that you have your private view key + private spend key + public address, proceed with this guide:

How to restore a Monero wallet from Private Keys

For the CLI, first perform step 1 to 10 as well. Thereafter, perform the following steps:

[1] Browse to the directory monero-wallet-cli is located.

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

[2b] On Linux and Mac OS X, open a new terminal from the same directory as monero-wallet-cli

[3a] On Windows, type the following command in the command prompt:

monero-wallet-cli.exe --generate-from-keys <wallet-name>

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

.\monero-wallet-cli.exe --generate-from-keys <wallet-name>

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

./monero-wallet-cli.exe --generate-from-keys <wallet-name>

[3b] On Linux and Mac OS X, type the following command in the terminal:

./monero-wallet-cli --generate-from-keys <wallet-name>

[4] Enter your private spend key, private view key, and public address, and it will "recreate" your MyMonero wallet.

P.S. Luigi1111 is a core-team member of Monero.


How is Emmy Noether related to Monero? I was wondering the reason the researchers from the monero lab chose to recognize her out of all mathematicians. (Im guessin it has something to do with her ring theories)

This is not a definitive proof but we can note the Review of Cryptonote Whitepaper by Surae Noether have this byline "This paper is dedicated to Emmy Noether, Satoshi Nakamoto, and the Bourbaki Group." As far as I know this is the first publication by one of the Noethers regarding Monero. The Bourbaki Group worked a lot on algebra and therefore rings so your hypothesis seems to be right.

Two minors reasons could be the pun on "No Ether" and the possibility to use the initials SN as a nod to Satoshi Nakamoto.


How do I enable incoming connections? (ELI5) Edit: I said 'outgoing connections' in the original question title, but apparently the correct term is 'incoming connections'. I meant: "How can I share my node's blockchain so that others can update theirs?" Currently I have 8+0 connections. I found some tips about router settings and I will post an answer when I get it to work.

I want to contribute to the network and I read that I should open port 18081 in order to enable outgoing connections. How do I do this? I don't know how to change the router settings. The router is a box that my ISP installed. I tried to add a rule in Windows Firewall, but that didn't work.

I have no network problems when it comes to minting PoS coins or even mining low-difficulty coins.

You should not have anything to do to allow outgoing connections, unless you're in a restrictive environment - in which case the steps to allow this are independent of Monero.

If you meant incoming connections, then you need to setup your router to allow port 18080, and forward it to the machine running monerod.

If you run "status" in monerod, you will see a "X+Y" counter pair at the end of the line: X represents the number of outgoing connections, and Y represents the number of incoming connections.

Port 18081 is for RPC connections, and you generally want to keep it local.

If you're getting any errors, posting them will help determine what issue you're facing.


Why does Monero use proof of work? Why does Monero use proof of work instead of something that saves electricity like proof of stake?

Have there been any serious to abandon PoW for PoS at some point similar to the plan of Ethereum developers such as Vitalik Buterin?

PoW is more secure than PoS in that it costs nothing to try to fork a PoS chain.  An attacker can try to make as many different chains as they can with a PoS chain, but with PoW if you try to fork the chain and you fail, that orphaned block took time and energy, because your computer is hashing away, working.  There is no work needed in PoS mining, therefore PoS chains will never be as secure as PoW.  Proof of Work stops bad actors from just running a script.  The attacker must launch bad workers, which is expensive to do.

See section three of http://bitfury.com/content/5-white-papers-research/pos-vs-pow-1.0.2.pdf


Disk space required nowedays? Oke a quick question:

How much disc space does monero need these days???

After the last time when it needed like 24gb on your windows drive.... it's now up to 32gb and counting. I've deleted already so many valuable programs just to run this wallet that i'm wondering what else i need to delete and how much more space it needs. I'm not a computer wiz so i rather delete every program on my computer rather then copy pasting things. But can anyone share how much more space it needs????

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

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


Is the purpose of the Kovri C++ project solely to benefit Monero? Is the Kovri project designed to solely benefit Monero or will the codebase be easily usable for all I2P developers?

While developed under the monero project umbrella, Kovri will be usable for general I2P usage, not only for monero. Even when used for monero, it will also be usable for other uses, if the user chooses so. Indeed, the advantage of being usable for general I2P traffic means that an observer seeing you using Kovri (which I assume may be possible via fingerprinting) will not know you are using monero, rather than something else (at least, from looking at the I2P traffic).

I believe the intent of building a separate I2P router was to avoid depending on Java and its libraries, which would have constrained the platforms which could run monero via I2P.


What are "white" and "gray" in the peer list? When I use the "print_pl" command in simplewallet to see the peer list, the first attribute of each line is either "white" or "gray". What is the meaning of it?

White peers are online and reachable and grey peers are offline.

The longer period of time it has been since you last used your daemon, the more grey peers you are likely to see.

White peers that fail to upgrade during a hard fork are (eventually) dropped from the network and become grey. People move and change VPS hosting providers, so peer status will always change over time.


Do transactions to subaddresses look different on the blockchain? If I sent from wallet A to wallet B's main address, then from wallet A to wallet B's subaddress, beyond normal "differences" in Monero transactions that obfuscate them, would the second transaction look different on the blockchain? (i.e. can you tell it went to a subaddress?)

No, there is no discernible difference on the blockchain when paying to a subaddress or normal address.


Monero Forking Guide I have been recommended to use the CryptoNote Forking guide (https://cryptonotestarter.org/inner.html)  as a basis for Forking Monero. However, there are a number of differences. For example, the following instructions refer to variables and locations that do not exist in the Monero source code but they do in CryptoNote:

//Name Your Coin Section

  — in src/CMakeList.txt file — set_property(TARGET daemon PROPERTY
  OUTPUT_NAME "YOURCOINNAMEd") Example:  set_property(TARGET daemon
  PROPERTY OUTPUT_NAME "furiouscoind")

//NETWORKING - Section 3

  Seed nodes — src/CryptoNoteConfig.h Add IP addresses of your seed
  nodes.  Example:  const std::initializer_list SEED_NODES
  = {   "111.11.11.11:17236",   "222.22.22.22:17236", };

Would anyone be able to advise as to

Does anyone have a more up-to-date Monero Forking guide?
Where do I put the IP Addresses of the SEED nodes
Where do set the Output Name? Does the const char CRYPTONOTE_NAME[] = "COINNAME" now suffice?
Is there anything else not included in the CryptoNote Forking Guide that I need to be aware of when trying to Fork Monero?

Try the forknote generator, you can find it at this address: https://github.com/forknote/monero-generator.


Ring signature with sublinear size increase The Wikipedia article on Ring signatures states that

CryptoNote implements O(n) ring signature scheme by Fujisaki and Suzuki in p2p payments to achieve sender's untraceability.
More efficient algorithms have appeared recently. There are schemes with the sublinear size of the signature,[1] as well as with constant size.[2]

Would these more efficient algorithms be usable for Monero (through a hard-fork) to reduce or even avoid the increase in size of high-mixin transactions?
[1] Fujisaki, Eiichiro (2011). "Sub-linear size traceable ring signatures without random oracles".
[2] Au, Man Ho; Liu, Joseph K.; Susilo, Willy; Yuen, Tsz Hon (2006). "Constant-Size ID-Based Linkable and Revocable-iff-Linked Ring Signature".

This was answered by core-team member smooth on Reddit:

  First one has a trusted setup. I don't know what issues there might be with the other one. I remember the MRL guys look at some sublinear ring sig at one point a year or two ago and it had high minimum size, such that it would only be useful for very large mix sets. That could still be an improvement overall but not necessarily a huge one so it wasn't highly prioritized.


how do I setup XMR-STAK-AMD webservice I recently (today) switched from wolf's xmr miner to xmr-stak-amd. First I would like to say that I'm getting a much better hashrate with the same settings (+100H/card) which I'm extremely happy about. However, I see on github screen shots of an html report interface but I don't see any instructions for setting it up or running it. Is this a self contained webservice, does this need to be in a pubic directory, etc? I should also mention I'm running on Ubuntu 16.10.

Does anyone know how to access this / setup this web interface?

Ok, I figured this out for myself. The built in microhttp server runs when the port number is set in the config.txt file. Had I read all the way through the config file the first time I would have seen the comment at the end.


How to validate cryptonight result? I have a XMR proxy and check results with the job target before sending it to real pool. If I use mining software with the cryptonight-lite algorithm, my proxy accepts these hashes. Please help me to write function to validate results, so that it accepts only Cryptonight results and rejects Cryptonight-lite results.

In current time I use this function (JavaScript):

function checkResult(result, target) {
    var targetDiff = parseInt(parseInt(target.length > 8 ? 'FFFFFFFFFFFFFFFF' : 'FFFFFFFF', 16) / parseInt(target.split(/(.{2})/).reverse().join(''), 16));
    var resultDiff = parseInt(parseInt('FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF', 16) / parseInt(result.split(/(.{2})/).reverse().join(''), 16));
    return resultDiff >= targetDiff;
}

It accepts Cryptonight and Cryptonight-lite hashes for XMR mining. I need this function to accept only Cryptonight hashes. Please help me to change this function. It seems I need other parameters besides target and result hash?

To accept only a specific hash type at the proxy is pretty simple.

The miner is returning a hash and nonce for the job that was given to it. Therefore, at the proxy, you just set the nonce in the job blob, hash it (with the algorithm you are interested in), then compare the result hash to what the miner submitted. If they match, it's a hash for the algorithm you wanted.


setting up multiple GPU's to mine I'm new to mining XMR, and mining in general. I'm currently using a Evga GTX760 Superclocked 2 gig card and am picking up a gtx 750ti tonight. For pretty cheap but I know I don't have it set up right for the 760. Because "GPU #0: Warning: block count 40 is not a multiple of SMX count 6." how do I fix this in the batch? As well how do I add the new card in to the batch file? I'm using the Nanopool TSIV-XMR CCminer and for the life of me cant find the information or I'm just not connecting the dots. Thanks in advance for the help

I had this error, rolling back my drivers appeared to fix this. Nvidia Driver Rollback


AEON Blockchain sync problem Well it's no monero question but I think it might still belong into this section.
I try to sync with the blockchain for the first time using the aeond.exe from release AEON-0.9.13.0-WIN64. It starts up and gives this error message:

2017-Oct-15 12:29:53.502950 [P2P0]Failed to connect to any of seed peers, continuing without seeds

Doesn't matter which P2P net it chooses, they all wont work. Tried this on 2 different PCs and on my dedicated Windows root server. Still wont work.

Any suggestions on what to do? Or is there a way to download the blockchain as a raw file and import it like it can be done with monero?

Appreciate every help!
Thanks a lot

This may not be a fatal error: if you already have peers in your p2pstate.bin file, then accessing seed nodes is not necessary. If you don't then it is, and you need to ensure you have working DNS from the machine/VM aeond runs on.

The Aeon seed nodes are:

74.91.23.186
  192.187.114.114

They expect connections on port 11180. There are just two, so if they're both down when you try to connect, you might have to wait. They appear to be both up currently.


Monero GUI: unable to sync I'm unable to sync, getting the following errror :

2017-Mar-17 13:28:54.264211 [P2P9]Failed to connect to any of seed peers, continuing without seeds

There is a problem with the seed nodes at the moment.
This is fixed in the coming release, hopefully in the next day or two: https://github.com/monero-project/monero/pull/1879

In the meantime, you can supply a node to start from:
./monerod --add-peer 107.152.130.98:18080 --add-peer 212.83.175.67:18080 --add-peer 5.9.100.248:18080
(this is simply adding the first three fallback peers to the command line)


List of transaction hashes in chronological order? Is there a daemon RPC call to get a list of all the latest transactions and their hashes?

You can use get_block which includes includes the tx hashes (tx_hashes) in that block. You can then use get_transactions if you need further details on the transactions.


Building Monero From Source on Windows 10 Pro I am following the Windows Guide here to compile from Source:
https://github.com/monero-project/monero

When I enter the command:
  make release-static-win64

I get the following error:

> spencer@aleph4 MINGW64 /c/Users/Spencer/Monero
> #  make release-static-win64 mkdir -p build/release cd build/release && cmake -G "MSYS Makefiles" -D STATIC=ON -D ARCH="x86-64" -D
> BUILD_64=ON -D CMAKE_BUILD_TYPE=Release -D BUILD_TAG="win-x64" -D
> CMAKE_TOOLCHAIN_FILE=../../cmake/64-bit-toolchain.cmake -D
> MSYS2_FOLDER=c:/msys64 ../.. && make CMake Error: Error: generator :
> MSYS Makefiles Does not match the generator used previously: NMake
> Makefiles Either remove the CMakeCache.txt file and CMakeFiles
> directory or choose a different binary directory. make: ***
> [Makefile:111: release-static-win64] Error 1
>
> spencer@aleph4 MINGW64 /c/Users/Spencer/Monero
> #

To solve this, rename the directory

C:\Users\...\monero\build\release

e.g. to

C:\Users\...\monero\build\zzzrelease


XMR to XMO (Recovery) Is it possible to recover XMR that was sent through mymonero.com to freewallet.org? At first I tried to send my XMR(mymonero.com) to deposit XMR address of(freewallet.org) but it says "Something unexpected occurred when submitting your transaction: Failed to decode address (#63): Invalid address prefix", so I used the  freewallet.org Monero Original deposit address and it went through. But then I didn't received it on my freewallet.org, I contacted their support they said it was mistake that I sent XMR to XMO and my XMR coins are stuck now. My question is that can this be recover using any tools or something like that? because if this is not valid at the first place why mymonero.org have transaction id on sending the xmr to xmo address? I'm sorry I'm newbie at this, hopefully masters like you can help me. Thanks in advance.

It is impossible for XMR to become XMO during a blockchain transaction. What actually happened is that XMR was sent to an "XMO address" which was interpreted as an XMR address. Therefore you sent XMR to an XMR address, and it's still XMR. You sent the funds to an XMR address they were not expecting you to send funds to.

Since they know the private keys to their XMO wallet, they should be able to use those private keys on the XMR blockchain to set up a wallet to get access to the the XMR funds that you sent. There is nothing you can do to reverse the transaction, because cryptocurrency transactions are irreversible.

If they are not willing to bother to do this for you, then please document the situation and notify the Monero community. There have been other reports of problems with freewallet.org documented here: https://www.reddit.com/r/Monero/wiki/avoid


Monero GUI - Is Daemon blocks remaining accurate when using --prune-blockchain? When using the --prune-blockchain flag in the Monero GUI, the "Daemon blocks remaining" message still seems to start as the number of blocks in the full (unpruned) ledger. Is this normal? The number of blocks remaining linearly decreases over time, but perhaps we are still skipping over some blocks aka pruning?

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

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

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

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

Is this normal?

Yes.


What is the transaction id and how its calculated? What is the tx id used for and why have it when there is already a payment id or even an integrated_address to identify a specific transaction?

Also how is it calculated? (guessing its a hash of the transaction or sumthin)
....well the tags just answered that lol

The 'tx id' is also known as the transaction hash. It is a keccak hash of the transaction data.

This hash is used to uniquely identify the transaction, which is why it's also referred to as the 'tx id'.

The tx id is actually a hash of 3 hashes:

A hash of the 'transaction prefix', which contains information such as the inputs, outputs, and the 'extra' field which contains any payment id associated with the transaction.
A hash of the 'base ringct' data, which includes the encrypted output amounts and the output Pedersen commitments.
A hash of the 'prunable ringct' data, which includes the output amount range proofs and ring signatures for the inputs.

The payment id that you can specify for a transaction is known in advance of creating the transaction. This means you can tell someone to use a certain payment id when sending you a transaction. If a payment is being sent to an integrated address, the payment id is also encrypted so that only the recipient can decrypt it.

The tx id, in contrast, is only determined after you create the transaction. By "create the transaction", I mean select the specific outputs that are going to be spent, choose decoy outputs, and construct the entire transaction payload that is ready to be submitted for mining. You do not have to actually publish or submit your transaction to be mined to determine the tx id.

Since the tx id is simply a hash of the transaction, anyone observing the public blockchain will be aware of the tx id of any transaction on the blockchain.


What is PayBee and how is it related to Monero? What is PayBee and how is it related to Monero?

Is it being worked on is a private repository? I cannot see much recent activity in GitHub other than forking code from BitPay.

What is PayBee and how is it related to Monero?

PayBee is a BitPay like payment processor. It will use Monero and Bitcoin as "default" currencies as far as I know. Fluffypony explanation of "what is Paybee" is as follows:

  It's a payment gateway I've been developing along with a few partners. We had to deal with a few false starts and issues along the way, but it's (finally) getting close-ish to release.

Source: https://www.reddit.com/r/Monero/comments/40gkul/what_is_paybee_does_it_have_something_to_do_with/

  Is it being worked on is a private repository?

As far as I know, yes. In addition, it has been in private beta for a few months now and merchants were, and are still, able to sign up to participate in it.


Low Hashrate for Some Nodes in Pool I have a lot of identical nodes all connected to the SXMR pool. They are CPU mining on 40 real cores (hyperthreading is disabled in BIOS) but I am finding that some nodes are performing far slower than other ones.

My question here is, am I doing something incorrect? Should I not connect the ~100 nodes I have to the same pool? Could this simply be a performance impact from having all of these nodes making an upstream connection? Is this just a matter of hash availability?

I'm aware that I'm not getting the maximum I could out of these due to 1 in every 10 nodes not performing anywhere near as well as the others.

The problem may be that CryptoNight is a memory-intensive PoW algorithm.  For effective mining, you need 2MB of L3 cache per core.

Here's an interesting answer describing CryptoNight.


How to compute ringct multisignature key images? (Disambiguation of MRL005) I'm looking at the multisignature scheme provided by MRL005 Section 4.4, and some things are unclear to me. I've attached a picture below of the expression for which I'm seeking some clarification.

Above, we have:

A generated key image (Ij)
A hash function (H)
A shared public key (Pe)
And a signer-specific public key (Pj)

No ambiguity there.
The actual operations required to calculate a given key image are the core of my questions.
Question 1: For the term (Pe | Pj)

Am I correct to interpret this as an inner product of the shared, and signer-specific public keys?

Question 2: For the term (Pe | Pj)

How would one actually calculate this value, given the two public keys?  A detailed example would be preferred here.

Question 3: For the term H()

Which hash function is used here?  Sha512, as in EdDSA? Keccak? Or something else?

1 & 2 - Pe | Pj is concatenation of the keys.
3 - Keccak, although as @knaccc comments, H() is not simply a hash function, it's hash-to-point, so should read Hp().


Does a Monero desktop ticker exist? I would like a desktop ticker so I don't have to go to a webpage constantly to check the Monero price in BTC.

I found one at https://www.coingecko.com/en/widgets/ticker/monero/btc but I have no idea how to put it on my desktop, it says "copy and paste to where you want it" but it does not copy to desktop.

I struggled to find a good menubar ticker for OS X, and eventually settled on using BitBar with a small plugin I wrote. Just drop this into your BitBar plugins folder and call it xmrrate.30s.sh or something:

#!/bin/bash

# XMR BitBar ticker, by Riccardo Spagni
#
# Shows last trade value for BTC/XMR on Poloniex

XMR=$(curl -s "https://poloniex.com/public?command=returnTicker" | egrep -o '"BTC_XMR":{"id":114,"last":"[0-9]+(\.)?([0-9]{0,5})?' | sed 's/"BTC_XMR":{"id":114,"last":"//' | sed 's/"//')

echo "∙ XMR: $XMR ∙"

Adjust as needed.


If I was to open a US based XMR exchange what laws I need to consider? Are there any laws restricting me from opening a Massachusetts, USA based Monero which would allow exchanges from fiat to XMR?

At the very least you would have to register as a money services business, which Poloniex and I believe Bittrex both have, and then as a MSB you would have to perform KYC/AML and record keeping to comply with the Bank Secrecy Act to detect and prevent money laundering. IANAL.


Where is the blockchain saved in Mac? I would like to delete the blockchain files from my computer. Where are these files located by default?

It is stored in /Users/[your username here]/.bitmonero

Example: /Users/sgp/.bitmonero

The .bitmonero folder is hidden by default, but it is there. The easiest is to open a Finder, hit CMD+SHIFT+G (keyboard shortcut for "Go to folder") and enter the path to open that location.


Mining aeon but the balance is still zero I want to solo-mine Aeon, so I downloaded AEON-0.9.12.0-WIN64.ZIP from https://github.com/aeonix/aeon/releases, registered my wallet using the simplewallet, and synced the blockchain in the Aeon daemon.

Then I started mining in simplewallet using start_mining
but I'm waiting for two days and if I check my balance it's still 0.  I'm using 99% of CPU and 6GB of RAM... How do I know I'm mining? What is the problem?

Details:

If I run show_hr, it shows me this: "hashrate: 312.6667"

When I start aeond, it shows me this:

  Starting... aeon v0.9.12.0() Module folder: C:\Users\memox\AEON\aeond.exe Initializing p2p server... Binding on 0.0.0.0:11180 Net service binded on 0.0.0.0:11180 Attempting to add IGD port mapping. No IGD was found. P2p server initialized OK Initializing cryptonote protocol... Cryptonote protocol initialized OK Initializing core rpc server... Binding on 127.0.0.1:11181 Core rpc server initialized OK on port: 11181 Initializing core... Loading blockchain...

From the output you gave, you seem to be mining just fine.

Your wallet balance will increase when you find a block. Blocks are found randomly, but a probability which depends on the network hash rate and your own. Roughly, you can expect to find 100 * 312 / 3000000 = 0.01% [1] of Aeon blocks. As there are 360 Aeon blocks in a day, you will find a block every 26 days on average. Note the on average, as variance can be large for small hash rate compared to the network hash rate.

Once you found a block (the daemon will point it out), you will have to refresh your wallet so it sees the incoming aeon.

[1] 312 H/s is your hash rate, and 3000000 H/s is the current network hash rate. At the time of your post, the network hash rate was closer to 1000000 H/s (see http://chainradar.com/aeon/chart), which would make the answer closer to a block every 9 days on average.


Can you lose your mined XMR from a pool? In the past I had generated a wallet and used that address to mine in a pool (minexmr). I had mined for a couple of months and I remember that I gather a "substantial" amount. However, I never received a payment since I didn't reach the threshold.
I stopped mining, and today (after 1~2 year) I decided to restore my wallet from the seed and see what's going on. Restoring from the seed  gave me a wallet address, that I guess it's the same as the old one?
Subsequently, I went back to the pool and entered my address to check what I had mined but there is nothing "credited" to my wallet. Is this normal? Have I lost what I had mined in the past as I never reached the threshold and never got paid?
Did I do anything wrong with restoring my wallet?

It clearly says this in the Terms and conditions page.
"Accounts which are inactive for longer than 365 days may be deleted. Any remaining balance will be treated as a donation to the Pool."
https://minexmr.com/terms
So yes you can loose your mined coins by being inactive for long.


What would the space saving difference be if MLSAG was applied over all inputs? Currently, MLSAG is being applied to each real input, giving one signature per real input. What would the space savings be if it was applied over all real inputs, giving one signature per transaction?

Update:

See zeroToMonero pg41

I'll restate your question for clarity:

Currently, it's the case that for transactions with multiple real inputs, multiple RCTTypeSimple MLSAG signatures are used. This is to prevent the leakage of the position of one real input in the ring from leaking the ring position of other real inputs (because they'd all be at the same ring index).

In an m real-input transaction with a ring size of n, what would the space saving be if a single RCTTypeFull MLSAG signature was used to sign the transaction instead of multiple RCTTypeSimple MLSAG signatures? The Zero to Monero paper says:

  Our perception is that the decision to limit RCTTypeFull transactions
  to one input was rather hastily taken, and that it might change in the
  future, perhaps if the algorithm to select additional mix-in outputs
  is improved and ring sizes are increased. Also, Shen Noether’s
  original description in [61] did not envision constraints of this
  type. At any rate, it is not a hard constraint. An alternative wallet
  might choose to sign transactions using either scheme, independently
  of the number of inputs involved. We have therefore chosen to describe
  the scheme as if it were meant for multi-input transactions.

The space requirement for an RCTTypeFull MLSAG signature is:
 32*(n*(m+1)+m+1) bytes of storage for the signature including key images (no pseudo outs are required).

The space requirement for multiple RCTTypeSimple MLSAG signatures is:
32*m*(2*n+3) bytes of storage for the signatures including key images and RCTTypeSimple-only pseudo out commitments.

Therefore, for the examples you gave, for mixin 7 (ring size 8):

1 input: RCTTypeFull = 576 bytes, RCTTypeSimple = 608 bytes. Saving = 32 bytes.

2 inputs: RCTTypeFull = 864 bytes, RCTTypeSimple = 1216 bytes. Saving = 352 bytes.

The savings at our current ring size of 11 are:

1 input: RCTTypeFull = 768 bytes, RCTTypeSimple = 800 bytes. Saving = 32 bytes.

2 inputs: RCTTypeFull = 1152 bytes, RCTTypeSimple = 1600 bytes. Saving = 448 bytes.


How to generate mnemonics from a random number? How do I generate 25/13 mnemonics from a random number?

I know how to generate Bitcoin style mnemonics with BIP39 (https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). However, Monero seems not using BIP-39 convention...

Is there any guidance that I can consult?
Thanks!

The source is the only documentation I'm aware of for this. See bytes_to_words in electrum-words.cpp. Every 4 bytes of the number (which is just taken as a byte array), converts to 3 words:

    w[0] = SWAP32LE(*(const uint32_t*)(src + (i * 4)));

    w[1] = w[0] % word_list_length;
    w[2] = ((w[0] / word_list_length) + w[1]) % word_list_length;
    w[3] = (((w[0] / word_list_length) / word_list_length) + w[2]) % word_list_length;

Where w[1], w[2] and w[3] are indexes to words in the selected language word_list.


TAILS - GUI v0.12 does not connect to the daemon (monerod) that is already running GUI v0.12 does not connect to the daemon (monerod) that is already running. That is, when I launch the GUI via ./monero-wallet-gui, it does not connect to the daemon that is running in a separate terminal. This used to work with GUI v0.11.

This particular issue should be resolved GUI v0.13.

This issue is currently being investigated. There is, fortunately, a quick and easy workaround, which is starting GUI v0.12 with ./start-gui.sh. That is:

Browse to the directory monero-wallet-gui is located.
Open a new terminal.
Execute -> ./start-gui.sh

It should now connect to the daemon (monerod) that is already running in a separate terminal.


How is Karbowanec different from Monero? I see that Karbowanec launched in May 2016 as a fork from the Cryptonote source code. How is it different from Monero, which is also a Cryptonote coin?

Both CLI and QT wallets are forks of CN reference implementations. By skimming over the Github pages, it seems like there are just some minor adjustments done to the original CN implementation, and that's about it. Also, their website doesn't state any specific features which would differentiate it from CN.

The difference between Monero and Karbowanec is practically the same as the difference between Monero and CN.

Since 2014, and at the time of this writing, Monero had 2866 commits on Github so it's hard to point a finger at some specific difference as there have been thousands of lines of code edited and decades of man-years spent working on it since the inception.


anonymity set (size) for stealth address (receiver) S1 sends fund to R1 using a stealth addresses.
The anonymity set (size) for the receiver (R1) is the size of all possible receivers in the blockchain.
Once R1 spends the funds, the anonymity set (size) for the R1 is 11 (size of Monero ring signature).
Is this true?

S1 sends fund to R1 using a stealth addresses.

"stealth address" is an unfortunate moniker. When a user sends funds to another users address, they create new, special, outputs that the receiver now owns and only the receiver can spend; the receivers address never gets stored on the blockchain, only these newly generated outputs, which have no observable linkage to the receivers actual address. "stealth outputs" probably better describes them. Anyway, I digress...

The anonymity set (size) for the receiver (R1) is the size of all possible receivers in the blockchain.

Yes.

Once R1 spends the funds, the anonymity set (size) for the R1 is 11 (size of Monero ring signature).

Sort of. It's not so much the spenders anonymity set is 11 (the ring size), rather the true output being spent has an anonymity set size of 11. For each input (an output) being spent, is one of 11 possibles.


What is the format of a block in the Monero Blockchain? What is in the header? How is the header made? What information about the transactions is present? What is prunable? What part of the block is used for the PoW?

Block

A block is defined in CNS003 as:

  block: a set of data (payload) with a block header

The structure of a block follows, and it is:

  Block Structure

  A block consists of three parts:

  block header,
  base transaction body,
  list of transaction identifiers.

  The list starts with the number of transaction identifiers that it
  contains.

In Monero source code, it is implemented as the block class.

The class inherits the block header class and adds the base transaction body as transaction miner_tx;, and list of transaction identifiers as std::vector<crypto::hash> tx_hashes;.

Block Header

Block header is also defined in CNS003:

  4.1  Block Header

  Each block starts with a block header. The major version defines the block header parsing rules (i.e. block header format) and is incremented with each block header format update. The table below describes version 1 of the block header format. The minor version defines the interpretation details that are not related to block header parsing.

  It is always safe to parse the block header of a particular major version with a parsing procedure suitable for said version, even if the minor version is unknown. Parsing the block header with an unknown major version is not safe as the content of the block header may be misinterpreted.

   +---------------+------------------+--------------------------------+
   |     Field     |       Type       |            Content             |
   +---------------+------------------+--------------------------------+
   | major_version | varint           | Major block header version     |
   |               |                  | (always 1)                     |
   +---------------+------------------+--------------------------------+
   | minor_version | varint           | Minor block header version     |
   |               |                  |                                |
   +---------------+------------------+--------------------------------+
   | timestamp     | varint           | Block creation time            |
   |               |                  | (UNIX timestamp)               |
   +---------------+------------------+--------------------------------+
   | prev_id       | hash             | Identifier of the previous     |
   |               |                  | block                          |
   +---------------+------------------+--------------------------------+
   | nonce         | 4 bytes          | Any value which is used in the |
   |               |                  | network consensus algorithm    |
   +---------------+------------------+--------------------------------+

             Table 4.1: Block header structure description

The definition of block header is found in Monero source code as well.

  struct block_header
  {
    uint8_t major_version;
    uint8_t minor_version;  // now used as a voting mechanism, rather than how this particular block is built
    uint64_t timestamp;
    crypto::hash  prev_id;
    uint32_t nonce;

Note that major version is used for hard-fork upgrade counting, as seen in Monero source code (1, 2). Looks like it's not exactly following the CN specification, where it was supposed to be changed only if the header parsing scheme changes.

Block Identifier

Each block has a block ID. The block ID of the previous block is made part of header of current block. It is also defined in CNS003:

  Calculation of Block Identifier

  The identifier of a block is the result of hashing the following data with Keccak:

  size of [block_header, Merkle root hash, and the number of transactions] in bytes (varint)
  block_header,
  Merkle root hash,
  number of transactions (varint).

  The goal of the Merkle root hash is to "attach" the transactions referred to in the list to the block header: once the Merkle root hash is fixed, the transactions cannot be modified.

Note that the block identifier is the result of hashing the blob with Keccak and it is not the same as PoW hash.

Mining / PoW Input

The mining data blob is the block header + merkle root + number of TX-es. It's hashed with CryptoNight to obtain the block difficulty. It's similar to block identifier given above, and omits the "size of [block header, ..." which is used exclusively for the block identifier.

See get_block_hashing_blob implementation in Monero source code for details.

  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;
  }

As you can see, it retrieves the block header blob, and appends Merkle tree root and number of transactions to the blob.

Block PoW Hashing

For actual hashing, see get_block_longhash implementation in Monero source code and explanation of the "block 202612 bug workaround": What happened at block 202612?

Merkle Tree Root

Merkle tree root is computed as follows, as defined in CNS003:

  5.1  Merkle Root Hash Calculation

  Merkle root hash is computed from the list of transactions as follows: let tx[i] be the i-th transaction in the block, where 0 <= i <= n-1 (n is the number of transactions) and tx[0] is the base transaction. Let m be the largest power of two, less than or equal to n. Define the array h as follows:

   h[i] = H(h[2*i] || h[2*i+1])
     where 1 <= i <= m-1 or 3*m-n <= i <= 2*m-1.
   h[i] = H(tx[i-m])
     where m <= i <= 3*m-n-1
   h[i] = H(tx[i-4*m+n])
     where 6*m-2*n <= i <= 4*m-1.

  Where H is the Keccak function that is used throughout CryptoNote, and || denotes concatenation. Then, h[1] is the root hash.

  The figure below illustrates the calculation of Merkle root hash in a block with 9 transactions. Each arrow represents a computation of H.

+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
 |tx[0]| |tx[1]| |tx[2]| |tx[3]| |tx[4]| |tx[5]| |tx[6]| |tx[7]| |tx[8]|
 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
    |       |       |       |       |       |       |       |       |
    |       |       |       |       |       |       |       V       V
    |       |       |       |       |       |       |    +-----+ +-----+
    |       |       |       |       |       |       |    |h[30]| |h[31]|
    |       |       |       |       |       |       |    +-----+ +-----+
    |       |       |       |       |       |       |       |       |
    |       |       |       |       |       |       |       +---+---+
    |       |       |       |       |       |       |           |
    V       V       V       V       V       V       V           V
  +----+ +----+  +-----+ +-----+ +-----+ +-----+ +-----+     +-----+
  |h[8]| |h[9]|  |h[10]| |h[11]| |h[12]| |h[13]| |h[14]|     |h[15]|
  +----+ +----+  +-----+ +-----+ +-----+ +-----+ +-----+     +-----+
    |       |       |       |       |       |       |           |
    +---+---+       +---+---+       +---+---+       +-----+-----+
        |               |               |                 |
        V               V               V                 V
      +----+         +----+           +----+           +----+
      |h[4]|         |h[5]|           |h[6]|           |h[7]|
      +----+         +----+           +----+           +----+
        |               |               |                 |
        +-------+-------+               +--------+--------+
                |                                |
                V                                V
              +----+                          +----+
              |h[2]|                          |h[3]|
              +----+                          +----+
                |                                |
                +----------------+---------------+
                                 |
                                 V
                           +-----------+
                           |root = h[1]|
                           +-----------+

           Figure 5.1: Merkle root hash calculation algorithm

Base Transaction Body / Coinbase TX

This is also known as "coinbase transaction" and is defined in CNS003:

  Each valid block contains a single base transaction. The base transaction's validity depends on the block height due to the following reasons:

 - the emission rule is generally defined as a function of time;

 - without the block height field, two base transactions could be indistinguishable as they can have the same hash (see [BH] for a description of a similar problem in Bitcoin).

The structure is as follows:

   +---------------+------------------+--------------------------------+
   |     Field     |       Type       |            Content             |
   +---------------+------------------+--------------------------------+
   | version       | varint           | Transaction format version     |
   |               |                  |                                |
   +---------------+------------------+--------------------------------+
   | unlock_time   | varint           | UNIX timestamp. See [CNS004]   |
   |               |                  |                                |
   +---------------+------------------+--------------------------------+
   | input_num     | varint           | Number of inputs. Always 1 for |
   |               |                  | base transactions              |
   +---------------+------------------+--------------------------------+
   | input_type    | byte             | Always 0xff for base           |
   |               |                  | transactions                   |
   +---------------+------------------+--------------------------------+
   | height        | varint           | Height of the block which      |
   |               |                  | contains the transaction       |
   +---------------+------------------+--------------------------------+
   | output_num    | varint           | Number of outputs              |
   |               |                  |                                |
   +---------------+------------------+--------------------------------+
   | outputs       | array of outputs | Array of outputs. See [CNS004] |
   |               |                  |                                |
   +---------------+------------------+--------------------------------+
   | extra_size    | varint           | Number of bytes in the Extra   |
   |               |                  | field                          |
   +---------------+------------------+--------------------------------+
   | extra         | array of bytes   | Additional data associated with|
   |               |                  | a transaction                  |
   +---------------+------------------+--------------------------------+

           Table 4.2: Base transaction structure description

This is how a miner gets his reward. He is free to generate the output as he wishes, which will hold the newly issued monero. Normally, it would be an output which will belong to his wallet, but it doesn't have to be. For example, a pool miner would be hashing a block where the pool picked the coinbase destination.

List of Transaction Identifiers

It is also defined in CNS003:

  4.3  List of Transaction Identifiers

  Base transaction is followed by a list of transaction identifiers. A    transaction identifier is a transaction body hashed with the Keccak    hash function. The list starts with the number of identifiers and is    followed by the identifiers themselves if it is not empty.

The structure is as follows:

   +---------------+------------------+--------------------------------+
   |     Field     |       Type       |            Content             |
   +---------------+------------------+--------------------------------+
   | tx_num        | varint           | Number of transaction          |
   |               |                  | identifiers                    |
   +---------------+------------------+--------------------------------+
   | identifiers   | array of hashes  | Array of transaction           |
   |               |                  | identifiers                    |
   +---------------+------------------+--------------------------------+

    Table 4.3: List of transaction identifiers structure description

What follows is the transaction bodies.

Transaction Structure

The transaction structure is explained here: Size requirements for different "pieces" of a Monero transaction

Examples

Monero Block

Command monerod print_block 1300000

timestamp: 1493568547
previous hash: 217b2757da92bc6369fc22d79ef16911fc0716bcea106450c94619e905f3c796
nonce: 25166505
is orphan: 0
height: 1300000
depth: 139416
hash: 31b34272343a44a9f4ac7de7a8fcf3b7d8a3124d7d6870affd510d2f37e74cd0
difficulty: 7877790006
reward: 7883911503742
{
  "major_version": 5,
  "minor_version": 5,
  "timestamp": 1493568547,
  "prev_id": "217b2757da92bc6369fc22d79ef16911fc0716bcea106450c94619e905f3c796",
  "nonce": 25166505,
  "miner_tx": {
    "version": 2,
    "unlock_time": 1300060,
    "vin": [ {
        "gen": {
          "height": 1300000
        }
      }
    ],
    "vout": [ {
        "amount": 7883911503742,
        "target": {
          "key": "7c54ec2fad8c41bb40cde9b78c002572ba777b05bb3bc80d0055c0d3489fdb17"
        }
      }
    ],
    "extra": [ 1, 116, 174, 179, 44, 181, 153, 245, 119, 27, 105, 192, 244, 181, 175, 62, 47, 244, 15, 129, 8, 223, 115, 234, 203, 131, 15, 62, 152, 103, 136, 144, 134, 2, 8, 0, 0, 0, 10, 174, 4, 8, 0
    ],
    "rct_signatures": {
      "type": 0
    }
  },
  "tx_hashes": [ "140564273396a16135ba0867ded6b7981fdc28bda45c62f993dc51ff26cfb2e5", "a32087d20f25e45097da9c899d8ec17df1d7563abe19047b3d115fe894bbf383", "4d2996d78485bd41980c79a7573e91fb06960a96884eda6b47877be8bc0e4eb4"
  ]
}

Monero Transaction

Command monerod print_tx 140564273396a16135ba0867ded6b7981fdc28bda45c62f993dc51ff26cfb2e5

Found in blockchain at height 1300000
// raw TX data comes here, edited out due to size
{
  "version": 2,
  "unlock_time": 0,
  "vin": [ {
      "key": {
        "amount": 0,
        "key_offsets": [ 58050, 114696, 565113
        ],
        "k_image": "000b744c27385c6179d1327de7926c4663ecf59ead1fa297a09cc856f53b5ce9"
      }
    }
  ],
  "vout": [ {
      "amount": 0,
      "target": {
        "key": "5f68b6e26c114b773bbc1d982255691018a70ca8b307fb63a70761df7d6384cd"
      }
    }, {
      "amount": 0,
      "target": {
        "key": "4e358822f55f27c6e12d51b0baf5ccfc471ae77208113ac9dc223197469d5c88"
      }
    }
  ],
  "extra": [ 1, 160, 134, 200, 194, 248, 112, 79, 200, 127, 185, 129, 147, 143, 194, 243, 211, 149, 139, 61, 112, 185, 86, 156, 121, 117, 232, 58, 42, 174, 162, 137, 213
  ],
  "rct_signatures": {
    "type": 1,
    "txnFee": 100000000000,
    "ecdhInfo": [ {
        "mask": "fb052c0d0bb478f75c8bf1a8e843473125d394caa4a1cec357792ae71ad2d30d",
        "amount": "60f8c83df2b16931bcf0e9af074f287acea41bd45b20e3c345be83370e3b440a"
      }, {
        "mask": "e85d36af212af85c7f556ea1e689ceca581bc87cec26f83a1d77fc1a4bd1420c",
        "amount": "b0e2961761673e749c0b36f8b1ac92dc85ebc6b9bda6ea804f3984028cc4e701"
      }],
    "outPk": [ "3bf4e8e8de2bbdd353486a50a46fd3dd380f8a0c3ac90eee6d4592c07585c1f2", "184c27a770095246ba6142e9e2cc4afd1d7506ce15d592cb2bcc3b9e4ac0880e"]
  },
  "rctsig_prunable": {
    "rangeSigs": [ {
        "asig": "6b9c...6902",
        "Ci": "78cc...3238"
      }, {
        "asig": "5d18...6d07",
        "Ci": "ce44...941b"
      }],
    "MGs": [ {
        "ss": [ [ "ce5f0dbb6a923862fd2a2e579520373721398774ec35485624888eeaab3ebd06", "120b8c025057494f357eab94cf8b81f6323d8d7639949e1efe889a119c96be0f"], [ "b5827d8931f597f37a0a445d526b279a9ab9b22caff1208c11e802b4b88e0e08", "f9977e6fd9aef346740b03491ddadcc6150f3206d0d40cde56de4d05c339f106"], [ "2a3438085f9ede8027257bbae261229e00f0a5f8fbe94a8e21050f42788e1d0e", "7b792d639af9fef1d2180fa60ee64a3940547fccf3e33b7653d6944e8e74f70c"]],
        "cc": "b46f8fbc1b2fde02a1b11b717259f275f19f190c4a7f39d30ca928c785fd6903"
      }]
  }
}


Historical XMR price volatility compared to BTC Where can I find historical volatility data comparing Monero with Bitcoin, measured against major fiat currencies (prefer data on EUR, GBP, AUD, NZD, USD, CAD, CHF, CNY or JPY) since the launch of Monero in 2014?

Secondly, where can I find volatility data for Bitcoin from the first two years following it's launch in 2008 to compare against the same data from the first two years of Monero trading?

Poloniex.com is the largest market for Monero and maintains records for XMR and BTC price information which can be given in terms of USD via the symbol USDT.  This market-specific price information can be retrieved through their exchange tab or through the site's API (example).  Further API documentation can be found at https://poloniex.com/support/api/.