tevador

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.

Table of Contents

• [1. Int

tevador

Mimblewimble-cheque: Scalable blockchain with 2-step transactions

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.

• 1. Introduction
  • 1.1 Previous work
  • 1.2 Contribution
• 2. Cryptographic primitives
  • 2.1 Notation

• 2.2 Hash functions

tevador

1. Introduction

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.

1.1 State of the art

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.

tevador

[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

tevador

JAMTIS

This document describes a new addressing scheme for Monero.

Chapters 1-2 are intended for general audience.

Chapters 3-7 contain technical specifications.

Table of Contents

tevador

Compact representation of fees for Mimblewimble

1. Introduction

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.

1.1 Contribution

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.

tevador

Minglejingle: Scalable blockchain with non-interactive transactions

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.

1. Introduction

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:

1. Supply security: No counterfeit coins have been created.
2. Ownership security: No coins have been moved without the authorization by the owner of the associated private keys.