Key Management

[TheBlueMatt]

...is almost entirely unhandled.

Generally, we need the final claim keys (ie channel_monitor_claim_key and channel_close_key) to be provided by the user (probably derived in some reliable way) and the rest are really our internal keys but should be generated from a secret the client gives us.

[ariard]

Hey, started to dig into it with a review of lnd stuff on it. So something similar like having a LightningWalletManager in charge of LN pure services and lay under it a WalletController trait (giving us UTXOs, protocol exit points, master seed). Maybe LightningWalletManager should suck up some actual keyring material like ChannelKeys and why not preimages and revocation points ?
Hopefully will show some code layout soon to ease the discussion.

[TheBlueMatt]

I don't think we need anything that fancy - I think we explicitly should not be tracking UTXOs outside of ChannelMonitors. Ideally all we'd have is a single HD master key and some well-defined way of deriving keys from it such that the client can easily scan the chain for outputs that are theirs, but I think we'll need something more flexible where we can inform the user that a given UTXO (as discovered by a ChannelMonitor) is theirs and can be spent with HD path X (eg for unrevoked HTLC-Timeout/Success outputs, we probably want to just tell the user about them and let them figure out when to spend them, though for shutdown_scriptpubkeys things can be much simpler).

[ariard]

About the UTXO it isn't the ones in on-chain channel txs but the ones spent by funding_tx, lnd have some kind of ChannelReservation to avoid double-spend of input while waiting for channel opening workflow completion. But yes surely too fancy, at least for 0.1.

Okay so basically, 3 services to manage : derivation from master key, association of HD path X to spendable output from commitment tx and HTLC tx and provision upstream of channel_monitor_claim_key/shutdown_key given us by user.

For the 256-bit master seed, derivation scheme is this one for me ?
master seed --> per-connection seed --> per-chain seed --> per-channel seed --> per-commitment secret

[ariard]

And maybe we want tracking of remote per-commitment secrets and so latest preimages to ease backup in only one place? But I think we can do it latter

[TheBlueMatt]

Not only complication, but wholly out of scope. rust-lightning is *not* a wallet. How a wallet wants to manage it's outputs and create funding transactions is entire up to the library client, same as how it wants to access the network/build watchtowers/store things on disk. rust-lightning just makes it easy to build those things around it to integrate lightning into a wallet.

…

On October 16, 2018 12:55:59 AM UTC, ariard ***@***.***> wrote: About the UTXO it isn't the ones in on-chain channel txs but the ones spent by funding_tx, lnd have some kind of ChannelReservation to avoid double-spend of input while waiting for channel opening workflow completion. But yes surely too fancy, at least for 0.1. Okay so basically, 3 services to manage : derivation from master key, association of HD path X to spendable output from commitment tx and HTLC tx and provision upstream of channel_monitor_claim_key/shutdown_key given us by user. For the 256-bit master seed, derivation scheme is this one for me ? master seed --> per-connection seed --> per-channel seed --> per-commitment secret -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #81 (comment)

[ariard]

Okay, noted, will stick to the bare minimum

[TheBlueMatt]

How far did you get here? I'd like to make some quick progress on this by next weekend for LN-hackday NY.

[TheBlueMatt]

I'm gonna try to hack together a solution for #55 in the coming day or three, but want to move forward on this quickly as well, so no rush, but if you aren't active on it I'll take it over.

…

On October 16, 2018 7:50:17 PM UTC, Matt Corallo ***@***.***> wrote: How far did you get here? I'd like to make some quick progress on this by next weekend for LN-hackday NY. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #81 (comment)

[yuntai]

I'm gonna try to hack together a solution for #55 in the coming day or three, but want to move forward on this quickly as well, so no rush, but if you aren't active on it I'll take it over.
…
On October 16, 2018 7:50:17 PM UTC, Matt Corallo @.***> wrote: How far did you get here? I'd like to make some quick progress on this by next weekend for LN-hackday NY. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #81 (comment)

oh, have you started #55? I started poking around it today and think it can get it done by the weekend.

[TheBlueMatt]

Oh oops, yes, I have it mostly done just a few more bits are land and figure out how I want the replay API to look.

…

On October 24, 2018 12:52:32 PM UTC, yuntai ***@***.***> wrote: > I'm gonna try to hack together a solution for #55 in the coming day or three, but want to move forward on this quickly as well, so no rush, but if you aren't active on it I'll take it over.> > […](#)> > On October 16, 2018 7:50:17 PM UTC, Matt Corallo ***@***.***> wrote: How far did you get here? I'd like to make some quick progress on this by next weekend for LN-hackday NY. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: [#81 (comment)](#81 (comment))> > oh, have you started #55? I started poking around it today and think it can get it done by the weekend. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #81 (comment)