We present Mimblewimble-cheque (MWC), a modification of the Mimblewimble (MW) transaction protocol that preserves its main properties, does not require additional security assumptions and allows transactions to be constructed without a communication round trip. Payments in MWC resemble cheques, i.e. Alice can make a payment to Bob by "writing a cheque", which Bob can "cash" by submitting it to the blockchain.
This document describes the search for a checksum algorithm to be used with Monero's new addressing scheme Jamtis. The purpose of the checksum is to detect accidental corruption of the address string.
Since Jamtis encodes addresses in base32, it allows the use of cyclic codes, which can provide guaranteed error detection, unlike hash-based checksums.
Monero currently uses a 32-bit hash-based checksum for its addresses. Hash-based checksums have a flat false positive rate regardless of the number of errors. Bitcoin's bech32 address format uses a degree-6 cyclic code optimized for short addresses of up to 89 characters. The cashaddr address format of Bitcoin Cash uses a degree-8 cyclic code that can detect 5 errors for lengths of up to 130 characters.
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.
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
This document describes a new addressing scheme for Monero.
Chapters 1-2 are intended for general audience.
Chapters 3-7 contain technical specifications.
The Mimblewimble (MW) protocol requires each transaction to specify an explicit fee amount. It is usually stored in the transaction kernel and signed with the kernel public key to prevent tampering. However, the ~100-byte kernel is the only part of a MW transaction that needs to be stored in the blockchain indefinitely. If the transaction fees are stored with full 64-bit precision, the fees may represent up to 8 percent of the whole blockchain download size as the transaction history grows.
This article describes a method to encode transaction priority and fee value in just 2 bytes (16 bits). The main idea is that instead of encoding the fee with the fixed precision of 1 atomic currency unit, we can encode the fee with a relative precision of about 0.1%-0.3%, which should be acceptable to most users.
This article describes the Minglejingle (MJ) protocol: a redesign of Mimblewimble (MW) for non-interactive transactions. It preserves the security and privacy properties, supports payment proofs, non-interactive coinjoin and secure pruning of spent outputs.
Blockchains are distributed ledgers that preserve the transaction history so that new network participants can, at any point in the future, verify these two security properties: