Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-27 📝 Original message: Lloyd Fournier ...

📅 Original date posted:2021-04-27
📝 Original message:
Lloyd Fournier <lloyd.fourn at gmail.com> writes:
> 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.

You need to ECDH with the node_id privkey, yes (as you do to establish
peer comms). But in the c-lightning model, that's part of central
routing, not the subdaemon which deals with a single channel. You can
still shutdown a channel without knowing the node's private key.

> 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.

The main concern is that access to one channel's keys doesn't give you
any access to the other channels' keys. I don't think there's a way
around that in any "I can derive another nodes' keys" model.

>>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.

Fair, but more reliable backups solve this better IMHO. (Roasbeef told
us that Electrum uses OP_RETURN to tag opens, which also works).

> 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?

If you ever lose that information, you can never open a channel again?
Or you simply believe them and retry if they offer a higher generation?

>> 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?

Well, bitcoin core famously didn't do this at all (had a key pool) and
people lost funds. Deterministic key generation is better, but it's
still making gross assumptions, usually undocumented, on how many keys
you can hand out before you *have* to use one.

It's sometimes shocking how unpolished Bitcoin infrastructure is. But
it's stuff like this that so many exchanges offer fixed deposit
addresses :(

> 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).

Well, I'd agree with you of course, but other implementations do allow
it. If you don't allow it, you don't need a temporary_channel_id at
all.

But that still only prevents gaps if you scan the TXO set, not the UTXO
set. And it doesn't help with unannounced peers or peers which are no
longer in the public graph. You want backups :)

>> 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.

I see encrypted backups as a more-likely-to-be-implemented solution
though. Because they're useful to send to places other than peers, and
they can also contain HTLC information if you want.

And after that, I don't think the remaining problem is sufficient to
engineer salvage solutions for.

But we can revisit if I'm wrong!

Cheers,
Rusty.