oleganza

Proving gadgets

This is a collection of fun algebraic tricks to prove various boolean and arithmetic statements inside zero knowledge proofs.

We are going to use Bulletproofs interface, but won't go into detail how Bulletproofs actually work.

Bulletproofs interface

Bulletproofs is a framework to create arbitrary proofs using a "Rank-1 Constraint System" interface. In simple terms, "rank-1" means that in our system we can express statements where secret values ("variables") can be added and multiplied.

oleganza

//! ```ascii
//! ┌──────────────────────────────────────────────────────────────────────────────────────┐
//! │    _______ __   __ ______  _______  ______ _______ _     _ _______ _     _ _______   │
//! │    |         \_/   |_____] |______ |_____/ |______ |_____| |_____| |____/  |______   │
//! │    |_____     |    |_____] |______ |    \_ ______| |     | |     | |    \_ |______   │
//! │                                                                                      │
//! └──────────────────────────────────────────────────────────────────────────────────────┘
//! ```
//!
//! # C Y B E R S H A K E

oleganza

Rust Script

A scripting variant of the Rust language: syntactic sugar for runtime memory ownership rules and other dynamic features, with none of the static ones.

The goal is to have a good complimentary language that's easier to write and tinker with, while interoperating with Rust easily.

"Rust learned from Ruby. What if Ruby learned from Rust?"

File extension

oleganza

Bulletproofs battleships

Rules

1. Each player has a board of 10x10 slots.
2. Each player has to place 5 ships, sizes of 1, 2, 3, 4 and 5 slots.
3. Ships can be oriented vertically or horizontally.
4. Ships cannot overlap.

Goal

oleganza

#include "api.h"
#include "crypto_sign.h"
#include "crypto_hash_sha512.h"
#include "randombytes.h"
#include "crypto_verify_32.h"

#include "ge25519.h"

int crypto_sign_keypair(
    unsigned char *pk,

oleganza

#!/usr/bin/env ruby -rubygems
# Shamir's Secret Sharing Scheme with m-of-n rule for 128-bit numbers.
# Author: Oleg Andreev <oleganza@gmail.com>
#
# * Deterministic, extensible algorithm: every combination of secret and threshold produces exactly the same shares on each run. More shares can be generated without invalidating the first ones.
# * This algorithm splits and restores 128-bit secrets with up to 16 shares and up to 16 shares threshold.
# * Secret is a binary 16-byte string below ffffffffffffffffffffffffffffff61.
# * Shares are 17-byte binary strings with first byte indicating threshold and share index (these are necessary for recovery).
# 
# See also: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

oleganza

// Before
func makeSandwich(completionHandler: (result:Sandwich)->Void)

// After
async func makeSandwich() -> Sandwich

// Informally equivalent to:

oleganza

Async semantics proposal for Swift

Modern Cocoa development involves a lot of asynchronous programming using blocks and NSOperations. A lot of APIs are exposing blocks and they are more natural to write a lot of logic, so we'll only focus on block-based APIs.

Block-based APIs are hard to use when number of operations grows and dependencies between them become more complicated. In this paper I introduce asynchronous semantics and Promise type to Swift language (borrowing ideas from design of throw-try-catch and optionals). Functions can opt-in to become async, programmer can compose complex logic involving asynchronous operations while compiler produces necessary closures to implement that logic. This proposal does not propose new runtime model, nor "actors" or "coroutines".

Table of contents

oleganza

(That's my attempt to understand what problem Impulse solves and how. I am not a designer/developer of this scheme.)

Problem

Regular Bitcoin transactions are not guaranteed until mined sufficiently deep in the blockchain. Unconfirmed transactions can be observed nearly instantly, but they cannot be trusted (could drop out because of insufficient fees, or double-spent).

Impulse Overview

oleganza

A reader asked me over email recently:

Have you posted anything or had any thoughts on Ghash.IO situation?

Nothing on this. I think it's just early volatility in bitcoin space. Some company (CEX) got serious about making a private mining farm and made a whopping share. Others will follow soon.

The dirty little secret of the blockchain is that it's not secure until increasing the hashrate by even 1% is an enormous economic feat. Currently it's not impossibly expensive to build your own farm with significant share - therefore the network is not very theoretically secure. Even if every existing pool had no more than 10%, you can't be sure that some guy does not unleash enormous hashing power at once and reverts some transactions.

When more companies start building private farms (and they will, it's the only cost-efficient way to mine; individual miners will soon disappear), you'll see more even distribution of the hashrate, but most importantly, the growth of hashrate will get slower. Because the slo