imeckler

fn combine(
  g1: &[ark_pallas::Affine],
  g2: &[ark_pallas::Affine],
  chal: &[bool]) -> Vec<ark_pallas::Affine> {
    let c = endo_challenge_to_field(chal);
    g1.iter().zip(g2.iter()).map(|(p1, p2)| p1 + &p2.mul(c))
    .collect()
}

fn endo_challenge_to_field(chal: &[bool]) -> ark_pallas::Affine::ScalarField {

imeckler

If you need a public key encryption system compatible with snarkyJS, I would suggest a hybrid cryptosystem using the Pallas curve (the Group type in snarkyJS) for the public key part, and Poseidon for the symmetric part.

To give a bit more detail:

• a private key would be a scalar field element x
• the corresponding public key would be the group element Group.generator.scale(x).

Let's say a message is an array of field elements msg: Array<Field> against a public key h: Group. In pseudcode:

type CipherText = {

imeckler

Note: If you haven't already added your qanet public address to our Google Sheet, please go ahead and add it using the link below. Only public addresses listed in this doc will receive public qanet tokens for testing. If you added your public address while a public qanet is running, you will have to wait until the next release to receive your tokens. Alternatively, you can ask the community members in the qa-task-force channel to send you some tokens now. Link to the Google sheet: https://docs.google.com/spreadsheets/d/15YT8DALkufDAxiYzT9dx-eW-JALjZTt-9H9ZqtvLPm0/edit?usp=sharing

If you ran a node before the hardfork:

• run coda client stop-daemon (or docker exec -it mina coda client stop-daemon) to gracefully shut down your existing node
• move any log files or keys (especially ~/.coda-config/coda.log and ~/.coda-config/wallet) to a new location for backup. Please send us your ~/.coda-config/mina-best-tip.log as well so that we can validate our chosen "best tip" for the new chain after the fork.

imeckler

use algebra::Field;
const rounds_full: usize = 8;

const rounds_partial: usize = 33;

const half_rounds_full: usize = rounds_full / 2;

pub trait Sponge<Input, Digest> {
    type Params;

imeckler

This document makes explicit what is hinted at in the Halo paper, which is a technique for taking two AHIOPs that have efficient "incremental verification" and "gluing them together" to obtain one recursive proof system.

More specifically, if we have

• An AHIOP $S_0$ for verifying $\F_p$ arithmetic
• An AHIOP $S_1$ for verifying $\F_q$ arithmetic
• A polynomial commitment scheme $C_0$ for polynomials in $\F_p[x]$ and whose proofs can

imeckler

let n = something
let k = log2 n

let b (u : f_q array) (x : f_q) : f_q =
  let x_to_pow2s =
    let res = Array.create k x in
    for i = 1 to k - 1 do
      res.(i) <- square (res.(i - 1))
    done
  in

imeckler

Keybase proof

I hereby claim:

• I am imeckler on github.
• I am ihm (https://keybase.io/ihm) on keybase.
• I have a public key ASAx8w6RrIQZCA-t7qutmJ98uFt4NaqfjShO7pdJIAs7GAo

To claim this, I am signing this object:

imeckler

let check_merkle_lookup
  : type a.
    depth:int
  -> root:Hash.Var.t
  -> entry:Hash.Var.t
  -> Bool_var.t list
  -> ((hash, a) Merkle_tree.t, unit) T.t
  =
  fun ~depth ~root ~entry addr ->
    let initial_path =

imeckler

diag = go [] where 
  go active (xs:xss) = map head active ++ go (xs:map tail active) xss

imeckler

(declare-datatypes () (
  (Ty (base (idx Int)) 
      (arrow (src Ty) (tar Ty))
      (prod (c1 Ty) (c2 Ty)) 
      )))
      
 (declare-datatypes () (
   (Expr exprA
         exprAtoBtoC
         exprB