Is "Two-phase Proof of Work" suitable for Monero?

The question to ask isn't 'Can this be done?' but rather 'Is this something we can benefit from?'.

Since you did ask explicitly if it was possible, I'll address that first:

Yes, it's absolutely possible for Monero to adopt this proposed PoW algorithm.  The PoW algorithm is orthogonal to the issue of privacy, as long as the PoW algorithm chosen isn't one which encourages extreme centralization.

Now, as to the second part.  Is this something we would benefit from?

Absolutely not.  The PoW suggested here aims to solve the problem of miner centralization in the bitcoin ecosystem, by reducing the gap between ASICs and other devices.  It tries to do this without screwing those who have invested in ASICs over completely, and represents a compromise which might be more palatable than just switching PoW in a manner that makes all ASICs obsolete.

By switching to this 'compromise algorithm', which benefits 50% from ASICs, we'd require anyone wanting to mine Monero profitably to invest in ASICs.  That would greatly hurt our network security (because everyone has a general purpose computer to mine with, but almost nobody is going to buy an ASIC just for the purpose of mining).

We're already seeing a ton of unprofitable mining, by botnets and enthusiasts, and we'd lose that 'free' security by switching to an algorithm requiring special hardware.  This point will be even more important when smart mining (background mining when computer is idle) is implemented into the daemon and GUI.


Low XMR-STAK hash rate on two cards in a 8 card Linux NVIDIA rig

It's been some time since last time i mined with Nvidia GPUs, but let's try with some tips.

First of all, there are 2 versions of the last xmr-stak (2.0 and 2.1). I tried both (amd) and had slighlty better results from 2.0. I encourage you to try both.

Let's recommend you some settings:

-About blocks: take note of the number of SMX of your cards (10 for 1060 and 15 for 1070). The default first config run by xmr-stak its 3 times smx (30 for 1060 and 45 for 1070). If you are fine tuning, you want to increase this value smx times value each test (30-40-50 and so on for 1060; 45-60-75 and so on for 1070). blocks value must be multiple of smx.

-About threads: all i have to say about threads its that they have to be multiple of 8 (8,16,24,32 and so on).

Ok, being explained that, i can recommend you, if you are using, lets say GPU0 for display, to put some bfactor (8) and bsleep (100), just in the card its displaying image. You can do this for testing purposes, if you dont notice improvement and/or stability, just leave it both 0.

Before proceeding on testing, please leave all cards on stock settings (clocks and voltage), and test fine tuning EACH CARD AND EACH SETTING (B or T) per test, because if you fine tune more than 1, it will be hard to know which one is crashing if the system crashes.

Some good combinations? you have to try by yourself. I have seen 8x160 and/or 80x30 gtx 1060s doing over 500H. Those values complies with the rules above explained. For the 1070s you can start with 8x45 and going up with blocks in increments of 15 (smx value) each test.

Last, but not least important, remember VRAM consumption and 2Mb rule. If you want to know how much RAM will it cost the card with each settings, multiply B*T*2=VRAM used. So, a 80x30 value in a gtx 1060 will use about 80*30*2= 4.8GB of VRAM. You cannot run a setting with more than available GPU VRAM, it wont work.

Remember to document each result, to ensure you can max out your perfomance. Fine tuning is the most beautiful and time consuming activity when mining. Im pretty sure you will have so much fun and will spend a good chunk of time fine tuning each card.

Last recomendation: start with "threads 8", fine tune blocks number accordly until you find the limit (unstable mining and/or crash or GPU VRAM limit). Take note of the last good value, both for settings and hashrate. After you have managed to do so try with "threads 16", rinse and repeat. It can be the case that your card likes a middle value instead of so much blocks or threads.

Its a lil long post, but i think i have include most basics here. I dont get tired of this: TEST EACH CARD, dont think that because you found a good setting in one card, lets say, a GTX 1070, it will work in another GTX 1070 just fine. Nothing more wrong about that. There is something called "silicon lottery".

Once you have found nice limits in all of your cards, proceed with overclock/undervolt or w/e you want to do in smi. Again, for EACH CARD separately. never assume a setting will work in another GPU, even if they are twins. This guide works with every NVIDIA card. I hope this helps. Kind regards...


Bitfinex asks for 64 character payment ID to withdraw, but the wallet generates shorter ones

A payment ID is optional, and determined by whoever you're sending to. If you're sending to yourself, then you do not need a payment ID (or you can make one up as you see fit).

The payment ID is arbitrary data which the recipient can use to associate with a sender: for instance, if you were to sent to Poloniex (instead of your on wallet), then Poloniex would give you a payment ID to use so they can tell an incoming transfer is intended for your Poloniex account, and not anyone else's.

In this case, you can leave the payment ID empty.

Whether you can use an integrated address, I do not know. This depends on whether Bitfinex supports these. It seems likely, but you would have to try (and, if it fails, possibly ask support to recredit your Monero in case this is not automatic).

Long style payment IDs are obsolescent, but most exchanges still use those instead of shorter ones, which are baked directly in a Monero integrated address.


I was renaming the wallet and then trying to load new wallet name to gen. key.

Totally assbackards from what people said. Sorry.


Integrated Address generation gives 16 bit randomly generated payment ID

First, integrated addresses embed an 8 byte (64 bit, 16 hex chars), payment ID. Monero started with an older format of payment ID which allowed for 32 bytes, but this was deprecated in favor of shorter 8 byte encrypted payment IDs, as used by integrated addresses.

Second, when using the RPC method transfer, if you are transferring to an integrated address, you would not supply the optional parameter payment_id as this is already set in the integrated address.

  I have 16 character string and I want 64 character strings, in this case what should I do?

I strongly recommend against this. Payment IDs in general are being deprecated in favor of subaddresses. If you must use a payment ID right now, use the short payment IDs (e.g. the type embedded in integrated addresses), therefore limited to 8 bytes. There really is no good reason for any new implementations to use payment IDs.


To my knowledge, it's never been possible to have more than one process that is using the same wallet at the same time.

Should you need to run both the GUI and the wallet RPC at the same time, you can duplicate (and rename) the wallet files so you use one for the GUI and one for the RPC. They can both use the same daemon and will be operating on the same keys, but independent files. You will still be able to send and receive funds from both, but bare in mind, sending from one wont show in the other without a rescan of spent outputs.

Lastly of course, depending on your use case, you could run one of the wallets as a view-only wallet and the other as a normal view & spend. For this you would create a view-only wallet.


What are the changes in CryptoNight v2 PoW algorithm?

The main changes are:

reading a whole 64 byte chache line at a time: many recent processors will read 64 bytes at a time when fetching from RAM, so access to the whole set is virtually free after it's cached. Since ASICs don't have to behave like this, this will increase the memory bandwidth an ASIC needs by 4, since Cryptonight acts on 16 bytes at a time. A simple addition is done to ensure an ASIC can't just multiplex the data.
adding integer math operations (division and square root): on a CPU, these are "hidden" by the memory access latency. This will cause an ASIC to have to have extra circuitry to compute those, as well as prevent part of the pipelining an ASIC may be able to perform due to the serialization of data use and calculation.

On most recent enough CPU/GPU hardware (apart from ARM), performance was found to be from 85% to 95% of the performance of Cryptonight, see reports from https://github.com/monero-project/monero/pull/4218.


I can't setup a monero pool on current software

I would recommend you to use Snipa's nodejs-pool. It runs on NodeJS 8+ if I remember correctly and has auto-deployment script which does most of the work during setting up phase... Also, refer to repository's issues for further questions, I think you will get an answer there faster than here.


What happens as monero network hash rate decreases

Value of a coin and hash rate goes hand in hand.
If value of coin decrease, then miners will have less reward for their mining and will rather go mine some other more profitable coin.

So if a coin is used only by 2 people and have low value. The hash rate needed to run network is tiny, but network is still secure.

Motive behind doing a 51% attack is economic and when value of coin decrease, there is less interest to do an 51% attack, since attacker would gain less.
So when overall miners hash rate decrease and price of coin decrease, there is no higher danger for a 51% attack as before.


