Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-01-31 📝 Original message: CJP <cjp at ...
📅 Original date posted:2016-01-31
📝 Original message:
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.
📝 Original message:
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.