Another option would be to somehow encrypt this data in, say, an OP_RETURN for any update transaction for each participant (perhaps worth breaking update symmetry for efficiency on this...) that way if an update ever happens on a state you don't have you can use your static key to decrypt the relevant data for what PK_si signed off on.
-- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Mon, Jul 12, 2021 at 3:16 PM Jeremy <jlru...@mit.edu> wrote: > Without an exact implementation, one thing you could do to fix the lost > state issue would be to make the scripts something like: > > [`<N+1> CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME <PK_root> > BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si > CHECKSIG`] > > In order to upgrade to state M>= N+1 you'd have to publish a transaction > signed with the BIP32 derived key for that update in the future. > > The downside is that you end up double publishing the txdata on the chain, > but it at least ensure data availability. >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