Accidently send funds to non-hardware wallet (GUI desktop). Would like to move them to hardware wallet

It seems as if it is possible to essentially send the funds "to myself" via transaction from non-hardware wallet account to my hardware wallet account. Am I correct in utilizing a transaction in this way to secure the funds on my hardware?

Yes.


Trying to understand how RCTTypeSimple works

I'm going to focus on this following part of your question as opposed to pointing out the issues in your math. The math used in Monero is covered very well, in full detail, in both Zero to Monero and MRL-0005.

But I think from this part of your question, and your other recent questions, here is your key problem:

  I cannot seem to decouple the signing process from proving that the inputs and outputs balance out, mainly because the signing process uses zG for some reason.

So let's take a step back. An MLSAG signature needs be constructed with a ring of input keys and commitments (real and decoys), then signed, to prove that the spender indeed owns one of the input keys in each input ring. The network also needs to be able to verify this, but crucially, without knowing which input in the ring is the actual input being spent.

We also need a way to hide transaction amounts from the rest of the network - only the sender and receiver should be able to decode the amounts. The Pedersen commitments fulfill this task, the amounts get blinded.

Now we also need to prove the sum of the real inputs being spent minus the sum of the outputs being created is zero and that they fall within a positive range.

The commitment to zero is used for both 1) validating the sum of the real inputs being spent minus the sum of the outputs being created is zero, but also 2) proving that an input being spent from an input ring is owned by the sender, without disclosing which input is the real input.

When speaking specifically about validating the real input amounts minus the output amounts is zero, recall that verifiers have a bunch of input commitments & public keys (one real, the rest decoys) and one or more outputs that need using in the calculation. They need to know that one of the input commitments used in the calculation is real. Clearly they cannot use all of them.

Finally, proving the amounts are all positive is the job of the range proof.

Hopefully that clears up some of your confusion. Perhaps reading specifically pages 8 & 9 of MRL-0005 may also help you, along with the math.

Update

Having digested a little more of your question, another thing jumps out at me that you seem to have missed:

  This would not be enough because the scheme does not end here, why?

Everything proceeding this part of your question, used the assumption (incorrectly), that there were only two inputs (the real ones). You miss the fact that if 2 inputs are being spent, there are actually 2 input rings of inputs. Each ring contains one real input being spent, the rest are decoys. Hopefully everything I detailed above helps you see why the scheme doesn't simply "end here", so to speak.

Monero uses a collection of interdependent pieces and it's well worth understanding the concepts behind these pieces and how they relate to each other before jumping head-first into the math.


how to run monerod as service on ubuntu 16.04


In the CLI wallet, how can I send to an address book contact?

Sending directly to an entry in the address book is not possible at the moment. In monero-wallet-cli, those entries can only be used via the address_book command. This is something that's not very hard add though, and might be a good first patch for a new contributor.


does current monero support submitting signed transactions from file?

Those transfer files need to be read and written using the same version of monero (or similar ones anyway).

Monero needs to be updated about twice a year, so you always have software which can work with the regular updates. Failing to do so means you'll drop off the network (but if others also do, you'll end up on a dead fork). The daemon should warn you if this is the case.

If the computer running your cold wallet is using old software, you need to update it first.


If you generated a wallet, you can use it. Online, offline, doesn't matter.

The minimum amount you have to mine before you will see the balance in your wallet is called "minimum payout" and depends on the pool you use. Every pool has a different minimum payout.

Take a look at this link so see different pools and their minimum payout.


Loki Daemon Node Crashed with Error Adding Block with hash and stuck at 99.99% sync

After trying a few times to sync and constantly getting stuck at 99% with that same error. I had to delete the Loki blockchain and just download it again. Instead of resyncing, just download the loki blockchain directly from: https://imaginary.stream/loki/

I did the following:

cd ~/.loki/lmdb
rm data.mdb
wget https://imaginary.stream/loki/data.mdb

Then start your loki daemon again.


GUI v0.13.0.3 does not start on Mac OS X (monero-wallet-gui cannot be opened because of a problem - Library missing)

This particular issue is fixed in GUI v0.13.0.4, which can be found here:

https://www.reddit.com/r/Monero/comments/9ti2on/gui_v01304_beryllium_bullet_released/

You can, most likely, resolve this issue by following selsta's suggestion here:

https://github.com/monero-project/monero-gui/issues/1658#issuecomment-430211706

Alternatively, you can try this suggestion:

https://www.reddit.com/r/Monero/comments/9oim67/monero_gui_v01303_not_opening_on_mac_osx_1014/e7untov/


Has a Monero GUI ever been hacked and the coins stolen?

To this date, I haven't seen anyone losing money from the GUI. When you think about it, it's not that simple: someone has to get not only your password but also the wallet file.


Auditing incoming transactions in Monero

Yes, the view key proves that outputs were destined for a particular wallet address. It cannot be proven whether these outputs were subsequently spent, but it can be guessed that they have been spent if the outputs are referenced in a transaction that creates a change output that is also destined for that same wallet (which someone with the private view key would be able to detect).
Yes, because both the output amounts and the blinding factors are encrypted using the shared secret H(aR) and included as part of the transaction data.


Fatal Error when trying to build monero-core

Got some help from radfish on github...

https://github.com/mbg033/monero-core/issues/52

Here's what radfish said...

  You need to manually merge monero-project/monero-core/PR # 14 in order
  to build (alternatively use develop branch in this repo), because
  monero daemon repo was updated to not build/install wallet lib/headers
  by default (need to pass BUILD_GUI_DEPS=ON option to cmake).

Here's what I did...

$ git clone -b develop https://github.com/mbg033/monero-core
$ cd monero-core
$ ./build.sh

And the resulting binary was in ~/monero-core/build/release/bin/monero-core


What language(s) should a new coder learn to contribute to Monero?

Monero is for most parts written in C++ and C. That is, currently 81.2% of the code is written in C++, whereas 15.9% of the code is written in C. The remaining languages are CMake, Shell, Python, Perl6, and Other. The "language distribution" can be seen here (click on the purple/pink bar to see the distribution). Thus, if you want to contribute to Monero you, preferably, ought to learn C++ and C. For Bitcoin this relatively similar. One small deviation is that the Bitcoin repository also contains a significant percentage of Python code. However, this is probably demo code. For Monero you can find this demo code in a seperate repository.

In addition, there is also the GUI to which you can contribute. Its repository can be found here. The GUI is for most parts written in QML and C++. That is, currently 80.0% of the code is written in QML, whereas 15.9% of the code is written in C++. The remaining languages are QMake, Shell, and Javascript. The "language distribution" can be seen here (click on the purple/pink bar to see the distribution). Thus, if you want to contribute to GUI you, preferably, ought to learn QML and C++. Note that for some GUI features you will also have to make changes to the general Monero repository.


How would a transition from cryptonight PoW to cuckoo cycle work?

Yes, that's basically what would happen if Monero switched to any other PoW. A good example is Vertcoin's switch from Scrypt-N to Lyra2RE (and then to Lyra2REv2).

Essentially, the changeover works like every other hardfork in the network. A future block height would be picked as the changeover point, after which the proofs of work in the block would have to follow the new algorithm. Node software would have to maintain the capability of verifying the cryptonote PoW as well as the new one because new nodes would need to be able to verify the work in all the blocks before the fork. Mining software would be able to abandon all cryptonote related code, though.

Note that as of now, my understanding is that Cuckoo Cycle can't be pool mined, which means the transition would have to have miners ready to start solo mining at the right height. This would be an issue that would have to be thought out carefully.


How do miners verify the Ring Signature of a transaction?

Monero transactions create outputs, which are where funds are stored. Each output has a public key, also known as a one-time public key and sometimes as a "stealth address".

If Monero was like Bitcoin, then to spend the output you would demonstrate knowledge of the private key associated with that public key. This is achieved using a signature.

But Monero prevents observers from knowing which output is really being spent. Therefore instead of providing a signature proving knowledge of the private key corresponding to one particular public key, a ring signature is provided which proves knowledge of one private key for an explicitly stated list of possible public keys.

Therefore each ring signature explicitly references all of the possible public keys whose outputs could potentially have been spent.

It is not necessary to do any kind of random "trying" of public keys. The list of possible public keys is listed, and no further information about which public key is actually being spent can be known.

Ring signatures are a set of data that can be validated by performing a set of mathematical operations on that data. The operations prove that a private key must have been known for one of the public keys referenced, but it cannot be mathematically determined which. The math is detailed on page 20 onwards of this document: https://github.com/UkoeHB/Monero-RCT-report/blob/master/Zero-to-Monero-1-0-0.pdf


Yes, it is a mistake. It should read:

This subaddress public spend key is multiplied by the primary private view key to yield the subaddress public view key


There is no code for doing cold multisig. There is not really much point since you can have one of your multisig wallets on an offline machine already, so adding a cold/hot system would not really add much I think.

If a multisig wallet on an offline machine cannot sign without a dameon, that should be fixed as I don't think it's inherently needed.


Payment ID is provided by the receiver of funds. In poloniex, It can be the case that they use Integrated addresses (where the payment ID its already attached to the public address). If its the case, you dont need to put Payment ID in bitfinex when sending to polo. Looking at this tweet seems to corroborate the above description. I hope this helps. Kind regards...


Basically what jwinterm said.

I think your best bet, assuming you want to do something else with your computer while catching up rather than catch up ASAP, would be to add --prep-blocks-threads 1 (or 2; it defaults to 4) to your command line. This will make it use only one (or two) core(s) to compute POW while in "catch up" mode.


I did this to recompile libgtest-dev with -fPIC and it worked for me.

sudo apt-get install libgtest-dev
cd /usr/src/gtest/
sudo cmake -DCMAKE_CXX_FLAGS="-fPIC"
sudo make
sudo mv libg* /usr/lib/


What is the purpose of the tail emission?

The first question one needs to ask before even considering adaptive
  blocksize limits is: Can a fee market actually work in the absence of
  a base emission?

  We first consider a blocksize large enough (or effectively infinite). In this scenario competition among miners will drive fees
  towards zero since there is no scarcity. This will in turn cause the
  difficulty and consequently the security of the crypto currency to
  collapse. We must keep in mind that orphan block based arguments will
  also fail since these are based on the presence of a base emission.
  This is in fact the very legitimate fear of the small block
  proponents.
  In the second case we consider a fixed blocksize, where the blocksize is small enough to impact fees. In this scenario we have a
  potentially infinite demand with a fixed supply. In theory fees
  therefore would go to infinity. We must keep in mind that as the
  legitimate demand rises towards the fixed limit, It becomes
  economically attractive for miners with a even small percentage of the
  hash rate to spam the network in order to profit by raising the
  overall fees. At this point only external competitive factors can stop
  the fees from rising to infinity. These take the form of fiat payment
  methods and other crypto currencies with the latter being not affected
  by a fixed blocksize limit. The impact of these external competitive
  factors is to reduce demand by devaluing the entire crypto currency.
  This will be delayed by miner spam, as miners will increase the spam
  in order to preserve the dwindling purchasing power of their fees
  until the system collapses to little or no transaction demand leading
  the first case above.

  The problem as I see it is that the system is inherently unstable.
  Either the mining revenue collapses first or the purchasing power of
  the mining revenue collapses first. We now come to the next question.
  Can one create an adaptive blocksize limit formula that does not
  converge as time increases towards (1) or (2) above? My instinct tells
  me no, particularly since the network has no way to measure the key
  parameter namely the amount of fees collected per block due to out of
  bound payments to miners. Furthermore there have been many brilliant
  minds looking at this issue and they have not come up with a solution.
  Proving this negative, in a rigorous mathematical sense, is of course
  another matter entirely. What the tail emission in Monero does is
  provide a stable anchor outside of the control of the miners on top of
  which an adaptive blocksize limit and a fee market can actually
  develop, by avoiding the instability above.

source: ArticMine


What is the maximum length of the payment id in Monero transactions?

Payment IDs come in two forms:

Old style payment IDs are 256 bits, and are plaintext. That's 64 hexadecimal characters.

New style payment Ids are 64 bits, encrypted on the blockchain. That's 16 hexadecimal characters. Those are almost always embedded in an integrated address, which conveniently pack both your standard Monero address and the payment ID.

If you want to put less data than 256 bits in a plaintext public payment ID, you can pad with zeroes.


As a XMR recipient after HF4 is there a way I can only accept RingCT payments?

If by "reject", you mean prevent that transaction from being mined and being available to your private key, then no.

