Key Management #81
Comments
|
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 ? |
|
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). |
|
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 ? |
|
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 |
|
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)
|
|
Okay, noted, will stick to the bare minimum |
|
How far did you get here? I'd like to make some quick progress on this by next weekend for LN-hackday NY. |
|
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. |
|
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)
|
|
cool! I will be back onto onion stuff. |
|
Fixed in #225. |
It suggested figuring something else out after lightningdevkit#81, but the API we settled on after lightningdevkit#81 (which I think is just fine) doesn't allow for anything cleaner, so this is fine as-is.
...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.
The text was updated successfully, but these errors were encountered: