How can I use Monero RPC via Python As documented in
https://ww.getmonero.org/resources/developer-guides/daemon-rpc.html
and
https://ww.getmonero.org/resources/developer-guides/wallet-rpc.html,
Monero can be used programmatically using daemon and wallet RPC.

If I wanted to use Python to extract data from the blockchain, for example nonce values over a block range to run statistics on, what is the best way to do it ?

The Monero team recently added a tool that makes it easy to integrate Monero RPC with Python. It can connect to running daemon and wallet and exposes their RPC interfaces:

The following command will connect to a monerod running on mainnet on default settings:

utils/python-rpc/console 18081

You'll get this output:

Variable 'daemon' connected to daemon RPC on 127.0.0.1:18081
>>>

You're now in a python interpreter, and the daemon variable is set to an object which can call daemon RPC directly, eg:

>>> daemon.get_version()
{u'status': u'OK', u'untrusted': False, u'version': 131078}
>>>

For the use case above (retrieving 21 nonce values from the blockchain from height 1000):

>>> [x.nonce for x in daemon.getblockheadersrange(1000, 1020).headers]
[3419004817, 3320605335, 295465941, 3696734864, 2221411748, 2201153093, 148086550, 524920481, 1766174771, 1831485859, 2409397405, 804573540, 535538542, 1487558207, 3340140970, 4029873826, 3890252333, 586366003, 1681558754, 1323530723, 240084243]
>>>

You can also connect the console to several processes, daemon and wallet, so you can interact with both from the same interpreter. The console will detect whether it's connecting to a node or a wallet, and will create the RPC proxy objects as daemon or wallet accordingly. If you connect to more than one demon or more than one wallet, the RPC objects will be daemons and/or wallets arrays instead of single variables. For instance, if you have a wallet running on port 8080:

$ utils/python-rpc/console 18081 8080
Variable 'daemon' connected to daemon RPC on 127.0.0.1:18081
Variable 'wallet' connected to wallet RPC on 127.0.0.1:8080
>>>

The console tool accepts full URLs if the daemon/wallet does not run on 127.0.0.1.

To use that framework in other Python programs, you should import the module(s) you need:

from framework.daemon import Daemon
from framework.wallet import Wallet


Why did Monero start with an enforced mxin of 2 then plans to hardfork to enforced mixin of 4 later? Are there any perks to doing it like this? Why not just start off with enforcing mixin of 4 at the beginning?

One of the reasons (maybe the only one, even) could be that without RCT, a transaction's size would grow significantly when mixin is increased, because any non-round amount needs to be split into many denominated outputs and each of those is 'mixin-ed'.

Even though the default is 4, I believe that many exhanges and pools - who do a lot of transactions - would prefer using the 2, until RCT is enabled.

With RCT, we get a one-time bump in TX size, but we can increase the mixin more cheaply because there will usually be just 1 or 2 outputs as we don't have to split into denominations anymore.


What's the tip for protecting your laptop from damaging during mining? I know using low-end hardware like laptop isn't a good idea, but I still want to know what mining condition could damage my laptop and how can I prevent it.

Things I've heard

Break every hour

In my memory, I've heard someone said let your laptop take a break every hour of mining.

Let your CPU cool

Flip your laptop to cool down your CPU better if your laptop's vent are pointing downward.

Plug in the power

Someone said, plugging power in modern laptops make it run faster.

What's right and what's wrong? I'm not pretty sure if every method is good for my laptop, who can point mt out?

None of the mentioned points is really correct.

1) Break every hour

I don't see how that could help in any way, really.

2) Let your CPU cool

Your CPU should not get to hot but letting the CPU cool down and then start again isn't the answer. The real answer is, don't let it run all the time on 100%. If you are mining you have to set the number of threads. The more threads the more your CPU is occupied. If you worry that your CPU might get to hot then don't use the maximum threads possible.

3) Plug in the power

That one is actually kind of correct. If you mine with your laptop then it can be that your laptop is set up so that it will not use the full processing power if not plugged in. If that's the case, then you have two possibilities. 1) Plug in the power 2) Change the OS setting so that it will use full processing power. Also, the real threat here is, that your battery might break faster if you constantly running on full power without being connected to power


How long do I need to mine until I see some coins in my wallet? I just started mining today and I set up my Address in the miner but I'm unsure if I did everything right and I'm mining "into" my wallet.

Mining with Claymore on I4700MQ with 6MB Cache on -t3 settings.

160 h/s

cryptomonero.com:1001

Wallet at MyMonero

Its a Notebook CPU but i got heat under control.
Once I know that my miner is set up correctly I will probably switch hardware.
It doesnt matter how much I receive, i just need some verfication.

Follow up question: Do I have to let my miner run through "in one session" until i've hit a threshhold or can I interrupt it and continue later without losing my progress which was under the threshold?

The reason you haven't seen a payout is because most pools have a threshold level below which they won't bother sending xmr to you.

Your share per tick is: 160 H/s / 50.53e^6 H/s, with a network rate of 50 megahash per sec, right now.  The previous mining reward was 9.2481 and a tick happens every 2 minutes.

With a threshold of 0.1 XMR we get:

0.1 XMR / [(160 H/s / 50.53e^6 H/s) * 9.2 XMR / tick * 0.5 tick / min] / 1440 min / day = 4.77 days

In other words, if the pool has a threshold of 0.1 XMR before paying out you can expect to mine for almost two days without seeing any returns.  On top of that comes any variance.  Some small pools might not find a block the day you're due for a reward, which would cause an additional day in delays.

Follow up answer: No, you can interrupt, and come back to it later. Your balance shows the amount already won. Every time your balance changes, it's your fair share of the block reward, which the pool holds for you until you cross the payout treshold.

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.


What is to stop mymonero.com from taking everyone's money? I'm concerned about storing my funds on this website. How can I know they are safe?

The fact that it never gets access to the your private spend key. The workings of the site are explained here.

Your monero are "kept" on the blockchain and not on the site itself. The site is just an interface to tell the network you want to move your monero, where all the cryptography to spend the coins (using your private spend key to sign the transaction) is performed by your computer. By logging-in, you're giving the program (javascript code running locally on your browser) your secret spend key so it can do its magic.

However, it's important to note that the site does store one piece of information: your private view key. Because of this, the site can see all your incoming transaction and provide you with the convenience of having your balance visible immediately.

Possible attack vectors include:

A hacker spoofing the site somehow, so you would load a different "program" (code running in your browser) which would steal your keys after you type in the mnemonic.

You could protect against this by always checking the correct site address and https certificate.

A hacker hacking the site server, changing the program delivered to the users and being able to steal the keys of whomever logs in after that point

You could protect against this by inspecting the code of the site. Let's say you make a snapshot of the site, and copare the newly downloaded one vs the old one. Not very practical to do, though.

Site owner going rogue and doing the same
Key logger on your PC
Browser extension malware

You could protect against this by disabling all addons/extensions
...

The important takeaways are:

If you have used the site in the past, and someone hacks it afterwards or the owner goes rogue, they won't be able to steal your funds.
Due to how it works, even if someone hacks the site, he would be able to steal only the funds of those who log in during the time the site is hacked
If the owner would go rogue, the word would soon go out. Highly unlikely considering the massive credibility of the current owner (one of core team).
Considering all above, it's recommended to keep larger amouts using simplewallet or cold storage. The site should be used for pocket money, like what you would normally keep in your physical wallet.


Any plans to have a Monero convention? Bitcoin and Ethereum seem to have meetups/convention every now an then, are there any plans to do this with monero?

Silicon Valley Monero meetup just announced:

https://www.reddit.com/r/Monero/comments/5h9zo0/silicon_valley_monero_meetup/


How do you store seed phrases for multiple wallets? Let's say you have not just a hardware wallet but multiple software wallets. How do you store your seed phrases? Steel plates are a good solution but often a headache to stamp and store.
Has anyone figured out an easier, more effective solution? Paper wallets are great but then you run the risk of losing it all in a fire.

Paper wallets are great but then you run the risk of losing it all in a fire.

Storing photocopies in more than one geographic location mitigates that risk significantly.
An alternative digital solution is to store all your seeds in a single text file encrypted and uploaded to multiple online locations. That way you just have to remember one password to decrypt your text file with all your seeds.
You could even use one of the many single/one password tools / services.
In my opinion, digital (so encrypted backups), hands down beats any paper / physical versions.


Automate mining on windows I am running mining on Windows 10 Pro in Microsoft Azure using MSYS2 MinGW 64-bit.

My process to mine currently is:

OPEN a MSYS2 terminal (lets call this MSYS2 A), navigate to appropriate directory and run ./monerod --offline
OPEN another terminal of MSYS2 (lets call this MSYS2 B), navigate to appropriate directory and run ./monero-wallet-cli. Follow the instructions for loading a wallet. Enter start_mining [thread count]
Go back MSYS2 A, and run show_hr

My question:
Is there any way to automate the process of starting mining in MSYS2 windows e.g. something equivalent of having a .bat file in a CMD window in a start menu.

Bonus question: Is there any way to be alerted if mining fails and to automatically restart the service?

MSYS2 is needed to build on windows.
However, you can mine directly within the regular windows command line, that's what i am doing.
So you might be able to create a bat file to:

Launch monerod
Start mining to your address within monerod, or in another window with monero-wallet-cli.

Try something like:

cd <path/to/monerod/folder>
:loop
monerod.exe --start-mining <address> --mining-threads <threads>
goto loop

For more sophisticated stuffs, try using "expect" to start "show_hr".


How do I allow incoming connections to my node running on Tor? I have a node running on a Pine64, and allow incoming connections to it by forwarding port 18080 on my router. Checking status on it would show 8(out)+x(in) connections, with x usually hanging around 30 or so.

Until Kovri is ready, I thought I would try running the node on Tor, and so followed the instructions at https://github.com/monero-project/monero#using-tor to run using torsocks, and seems to be working. However, I now always get 8(out)+0(in) connections. I'm guessing that is happening because incoming connections are using a different ip address that is not forwarded on my router. Any suggestions as to how to allow incoming, or is this the price you pay for using Tor?

