š
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>;
Jeremy [ARCHIVE] /
npub1q8ā¦8qwta
2023-06-09 12:40:41
in reply to nevent1qā¦s94c
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaSeen on
wss://relay.noswhere.comPublished at
2023-06-09 12:40:41Event JSON
{
"id": "9b93311d71f05068c5e5dfb3445e5c534f294a4fa0207c64dfc353a4a3b978eb",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686314441,
"kind": 1,
"tags": [
[
"e",
"772573b97467822879caccac29bd71111faf33583ea905cc7da917f366a8411d",
"",
"root"
],
[
"e",
"ec897deb7a7fa0d2e5d4a904f35e55ee3ff417408ed6ef3051480b61d1819250",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "š
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",
"sig": "f43e6e97a878498059a981652a160924f3466e5228b7f5a93dd2e7ad14108250ca9eb881fec2c2369628bb414130f60a8c4e464c4246e7f7b4cd30b6fa51094a"
}