Jeffro jeffro256

[Draft] Zero-cost post-quantum mitigations for Seraphis

This draft presents post-quantum mitigations for Monero's next transaction protocol Seraphis. These mitigations are "zero-cost" in the sense that they only involve changes to the way private keys and blinding factors are calculated, which is transparent to blockchain verifiers. Mitigated keys will be compatible with a future hard-fork that can be put in place to ensure monetary soundness and security of the protocol even against a quantum computer.

While these mitigations do not prevent a quantum adversary from breaking the privacy of past transactions, they protect Monero from a total collapse that would result from an undetectable money supply inflation or the theft of users' funds.

1. Introduction

In 2020, Monero performed a post-quantum security audit that confirmed severe vulnerabilities of the transaction protocol against quantum algorithms [[1](https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeup

JAMTIS-RCT

This document introduces a new addressing scheme for Monero called Jamtis. The new addresses are 244 characters long and come with several new features. The new scheme allows users to delegate blockchain scanning to a 3rd party service without revealing which specific outputs belong to the wallet or the amounts that were received. New wallet tiers are introduced for merchants that only have capabilities for generating addresses or processing incoming payments. New addresses can be created statelessly (without the need to keep track of how many addresses have been generated). View-only wallets can display the correct balance.

The transaction protocol that comes with Jamtis is backwards compatible with existing CryptoNote addresses. That means wallets can send payments to both new and old addresses and the resulting transactions will be indistinguishable in the blockchain. Additionally, the protocol provides Janus attack mitigations for both new and old addresses.

Required possession duration of malicious hashpower for successful double-spend attack with a $z$ stopping rule.

An attacker possesses $q$ share of Monero's hashpower for a duration of $d$ blocks. Honest miners possess $p=1-q$ hashpower share.

Let $z$ be the number of blocks that the potential victim waits for "full confirmation" of a transaction. When a transaction is mined in a block on the honest chain, that means that the transaction has one confirmation, i.e. $z=1$. When another block is mined on the honest chain, $z=2$.

Monero FCMP `MAX_INPUTS`/`MAX_OUTPUTS` empirical analysis

Limiting the number of inputs and outputs allowed in a transaction may reduce the storage space and verification computation costs of Full-Chain Membership Proof (FCMP) Monero transactions. See here for initial discussion. This note is a preliminary attempt to measure the likely cost of different values for the proposed MAX_INPUTS and MAX_OUTPUTS blockchain consensus rule parameters. The analysis uses empirical blockchain data from here, estimated cost per input/output cardinality based on modified Python code (see below) here, and the results of an output consolidation algorithm.

TODO: MAX_OUTPUTS analysis

The output consolidation algorithm attempts to consolidate outputs in the fewest number of "rounds

	/**
	* Encrypts plaintext using AES-GCM with supplied password, for decryption with aesGcmDecrypt().
	* (c) Chris Veness MIT Licence
	*
	* @param {String} plaintext - Plaintext to be encrypted.
	* @param {String} password - Password to use to encrypt plaintext.
	* @returns {String} Encrypted ciphertext.
	*
	* @example
	* const ciphertext = await aesGcmEncrypt('my secret text', 'pw');