Hey Rusty, Thoughts on each point below.
On Fri, 23 Apr 2021 at 14:29, Rusty Russell <ru...@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
