From cjp at ultimatestunts.nl  Wed Jan 27 19:34:15 2016
From: cjp at ultimatestunts.nl (CJP)
Date: Wed, 27 Jan 2016 20:34:15 +0100
Subject: [Lightning-dev] Laundry list of inter-peer wire protocol changes
In-Reply-To: <87d1snvhyf.fsf@rustcorp.com.au>
References: <87d1snvhyf.fsf@rustcorp.com.au>
Message-ID: <1453923255.11915.36.camel@ultimatestunts.nl>


> I'm sure I've missed things; what are they?

The lazy answer is to tell you to read the Amiko Pay protocol
description.[1] :-P Note that it is (of course) already outdated. To
give you some of the concept choices in there:

* Transport layer: TCP. We don't need its retransmission features (since
it's not good enough and we'll re-implement it in a higher layer), but
unlike UDP it works well over TOR.
* Serialization: JSON, with some conventions added on top of it, e.g.
for more efficient transfer of binary data. It is bloated, but easily
debuggable and easily extensible. Good for prototypes, maybe not so good
for high-performance production code.
* Message confirmation: this is done manually (instead of relying on
TCP), so that a node knows which messages were received / need to be
re-transmitted, even after a crash + restart.
* There is not only two-way communication between linked peers, but also
between payer and payee. This is necessary for Amiko Pay's
bi-directional routing, but also useful e.g. for transmitting meta-data
that doesn't fit in a QR code. Amiko Pay transmits an arbitrary-contents
"receipt" from payee to payer; in the future, this might be digitally
signed by the payee, as a "proof of transfer of ownership" of
non-cryptographic goods.
* Bi-directional routing: both payer and payee route towards a "meeting
point". This way, neither payer nor payee has to have a routable address
on the network. This is good for both payer and payee privacy; also, in
case of a semi-centralized network with a couple of large hubs, this
allows the network to grow without the large hubs noticing it, both in
payer and in payee direction.
* Multiple channels per link: useful to be able to route transactions
the usual way while one of the channels is (temporarily) closed. It's
also the easy way of adding more funds to an existing link, or funds
from both sides.
* Different channel classes: the micro-transaction design, and its
implications on what info needs to be transferred in which situations,
is a separate, higher-level protocol layer on top of a more generic
protocol that takes care of routing.
* Reserving before locking: this is an optimization, to reduce the risk
of locking funds in payment channels on a part of the route, and then
having to undo the locking when it turns out that the remaining part of
the route doesn't exist (anymore). Reserving is an informal(*),
temporary locking of funds for use in the transaction, and can be done
and undone very fast, without any channel operations. It is done
together with route searching + establishment.

CJP

PS. Don't trust a protocol spec that doesn't have an implementation,
since it's probably missing a couple of essential things. Don't use an
implementation that doesn't have a protocol spec, since you're likely to
run into future compatibility issues.

(*)informal = without cryptographic commitment, and without actual
channel update.

[1]https://github.com/cornwarecjp/lightning/tree/cornwarecjp/communications