rich1.0npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hhttps://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://nostr.ae📅 Original date posted:2021-12-09 📝 Original message: 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