From rusty at rustcorp.com.au  Mon Feb  1 01:02:56 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Mon, 01 Feb 2016 11:32:56 +1030
Subject: [Lightning-dev] Laundry list of inter-peer wire protocol changes
In-Reply-To: <1453929582.11915.56.camel@ultimatestunts.nl>
References: <87d1snvhyf.fsf@rustcorp.com.au>
	<1453929582.11915.56.camel@ultimatestunts.nl>
Message-ID: <87twltutrz.fsf@rustcorp.com.au>

CJP <cjp at ultimatestunts.nl> writes:
> There are a couple of subjects where new concepts are being worked out,
> or where alternative concepts exist; these things are likely to continue
> to evolve after you finish the first version of the protocol.
>
> It would be great if concept changes in one subject can be made more or
> less independently from concept changes in another subject. In order to
> make this possible, I suggest to de-couple certain things, and let each
> subject have its own sub-protocol, with version number / protocol
> identifier.
>
> The way I see it, the following subjects have ongoing design /
> alternative concepts, more or less independently from each other:

Indeed!

> * Micro-transaction channel design: e.g. several variations on the
> Lightning channel design, and Amiko Pay's escrow-based HTLC emulation
> and IOU semi-channel.

Yes, for lightning I would further split this into wire crypto, wire
protocol, anchoring and fee design, and commit transaction design.

> * Commit conditions: traditional definition consists of a hash value and
> a time-out. For practical purposes, Amiko Pay also adds a "start time",
> and there is an alternative concept of using keypairs instead of hash
> values to de-correlate a transaction in different links.

Good point.  I think of this as a sub-part of transaction design, but
it's logically a separable issue.

> * Routing: how to exchange routing info. For source routing: informing
> each other about Lightning nodes that exist. For source and non-source
> routing: informing each other about availability of routes, expected
> capacity and fees. The type of routing info depends on the routing
> algorithm in use by a node.

There are several topology issues:

1) Source-routing format (aka. onion design).
2) Route and fee broadcast and finding (eg. How do I find a route to X
   where all nodes support keypair commitments?).
3) Initial node finding (how do I find a node to create channels to?)

> In Amiko Pay, the micro-transaction channel design is already separated
> from the rest of the protocol; commit conditions are not (yet), and
> exchange of routing info doesn't really exist yet, since it's still
> doing "dumb" non-source routing (trying every possible route).

In c-lightning, routing is separate because it doesn't exist yet :)

Cheers,
Rusty.