{"type":"rich","version":"1.0","author_name":"npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","author_url":"https://nostr.ae/npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwta","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-07-12\n📝 Original message:\nAnother option would be to somehow encrypt this data in, say, an OP_RETURN\nfor any update transaction for each participant (perhaps worth breaking\nupdate symmetry for efficiency on this...) that way if an update ever\nhappens on a state you don't have you can use your static key to decrypt\nthe relevant data for what PK_si signed off on.\n\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Mon, Jul 12, 2021 at 3:16 PM Jeremy \u003cjlrubin at mit.edu\u003e wrote:\n\n\u003e Without an exact implementation, one thing you could do to fix the lost\n\u003e state issue would be to make the scripts something like:\n\u003e\n\u003e [`\u003cN+1\u003e CLTV DROP PKu CHECKSIGVERIFY GETLOCKTIME \u003cPK_root\u003e\n\u003e BIP32DERIVE CHECKTRANSACTIONSIGNEDFROMSTACK`, `2016 CSV DROP PK_si\n\u003e CHECKSIG`]\n\u003e\n\u003e In order to upgrade to state M\u003e= N+1 you'd have to publish a transaction\n\u003e signed with the BIP32 derived key for that update in the future.\n\u003e\n\u003e The downside is that you end up double publishing the txdata on the chain,\n\u003e but it at least ensure data availability.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/54e583d7/attachment.html\u003e"}