Monero does not have an hidden service as Bitcoin does. This would be needed in order for an external client to connect via Tor. Allowing clients to connect via clearnet would need code changes in Monero so outgoing connections could be made via Tor, while listening for incoming connections could be made normally. Alternatively, allowing proxy connections should also work. None of these things are done in monerod.


What exactly is a coin? maybe this is a stupid question but hey, posting will hurt nobody so I'll give it a shot. :)

I'm wondering, what exactly a Monero is, speaking data wise. According to the Bitcoin Whitepaper, a Bitcoin is "a chain of digital signatures" and I think I get what that means and having read the Cryptonode Whitepaper, this hasn't fundamentally been changed in Monero.

What I'm wondering is: What exactly is created when a new block is found and the Moneros as reward are given out to the lucky miner? Is it just a series of bytes which propably can be represented as a string? And if so, how is the nominal amount (e.g. 25 Monero) attached to that string and how is it possible to only spend a fraction of those Monero?

Or to put it another way: What exactly is a satoshi or the atomic unit of Monero made up from?

I know those questions are propably not easy to answer and have been answered before, but I just couldnt find a satisfying answer.

Thanks a lot to anyone who is willing to shed some
light on those questions! :)

I'm wondering, what exactly a Monero is, speaking data wise. According to the Bitcoin Whitepaper, a Bitcoin is "a chain of digital signatures" and I think I get what that means and having read the Cryptonode Whitepaper, this hasn't fundamentally been changed in Monero.

That's right. It's the same. But in Bitcoin, one signature is checked against one public key, and in Monero it's checked against arbitrarily many keys (ring signature), thus hiding the private key used to create the signature and authorize the movement.

  What I'm wondering is: What exactly is created when a new block is found and the Moneros as reward are given out to the lucky miner? Is it just a series of bytes which propably can be represented as a string? And if so, how is the nominal amount (e.g. 25 Monero) attached to that string and how is it possible to only spend a fraction of those Monero?

A brand-new cryptographic key is created together with an associated amount matching the emission formula. That's it. Since the amount is stored as a 64-bit number, we can represent numbers from 0 to 2^64 - 1. The atomic unit is literally 1 bit. We arbitrarily pick where the decimal point will be and call that a Monero :) That's why it can be divided, because we've left enough digits after the decimal point. Fundamentally, it's really 64-bit integer math.

  Or to put it another way: What exactly is a satoshi or the atomic unit of Monero made up from?

Bits :)


Constructing a Stealth Monero Address? Is it possible from Section 4. Address Serialization cns007.txt and Section 3. Variable-Length Encoding of Integers cns003.txt to compute a Monero Stealth Address from the following?

1) Private Spend Key:
198584347013dd91832be3d82529437db7cc8e1850e559cdd3872b29ca819601

2) Private View Key is computed from a 256-bit Keccak hash:

% keccak  -256 198584347013dd91832be3d82529437db7cc8e1850e559cdd3872b29ca819601
889DA12A88D36BCE0966AB1A79125779DD1F2FC6F1145DE131FD52A5B468796D

3) Edwards 25519 Public Key corresponding to the Private Spend Key:

% ed25519 198584347013dd91832be3d82529437db7cc8e1850e559cdd3872b29ca819601
c2b898f1c5136fe21aeff926655563a0868e23647798e3f33691e94ef7de0b64

4) Edwards 25519 Public Key corrresponding to the Private View Key:

% ed25519 889DA12A88D36BCE0966AB1A79125779DD1F2FC6F1145DE131FD52A5B468796D
0a2ada1dc29cb84280376970a3c703d5a3a148f83db5aaed44a1fa33de59bdde

If so, how can the information above be used to construct a Monero Stealth address?

In Monero, coins are received to a unique, one-time stealth address. The formula for stealth addresses is as follows:

P = Hs(rA)G + B

Where:

P -- the final stealth address (one-time output key, the destination where funds will actually be sent);
Hs* -- a hashing algorithm that returns a scalar (i.e., the hash output is interpreted as an integer and reduced modulo l);
r -- the new random scalar Alice chose for this transaction;
A -- Bob's public view key;
G -- the standard Ed25519 base point;
B -- Bob's public spend key.

You provided us with the private view key (a) and private spend key (b), and the public view key (A) and public spend key (B). In addition, we have the base point (G). It should be noted that you forgot to reduce modulo l your private view key. Your correct private view key (a) is:

faa5defce980fdbd03b9dd4841371dfcdc1f2fc6f1145de131fd52a5b468790d

This gives the correct public view key (A), which is:

3c450f27cd6849d9130addb2c566d910c5ef9bf4cecaed547004496fda52a4ff

I don't know what you used to get to your public spend key (B), but it returns differently for me, namely:

b66991d7d7c68513533d0560f820d75adfb0911487ba62274b759f7b3ccd4a90

For what it's worth, the curve constants from the CryptoNote whitepaper can be seen here. Note that for a dual-key stealth address to be created, the sender (Alice) does ECDH (Elliptic curve Diffie–Hellman) with her randomly-chosen r (private tx key) and the receiver's (Bob) public view key, A. This is point D (D = rA), which is a shared, secret point known only to Alice and Bob (D = D'). Thus, no one other than Alice or Bob is able to compute D. Second, Alice uses D to generate a new scalar, f, with f = Hs(D). Third, Alice computes F = fG. Lastly, Alice computes P = F + B (Bob's public spend key). Note that F is equal to Hs(rA)G in the formula above.

Back to your question. You first have to generate a random r, which can be done as follows in the Chrome console using Javascript on this page. Since you already generated a random private spend key, we only have to generate a random r. This can be done by using random_scalar();. Using this I get:

9f558def5f918481f3c130d4cbea908f0cef9aedc5f5b259bb18b3b9ea4e5b0e

The public tx key (R) is then:

11f63287b184708fd40618154a19afa35e2366ef22417223e8feac1639b68ace

For what it is worth, the public address is:

48Y3H2eSZ6C4EUjY1B5viSGCbCLPcmMiy7aD69yqUsaHR8GLE3rvSwrdJtpZYG1peC3oipCqfUvCcF89i86kuEjVVr5GCdj

Thus, to summarize, our "start" variables are:

var b = "198584347013dd91832be3d82529437db7cc8e1850e559cdd3872b29ca819601"; |  Your private spend key
var a = hash_to_scalar(b); | Your private view key (deterministic derivation) | a = "faa5defce980fdbd03b9dd4841371dfcdc1f2fc6f1145de131fd52a5b468790d"
var B = sec_key_to_pub(b); | Your public spend key, this function multiplies base G by its input | B = "b66991d7d7c68513533d0560f820d75adfb0911487ba62274b759f7b3ccd4a90"
var A = sec_key_to_pub(a); | Your public view key | A = "3c450f27cd6849d9130addb2c566d910c5ef9bf4cecaed547004496fda52a4ff"
pubkeys_to_string(B,A); | This will return your public address | Public Address = "48Y3H2eSZ6C4EUjY1B5viSGCbCLPcmMiy7aD69yqUsaHR8GLE3rvSwrdJtpZYG1peC3oipCqfUvCcF89i86kuEjVVr5GCdj"
var r = "9f558def5f918481f3c130d4cbea908f0cef9aedc5f5b259bb18b3b9ea4e5b0e"; | private tx key
var R = sec_key_to_pub(r); | Public tx key | R = "11f63287b184708fd40618154a19afa35e2366ef22417223e8feac1639b68ace"

Now let's create a stealth address! This is done as follows:

var D = generate_key_derivation(A, r); | ECDH, rA | D = "b2896554aa33603868b4c5d106f4873620aabb96d22bc236192f1bcfa38451bb"
var f = derivation_to_scalar(D, 0); | 0 is the output index. The standard method combines these last few steps into one, but for clarity they are split here | f = "236b65c107cf838db70d41f5e795e526e2043f471d2b2daefa24fb4b22f0340c"
var F = sec_key_to_pub(f); | F = "2dd26c9941f5fe2aeeab30d2ebc41dd21241cb4d4327c27588bde076a0e893f4"
var P = ge_add(F,B); | "ge" means group element. This function adds two points together. Note that F is Hs(rA)G | P = "b696760c160efa648d681a7a65cdee3c5f0c23d3866c08c90473021d7892f1a3"

P (b696760c160efa648d681a7a65cdee3c5f0c23d3866c08c90473021d7892f1a3) is a valid stealth address. An image of the aforementioned steps performed in the browser console on https://xmr.llcoins.net can be seen here.

Note, however, that in Monero the stealth addresses are created by the sender and not by the receiver. Thus, those last four steps are performed by the sender (Alice) in Monero.

Sources:

https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-introduction

https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-part-2-stealth-addresses


Monerod synchronization problems Monero noob here, my friend basicly did everything when he made me a wallet and stuff.

I had version "0.9-4-0", but it just froze and looked for blockchain. So i read some tips online, and downloaded "10.3.1" and deleted the c:bitmonero file.

Now i get this error:

Error: refresh failed: refresh error: block parse error.

Any guides or tips? Please go easy on me!

When ugrading from 0.9.x to 0.10.x it's highly recommended to delete the database and re-sync from scratch. You almost got it, but the default location of the database is in the c:\programdata\bitmonero directory not c:\bitmonero. Instructions below.

Make sure that monerod isn't running. Go to %programdata% and delete the "bitmonero" folder in that directory. Then try re-launching either monerod and use monero-wallet-cli if you prefer the CLI or launch monero-wallet-gui if you are a GUI user.

It'll take approximately an hour on a fast computer w/ SSD to download the entire blockchain, longer for a regular HDD, slow network, slower computer.


If you send two transactions to the same one-time address, will they both be accepted by the blockchain? A one time address is supposed to be, well, used only once.

If you send two transactions to the same one time address, will both transactions be accepted into the block chain? I know that if they were, only one would be spendable.

