📅 Original date posted:2020-12-10
📝 Original message:
On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?
>
> Nice work. This would be a definite recovery win. We should add this
> to the DF spec, because Lisa was almost finished implmenting it, so it's
> clearly due for a change!
>
Yes that's certainly a fine way to do it.
I was also thinking you could eliminate all "basepoints" (not just funding
pubkey) using something like this. i.e. just use the node pubkey as the
"basepoint" for everything and randomize it using the shared secret for
each purpose.
Note that in practice you can have nodes reconnecting to you.
>
Hmm, this is a good point.
I was incorrectly assuming the best way to implement "recovery mode" would
be to never accept incoming connections.
We've long thought about peers supplying some storage for each other, so
> you can spray out (encrypted) backups that way. It's actually a fairly
> trivial addition; your scheme makes for much less data to store.
>
I've also been thinking about the best way to go about this.
If you're able to encrypt some backups to different places then all you
have to do is find one of your honest channel partners using this method
and then get encrypted hints to find them all.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201210/28068208/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:01:42
in reply to nevent1q…6vz7
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:01:42Event JSON
{
"id": "285822059011ab67a17e7f8de81bbe7bdce4d9f30f1b0d87312a9ff94ba7a5d1",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315702,
"kind": 1,
"tags": [
[
"e",
"00d04f5d5dbc11371cafd7ab01bc802b993b222fe5855ee6daccf8136379e483",
"",
"root"
],
[
"e",
"7e0200a1ba602699359f9df986ba189b391583d2954ec3b4c3f9e0ccee0d195b",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2020-12-10\n📝 Original message:\nOn Wed, Dec 9, 2020 at 4:26 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e\n\u003e Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?\n\u003e\n\u003e Nice work. This would be a definite recovery win. We should add this\n\u003e to the DF spec, because Lisa was almost finished implmenting it, so it's\n\u003e clearly due for a change!\n\u003e\n\nYes that's certainly a fine way to do it.\nI was also thinking you could eliminate all \"basepoints\" (not just funding\npubkey) using something like this. i.e. just use the node pubkey as the\n\"basepoint\" for everything and randomize it using the shared secret for\neach purpose.\n\nNote that in practice you can have nodes reconnecting to you.\n\u003e\n\nHmm, this is a good point.\nI was incorrectly assuming the best way to implement \"recovery mode\" would\nbe to never accept incoming connections.\n\nWe've long thought about peers supplying some storage for each other, so\n\u003e you can spray out (encrypted) backups that way. It's actually a fairly\n\u003e trivial addition; your scheme makes for much less data to store.\n\u003e\n\nI've also been thinking about the best way to go about this.\nIf you're able to encrypt some backups to different places then all you\nhave to do is find one of your honest channel partners using this method\nand then get encrypted hints to find them all.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201210/28068208/attachment.html\u003e",
"sig": "114b88d6c39798657fb29cd5451fc341fed6b54c91be088a2303778b36a406a2f8d4665e753e7edb89007899fb9d5b4e42d44b59f2f85ce6c3cec0686eaf72e2"
}