Skip to content

Instantly share code, notes, and snippets.

View emschwartz's full-sized avatar

Evan Schwartz emschwartz

View GitHub Profile
@emschwartz
emschwartz / gist:11169560
Created April 22, 2014 08:09
keybase.md

Keybase proof

I hereby claim:

  • I am emschwartz on github.
  • I am emschwartz (https://keybase.io/emschwartz) on keybase.
  • I have a public key whose fingerprint is C15A 266A 6BD3 E7F2 0541 DAA4 E422 6920 D03D F1CF

To claim this, I am signing this object:

/**
* Check if remote is connected and attempt to reconnect if not
*/
function ensureConnected(remote, callback) {
if (isConnected(remote)) {
callback(null, true);
return;
} else {
var test_transaction = new ripple.Transaction(),
client_resource_id = 'ebb9d857-fc71-440f-8b0a-f1ea3535986a';
test_transaction.payment({
from: 'rLpq5RcRzA8FU1yUqEPW4xfsdwon7casuM',
to: 'rLpq5RcRzA8FU1yUqEPW4xfsdwon7casuM',
amount: '10XRP'
});
var states = ['submitted', 'pending', 'validated'];
{
"success": true,
"payments": [
{
"source_account": "rBEXjfD3MuXKATePRwrk4AqgqzuD9JjQqv",
"source_tag": "",
"source_amount": {
"value": "1",
"currency": "XRP",
"issuer": ""
### Keybase proof
I hereby claim:
* I am emschwartz on github.
* I am emschwartz (https://keybase.io/emschwartz) on keybase.
* I have a public key whose fingerprint is A7AA 7052 F073 9404 2830 BAEF A3D7 E122 1268 5983
To claim this, I am signing this object:
@emschwartz
emschwartz / worstCaseThresholdLength.js
Last active March 23, 2016 23:59
Calculating the worst case threshold length
'use strict'
const threshold = process.env.THRESHOLD ? parseInt(process.env.THRESHOLD) : 150
const numSubconditions = process.env.NUM_SUBCONDITIONS ? parseInt(process.env.NUM_SUBCONDITIONS) : 10
const minWeight = process.env.MIN_WEIGHT ? parseInt(process.env.MIN_WEIGHT) : 1
const maxWeight = process.env.MAX_WEIGHT ? parseInt(process.env.MAX_WEIGHT) : 256
const minLength = process.env.MIN_LENGTH ? parseInt(process.env.MIN_LENGTH) : 1
const maxLength = process.env.MAX_LENGTH ? parseInt(process.env.MAX_LENGTH) : 1024
function getRandomIntInclusive(min, max) {
@emschwartz
emschwartz / 01_sender.js
Created May 19, 2016 23:04 — forked from justmoon/01a_sender.js
SPP Example
import { Client } from 'spp-client'
const client = new Client({
username: 'alice@red.ilpdemo.org',
password: 'secret'
})
function pay () {
const payment = client.payment({
destination: 'bob@blue.ilpdemo.org',
@emschwartz
emschwartz / README.md
Last active January 17, 2017 12:46
ILP Foundations Discussion

This is a brief summary of some ongoing discussions about fundamental Interledger topics: the packet format, the addressing scheme, and the protocol layer built directly upon ILP. Ideas are welcome!

Packet

Full discussion: Proposal: we need an Interledger Packet -- not just an ILP Header

Questions

  1. Should the packet be:
  • JSON
  • Binary (CBOR, OER, Protobuf, or custom)
  • JSON for now and binary later when we are more concerned with performance
@emschwartz
emschwartz / README.md
Last active December 1, 2017 18:57
Merging lesson from ILP 2/3 back into ILPv1

Lessons

  1. Focus on small payments and have connector limit bandwidth per user
  2. Focus on payment channels for cryptocurrencies instead of escrow or trustlines
  3. We need a production-ready open source connector ASAP

Steps to a real-money-ready connector

Must-Haves

  • Add fulfillment data
@emschwartz
emschwartz / README.md
Last active January 31, 2018 17:04
PSK2 take 2

Motivation for changing PSK2 Draft 1

Draft 1 of PSK2 attempts to support both streaming and chunked payments. However, it includes some features that are only useful for chunked payments and does not include some others that would be needed for a proper chunked payments implementation.

Based on a conversation with @sharafian, this proposes narrowing the scope of PSK2 while making it easier to build use cases like streaming and chunked payments on top.

For context, @justmoon had the idea to use PSK2 for "payment sockets", which I started implementing yesterday. However, @sharafian made the point that for many receiver use cases, it's better for the PSK2 receiver not to keep state but to simply call a callback for every chunk it gets. Applications will figure out their own logic for which chunks to accept and how to track the balance for different users or interactions. Therefore, PSK2 doesn't need the fields that are specifically fo