kayabaNerve

Speedy Fuzzy Range Proof

https://github.com/kayabaNerve/fcmp-ringct/blob/divisor-paper/divisors.pdf posits a 7-multiplicative-constraint proof of scaling with a k-bit scalar. This technique can be used to prove a Pedersen Commitment opens to a value within a i-bit range more efficiently than traditional bit commitments.

1. Perform a proof of scaling for a k-bit scalar and the blinding generator H (7 multiplicative constraints).
2. Perform a proof of scaling for an i-bit scalar and the binding generator G (7 multiplicative constraints).
3. Perform an incomplete addition (3 multiplicative constraints).

This makes the proof in total use 17 multiplicative constraints, not the traditional i. It does require commiting to 2(k+i) values however, where a vector commitment can have as many items as rows in the IPA multiplied by two, and each vector commitment grows the proof by 4 elements and itself.

kayabaNerve

The Dero Protocol

The protocol uses a pair of rings, one for the senders, one for the receivers, represented as a singular ring. With each transfer, a list of ElGamal ciphertexts is provided for all accounts within the joint ring. This ElGamal ciphertext is formed as r * G, (r * K) + (a * G), where r is some randomness, K is the key for the account the ciphertext is for, and a is the amount.

The Dero Wallet Protocol

Dero offers an 'encrypted message' with every transaction. Even if the user does not explicitly provide one, a message will exist (either with internally provided values or left empty). For the only defined type of message, the message is encoded as the index of the sender, a CBOR-encoded object, and zero-padding. The message is encrypted with the Chacha20 stream created by a key of H(H(r * K) || K) where r is some randomness and K is the key for the account the ciphertext is for.

The Issue

kayabaNerve

import random
# 2**31 - 1 is prime, making this a prime field
field = 2**31 - 1
 
# Modular inverse via egcd
def mod_inv(a):
  a = a % field
  t = 0
  new_t = 1
  r = field

kayabaNerve

For generators T, U, V, W, K = x T + y U + z V, prove knowledge of the witness and legitimacy of a claimed L = (z / y) W.

Provide K, L.

Form a Generalized Schnorr Protocol statement of

Matrix:
[
  [T, U, V],
  [0, L, -W],

kayabaNerve

Full-Chain Membership Proofs + Spend Authorization + Linkability

This proposes an extension to FCMPs to make them a drop-in replacement for the exsting CLSAG. In order to be such a replacement, the proof must handle membership (inherent to FCMPs), spend authorization, and linkability.

Terminology

• FCMP: Full Chain Membership Proof
• GBP: Generalized Bulletproof, a modified Bulletproof supporting Pedersen Vector Commitments in its arithmetic circuit proof. Security proofs are currently being worked on by Cypher Stack.
• GSP: Generalized Schnorr Protocol, a proven protocol for 2009 for proving: For a m*n matrix

kayabaNerve

Dero is a private cryptocurrency with a variety of user-focused features. With its advertising, it has attracted many people who value privacy. Unfortunately, many other communities of private cryptocurrencies have very unfavorable views of the Dero community, and vice versa. While these unfavorable views feed back into each other, this post attempts to review why these misunderstandings originally occurred, provide common ground, and put forth a new basis for going forward. This post will never convince those truly toxic to not be toxic, yet aims to appeal to anyone who values privacy and is willing to engage in good faith.

Please note these are my personal thoughts intended for a beginner. They aren't not meant to be 100% accurate on every formal definition, I haven't spent hours publishing them into a proper article, and I don't care to spend such effort. I may or may not update this for clarity/flow as time goes on. Until then, please note this is a rather low quality piece of writing in my opinion, even

kayabaNerve

The following is a rough sketch of a potential design, largely written in
present-tense.

---

We achieve a constant-time constant-size trustless ZK proof by recursing a
trustless sublinear Spartan instance to a minimum bound.
 
We then allow arbitrary users to specify a R1CS proof of size equal to the
minimum bound, allowing said users to in-effect specify and verify Spartan

kayabaNerve

Personally, I believe not moving to a curve cycle may be the biggest failure possible with Seraphis, and I'd likely lose interest in further contributing to Monero.

The end goal of any protocol is properly and efficiently doing its stated goal. For Monero, we prioritize privacy, yet we always seek out the best ways to be private. This shows with us not adopting a trusted setup (offering constant-time verification of any statement of any complexity, yet not being verifiable), yet moving from Borromean signatures to Bulletproofs, and later Bulletproofs+. We value performance, yet not when it's unsafe.

Currently, the only known sublinear proofs either:

1. Require pairing-based curves, whose security is an active discussion (notably, within the last decade they lost tens of bits)
2. A curve cycle

While Monero can find efficient proofs without a curve cycle, as seen with Bulletproofs, and still implement Curve Trees without a curve cycle (the current best case for full-chain membership proofs), via tower-hashin

kayabaNerve

fn polynomial<F: PrimeField + Zeroize>(coefficients: &[Zeroizing<F>], l: u16) -> Zeroizing<F> {
  let l = F::from(u64::from(l));
  let mut share = Zeroizing::new(F::zero());
  for (idx, coefficient) in coefficients.iter().rev().enumerate() {
    *share += coefficient.deref();
    if idx != (coefficients.len() - 1) {
      *share *= l;
    }
  }
  share

kayabaNerve

Featured Addresses

A previous proposal, Guaranteed Addresses, discussed a bit flag for the existing Monero address formats, extending their functionality by removing the burning bug as a potential exploit. This design ended up requiring per-network bits, leading to the suggestion from jberman to create a new address type per-network, one which is followed by a bit-flagged VarInt specifying features. This would create a highly composable address format allowing adding new features when demand is sufficient, without running into the original problem yet again.

Specification

Monero addresses are currently:

• VarInt type
• Public spend key
• Public view key