CJP [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-11 📝 Original message: Hi, I've had another look ...
📅 Original date posted:2016-02-11
📝 Original message:
Hi,
I've had another look at C-Lightning protocol description[1], in the
hope to make a sort of match between your message types and the message
types in Amiko Pay. In the best case, there would be a near-perfect
match; in the worst case, the entire sequence would be different
(unlikely, since we try to accomplish similar things).
The result was a bit unexpected: there was hardly any match at all, but
this was not due to solving things in different ways, but because of
implementing nearly opposite subsets of the functionality of Lightning.
In Amiko Pay, the core protocol is mostly concerned with multiplexing
multiple channels of potentially different types, opening/closing
channels, doing a little bit of routing and following the payment
sequences (reserving/route finding, route canceling, fund locking, fund
releasing etc.). Channel implementation details, such as what messages
to exchange in case of opening/closing a channel, or in the different
steps of a transaction, depend on the different channel types, and no
Lightning-style channel type has yet been implemented.
On the other hand, the C-Lightning protocol description basically *only*
deals with the channel implementation details (what data is exchanged in
case of opening/closing a channel, or in the different steps of a
transaction). I don't see much about routing, for instance. The
C-lightning message structures would be perfect to put inside Amiko
Pay's ChannelMessage messages, and together they would make a more
complete protocol.
To make a (pretty weak) analogy: maybe you can see C-Lightning's
protocol as a fundamental building block of Lightning networks, in the
same way as you can see bi-directional byte streams as a fundamental
building block of computer networks. Then, the 'raw' protocol used by
C-lightning would be a bit like a serial point-to-point connection, and
C-lightning inside Amiko Pay would be a bit like a TCP/IP connection.
They deliver the same core functionality on application level, but
TCP/IP, being more layered, provides more versatility. It adds
multiplexing of different streams, and alternative communication
concepts (e.g. UDP).
For me, this was a bit of an eye-opener, though I should have expected
it, from what I know about C-Lightning. C-Lightning's protocol
description will be a nice guide for developing a true Lightning style
channel in Amiko Pay. Judging the development time and lines of code in
C-lightning, I guess the part that is implemented in C-lightning has
quite a bit of complexity, so I hope to build on Rusty's experience and
expertise, to do things a bit faster in Amiko Pay. I'd like to use some
C-lightning code as well, but I doubt it will be easy to integrate
(Amiko Pay is quite a restrictive framework for channel implementations,
and we have a language barrier between C and Python). Maybe we could
start with a 'dirty hack'-style of gluing things together, for a proof
of concept.
CJP
[1]
https://github.com/ElementsProject/lightning/blob/master/lightning.proto
📝 Original message:
Hi,
I've had another look at C-Lightning protocol description[1], in the
hope to make a sort of match between your message types and the message
types in Amiko Pay. In the best case, there would be a near-perfect
match; in the worst case, the entire sequence would be different
(unlikely, since we try to accomplish similar things).
The result was a bit unexpected: there was hardly any match at all, but
this was not due to solving things in different ways, but because of
implementing nearly opposite subsets of the functionality of Lightning.
In Amiko Pay, the core protocol is mostly concerned with multiplexing
multiple channels of potentially different types, opening/closing
channels, doing a little bit of routing and following the payment
sequences (reserving/route finding, route canceling, fund locking, fund
releasing etc.). Channel implementation details, such as what messages
to exchange in case of opening/closing a channel, or in the different
steps of a transaction, depend on the different channel types, and no
Lightning-style channel type has yet been implemented.
On the other hand, the C-Lightning protocol description basically *only*
deals with the channel implementation details (what data is exchanged in
case of opening/closing a channel, or in the different steps of a
transaction). I don't see much about routing, for instance. The
C-lightning message structures would be perfect to put inside Amiko
Pay's ChannelMessage messages, and together they would make a more
complete protocol.
To make a (pretty weak) analogy: maybe you can see C-Lightning's
protocol as a fundamental building block of Lightning networks, in the
same way as you can see bi-directional byte streams as a fundamental
building block of computer networks. Then, the 'raw' protocol used by
C-lightning would be a bit like a serial point-to-point connection, and
C-lightning inside Amiko Pay would be a bit like a TCP/IP connection.
They deliver the same core functionality on application level, but
TCP/IP, being more layered, provides more versatility. It adds
multiplexing of different streams, and alternative communication
concepts (e.g. UDP).
For me, this was a bit of an eye-opener, though I should have expected
it, from what I know about C-Lightning. C-Lightning's protocol
description will be a nice guide for developing a true Lightning style
channel in Amiko Pay. Judging the development time and lines of code in
C-lightning, I guess the part that is implemented in C-lightning has
quite a bit of complexity, so I hope to build on Rusty's experience and
expertise, to do things a bit faster in Amiko Pay. I'd like to use some
C-lightning code as well, but I doubt it will be easy to integrate
(Amiko Pay is quite a restrictive framework for channel implementations,
and we have a language barrier between C and Python). Maybe we could
start with a 'dirty hack'-style of gluing things together, for a proof
of concept.
CJP
[1]
https://github.com/ElementsProject/lightning/blob/master/lightning.proto