If by "reject", you mean only act on rct payments, then you could ask the client for a monero address to return non-rct payment, possibly minus a small fee to cover the tx fee (for instance, I believe shapeshift will return your monero if you don't pay the exact amount, or if you send too late).

The intent of allowing both transaction types for a while is to leave some time for people to update, and not summarily reject transactions in too short a timeframe. Moreover, switching at once would mean the anonymity set for rct outputs would be pretty small for the first few rct outputs being sent in rct transactions, though that will fix itself quickly.

Please note that if you want rct outputs, you can resend any newly received non-rct outputs to yourself as an rct transaction.


How do I send XMR to multiple different addresses?

She can do just one TX, unless she wants to specify a different payment ID for each recipient.

The CLI wallet supports this, the format is transfer <address> <amount> [<address 2> <amount 2>] ... [<address n> <amount n>] [<payment ID>].

Note how there's only one payment ID. That's because you can specify only one payment ID per TX (for now at least, in theory it could be changed to multiple and it would work as long as everyone recognized and implemented the new convention).

I'm not sure what will be the wallet behavior if some of the addresses have payment ID integrated. Only one can be used, that's for sure, but I'm not sure which one would be picked by the wallet.

About the transaction size (by @kenshi84):
Assuming the ring size being the same, the single multi-destination transaction will be smaller in size than the multiple single-destination transactions combined, since the former can "reuse" the same input ring signatures for all the destinations.


Since Monero has a separate daemon monerod, which synchronises with the network, a command line wallet monero-wallet-cli and a GUI wallet monero-wallet-gui to generate keys, sign transactions etc.

Both wallet versions need a fully synchronised node to scan for new outputs. For best privacy, it's recommended to run an own node (locally or remotely hosted), since you will not disclose for what outputs your wallet is searching on the blockchain. However, when you have not the resources available due to a slow internet connection or no option to run a node 24/7, you can connect to an open node over the internet, which will save you bandwidth and disc space. For example moneroworld.com offers some open remote nodes.

For broadcasting own transactions you can probably keep even more privacy when using a hidden node over the i2p network, since you will not disclose your IP address along with your transaction to anybody.


Is it planned to implement Hashed Timelocked Contracts (HTLC) through the monero multisig wallet?

I don't believe that's planned just yet. In any case, Monero's time lock implementation is incompatible with that of Bitcoin-based currencies, so right now atomic swaps between Monero and, say, Bitcoin wouldn't work. At least a modification to the atomic swap protocol would be needed. https://github.com/monero-project/monero/issues/1184


What is the easiest way to setup a new public Oxen service node?

Follow the guide here as of May 2021:
https://docs.oxen.io/using-the-oxen-blockchain/oxen-service-node-guides/full-service-node-setup-guide
If setting up a brand new Ubuntu 20.04 server, you just need the following commands:
sudo curl -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg

echo "deb https://deb.oxen.io focal main" | sudo tee /etc/apt/sources.list.d/oxen.list

sudo apt update

sudo apt install oxen-service-node

oxend status

If you want to skip the downloading of the entire blockchain, you can always fetch the entire blockchain from:
https://public.loki.foundation
Just download and replace it directly to: /var/lib/oxen/lmdb
Another alternative is put this in a bash script and run it on a fresh install of Ubuntu 20.4:
#!/bin/sh
sudo curl -so /etc/apt/trusted.gpg.d/oxen.gpg https://deb.oxen.io/pub.gpg
echo "deb https://deb.oxen.io focal main" | sudo tee /etc/apt/sources.list.d/oxen.list
sudo apt update -y
sudo apt upgrade -y
apt install fail2ban magic-wormhole ack-grep oxen-service-node -y
systemctl stop oxen-node
cd /var/lib/oxen/lmdb
rm data.mdb
wget https://public.loki.foundation/loki/data.mdb
chown _loki: data.mdb
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile swap swap defaults 0 0" >> /etc/fstab


How can I get my own genesis tx to use in my monero fork?

I had the same problem. I had to solve it by writing custom function. It generates new account, save account keys to file, and sends block 0 reward money to it in genesis transaction. It also generates source code line to be changed in the cryptonote config file.

Note: Monero CLI wallet would not see block reward sent in this transaction because it does  not process genesis tx - processing of it has to be forced in wallet code.

I have also added command line option --print-genesis-tx to src/daemon/main.cpp where I call this function.

// Helper function to generate genesis transaction
void print_genesis_tx_hex(uint8_t nettype) {

using namespace cryptonote;

account_base miner_acc1;
miner_acc1.generate();

std::cout << "Gennerating miner wallet..." << std::endl;
std::cout << "Miner account address:" << std::endl;
std::cout << cryptonote::get_account_address_as_str((network_type)nettype, false, miner_acc1.get_keys().m_account_address);
std::cout << std::endl << "Miner spend secret key:"  << std::endl;
epee::to_hex::formatted(std::cout, epee::as_byte_span(miner_acc1.get_keys().m_spend_secret_key));
std::cout << std::endl << "Miner view secret key:" << std::endl;
epee::to_hex::formatted(std::cout, epee::as_byte_span(miner_acc1.get_keys().m_view_secret_key));
std::cout << std::endl << std::endl;

//Create file with miner keys information
auto t = std::time(nullptr);
auto tm = *std::localtime(&t);
std::stringstream key_fine_name_ss;
key_fine_name_ss << "./miner01_keys" << std::put_time(&tm, "%Y%m%d%H%M%S") << ".dat";
std::string key_file_name = key_fine_name_ss.str();
std::ofstream miner_key_file;
miner_key_file.open (key_file_name);
miner_key_file << "Miner account address:" << std::endl;
miner_key_file << cryptonote::get_account_address_as_str((network_type)nettype, false, miner_acc1.get_keys().m_account_address);
miner_key_file << std::endl<< "Miner spend secret key:"  << std::endl;
epee::to_hex::formatted(miner_key_file, epee::as_byte_span(miner_acc1.get_keys().m_spend_secret_key));
miner_key_file << std::endl << "Miner view secret key:" << std::endl;
epee::to_hex::formatted(miner_key_file, epee::as_byte_span(miner_acc1.get_keys().m_view_secret_key));
miner_key_file << std::endl << std::endl;
miner_key_file.close();

//Prepare genesis_tx
cryptonote::transaction tx_genesis;
cryptonote::construct_miner_tx(0, 0, 0, 10, 0, miner_acc1.get_keys().m_account_address, tx_genesis);

std::cout << "Object:" << std::endl;
std::cout << obj_to_json_str(tx_genesis) << std::endl << std::endl;

std::stringstream ss;
binary_archive<true> ba(ss);
::serialization::serialize(ba, tx_genesis);
std::string tx_hex = ss.str();
std::cout << "Insert this line into your coin configuration file: " << std::endl;
std::cout << "std::string const GENESIS_TX = \"" << string_tools::buff_to_hex_nodelimer(tx_hex) << "\";" << std::endl;

return;
}


Relationship between pseudoOuts and Real outputs

This seems to imply that we must choose the blinding factors in the pseduoOuts in such a way that the sum cancels out with the sum of the blinding factors

And that's what happens. The blinding factors chosen are random numbers [source] for all but the last input. Then the last inputs is calculated so that the sum of all inputs is the same as the sum of the outputs [source].


Opening Port 18080 for Incoming Connections on Router

The methods to open ports are specific to the router you have. You don't need physical access to the router, just access to the routers web admin interface. So, I suggest you search for your specific router model and instructions, if this is your own router.

If you are on a non-configurable network like a public WiFi, instead you need to ask the Internet provider to open the port for you.

If you need to configure the Ubuntu firewall, you can install iptables plus ufw and open the 18080 port on the firewall with the directive ufw allow.


Did you try a different Address or checked your Address if it is correct? I tested it using an invalid address and I got almost the same error. However, valid address works!

[2017-04-18 00:38:10] : MEMORY ALLOC FAILED: VirtualAlloc failed.
[2017-04-18 00:38:10] : Starting single thread, affinity: 0.
[2017-04-18 00:38:10] : Starting single thread, affinity: 1.
[2017-04-18 00:38:10] : MEMORY ALLOC FAILED: VirtualAlloc failed.
[2017-04-18 00:38:10] : Connecting to pool pool.minexmr.com:7777 ...
[2017-04-18 00:38:14] : Connected. Logging in...
[2017-04-18 00:38:14] : SOCKET ERROR - invalid address used for login


What does the 'Sweep Unmixable' button in the current version of the GUI do?

TL;DR It allows you to 'get rid' of outputs in your wallet which have strange amounts like 0.000006839355, and are unmovable without combining them with another output. However, they are unmovable only if they are non-RCT or came before the 2nd hard-fork. Chances are, new users will never have to use this command.

First, let me explain why they're 'unmixable' in the first place.

Your balance is made up of outputs of various amounts which you've received in the past. Every time you send, some of those get combined together until you reach some amount, which is then sent to the destination, and some change returned to your wallet.

Think of outputs as bills: you received a bill of 40 and 100 in the past, and now you want to pay something worth 120. Your wallet 'burns' the 100+40 bills, creates new bills of 120 and 20, sends the 120 to your recipient and returns the 20 to yourself and you're left with the bill of 20, plus whatever else you already had in the wallet. In Monero, these 'bills' can now be created with any amount (pre-RCT, they had to be round numbers like 10, 1, 0.1, 0.01 ...).

Thing is, Monero combines multiple outputs in a ring-signature, effectively hiding the one actually getting spent among other outputs found in the ring signature. Now, with RCT, you can pick any output for the ring signature because all the amounts are hidden. Before, you had to choose other outputs of the exact same value. This required splitting any amount into multiple outputs with common denominations, but there were always some of them which were unique, like 0.000006839355. There's simply no other like it, so there are no other outputs among which it could hide, and it would have to get spent alone. It's a special case which doesn't benefit from applying ring signatures and thus the special treatment. Because of this, you'd only want to use it once to join it with other outputs. The sweep_unmixable command is there to get rid of those special outputs once and for all (if you actually have them in your wallet, that is).


What is src/blocks/checkpoints.dat and why is it not plaintext in the source code?

It is the set of block hashes from the genesis block to a fairly recent block, and is used to speed sync up for historical blocks. It is typically updated shortly before a new release.

Those hashes are stored as is so they can be read without having to parse hex strings, which would be slower and use more memory.


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

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


Will 2 minute block times discourage retail merchant adoption?

Actually, instant (well, speed of information) payment channels are possible with monero, even now (no protocol changes to monero necessary).

First we will just start with one way payment channels. The merchant and buyer set up a some sort of multisig wallet. They mutually sign a transaction that sends the its contents back to the sender. The signature is sealed in time-release crypto using steps 2 through 2 through 4 here which forms the expiration date of the channel (which can be updated). The merchant will want to not accept transactions after or even near the expiration date. The time release crypto only needs to be released if the merchant is dishonest; an honest merchant can help the buyer recover his funds without it.

Now, to send funds to the merchant, such that the merchant instantly knows he cannot be cheated, the merchant and buyer simply mutually sign a transaction to the merchant's personal monero address. This can not be double spent, since the merchant would need to sign a transaction to double spend it. Additionally, they need to create a new expiration transaction, since it will have the wrong input. This also gives them an opportunity to set up a new release date.

You can also encrypt the transactions with the merchant's public key. This means that if the buyer sends them X monero, but then wants to send them Y, the merchant and buyer can simply create a new X+Y monero transfer, without the merchant fearing that the X monero transaction would override it (as long as he didn't publish it). The merchant could, say, publish these transactions once day, making this system ideal for micropayments.

Exercise for the reader: generalize the above into lightning network (hint: even more Secure multi-party computation will be needed).


block 202612 , how been findet this value?

It's pow value , can be find at set_log 2


How to check the number of confirmations for a transaction?

As far as I know there is currently no "amount of confirmations" displayed by any of the block explorers. However, an easy way around this is to subtract the block your transaction was included in from the current blockheight. This will give you the number of confirmations. Thus, let's say your transaction was included into block 1111111 and the current blockheight is 1111130, your transaction has 1111130 - 1111111 = 29 confirmations.

Note that you can check the blockheight of your transaction by entering the transaction ID / hash into MoneroBlocks. The From Block is the blockheight your transaction was included in. The Height on the front page of MoneroBlocks is the current blockheight.


Relationship between a pool and local wallet

Basically, for every block the pool finds (when you are actively mining) it will credit you some XMR proportional to your share of the pool's hashrate. For example, if your hashrate is 1 KH/s and the pool's hashrate is 100 KH/s (so 1/100th), they will credit you 1% of the coinbase transaction (i.e. the block reward + fees). I am saying approximately because pools can use PPS (Pay-Per-Share), PPLNS (Pay-Per-Last-N-Shares), or something else, which can result in the hypothetical 1% being somewhat off. In addition, to clarify, this is done off-chain. Then, once you reach a certain treshold (at the time of writing it's typically 0.5 XMR), the pool will pay you out (on-chain). That is, they will send the 0.5 XMR to the wallet address that you specified in your config.

A bit more on PPS and PPLNS from here:

  However, note that interruptions affect how much you will win in the first place. There are 2 different pool policies PPS (pay per share) and PPLNS (pay per last N shares). With PPS, you will always win a piece of block reward proportional to your shares submitted to the pool / total shares submitted to the pool. With PPLNS it's a bit different, to discourage pool hopping.


Monerod finished syncing but now never catches up in GUI wallet, monerod still syncing

Step 1:
cd ~/Downloads/monero-gui-0.10.3.1-beta2

Step 2:
wget -c --progress=bar https://downloads.getmonero.org/blockchain.raw

Step 3: I
./monero-blockchain-import --guard-against-pwnage 0 --input-file ./blockchain.raw

Step 4:
rm -rf ./blockchain.raw

Step 5:
./monerod --detach


Why is the Monero hash rate so low after the v7 fork compared to other Monero forks?

When Monero forked to v7, it changed its proof of work algorithm. While it previously used Cryptonight, it now uses a slight variant (technically, variant 1) of Cryptonight, which should be typically slightly slower to compute.

After the fork, miners would were not able to update their hash algorithm were left unable to mine Monero. While patches were made to most known mining software, one major type of miner could not update: ASICs.

ASICs are hardware made to run one particular piece of code fast, and nothing else. ASICs were made to mine Cryptonight, and were able to do it much faster than CPUs and GPUs, leaving normal users out in the cold. When Monero forked, these ASICs were left unable to mine Monero, causing the overall network hash rate to plummet, restoring viability to everyone else.

However, these ASIC miners could still mine other forks such as Monero Classic which are still using the legacy proof of work, leading to high hash rates. However, since they are mining incompatible algorithms, their hash rate can no longer be compared. Indeed, the average time to compute a "variant 1" hash is larger than the average time to compute a legacy hash, since ASICs exist to compute legacy ones very fast.


Alternate Coins Implementation in this pool

Adding a new coin to the pool requires creating and implementing a new js file in /lib/coins, creating and implementing a new js file in /lib/payment_systems and referencing both these new files in the coinConfig.json file. If you just duplicate an existing coins files and edit appropriately, that's probably the easiest method. Note, you'll need to be running a daemon for any coin you add of course.

With regards to running multiple coins in a single pool, you can't with nodejs-pool.


Maybe the easiest would be to go through VPN, although I don't know exact instructions.

The amount of traffic shouldn't be much considering what's being transmitted and the frequency of it. Possibly increase your mining difficulty so that your miner doesn't spam solved shares every second (which also reduces efficiency of your mining due to communication overhead), but not too much so you don't time-out. Maybe 10s target would be just fine.

There's only one miner which supports SSL connection: https://www.reddit.com/r/Monero/comments/5ow0ch/supportxmr_optimized_claymore_ssl_support/


Is there a Monero project or improvement proposal to make Monero have instant transactions?

In Monero, like other cryptocurrencies, the transactions themselves are fairly instant - they get instantly broadcast to the network and get placed in the tx pool. Wallets also see these transactions pretty much instantly.

A transaction however is not deemed confirmed until it has been mined into a block. And even then, because there can be small reorgs on the main chain, allowing a sensible depth of blocks mined increases the likelihood of a transaction sticking (i.e. not being naturally caught up in a reorg or a malicious double spend for example).

This is the reason the Monero wallets enforce a 10 block (~20 minutes) confirmation/lock time  before deeming a transaction fully complete.

A receiver (merchant) of XMR, can of course choose any confirmation window they like to release goods. Some merchants will take on a small risk by releasing goods on a zero-conf basis (e.g. as soon as they see the tx in the tx pool). In this situation it is an "instant" transaction of goods. The merchant is taking a small risk here by releasing goods before they are sure the tx won't get reversed.

All cryptocurrencies based on a PoW chain have this situation. Of course, others may develop wallets that don't place a sensible lock time on funds, but then they are pushing the risk onto users who may not fully understand the risks / implication of this.


Does the new v5 hardfork low fee option create a risk for blockchain bloat?

I understand the only thing limiting people from inserting, for example, a 180MB FLAC encoded recording of The Sign into the tx-extra field in a Monero transaction is the high fees they pay per kb.

That's the 2nd limiting thing, really. First, we'd have to somehow get to a block size median of min. 90MB. The dynamic block size and reward penalty make it expensive. Not only that, but 51% miners can veto a median increase even if there is enough fee pressure to justify an increase. Also, 51% miners can "reset" the median to a lower value and have the "attacker" work his way up all over again - paying the price all again.

  Considering the v5 hardfork creates a new fee tier that allows very cheap transactions per kb, doesn't this create a new risk for inordinate blockchain bloat, where people could potentially include an abusive amount of data in tx-extra for very little money?

Well, it will not really be "very cheap". It will be exactly 4x cheaper than what it is now. It should create smoother experience for "normal" users because 4x multiplier will become wallet default (the cost/TX will be the same as it is right now pre-HF). We can assume pools will use 1x, so "normal" human-made transactions should skip the queue of pool payouts. Any "spam" at 1x would also not be felt by users sticking to the defaults as they would skip over the "spam". When the network usage would drop, it would make room for those 1x TX-es which could get into blocks - and so what? Some of them would be pool payouts, some of them could be "spam" but they would really achieve nothing other than writing some useless data to the blockchain.

Sure, if you want to systematically abuse the network, you could put whatever into the TX-extra and see where it gets you. You could also use a mixin of 10000 if you want to bloat the size of a single TX or you could spam the network with 10000 "normal" TX-es but if you want to prevent normal use you'd have to beat the default fee of x4, which is at around 0.3$/12kB. Chances are, the network would function just fine despite this spam so why would anyone bother?

Since Monero has strong privacy features, we can't really differentiate between transactions so some cost must be there to encourage rational use and that's all we can really do.


Unlocked Balance 0 , Balance is correct.

If, as you state, you are resyncing the entire blockchain, you will need to wait untill it has fully downloaded and been scanned by the wallet before being able to spend any unspent balance.


How to avoid antivirus to delete monero miner?

Try to set exceptions in the Anti-Virus software, which means to exclude certain directories and/or files to be excluded from scans.
It worked out for me for xmr-stak miner, which was detected as virus/trojan in MS Security Essentials.


How do I use a computer with a wallet to access a headless node at my home?

Yep! That can totally work. We'll call your headless node the Monerodo for simplicities sake (Monerodo = Monero Node).

On the Monerodo you want to launch monero with the following flag:

monerod --rpc-bind-ip IP.OF.YOUR.MONERODO

This tells your daemon to listen to RPC calls on the IP address provided.

Then on your other computers, you just run the wallet with:

monero-wallet-cli --daemon-host IP.OF.YOUR.MONERODO

And that's it!

You'll have to open the firewall for port 18081 on your Monerodo to allow connections between the two devices.


Hardware update required on Monero mining

Actually, the AMD Radeon VEGA cards, both 56 and 64, are the best options for mining Monero. Nothing is comparable to VEGA and with fine tuning you can reach really high hashrate (about 2000H/s) with really low TDP.

To understand how to config VEGA and miners, useful sources are:

Monero and Vega - the definitive guide
Vega Mining - A
Consolidated Guide

Regarding the processor, CPU is not important at all and doesn't play a significant role, but if you have a XEON or a RYZEN you can add nice hashrate to total value also mining with CPU.


What use cases exist for a high level of blockchain privacy?

The issue that comes with saying, "I have nothing to hide" in a privacy debate is a thorny one.  For example, even though you may have nothing to hide in your private communications with friends and family, would you be comfortable publishing all of your conversations on a public ledger, or even just handing over your Facebook and e-mail passwords to a stranger?

With regards to personal finances specifically, even though you may not make any illegal purchases, you can still benefit from privacy for a number of reasons including protection from issues such as:

Receiving targeted advertising based on your spending habits.
Revealing your net worth or salary, possibly making you the target of thieves.
Revealing to which charities, political campaigns, or causes you donate that others may not agree with.

Additionally, adding a layer of  privacy to your spending also helps in preventing fungibility issues with a cryptocurrency such as receiving "tainted coins" or having your address blocked by a third party for falsely "suspicious activity."

The items above are far from exhaustive, but hopefully it is now more clear why everyone stands to benefit from the privacy Monero offers.


Monero Helium Hydra - Segmentation Fault

This crash was fixed in https://github.com/monero-project/monero/pull/2492, and you can merge it to your tree with the following commands:

git checkout -b crash-fix
git fetch origin pull/2492/head:2492
git cherry-pick 2492

You're now on a branch with whatever source you had before, plus the crash fix. You can now compile normally.

When you want to get back to master (ie, to pull latest):

git checkout master


For what reason could I use the monerod 'ban' command?

If you run an instance of monerod with internet open bind ports, you may want to ban ips that are malicious or suspecious, like one trying a DOS attack or a node running a buggy version.

Dropping the packet based on its IP, before parsing it, drastically reduces the load on the server and the attack surface.


What are some proposed solutions to preventing ASIC's from mining Monero?

Monero forks every 6 months or so to prevent ASICs

Monero does a fork, which we call a network upgrade, roughly every 6 months. The upgrade isn't specifically to "prevent ASICs", that has just been one of the many things that have gone into the last couple of upgrades. Features both big and small get released in these upgrades - including ASIC resistance changes.

  Even with the new proposed RandomX pow algo, eventually ASICs will be built.

This is not necessarily correct. An ASIC (Application Specific Integrated Circuit), is built for one specific task (hence the Application Specific part of the name). RandomX/CryptoNightR are designed to be efficient on general purpose hardware by creating random tasks. A CPU (and GPU) are general purpose chips. For an ASIC to be developed that works with RandomX/CryptoNightR, it would essentially have to be designed in the same way as a CPU/GPU - e.g. be general purpose.


You're most likely using an old daemon, which cannot understand the new transaction output format. This is what you get for using some random daemon from somewhere on the internet :)

Either use your own, or find a sane one.


How does MoneroClub work?

It basically is similiar to LocalBitcoins. However, MoneroClub works more like a bulletin board, where buyers and sellers can find, and subsequently contact, eachother. From MoneroClub's website:

MoneroClub is localized peer to peer (P2P) exchange platform for Monero (XMR).
Compared to typical exchanges, MoneroClub is decentralized. MoneroClub never has control of your transactions or funds. Instead, buyers and sellers work directly with each other.
We recommend local cash transactions as the best way to prevent fraud and scams that often occur with PayPal, Western Union, or credit card transactions. However, it is possible to arrange any payment type with your correspondence.
MoneroClub behaves similarly to a bulletin board. Buyers or sellers post advertisements describing the prices and quantities of XMR they desire to exchange, and interested parties can contact them directly to work out the details.
We provide fixed or flexible pricing using a custom MoneroIndex (+/- any%) which removes dependencies on centralized exchanges for price information.
Meet nice people in your region and let MoneroCommunity grow!

Is there a trust system that can be used to compare traders?

At first glance, there does not seem to be some kind of trust system in place. Therefore, it is advised to be cautious when doing trades. Especially with a new trader.

Is escrow available?

Given that is kind of a bulletin board, there seems no escrow available. However, the core-team members are usually open to acting as escrow. You can contact them via their emails, or on IRC (#monero on Freenode).

How does the site make money?

As far as I can see the site is basically a non-profit and was build to contribute to the Monero ecosystem.


Do all coins using CryptoNote provide untraceabilty?

Kind of.

All CryptoNote coins use stealth addresses. This helps make it difficult to know what accounts receive money. Monero also uses stealth addresses. However, there are large differences with ring signatures and RingCT.

Ring signatures mask the source of funds being used to send a transaction. Monero mandates that at least 5 possible inputs must be used (including the real one) when sending a transaction. Few other cryptocurrencies have this same mandate. Bytecoin, for instance, allows people to send transactions without masking the source used. This means certain transactions are partially traceable, and this traceability even negatively impacts other transactions that try to mask this information. To substantially mitigate these concerns, Monero made this masking mandatory.

Furthermore, Monero includes RingCT, which hides the amount sent in a transaction. Most CryptoNote projects (especially old ones) do not include this, which means people can try to analyze the amounts being transacted.


Can I restore my account using just the keys file?

You DO need your password (which may be empty if you did not set one originally) to use your keys file. The keys file itself is encrypted by a key derived from your password.

If you do not have your seed, and lose your password, the keys file will be useless (unless you can brute force the password).

For the interests of clarity, "restoring" from a keys file is the same as "refreshing the wallet from the first block, rather than last refreshed block". They keys file is needed for both, and the wallet behavior is the same (except the refresh starting point is different). This may help see why your password is needed, since you input it when you open your wallet.


You are correct, that's all you have to do. However, when you restore it in a GUI/any live method its not a cold wallet anymore. So be very extra careful that the computer you are working has an anti-virus and you are positively sure that it is clean from malwares/keyloggers.

If you want to make your paper wallet still "cold", there are other ways you can view your funds. E.g. How can we view the balance of a cold wallet storage and keep it cold?


What is the difference between monerod --detach and monerod --non-interactive?

Only --detach will run the daemon in the background. --non-interactive will run in the foreground but the daemon will not require a Terminal for input.
Quoting from monerodocs monerod reference:

--detach

Go to background (decouple from the terminal). This is useful for long-running / server scenarios. Typically, you will also want to manage monerod daemon with systemd or similar. By default monerod runs in a foreground.

--non-interactive

Do not require tty in a foreground mode. Helpful when running in a container. By default monerod runs in a foreground and opens stdin for reading. This breaks containerization because no tty gets assigned and monerod process crashes. You can make it run in a background with --detach but this is inconvenient in a containerized environment because the canonical usage is that the container waits on the main process to exist (forking makes things more complicated).


Synchronizing and p2pstate.bin, GUI wallet

If you are fully synchronized but your block height is not the same as other people, you are not fully synchronized or are connected to bad peers. Check against know block explorers (e.g. xmrchain.net) or remote node operators (like xmr.to).

As repeatedly pointed out, churning in most cases is actually harmful to your privacy. The only exception I'm aware of is churning specific outputs you know you need to disassociate from each other. As for p2pstate.bin, deleting it just means your daemon is going to have to look for peers again, t does not mean you are guaranteed to use new / different peers. I suggest you only delete it if your having sync problems.


If you are sure that your transaction is in the block chain and your monerod is synchronize 100% type the following in the CLI wallet. This will rescan the blockchain to check your own transactions.

rescan_bc

If you are not sure if you are 100% synchronize type the following in monerod

status


What is the format of a block in the Monero Blockchain?

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"
      }]
  }
}


