Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-27 📝 Original message: Hey Rusty, Thoughts on ...
📅 Original date posted:2021-04-27
📝 Original message:
Hey Rusty,
Thoughts on each point below.
On Fri, 23 Apr 2021 at 14:29, Rusty Russell <rusty at rustcorp.com.au> wrote:
> OK, I'm now leaning *against* this method.
>
> 1. It removes the ability to update a channel without access to the node's
> secret key. At the moment the node secret key is only needed for
> gossip and to DH to set up a new peer connection. c-lightning does
> not use this for now (we keep the per-channel keys in the HSM too),
> but it would be a perfectly acceptable tradeoff not to do this.
>
Don't you also need the node secret key for onion routing? i.e. every time
you update your channel to forward a payment.
I am not familiar with lightning HSM designs and security goals but to me
it doesn't sound like much of a cost to keep the key on the HSM and to
include doing channel updates as well seeing as it's already doing so much
work. If it is desirable to have different keys for DH and channel updates
then a simple solution is to have two static public keys -- one for each
task.
>From my perspective it is worth making the necessary sacrifices to include
this feature. For me and many people, lost data without backups is the
biggest risk to my funds in lightning. Certainly much more threatening than
whether certain keys are on a HSM or not. Anecdotally I've heard stories
like "I put my lnd on autopilot and then lost my disk died -- all my funds
are gone!?" more than once.
2. It doesn't get rid of temporary_channel_id, since we don't know
> the generation_number until both sides have sent it. We have a
> workaround for this already in dual-funding anyway.
>
Why did you decide to send this rather than just look up in your own
database what "generation" should be? I think that it's easy to make sure
that you and the other node are on the same page about this number without
communicating it. If someone is opening a channel with data that appears to
be invlaid because they are using the wrong generation then sending an
error back indicating what you are up to should be sufficient to recover?
> 3. Because we need a generation counter, it's not quite as easily
> scannable as you'd hope (the "gap" problem).
>
This doesn't seem to be a big issue. You are trying to recover your funds
after all so you can afford to scan over very large gaps i.e. leave the
node on for days. I mean my Bitcoin wallet manages to handle this so why
wouldn't it work here? I wonder if it is even necessary to bump the
generation until a funding tx is confirmed -- I can't think of a good
reason why you would want to open two channels to the same node at the same
time (why not put all your funds into the same funding).
> I think the "encrypted blob served by peers", even in a very naive way,
> offers another way to do this, though it requires the assumption that at
> least one peer is honest.
>
I see encrypted backups as complementary. With this scheme you can at least
find a peer that you've had a channel with. From the encrypted backup you
left with them you can then find others and check against them.
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210428/9090ecc5/attachment.html>;
📝 Original message:
Hey Rusty,
Thoughts on each point below.
On Fri, 23 Apr 2021 at 14:29, Rusty Russell <rusty at rustcorp.com.au> wrote:
> OK, I'm now leaning *against* this method.
>
> 1. It removes the ability to update a channel without access to the node's
> secret key. At the moment the node secret key is only needed for
> gossip and to DH to set up a new peer connection. c-lightning does
> not use this for now (we keep the per-channel keys in the HSM too),
> but it would be a perfectly acceptable tradeoff not to do this.
>
Don't you also need the node secret key for onion routing? i.e. every time
you update your channel to forward a payment.
I am not familiar with lightning HSM designs and security goals but to me
it doesn't sound like much of a cost to keep the key on the HSM and to
include doing channel updates as well seeing as it's already doing so much
work. If it is desirable to have different keys for DH and channel updates
then a simple solution is to have two static public keys -- one for each
task.
>From my perspective it is worth making the necessary sacrifices to include
this feature. For me and many people, lost data without backups is the
biggest risk to my funds in lightning. Certainly much more threatening than
whether certain keys are on a HSM or not. Anecdotally I've heard stories
like "I put my lnd on autopilot and then lost my disk died -- all my funds
are gone!?" more than once.
2. It doesn't get rid of temporary_channel_id, since we don't know
> the generation_number until both sides have sent it. We have a
> workaround for this already in dual-funding anyway.
>
Why did you decide to send this rather than just look up in your own
database what "generation" should be? I think that it's easy to make sure
that you and the other node are on the same page about this number without
communicating it. If someone is opening a channel with data that appears to
be invlaid because they are using the wrong generation then sending an
error back indicating what you are up to should be sufficient to recover?
> 3. Because we need a generation counter, it's not quite as easily
> scannable as you'd hope (the "gap" problem).
>
This doesn't seem to be a big issue. You are trying to recover your funds
after all so you can afford to scan over very large gaps i.e. leave the
node on for days. I mean my Bitcoin wallet manages to handle this so why
wouldn't it work here? I wonder if it is even necessary to bump the
generation until a funding tx is confirmed -- I can't think of a good
reason why you would want to open two channels to the same node at the same
time (why not put all your funds into the same funding).
> I think the "encrypted blob served by peers", even in a very naive way,
> offers another way to do this, though it requires the assumption that at
> least one peer is honest.
>
I see encrypted backups as complementary. With this scheme you can at least
find a peer that you've had a channel with. From the encrypted backup you
left with them you can then find others and check against them.
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210428/9090ecc5/attachment.html>;