jtremback

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure("2") do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at

jtremback

I am not actively updating this gist and it is already out of date. Please see http://altheamesh.com/documents/universal-payment-channels.pdf

Universal Payment Channels

Jehan Tremback

Zackary Hess

Introduction

jtremback

Good writing, but it seems like a non-useful direction. See bold text at bottom of page

A channel is basically a mechanism where a group of nodes provably agree on a series of state updates and their order. At any point in time, any of the nodes can publish the latest agreed-upon state update to a blockchain. After a pre-agreed delay period the blockchain makes this state update permanent (for example, transferring escrowed funds to various accounts). However, if another node participating in the channel publishes a higher-nonced state update before the delay period is up, the higher-nonced update takes precedence. This means that participants in a channel can stop each other from cheating if they are able to publish to the blockchain at least once every delay period.

In Hess channels[1], a balance number is altered in each channel transaction to make payments between two parties. Channel transactions also include an array of hashlocks (or in the original spec, other "bets"), because otherwise each has

jtremback

A channel consists of two transactions on the blockchain.

Opening Transaction:

{
  channelId: String,
  pub1: Pubkey,
  pub2: Pubkey,
 amount1: Integer,

jtremback

/bin/bash /home/openwrt/sudowrt-firmware/built_firmware/builder.ar71xx/build_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/gcc-linaro-4.8-2014.04/gcc/../move-if-change tmp-gcov-iov.h gcov-iov.h
echo timestamp > s-iov
x86_64-linux-gnu-g++ -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ic -I/home/openwrt/sudowrt-firmware/built_firmware/builder.ar71xx/build_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/gcc-linaro-4.8-2014.04/gcc -I/home/openwrt/sudowrt-firmware/built_firmware/builder.ar71xx/build_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/gcc-linaro-4.8-2014.04/gcc/c -I/home/openwrt/sudowrt-firmware/built_firmware/builder.ar71xx/build_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/gcc-linaro-4.8-2014.04/gcc/../include -I/home/openwr

jtremback

% Run gossip:start()

-module(gossip).
-export([start/0, node/3]).

node(NodeId, Peers, MessagesForwarded) ->
  receive
    {add_peers, From, NewPeers} ->
      From ! add_peers_done,
      node(NodeId, NewPeers, MessagesForwarded);

jtremback

• Light clients can verify that their shit is correct
• you need a certain number of votes
• quorum of signatures to verify that the block hash at a certain height is what was signed by the quorum
• set of validators, supermajority is more than 2/3 or more of the validator set signing a block hash at a certain height. tells you that block was commited by the block chain
• if that's not true and they actually signed another block hash at that height, in tendermint you can figure out who double signed. they get slashed. with caveats.
• the block hash is a merkle tree root hash that includes all the transactions for that block as well as the validator signatures for the prev block
• it also includes the entire application state tree in the merkle hash path. the entire application state and contract data are all stored in tree
• you can prove that the value of a key in the app state tree is a certain value at a certain block height by checking the merkle proof against the block hash
• this is good for light clien

jtremback

function calculateDistance (touchA, touchB) {
  const diffX = touchA.pageX - touchB.pageX;
  const diffY = touchA.pageY - touchB.pageY;

  return Math.sqrt(Math.pow(diffX, 2) + Math.pow(diffY, 2));
}

function calculateMiddlePoint ({x: aX, y: aY}, {x: bX, y: bY}) {
  const x = (aX + bX) / 2;
  const y = (aY + bY) / 2;

jtremback

In react native, we have a need to handle pieces of data that are too large to move over the objc-js bridge. Currently, I do this by putting the data on the file system, reading it from there, then erasing it when done. This is just like manual memory management, but slower, and any "memory leaks" will persist and continue to take up space until the app is deleted. It would be good to have pointers to objc memory accesible from JS.

To evaluate different ways of doing this, let's consider a hypothetical application. A camera module needs to take a photo which is then uploaded by an http module.

Singleton dictionary

This would involve the camera and http module both having compatibility with rn pointers, and the user installing a 3rd module, rn-pointers. The rn-pointers module would mostly consist of a singleton dictionary in objc.

• When an rn-pointers compatible module wishes to return a pointer, it generates a UUID, and sends an event with that UUID and a payload of the data in question.
• Rn-pointers

jtremback

#import "RCTCameraManager.h"
#import "RCTCamera.h"
#import "RCTBridge.h"
#import "RCTEventDispatcher.h"
#import "RCTUtils.h"
#import "RCTLog.h"
#import "UIView+React.h"
#import "NSMutableDictionary+ImageMetadata.m"
#import <AssetsLibrary/ALAssetsLibrary.h>
#import <AVFoundation/AVFoundation.h>