MoneroMonero is a digital currency that is secure, private, and untraceable.
https://getmonero.org
A note on fees<p>Lately, a common reoccurring complaint has been that fees are too expensive. Whilst we don't disagree with that statement, we have to thoroughly analyze the situation first. Furthermore, the notion of devs having to release new binaries with lower fees is myopic, because (i) it'd merely kick the can down the road, (ii) changing the constants or formulas requires a hard fork, i.e., they are enforced on a consensus level, and (iii) constantly intervening would be contradictory to our grass-roots, decentralized nature.</p>
<p>Let's start by comparing Monero's per kB fees to the per kB fees of other (hybrid) proof-of-work coins. Fees per kB for a typical transaction (2 inputs + 2 outputs):</p>
<ul>
<li><strong>Bitcoin:</strong> ~$26.90</li>
<li><strong>Ethereum:</strong> ~$2.91</li>
<li><strong>Litecoin:</strong> ~$0.10</li>
<li><strong>Dash:</strong> ~$0.07</li>
<li><strong>Monero:</strong> ~$0.24</li>
</ul>
<p>As you can see, the per kB fee of Monero is fairly low. However, due to the high transaction size, the absolute default fee (in $ terms) is quite high. Note that the transaction size is this big due to Monero's inherent default privacy, i.e., the range proofs, which mask the amount values, make up ~12 kB of a single transaction. RingCT, however, was absolutely necessary to strengthen the privacy of the network. More specifically, there were a lot of privacy "leaks" when Monero didn't mask amounts yet. Fortunately, <a href="https://getmonero.org/2017/12/07/Monero-Compatible-Bulletproofs.html">Bulletproofs</a> will reduce transaction sizes by at least 80%.</p>
<hr />
<p>To thoroughly analyze the situation, let's continue with examining the constants. We start with examining the penalty function and the dynamic block size algorithm. The formula is as follows:</p>
<p><strong>Penalty = BaseReward * ((BlockSize / M<sub>N</sub>) - 1)²</strong></p>
<p>The new reward is:</p>
<p><strong>NewReward = BaseReward - Penalty</strong></p>
<p>Where:</p>
<ul>
<li>M<sub>N</sub> is the median of the block size over the last N blocks, with N being <a href="https://github.com/monero-project/bitmonero/blob/master/src/cryptonote_config.h#L57">100</a> in Monero</li>
<li>BlockSize is the size of the current block</li>
<li>BaseReward is the reward as per the emission curve or where applicable the tail emission</li>
<li>NewReward is the actual reward paid to the miner</li>
<li>The maximum allowed block size is 2M<sub>N</sub></li>
</ul>
<p>Note that the formula of the BaseReward is defined <a href="https://bitcointalk.org/index.php?topic=583449.0">as follows</a>:</p>
<p><strong>BaseReward = 2 * ((S - A) * 2<sup>-20</sup> * 10<sup>-12</sup>)</strong></p>
<p>Where:</p>
<ul>
<li>2 is the adjustment factor for the switch to two minute blocks</li>
<li>S is the initial number of atomic units is = 2<sup>64</sup> - 1</li>
<li>A is the current circulation, which can be found <a href="https://moneroblocks.info/">here</a>. In addition, the current circulation (emission) displayed on the block explorer has to be multiplied with 10<sup>12</sup> (Monero uses 12 decimal places) to convert it to atomic units.</li>
</ul>
<p>Note that the minimum block size limit is 300 kB. Thus, miners are able to construct blocks up to 300 kB without incurring a penalty. In other words, aforementioned penalty function only "kicks in" for blocks bigger than 300 kB.</p>
<p>Now, a default transaction in Monero, i.e., one that has two inputs and two outputs, is approximately 13.2 kB. Let's plug this into the formula:</p>
<p>Assuming a current <code class="highlighter-rouge">BaseReward</code> of 5.7 XMR:</p>
<p><code class="highlighter-rouge">Penalty</code> = (5.7 * ((313.2/300)-1)², which yields ~0.011 XMR.</p>
<p>Note that the <code class="highlighter-rouge">BaseReward</code> was significantly higher 6-12 months ago, which translates to a higher penalty.</p>
<p>Now, miners need incentive to expand the block size. Therefore, the fee from including one additional transaction (above 300 kB) needs to outweigh the penalty. Otherwise, miners will simply fill blocks until 300 kB and exclude any other transactions, which would lead to a congested network and a large mempool. In sum, the current default fee (~0.013) was set to incentivize miners to include one additional transaction in their blocks without losing revenue.</p>
<p>As you can see from aforementioned penalty function, the penalty will go down when the base reward decreases. Furthermore, as can be easily spotted by graphing the function, the penalty function is more "lenient" in the beginning of the function. This means that any decrease in transaction size translates to a bigger than equal decrease in fees. Put differently, for example, an 80% reduction in transaction size could lead to an 90% reduction in fees. Let's play around with the formula to get some more concrete numbers. Assuming single-output bulletproofs, the transaction size of a typical transaction would be ~2.5 kB. Now, let's also assume that we want to incentivize miners to expand the block size with two transactions without losing revenue. That is, they will be able to include two additional transactions (above the minimum block size limit) without the penalty outweighing the fees. Plugging in the numbers, we get:</p>
<p><code class="highlighter-rouge">Penalty</code> = (5.7 * ((305/300)-1)², which yields ~0.0016 XMR or ~0.0008 XMR per typical transaction.</p>
<p>Reducing the transaction size with approximately 80%, but keeping the same minimum block size limit might be a bit blunt. Therefore, it could be that the minimum block size limit would be lowered to 100, 150, 200, or 250 kB. Let's plug in the numbers again:</p>
<p><code class="highlighter-rouge">Penalty</code> = (5.7 * ((255/250)-1)², which yields ~0.0023 XMR or ~0.00115 XMR per typical transaction.</p>
<p><code class="highlighter-rouge">Penalty</code> = (5.7 * ((205/200)-1)², which yields ~0.0036 XMR or ~0.0018 XMR per typical transaction.</p>
<p><code class="highlighter-rouge">Penalty</code> = (5.7 * ((155/150)-1)², which yields ~0.0063 XMR or ~0.00315 XMR per typical transaction.</p>
<p><code class="highlighter-rouge">Penalty</code> = (5.7 * ((105/100)-1)², which yields ~0.014 XMR or ~0.007 XMR per typical transaction.</p>
<p>You can graph all the outcomes by setting M<sub>N</sub> to <code class="highlighter-rouge">x</code> and <code class="highlighter-rouge">BlockSize</code> to <code class="highlighter-rouge">x+5</code>.</p>
<hr />
<p>One might ask oneself, how does the dynamic fee algorithm come into play? First, to clarify, the default fee is set to account for the penalty in a bare minimum case. That is, a case where miners expand the block size with one additional transaction above the minimum block size limit. More specifically, in the current situation it would mean creating a block of 313 kB (to reiterate, the minimum block size is 300 kB). Once the median block size (of the last 100 blocks) significantly diverges from the minimum block size, the dynamic fee algorithm comes into play.</p>
<p>Let's examine the dynamic fee algorithm:</p>
<p><strong>Fee = (R/R<sub>0</sub>) * (M<sub>0</sub>/M) * F<sub>0</sub></strong></p>
<p>Where:</p>
<ul>
<li>R is the base reward</li>
<li>R<sub>0</sub> is the reference base reward (10 XMR)</li>
<li>M is the block size limit</li>
<li>M<sub>0</sub> is the minimum block size limit (300 kB)</li>
<li>F<sub>0</sub> is 0.002 XMR</li>
</ul>
<p>As a practical example, a few moons ago the median block size increased to approximately 400 kB and thhe default fee went down to ~0.0095. As we can see from the formula, this approximately matches the theoretical fee. That is:</p>
<p><code class="highlighter-rouge">Fee</code> = (6.5/10) * (300/400) * 0.002 = 0.00975</p>
<p>Basically the inverse of the percentage increase of the median block size (against a base of the minimum block size) translates to the percentage reduction in fees. More specifically, a 600 kB median block size, which is a 100% (or factor 2) increase translates to a 50% (1/2) reduction in fees.</p>
<p>So why did the significant price increase not lead to a significant reduction in absolute fees, i.e., fees in XMR terms? Well, basically, the factor increase in price was significantly higher than the factor increase in usage. Furthermore, the median block size needs to be constantly above 300 kB in order for the dynamic fee algorithm to work properly. Moreover, the algorithm was designed to correlate with price, but, as we can see, price is imperfectly correlated with usage. In sum, whilst usage has grown a lot, it hasn't grown as much as the price and therefore fees (in XMR terms) have not declined yet.</p>
<hr />
<p>From combining the penalty formula and the dynamic block size formula with the dynamic fee formula we can infer that a higher minimum block size limit (for example, 300 kB) leads to lower initial default fees, but fee reduction (by the dynamic fee algorithm) being somewhat "slow". By contrast, a lower minimum block size limit (for example, 150 kB) leads to higher initial default fees, but faster fee reduction.</p>
<p>In conclusion, whilst fees are currently too high, they, most likely, won't be anymore in the future. In addition, more research has to be conducted on the topic of the minimum block size limit, because, preferably, we'd like to use a limit that doesn't require future intervention anymore.</p>
<hr />
<p><strong>A few remaining notes:</strong></p>
<ol>
<li>
<p><em>Median</em> fees were taken from <a href="https://bitinfocharts.com/">Bitinfocharts</a>.</p>
</li>
<li>
<p>A more in depth analysis (by ArticMine) of the penalty function can be found <a href="https://bitcointalk.org/index.php?topic=753252.msg13591241#msg13591241">here</a>.</p>
</li>
<li>
<p>The penalty function in the original <a href="cryptonote.org/whitepaper.pdf">CryptoNote whitepaper</a> is somewhat different. More information can be found <a href="https://monero.stackexchange.com/questions/1067/block-reward-penalties-and-dynamic-block-size">here</a>.</p>
</li>
<li>
<p>Code details and the actual implementation of the dynamic block size algorithm can be found <a href="https://github.com/monero-project/monero/blob/master/src/cryptonote_basic/cryptonote_basic_impl.cpp">here</a>.</p>
</li>
<li>
<p>Code details and the actual implementation of the dynamic fee algorithm can be found <a href="https://github.com/monero-project/monero/commit/82dbba10d467e28e56929e2e7f3b1f04d4635da4">here</a>.</p>
</li>
</ol>
Mon, 11 Dec 2017 00:00:00 +0100
https://getmonero.org/2017/12/11/A-note-on-fees.html
https://getmonero.org/2017/12/11/A-note-on-fees.htmlMonero Compatible Bulletproofs<p>Here is a quick update on Bulletproofs and their role in Monero. Bottom line: they're awesome, they work, the fees are lower, and they're moving into testnet.</p>
<p>Monero's confidential transactions hide the amounts involved. To ensure that inputs and outputs balance properly in a way that can be verified by anyone, we use commitments that have useful algebraic properties. However, this isn't enough. We also need to ensure that each amount is a positive value that won't risk an overflow, and this is where range proofs come in. A range proof allows anyone to verify that a commitment represents an amount within a specified range, without revealing anything else about its value. Our current range proofs scale linearly in size with the number of outputs and the number of bits in the range (currently 64 bits), meaning they make up the bulk of a transaction's size. Further, this means that a transaction with multiple outputs needs multiple separate range proofs. Not great.</p>
<p>Thanks to a fantastic new paper by Bünz, Bootle, and others (<a href="https://web.stanford.edu/~buenz/pubs/bulletproofs.pdf">freely available here</a>), there is a more efficient way to handle range proofs. The size of a bulletproof increases only logarithmically with both the size of the range and the number of outputs. 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).</p>
<p>Let's look at the typical two-output transaction, where I send you some XMR and direct the change back to myself. 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.</p>
<p>We have working Java test code for bulletproofs available now (<a href="https://github.com/b-g-goodell/research-lab/tree/master/source-code/StringCT-java/src/how/monero/hodl/bulletproof">at this GitHub repo</a>) for both single and multiple outputs. The code for single-output bulletproofs has been ported to C++ by moneromooo (<a href="https://github.com/monero-project/monero/pull/2883">found at this pull request</a>) and will be available on testnet shortly. The code is being reviewed and tested thoroughly.</p>
<p>Multiple outputs raise some issues that need further thought. Because bulletproof verification is linear in the number of outputs (while the size scales logarithmically), an attacker could pack a transaction with many outputs; this tiny transaction would require low fees but would be computationally expensive to verify, opening the door to denial-of-service attacks. Because of this, we will need to adjust the fee structure away from transaction size and take into account the verification scaling. This doesn't mean fees go up, though! It just means that the fees will scale properly and in a safe way.</p>
<p>To avoid any problems, we're deploying bulletproofs in two stages. You'll first see only the single-output proofs. A two-output transaction will initially use two separate proofs, which still offers massive savings from what we have now. You'll see lower fees and faster verification times. We'll continue discussions about fee structure while we test multiple-output proofs, and later deploy them as a second stage. We want to encourage miners to use multiple-output proofs while being safe about fee scaling.</p>
<p>Overall, bulletproofs represent a huge advancement in Monero transactions. We get massive space savings, better verification times, and lower fees. If you're a fan of testnet, keep an eye out for bulletproofs!</p>
Thu, 07 Dec 2017 00:00:00 +0100
https://getmonero.org/2017/12/07/Monero-Compatible-Bulletproofs.html
https://getmonero.org/2017/12/07/Monero-Compatible-Bulletproofs.htmlLogs for the Monero Research Lab Meeting Held on 2017-11-27SPECTRE, multisig, Bulletproofs (range proofs), ZKStarks, ASIC resistance, and miscellaneousMon, 27 Nov 2017 00:00:00 +0100
https://getmonero.org/2017/11/27/logs-for-the-Monero-Research-Lab-meeting-held-on-2017-11-27.html
https://getmonero.org/2017/11/27/logs-for-the-Monero-Research-Lab-meeting-held-on-2017-11-27.htmlLogs for the Community Meeting Held on 2017-11-25Community highlights, Forum Funding System updates, RFC-HWALLET-1, Monero integrations, Malware Response Workgroup, Monero Coffee Chat, and miscellaneousSat, 25 Nov 2017 00:00:00 +0100
https://getmonero.org/2017/11/25/logs-for-the-Community-meeting-held-on-2017-11-25.html
https://getmonero.org/2017/11/25/logs-for-the-Community-meeting-held-on-2017-11-25.htmlOverview and Logs for the Dev Meeting Held on 2017-11-19Discussion of open PRs and issues, Bulletproofs, Monero Research Lab, Monero integrations, dedicated Monero hardware wallet, multisig, and miscellaneousSun, 19 Nov 2017 00:00:00 +0100
https://getmonero.org/2017/11/19/overview-and-logs-for-the-dev-meeting-held-on-2017-11-19.html
https://getmonero.org/2017/11/19/overview-and-logs-for-the-dev-meeting-held-on-2017-11-19.htmlWorkgroups and ResourcesA brief overview of workgroups in Monero and the resources that are provided for them to succeed.Mon, 13 Nov 2017 00:00:00 +0100
https://getmonero.org/2017/11/13/workgroups-and-resources.html
https://getmonero.org/2017/11/13/workgroups-and-resources.htmlLogs for the Monero Research Lab Meeting Held on 2017-11-13Educational outreach, multisig, Bulletproofs (range proofs), RuffCT, and miscellaneousMon, 13 Nov 2017 00:00:00 +0100
https://getmonero.org/2017/11/13/logs-for-the-Monero-Research-Lab-meeting-held-on-2017-11-13.html
https://getmonero.org/2017/11/13/logs-for-the-Monero-Research-Lab-meeting-held-on-2017-11-13.htmlLogs for the Community Meeting Held on 2017-11-11Community highlights, Forum Funding System updates, RFC-HWALLET-1, Monero December, upcoming meetups, growing involvement, and miscellaneousSat, 11 Nov 2017 00:00:00 +0100
https://getmonero.org/2017/11/11/logs-for-the-Community-meeting-held-on-2017-11-11.html
https://getmonero.org/2017/11/11/logs-for-the-Community-meeting-held-on-2017-11-11.htmlOverview and Logs for the Dev Meeting Held on 2017-11-05Discussion of open PRs and issues, Bulletproofs, Monero Research Lab, MyMonero, Kovri, multisig, and miscellaneousSun, 05 Nov 2017 00:00:00 +0100
https://getmonero.org/2017/11/05/overview-and-logs-for-the-dev-meeting-held-on-2017-11-05.html
https://getmonero.org/2017/11/05/overview-and-logs-for-the-dev-meeting-held-on-2017-11-05.htmlLogs for the Monero Research Lab Meeting Held on 2017-10-30Multisig, hash-based accumulators, blockchain protocols, quantum-hard shuffle PRNG, educational outreach, and miscellaneousMon, 30 Oct 2017 00:00:00 +0100
https://getmonero.org/2017/10/30/logs-for-the-Monero-Research-Lab-meeting-held-on-2017-10-30.html
https://getmonero.org/2017/10/30/logs-for-the-Monero-Research-Lab-meeting-held-on-2017-10-30.html