BIP448 Rebindable transactions and Lightning

I've been trying to understand BIP448 - rebindable transactions for a little while now. As best I can figure, the idea is that it would allow two people who have a lightning channel with each other to commit to channel updates by signing a transaction template that can be "reused."

Imagine your channel partner publishes an old channel state. It would be cool if you could just publish the more recent state and "override" their transaction. Instead, lightning as it is today involves quite a bit of complexity (penalty transactions, revocation secrets, etc). Using BIP448 rebindable transactions, channel partners could authorize each new channel state in a way that does not commit to the exact previous output it will spend. A signature authorizing State 3 could therefore remain valid whether State 3 spends the original channel output or a compatible output created by a State 1 or a State 2 transaction.

So even if your channel partner publishes an old state you could use the outputs from the old state as inputs to your transaction if you have a more recent state. All of this hinges on channel closing transactions including some kind of timelock past which their outputs would no longer be rebindable.

That is probably not the clearest way of stating it, but I find this concept very difficult to understand.

The main thing to grasp is that a rebindable transaction would let you commit to a transaction without specifying the exact utxos. This sounds a little insane, but I think it is relatively constrained. And it has a very nice property for protocols like lightning where the state of a channel gets updated but not necessarily broadcast to the chain -- signatures become rebindable to the latest valid state.

BIP448 and statechains

The good people at localhost research and lx-dev made an adaptation of this concept for statechains (which also have this problem of creating up

You may recall that a statechain functions by splitting the key into two pieces with the statechain operator holding one and you getting the other. Statechains also have the problem where a previous holder of a coin can publish a stale state withdrawing coins. To prevent this, statechains often use decreasing timelocks to enforce the order in which withdrawal transactions can be mined. But this puts a finite horizon on how many transactions can occur before the timelocks approach present time.

This creates a problem that is quite similar to the stale-state problem in Lightning. Rebindable transactions offer another way of dealing with it: in the BIP448 statechain construction, each owner receives a pre-signed update transaction representing their state. If a previous owner broadcasts an older state, the current owner can take their newer update transaction and rebind it so that it spends the output created by the stale state. The older state cannot immediately settle, giving the current owner a challenge period in which to move the coin forward to the latest state. Once the newer update confirms, the stale owner's settlement transaction can no longer spend its original input.

Here is how localhost and lxdev put it:

They have built a mutinynet version of it if you want to try it out: https://bip448.cash/

(I still feel like I'm not quite understanding something about this rebindable transactions concept.