Seeking tool to inspect/study monero cli source code

Seems first answer is a selfish one ;) ... since yesterday I'm evaluating Sourcetrail (https://www.sourcetrail.com) and seems what I was seeking...
I haven't tried it against Monero source code yet, I've just followed the tutorial project introducing its main logic and functions.... but it seems what I'm looking for, so I'm writing about it hoping to help others with my same needs.
Of course I'll still be very happy to listen to other suggestions/experiences as well


You can try applying the help-to-your-door patch:

https://github.com/moneromooo-monero/bitmonero/tree/cache-block-template

It caches block templates, which helps mining pools a lot.


GUI Wallet History Intact but Zero Balance?

Unfortunately the only way to trace what happen to your balance is through command line.

First, check if you are fully synchronized by typing the following command in the monerod.(The black window with many text showing)

  status

The next thing you can do is open the CLI wallet. It's the "monero-wallet-cli.exe"

Try running the following command

  rescan_bc

Also you can use the following command if there are transfers out/in

  show_transfers

Lastly, if all failed try deleting your blockchain(It is in C:\ProgramData\bitmonero) and synchronizing again using the latest monero here https://getmonero.org/home. Remember always backup your seed/keys before doing so.


How are Monero blocks found and confirmed? (solo mining)

It's pretty similar to Bitcoin:

