mirror of
https://github.com/monero-project/monero-site.git
synced 2024-12-23 12:09:49 +00:00
add 2018 year in review
This commit is contained in:
parent
999fe3abd6
commit
4c90e69842
1 changed files with 58 additions and 0 deletions
58
_posts/2019-02-12-2018-year-in-review.md
Normal file
58
_posts/2019-02-12-2018-year-in-review.md
Normal file
|
@ -0,0 +1,58 @@
|
||||||
|
---
|
||||||
|
layout: post
|
||||||
|
title: Monero - 2018 Year in Review
|
||||||
|
tags: [dev, core, crypto]
|
||||||
|
authors: dEBRUYNE, needmoney90
|
||||||
|
---
|
||||||
|
|
||||||
|
2018 has come to a close. Over the course of the year, Monero experienced a spectacular amount of ecosystem growth, greatly improved usability, and adopted critical protocol enhancements. This blog post aims to concisely review the most notable improvements that occurred, as well as some setbacks that were encountered.
|
||||||
|
|
||||||
|
# Setbacks
|
||||||
|
|
||||||
|
Despite the tremendous amount of progress the community and protocol experienced, as always, there were inevitable unforseen setbacks. The response to these obstacles is a critical part of any development cycle, as is the disclosure of how they were handled. Here is a short overview of the largest obstacles faced in the development of Monero in 2018:
|
||||||
|
|
||||||
|
First, in the beginning of the year, ASICs were detected on the network. The hashrate rose dramatically, until it was estimated that 80-90% of the network was specialized hardware, posing a significant danger to the security of the network. Monero's social covenant includes egalitarian mining, and the community pushed for [a modification to the proof-of-work algorithm](https://www.getmonero.org/2018/02/11/PoW-change-and-key-reuse.html) which could not run on the ASIC hardware. The PoW modification was implemented in the scheduled April 2018 protocol upgrade, and successfully managed to boot existing ASICs of the network. A second PoW modification was implemented in the scheduled protocol upgrade of October as a precaution and deterrent.
|
||||||
|
|
||||||
|
Second, two critical vulnerabilities were discovered in the client. The [the multiple counting bug](https://www.getmonero.org/2018/09/05/a-post-mortum-of-the-multiple-counting-bug-2018-09-05.html) would have allowed an attacker to create a transaction in which the transaction public key was included multiple times, causing the client to erroneously return that more funds were received than were sent. By utilizing this particular bug, an attacker would have been able to steal funds from organizations in the Monero ecosystem. Fortunately, the bug was confined to the accounting functionality of the wallet software, and so the protocol and coin supply were not affected. The [burning bug](https://ww.getmonero.org/2018/09/25/a-post-mortum-of-the-burning-bug.html) caused the software to not display a warning when burned outputs were received, allowing an attacker to burn funds of any recipient who allowed withdrawals following deposits. If exploited, it would have allowed a determined attacker to burn the funds of an organization's wallet, while only costing themselves transaction fees. Similarly to the multiple counting bug, this bug also did not affect the protocol, and would not have allowed an attacker to alter the supply. Both bugs were dealt with swiftly and professionally by the developers, following the [vulnerability response process](https://github.com/monero-project/meta/blob/master/VULNERABILITY_RESPONSE_PROCESS.md). It's imperative, however, that we learn from these events and seek improvements that could significantly mitigate the impact of similar bugs in the future.
|
||||||
|
|
||||||
|
A third obstacle involved Monero forks (such as Monero Original and Monero Classic) retaining the transaction output (TXO) set, jeopardizing the privacy of Monero users. For example, if Alice spends her output on the Monero Classic chain with ring A, B, C, D, E (where A is the real input) and thereafter spends the same output on the Monero chain with ring A, F, G, H, I (where, again, A is the real input), an observer could reasonably infer (by analyzing both chains) that A was the input being spent, i.e., the real input. Now, if another user used Alice's output A as a decoy output, their privacy was weakened, as the output was, due to Alice's behavior, rendered obsolete as decoy. Fortunately, the Monero developers added several mitigations (for example, a user now has an option to reuse their ring), rendering aforementioned analysis mostly obsolete. In addition, the user can utilize a special tool which ensures no provably spent outputs (e.g. Alice's output in previous example) are used as decoy outputs. This significantly reduced the impact of key image reusage, for example, in the event of a Monero user claiming their Monero Classic. Subsequent research by Justin Ehrenhofer confirmed their effectiveness.
|
||||||
|
|
||||||
|
# Fundamental
|
||||||
|
|
||||||
|
The most significant fundamental improvement of the year was Bulletproofs. Bulletproofs, which were successfully audited by two renowned security firms ([Kudelski](https://research.kudelskisecurity.com/2018/07/23/audit-report-of-moneros-bulletproofs-integration/) and [Quarkslab](https://blog.quarkslab.com/security-audit-of-monero-bulletproofs.html)) and one independent researcher (Benedikt Bunz), are a type of range proofs that are substantially more efficient than the now-deprecated Borromean range proofs. Range proofs ensure (with clever mathematics) that a malicious attacker cannot inflate the coin supply by sending a negative amount of money, leaving themselves with a positive balance.
|
||||||
|
|
||||||
|
The critical parts to optimize in a range proof are proof size and verification time - Bulletproofs blow Borromean range proofs out of the water in both categories. The transaction size of a typical old transaction (two inputs and two outputs) using Borromean range proofs was approximately 13kB, which has been improved by ~80% to about 2.5kB with Bulletproofs. Additionally, blocks of transactions that utilize Bulletproofs are about forty times faster to verify than the legacy Borromean range proofs, while individual transactions are nearly five times faster to verify. The improved transaction block verification speed affects people syncing the blockchain, while the individual transaction verification speed improvement predominantly affects 24/7 nodes that verify transactions in real time (including mining nodes).
|
||||||
|
|
||||||
|
A new feature that was implemented in 2018 was subaddresses. Subaddresses are similar to Bitcoin's HD (hierarchical deterministic) wallets, where a user can create an unlimited amount of public addresses that all correspond to the same private key. In Monero, these so-called subaddresses start with an 8. They are unlinkable to the main public address (the one that starts with a 4) and all other subaddresses. Subaddresses make off-chain linking significantly more difficult, greatly improving the privacy and experience of Monero users. Previously, unless a user was utilizing multiple different wallets, they had to give the same public address to every service they wanted to interact with. This allowed services to link users across services by cross-checking their addresses. Furthermore, users were potentially prone to linkage if they used the same address for multiple different transactions at the same service (for example, ShapeShift before it required KYC/AML compliance). Subaddresses render this kind of analysis mostly obsolete. In addition to subaddresses, a subaccount feature was implemented, allowing a user to create multiple accounts (with the option to generate multiple different subaddresses per account). This allows for separation of finances, as funds from different account cannot be combined (a user can still transact funds between account A and B though).
|
||||||
|
|
||||||
|
The year 2018 also saw the release of multi-signature transactions on mainnet. In Monero, multi-signature addresses are indistinguishable from regular addresses, and multi-signature transactions are indistinguishable from regular transactions. Senders cannot infer whether they are sending to a multi-signature address or a regular address. Similarly, recipients will not be able to infer whether the transaction he received came from a multi-signature address or a regular address. Initially, multisig was only implemented in an N/N and N-1/N form (where the numerator is the number of required signers and the denominator the number of total potential signers). Later in the year however, code was added to the Monero repository that allows users to set a custom number of required and total signers. At the end of the year, the initial version of the ([Multisig Messaging System](https://www.reddit.com/r/Monero/comments/9ubspw/try_out_a_future_of_easier_monero_multisig/) was merged into the Monero code repository. Following this, Exan Tech announced that it would be releasing a wallet with multisig support. Both projects aim to significantly improve user experience with respect to generating a Monero multi-signature wallet, and performing multi-signature transactions.
|
||||||
|
|
||||||
|
Numerous privacy improvements went live in 2018 as well. First, the ring size, which denotes the total size of the ring (i.e. the real input plus all decoy outputs), was changed to a static parameter. All users of the Monero network now use the same ring size when performing their transactions. This prevents users from consistently using an atypical ring size, which could be detrimental to their and others' privacy. A static ring size ensures that transactions are more homogeneous, and strengthens the privacy of all users on the network. Second, the (minimum) ring size was bumped from 5 to 7 in the scheduled protocol upgrade of April, and then to 11 in the scheduled protocol upgrade of October. Third, transactions are now also required to sort inputs, which mitigates wallet fingerprinting. Previously an observer could possibly infer which wallet a user used by looking at the way inputs were sorted. Fourth, the wallet now selects decoy outputs in accordance with a certain gamma distribution, which better mimics spending behavior of the user. This follows the recommendation of previous research on spending patterns.
|
||||||
|
|
||||||
|
# Usability
|
||||||
|
|
||||||
|
Usability was improved dramatically in 2018. Many new features were added to the official CLI wallet, such as ability to encrypt the 25 word mnemonic seed, the ability to lock an output, subaddresses and subaccounts, numerous features that improve coin control, and many others too numerous to list. The GUI wallet received a user interface overhaul and many user interface optimizations, greatly improving user experience. Additionally, both the CLI and GUI wallet enjoyed multiple performance improvements (most notably, wallet refresh speeds), bug fixes, and a new fee algorithm. To expand on the latter, the new fee algorithm ensures that the wallet uses a low priority fee when network activity is sufficiently low (as measured by transaction pool activity and size of the last ten blocks). This ensures that the user does not pay excessive fees for their transactions. The wallet will switch to default priority if network activity is relatively high, ensuring users do not experience significant delays. Both the [official CLI](https://monero.stackexchange.com/questions/8503/how-do-i-generate-a-ledger-monero-wallet-with-the-cli-monero-wallet-cli) and [GUI](https://monero.stackexchange.com/questions/9901/how-do-i-generate-a-ledger-monero-wallet-with-the-gui-monero-wallet-gui) added Ledger (a popular hardware wallet) integration. The daemon (monerod - the software the user utilizes to run their own local node) received tons of performance improvements and bug fixes. As a result, sync time and stability improved significantly. In addition, a new feature was added that allows the user to bootstrap via a remote node while the local daemon syncs the blockchain in the background. In other words, the wallet temporarily connects to a remote node until the local node is fully synced. This provides immediate access while retaining the benefits of running a local node. Lastly, a foundation was laid for blockchain pruning. Even though pruning in Monero is less efficient than pruning in Bitcoin-based cryptocurrencies, a substantial amount of data can still be pruned, and significant advancements have been made in that field.
|
||||||
|
|
||||||
|
[Monerujo](https://play.google.com/store/apps/details?id=com.m2049r.xmrwallet), a third-party Android wallet, added [Ledger integration](https://medium.com/@anhdres/how-to-use-monerujo-with-the-ledger-nano-s-758fff199bb4), as well as lots of meaningful performance and user experience improvements. [Cake Wallet](https://itunes.apple.com/us/app/cake-wallet-for-xmr-monero/id1334702542?mt=8), [MyMonero](https://itunes.apple.com/gb/app/mymonero-send-money-privately/id1372508199), and [X wallet](https://itunes.apple.com/us/app/x-wallet-monero-wallet/id1335168711?ls=1&mt=8) all released a Monero iOS wallet in 2018. Additionally, MyMonero released a set of desktop wallets suitable for [Linux](https://mymonero.com/downloads/linux), [MacOS](https://mymonero.com/downloads/mac), and [Windows](https://mymonero.com/downloads/win), Edge Wallet (a multi-coin wallet) added Monero support to their [iOS](https://itunes.apple.com/us/app/edge-bitcoin-wallet/id1344400091?mt=8) and [Android](https://play.google.com/store/apps/details?id=co.edgesecure.app) wallet, and XMRwallet released a [webwallet](https://www.xmrwallet.com/) with [TOR / onion support](http://xmrwalletdatuxds.onion/). Lastly, a pull request that enables [preliminary Trezor (T model) support](https://freedomnode.com/blog/113/how-to-setup-monero-wallet-with-trezor-model-t-ahead-of-schedule) was merged into the Monero code repository.
|
||||||
|
|
||||||
|
# Ecosystem
|
||||||
|
|
||||||
|
The Monero ecosystem grew and evolved over the course of 2018. First, a repository called the [Monero Ecosystem](https://github.com/monero-ecosystem/) was created that collects Monero related projects created and managed by members of the community. Examples are [pymonero](https://github.com/monero-ecosystem/pymonero) (which is a fork of monero-project/monero to deliver Python C++ bindings), [monero-java-rpc](https://github.com/monero-ecosystem/monero-java-rpc) (an implementation of the Monero wallet in Java), and [submit-tx-via-tor](https://github.com/monero-ecosystem/submit-tx-via-tor] (a bash script to submit raw Monero transactions over Tor). Second, the [Monero Malware Response workgroup](https://src.getmonero.org/2018/09/26/Introducing-the-Monero-Malware-Response-Workgroup-Website.html) was created by community members to aid people negatively affected by malware potentially mining Monero. Third, [the Monero Localization Workgroup](https://www.reddit.com/r/Monero/comments/9u64km/the_monero_localization_workgroup_is_one_year_old/) [switched to a new translation platform](https://www.reddit.com/r/Monero/comments/a3pfb3/the_translation_platform_pootle_is_now_ready_to/) named Pootle, which greatly simplified the translations process. Fourth, the [Monero Outreach workgroup](https://www.monerooutreach.org/index.php) was created with the aim of better marketing Monero to end-users by writing articles and short stories, creating a quick-facts sheet, creating videos, and making a guerrilla marketing toolkit. Fifth, the Mastering Monero book was released, which condenses a vast amount of Monero related information, thereby aiming to educate, in an easy to understand way, the interested reader about all things Monero. The book first appeared in hard copy format and costs approximately $20. A free e-book variant will be released in 2019. In addition, all proceeds from sales of the book will be donated to the Monero project. Sixth, [Monerostuff](https://monerostuff.com/) was created by a community member with the aim of teaching newcomers about Monero. Seventh, [Monerodocs](https://github.com/monerodocs) was created with the aim of improving documentation. Lastly, [Tari was announced](https://www.reddit.com/r/Monero/comments/8lgvw4/introducing_tari_a_decentralised_assets_protocol/), which is "a decentralised assets protocol that is going to be built on top of Monero. Think of it as something like coloured coins or CounterParty, but for Monero and a lot more scalable (ie. not using an embedded consensus mechanism)." Additionally, Tari labs was created to work on the Monero protocol. To quote the original announcement:
|
||||||
|
|
||||||
|
> **How does this benefit Monero?**
|
||||||
|
|
||||||
|
>Our investors believe in what we want to build with Tari, but they also believe in Monero as the world's leading private digital currency, and also as a powerful base layer upon which projects can be built. Because of this, we have capital that we are using to not only build the Tari protocol, but to enhance aspects of the Monero software stack and ecosystem.
|
||||||
|
>
|
||||||
|
>Consider three examples of areas the Tari Labs team will be focusing on over the next year:
|
||||||
|
|
||||||
|
> - Researchers will work with the Monero Research Lab to identify ways to improve Monero's block and transaction propagation. This will increase on-chain scalability for Monero, as well as speed up initial syncing of nodes. Tari Labs developers will also assist the Monero development community by implementing some or all of these improvements.
|
||||||
|
> - Tari Labs developers will work with Tari Labs researchers to create and implement an atomic swap mechanism that will initially allow for atomic swaps between Monero and other cryptocurrencies, such as Litecoin, but will also be used later on for atomic swaps between Monero and assets issued on Tari.
|
||||||
|
> - Developers at Tari Labs will work on a Lightning Network router implementation that supports both Bitcoin and Monero, allowing Monero to benefit from the added off-chain privacy that LN provides.
|
||||||
|
|
||||||
|
>In addition, Tari has plans for ways we can more directly support Monero development in the future through the creation of development hubs around the world, where people will be able to apply for grants that will let them work on Monero or Tari for a period of time. This concept, whilst still in its infancy and quite far away from inception, will provide people with the opportunity to contribute to the Monero codebase, research, and ecosystem on a more regular, full-time basis.
|
||||||
|
|
||||||
|
While there were many other improvements, they will be excluded from this particular blog for brevity's sake. For more a more granular list of historical updates, refer to [our Twitter account](https://twitter.com/monero). By scrolling through the tweets, you can get a concise overview of what happened during 2018.
|
||||||
|
|
||||||
|
All in all it was a spectacular (and eventful) year for Monero. Much was accomplished, but there is much more remaining to be done. The road to being the most private cryptocurrency we can be will be long and difficult, but we hope to see you continue on this journey with us!
|
||||||
|
|
||||||
|
P.S. The Monero Research Lab will be releasing their own year in review soon, which is why they have been excluded from this particular blog.
|
Loading…
Reference in a new issue