Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2020-08-23 📝 Original message: Olaoluwa Osuntokun ...

📅 Original date posted:2020-08-23
📝 Original message:
Olaoluwa Osuntokun <laolu32 at gmail.com> writes:
> After getting some feedback from the Lightning Labs squad, we're thinking
> that it may be better to make the initial switch over double-opt-in, similar
> to the current `shutdown` message flow. So with this variant, we'd add two
> new messages: `commit_switch` and `commit_switch_reply` (placeholder
> names). We may want to retain the "initiator" only etiquette for simplicity,
> but if we want to allow both sides to initiate then we'll need to handle
> collisions (with a randomized back off possibly).

(Sorry for long delay catching up with backlog).

Yeah, modelling on the shutdown flow makes more sense to me, due to
simplicity.

I think we will end up with a linear progression of channel types (type
n+1 is always preferred over type n). This has the benefit of
*reducing* the test matrix at some point by dropping older formats.

(You can't drop older format completely without an onchain event, of
course, since you need to be able to penalize ancient commit txs.
Though perhaps you just pregen penalty txs for those cases and behave like
a watchtower, maybe even not bothering about HTLCs?)

I think inventing a new commitment type numbering scheme is unnecessary:
just use existing feature bits and define what upgrades are permissable.

I send `commit_switch` with features, you send `commit_switch` with
features, we do feature matching to determine new features for channel.
You can easily figure out the intersection: if one requires a feature
the other doesn't offer, it's a noop (upgrade failure). Similarly, if
the combination offers no new features, it's a noop.

You can't add HTLCs after you've sent `commit_switch`. You can add
again (under the new rules) once:
1. You've both sent and received `commit_switch`.
2. You have no outstanding HTLCs (in either direction).

This means we don't have to worry about the case where we both propose
upgrades at once, it Just Works. It's also Just Works to always send on
reconnect, and simply echo your current features if you receive an
unexpected `commit_switch`.

---
I'd like to Upgrade The World to anchor_outputs, so maybe cleanest would
be:

1. Release supports anchor_outputs (odd).
2. Release supports upgrading to anchor_outputs.
3. Release requires anchor_outputs (even), unilaterally closes channels
w/o (ideally very few!).

We need a feature bit for upgrades, since we don't want to stop the flow
if they don't respond to commit_switch (i.e. it should be even).

Anyone working on this right now?

Cheers,
Rusty.