First, a block template is created. This is a block skeleton, which looks like a block but is not actually valid due to not having a PoW hash which matches the current difficulty. This block template includes a coinbase tx to the address you specified, and a Merkle tree of the transations it includes.

Then, a loop will increment a nonce in the block and hash to see if the resulting hash comes within the difficulty limit. If yes, you found a block. If not, you continue. If you've searched the whole nonce space without finding a block and the chain still hasn't moved, you have to change something else (the set of transactions to include, or the block timestamp), then you can repeat over the nonce again.

Once a block is found, it's relayed to other nodes, and you resume mining on top of that new block.

If the chain changes while you're mining, you update according to the rules, ten resuming mining on top of the new chain tip.


Are transactions with multiple real inputs bound to require all the real inputs

The OP workaround does not actually mimic a Bitcoin nLockTime tx, because the second tx (with the actual funds), is not published - it cannot be, the network would reject it. An nLockTime tx is actually published to the network but cannot be mined (included in a block) until the specified time has passed.

The moment a Monero tx is published, it can, and almost certainly will within 2 minutes, be mined. And as soon as it's mined/confirmed on the blockchain, it is final, even if it has an unlock time set (ref this answer). This means the output(s) of that tx cannot be spent (used as inputs) in another tx, until the unlock time has passed.

Therefore, if you set an unlock time on a tx destined for a multisig wallet, the outputs of that tx, which are now owned by the multisig wallet, need to both pass the unlock time and be signed by both wallet participants to be spent. The tx cannot be cancelled and it can only be refunded* (sent back) once it has passed its locked time and signed by all participants.

(*) I say refunded here, but this is actually just a normal, manual, spend. There is presently no such thing as a tx refund address in Monero which would allow a more automated refund.

Pulling this all together, dissecting your question(s):

  The question is are these multiple real input transactions binding?

The moment a valid tx is sent to the network and mined/confirmed, it is binding. The input(s) must have been unlocked and you must have had the signing key(s) for them.

  Meaning I have money in a 2-of-2 multisig account A where I own one of
  the keys and money in account L, where L is locked using
  transaction-unlock-time, and I have a valid transaction using A and L
  as real inputs back to to an output I hold.

You simply cannot have a situation like you have described here. It cannot be both "in a 2-of-2 multisig" wallet (locked or not) and in another wallet (locked or not). The moment you send (publish) the output to the multisig, it has to have been unlocked in your source wallet, and even if you specify it is to be locked when received in the multisig wallet, you cannot do anything with it after in the source wallet (it is now spent, regardless if it is now locked or not).

  If I was a bad actor, could I separate the transaction and just send
  the money from A back to me by separating the transaction? Or is this
  a hard problem?

Given you have defined A as a 2-2 multisig, the only way you can send it back to yourself is by having both the other signer sign this new transaction sending it back to you and the funds not being locked in the multisig. There is no gaming this.


How does input reference the output of some transaction?

The daemon keeps a table of all the transaction outputs in the order where they appear in the blockchain. The offsets in a transaction input allow to quickly recover the indexes of the referenced outputs in this table.

There is no command in the daemon to query the table of outputs directly. But there are some external programs that can be used or modified to make custom blockchain queries. For example, the transactions-export could be a good start.


Does running 2 Monero nodes behind the same LAN help the Monero network?

does it help the Monero network?

Not really. What helps is full nodes and bandwidth, if you have >1 node sharing the same pipe so to speak, you are still offering the same bandwidth, just split between daemons. If the goal is to help as much as possible, make sure you allow lots of peers and as much bandwidth as you can share. See options:
  --out-peers arg (=-1)                 set max number of out peers
  --in-peers arg (=-1)                  set max number of in peers
  --limit-rate-up arg (=2048)           set limit-rate-up [kB/s]
  --limit-rate-down arg (=8192)         set limit-rate-down [kB/s]
  --limit-rate arg (=-1)                set limit-rate [kB/s]
  --public-node                         Allow other users to use the node as a
                                        remote (restricted RPC mode, view-only
                                        commands) and advertise it over P2P

And (as per last option above), consider allowing your daemon to be used as a remote node (so make sure you port forward the RPC port also).


You just need to run a publicly avaiable server (either with a public address, or with a NAT on a router/firewall) with a monerod running on it, that expose ports 18080 & 18081 over the Internet.

Biggest requirement will be the hard drive space to hold the copy of the blockchain.


How to convert monero's curve25519 basepoint to bouncycastle

Monero uses ed25519. The code in the github link you referenced (which I helped write) uses curve25519 instead of ed25519. The reason is that that code was to prototype RTRS RingCT, which relies heavily on variable base scalar multiplication. Curve25519 is higher performance at variable base scalar multiplication than ed25519.

Prior to switching that project to curve25519, I'd already written code that uses an ed25519 library in Java, where the ed25519 library was borrowed from the NEM project. You can see the old commit of the ed25519 Java code here: https://github.com/monero-project/research-lab/commit/46d95551ff1852aa2e13a875b25d817a7f044a1c#diff-4c2f0ce20e9eb6549240e4f58175980a


Why can't Monero use kovri as default for all connections?

This is a copy and paste from an exchange on reddit. Answer looking for improvements and / or editing :)

FP - Not a good idea, then nearly the entire network is at risk of being Sybil attacked. Operating a full node in its entirety on hidden services is something that should be reserved for users in highly adversarial environments who can’t use a remote node for one reason or another.

smooth - It's not because they are more susceptible to isolation attacks. Most users and the network as a whole are best served by connecting to both (their own transactions should only be sent over i2p to prevent any possibility of associating them with an IP address by the above described methods)

Q: i guess I just don't get why connecting via i2p would lead to isolation attack or Sybil. Wouldn't it be the same procedure - hardcode some i2p seed nodes, connect to the seed nodes, get a peer list of i2p-connected peers, and then go from there? Is the problem that making an i2p address is easier than getting more IP addresses?

