Skip to content

Instantly share code, notes, and snippets.


Stefan Thomas justmoon

View GitHub Profile
justmoon / benchmark.js
Last active Oct 23, 2018
BigNumber.js vs Long for UInt64 serialization
View benchmark.js
const Benchmark = require('benchmark')
const BigNumber = require('bignumber.js').BigNumber
const Long = require('long')
const TEST_DATA_STRINGS = new Array(ITERATIONS_PER_CALL).fill(null).map((v, i) => String(i))
const TEST_DATA_BUFFERS = => Buffer.from(new BigNumber(str).toString(16).padStart(16, '0'), 'hex'))
const HIGH_WORD_MULTIPLIER = 0x100000000
justmoon / codius.geojson
Created Jun 19, 2018
Codius hosts as of 2018-06-18
View codius.geojson
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

ILPv1 over ILPv4


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 /
Created Dec 19, 2017
Avoiding a combinatorial explosion while migrating to LPI2

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

Wire format changes

  • Switching from ILP packet 1.0 to "forwarded payment packets" (no amount)
justmoon /
Last active Dec 15, 2017
Interledger Dynamic Configuration Protocol (IL-DCP) Draft

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 /
Created Sep 18, 2017
BTP Final Notes
  • 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 /
Last active Nov 24, 2018
ILP Compatibility for Bitcoin


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
justmoon /
Created Mar 17, 2017
Delegated Channels Proposal

Delegated Channels

State of the Art

Payment Channels

Ripple currently supports Payment Channels (PayChan). This allows users to transact in small amounts without reporting each incremental change to the Ripple Consensus Ledger (RCL). Unfortunately, the current scheme has a major limitation when used with Interledger payments: Interledger payments are conditional payments, whereas Ripple Payment Channels only support unconditional transfers of value.

In practice, this means that two parties who wish to settle Interledger transactions over RCL must decide whether the PayChan claim is sent when the Interledger payment is prepared or when it is executed. The difference is that in the former case, the sender takes the risk that the receiver will not actually forward the payment, while in the latter case, the receiver takes the risk that the sender will not actually send the PayChan claim. Either way, one party can trivially defraud the other if it so cho

justmoon /
Last active Feb 8, 2017
Top-level ILP address prefixes

(This document is a draft.)

We define the following top-level ILP address prefixes:

  • g. for the globally routable address space defined by IL-RFC 0015
  • private. for any privately routable address space (similar to private networks in IP, e.g.
  • example. for addresses appearing in examples or documentation
  • test1., test2., test3. for addresses using in testing (similar to TEST-NET-{1,2,3}; used by five-bells-integration-test)
  • local. for ledger-local addresses (similar to link-local addresses in IP, i.e.
  • peer. for ledger-local addresses used in the context of a peering relationship (used by ilp-plugin-virtual)
justmoon /
Last active Jan 30, 2017
Construct 2017 Interledger Workshop Pre-Briefing

Welcome aspiring connectors!


What is Interledger?

Interledger is a protocol for payments across different (types of) ledgers. It is inspired by the history, architecture and philosophy of the Internet Protocol.

For those of you familiar with Lightning - it's basically like Lightning across different ledgers, even different types, e.g. from PayPal to a blockchain: