justmoon

/**
 * This is an experimental API design for a signal/reactive library.
 *
 * Compared to @preact/signals, the main difference is the introduction of a
 * different way of creating effects. Effects are async functions which contain
 * a loop centered around a signal reader which is an async generator.
 *
 * This makes it so there is a persistent scope (outside of the loop) and a
 * dynamic scope (inside the loop). This results in very readable reactive
 * code that is mostly plain JavaScript.

justmoon

const makeComponent = <TDeps extends Dependencies, TProduct>(dependencies: TDeps, factory: (deps: ResolvedDependencies<TDeps>) => TProduct): SmartFactory<TProduct, TDeps> => {
  const smartFactory = (predefinedDependencies = new Map()) => {
    const resolvedDependencies: Partial<ResolvedDependencies<TDeps>> = {}

    for (const key of Object.keys(dependencies)) {
      if (predefinedDependencies.has(dependencies[key])) {
        resolvedDependencies[key as keyof ResolvedDependencies<TDeps>] = predefinedDependencies.get(dependencies[key]) as ResolvedDependencies<TDeps>[string]
      } else {
        const resolvedDependency = dependencies[key](predefinedDependencies) as ResolvedDependencies<TDeps>[string]
        resolvedDependencies[key as keyof ResolvedDependencies<TDeps>] = resolvedDependency

justmoon

/**
 * This is a simple PRNG I built for fun using the SFC32 algorithm by Chris Doty-Humphrey.
 *
 * This code is provided without any warranty, express or implied, and is hereby placed in the public domain.
 *
 * If you're looking for a good quality pseudo-random generator as an NPM package, I recommend `pure-rand`.
 */

/* eslint-disable unicorn/prefer-code-point */
/* eslint-disable unicorn/prefer-math-trunc */

justmoon

const Benchmark = require('benchmark')
const BigNumber = require('bignumber.js').BigNumber
const Long = require('long')

const ITERATIONS_PER_CALL = 1000

const TEST_DATA_STRINGS = new Array(ITERATIONS_PER_CALL).fill(null).map((v, i) => String(i))
const TEST_DATA_BUFFERS = TEST_DATA_STRINGS.map(str => Buffer.from(new BigNumber(str).toString(16).padStart(16, '0'), 'hex'))

const HIGH_WORD_MULTIPLIER = 0x100000000

justmoon

justmoon

ILPv1 over ILPv4

Motivation

ILPv4 makes some trade-offs compared to ILPv1. However, mixed in with these trade-offs are some - imho - pure improvements. This document describes what it would look like if I had to redesign ILPv1 given what we know now, but weren't willing to make some of the more controversial trade-offs. This work also revealed the surprising conclusion that ILPv1 transactional semantics (non-chunked or "universal mode quasi-atomic") are possible to achieve using ILPv4.

Differences between ILPv1 and ILPv4

There are two main differences that are relevant for this discussion:

justmoon

We are currently in the middle of a fairly major refactoring which includes a lot of internal APIs changing and a few aspects of the wire format changing as well.

API changes

• See LPI2.
• See ilp update PR to LPI2

Wire format changes

• Switching from ILP packet 1.0 to "forwarded payment packets" (no amount)

justmoon

Interledger Dynamic Configuration Protocol (IL-DCP)

Client sends a transfer to the host:

{
  amount: '0',
  executionCondition: '[SHA256(32 zero bytes)]',
  expiresAt: '[Five second timeout]',
  ilp: {

justmoon

• BTP URIs: btp+wss://:token@hostname.example:port/path

• There is only one BTP version, but in the future we will likely add a subprotocol to the auth message that allows the client to advertise features and a subprotocol for the response that allows the server to acknowledge these features

• Subprotocols either use the feature

• The first protocol in the packet is called the primary

• If the packet contains more than one protocol with the same name, reject the whole packet with a BTP error

• If there are zero elements in protocol data, this is syntactically valid, although in the case of Message may return a BTP error

• Nginx proxy statement for each peer

justmoon

Introduction

Bitcoin is a popular digital asset hosted by a public proof-of-work blockchain. As such, it would be nice to allow Bitcoin users to (securely) participate in Interledger Protocol (ILP) transactions.

There are three modes of operation described in this document, each with different security and performance trade-offs:

1. Escrow Hashed Timelocked Contract (HTLC)

   This is the most secure, but also slowest way to integrate with Bitcoin. Each ILP transaction requires two consecutive Bitcoin transactions, so a delay over more than an hour is to be expected. This mode would be suitable for larger payments.

2. Payment Channel