How to check if transaction pays to my address? Let's assume I have an address, a secret view key for it, and a transaction. The transaction has been checked by a daemon to be valid.

How do I figure out if the transaction pays something (and how much) to the address? What are the operations I need to perform?

PS: I'm asking only about v11 and v12 protocol.

Additional info:

It's not obvious in the explanation below that some transactions have more than one pubkey. Specifically, it happens when the tx pays out to multiple subaddresses. A good explanation of what additional data should be processed is in this question

Extract the tx public key R from the tx extra field, and for each output, it's key
K and index i, then using your private view key a and public spend key B, you own the output if:

Hs(8aR||i)G+B == K

To find out how much you received, take the encrypted amount e for that output index from the transaction's ecdhInfo field and decrypt:

xor8(e, keccak("amount"||Hs(8aR||i))

Note, xor8 is XOR'ing the first parameter with the first 8 bytes of the second parameter, the result is the decrypted amount.


Monero project visual c++ I want to edit c++ monero project in visual studio c++. Is anybody know where I can find this type of project? What kind of libraries are required?

The Monero code is built using gcc. There is no support for building with Microsoft's tools, and it is not expected to work.


Can someone help me read a block explorer? If I enter a transaction no. (not trx id) in a site like blox.supportXMR.com I see first of all 2 outputs with amounts of 0. Then below I see 2 inputs that are broken down into groups of "stealth" addresses. Each of the 2 groups have an amount indicated. I am trying to figure out what input and output actually mean and why input has amounts and output does not (I thought amounts would not show anywhere now). Also, it seems that mixin level cannot be determined on a blockexplorer. It seems that whatever mixin I use, it shows 2 outputs. Thanks.

I'm not sure if you understand the CryptoNote protocol sufficiently. If not, the whitepaper should probably be the first resource for you to consult with.

RingCT was first published in MRL-0005, but some of the details are different in the current implementation.

I have made several posts trying to understand (and explain) how RingCT works:

Questions regarding the cryptography behind RingCT
Does the key vector approach in RingCT represent linkability among transactions? Can it be exploited by blockchain analysis?
Can I manually check consistency of Pedersen Commitments in RingCT?

I hope these posts are helpful to you. Anyway, I try to answer your questions below. Let's take the following transaction as an example:

947433d235244bf323fd33b8a1da3cca3d77f55b08e062049f7eae35eb5d77d1

  I see first of all 2 outputs with amounts of 0.

These are 2 new outputs created in this transaction. Their amounts are 0 because they are in the RingCT format.

  Then below I see 2 inputs that are broken down into groups of "stealth" addresses. Each of the 2 groups have an amount incidated.

This example transaction has 4 inputs, and their amounts are indicated (0.7, 0.02, 0.005, 30.0) since they are in the pre-RingCT format.

  I am trying to figure out what input and output actually mean and why input has amounts and output does not (I thought amounts would not show anywhere now).

The reason why the inputs have nonzero amounts and the outputs have zero amounts is because this transaction is converting pre-RingCT outputs to RingCT outputs. Another example below is a RingCT-to-RingCT transaction, so all the amounts are zero on both inputs and outputs:

2b39c3f9e6d65fd9b2e59be412bcfd9fb234951ab7bcb28639ffbaa7a4579108

  Also, it seems that mixin level cannot be determined on a blockexplorer. It seems that whatever mixin I use, it shows 2 outputs.

The mixin level is indicated by the number of keys in each of the groups. In the above two examples, the mixin are 3 and 2, respectively. Typical RingCT transactions have two outputs, one going to the payment destination and the other going to yourself as the change.


Monero deposit did not arrive on binance I have made a deposit of XMR at 16:29:50 CET on 2018-05-02 (Now almost 16 hours ago). I am using Monero GUI v0.11.1.0. The transaction id is e793d31e00250540da8a1edab7a2aab6f063767e1c604c6634c5b9e9f2c1afad. I have used the correct payment id and deposit adress but the XMR's are still not on my Binance account. The balance on my wallet is back to 0 and all transactions are confirmed. It seems I have done everything correct but my XMR's seem to be lost. Could you please hep me?

First thing you have to do is, download the newest version of the Monero Client GUI and import your wallet there. Make sure to user version 0.12.

Then sync the blockchain and let's see if you still have that issue.

I think you will actually see that you still have your Moneros in your wallet and that the transaction didn't work out.


Problems setting gui wallet on Tails I get these two situations...

If I try to run the wallet gui file with that command, it shows as following:

amnesia@amnesia:~/Persistent/Tor Browser/monero-wallet-gui$ ./monero-wallet-gui ./monero-wallet-gui: error while loading shared libraries: libQt5Quick.so.5: cannot open shared object file: No such file or directory

Also if I try to run from the script provided, I get the following:

./start-gui.sh
./monero-wallet-gui: /usr/lib/i386-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.21' not found (required by ./monero-wallet-gui)
./monero-wallet-gui: /usr/lib/i386-linux-gnu/libstdc++.so.6: versionGLIBCXX_3.4.21' not found (required by /home/amnesia/Persistent/Tor Browser/monero-wallet-gui/libs/libproxy.so.1)

How to correct these? Thanks in advance (:

Extra: I do have the correct (32 bit) installed and also the latest Tails build.

You seem to be missing the applicable libraries for the build.

If you go to the Monero github page.

https://github.com/monero-project/monero

and scroll down to: Compiling Monero from Source.

And install the necessary libraries highlighted, that should resolve your issue.


Does the dynamic blocksize limit and penalty function lead to a tragedy of the commons? My understanding is that:

The penalty applies to the block subsidy and not the transaction fees.
Under constant demand blocks can increase continuously by pushing up the median block size.
There doesn't seem to be a push back mechanism to confine block size except for reduction of the median by block space exceeding demand.

This means that as long as there are enough transactions waiting, blocks could always get full which would not incur a penalty. However, whenever there are enough transaction fees waiting to add e.g. 0.25% of the block subsidy with 5% additional block space, it would be economically viable to exceed the median block size by 5%.

In a scenario of constant demand excess such as Bitcoin is currently entering, blocks could continuously grow e.g. by the aforementioned 5% per day. Even a consistent growth of 5% per day would amount to 40% per week. As the block space supply could then grow exponentially and essentially unboundedly, all kinds of use cases that require cheap block space would be attracted, in turn creating a practically unbounded demand.

Meanwhile, assuming approximately homogeneous fee levels over the body of waiting transactions, e.g. transactions filling 5% of the block space should not exceed 0.0025 of the block subsidy, otherwise a bigger block would be more profitable to the miner. Hence, short term optimizing miners could have fees trending toward a small fraction of the block subsidy (for the assumed 5% growth it would be 5,25%).

This growth would be further exacerbated by the decreasing block subsidy reducing the cost of block size increases.

With sufficient demand, one would end up with a boundless block size, and a minuscule block reward, a tragedy of the commons. What am I missing?

With sufficient demand, one would end up with a boundless block size, and a minuscule block reward, a tragedy of the commons. What am I missing?

I would argue you are missing physics. At some point, the physical limits of the network bound the blocksize. I.e., if a miner decides to keep pushing the blocksize higher, eventually a blocksize will be reached that takes considerably longer to propagate through the network than a smaller block.

Indeed, there are two prerogatives for blockchain mining:

Crafting a block with the highest reward possible
Propagating that block to the entire network before a competing block propagates through the network

The evidence for #2 can be seen in the bitcoin network - mining pools opt to mine empty blocks even though they could receive more bitcoin if they mined blocks with transactions. (although this behavior seems to have stopped recently with the advent of centralized block relay networks)

So, as is often the case, the phrase "tragedy of the commons" is missing a key qualifier that the coiner of the term realized he should have added - "Tragedy of the unregulated commons". In our case, the regulation is physics, so the Monero network will always adapt at the rate of the technology that runs the software.

Edited to add: The dynamic fee algorithm also provides an incentive to keep the blocks small. As the block size increases, the minimum relay fee decreases.  Thus, even though you are filling the blocks with more transactions, it not necessarily the case that the transaction fees are worth more.


Is there a block explorer that shows raw blocks? I search for a online block explorer that has a raw view for blocks.

Preferably in the getblocks.bin binary format as hex string.

It would also be great if it had testnet network.

A bonus would be if the explorer is open source somewhere.

Edit:

For bitcoin its something like this
In json and here in hex.

I am searching for the "block_complete_entry" data of a single block, there should be also pruned tx data in there.

struct block_complete_entry
  {
    blobdata block;
    std::vector<blobdata> txs;
    BEGIN_KV_SERIALIZE_MAP()
      KV_SERIALIZE(block)
      KV_SERIALIZE(txs)
    END_KV_SERIALIZE_MAP()
  };

https://xmrchain.net (source: https://github.com/moneroexamples/onion-monero-blockchain-explorer).

Open source and has various methods to call. E.g.:

https://xmrchain.net/api/rawblock/1637504

Bonus, yes has testnet to.


What is so different about RandomX from other attempted ASIC-resistant mining algorithms? I read that the original Cryptonight hashing algorithm was optimized for the L3 cache of a modern CPU, giving CPUs as large of an edge as possible. I've also heard that RandomX effectively turns a modern day CPU into the most effective mining tool - to me, these sound the same.

How is RandomX so different, as to be ASIC-resistant? What does it do that's so fundamentally different from X11, Cryptonight, Scrypt, and others, such that it can be called truly ASIC-resistant and not another algorithm that will fall in a couple of years?

Cryptonight really only exploited one particular feature of modern CPUs, fast cache access. When it was designed, it was thought ASICs would be at a significant disadvantage because of their general lack (at the time) of access to fast memory. It was also not imagined the ways in which ASIC manufacturers could overcome the memory constraints.

RandomX however is designed to exploit the very nature of CPUs: general purpose computing. CPUs are designed to be able to run a wide variety of tasks, this is their feature if you will. The algorithm largely achieves this by being dynamic - random programs are created and executed by a virtual machine. For an ASIC to be competitive, it would essentially have to be an improved CPU, for which everyone would benefit, not just Monero.

Quite frankly, no other algorithm (including the broad list you want compared), go anywhere near the lengths that RandomX does to favor general purpose CPUs. Probably the closest design-wise out there is ProgPoW, which targets the features of GPUs.


How to convert Bitcoin mnemonic to Monero mnemonic? I am working on a crypto wallet which supports both Bitcoin and Monero. Wallet first generates a BIP-39 mnemonic and after that mnemonic is used to generate a public and a secret key for Bitcoin.

I want a similar thing for Monero but using the same Mnemonic which is of 12 words. I know how to generate wallets keys and address from 13-word Mnemonic using mymonero-core-cpp code.

So in short my question is that "Is there a way to convert the BIP-39 12 words mnemonic to 13 words mnemonic by appending the checksum or whatever Monero uses in its protocol"?

Assuming your wordlists match, the 13th word is just a checksum word. You concatenate the prefixes of the main 12 words, run a checksum over it, mod that with the word count and, hey presto, you have the index of the word to use as your 13th word.

Example from luigi1111 here which shows creating the checksum

Note that the official Monero wallets makes use of 25 word versions nowadays as these offer much higher entropy.


Anyway to watch my own monero address without installing the full monero wallet? Is there a way to monitor my monero address without the need to download the entire blockchain? And I don't want to constantly paste my private view key into a block explorer to see it neither. I want it to be able to just click a button or visit a link and be able to see my balance from time to time. What solutions are there?

You can download the official GUI and set up a view-only wallet, without downloading the entire blockchain. You would still have to sync your wallet with the network. This doesn't take a long time.
Connecting to remote node - so you don't have to download the blockchain.
Set-up a view-only wallet


Am i destroying my pc by mining? I have AMD FX 8350 on msi 970 motherboard. Monero mining seems to be good at 400 H/s. With the stock heat sink and no overclocking will this damage my components or degrade the performance.

Will reducing threads to 4 make it more durable?  (At 4 cores im getting around 350H/s)

Should i buy a better cooling system? Current temp is around 55 to 60 °C

In addition i have a huge air supply. Even though it looks stupid its working. (In the picture)

Running at full utilization is likely to degrade performance, especially for the CPU. It's difficult to say by how much, though.

Luckily, your temperatures are pretty solid at only 60 degrees. This is around the maximum I would recommend for constant use.

Since the 8350 has an 8MB cache, it's actually optimal for you to mine with 8/2 = 4 threads. Any number greater than this is most likely wasted. You can reduce it below 4 to reduce CPU use.


Trying to get private view key from hash seed generated from mymonero mnemonic (13 words) in Python I tried to get a private view key but somehow I can't get it to work. However, I do manage to get the hash of the seed from the hexadecimal seed created from the mnemonic.

The hexadecimal seed was obtained from here for testing. I seem to manage to get the correct hash of th seed by keccak_256 hexadecimal seed.

I read many sites state that private view keys can be obtained by sc_reduce32 the hash of seed. But I don't get it working.

Here is my code; it runs in Python 2.7.

Can someone show me how to get the private view key from the hash of the seed?

If possible I prefer the method to work in Python 2.7 since most of my previous work was done in that Python version.

Your sc_reduce32 function was using the wrong value to reduce by, and you had not reversed the endianness of your bytes. Here is working code:

import sha3

l = 2 ** 252 + 27742317777372353535851937790883648493

def reverse_byte_order(hex):
    if(len(hex)%2==1): hex = '0' + hex
    return "".join(reversed([hex[i:i+2] for i in range(0, len(hex), 2)]))

def sc_reduce32(key):
    return reverse_byte_order("%x" % int((int(reverse_byte_order(key), 16) % l)))

def cn_fast_hash(hex):
    k = sha3.keccak_256()
    k.update(bytearray.fromhex(hex))
    return k.hexdigest()

hexadecimal_seed = "852249bca4446e65501cc7f8338027ec"
hash_of_seed = cn_fast_hash(hexadecimal_seed)
private_spend_key = sc_reduce32(hash_of_seed)
private_view_key = sc_reduce32(cn_fast_hash(hash_of_seed))

print "Non-standard Seed = ", hexadecimal_seed
print "Normalized Seed   = ", hash_of_seed
print "Private Spend Key = ", private_spend_key
print "Private View Key  = ", private_view_key


How can the network or monero community reduce the txpool size? Does increasing hashrate help? Or does it simply rely on waiting for the blocksize median to increase?

Not really. Rapid growth in hashrate would only be slightly useful short term until the difficulty retargets which happens rather fast. This is only because you'd reduce the time between the blocks slightly so you may be able to squeeze a little more over some time period.

It really relies on blocksize median increasing, which is happening slowly - right now at 70kB. However, there's a problem with the current set-up (due to size of a single typical TX relative to min. blocksize) which ought to be fixed in the next HF. See here for more details: How can block size grow over time when miners are incentivised to keep size small?


Is there MRL-0007? What topic is it about? I see from a previous post that MRL-0001~0005 are complete and published while MRL-0006 and MRL-0008 are still ongoing, but I've never heard anything about MRL-0007. Is there such a thing? If so, what issue does it address?

Based on this comment from fluffypony it appears that MRL-007 was skipped and does not (currently) exist.

  @kenshi84 any chance you could do a formal write-up and submit it to the Monero Research Lab repo for us to publish? It would go as MRL-0006, and the current WIP that is MRL-0006 would be moved out to 7 or something.

@kenshi84 confirmed a willingness to begin working on a formal write up (to become MRL-006) for the topic in the one-time receiving address idea that led to this pull request

  @fluffypony Sure, I'd be honored to be able to publish at MRL:)

The previous MRL-006 will be renamed MRL-007 and Difficulty Adjustment Algorithms in Cryptocurrency Protocols research will continue.


Where can I find the selection of the decoys (stealthy addresses) when constructing a transaction? When constructing a new transaction, I have reached the function cryptonote_core/cryptonote_tx_utils.cpp/construct_tx_with_tx_key() and I am trying to understand where the decoys came from? How and when are they selected?

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

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


dev pool socket error I have been experiencing a problem with my mining rig and was wondering if anyone has ran into the same problem. I am using XMR-stak 2.2.0 and sometimes XMR-stak restarts because my hashes drops below the threshold that I set.  In my logs I noticed that when this happens, I get the following error:

  Dev pool socket error - mining on user pool

Does anyone know what this means?

from reading this issue thread it appears to be hardware related make sure to double check your equipment and overclocks if you have them also if you're exceeding the wattage of your PSU.


Can I identify the true input of a transaction as the spender on an explorer? What information would I need to discern my true input to the transaction from the mixins? Can this be easily done?

Every transaction declares a key image for each ring of outputs being spent, where that key image relates to the true output being spent.

The only way to know whether that transaction is spending your output is to check whether any of the key images declared are key images for outputs you've previously received.

The only way to know which outputs you've previously received is to scan the entire blockchain for any outputs destined for your wallet.

Since explorers typically will not replicate this 'wallet-like' functionality for scanning the entire blockchain with your private view key to discover outputs you own, this would not be possible to do with an explorer.

If you have previously used a wallet to discover which outputs you own, you could make a note of the key images of any outputs you own (this requires knowledge of both your private spend and private view keys). You could then compare those key images with those presented by an explorer.


Simple website to check Monero balance Similar questions have been asked often, but no satisfying answer so far...

Is it possible to (read-only) check the balance of a Monero address with only providing the address and ViewKey (no Payment Id or SpendKey or whatever), and without first installing/syncing software for it?

Just a simple web interface for this?

Something like mymonero.com would be nice, but for the login on it, you always have to provide the SpendKey as well (or the LoginKey), which makes it risky to lose the funds.

Is it possible to (readonly) check the balance of a Monero address with only providing the address and ViewKey (no Payment Id or SpendKey or whatever), and without first installing/syncing software for it? Just a simple web interface for this?

Yes, that's possible

Private wallet

For a private wallet, turns out this is really a good question! I don't have an answer for you but maybe this post will help you: How can I check the balance of a Monero paper wallet?

exchange wallet:

A very easy way would be to grab an API of some exchange (for example Binance), have your funds there and by accessing a website you can check the balance of your wallet.

So since an exchange gives you access to your balance, you could easily use that to show that balance somewhere.


Calculating the cost of a double spending attack A toll booth owner wants to accept zero confirmation transactions (because waiting for confirmation would lead to long lines at the toll booth) and open the gate as soon as the transaction (with integrated payment ID) reaches the mempool.

Is there a way the toll booth operator can calculate the cost of a double spending attack against be Monero network based on current network hashrate?

The toll booth operator knows there are some tech savvy drivers who regularly use his road (that are smart enough to know how to attempt a double spend). However he wants to measure that impact against the lost revenue that will result if long lines cause some drivers to start taking alternative routes.

Accepting cash or credit cards is not an option because some of the users of his toll booth frequently never carry cash and value their privacy too much to use credit cards.

It depends heavily on how much work has to be (provably) redone. If you act upon a transaction that has just hit the txpool, there is not work yet to be redone by a miner, so it's cheap. Same as for bitcoin. This assumes that the attacker is able to send a tx to your pool, while sending a different tx spending at least an identical input to mining pools. As monero and bitcoin use the same PoW system, attacks against either are the same.

Now, with your particular example, you probably have a way to determine who cheated, so you can either ban them from your toll gate in the future, or force them to use a queue where payments wait for one confirmation, which should in itself be a good incentive not to cheat :)


is the Bitmain X3 compatible with Monero Will Bitmain X3 be able to mine Monero?

No the hardfork changed the algorithm to prevent ASIC usage.

Source


How does it affect my node when I get the message: "No incoming connections - check firewalls/routers" I don't have any ports open and I get the message: "No incoming connections - check firewalls/routers". What does this impact on my node? Can I still connect to my node locally and use its RPC interface?

What does this impact on my node?

By not forwarding ports, you are preventing access for external nodes. Note however, nodes that you initiate a connection with can still sync from your node.

  Can I still connect to my node locally and use its RPC interface?

Yes.


Block height and notification procedure for v7+ forks Has the block height for the v7 fork been decided upon yet? What procedure will be used to provide notice exchanges, mining pools and merchants about the upcoming fork.

Starting with v7 will their be any wallet based notification systems for upcoming forks?

Has the block height for the v7 fork been decided upon yet?

As can be seen from the code here, there's currently no block height set yet for the v7 fork. It'll likely be somewhere in March 2018 though. However, there has also been some talk about pushing it back 1-2 months to accommodate more review for single-output Bulletproofs.

  What procedure will be used to provide notice exchanges, mining pools and merchants about the upcoming fork.

Typically the core-team and the community will try to make exchanges, merchants, services, mining pools, miners, and (economically sensitive) nodes aware of the upcoming hard fork. This is done by spreading awareness of the hard fork on social media, sending out emails, or by other means of contact. In addition, I typically put up a hard fork megathread (example [1], [2]). These threads basically inform users and asks the community to spread awareness of the hard fork.

  Starting with v7 will their be any wallet based notification systems for upcoming forks?

A few weeks before the fork, the daemon will start notifying the user of an upcoming hard fork. In addition, if the user hasn't upgraded after the fork, the daemon will notify the user that there's a new version available.


How does the "--check-updates" parameter of monerod work? The monero daemon has this option:

  --check-updates arg (=notify)         Check for new versions of monero:
                                        [disabled|notify|download|update]

I tried running my node with --check-updates update, but no update/notification takes place.

$ ./monero-v0.10.2.1/monerod --check-updates update

status shows up to date.

Height: 1275771/1275771 (100.0%) on mainnet, not mining, net hash 57.12 MH/s, v4, up to date, 8(out)+21(in) connections, uptime 0d 23h 59m 3s

Is it implemented/working?

If yes, how does it work?

The --check-updates option has four subcommands:

update     subcommands: check (check if an update is available), download (download it if there is), update (not implemented)

check: check for updates, but do nothing beyond printing a notification
download: download any update
update: run the newly updated version

The last one is not implemented yet, only the first three are at the moment.

When you run status, the "up to date" comment does not refer to whether a new version is available: it relies on the timing of last known fork to determine whether there should be an update by the current time. It could be replaced with the new --check-updates method, now that it exists. Feel free to open a bug on https://github.com/monero-project/monero/issues mentioning that fact, and pros and cons may be discussed there.


Cold transaction signing with GUI Is it possible to safely complete a cold transaction signing process with the official GUI instead of the CLI process described here?

Try this:

Create a view only wallet (settings page)
Open view wallet and create a transfer, save with "Save tx" button
In original wallet, click "Sign tx" on send page and select the file
in view wallet, click "Submit tx" and select the signed tx file


What is the status of web mining? Now that I have my pool up and running, how long before we get a production web Miner?  I'm trying to get non-techies start mining and a great start would be a web Miner.

Thanks,

There's no official web miner for Monero. Some developers wrote code for that purpose but that has nothing to do with the Monero project itself.

There are services where one may register, paste code to their website, and make visitors mine for them (and for miner authors, as they charge quite high fees).

Regardless of the origin of the code, this way of mining is highly inefficient. The mining algorithm is designed to run as machine code on bare CPU/GPU chips, not as high-level language in virtualized environment of a browser. Of course, WebAssembly optimizations may drive the overhead lower but don't expect it to be profitable unless you have HUGE traffic on your website.

And when you deal with huge traffic, the last thing you want is to scare people off by running some shady code on their computers, which spins up fans, eats batteries and usually generates anti-virus warnings. Having many visitors, you'll certainly find a better way to monetize that traffic.


Differences between Masari web wallet and Mymonero A beta version of a web wallet for Masari (a Monero fork) have been released (https://medium.com/@c5d1c1a0c9a8/5e7de6f4919a). It is presented as "Cryptonight’s first client side web wallet". How are its mechanisms different from Mymonero web wallet? What is done server-side on Mymonero but not on this new site?

Disclaimer: I am the creator of this new wallet

When you use MyMonero, your private view is sent to the server (with your public address), but not the private spend keys.
It means the server is able so see your balance(EDIT: the server is able to see the incomming amounts, not the outgoing amounts. It means the balance will be off), and the server is precomputing everything for your browser and your browser is doing the final work : checking that the tx are really yours basically.

In the wallet i'm working on with the Masari team nothing is sent to the server.
The server is only here to send you the blockchain and that is it. All the decryption is done on your browser. Yes it's using more resources of your computer, but we will never be able to even check your balance.
I'm working on improving the performance, but they are currently more than reasonable. In theory, the website could even connect directly to a RPC daemon (not done due to performance issues, but we could and our first prototype did that).

If you need more clarification, i will follow this post and i'm also available on the main masari discord or reddit/r/masari

Gnock


Why Are Mining Passwords 'x' In any of the 'get started mining' type sites, I see that password is always x. In xmr-stak, it seems to suggest putting in 'mostly empty or x' as a password. Does this really mean I should be using some default one-character password, or am I just misreading?

It's a placeholder, since they're unused (or, at least, I am not aware of any mining software which uses that password), even though they're part of the JSON communication between miner and pool. You can put whatever you like, x or otherwise.


What will be the effect on monero if bitcoin deploys schnorr sig's? Let's take this question two ways.

Assuming Schnorr requires a hard-fork - let's take into consideration what that could do to bitcoin in context of this question.
let's assume schnorr is deployed without major problem or impact to bitcoin (seems unlikely but would be very nice to see the community band together for something so fundamentally bitcoin as privacy). Does monero lose all it's advantage over bitcoin?

Sorry if this is too discussiony,trying to be more question oriented but the speculative nature of the question lends itself more to discussion.

I didn't know about Schnorr. But Imo, it's not the same lvl of privacy that monero offers.
Plus, there's no interest for bitcoin to include anonimity in transactions. Bitcoin still suffers of its pseudo-anonimity. Even in 2016, there's still dumb political/financial reviews that point the btc as "money laudering, terrorist act, drugs implication" ...
Btc has never been and will never be an anonymous crypto and the fact that the btc is still rising and consolodidating after years is directly related to the fact that the bitcoin comunity want to prove his credentials as a concurrent of fiat currency.

Sorry for my english


Using exponentiations instead of ECC multiplication in computing Stealth address I'm developing a variant of Monero.

Is it possible to change the ECC multiplication rA  with r^A  of the stealth address term Hs(rA)G+B.
And of course also the multiplication by G.

IMHO it should  be interchangble but I want to be sure.
What other modification do I need to make? Is it breaking any security assumptions?

The reason we use ECC multiplication (which I'm sure you know is not just regular integer multiplication) is that it is a homomorphic trapdoor function.

You could potentially use unpadded RSA to achieve the same objective https://en.wikipedia.org/wiki/Homomorphic_encryption

However, the reason that all cryptocurrencies use ECC and not RSA is that RSA public keys in particular are enormous compared to the size of ECC public keys. RSA would make for an unnecessarily bloated blockchain.

There is another way of interpreting your question though. Sometimes people use the term exponentiation to describe the exact same operation that Monero usually describes as scalar multiplication. In which case, you could use the alternate notation. Just note that the equivalent of rA is written as A^r and not r^A.


monero-wallet-rpc: Transfer from sub-account? Is there an API call to transfer Monero from a specific sub-account?

"Transfer" API (https://getmonero.org/resources/developer-guides/wallet-rpc.html#transfer) does not appear to ask for a sub-account index/tag.

For example, I have 3 sub-accounts and want to send Monero from the 3rd one only, so that the other 2 sub-accounts have their balances remain unlocked.

Alas, the developer guides are, at the time of writing, a bit outdated. Fortunately, however, a number of people are working on ensuring they will be up to date soon. One of those people is oneiric and I'll use the example from his repository to answer your question. See below for an updated guide on the Transfer RPC command:

  Transfer

  Send monero to a number of recipients.

  Inputs:

  destinations - array of destinations to receive XMR:

  amount - unsigned int; Amount to send to each destination, in atomic units.
  address - string; Destination public address.

  account_index - unsigned int; Transfer from this account index.
  subaddr_indices - array of unsigned int; Transfer from this set of subaddresses.
  fee - unsigned int; Ignored, will be automatically calculated.
  mixin - unsigned int; Number of outpouts from the blockchain to mix with (0 means no mixing).
  unlock_time - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
  payment_id - string; (Optional) Random 32-byte/64-character hex string to identify a transaction.
  get_tx_key - boolean; (Optional) Return the transaction key after sending.
  priority - unsigned int; Set a priority for the transaction. Accepted Values are: 0-3 for: default, unimportant, normal, elevated, priority.
  do_not_relay - boolean; (Optional) If true, the newly created transaction will not be relayed to the monero network. (Defaults to false)
  get_tx_hex - boolean; Return the transaction as hex string after sending
  get_tx_metadata - boolean; Return the transaction metadata.

  Outputs:

  fee - Integer value of the fee charged for the txn.
  tx_hash - String for the publically searchable transaction hash
  tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
  amount_keys - List of strings for the amount keys.
  amount - Amount transferred for the transaction.
  tx_blob - Transaction as hex string if get_tx_hex is true
  tx_metadata - Transaction metadata string if get_tx_metadata is true.
  multisig_txset - Set of signing keys used in a multisig transaction (empty for non-multisig).

  Example:

$ curl -X POST http://127.0.0.1:18082/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"transfer","params":{"destinations":[{"amount":100000000,"address":"9wNgSYy2F9qPZu7KBjvsFgZLTKE2TZgEpNFbGka9gA5zPmAXS35QzzYaLKJRkYTnzgArGNX7TvSqZC87tBLwtaC5RQgJ8rm"},{"amount":200000000,"address":"9vH5D7Fv47mbpCpdcthcjU34rqiiAYRCh1tYywmhqnEk9iwCE9yppgNCXAyVHG5qJt2kExa42TuhzQfJbmbpeGLkVbg8xit"}],"mixin":4,"get_tx_key": true}}' -H 'Content-Type: application/json'

{
  "id": "0",
  "jsonrpc": "2.0",
  "result": {
    "fee": 48958481211,
    "tx_hash": "985180f468637bc6d2f72ee054e1e34b8d5097988bb29a2e0cb763e4464db23c",
    "tx_key": "8d62e5637f1fcc9a8904057d6bed6c697618507b193e956f77c31ce662b2ee07",
    "amount_keys":[],
    "amount": 300000000,
    "tx_blob": "",
    "tx_metadata": "",
    "multisig_txset": ""
  }
}


Monero blockchain fetch blocks by date I'd like to use the Monero API. Is there a REST API method which can fetch Monero blocks by specific date?

Thanks
Sajudeen

No.

However, you can get blocks by height, and height maps fairly well to date. There are on average two minutes per block since height 1009827, and one minute per block before that. It's then a simple conversion.

To get blocks by height, use the getblockheadersrange, which has start_height and end_height parameters.

Example:

curl -X POST http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_block_headers_range","params":{"start_height":1545999,"end_height":1546000}}' -H 'Content-Type: application/json'


How to connect to a node with cpuminer For training purposes, I am trying to connect to a private node using the cpuminer-multi but it fails.

Is this command line correct?
cpuminer -a cryptonight -o stratum+tcp://xxx.xxx.xxx.xxx:18080 -u wallet -p x -t 3 --userpass A:B

Daemon runs as: ./monerod --rpi-login A:B

The node ran and synchronized and I made sure that port 18080 is open
on the client, i am trying to connect to the node but I get :
                      Signature mismatch and
[2017-12-27 15:33:53] stratum_recv_line failed
[2017-12-27 15:33:53] ...retry after 10 seconds

On the node, I get Signature mismatch, connection will be closed

Is there something missing?

That command is not correct.

You are connecting a cpuminer, which talks pool language by default, to a daemon's P2P port, which speaks monero P2P.

You need to change two things:

connect to the RPC port (18081 by default)
tell the cpuminer to not talk pool language but dameon RPC language using daemon+tcp instead of stratum+tcp

Not all miners know how to talk to the daemon instead of to a pool, so yours may not be able to. If not, use another miner (or use a more recent version).

For more information, see Solo GPU mining (partly applies to solo CPU mining).


Zero to Monero: What are base keys? I have been reading the very well written Zero to Monero book. I am currently at Section 3.1, page 25. The paragraph introduces a term 'base key' from out of nowhere and it has gotten me confused. Is this the same as the EC curve generator G? How is this different from the public key?

The curve generator is just another name for the curve's base point, which is denoted as G.
In Z2M 3.1, each "base key" J is simply a curve point you are going multiply by a scalar k (a private key) to get a new curve point K (a public key).
Put simply, the proof discussed is about creating a proof to show you know the k multiplied by each J to create each K, and you can prove this without revealing k.
Or annotated first line from 3.1: "It is often useful to prove the same private key (scalar k) was used to construct public keys (each point K) on different ‘base’ keys (each point J)"


Error on initial monero daemon start with *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL I just installed and started up the daemon on windows and im getting the error:

19192   INFO    global  contrib/epee/src/mlog.cpp:145   New log categories: *:WARNING,net:FATAL,net.p2p:FATAL,net.cn:FATAL,global:INFO,verify:FATAL,stacktrace:INFO
Height: 47601/1388220 (3.4%) on mainnet, not mining, net hash 895.47 kH/s, v1, up to date, 8(out)+0(in) connections, uptime 0d 0h 1m 21s

That's not an error. Looks normal to me :)
The first line is starting with INFO, and it's just telling you which kind of events will get logged.

Also, I suggest creating a shortcut to monerod.exe, and adding --block-sync-size 10 to it, as below. Seems to be a cure-all for slow sync.


Can the Monero daemon bind to a UNIX socket? Is there an option to bind monerod to a unix socket?

I know there is rpc-bind-ip but it doesn’t seem to be happy with sockets.

No. Currently only TCP/IP sockets are implemented.


How to determine number of used subaddresses after restoring from seed? Suppose I created and published i=10 subaddresses from which 5 already received a payment.

After restoring my wallet from the 25-word seed, how would I know how many subaddresses were already generated?
How could I avoid giving out the same subaddress to two different individuals? Do I need to keep track of the amount of subaddresses generated to ensure to use the i+1th subaddress after restoring from seed? (The same issue also applies to using the same wallet from multiple devices, the wallets somehow need to keep i in syn)

An option to anonymously publish the number of generated subaddresses in the blockchain would be a nice feature to avoid reusing i. This'd allow my wallet to know exactly with which i to continue.

This could work as follows:
An optional transaction field (let's call it hid) could be added which allows to store up to eg 8 byte of anonymous data. Whenever creating a new subaddress, a new transaction to myself is issued including the current value of i (number of subaddresses) encrypted using a special format (or, prefix) in this field.
Upon sync (eg after restoring from a seed), my wallet checks the most recent transaction whose hid field is not empty, decrypts its value, checks if it matches the special format (or, prefix) and immediately knows how many subaddresses were already generated.

When restoring a wallet from the seed, the wallet automatically expands the internal subaddress table such that it can recognize incoming transfers to new subaddresses. If you type address all, the wallet displays a list of subaddresses in use so far:

[wallet 9xLMUj]: address all
0  9xLMUjRpNfEQLoYwogkmiBg9H6XP18mJ3UJphkvhWo9SB3vwbJFSryNfVz6vJFigYwLadki17xHQG7qsxQnnZPuPC1XvpHq  Primary address (used)
1  Bh7S7kAEQmdQ8eGjnySzb7XShEZdYVScQ8FXtbXgfoQF5NkuNH5FnTSXzfehhbnrypWuwUqtbi28YFKy2aVcqy68FGUfAwk   (used)
2  BfSTksPWaf1iJLJGHtyg6DRzWERXQA1coJTJULcwh8BBZuNgvyYcG2NYaJBQnf1d9yDAXExZaJH46AGMehGJiZCv3MsR1vg   (used)
3  BYTWmE5EXGwB2HHfN2vXvkY5U8Aj5bQgQBqyk33Hf9akfN3cFTpumyNh3kFkYLtvfjgxGgwvhDDPSBy6oR8Jh4bXSrYMaMi   (used)

The (used) flag indicates that the subaddress has ever received any funds so far. You can use address new to generate a new address.

If you generated a new subaddress and gave it to someone else, but that person didn't send money to that address, then the information about you giving the address to that person doesn't get recorded in the blockchain, so it's impossible for you to recover that information from the blockchain when you restore the wallet from seed.

I don't think it's practical to make a special transaction every time you issue a new subaddress just for the sake of recording the information about your new address in the blockchain.


Why are hard forks planned every 6 months? As more code is written and the Monero technology advances (perhaps the pace of development will slow), will the need for biannual hard forks remain? Is there a particular purpose behind this?

Every single piece of security software you run has to try force security updates, otherwise you could be running a trivially compromised piece of software. Most closed-source software, and even open-source software that isn't as sensitive to tampering as Monero, use things like mailing lists to notify you of a new major version. Lots of them also use in-app notifications, which users have become adept at ignoring or clicking away.

Having regular, timed hard forks forces users to update the very sensitive piece of security software they're running, and benefit from all the patches, bug fixes, and reduced exploit vectors in newer versions. Being able to add functionality, and know that the whole network has access to it in-step with each other, is just icing on the cake.

In future when Monero is more stable we'll go down to annual hard forks, as mentioned elsewhere in these answers. If the core Monero daemon gets to a point where it's particularly secure and particularly stable (eg. the code has been formally verified, and been in production for years with little or no incidences) we can even go stretch them out further.


Why does Monero seem to only use the first six decimal places (and not the full 12)? My current balance always shows the last six decimal places as 0 (eg: "Balance: 1.234567000000). Is this just me, or does Monero not currently use all 12 decimal places? Can this change in the future with a hard fork or something?

That's simply because you just don't have a fraction of a balance that small. When you think about it, roughly estimating that 0.1 XMR = $1, then 0.000001 = $0.0001, and so very seldomly is anyone dealing with prices smaller/more precise than that.

A second thing to consider... Technically, Monero (like Bitcoin) doesn't use decimals at all. It uses what are usually referred to as atomic units, or in Bitcoin lexicon "satoshis". Technically,

1 XMR = 1 000 000 000 000 atomic units
1 BTC = 100 000 000 atomic units

Or in other words, you don't have 1.234567000000 XMR, you have 1 234 567 000 000 atomic units.

This is so that all outputs are integers, which helps ensure that input and output math is exact (integer math is exact, while floating point math can get muddy). The "coin" conversion to decimals is just to make things easier to use for humans.

When you think about it in atomic units, it doesn't make sense that decimals "aren't used". Of course they are! They are what make you have 1.234567 XMR and not 0.000001234567 XMR!


Monero GUI will not build on Debian 8 Git cloned monero-core, installed the required dependencies.

Running ./build.sh yields:

/usr/bin/ld: cannot find -lwallet_merged
/usr/bin/ld: cannot find -lepee
/usr/bin/ld: cannot find -leasylogging
collect2: error: ld returned 1 exit status
Makefile:367: recipe for target 'release/bin/monero-wallet-gui' failed
make: *** [release/bin/monero-wallet-gui] Error 1

I then tried changing monero-wallet-gui.pro to include the contrib directory:

INCLUDEPATH +=  $$WALLET_ROOT/include \
                $$PWD/src/libwalletqt \
                $$PWD/src/QR-Code-generator \
                $$PWD/src \
                $$WALLET_ROOT/contrib \
                $$WALLET_ROOT/src

Since the libraries it cannot find, are in the contrib directory. Still errors.

Debian 8 64bit
Qt 5.9.2
cmake version 3.0.2
gcc version 4.9.2 (Debian 4.9.2-10)

I'm guessing this is some sort of include or $PATH error, as it cannot seem to import these libraries. Any ideas?

Edit: apart from not being able to build via build.sh, it also does not build via QtCreator.

Monero will be built only if GCC 5 and G++ 5 are installed in your system.


What PoW hashing algorithms did Monero historically use? Originally, Monero used the Cryptonight PoW algorithm, then started modifying it to thwart ASICs getting large parts of the network hash rate.

What is the timeline of these changes ?

Monero's genesis block dates back from April 2014. The first PoW change was in 2018.

The full history is:

| block   | date       | PoW algorithm
|---------|------------|--------------
| 0       | 2014-04-18 | Cryptonight (retroactively CNv0)
| 1546000 | 2018-04-06 | Cryptonight variant 1 (CNv1)
| 1685555 | 2018-10-18 | Cryptonight variant 2 (CNv2)
| 1788000 | 2019-03-09 | Cryptonight variant 4 (CNv4)
| 1978433 | 2019-11-30 | RandomX

Monero switched to RandomX in November 2019, a new PoW algorithm not based on Cryptonight, which is based on the premise of random code execution.


Doing both CPU and GPU mining on a machine? Is it possible for two miner softwares to be running on a machine? One doing CPU mining, other doing NVIDIA GPU mining? Can you share the names of the miners you use and the little about the hardware you have?

Yes this is totally doable. Just make sure to leave some CPU breathing room for the GPU miner application to feed the GPU with data by limiting the maximum threads used by the CPU miner.


Minimum and maximun number of mixin right now? Is it a hard rule that there needs to be 11 ring signatures right now for a transaction to take place right now?

Ring-size is now fixed at 11. So, 10 decoys (mixins) and 1 real.


Will a large and sustained increase in Monero transactions resolve the current issues of the dynamic block size penalty function? The fee algorithm has not readjusted as intended following the dramatic increase in median transaction size which came with the upgrade to RingCT transactions.  A conclusion reached on the subject has indicated that the dynamic block size penalty function does not work as intended when a typical transaction is close to the median block size.

Would the existing block size penalty function work as intended if the median block size increased due to a higher number of transactions on the network and sufficient fees to pay for the necessary block size increase?  What magnitude increase to the current transaction rate of 100 tx/hour would be required to achieve a satisfactory result?

Maybe it would.

In theory, to smoothly function as "originally intended" would mean the median block size would somehow have to grow to the point where one TX is 1.2% of the median, which translates to a block size of roughly 1250kB (15kB being a safe size to fit a "typical" transactions). The magnitude would then be around 2500TX/hour or 0.7TX/s. It's a long way to reach that level of adoption.

However, one needs to be careful when evaluating such things, because in practice we could see something entirely different.

The 1.2% is a direct consequence of arbitrary constants chosen in the current min. fee formula. If it was chosen such that it's, for example, 2.4% then the tipping point would be at 625kB but the min. fee would be double then what it is now.

I'd say it would happen way sooner because external factors such as market price and user willingness to pay some fee also have an impact on this. For example, currently you need around x20 min. fee multiplier to start the dynamic process. If everyone offered the x20 fee, then it would be viable for the miners to start expanding blocks for 20%, which is just enough to squeeze in one TX at 60kB median, 2 TX-es at 120kB median and so on. Note that with current prices that would mean everyone is willing to offer around 5$ to place a single TX! If it meant 0.3$, then we probably wouldn't be talking about this problem right now :)

For example, if we consider 0.3$ as some fee which everyone is willing to pay by default, and model with a flat market price, the tipping point where 0.3$ gets you 1 TX more is at about 280kB block size, as seen in the chart below:

Note: W_0 = 101.2%, W_T= (15kB) / (median block size) + 1.

But what if the price also grows? Then we could end up having the same problem all over again. Long-term, if the price should raise with block size slower than linear, then it's likely we will never have this problem again in the future. It's just getting out of the trench which seems hard, and this trench shouldn't have been there in the first place!

So it's not just the formulas which could help as dropping the market price 20-fold would also fix the problem. One could argue that if the network gets clogged and the price drops as a consequence the problem would fix itself.

But I digress. If there was a consistent stream of TX-es coming in, then even with the current set-up the block size would be able to creep up slowly until it crosses over some point where the min. fee would drop so the users are willing to use higher multipliers. One could argue that was not the intended way the system should work and that at any given moment some would be willing to use at least some lower multipliers. Problem is that right now anything <20x does nothing of significance, because of the TX size issue. The dynamic block size is really there to accommodate some peak usage times and not have to wait days for backlog to be cleared.

Thing is, the RCT HF introduced bigger TX-es but did nothing to address these dynamics at the same time. I understand that there was the thought that people would still be using non-RCT TX-es which would alleviate the problem but the reality is that more than 99% of TX-es are RCT even though it's not mandatory!

At the end, we see that it's also about the price of min. fee at which miners can do something. The current min. fee gives no incentive to miners to do anything because of the TX size issue and yet it could already be considered pricey. Nobody wants to pay x20 the min. fee and make miners do something because the min. fee is high enough by itself. So really, there are many aspects to this and many possible solutions. We'd want to pick the one which would let us forget about the problem forever :) However, as the project is still in some early stage, these kind of details must be worked out and evaluated as we go on. The only worthwhile data which could be used as a guideline is the one for Bitcoin, and Bitcoin is also in some early stage, having its own problems and trying to work them out.


What is a key image? When a transaction is made with monero there is a 'key image' in the transaction info. what is this exactly? is it like the diffie-hellman exchange to create the one time addresses?

Monero are always sent to the one-time destination (public key) P. In the CN whitepaper, the corresponding private key is referred to as x.

When you're spending, you're combining your P with a couple of other ones in a ring signature and signing with the x. Only one of the Ps will be spent, but the ring signatures hide which one. In other words, the signature is verified by all of the Ps, and it looks like any of their corresponding private keys could have signed the transaction, thus obfuscating the sender. But how do we know you're not double-spending? We need a way to prove that the private key used to sign was not used before, without revealing which one it is. That is where the key image comes in:

I = xHp(P)

Let's also take a look at how the one-time key-pair is derived:

P=xG

Since I is a one-way function of x this means that:

Nobody can recover the public key from the key image and identify the signer;
The signer cannot make two signatures with different I’s and the same x which in effect means you can spend your P only once.


How can I integrate Monero in a website using PHP? Can anyone please tell me how I can integrate Monero using PHP?
Do I need to install monero wallet first?
I am using this Monero library, but don't know how to login to Monero by using it.
If I need to install a Monero wallet first, then how I can install it on my host?
I have searched a lot about this on the internet but failed to find anything

The file you linked is not a Monero library. At most, all it shows is a couple of examples of calling the RPC methods, for which is an easy task in any coding language. Just run the monero-wallet-rpc application and call its HTTP methods.

If you want/need to use a library that wraps that up further, for example because you don't know how to call a HTTP based API or don't want to work with parsing JSON, there are a few Monero PHP wrapper libraries, such as monero-integrations/monerophp.

Regardless what library you use (if any), you will first need to create a wallet file (either with monero-wallet-cli or the Monero GUI wallet), then on your server, run monerod (the daemon) and monero-wallet-rpc (the thing that exposes RPC methods to work with your wallet).

Another approach is to use a payment processor, such as GloBee. These have their own API but allow you to accept payments without needing to run a daemon or wallet RPC, useful if you don't have a hosting environment that you can install/run your own applications on.


Is there any way to mine using an integrated GPU? Is it possible to mine with an AMD APU's integrated GPU, or Intel's integrated graphics processors? If so, any idea what kind of hashrate one can get?

Wolf's GPU miner works with AMD integrated GPUs too. I tested it several months ago. https://twitter.com/hyc_symas/status/695730032291917825

On the A10-4600M each CPU thread got about 50H/s. In my laptop, the dGPU gets about 90H/s. The iGPU gets around 40H/s. These numbers are from memory and I may be misremembering.

With the current AMD driver on Linux, you can only have one GPU active at a time, so you can't enable one for driving the display and use the other for number crunching. It's quite inconvenient. (The open source driver lets you run both GPUs at once, but it lacks support for OpenCL 2.0.)

Correction: not sure if due to an update, but the current AMD driver now allows both GPUs to be active at once. (2016-10-14)

I've just tested with 2 out of 4 CPU threads, plus both the dGPU and iGPU active at the same time. Overall hash rate is slower than just using the CPU + dGPU without the iGPU. This is because the iGPU competes with the CPU for RAM access. With just 2 CPU threads and dGPU, the dGPU gets 89.5H/s and the CPU threads get 50H/s each. Adding the iGPU to the mix, the iGPU gets only 13H/s, the dGPU drops to 87.5H/s, and the CPU threads drop to 23.6H/s.

This is in an Asus N56DP laptop with A10-4600M APU and Radeon HD 7730M dGPU.


How is the Monero network hashrate calculated and how is it different than bitcoin? I've read somewhere that the Monero network hashrate is only an estimation based on the current network difficulty. Is this different than the conventional (bitcoin-like) network hashrate measurements, and if so, why?

Bitcoin uses a different difficulty adjustment algorithm than Monero, which consequently leads to a different estimation of the network hashrate. More specifically, Bitcoin uses a fixed window of 2016 blocks, which should take approximately 2 weeks with 10 minute blocks. After this window the difficulty is retargeted such that, on average, the block time (the time it, on average, takes to mine a block) is 10 minutes. That is, if the window took less than 2 weeks to complete, the difficulty will be adjusted upwards and vice-versa.

By contrast, Monero uses a rolling window of the last 720 blocks. In essence, for each new block the difficulty is being retargeted based on the last 720 blocks. Thus, for example, block 1000720 will take blocks 1000000 to 1000720 for the difficulty calculation, whereas block 1000721 will take blocks 1000001 to 1000721. In addition, to mitigate the effect of dishonest and inaccurate timestamps, 20% of the outliers are cut-off for the calculation¹.

A rolling window will reduce the variance of block time, because the network is able to adjust the difficulty every block. By contrast, with Bitcoin it would be possible to push out 5 minute blocks for a week or 1 hour blocks for 12 weeks until the difficulty retargets.

Sources:

https://cryptonote.org/whitepaper.pdf


Error: basic string:_M_replace_aux This is an error from the past however renaming the wallet fails with error: no keyfile found. if i rename both I get error:_M_replace_aux.

Am I doing it wrong?  What cache files are people referring to?

Ubuntu OS throughout the wallets life.

Thank you!!!!! (in advance)

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

Totally assbackards from what people said. Sorry.


In LOKI, how do you tell how much loki is being staked? In Loki, how do you tell how much is being staked on the network? And how long does staking and unstaking take when you first activate it?

Given that the staking requirement is a known value, and the number of nodes active on the network is also known, you can calculate the minimum amount of Loki being staked on the network by simply multiplying the staking requirement by the node count. Let's take today for example:

Staking requirement (27137) * node count (465) = 12,618,705 Loki

The process of staking itself is explained in detail here https://lokidocs.com/ServiceNodes/SNFullGuide/

With the introduction of Infinite Staking, unlocking a Service Node takes 15 days. If your node goes down, it'll be unlocked in 30 days.


How can I compile a mining software for my mac computer that uses an NVIDIA GPU? Please, don't ask me why.

I have a computer that runs OS X on it with a NVIDIA GPU card. I would like to compile my mining software for GPU mining, but I don't find any info at all about this on the internet.c'est

Thanks.

You want tsiv's ccminer-cryptonight.

I've never successfully compiled it on macOS, and don't have a mac desktop anymore to test it on, but I believe a few recent Issues on github answer this question...

https://github.com/tsiv/ccminer-cryptonight/issues/9

https://github.com/tsiv/ccminer-cryptonight/issues/6

Your best bet is to try to follow the build instructions there, maybe follow up on one of those issues if you have similar problems, and see what you can do. If you succeed, you should post the full compile process here as the "Accepted Answer" unless someone else answers better than me before then.


View monero subaddress balance without monero-wallet-cli Is there any way to

get the balance of a subaddress, with only the view key (programmaticly) and no monero-wallet-cli installed? At best a js lib. Assume it is connected to an open node.
run the monero-wallet-cli on an aws lambda?

I know of the monero-javascript project.
https://github.com/monero-ecosystem/monero-javascript

Sadly I can't run a wallet-rpc node on my own.

You cannot get a balance with a view key alone. All you can do with a view key is view incoming transactions - not get a wallet balance. To determine a wallet balance you also need a way to know what is spent. With a view-only wallet, you can import key images which will enable you to view a balance. Thus, you would first have to create a view-only wallet using the view key and then import key images.
For programatic access you would use the monero-wallet-rpc, not monero-wallet-cli. In theory you could run this on AWS Lambda but whichever tool/host you used, you still need access to a daemon also.


Why is the monero GUI synchronization starting from zero every time the daemon boots up? http://prntscr.com/hpeep2

As you can see, even though I have a 34 GB file, it is telling me that I have over 1M blocks left to synchronize. But earlier today it was telling me there are about 20K left. What is the solution to this?

The current GUI looks like its synchronizing twice. This may be what you are seeing.

Basically, your client first needs to synchronize with the network. This is the downloading and verification of the blockchain.

Then, your client needs to scan the blockchain with your private keys. This is probably what you are seeing.


What is the fee when using xmr.to service to send xmr to a bitcoin address? I know xmr.to mentions that they don't charge a fee, but I'm sure they make a cut on the exchange rate some how. How does xmr.to make a profit? They have a fee their system if you exchange more, your fee is higher. What is this fee %?

XMR.TO admin here.

I do not know where you saw that XMR.TO does not charge a fee in general, this is not true and to the best of my knowledge we never made such statements.
However it is true we do not charge anything on small orders. The reason is that, unlike all competitors, we are a Monero-specific service: we launched in 2015 for both building a business AND serving the Monero community, maximizing Monero's utility immediately rather than waiting for sufficient merchants acceptance in the future. We are also involved with Monero on an individual basis since inception and our interests align very much with those of the Monero community at large.
As a result, we typically offer better prices than anyone else for everyday amounts. Currently the service is "free" for amounts up to 0.5 BTC.

We do charge something for larger orders (larger than 0.5 BTC). It is difficult to tell you how much, basically the percentage of the cut is proportional to the amount you exchange. This is why we specify in the FAQ that you need to enter the amount you want to exchange to find out about the specific rate we offer for this specific amount at that time.


Does Monero still use the Cryptonight algorithm since the fork? Ok, I have read about the Lithium Luna release that's supposed to be ASIC resistant.  However, I'm unclear about whether Monero is now using a new hash algorithm.  Is Monero still using its CryptoNight algorithm or some variant?

Broadly speaking, it is still using the Cryptonight design, but the v7 hardfork included some modifications to the algorithm to brick the current generation of ASICs.

See https://github.com/monero-project/monero/pull/3253/files

All v6 mining software, including pools, have had to upgrade to match the new algorithm.


If the Monero started with rCT, would it be needed to have any part of the codebase handling dust? I mean there is so much code in Monero handling situation that involve any dust.
Is it just for backward compatibility or would it be needed even if the Monero started with rCT?

I know about 2 types of dust:

1) dust as an output lower than fee
As far as I understand it, it just seems unnecessary to call it dust, because the only special thing is that this "dust" can't be sent on it's own, nothing more, right?

2) dust as some amount that was unmixable before rCT
If the Monero started with rCT, it would not happen to have this kind of dust, right?

So in the end, if the Monero started now with rCT, it could remove all the dust code, right?

It would indeed not be needed.

For the "below its weight in fee" case, the wallet could just avoid spending those outputs.


Installed the monero gui client for windows. How do I join a pool to mine? IS there a step by step tutorial on how to join a monero pool to cpu mine? I just installed the monero desktop client for windows.

The official monero client only supports solo mining as far as I know. You will need to download a different CPU miner for monero to connect to a pool. xmr-stak-cpu is a good one.
You can find that here: https://github.com/fireice-uk/xmr-stak-cpu

I've always used linux for cpu-miners and compiled it from source. It looks like there is a windows .exe file hosted there, but you still might need to install a c++11 compiler.


Any plans of Monero based documentary? I have seen the documentaries Rise and Rise of Bitcoins and Bitcoin Gospel, any plans of a documentary on Monero?

I have not heard of one. But eventually, if Monero continues to grow and get mass adopted, a documentary is inevitable.

They'll have plenty of material to work with, considering our origins are as mysterious as Bitcoins. Yet we also have the whole CryptoNote/Bytecoin scam drama to add, alongside thankful_for_today's shenanigans, so it could be a colorful flick.

Personally I'm hoping for some silky narration by Fluffypony over HD coastal vistas of Plettenberg Bay.


I want to run a node. Is it better for the community for me to run it at home, or on a VPS? As the title says, I want to run my own node. I own a few domain names, so I was considering running it on a VPS and pointing a domain to it. However, that will cost me about $20/month for the VPS+storage.

For $250-300, I can get a ZBox CI329 or an Intel NUC, then add a 256GB SSD and 4GB RAM. After a year or so, the mini PC option would pay for itself.

My questions are:

Is one option "better" than the other for the community?
Is there a risk to my home network if I run the node at my house? I know I need to forward a port, but does the monerod software encrypt all traffic?

Firstly, welcome!

  Is one option "better" than the other for the community?

This is a somewhat nuanced question unfortunately. It depends firstly on whether you are planning to open up you node for inbound connections (thus allowing others to sync blocks from you) and whether you also open up the RPC (so other user's wallets can use your node as a remote node). If this is your intention, then the more bandwidth you make available, the "better" it will be. So when judging which route to take, factor in your bandwidth costs too.

  Is there a risk to my home network if I run the node at my house?

If you run an open node (so having p2p and RPC open for inbound connections), the biggest "risk" is having your bandwidth exhausted. To mitigate this, you can make use of the daemon options:

--limit-rate-up arg (=-1)             set limit-rate-up [kB/s]
--limit-rate-down arg (=-1)           set limit-rate-down [kB/s]
--limit-rate arg (=-1)                set limit-rate [kB/s]

You should also make use of the --restricted-rpc flag, or use a separate port for public usage via --rpc-restricted-bind-port, to ensure you don't leak any unnecessary, private information.

  I know I need to forward a port, but does the monerod software encrypt all traffic?

Traffic is not encrypted (although there are some SSL features coming in the next release). If you goal is to offer an extra layer of privacy for users, consider running the node as a tor/i2p hidden service. That would be very helpful as there is easier tor/i2p integration coming in the next release too - and the more nodes we have on privacy networks, the better.

I hope this is useful and thanks for considering taking the extra step for the ecosystem.


Has bandwidth usage or data transferred when mining or hosting a full node increased since the introduction of RingCT? I've recently started hosting a handful of nodes on my home internet connection and mining to a pool from these machines, it seems as though my internet connection has become a lot slower and a lot of data has been used up.

It's possible that this is simply an issue with my ISP, but I wanted to find out if anyone knows the amount of data uploaded/downloaded when hosting a full node and when mining now that RingCT has been implemented. Have bandwidth and data transfer requirements increased?

I'm aware of the 'limit' command in monerod, which I have set to 100, but sometimes it still seems like the Monero nodes and mining processes are taking up a lot of bandwidth.

Yes, RingCT transactions are much bigger than non-RingCT transactions. The monthly blockchain growth has already more than doubled in comparison to December 2016, when RingCT hasn't been enabled yet.

Why are you hosting more than one full node at home? You just need one full node and all your local machines can connect to it via local network.


What is the origin of Monero and its relationship to Bytecoin? I've read many things about the origin of Monero and its relation to Bytecoin and other cryptonote coins. What are the details of Monero's origin?

Edited to add: this question / answer is not a duplicate. This is an attempt to narrow down the scope of this question & answer series which is on hold because its too broad.

The answer to this question is long and any shortening doesn't do the question justice.

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

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

The Alleged CryptoNote/Bytecoin Story

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

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

Immediate Red Flags

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

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

Indisputable Facts

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

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

signature in the v1 whitepaper

signature in the v2 whitepaper

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

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

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

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

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

XMP properties for the v1 whitepaper

XMP properties for the v2 whitepaper

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

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

pdfTeX 1.40.14 pushed to source repo on Feb 14, 2014

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

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

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

And Now for Some Conjecture

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

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

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

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

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

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

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

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

Batshit Insane

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

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

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

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

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

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


How are the various tx-extra types/formats used? Reading the code, I see that transactions can contain an unlimited number of tx_extra_field items.

tx_extra_field is defined in src/cryptonote_core/tx_extra.h as a union of a few possible types, identified by a type byte:

#define TX_EXTRA_TAG_PADDING                0x00
#define TX_EXTRA_TAG_PUBKEY                 0x01
#define TX_EXTRA_NONCE                      0x02
#define TX_EXTRA_MERGE_MINING_TAG           0x03
#define TX_EXTRA_MYSTERIOUS_MINERGATE_TAG   0xDE

Further, nonces can be one of:

#define TX_EXTRA_NONCE_PAYMENT_ID           0x00
#define TX_EXTRA_NONCE_ENCRYPTED_PAYMENT_ID 0x01

What are each of these types/formats used for? Also, what is the purpose of padding?

Thanks

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

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

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

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

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


What is the most common way currently being used to create web based wallets? I'd like to know the most common way people are creating these web wallet services for monero. I know there's a few different languages being used as well as bash/shell scripting, but can anyone give me a summary of exactly how it works, or point me to a website that has that info?

To much to explain, but in short: frotnend sends private viewkey and address to the backend. Backend scans the blockchain, using your viewkey and address for incoming transactions to you. At the same time, it makes guesses about possible outgoing transactions. Only guesses are possible, because backend does not have spendkey. Found your incomming txs are send to frontend along with possible spendings. The frontend, because it has spendkey, can filter out incorrectly guessed spendings, thus giving you the correct balance.

I can point you to full source code of a web wallet (OpenMonero) and its working example on testnet

https://github.com/moneroexamples/openmonero
http://139.162.32.245:81

It contains both fully open sourced frontend and backend, so that you can even host it yourself. The backend has a lot of comments explaining what it does. You can also make issues on github if something is not clear.


How do I reduce the apparent memory usage of Monero? We all know that LMDB uses a memory-mapped database, so the actual usage of memory by the monero network service process (aka monerod, monero daemon) is very minimal (once network synchronization has completed).

More information on caching and memory mapping can be found here.

Despite these facts, it is sometimes advantageous to reduce the apparent usage of memory by the monerod process. How can one reduce the apparent memory usage?

As per comments, Monero memory usage is not an issue here, it's about understanding Linux memory. The usage is not "high" and there is no reason to change anything for those that simply do not understand Linux memory.


How to build MyMonero wallet for Windows? I would like to test the MyMonero lightweight wallet on Windows in its current state of development.

Can someone please walk me through how to package the source code to test the wallet on Windows? I understand that this is a pre-release and I don't plan to put any money in the wallet.

I found this. Ideally, I would just like a simpler and perhaps more verbose version of this.

The MyMonero desktop app is built with Electron. To build it you need to install NodeJS and NPM.

After installing Node, download the source code from GitHub, open command prompt and go to the directory containing the source code, run npm install to grab the dependencies and then npm start to launch the program.


What are bulletproofs? I have heard that Monero transactions are relatively large, and that Bulletproofs will make Monero transactions smaller. Can someone give a high-level overview about what these are, and how they effect Monero?

Most of the information below is taken from this post on the GetMonero website.

To understand bulletproofs, you need to first understand what a range proof is. According to the post:

  A range proof allows anyone to verify that a commitment represents an amount within a specified range, without revealing anything else about its value.

Monero uses the range proof in RingCT to secure the amount being sent in a transaction. Without range proofs, the amount sent could be hidden, but a sender could cheat by making coins out of thin air. Thankfully, range proofs prevent this from happening.

Bulletproofs are a more efficient type of range proofs. You can view a copy of the research paper for free here. The research paper defines Bulletproofs as follows:

  ...a new non-interactive zero-knowledge proof protocol with very short proofs and without a trusted setup; the proof size is only logarithmic in the witness size. Bulletproofs are especially well suited for efficient range proofs on committed values...

Bulletproofs offer substantial improvements when using multiple outputs. With current Monero range proof technology, transaction sizes scale mostly linearly depending on the number of outputs (eg: 1 output = 7kB, 2 outputs = 13kB). With bulletproofs, these scale logarithmically instead (eg: 1 output = 2kB, 2 outputs = 2.5kB).

As the post notes, there are two ways bulletproofs can be implemented in Monero:

  This gives us two related types of bulletproofs: single-output and multiple-output. A transaction with multiple outputs can either include several single-output proofs or one multiple-output proof (which is smaller than the separate proofs).

The former brings substantial improvements, and the latter brings a little more than the former. The post estimates the following performance improvements:

  With our current range proofs, the transaction is around 13.2 kB in size. If I used single-output bulletproofs, the transaction reduces in size to only around 2.5 kB! This is, approximately, an 80% reduction in transaction size, which then translates to an 80% reduction in fees as well. The space savings are even better with multiple-output proofs. This represents a significant decrease in transaction sizes. Further, our initial testing shows that the time to verify a bulletproof is lower than for the existing range proofs, meaning speedier blockchain validation.

Bulletproofs will be deployed in the October scheduled protocol upgrade. It has been live in testnet since the beginning of 2018.