First, to clarify again, the question is about one-time addresses, i.e. stealth addresses, which are different than the public addresses. The public addresses can be reused freely, whereas the stealth addresses cannot. For consistency, I'll only use the term stealth address (one-time address) in this answer.
To answer your question, we first need a bit of background. In Monero, key images prevent double spending in the blockchain. Key images are generated by the receiver (Bob) of a transaction, to see if the outputs that belong to him are spendable. Or to put differently, if they aren't already spent. The receiver wants to verify this, because he will most likely want to spend his funds somewhere in the future. From core-team member luigi1111's article:

To check if P is spent, Bob computes its "key image" and queries the blockchain to see if it is marked as spent. Key image I = xHp(P).

Note that P is Bob's stealth address, with P = Hs(rA)G + B.
Where:

P -- the final stealth address (one-time output key, the destination where funds will actually be sent);
Hs* -- a hashing algorithm that returns a scalar (i.e., the hash output is interpreted as an integer and reduced modulo l);
r -- the new random scalar Alice chose for this transaction;
A -- Bob's public view key;
G -- the standard Ed25519 base point;
B -- Bob's public spend key.

From the formulas we can infer that, if the sender (Alice) uses the same stealth address of the receiver (Bob) for two transactions, Bob's outputs of one of the transactions will be burned. That is, both transactions will generate the same key image for Bob. Therefore, only Bob's outputs of one of the transactions are subsequently spendable. Now back to your question, given that stealth addresses are randomly generated, is it highly unlikely that Alice received the funds she has subsequently sent to Bob on a reused stealth address as well. Therefore, the key images generated by Alice are unique and she would be able to send two different transactions to the same stealth address of Bob, which thus will both be accepted into the blockchain.
I previously mentioned that stealth addresses are randomly generated and therefore should not be able to collide, or put differently, reused. One may ask themselves, how would a stealth address appear twice? To answer this, I'll use the comment of reddit user TheKing01:

Technically, stealth address reuse is already possible if you're dumb. A sender can use a one time address more than once if they aren't careful. (It does help though that it is happening all inside simplewallet, so their is no chance for human error in this regard. Either using third party buggy clients or using a bad random number generator could be a problem though).
There is a good way to prevent this type of failure though; simply check if the one time address you are using is already on the block chain (this can be done automatically). If it is, you know there is a problem.


how to run monerod as service on ubuntu 16.04 I've installed monerod on remote ubuntu machine, but can't start as daemon.
systemd service keeps failing.
tried to run with --detach with no luck.

systemd[1]: Starting Monero Full Node...
systemd[1]: monerod.service: Control process exited, code=exited status=203
systemd[1]: Failed to start Monero Full Node.
systemd[1]: monerod.service: Unit entered failed state.
systemd[1]: monerod.service: Failed with result 'exit-code'.

can anybody share experience with running monerod as systemd service?


Is there preferred hardware on which to run simplewallet to ensure random wallet generation? Would a Monero wallet generated with simplewallet on a Raspberry Pi be as secure as one generated on an Intel-based Mac or PC? How can one determine whether one's random number generator is good enough?

The Trezor built on a 32-bit ARM Cortex has a true Random Number Generator (RNG).

Having analog-to-digital (A/D) converter making very small voltage measurements can assure randomness.  Most electrical engineers are very familiar with the "thermal noise floor" that in a statistical sense is governed by K*T*B*NF physics equation. K = Boltzman's Constant, T = Temperature in Kelvin, B = Bandwidth in Hertz, NF = Noise Figure of amplifier feeding the A/D converter(s).


MyMonero Import fee - payment from import? I know that there is a fee to use MyMonero to import monero to a mymonero wallet.

My question is this - is the fee deducted from the imported monero, before it is lodged in the mymonero wallet, or do i need to pay with monero before the import occurs - so effectively I need to have monero to pay the import cost before it allows the import?

Thanks,

It's not a fee for importing moneros. It's a fee for importing your address's transaction history. A wallet cannot import moneros because moneros are not stored in wallets. They're stored at addresses on the blockchain.

Your address could have a history associated with it, if someone has previously sent moneros to it, or if you you have previously used some other wallet software to spend moneros from it. If you pay the fee, MyMonero will trawl through a copy of the blockchain (kept on a mymonero.com server) and figure out your transaction history.


Mining pools overseas and the impact on the hashrate I am located in USA but I am mining using a pool in France. The question is, because the pool is overseas does it impact my hashrate ?

I noticed a week ago I was about 1.8-2 KH/s and now I have a miserable 1.3KH/s.

Many thanks!

I'm not sure what miner you are using, but if you're using XMR-Stak, one of the better ones at the moment, you can click 'r' to get a report on your submitted work. If you have a low acceptance rate, you are losing your work.

Here's an example from one of my own workers that runs through an SSH tunnel (which adds latency).

RESULT REPORT
Difficulty       : 18000
Good results     : 9233 / 9284 (99.5 %)
Avg result time  : 105.2 sec
Pool-side hashes : 45846000

Top 10 best results found:
|  0 |         62213495 |  1 |         54395912 |
|  2 |         28981579 |  3 |         28899680 |
|  4 |         28802304 |  5 |         26687670 |
|  6 |         23322195 |  7 |         16208637 |
|  8 |         15118120 |  9 |         13861144 |

Error details:
| Count | Error text                       | Last seen           |
|     9 | Low difficulty share             | 2017-06-19 15:55:14 |
|    11 | [NETWORK ERROR]                  | 2017-06-18 15:01:07 |
|    31 | Block expired                    | 2017-06-21 07:07:45 |

As you can see, my "good rate" is 99.5%. This is on a slow CPU which also does a lot of other work and often has CPU power taken away for other tasks.

I've noticed that the hashrate reported by the pools vary a fair bit, so I'm not sure they can be trusted. I calculate my own hashrate by polling the pool API and averaging over 1 hour. I can then compare that to the sum of rates reported by each worker. ('h' key in XMR-Stak.)


How to pronounce Monero correctly I would like know how to pronounce monero correctly so when I talk about it, I can give people the right information.

Thanks,

Given that Monero comes from Esperanto, it'd probably be best to use Esperanto's pronunciation. As u/Bagatell_ pointed out on Reddit, you can use Google Translate for this:

  https://translate.google.com/#eo/en/monero has audio

Other suggested pronunciations can be found here:

https://www.reddit.com/r/Monero/comments/5kska9/how_is_monero_pronounced/


Is there a library similar to bitcore? Is there a library like insight / bitcoin that interacts with Monero to create an API to scan the blockchain?

You'll find some examples over at https://github.com/moneroexamples

However, Monero's blockchain does not offer as much information like Bitcoin's blockchain and you will fail to query balances of specific addresses or transaction details unless you have access to the private keys.


Implications and remedies of fixed 'H' in Pedersen commitment In the monero document "Zero to Monero" pp. 30 the Pedersen Commitment scheme is described as requiring generators G, H such that no-one knows an x where G = x*H. The actual H is defined as H=to_point(Keccak(G)) where to_point is a function mapping scalars to elliptic curve points. Gregory Maxwell describes this function in more detail:

  ... Where to_point() takes the input as the x value of a new point, checks that its on the curve and solves for the y value. ...

Rather than simply multiplying by G, somewhat breaking the scheme.

However, if someone was to figure out the x above doesen't this become a single, centralized point-of-failure for the entire currency? Meaning that by breaking this single, 128-bit secure key, absolutely all monero transactions - future and past - could be decoded w.r.t. the amounts sent? As a follow up: would it be possible for the sender to pick a fresh H for every transaction?

The commitment is actually xG + aH where both G and H are pre-defined generators. The
hardness of the discrete logarithm problem ensures calculating a from H (or x from G) is infeasible. Put another way, both G and H are points, and because of ECC point multiplication, you can't deduce x or a.

Further, you'll see described in Maxwell's Confidential Transactions paper:

