kayabaNerve

Keybase proof

I hereby claim:

• I am kayabanerve on github.
• I am techaspirer (https://keybase.io/techaspirer) on keybase.
• I have a public key ASCSYCHgV_SH_oBFWZp_chFXw-R-AawQgVbKfx_9Oi1lego

To claim this, I am signing this object:

kayabaNerve

import tables

#Valid object times.
type NaturalObjectKind* = enum
    nokBoolean, nokInt, nokString, nokArray, nokObject

#Natural Object.
type NaturalObject* = ref object of RootObj
    case kind*: NaturalObjectKind
        of nokBoolean:

kayabaNerve

#Constructor 1.
proc newSketcher*[T](): Sketcher[T] {.inline, forceCheck: [].} =
    @[]

#Constructor 2.
proc newSketcher*[T](
    elements: seq[T] = @[]
): Sketcher[T] {.forceCheck: [].} =
    result = @[]
    for element in elements:

kayabaNerve

import ../../../lib/[Errors, Hash]
import ../../../Wallet/Wallet

import ../../../Database/Transactions/objects/SendObj

import ../SerializeCommon

proc parseSend*(
  sendStr: string,
  diff: uint32,

kayabaNerve

extern crate libc;

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

use serde_json;

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

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

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

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

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