Smooth: Not only numerically more addresses, but in the case of IP you can take measures to spread out your connections geographically, across ISPs, etc. due to the way IPs are assigned. (I don't think Monero does this now, but Bitcoin does.) With something like i2p or Tor hidden services it is completely opaque and there is no reasonable way to know whether all of the i2p addresses are actually the same attacker.

The other thing is that you do want to make sure there is a robust and attack-resistant interconnection between the i2p and IP networks (one of those papers describes an attack where the attacker arranges for all of the Tor exit nodes to be banned.) How do you do that (other than appointing someone to be responsible for maintaining it, and even then, their specific nodes can be attacked)? The only robust and decentralized way I can think of is to have nodes connect to both by default.

FP: How do the seed nodes know their peers aren’t malicious? The peers could behave well with the seed nodes (which they can trivially identify because it’s hard coded), and misbehave with everyone else.

Q: how is that currently addressed in the existing system?

FP: IPv4 has a cost, and you can make it harder by limiting it to one active peer per C-class, using anchor connections, etc. Here are two resources:

https://arxiv.org/pdf/1410.6079.pdf

https://eprint.iacr.org/2015/263.pdf

The work IPGlider has been doing on Monero is based on that last paper.


RingCT does not create fake outputs. Here is a good dumbed-down explanation of its principle: ELI5: How does RingCT work?

Therefore there is no difference between "normal" transactions and RingCT ones in terms of double-spend prevention: it is handled in the exact same way using key images.


What is novault and what is its connection to Monero?

According to its GitHub description:

  novault is a command-line utility and Python module for generating passwords and cryptocurrency wallets from a combination of a description and a master password. The description and master password are hashed, generating a pseudo-random seed which is then formatted as a password or wallet keys/address.

There is no official connection between Novault and Monero but the first two currencies supported are Bitcoin and Monero. The author accepts donations in Monero and stated in the tools r/monero announcement:

  My main motivation to develop novault started with my use of Monero, but since this is not a purely-Monero tool I opened a subreddit at /r/novault. You are welcome to comment to this post or open new ones in /r/novault.

Since this tool is not an official Monero project a review of its safety is outside of the scope of this Stack Exchange. Having said that at least one Monero core developer, Riccardo Spagni has expressed interest in it. Users can review the source code and make their own conclusion.


If I compile monerod from source, do I also have to compile the GUI to use the GUI?

There are no pre-compiled GUI binaries released yet. When beta is released you will be able to download binaries but for now you need to build them yourself.


Mining Blob
The mining blob is the block header + merkle root + number of TX-es. It's similar to block identifier as 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. The PoW hash is obtained by hashing the blob with CryptoNight, and it doesn't contain 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 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 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?


Does the miner program used affect the hashrate?

Different programs do things differently, some faster, some slower, so yes, which miner you use has an impact on your hash rate on the same hardware. The differences are usually minimal for the main contenders though. AFAIK the Minergate miner is javascript, which is going to be slower than something like Wolf's minerd (at least for the CPU miner, since the GPU one is probably a precompiled kernel).


Explain like I'm 5: How does MoneroDice work?

return on win = (bet amount)(multiplier)

chance of winning = 99/multiplier

(If one rolls more than the chance of winning)
over = (100 - chance of winning)
(If one rolls less than the chance of winning)
under = (100 - over)


How do I build Monero for Windows from source?

Detailed instructions about how to compile Monero on Windows can be found here.
If you are encountering problems compiling the x86 version try this walkthrough.

The x86 version requires specialized x86 dependencies (on Windows).


Running monerod in the cloud on SSD volume, but with a tight limit on IOPS imposed by the provider. Will the PR #1506 help?

Yes, judging from my test results PR#1506 should reduce the IOPS requirement by at least half.


is this how (address new) is supposed to work?

Subaddresses are deterministic, so the "new" command is revealing each next subaddress in the sequence to you.

The wallet is supposed to remember how many subaddresses you've asked to see. If you terminate the wallet process instead of shutting it down gracefully, it may not write this count to disk.

Therefore when you reopened the wallet, it observed the incoming funds at subaddress 3 and then had to assume that you had not issued any further subaddresses since it had not managed to properly store that information previously.


If you have mnemonic seed, does the phrase need to be in order?

Yes, the word order matters. Somebody else can provide the correct math behind this answer, but the short version is that words out of order will have different results.

For example, if I generate this random seed using Luigi1111's generator:

down nurse broken pager phrases owner shuffled titans pavements zapped fungal balding ruffled swagger noodles duties haystack yearbook navy akin woes glass pram punch haystack

it results in this address:

49fvJmi7uRs3gn7PEf1skdLnYueQ2yNFVWpoAFbPudyr1TCQgXV699t5B8yDJKuCzH8chLczzvMR9dWj9Xi8UR2Y1a7Udjk

But if I switch the first two words (placing "nurse" in front of "down") the generator errors:

"Your private key could not be verified, please try again"

Long story short, the word order matters. The one change you can do is shorten each word to its first three letters. So instead of "down nurse broken ..." you could write "dow nur bro ..."

Edit: Good input by Jolly Mort below. The generator errored, not because that mnemonic seed is bad, but because the 25th word in the seed (haystack) is a checksum of the other 24, so it will error if any of the previous words are changed. If the checksum word was recalculated after switching down and nurse, the address would give a legit address, but it would not be the same one as before. So the word order still matters.


What is fungibility and why does it matter?

Fungibility is the property of a good or a commodity whose individual units are capable of mutual substitution. That is, it is the property of essences or goods which are "capable of being substituted in place of one another."
For example, since one ounce of pure gold is equivalent to any other ounce of pure gold, gold is fungible. Other fungible commodities include sweet crude oil, company shares, bonds, other precious metals and currencies. Fungibility refers only to the equivalence of each unit of a commodity with other units of the same commodity. Fungibility does not relate to the exchange of one commodity for another different commodity.
This from https://en.wikipedia.org/wiki/Fungibility also check this: http://www.investopedia.com/terms/f/fungibility.asp
Now, let's compare Bitcoin to Monero: In this case the transaction history is very important. Bitcoin is not fungible because one can always trace where the coins come from (the public ledger is clear for everyone to see). So let's assume that a Bitcoin was used in a shady transaction (drugs, stolen goods, ...). When that coin lands in your wallet, it would be possible to look into the transaction history of that coin and detect that said shady transaction was carried out, so the Bitcoin that landed in your wallet is not equal anymore to a 'fresh' Bitcoin without transaction history. So that Bitcoin is now tainted... Now that Bitcoin/address could be blacklisted so it can't be used anymore.
Monero on the other hand has an opaque blockchain, aka the coins' transaction history can't be looked up, so one XMR will always be one XMR, no matter in which transactions it would have been used before. In a way one could compare it to cash vs digital money. Monero would be cash (untraceable) and Bitcoin would be digital money (traceable), though there are still subtle differences.

No other cryptocurrency that I know of has this property worked out as well as Monero, because Monero is private on the protocol level with the option to be transparent, the other coins are public by default, with the option to be private (Dash, Zcash, ...). In the latter case it means that coins must 'leave' the public blockchain to make them private (via mixing service or other mechanism), this already means that those coins are 'different' (aka not fungible) from the ones that are always on the public blockchain. And those services still don't offer the same level of anonymity that Monero does...

For your last question, could you expand a bit more? I don't quite get the link between physically giving some 'thing' and fungibility.


Mandatory vs optional stealth address use

The big advantage is that enforcing one time addresses at the protocol level will prevent people from forgetting, or not bothering with using them.
In fact, reusing an address in Monero leads to an output becoming unspendable (since two outputs will also have an identical key image).

If the protocol was changed to allow address reuse, it would of course undermine privacy for the parties in that transasction, but it would also undermine privacy for the rest of Monero users in some small way, by making it fractionally easier to make inferences. For instance, if you are trying to work out which if inputs A, B, C, and D is the real input in a transaction, if one of them uses the same address as another input you know is from someone who sold all his monero beforehand (or other arbitrary reason you know they can't have spend an input, as it is irrelevant for the argument), then you can remove that input from consideration. This is similar to how you can remove inputs from consideration if they can be found to be spent with mixin 0 in another transaction, etc.

The main negative of using enforced one time addresses is that it becomes hard to scan for outputs paid to you: you have to process every single output of a transaction with your view key to see if it is yours. This makes SPV wallets difficult, and is generally slow.