The Pedersen commitment is created by picking an additional generator
for the group (which we'll call H) such that no one knows the discrete
log for H with respect to G (or vice versa), meaning no one knows an
x such that xG = H. We can accomplish this by using the cryptographic
hash of G to pick H:

    H = to_point(SHA256(ENCODE(G)))

Which is precisely how H is constructed in Monero: H = Hp(G), which is H = to_point(Keccak(G)).

Further:

  However, if someone was to figure out the x above doesen't this become a single, centralized point-of-failure for the entire currency?

No. x is a binding factor in a single commitment. A centralized point of failure would be if someone knew the discrete log for H with respect to G (or vice versa). If one miraculously calculated an x in one commitment, this wouldn't compromise other commitments. Think about it like this: just because you know your x for a commitment, doesn't mean you can work out other x's.

Also:

  As a follow up: would it be possible for the sender to pick a fresh H for every transaction?

That's essentially what happens because of the point multiplication using a. E.g. aH.


How do I start using Monero with the command line tools? If you need to use the Monero command line tools, how do I get started with Monero?

When you’re on Linux or macOS, I usually put the Monero software in the /opt directory. That’s where “optional” software typically goes outside of the OS packaging system. I also try to plan ahead and keep multiple versions.

E.g. on macOS, for the Wolfram Warptangent release, I created a subdirectory like this:

$ cd /opt
$ sudo mkdir monero.mac.x64.v0-10-0-0
$ cd monero.mac.x64.v0-10-0-0
$ sudo tar -jxvf /Users/Nicolas/Downloads/monero.mac.x64.v0-10-0-0.tar.bz2
x ./monero-blockchain-export
x ./monero-blockchain-import
x ./monero-wallet-cli
x ./monerod

Then I make a symbolic link to the “current” release:

$ cd ..
$ sudo ln -s monero.mac.x64.v0-10-0-0 monero
$ ls -lrd monero*
drwxr-xr-x  10 root  wheel  340 Aug 31 22:21 monero.mac.x64.v0-9-4-0
drwxr-xr-x   6 root  wheel  204 Nov  6 13:02 monero.mac.x64.v0-10-0-0
lrwxr-xr-x   1 root  wheel   24 Nov  6 13:03 monero -> monero.mac.x64.v0-10-0-0

As you can see, I did the same for the 0.9.4 release. It allows to easily switch to an older release (by removing the monero symbolic link, and recreating it to another target directory), in case you need to test something with an older wallet.

At the user level, from my home directory, I just added the following to my .profile file:

# Monero
PATH="${PATH}:/opt/monero"

Then, from a new terminal (or after re-login), you can just call the binaries without ./ in front of it.

$ which monero-wallet-cli
/opt/monero/monero-wallet-cli
$ monero-wallet-cli --help
…


How can Monero defend against a "majority of view keys" attack? My question is a follow-up on a recent thread on Reddit:

  In this talk! a question was asked how many of view keys are needed to
  see through the whole blockchain and deanonymize all the transaction.
  Riccardo Spagni answered around 80%, which is a lot and an entity like
  IRS would not be able to get that many keys from actual users. But
  what about generating millions of accounts every hour to keep having
  80% of all view keys in the network? These generated and otherwise
  unused accounts would be used for transaction input mixing, right?
  This entity could then filter the inputs for transactions of interest
  by the outputs of its own accounts, which definitely were not the
  original spender. What do I not understand here? Or is it a valid type
  of attack but infeasible with large amount of account?

There are 3 aspects I would like to see answered:

How likely is such an attack? Is it merely theoretical?
Is there way to detect such an attack?
Would increasing the ringsize help? Or would that just gain time?

Let's start with the original question, which is making some false assumptions.

  Riccardo Spagni answered around 80%, which is a lot and an entity like IRS would not be able to get that many keys from actual users.

It's important to clarify 80% of what exactly, as we'll see below.

  But what about generating millions of accounts every hour to keep having 80% of all view keys in the network?

Doesn't matter. "Accounts" don't really exist. There's nothing written to the blockchain once you create an "account". Only when you actually receive your first funds, there are some outputs which are controlled by some wallet and which could be used for the mentioned attack.

  These generated and otherwise unused accounts would be used for transaction input mixing, right?

Not right. Until you actually receive some funds, there's nothing "yours" on the blockchain to "mix" with.

  There are 3 aspects I would like to see answered:

First, we must understand how the attack is supposed to work. Currently, by default, ring signatures are constructed with a ring size of 5 (1 of the signer + 4 other). This means that for any 1 input, there are 5 possible sources, ie 5 possible one-time keys (aka "outputs"). If someone recognizes all those 4 other one-time keys which your wallet picked as his, then to him it will be clear that the remaining 1 is the real one getting consumed.

Obviously, we get 80% based on that. So, if we increase ring size to 10, then the attacker would need 90% and so on. Remember, we're talking about one-time keys. Every Monero transaction generates those as destination and Monero are never sent to the address itself. Each Monero trasaction consumes some existing one-time key and generates a brand new one for the destination. The address is like a blueprint to create those, and the viewkey is a template used to recognize them as belonging to your wallet.

So, an attacker could own just 1 view key, but 80% of the one-time keys used for the input to be able to tell which one is the real one getting consumed. It still wouldn't reveal the owner just like that, but would only trace the funds 1 step back to some other one-time key. If you don't own 80% for the transaction which created that one, it's a dead end and you cant trace back further.

Since your wallet picks those other outputs randomly, an attacker can't plant them in advance. He must instead keep generating 80% of the outputs on the blockchain to uniformly cover 80% everywhere, so whatever your wallet would pick there would be a good chance of picking those that belong to the attacker. Remember, other people are transacting at the same time. So an attacker needs to beat the entire user-base of Monero. For every 1 legitimate output, he must make 4 others. He must pay the fee for it, too! Can you imagine the cost of sustaining such an attack?

We can now answer the 3 points

  How likely is such an attack? Is it merely theoretical?

Higly unlikely, as explained above.

However the above is not the full story, as there are other ways to recognize outputs as belonging to some address. You could steal people's view keys which would give you an edge without having to make the transactions yourself. You could coerce mymonero-type services (which keeps user viewkeys) to give up all user accounts, and then all of their outputs would then help you as well. So a situation where 80% of transaction volume originates from mymonero users would be a real danger.

  Is there way to detect such an attack?

I guess not really, since we can't ever tell 2 outputs apart. We can't know if some TX is legitimate or if it's been made with the purpose of generating noise. However, the cost of such attack is a good deterrant.

  Would increasing the ringsize help? Or would that just gain time?

It would help, yes. And time is really gained just by transacting normally - any legitimate transaction increases the cumulative cost for the attacker so he must try hard to keep up.


private spend key versus mnemonic seed What is the difference between a private spend key and mnemonic seed?

Can both be used to sign a transaction? Are there any things that I can derive from one but not the other?

Thanks to deterministic key derivation, the private spend key is an alternate representation of the mnemonic seed. Both the mnemonic seed and private spend key can be used to derive all other keys

The private spend key is used to sign Monero transactions.

Simplewallet mnemonics seed are comprised of 25 words with the last word being used as a checksum. Those words correspond to a 256-bit integer, which is the account's private spend key. With simplewallet the spendkey is the mnemonic seed The private view key is derived by hashing the private spend key with Keccak-256, producing a second 256-bit integer. The corresponding public keys are then derived from the private keys.

MyMonero works in a similar manner but with 13 word mnemonic seeds with the last word being the checksum The 13 words correspond to a 128-bit integer that is used for both spend and view key derivation. With MyMonero the spendkey is the hashed mnemonic seed

Deterministic wallets make wallet recovery and key derivation easy. It is worth noting that you cannot derive the view key from the private key for non deterministic wallets.


Bunch of errors when running monerod. ERROR cn src/cryptonote_core Is this normal during syncing? I just downloaded .11 and ran monerod on ubuntu.

2017-09-18 19:28:28.513 [P2P0]  ERROR   cn  src/cryptonote_core/cryptonote_core.cpp:662 Exception at [core::handle_incoming_txs()], what=Error finding txpool tx meta: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid

This is a secondary error which happens after a DB error. The DB may or may not be corrupted. The recovery steps, in increasing order of violence:

restart monerod
restart monerod adding --db-salvage
remove the ~/.bitmonero/lmdb directory


Would It Be Technically Possible To Delete Old Blocks From A Blockchain? From what I understand, a cryptocurrency mine needs to store a copy of the entire blockchain in order to be able verify transactions, which is why most wallet owners are not miners. The more centralized a decentralized consensus is, the more likely it is that its participants will 'defect' and screw over other participants, as in 51% attacks. And since these mines are physical locations, they will be able to be blackmailed by defenders of the legacy fiat monetary system. Therefore, the goal should be to create a cryptocurrency that is radically decentralized. It should be mined on every smartphone, maybe even on every internet browser while the CPU capacity is not used. And this requires the blockchain to be radically small, small enough to fit on a few GB of flash memory, and with the potential to stay that small if there are millions of transactions per day due to worldwide adoption.
That's why one solution seems to be to simply not store transactions forever but delete old blocks.
[Q] Much like this Reddit user suggests, would it be technically feasible to delete old blocks from a blockchain in order to keep the data storage requirement for becoming a miner small? A cryptocurrency could, for instance, only keep the last year of transactions, and everything older gets deleted. The discussion seems to imply that this is technically possible, but maybe not desirable because funds are lost if they are not retransferred within the time window. So my question is: does a blockchain need to have all blocks down to the genesis block to verify transactions, or can it's participants agree to just use the oldest blocks available?
Private blockchains like Monero can't be pruned based on what coins are spendable, because that data is not available and every coin is potentially spendable. So it would just grow forever until mining becomes centralized in a few data centers. And that makes it vulnerable to attack. In order to stay honest, a blockchain needs to be radically decentralized. Then hash wars would not be a weapons race between the super computers of fraudulent actors and the super computers of honest participants, but between the super computers of fraudulent actors and the combined computing power of the entire world. Mining should be on by default in every wallet, and every browser should mine (for you) while you're not using the CPU power for something else! (It does not have to waste energy, the mining could only be applied when there is a dispute, but it has to be available in case there is a dispute.) But for this to happen, these devices have to be full nodes. In other words the entire blockchain can only be a few dozen GB or so.
I'm thinking maybe this blockchain would only be for short-term transactions, and people would not have large amounts of money on it. The spending blockchain with only a year of storage could be really small and fast, while the long-term blockchain that stores things forever would not have that many transactions because people only transfer large sums now and them. It's doesn't have to be all in the same cryptocurrency/chain. Specialize it! People usually have their pension funds on the same bank account as their beer money either. So when you go to prison and can't renew your wallet, only a relatively small amount of money is lost. Or automatic devices could be built that retransfer your holdings before the time limit.) Or would that lead to loss of value in one of these currencies?

You've formed an opinion and make a lot of statements based on inaccurate information.

"to store a copy of the entire blockchain" – Miners do not need to have a copy of the blockchain. They only need to have access to the network. This is because miners don't need to verify transactions, that's the job of the network (everyone who runs a node). A miners job is to propose new blocks.
"Private blockchains like Monero can't be pruned" – Yes they can and Monero has this exact feature.
"So it would just grow forever until mining becomes centralized in a few data centers" – You make the common mistake of ignoring the advances in storage capacity and decreasing cost.

Therefore the question of whether it's possible to delete old blocks becomes a moot point.


Does the monero-powpy miner check if it has a new job? You can find it here. I want to know if it checks if it has gotten another mining job while mining.

The stratum miner processes any jobs sent to it. Although the stratum miner is one file, it is actually two processes:

The main process handles the socket messages between itself and the connected pool.
A worker process which mines jobs.

Line 88 (which is in the 1st process) has q.put(job), which puts a received job in a queue and line 111 (which is the 2nd process), has job = q.get(), which consumes a job and mines it.


Connect to remote node using moner-wallet-cli with --daemon-address with a password? I'm trying to use my password protected remote node with the following cli command, but it doesn't work. What is the correct format to use a user/pass with the remote node in the cli?

./monero-wallet-cli --daemon-address  aaa:bbb@xxxxx.com:18089

A login (username + password), if set on the daemon (via the monerod --rpc-login flag), has to be passed via the --daemon-login flag upon launching monero-wallet-cli. That is, monero-wallet-cli --help states:

