kayabaNerve

import random
field = 2**31 - 1
 
# Modular inverse via egcd
def mod_inv(a):
  t = 0
  new_t = 1
  r = field
  new_r = a % field
  while new_r != 0:

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

kayabaNerve

This has been deprecated for Featured Addresses.

Guaranteed Addresses

Monero payments are not guaranteed to be spendable, when individual transactions are scanned. Only when the entire chain is scanned will you learn if an output has conflicts, and only with the private spend key can you see if one of those conflicts has been spent, already having burnt all potentially usable outputs. This makes view-only scanning of the chain insecure, under the standing policy of "credit difference", as the wallet will credit the difference even if the funds are already burnt.

It should be noted wallet2 will stop crediting the difference if it knows the key image was used, as it should, yet it will continually credit if view-only, as it'll never learn when key images are used (unless imported, which may break a desired privacy model). Unfortunately, this is not an issue with a simple fix. Solely crediting the initial transfer potentially leaves fun

kayabaNerve

extern crate libc;

use std::{
  ptr,
  mem,
  os::raw::c_char,
  ffi::{CStr, CString}
};

use serde_json;