rich1.0npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtahttps://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtanjumphttps://nostr.ae📅 Original date posted:2021-07-12 📝 Original message: 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 <jlrubin at 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/54e583d7/attachment.html>