--daemon-login arg          Specify username[:password] for daemon                                       RPC client

Thus, in your example, the login would be passed as follows:

./monero-wallet-cli --daemon-address <domain-or-ip-of-remote-node>:<port-of-remote-node> --daemon-login <username>:<password>


How do I split my wallet into smaller denominations? Suppose I have only a single 100 XMR output denomination for my address. How can I split this up, so that when I want to make a 5 XMR transfer, only a subset of my 100 XMR will be locked for about 20 minutes (10 confirmations)? On Reddit, JollyMort made a good analogy with actual cash, where $100 is split into 10 separate $10 bills.

Could someone please post an example of the monero-wallet-cli command to use?
Since transfer fees eat away from the original 100 XMR, I suppose you can't split 100 XMR into 10 times 10 XMR, right?

You can do this by using the transfer_original command. The default transfer command will not split, but seems to be aggregating all the amounts going to the same address in a single denomination. This is based on a few tests I did just now.

So, to split 100XMR to 10 denominations of 10XMR, you'd do:

transfer_original <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10 <youraddress> 10

Of course, you need to have a little more than 100XMR to be able to pay the fee.

One problem with this was pointed out, though. All of these 10 denominations would be in the same TX. If using more than one of them for some payment of >10XMR, it would stick out on the blockchain and these 2 (or more) outputs could be linked together because they come from the same TX. This is unlikely to happen by pure chance when picking decoy outputs to mix with so one could say there's a high likelihood that those 2 outputs belong to the same sender. Not only does this reveal that those 2 outputs were spent by the same person, but it could also reveal that they were likely spent. Then, any ring signature which uses one of those as decoy outputs would be weakened as well.

I'm not sure if it would have a significant impact to privacy if done once per wallet, but I'm inclined to think that it's not such a good idea, after all.


How to use the full node? I am new to Monero but have read some documentation and have read that it is recommended to use the full node and so I installed it to my PC. The problem is the I got no idea how to send money or receive money, like what should I do in order to start a transaction etc.

To me, that is the core factors about these services so I do not know why I have not been able to find a place where I could read some instructions about this.

you can use the full node by running the Monero GUI Wallet (however it's in Beta 2)

here's the link for windows
https://downloads.getmonero.org/gui/monero-gui-win-x64-v0.10.3.1.zip


How do I back up my funds? I plan to use Monero to receive donations. In case of whatever reason something goes wrong with my laptop, I wan't to be able to keep back ups of my funds. Is this possible? I have an Android phone and an external drive. How do I go about backing up Monero funds from my Windows laptop to my phone and/or external drive?

Your funds are not stored on your laptop, they're stored on the blockchain. Copies of the blockchain are stored on perhaps hundreds of thousands of computers all over the world.

What you need to keep safe is your Monero seed. This is the credential that you use to scan the blockchain to see what funds have been sent to you, and to prove you have the right to spend those funds.

If you keep your seed (the 25 word phrase) safe, then even if your laptop breaks, you can at any point in the future download and install a fresh copy of the Monero wallet software on another computer and have full access to view and spend your funds.

If you are using your wallet to send funds to people, your wallet file on the computer you are using will build up a log of your outgoing transactions. Because of Monero's privacy mechanisms, if you lose access to the wallet file, then you can't later figure out the Monero wallet addresses of people you've paid. All that will be remembered is that you did make outgoing payments on particular dates.

On Windows, your wallets are typically stored in your Documents\Monero\wallets folder.

On Mac, your wallets are typically stored in the monero\wallets folder.

Therefore for full access to view and spend your funds, you only need to keep a safe copy of your 25 word seed. But to also remember your outgoing transaction history, you'll also want to keep regular backups of the wallet file on the computer you use to make those transactions.


Why would a candidate transfer be sitting in the memory pool after 3 days? Block explorer explorer.xmr.my currently shows a transaction in the memory pool with "Age 76:18:00", that is more than 3 days.

Assuming the information shown is accurate, I am wondering why it wouldn't be included in a block?

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

Moneroblocks

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

Chain Radar

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

Onion Monero Blockchain Explorer

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

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

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

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


Transaction: 6 hours and 0 confirmations Is there others than me experiencing a slow XMR chain?
It has been 6 hours and 0 confirmations.

It's rush hour at the moment. Eventually blocksize will grow big enough to confirm all the transactions - including yours.

See how it develops here: http://moneroblocks.info/stats/block-medians

In the meantime, you could use a higher fee for "mission critical" TX-es which usually skips the line. If everyone wanted to skip the line at the same time, then the blocks would grow even faster. Note that the "high priority" may be too expensive for some - about 6$. Check the fees here: https://www.monero.how/monero-transaction-fee-calculator


I forgot to upgrade (from CLI or GUI v0.13 to CLI or GUI v0.14) and created / performed a transaction on the wrong (alternative) chain I forgot to upgrade (from CLI or GUI v0.13 to CLI or GUI v0.14) and created / performed a transaction on the wrong (alternative) chain. How do I resolve this issue and let the CLI / GUI show my proper balance?

First and foremost, you have to ensure that you properly upgraded to v0.14. A guide can be found here. In addition, your blockchain has to be "corrected" such that your node syncs to the right chain. A guide can be found here. Thereafter, follow these steps:

Local node

GUI:

Go to the Settings page of the GUI.
Press on the Log tab.
In the command + enter (e.g. 'help' or 'status') box type -> flush_txpool
If you're unable to execute this command, proceed with step 7.
Your transaction should now show as Failed on the History page.
Your balance should now reflect the proper balance.
If not, exit the GUI, but keep the daemon running.
Browse to the directory your wallet files are located (Documents\Monero\<wallet-name> on Windows | home/<username>/Monero/<wallet-name> on Linux | Users/<username>/Monero/<wallet-name> Mac OS X).
Rename <wallet-name> (the file without extension) to <wallet-name>-old.
Restart the GUI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.
You should see your proper balance once the wallet is fully refreshed.

CLI

Type flush_txpool into monerod
Use show_transfers (in monero-wallet-cli) to verify that your transaction now shows as failed
Your balance should now reflect the proper balance.
If not, type rescan_spent in monero-wallet-cli

Remote node

It's quite unlikely that the remote node you connect(ed) to was running a v0.13 daemon (monerod), as most remote node lookups have proper checks in place. However, use the following steps if it occurred and you created / performed a transaction:

GUI:

Exit the GUI.
Browse to the directory your wallet files are located (Documents\Monero\<wallet-name> on Windows | home/<username>/Monero/<wallet-name> on Linux | Users/<username>/Monero/<wallet-name> Mac OS X).
Rename <wallet-name> (the file without extension) to <wallet-name>-old.
Restart the GUI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.
You should see your proper balance once the wallet is fully refreshed.

CLI:

Exit the CLI.
Note that, by default, the CLI stores the wallet files in the same directory as monero-wallet-cli
Rename <wallet-name> (the file without extension) to <wallet-name>-old.
Restart the CLI. This will trigger a wallet refresh from scratch, which shouldn't take longer than 30 minutes.
You should see your proper balance once the wallet is fully refreshed.


I am running blockchain 0.9.4. Why is it not syncing? I know that you can send coins from 0.9.4 to 0.10.0. If I am still running 0.9.4 will it sync with 0.10.0 blocks?

I am trying to sync my 0.9.4 chain and it does not seem to be syncing any new blocks.

"I know that you can send coins from 0.9.4 to 0.10.0" - I'm not sure what you mean by that? They aren't separate chains like Ethereum and Ethereum Classic, it's the same chain but a newer version of the software.

You can't use 0.9.4 as it's an old, deprecated version of the software. You need to update to 0.10.0, and you may want to sync up from scratch instead of waiting for the database to be converted to the newer format (database changes aren't common, so this won't occur with every upgrade).


Monero mining software I have just started mining and I found that every miner that I download is not running, blocked by chrome, or blocked by antivirus.
Right now I'm using minergate and I don't like it.
I want some mining software.
Please don't tell the ones on Linux because my cpu (ryzen) isn't supported by Linux, any Linux.
I don't care if it is cli or gui.
Thanks.

You can use any miner which supports cryptonight algorithm.
ccminer, cpuminer comes to mind, both supports cryptonight.
Minergate's miner is actually a moded cgminer, and their blog is actually quite helpful, but there are suspicions that their software is skimming hash rates, I personally don't use any closed source miners.
The ultimate solution would be running Linux, just wait a couple of months till the proper firmware from AMD and new kernels get released then you can try again.


Can you trustlessly trade Monero for Bitcoin? Some cryptocurrencies can be traded in a trustless manner, also known as atomic cross-chain traded. This means that when the trade is done, either the entire trade is done, or none of it is (otherwise, one party could choose not to send their coins).

Can this be done between Bitcoin and Monero. Monero doesn't have scripting support, so the above link's protocol wouldn't work.

One application for this is recovering stolen Bitcoins. If your Bitcoins are stolen, you can buy them back at a discount from the attacker. Since you don't trust each other, or even trust a common arbitrator, it needs to be a trustless trade. You won't recover all your wealth (since you had to give up some of your Monero, which you may have had to buy), but since its at a discount, you'll have recovered some of it. (The thief is likely to accept this, since otherwise he would need to go through the process of laundering the bitcoins.)

Indeed it can. Let's say Alice has Y XMR and Bob has Z BTC, and they want to trade.

Alice and Bob setup a multisig wallet (see this).
Alice creates (but does not sign) a transaction of Y XMR to the multisig wallet.
Alice and Bob mutually sign a transaction from the multisig wallet that sends Y_1 XMR < Y XMR to itself, but locked for 48 hours. They also sign a transaction to send Y_1 and (Y - Y_1) to Alice. These transactions are called the escape transactions, and are not published to the block chain unless Bob acts maliciously.
Alice signs her transaction from step 2 and publishes it to the blockchain. Then Alice and Bob wait until Bob feels that there are enough confirmations of the transaction.
Bob now buys Alice's key to the multisig wallet using his Z BTC using a contingent bitcoin payment. This payment expires if not claimed in 24 hours.
Alice redeems this transaction, revealing her mulitsig key.
Bob drains the multisig wallet for its Y XMR.
Alice know has the Z BTC, and Bob has the Y XMR.

In the event of one of the parties being malicious

If Alice or Bob refuse to do step 1, 2, 3, no coins have changed hands, and the trade is aborted.
If Alice refuses to do step 4, the transactions signed in step 3 are invalid, and so no valid transactions have been signed. The trade is aborted.
If Bob refuses to do step 5, Alice can redeem her Y XMR after 48 hours by publishing the escape transaction.
If Alice refuses to do step 6, the trade is aborted. Bob will be able to recover his Bitcoin after 24 hours. (Alice will also be able to redeem her Monero after 48 hours.)
If Alice tries to publish the escape transactions after step 6, only the first one will be accepted (since the second one is spending monero that is time locked). Bob can and must then redeem (Y-Y_1) XMR from the multisig wallet (since he know has both of its keys), which permanently invalidates the second escape transaction (he can redeem a lesser amount, if he so chooses, as well). After 48 hours, he will be able to move or spend the Y_1 monero that was time locked. Despite Alice trying to be malicious, the trade has been completed successfully.

The only issue with this is that a party acting maliciously can cause the other parties funds to be frozen, but this is only temporary. It may even be possible to add collateral such that if one party aborts once the funds are locked, the other party gets their collateral. That is a question for another day though.

The 24 hours and 48 hours in the above protocol can be adjusted for security. The only requirement is that the contingent payment expires before the escape transactions become valid (with a good buffer in between just in case), as otherwise Alice could drain the multisig monero wallet and then reveal her key to get the bitcoin.


How to programatically validate Monero address When withdrawing with BTC this line of code checks for empty wallet and a false wallet addresses and aborts the withdrawal if either are detected. I have the empty part working for XMR what would I use for the actual address validation.

if(empty($address))

return Redirect::back()->withInput()->with('error','Bitcoin address invalid!');

$validator = $wallet->validateAddress($address);

if(!$validator['isvalid'])

return Redirect::back()->withInput()->with('error','Bitcoin address invalid!');

To do a rough check on a Monero standard wallet address (not an integrated address), verify that it is 95 characters long, check it starts with a 4 (standard wallet address) or an 8 (subaddress) and that it only contains valid Base58 characters. The definition of Base58 allowed characters is "mixed-case alphanumeric, except the following similar-looking letters are omitted: 0 (zero), O (capital o), I (capital i) and l (lower case L)".

To do a rough check on a Monero integrated address, the procedure is the same as above except you'd verify that it is 106 characters long instead of 95 characters. It will still start with a 4.

To fully validate a Monero standard address or subaddress, you need to split it apart and verify the checksum. To split it apart, you need to perform a base58 decoding, taking care to note that Monero's base58 implementation is different to that of Bitcoin. Let's call that decoded result W. The first byte of W is the address type, which you should make sure is either 0x12 (standard) or 0x2A (subaddress). Then you need to check that the first 4 bytes of the keccak-256 hash of the first 65 bytes of W match the last 4 bytes of W. The technical details are here: What are the "public" viewkeys and spendkeys?

To fully validate a Monero integrated address, the procedure is the same as above except when you base58 decode it to get W, check that the first byte is 0x13. Then you'll check that the first 4 bytes of the keccak-256 hash of the first 73 bytes of W is equal to the last 4 bytes of W.

You'll see a javascript implementation of these methods (including keccak-256 and base58 decoding) here: https://xmr.llcoins.net/

There is a 1 in 4.3 billion chance that the address will pass the checksum test if it is corrupted. If you want to be insanely thorough (perhaps because you'd written your own code to generate addresses and wanted to check you were generating them correctly), you could check that the compressed EC points in the address are valid. To do this, after reading the first byte of W, you'd then read two groups of 32 bytes as EC points. Then you'd attempt to decode each point using a library that would alert you to badly formed points. Random bytes would be valid Ed25519 points 50% of the time. After that, you'd verify that the curve points are in the group of the Ed25519 base point G. To do this, you'd scalar multiply each EC point by 2^252 + 27742317777372353535851937790883648493 and verify that the resulting EC point hex is the identity point 0100000000000000000000000000000000000000000000000000000000000000. There would only be a 1 in 16 chance that random bytes would pass this test (i.e. 1 in 2 chance it would be an Ed25519 point at all, and then only a 1 in 8 chance it'd be in the base point group).


How do I use a computer with a wallet to access a headless node at my home? I'm running a headless, low wattage Ubuntu 16.04 (x86, if that matters) system that I have SSH'ed into, ran Screen, ran ./monerod, and then detached the Screen.  This is my node.  I also set up this system with a static IP, both within Ubuntu and within my router settings.

I've got a second computer (client) that I dual boot into either Mac OSX or Ubuntu.  I figure I can --restore-deterministic-wallet in each OS (which happens to be a wallet from a prior installation), and then I can use that wallet from either OS.  I'll just need to ensure it refreshes whenever switching to the other OS, if I've made any transactions.

Anyway, what I was thinking is that I want the wallet on this computer (client) to be refreshed from the other computer (node).

Can this work?  Basically, I don't want my "client" computer to have to sync the blockchain every time it fires up.  I just want to use it as a light client, since I've already got a node online and fully synced.  Can I do it?  How do I do it?

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.


Multi-sig flexibility When multisig becomes available for Monero how flexible will it be?

If "M" is number signatures required and "N" is the number of signatures available what is the minimum and maximum "M" and "N" possible for Monero "M" of "N" multisig transactions?

Can there be additional options such as requirement that each signature must happen within a certain time period (or number of blocks) of another signature?

Ring multisignature transactions can theoretically be implemented for any number of users and required signatures:

  Suppose that a group of n users wants to create a multisignature address requiring t of the group to sign in order to spend any funds received, and in such a way that any observer will be unable to determine for certain whether funds have been sent from this address or not, but in such a way that spending funds twice is impossible

Although I am not aware of plans to facilitate placing specific time requirements for the completion of signatures for Ring multisig transactions, research has focused on some use cases where that feature would have value:

  Another possible use of threshold multisignature is for an organization, such as the board of directors of a company holding company funds, or the developers of an open source software project holding donated funds, to control their funds in such a way that a certain number of members is required to execute any decision regarding the expenditure of those funds.

RingCT will provide multisig Monero transactions with unique anonymity related benefits not available in any other crytocurrency:

  threshold signatures can be used in conjunction with the ring signatures, one-time keys, and ring confidential transactions of Monero to allow for anonymous threshold signature transactions with recipients, senders, and amounts obscured.


How to "unpack" a Monero integrated address using the command line? I have 2 questions:

1) how to unpack a Monero integrated address without the wallet RPC (just using common Linux utilities on the command line)? I couldn't find the format of the integrated address (or I didn't search enough)...

