Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-12 📝 Original message: Another option would be ...

📅 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>;