On Thu, Dec 09, 2021 at 12:34:00PM +1100, Lloyd Fournier wrote:
> I wanted to add a theoretical note that you might be aware of. The final
> message "Bob -> Alice: revoke_and_ack" is not strictly necessary. Alice
> does not care about Bob revoking a commit tx that gives her strictly more
> coins.
That's true if Alice is only sending new tx's paying Bob; and Rusty's
examples in the `option_simplified_update` proposal do only include new
HTLCs...
But I think it's intended to cover *all* update messages, and if Alice is
also including any `update_fulfill_htlc` or `update_fail_htlc` messages in
the commitment, she's potentially gaining funds, both for the amount of
fees she saves by avoiding extra transactions, but for the fulfill case,
potentially also because she doesn't need to worry about the fulfilled
htlc reaching its timeout.
Actually, as an alternative to the `option_simplified_update` approach,
has anyone considered an approach more like this:
* each node can unilaterally send various messages that always update
the state, eg:
+ new htlc/ptlc paying the other node (update_add_htlc)
+ secret reveal of htlc/ptlc paying self (update_fulfil_htlc)
+ rejection of htlc/ptlc paying self (update_fail_htlc)
+ timeout of htlc/ptlc paying the other node (not currently allowed?)
+ update the channel fee rate (update_fee)
* continue to allow these to occur at any time, asynchronously, but
to make it easier to keep track of them, add a uint64_t counter
to each message, that each peer increments by 1 for each message.
* each channel state (n) then corresponds to the accumulation of
updates from each each peer, up to message (a) for Alice, and message
(b) for Bob.
* so when updating to a new commitment (n+1), the proposal message
should just include both update values (a') and (b')
* nodes can then track the state by having a list of
htlcs/ptlcs/balances, etc for state (n), and a list of unapplied
update messages for themselves and the other party (a+1,...,a') and
(b+1,...,b'), and apply them in order when constructing the new state
(n+1) for a new commitment signing round
I think that retains both the interesting async bits (anyone can queue
state updates immediately) but also makes it fairly simple to maintain
the state?
> Bob's new commit tx can use the same revocation key as the previous
> one
That's a neat idea, but I think the fail/fulfill messages break it.
_But_ I think that means it would still be an interesting technique to
use for fast forwards which get updated for every add message...
> Not sending messages you don't need to is usually
> both more performant and simpler
The extra message from Bob allows Alice to discard the adaptor sigs
associated with the old state, which I think is probably worthwhile
anyway?
Cheers,
aj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