2) if I send some XMR to an "unpacked" integrated address, explicitly using the payment_id, it's the same as sending directly to the integrated address, right? I ask because Tux exchange just added XMR with integrated address, but other exchanges don't support withdrawals to an integrated address (Hitbtc for example returns an error).

My idea is to unpack the integrated address and send the old way (using the payment id).

Thank you!

This site helped:

https://xmr.llcoins.net/addresstests.html

The relevant code is here:

https://xmr.llcoins.net/js/site.js

on function addrCheck().


Does the miner transaction (of a block reward) get sent to a miner's stealth address? Does the miner transaction (of a block reward) get sent to a miner's stealth address? (Or to the public address of the miner)

Thanks.

It is still a stealth address but the amount is not hidden.


Can the Monero block chain be used for anonymous communication/ data storage/ private records for small to big entity? Can the Monero block chain be used to transmit anonymous messages or for data storage?,

For example a military secret, confidential state data, company private records, employee payroll, private communication between two users, or a group, private data stored in block chain in a decentralized and a private way in the block chain (instead of current private communication model like  Off The Record/ pidgin/Tor which has several drawbacks like accidental loss of data and news of Tor being cracked by NSA).

If so, what needs to be done, how can such technology be created on the Monero block chain?

You can put potentially any data into tx_extra and it will be stored on the blockchain with your transaction, only accessible with your keys.

This however, will bloat your transaction size and your transaction will be more expensive as you have to pay per kb. For now, beside the elastic blocksize limit (median of last 100 blocks * 2) there is no maximum how much data tx_extra can contain, so if you can afford, you can store almost anything you want.


If I have a vanity address does it decrease my wallets security? I've seen some people with vanity Monero addresses like 43COINxxxxxx. Does having a vanity address like this increase its susceptibility to getting cracked and view/spend keys getting found?

In terms of cryptography: no, unless the vanity generator is badly implemented, without a proper source of entropy.

Although, if you use an untrusted vanity generator, they could record your private key and send it somewhere. Good old trick.


The GUI uses all my bandwidth and I can't browse anymore or use another application that requires internet connection Per title, the GUI uses all my bandwidth and I can't browse anymore or use another application that requires internet connection. How do I resolve this?

monerod takes a lot of bandwidth during the initial sync. If you're unable to browse or use any applications that require internet connection, you can limit monerod's bandwidth as follows:

Go to the Settings page of the GUI.
Look for the daemon startup flags box.
Add this line -> --limit-rate 500
Exit the GUI and make sure to stop the daemon as well.
Restart the GUI + daemon.

Step 4 & 5 are needed for the flag from step 3 to take effect. Note that --limit-rate 500 will limit the bandwidth to 500 kB/s. Note that you can tweak the parameter / flag yourself by adjusting the value.


Error calling RPC method create_wallet with curl I have a remote node setup with RPC enabled and restricted_rpc set to false. I am trying to create a new wallet remotely, but I'm getting the response: Error: method not found

curl -u 123:abc--digest -X POST http://xxxx.com:18089/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"create_wallet","params":{"filename":"mytestwallet","password":"mytestpassword","language":"English"}}' -H 'Content-Type: application/json'

Alternatively, how can I do it locally using monerod that connects to a remote node? Basically I don't want to download the entire monero blockchain, but still be able to create wallets.

