I love this idea, and support the CCS. I have known Anhdres through Monero-related collaborations since 2018, and we worked together on Mastering Monero, so I can attest to both the quality of the work and professionalism. Additionally, Anhdres has demonstrated excellent ability to illustrate Monero concepts very clearly, e.g. I believe this article is easily the most approachable explanation of Monero's accounts/wallets/etc structure: https://anhdres.medium.com/how-moneros-accounts-and-subaddresses-work-in-monerujo-4fa7df0a58e4
Thanks @anhdres, looking forward to the garden :)
Isthmus here, confirming that I have received from Rucknium the documents for the scientific review panel.
Results are in!
Internal Milestone 1 and Milestone 2 deliverables shared in comment above.
Milestone 3 deliverables are available for review:
I've been eagerly awaiting atomic swaps for years! Allowing permissionless entry to XMR via BTC will make Monero accessible for a much broader user base. Looks like a good proposal and solid team.
Hey everybody, wanted to share some updates. Please note that these are notes from incomplete research, expected to contain errors. Please see the technical writeup from Phase 3 for actual audit results.
Here's the table with a high-level overview of the security of current mechanisms against various quantum algorithms. (This is the deliverable for Phase 1)
Much of the writing is underway now, which includes vulnerability TL;DRs (Phase 2 deliverable), along with the technical writeup. The nontechnical docs will be distilled as we complete the formal writeups.
Monero's key-derivation mechanism is based on the hardness of the discrete log problem which enables an adversary to use a public address to derive the private key. This is because the scalar multiplication operation used to generate the public key is a one-way function for traditional computers, but can be reversed by an adversary leveraging Shor’s algorithm.
G*k → K is one way for traditional computer K,G→k is possible for a quantum computer via Shor’s
In general, the solution must meet the requirement of being a one way function that is not vulnerable to reversal through employing an algorithm efficiently on classical or quantum hardware. Possible replacements for this mechanism include public key cryptography systems involving lattice, multivariate, hash, code and supersingular elliptic curve isogeny based problems to generate public keys. This would essentially entail a replacement of current RSA protocols used to generate public keys with another protocol that is provably quantum secure, but has the drawback of larger key sizes and longer verification times. The most time and space efficient public key protocol that still allows the other privacy features of Monero to function effectively would be the best solution to implement. There are presently a few schemes available that allow for these properties. Current families of post-quantum cryptography which would allow for post-quantum secure solutions include lattice, multivariate, McEleise, hash and SSECI based cryptography.
Monero's one-time “stealth” addresses are vulnerable to deanonymization by a hypothetical adversary that can leverage Shor’s algorithm in conjunction with Grover’s algorithm. This means that the adversary could identify the wallet public keys that were used to generate the stealth address.
One time “stealth” addresses are generated uniquely and pseudorandomly for each transaction made using Monero. This feature of Monero adds an extra layer of security to the protocols and masks the public keys used in each transaction from being public knowledge. The way a potential quantum adversary could break the security of this mechanism is based upon the breaking of two previously held assumptions; the first being the strong RSA assumption and the second being the assumption that it is difficult to reverse hash functions.
Below is how a theoretical quantum adversary could disable the stealth address feature,
Alice first sets up a one-time stealth address by generating a random number r If Alice wants to send a transaction to Bob, a one time stealth address is formed as such: Kstealth = hash(rKBv)G + KBspend Alice submits this and rG to the network Once submitted to the network, Bob can see it is meant for him using his private key rkBvG = rKBv From this, K’Bspend= Kstealth - hash(rKBv)G = KBspend This is considered secure classically, however a quantum adversary could break this feature as such: Find r, by factoring rG using Shor’s. Using Grover’s, find a K spend and view public key pair amongst existing public keys such that Kstealth = hash(rKBv)G + KBspend For a given r. From this, the private key derivation is simple, using Shor’s to factor such that: KB = kBG G*k → K is one way for traditional computer K,G→k is possible for a quantum computer via Shor’s
As shown, using a combination of Shor’s and Grover’s algorithm a quantum adversary could make stealth addresses unfeasible to use as a security mechanism. It should be mentioned however that while Shor’s algorithm does provide an exponential speedup in factoring large integers and solving other related problems, Grover’s algorithm only provides a quadratic speedup. Therefore, for very large data sets or key lengths Grover’s search algorithm might not present as much of a security risk.
In the example above, it is also pre-supposed that an adversary has a list of public view and spend keys, one of which is used in the transaction. It might not be necessary to have this, but by substituting this for something equivalent which requires someone to sort through an unordered set of data would present a security loophole a quantum computer could exploit, this could also be a list of known subadresses. If the stealth address is instead generated from a subaddress derived from an actual public key, an extra step would involve using Shor’s algorithm to solve the DLP used to generate the subaddress from the actual address.
(stealth addresses derived from subaddresses nonetheless provide an extra layer of security)
Unlike the example described above, most transactions will contain more than one output. Monero senders usually generate only one random value r such that rG is known as the transaction public key which is published along with the other transaction data in the blockchain.
Below is an example of how this could work.
Alice sends a transaction to Bob, the “transaction public key” which is randomly generated and used for the one time stealth address is rG = “06ba8” which is sent along with Bob’s one time stealth address “f717c” = Kstealth to the network.
Eve has a quantum computer and a list of Monero public key addresses and is trying to find out the associated public keys from the stealth address.
First, Eve factors the transaction public key (first finding the preimage if it's hashed, which might take a bit longer compared to some of the other steps she’d undergo depending on the key length.) She finds r = 789
Once Eve knows r, she plugs it into the oracle circuit for grover’s algorithm searching through the list of Monero public key addresses she knows to find a match such that
“f717c” = hash(789*Kv)G + Kspend
Eve finds that this corresponds to Bob’s public key addresses and the process is complete.
In general, the solution must not use a security protocol dependent on the DLP or another system vulnerable to a quantum computer. Increasing key lengths could also work to make it harder for Grover’s algorithm to find the preimage. Current relevant methods include lattice based cryptography, MaTriCT being a useful protocol to consider. Such a change would require updating the protocols but keeping the same mechanisms (all backend) and has the tradeoff of having larger key lengths and taking longer to process transactions.
Monero relies on generating seeds using a PRNG for the security of certain mechanisms to remain intact. It is already a problem, even without a quantum computer, that an outside adversary could gain an advantage in breaking security features for seeds that are generated from low entropy. The entropy in each case is generated by the OS of each device running Monero, but in some cases it can create “bad seeds” from low entropy that lead to advantages in overturning a few security assumptions. With a hypothetical adversary in possession of a quantum computer, it is possible to gain information about certain states that are meant to be hidden using either Fourier fishing, Grover’s algorithm
However, since this is already a security problem for adversaries with classical hardware (finding through brute force the state of a PRNG) it could be prudent to consider an alternative to the current PRNG mechanism. Perhaps having an outside source generate the entropy to create seeds (like a quantum computer or some other third party service providing entropy as a service), or if the Monero wallet repeatedly sampled the PRNG and applied statistical randomness tests to check entropy quality before generating new keys. In any case, it would require more computational resources to implement.
See Stealth address section
Monero's Ring signature component, which has the security properties of masking the keys associated in each transaction, should be computationally infeasible to determine which of the group members' keys was used to produce a signature. This security feature is vulnerable to a hypothetical adversary that can leverage Shor’s algorithm efficiently. The way ring signatures work in Monero is that the ring signature makes use of your account keys and a number of public keys (also known as outputs) pulled from the blockchain using a triangular distribution method. Over the course of time, past outputs could be used multiple times to form possible signer participants. In a "ring" of possible signers, all ring members are equal and valid.
This feature, which relies on one-way functions and private key signatures, in practice ensures transaction outputs are untraceable. With a quantum adversary, these one-way functions become reversible leveraging Shor’s algorithm. This in effect unveils the public and private keys behind each transaction, no longer hidden as a ring signature. With this information no longer hidden, the private keys used to sign the ring signature can be decoded and matched to their associated public keys. From this, the fundamental security feature that ring signatures provide can be rendered null Below is an example of how one could find an individual signature from a ring signature
List of keys L = {aG,bG,cG,dG,eG,fG,gG,hG,iG} in ring signature Where a - i are used to generate public keys, one is the legitimate transaction K,G→k is possible for a quantum computer via Shor’s Associated keys are then used to generate proofs Once one is found such that it matches the key image associated in that transaction, the appropriate signature is found.
ringCT security is broken by factoring each signature until the appropriate key is found that corresponds to the relevant transaction ID. If each key is already hashed, then using Grover’s algorithm or some method to exploit the internal architecture of the particular hash function (see Simon’s problem) it becomes possible to find the pre-image of the hash of the MLSAG signature. From this, it is a simple process of using Shor’s to find the private (or public) keys associated with each value.
To summarize, a keyed "combining function" which takes a key k , an initialization value v, and a list of arbitrary values and outputs a single value z is usually secure. The equation is solvable for any single input, but it is infeasible to solve if the adversary cannot invert any of the (here RSA-based) trap-door functions. With a quantum computer utilizing Shor’s this is possible and so it can be solved efficiently.
In general, the solution to this is to have the one-way functions reliant on another form of cryptography instead of elliptic curve cryptography such that the one-way functions cannot be reversed by a quantum computer leveraging Shor’s algorithm. Current relevant methods include MatRiCT which uses lattice based cryptography, or other lattice based signature schemes such as BLISS. Such an implementation would require changing the current ring signature scheme, this would essentially require altering the one-way functions such that they are based on NQP-hard as well as NP-hard problems. The tradeoff would be larger key sizes and longer verification times. This could prevent implementation until smaller, more efficient methods of creating one-way functions to base public and private keys are made.
It is possible for a hypothetical adversary that can leverage Shor’s and Simon’s algorithm to forge a valid value that satisfies the Bulletproof upon which the amounts in each transaction are encoded. Each Bulletproof is verified as correct before being added to the ledger, the Bulletproof is what is used to verify a certain amount of Monero has undergone a transaction by relying on a proof that sum(inputs) = sum(outputs) + fee.
A fundamental component of the Bulletproof is the range proof. Range proofs are proofs that a secret value, which has been encrypted or committed to, lies in a certain interval. Range proofs do not leak any information about the secret value, other than the fact that they lie in the interval. The arguments for a range proof require only a constant number of commitments. However, each commitment is large, as the security of the argument relies on the Strong RSA assumption. With a quantum computer, this assumption is overturned.
The Strong RSA assumption is the assumption made that given a modulus N of unknown factorization, and a ciphertext C, it is infeasible to find any pair (M, e) such that C ≡ Me mod N. Using Shor’s algorithm, this pair can be found easily and thus presents a security flaw in the design of range proofs. Classical Adversaries are assumed to be operating in Probabilistic Polynomial Time (PPT) While a quantum adversary would operate in BQP.
Given G as a Generator, y as a “blinding factor” and K and t being the public key of the transaction and the number of ring transactions respectively:
We define a commitment to an output’s amount b as: C(y,b) = yG + bH H = γG Where γ is meant to be hard to find in PPT, but within BQP it is not From this, bH can be found and the amount, b, can be forged in the transaction Forged amount is f such that f != b and C(y,b) = C(y,f) yt = hash(commitment_mask, hash(8rK,t) amountt=bt(XOR)hash(“amount”,hash(8rK,t)) The transaction data is stored as the commitment, C(yt ,bt). A BQP adversary could find a C(yt ,bt) such that bt includes f such that C(y,bf) = C(y,f) This is such that the input and output commitments are still valid, sum(C(y,b)) - sum(C(x,a)) = 0 As C(x,a) (input commitment) also utilizes a similar masking feature that is also vulnerable to a PQPT adversary C(x,a) = xG + aH,
If one can find appropriate values such that an arbitrary b be chosen while C(yt ,bt) is valid, this would allow amounts to be forged in transactions. Below is a demo of how this “tricks” the commitment scheme:
Alice has a value, heads or tails and a message (the “salt”) to be hashed. h = (“blah”,heads) (For this example, let’s say h = 06ab8) She sends this over to Bob. Bob receives it and flips a coin. Alice then reveals h was formed from the string “blah” and heads. Bob hashes “blah” and heads; h’ = (“blah”,heads). He gets 06ab8. Hence, satisfying the proof that Alice had “committed” heads beforehand and they record it on a ledger.
The way Alice would fool this scheme is by finding values (“salt”) that when hashed with a certain desired value equal the same output. This is described below:
Alice chooses a value, tails. Then hashes it with “blah” such that the output hash is as if she had picked heads with another salt value. h = (‘halb”, tails) = 06ab8 She sends this over to Bob, Bob receives it and flips a coin Alice then states h is formed from “blah” and heads. Bob hashes “blah” and heads: h’ = (“blah, heads) = 06ab8 = h, this satisfies the proof. However, Alice had actually “committed” another value beforehand, but since it satisfies the proof it is recorded nonetheless.
In order to forge amounts, it is presumed hard to find certain values to fool the proof that one has “committed” a certain amount beforehand. This commitment “proof” relies on the intractability of the Discrete Log Problem.
A possible way to replace this feature would be through using ZK-STARKS for commitments/proofs. ZK-STARKS scales differently and may have longer or shorter time-space requirements depending on how it is implemented.
See Forge amounts and Ring signatures sections.
Monero's RingCT transaction amount encryption is vulnerable to decryption by a hypothetical adversary that can leverage Shor’s algorithm by reversing the one way functions used to provide the security of this mechanism, and overturning the foundation upon which it is based upon (namely the DLP); thus, allowing transaction amounts to be unmasked. In general, the solution must involve one-way functions that are not vulnerable to decryption by a quantum adversary. One current relevant method is MatRiCT, a lattice based scheme. This would require a switch to lattice cryptography and has the downside of larger key sizes and verification times, but is still feasible to implement with existing hardware.
(See Forge Amounts Section)
Bulletproofs rely on a strong RSA assumption to provide zero-knowledge proofs with a small size. With a quantum adversary, the strong RSA assumption is no longer valid using Shor’s algorithm. Furthermore, the Discrete Log Relation used to generate bulletproofs relies on the assumption that an adversary can’t find a non-trivial relation between randomly chosen group elements. However, using a Quantum distinguisher this can be done. Rendering one basis of which bulletproofs are formed as insecure.
ZK-STARKS can be implemented as a quantum proof secure way to conduct zero-knowledge proofs. This can replace bulletproofs but has the drawback of requiring longer verification times and taking up a larger average transaction size. But, as the name implies, ZK-STARKS are scalable and are far smaller than many other quantum secure counterparts.
Part of the RandomX algorithm is hash-based, which in addition to imparting ASIC resistance, is also plausible quantum secure
See stealth address Section
Monero Payment ID’s are vulnerable to decryption by a hypothetical adversary that can leverage Shor’s algorithm by reversing the one way functions used to provide the security of this mechanism. In general, the solution must involve one-way functions that are not vulnerable to decryption by a quantum adversary. One current relevant method is MatRiCT, a lattice based cryptography scheme. This would require a switch to lattice cryptography and has the downside of larger key sizes and verification times but is still feasible to implement with existing hardware.
Monero's Keccak hash function is vulnerable to a hypothetical adversary that can leverage Grover’s algorithm or a Bernstein-Vazirani type algorithm. Using Grover’s algorithm, one can find the pre-image of this hash by matching values. Using a method similar to the one used in Simon’s problem to find the XOR mask, one could use something like the Bernstein-Vazirani algorithm to reverse the keccak hash function. The success of implementation depends on the internal architecture of the specific hash function. One simple solution to attacks involving Grover’s algorithm is to use the same hash function but with double the key length output, or use an entirely new hash function altogether.
By setting up Grover’s algorithm such that the oracle circuit is used to find the associated pre-image of the given hash digest for a set of N values. Instead of requiring N steps to reverse it could take √N steps.
Attacks similar to the one described in Simon’s problem utilizing an algorithm like the Bernstein-Vazirani algorithm could make specific hash functions obsolete depending on their internal architecture, including the keccak hash function. Current and relevant methods include doubling the key length which would require migrating to a new hash function. This hash function would be harder to find the pre-image of using Grover’s algorithm and has a tradeoff of taking up slightly larger computational resources that would prevent implementation. Attacks that are similar to what is described in Simon’s problem would require a case-by-case examination basis to determine whether the internal architecture would allow it to be reversed or if hidden information could be gleaned from it.
Since this component in development is based on ZK proofs reliant on the DLP being intractable, it would be vulnerable to a quantum computer utilizing Shor’s algorithm to solve discrete log problems quickly. By basing the security of this feature on problems also hard to solve on a quantum computer instead of DLP, this feature would still retain security against a quantum adversary.
Thanks, everybody! We've begun work, and shared shared weekly updates in MRL. Here is our preliminary analysis of existing vulnerabilities. (Results subject to change as research progresses!).
It also seems like Keccak might run into issues with Shor's + Bernstein–Vazirani algorithm (Hidden Linear Function Problem).
Research will continue until September, however Insight is requesting the full payout now to avoid volatility risks, to address 83srW....wpZrf
Best,
-:- Isthmus
Mitchell P. Krawiec-Thayer (cca4aef7) at 21 May 18:11
Mitchell P. Krawiec-Thayer (cca4aef7) at 20 May 22:58
Updating the cost to reflect today's exchange rate of 65 USD/XMR, a...
Thanks for the feedback and support! Some quick notes:
@sgp - In addition to the dissemination of information listed above, we'll also be sharing results for a wide audience in an upcoming Monero Talk episode.
@surae - Yep, we'll still keep an eye out for any serendipitous straightforward and performant mitigations. There might be some low-hanging fruit, like concatenating a post-quantum checksum to vulnerable hash digests.
Mitchell P. Krawiec-Thayer (21771e7e) at 01 May 23:20
Update research-post-quantum-monero.md
Mitchell P. Krawiec-Thayer (f266645d) at 01 May 21:59
Oops, need the header!
Mitchell P. Krawiec-Thayer (95da4c13) at 01 May 21:55
Update to draft version 2
Monero transactions created between 2014 and 2020 utilize cryptographic mechanisms that were not designed to be private or secure against quantum computers. Algorithms that could theoretically circumvent several of Monero's security and privacy features are already known, such as Shor's algorithm (which breaks security based on the discrete logarithm problem) and Grover's algorithm (which could be used to forge blocks).
Let us define a hypothetical “practical” quantum computer as any device that enables an adversary to effectively circumvent some security expectation provided by cryptographic mechanisms. This is not defined by some magic number of qubits or any particular configuration; it refers to the capability to leverage methods such as Fourier fishing, Grover's algorithm, or Shor's algorithm with enough complexity to tackle modern cryptography. Speculation on whether practical quantum computers will ever exist, and when they might arrive, is outside the scope of this cryptography research proposal.
There are several ways that a sophisticated quantum adversary might access funds and sensitive information that would otherwise be cryptographically obfuscated:
Retroactive deanonymization puts today's Monero users at the hands of tomorrow's [quantum or classical] adversaries. If practical quantum computers that can break Monero's encryption arrive at any point in the future, then users' lifelong transaction history willl become public for ingestion by the AdTech industry, stalkers, criminals, and governments. It is irrelevant which party publishes a de-anonymized copy of the Monero blockchain first - the universal evaporation of privacy is irreversible.
Thankfully, cryptographers have developed several post-quantum security and privacy schemes that may be adaptable to Monero. Promising techniques include zero-knowledge lattice cryptography based on the shortest vector problem. Methods such as hash-based ring signatures, GLYPH (Schnorr-like lattice-based signature scheme), and the cohort of NIST post-quantum candidates were all designed to enable security in a post-quantum world. The quantum resistant ledger is of particular interest due to its extensibility, immutability, and RandomX integration - however no privacy features are currently implemented. Other designs for anonymous post-quantum cryptocash have been considered, and the Halo recursive zero-knowledge proving system offers plausible post-quantum security. Each approach has its own benefits, drawbacks, and space/time complexity - our research recommendations will take into account these practical considerations in addition to theoretical compatibility.
This research will (1) study and simulate the threats listed above to assess Monero's vulnerability to quantum computers, (2) evaluate post-quantum cryptography scheme candidates to create a roadmap for hardening Monero against quantum adversaries, and (3) openly communicate the results for a variety of audiences.
The advent of powerful quantum computers will wreak havoc on almost every aspect of our digital infrastructure. Access to sound money (which requires privacy) is a fundamental human right and should be considered a high priority for hardening against quantum adversaries. To our knowledge, there are currently no plausibly post-quantum anonymous currencies in use today, meaning that only short-to-intermediate term financial privacy is available with current technology. The first coin to implement long-term post-quantum privacy features will be in a strong position for adoption, even long before quantum computers arrive.
"A post-quantum world would destroy Amazon, Wells Fargo, Visa, and most world governments. But there's no reason it has to also destroy Monero."
Surae Noether
R & D Institution: Insight
Funding Institution: Monero CCS
Duration: 3 months (June - August 2020)
Contributors:
The first phase of this problem will focus on identifying which of Monero's security features are susceptible to quantum adversaries. We'll look for vulnerabilities to known tools such as Shor's algorithm (which can find discrete logarithms is polynomial time, breaking the DL problem), Grover's algorithm (which produces a quadratic speedup when searching for inputs that map to a particular output for any black box function), and Fourier fishing in conjunction with the Deutsch-Josza algorithm (which can potentially be used in taking advantage of Monero's proof of work method in bounded-error quantum polynomial time).
Some vulnerabilities are already known, for example that cryptography based on elliptic curve and the discrete logarithm problem can be made insecure using Shor's algorithm. We will examine Monero's protocol for other examples of security based on problems that are computationally intractable for classical computers and easy for quantum computers. Some current privacy features are thought to be quantum resistant (such as Monero's masked amounts) and we will cautiously verify their security against our algorithmic adversarial toolkit.
Phase 1 deliverables:
Monero mechanism 1 | Monero mechanism 2 | ... | |
---|---|---|---|
Shor's algorithm | Plausibly secure | Plausibly secure | ... |
Grover's algorithm | Irrelevant | VULNERABLE | ... |
Fourier Fishing | Plausibly secure | Irrelevant | ... |
... | ... | ... | ... |
After locating and documenting Monero's quantum vulnerabilities, we will identify alternative cryptographic schemes that mitigate these weaknesses. Known post-quantum systems will be examined for Monero-compatibility (see Appendix 1 for a list of potentially relevant literature to be analyzed). In addition to interoperability, we will note practical considerations related to verification time, signature/proof size, and implementation. If there are no known solutions for mitigating a particular vulnerability, we will note the constraints necessary for developing a unique solution.
There are three broad categories of implications, which are not mutually exclusive:
Vulnerable privacy features will be given highest priority, since retroactive deanonymization poses a threat to today's Monero users, whereas theft and mining are not an issue until quantum computers scale past a distant threshold. Mining vulnerabilities are the lowest priority, since switching consensus mechanisms is easier than implementing new cryptographic schemes.
It's important to note that many current post-quantum cryptography candidates require large proofs and significant computational resources, and will thus not be suitable for immediate deployment. For this reason, understanding broad strategies and their tradeoff will be more useful than specific implementations. Thankfully, consumer device capabilities increase over time, and researchers continue to discover new faster/smaller proving systems, so these practical barriers are temporary.
Phase 2 deliverables: List of vulnerabilities, following this format when possible:
Monero's [component] is vulnerable to [impact] by a hypothetical adversary that can leverage [algorithm]. In general, the solution must meet [requirements]. Current relevant methods include [cryptosystem] which would require [migration process] and has [tradeoffs] that would prevent implementation until [device bandwidth/resource threshold] is widely available.
Throughout this entire project, the community will receive updates during the weekly #monero-research-lab meetings. During phase 3 however, several specific documents (the key deliverables from this research) will be freely published:
Phase 3 deliverables:
User-friendly writeup: This community-facing writeup will provide an approachable explanation of how hypothetical quantum computers may impact Monero, and possible future mitigations. The writeup should minimize FUD and provide the context that these vulnerabilities apply to almost all cryptocurrencies (not only Monero).
Technical documentation: An MRL position paper to distill key information for (current and future) researchers and developers. The writeup should formally describe vulnerabilities, and highlight potential strategies and solutions, noting their tradeoffs. Code snippets may be included if appropriate for pedagogical purposes or clarity.
Non-technical 1-pager: An ELI5 / TL;DR summary will be provided for journalists, Monero Outreach, etc. This blurb will discuss risks and myths with no technical jargon, with key takeaways that a broad audience will appreciate.
Results and updates will be also disseminated via Twitter threads, Reddit posts, and Breaking Monero videos.
Updated 2020-05-20: Based on discussion in #monero-community earlier today, we are moving forward with option #2 below (pre-payment to mitigate volatility risks). The original text is left below for transparency & context.
The team tackling this project consists of one full-time researcher dedicated solely to this proposal (Adam), along with mentoring and writing by Mitchell (5-15 hr/wk), input from the Director of Security, and internal editors/reviewers. We intend to execute this research initiative over a twelve week period between June - August 2020 for 37500 USD.
Insight's bills and employees' salaries are dollar-denominated, so we must minimize exposure to volatility risk. We are open to three different approaches, and will let the community choose how to proceed:
Here is relevant literature that will be reviewed and annotated for utility to Monero. List compiled by Dr. Brandon Gooddell
Mitchell P. Krawiec-Thayer (08acecb8) at 30 Apr 00:26
Add proposal
Mitchell P. Krawiec-Thayer (5a924c88) at 30 Apr 00:25
Mitchell P. Krawiec-Thayer (f4ffae1b) at 30 Apr 00:21
Mitchell P. Krawiec-Thayer (f4ffae1b) at 30 Apr 00:19
Post-quantum research CCS
Mitchell P. Krawiec-Thayer (5a924c88) at 30 Apr 00:19
Mitchell P. Krawiec-Thayer (190b398d) at 30 Apr 00:19
Mitchell P. Krawiec-Thayer (190b398d) at 30 Apr 00:18
Monero post-quantum research proposal CCS