Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-29 📝 Original message: CJP <cjp at ...
📅 Original date posted:2016-01-29
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
>> 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.
Agreed. I've implemented TCP for the moment, but am not making any
assumptions about it for protocol design.
> * 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.
Agreed. I think I'd like something better for a protocol definition,
but it's nice for prototyping.
> * 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.
I think the protocol itself needs to be robust against retransmissions.
There's no way to know if the other side received your acknowledgement
before a crash, so you will always need to handle duplication on
re-establishment.
> * 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.
I agree. There's room in the initial onion design for payer -> payee
messages, but we don't have a channel for responses.
I can't see an easy way to implement the payee --> payer comms reliably:
to be reliable it would have to be published on-chain in the commit tx.
(Which we could do by constructing HTLCs such that they require a blob
signed by the payee, but that's tracable ...).
Mats and Laolu wanted to add an arbitrary comms protocol layer, but I
think that's something we can defer.
> * 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.
Yes, I've totally punted on routing and fees. This idea merges well
with the idea of randomly selecting a handful of "beacons", which I've
toyed with in the past.
> * 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.
For the moment this is done with separate connections, though it would
be fairly trivial to multiplex over a single transport.
> * 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.
Yes, and we can't really finalize the lower-level implementation until
we have the upper parts anyway...
> * 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.
I think that trades one DoS for another, though. It saves cryptographic
constructs, but latency is the real cost, and this increases it.
Of course, we'll have to revisit that if the network in practice proves
subject to these problems...
> 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.
Rough consensus and running code, indeed.
Thanks,
Rusty.
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
>> 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.
Agreed. I've implemented TCP for the moment, but am not making any
assumptions about it for protocol design.
> * 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.
Agreed. I think I'd like something better for a protocol definition,
but it's nice for prototyping.
> * 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.
I think the protocol itself needs to be robust against retransmissions.
There's no way to know if the other side received your acknowledgement
before a crash, so you will always need to handle duplication on
re-establishment.
> * 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.
I agree. There's room in the initial onion design for payer -> payee
messages, but we don't have a channel for responses.
I can't see an easy way to implement the payee --> payer comms reliably:
to be reliable it would have to be published on-chain in the commit tx.
(Which we could do by constructing HTLCs such that they require a blob
signed by the payee, but that's tracable ...).
Mats and Laolu wanted to add an arbitrary comms protocol layer, but I
think that's something we can defer.
> * 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.
Yes, I've totally punted on routing and fees. This idea merges well
with the idea of randomly selecting a handful of "beacons", which I've
toyed with in the past.
> * 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.
For the moment this is done with separate connections, though it would
be fairly trivial to multiplex over a single transport.
> * 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.
Yes, and we can't really finalize the lower-level implementation until
we have the upper parts anyway...
> * 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.
I think that trades one DoS for another, though. It saves cryptographic
constructs, but latency is the real cost, and this increases it.
Of course, we'll have to revisit that if the network in practice proves
subject to these problems...
> 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.
Rough consensus and running code, indeed.
Thanks,
Rusty.