Are you saying you're asking a node to create a wallet ? A node cannot. A node doesn't deal in wallets, just in blockchain. Ask your local wallet, which in turns talks to the node hosted wherever.


How to make a symlink to an external drive? I have an external drive that I want to store my blockchain on. I gather that I can make a symlink to my .bitmonero folder so the blockchain automatically gets stored on the external drive but I don't know how to do it. Can anyone walk me through setting this up?

The simplest and most portable approach is provided by dEBYUNE above. The --data-dir can also be defined in the monero node's configuration file so it does not have to be passed as an argument of the monerod CLI.

Otherwise, a UNIX only approach is provided below.

Step 0 - make sure monerod is not running

Step 1 - make sure the owners, groups and permissions of the external directory are the same or appropriate for your system's permission security model.

Step 2 - make a relative path tape archive (tar) file of your ~/.bitmonero file.

% cd ~

% tar cvf /your_desired_external_drive_path/.bitmonero.tar .bitmonero

% cd /your_desired_external_drive_path

% tar xvf .bitmonero.tar

Step 3 - rename your original .bitmonero directory. (Can delete after step 6 after confirming monerod is functioning reliably.)

% cd ~

% mv .bitmonero original.bitmonero

Step 4 - make a relative .bitmonero directory link

% ln /your_desired_external_drive_path/.bitmonero .bitmonero

Step 5 - confirm link was made properly by:

% ls -l .bitmonero

Step 6 - start your monero daemon the way you did previously, in this case --data-dir becomes optional.


How does one prove ownership of a Monero address? Just like how a user can prove they are the owner of a Bitcoin public key by signing a message, how can a Monero user prove they are the owner of a Monero public key?

Best is to sign a message consisting of your address, with your address.
The sign and verify commands have been merged just yesterday: https://github.com/monero-project/bitmonero/pull/818

First, make a file with the data you want. It just happens that, when creating a wallet, your address is saved in WALLETNAME.address.txt.

Then, sign:
sign WALLETNAME.address.txt

Then send the signature output by that command to the other party, who can now verify:
verify WALLETNAME.address.txt 4xxxxxx SigV1xxxxxx


Pool mining to local wallet Is it possible to use pool mining to mine to a wallet created with monero-wallet-cli stored on my local machine?

If so, what is this minimum amount that needs to be pool mined before I will find a balance on my local machine?

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.


Why does the Daemon keep flipping about after full loading WhiteDragon coffin dodger at work, I managed to be fully loaded after a three day tedious wait all the block data for the /monero-gui-v0.17.1.9
Not pain free with a couple of restarts, all from scratch.
On shutting down the wallet had to kill the background demon with a Ctrl C, otherwise the PC was more or less locked out for normal work.
On restarting the /monero-gui-v0.17.1.9/monero-wallet-gui it took a while for the syncing to restart and in the lower left of the wallet I have:-
Wallet is synchronised
Daemon is synchronised(87656)
then it flips to
Waiting for daemon to sync
Daemon blocks remaining:     2224076
The error reports are
E Blocks start before blockchain offset: 0 2265000
E !m_blockchain.is_in_bounds(current_index).
THROW EXCEPTION: error::out_of_hashchain_bounds_error
Seems like it is trying to download the whole damned data in full again - time to pull the plug!
Thanks for any help/pointers -> WhiteDragon

On a bit of digging found that the daemon had ignored the /Homedirectory/.bitmonero/lmdb that took 3 days to create. On restarting the gui the daemon began to re-create in total the data in /Homedirectory/Monero/monero-gui-v0.17.1.9/lmdb - it had stuffed 2gig already by time I pulled the plug. I cp'd the .bitmonero/lmdb content to this new location that had magically appeared and was able to resync the gui.  It would help if the daemon had an address or environment variable where to find the data.mdb rather find it chuntering off on it's own. Need more Noddy guide(s) for Newbies.
PS.
even a disk to disk copy of 106 gig takes nearly an hour to complete.
Follow up:- On checking with monerod --help   noted that /Homedirectory/.bitmonero is the default location for the database - hmmm, finger trouble at work - yes I had stupidly in the gui Settings/node section entered the download directory for the Blockchain location - DOH! Deleted my entry such that it was marked as default. Now I can remove the extra 106gig copy of the database. On restart the re-sync took a few minutes to complete and was in the correct location of /HomeDirectory/.binmonero
Time for a cup of coffee now that is fixed!


Newbie, tracing/understanding transactions Am I correct?
I see in my transaction "From Block" these things:
Hash    IDon'tKnowIfIShouldObscureThis
Height  1317365 (437 confirmations)
Timestamp (UTC) 2017-05-24 18:40:59 (15 hours ago)

In my Full node Monero Wallet I see:
Synced 1238883/1288639

Does this mean:
1: I have to wait untill synced Synced 1288639/1288639
2: Then wait untill I get 1317365
before I can see the money in my balance?

(balance is still 0)

I see in my transaction "From Block" these things:
  Hash IDon'tKnowIfIShouldObscureThis
  Height 1317365 (437 confirmations)

  In my Full node Monero Wallet I see: Synced 1238883/1288639

  Does this mean I have to wait until I get 1317365
  before I can see the money in my balance?

You are correct. Until you have synced up the the block height of your incoming transaction your wallet will be unaware of it.

With Monero there is no way to look up the balance of an address. Instead every block is scanned to see if it contains any outputs which your wallet controls. In your case the block in question will not been seen until you sync to height 1317365


How do I upgrade my software to the newest version? I've been running one of the following:

CLI / GUI v0.14.X.X
CLI / GUI v0.15.X.X

How do I update these to the newest version?

First and foremost, we encourage users to check the integrity of the binaries and verify that they were signed by Fluffypony's GPG key. A guide that walks you through this process can be found here for Windows and here for Linux and Mac OS X.
CLI: (most recent version: v0.17.1.9)
If you are using the CLI you ought to perform the following steps:

Download the new binaries (the .zip file (Windows) or the tar.bz2 file (Mac OS X and Linux)) from the official website or Github.

Extract the new binaries to a new directory of your liking.

Copy over the wallet files from the old directory (the one that contains the v0.15.X.X, v0.16.X.X, or v0.17.X.X binaries).

Note that a blockchain resync is not needed. Thus, if you open monerod-v.0.17.1.3, it will simply pick up where it left off.

GUI: (most recent version: v0.17.1.9)
If you are using the GUI you ought to perform the following steps:

Download the new binaries (the .zip file (Windows) or the tar.bz2 file (Mac OS X and Linux)) from the official website or Github.

Extract the new binaries to a new directory of your liking. This is the easiest and recommended way. Alternatively, however, you can overwrite the old binaries.

Open monero-wallet-gui¹. It should automatically load your "old" wallet and you should be set for the upcoming scheduled network upgrade.

If you're running a local node, the integrated daemon (monerod) will first have to convert your database to a new version. This may take a 5-10 minutes and the GUI will show that it's Disconnected. I'd advise to simply let it run and after the database conversion has completed the GUI will connect back to the daemon (monerod).

(1) On Linux you ought to start the GUI with the start-gui.sh script, i.e., ./start-gui.sh.
(2) If, for some reason, the GUI doesn't automatically load your old wallet, you can open it as follows:
[1] On the second page of the wizard (first page is language selection) choose Open a wallet from file
[2] Now select your initial / original wallet. Note that, by default, the wallet files are located in Documents\Monero\<wallet-name> (Windows), Users/<username>/Monero/<wallet-name> (Mac OS X), or home/<username>/Monero/<wallet-name> (Linux).
Lastly, note that a blockchain resync is not needed, i.e., it will simply pick up where it left off.


Monerd error on rpc-bind to make a public node I set my rpc-bind-ip=x.x.x.x in my bitmonero.conf file and used my public IP addres. But I am getting this error:

  ERROR   default src/rpc/rpc_args.cpp:80 --rpc-bind-ip permits inbound
  unencrypted external connections. Consider SSH tunnel or SSL proxy
  instead. Override with --confirm-external-bind

What else do I need to do to make a public node where my monejuro can connect to?

FYI, I'm on linux with firewall enabled and ports opened for monero rpc.

You have to do what it's told and add --confirm-external-bind


Are there separate view keys for each account in a Monero wallet? I understand that a seed is used to generate your initial private spend key as well as the private/public view keys; creating your initial account and first real subaddress. From there, other accounts with their own subaddresses can be generated and added to your wallet.

Does this mean that all accounts have the same view key (because the view keys are directly derived from the seed and not from the accounts)?
If so, does this mean every subaddress generated is using the same public view key no matter the account it is in?
Is there any way or plan in the future to have different view keys for each account in a wallet?
I know there is no limit to the number of subaddresses an account can have - is there a limit (or recommended limit) for the max number of accounts the monero-wallet-cli can handle?
Looking at the RPC commands on getmonero.org I don't see a way to see payments coming into a specific subaddress. Is there a command like get_payments (or even just locally in monero-wallet-cli), that can break out payments to a specific subaddress?
Also reading Moneropedia > View Key, I came across this:

  By sharing a viewkey, a person is allowing access to view every incoming transaction for that address. However, outgoing transactions cannot be reliably viewed as of June 2017. Therefore, the balance of a Monero address as shown via a viewkey should not be relied upon.

Why would some outgoing transactions not be viewable after June 2017?

Thank you so much for your time.

Does this mean that all accounts have the same view key(because the
  view keys are directly derived from the seed and not from the
  accounts)?

Just to clarify, "account" is just about grouping sets of subaddresses together. There are only subaddresses, and we decided to group them into accounts that would share the same balance for presentation purposes only. The blockchain has no idea what an account is. Accounts are only really part of a two tier numbering scheme, and nothing special.

Subaddresses were specifically designed so that the same private view key is used to scan for all incoming funds to all subaddresses.

  If so does this mean every subaddress generated is using
  the same public view key no matter the account it is in?

They're all generated from the same private view key

  Is there any way or plan in the future to have different view keys for each account
  in a wallet?

They share the same private view key for performance reasons. If you had N different private view keys, wallet scanning time (which is computationally expensive due to elliptic curve operations) would take N times longer. Thus, if you really want multiple private view keys, we decided that separate wallets were the best approach. This is just wallet logic though, and nothing is stopping someone from forking the Monero wallet and implementing a scheme with multiple view keys. This fork of the wallet software would be totally compatible with the Monero network and blockchain.

  I know there is no limit to the number of subaddresses an
  account can have - is there a limit(or recommended limit) for the max
  number of accounts the monero-wallet-cli can handle?

There technically is a limit, which is 2^32 (approx 4 billion) accounts, each with 2^32 subaddresses.

  Looking at the RPC commands on getmonero.org I don't see a way to see payments coming
  into a specific subaddress. Is there a command like get_payments (even
  just locally in monero-wallet-cli) that can break out payments to a
  specific subaddress?

get_payments does return a "subaddr_index" with a major and minor index (account and subaddress index).

  Why would some outgoing transactions not be viewable after June 2017?

Monero's privacy mechanisms are designed so that you can't tell for sure if an output has been spent, unless you know both the private view key and the private spend key. Thus it has never been enough to only know the private view key, if you want to know for sure about outgoing transactions. Some wallets may have tried to guess at outgoing transactions, based on the receipt of change outputs that happen to mention other outputs received to your wallet in the list of spent outputs. You need to know the private spend key in order to know the key images for your outputs, and only someone with the knowledge of the key images can tell whether outputs have been spent. I don't see how June 2017 would have changed this, unless some wallets that had previously been guessing at outgoing transactions decided to stop guessing.


ELI5 how to install AEON on Ubuntu 16.04 LTS After the downloading the tar.gz file from GitHub to my default downloads folder what do I do next?
The readme below seems to provide general instructions for compiling from master but is not specific for installing the latest release I downloaded above.
Compiling AEON

On Unix and Linux:
Dependencies: GCC 4.7.3 or later, CMake 2.8.6 or later, and Boost 1.53 or later (except 1.54).

To build, change to the root of the source code directory, and run 'make'.

The resulting executables can be found in build/release/src.

When I extract the tar.gz file I do not see the executable file (aeond or aeon-wallet-cli) like I would when performing the same process for a Monero release. Please provide me with step by step commands to install AEON starting with the assumption that I have downloaded to tar.gz file for the v0.9.11.0 AEON release

The following assumes that your default downloads folder is called Downloads and that it's a subdirectory of your home directory, that the aeon source code archive that you downloaded is called aeon-0.9.11.tar.gz and that it get unpacked as an aeon-0.9.11 directory. You'll have to adjust the instructions if the names of your files or directories differ.

Open a command-line terminal and enter the following four commands:

cd ~/Downloads
gzip -cd aeon-0.9.11.tar.gz | tar xvf -
cd aeon-0.9.11
make

If you've already got all necessary dependencies installed, the above will just work. But if not, you'll need to install whatever's missing using whatever package manager Ubuntu provides. You've probably already got make — find out (from your terminal) by entering make --version, and if you've already got cmake, then cmake --version will tell you the version. The GCC 4.7.3 dependency means the C++ compiler, so check the version by entering g++ --version. If you have the boost headers installed, you can perhaps list them with ls /usr/include/boost, and you should be able to list the boost libaries with ls /usr/lib|grep boost: this may give you a clue as to which boost version you've got (for instance, I've got version 1.56, and that last comamnd tells me that I have various files with names similar to libboost_filesystem.so.1.56.0.

If the build works, you will end up with aeond, simplewallet, simpleminer and connectivity_tool in the folder ~/Downloads/aeon-0.9.11/build/release/src (note that “~” is a quick way of referring to your home directory). Try entering ls -l ~/Downloads/aeon-0.9.11/build/release/src for a detailed listing.


When you sign a Monero transaction, are you signing a hash? When you are signing a Monero transaction, do you sign the transaction itself, or do you hash the transaction and then sign that?

In the interest of pedantry (and since I can't comment -_-):

You sign the hash of the transaction prefix. In Monero that is everything but the signatures.
(at the above answer) Monero relies on ed25519, not EdDSA. EdDSA is a particular signature system (completely absent in Monero). Monero's ring signatures are presently the Fujisaki-Suzuki variety, implemented in the ed25519 curve.

One additional quibble: in Monero's ring signatures, the hash doesn't actually have "mathematical" transformations applied--it is rather hashed again along with a bunch of other data--so one actually could "sign" an arbitrary-length message instead of a hash of said message.


Is the 'pseudoOuts' of 'rctSig' the commitment on input amounts for simple RCT It seems that the genRctSimple function will make a different input commitment for each input amount (line 675-683 in file src/rct/rctSigs.cpp). And summation of these input commitments = output commitments. Why not just use original input commitments along with the input coins? Is it for unlinkability? Or for later checking (if yes, how?) Or something else?
Appreciate greatly for any possible answer.

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

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

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

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


How much time to have blockchain synced? I am wondering if there's a command to predict / calculate how much time does bitmonerod.exe still need for a blockchain fully synced.

Currently its 404321/1133160 and my network usually has a download speed of +3mb/s

Any guesses? Thanks!

I am wondering if there's a command to predict / calculate how much time does bitmonerod.exe still need for a blockchain fully synced.

This is basically impossible to calculate. Syncing speed depends on a variety of factors, such as type of hard drive (SSD or HDD), computer specifications (old computer versus relatively new computer), and bandwidth.

On a decent computer with an SSD it will take about 1-2 hours. On a decent computer with an HDD it will already take 6-8 hours. If you have a relatively old computer it might take 12 hours to several days even.


Digest Authentication in monero-wallet-rpc I have an application and I want to connect it to my Monero wallet. I can use curl to access the wallet using --digest but my app can't use curl. I am using jsonrpc in Ruby and I can make the call to the wallet successfully but there is an authentication issue because the wallet uses digest. Is there a way to disable digest in the monero-wallet-rpc? If not is there anyone who knows how to use digest in jsonrpc? I will post the my code if anyone wants to see it.

Any help would be greatly appreciated

Ruby's standard net library doesn't appear to have digest authentication support. However, there is a gem which adds digest support and there are several HTTP client libraries (e.g. HTTPClient and many others) that also add support.

You can of course disable login altogether on the monero-wallet-rpc by passing the --disable-rpc-login at startup, though I would only recommend disabling login if you are not exposing the RPC externally (so only listening localhost) and the machine it is running on is sufficiently secured.


Is there any exchange that offers a Monero/Aeon trading pair? Aeon is the cleanest fork of Monero and shares a developer and some community members. Are there any exchanges where Monero can be traded for Aeon directly without the need to use Bitcoin as an intermediary currency for the exchange?

Currently there are two exchanges that offer direct XMR/AEON conversion each with its own limitations/warnings. The third option would be direct OTC trades (optionally with an escrow agent to reduce risk).

Cryptopia offers the most XMR trading pairs of any exchange including an XMR/AEON pair. Its current limitation is very low trading volume compared to the Poloniex (first exchange that offered Monero trading pairs including XMR/AEON previously).
Changelly operates in a manner similar to Shapeshift but unlike Shapeshift offers Aeon trading and direct XMR/AEON conversion. It receives a large level of distrust within the Monero community due to its connection with Minergate
There is a Bitcointalk thread designed to connect buyers and sellers hoping to arrange OTC trades. IRC trading at #monero-otc is another option
LocalMonero also provides an OTC platform for XMR/AEON trades.

The centralized exchange with the most Aeon volume is Bittrex. It was not mentioned in my answer above because they do not offer a XMR/AEON trading pair. Bittrex does offer both a BTC/XMR trading pair and a BTC/AEON trading pair.


Is there a javascript implementation to generate your Monero subaddresses without giving out your private-spend key? I want to create an online widget where one can output their subaddresses without having to input their private-spend key and only use the other keys provided. Is there a javascript implementation of this?

Yes, you can use this Javascript NPM package to generate subaddresses: https://www.npmjs.com/package/subaddress


Problem transfering to Monero address copied from SE comment using monero-wallet-cli. `Error: wrong address` I was trying to send some testnet coins to myself to an old address that I posted in a comment in this post. You can see that xmr_eric was successful in sending me some coins at the time. So today I tried to copy the address from that comment I made into monero-wallet-cli and do

transfer 9z1N6pssDU3hvq9X6iqxk2g2e4tfc2WqfiMcKLR2dE8mZVjGN4yCKBD4QE8jxNMMCabNQNzDKLUnZSguEMMr4YPSBcMuJ8p 1,

but then I get:

Error: wrong address: 9z1N6pssDU3hvq9X6iqxk2g2e4tfc2WqfiMcKLR2dE8mZVjGN4yCKBD4QE8jxNMMCabNQNzDKLUnZSguEMMr4YPSBcMuJ8p...

I assume it is something that happens when copying from that particular SE comment. I tried from two different computers and the two wallets gave the same error. Actually, if I run exactly the same command, copying the address from inside the wallet itself:

transfer 9z1N6pssDU3hvq9X6iqxk2g2e4tfc2WqfiMcKLR2dE8mZVjGN4yCKBD4QE8jxNMMCabNQNzDKLUnZSguEMMr4YPSBcMuJ8p 1

I get the normal response:

transfer 9z1N6pssDU3hvq9X6iqxk2g2e4tfc2WqfiMcKLR2dE8mZVjGN4yCKBD4QE8jxNMMCabNQNzDKLUnZSguEMMr4YPSBcMuJ8p 1
The transaction fee is 0.026000000000.
Is this okay?  (Y/Yes/N/No)n

I compared the two strings in a text editor, and they are visibly identical... And, sure enough, if I just type the address, character by character, then it works fine. Do you know what this could be?

In the first two cases you have "\n" in the address.

9z1N6pssDU3hvq9X6iqxk2g2e4tfc2WqfiMcKLR2dE8mZVjGN4yCKBD4QE8j<\n>
xNMMCabNQNzDKLUnZSguEMMr4YPSBcMuJ8p