Closed Overtorment closed 3 years ago
If the channel was using static remote key then a remote force close would result in funds being sent on-chain to an output that uses a static key covered by the seed. There would be no delay required to sweep
You could check out https://github.com/guggero/chantools for tools for fund recovery from the seed
If a legacy channel type was used then you would need the SCB to help you get the cooperation of the remote node to identify the randomizing element in the output key because before static remote key the funds were sent to a dynamic key that requires state beyond the HD seed
im running an experiment with 1 mBTC channel.
i force-closed on a remote node.
channel was "commitment_type": "STATIC_REMOTE_KEY",
now Im restoring client's node from mnemonics and from reading https://github.com/guggero/chantools I had an impression that node should sweep funds from static key automatically but its not happening. what am i doing wrong?
i noticed that remote node waited for 144 blocks and sweeped funds back:
You might want to check out this issue which deals with a similar scenario: https://github.com/lightningnetwork/lnd/issues/4778
I had an impression that node should sweep funds from static key automatically but its not happening. what am i doing wrong?
So right now we explcitily sweep these funds when we carry out the SCB recovery flow. What we don't yet do (which is mentioned in #4778) is make the wallet aware of those funds. We use a different keyscope/account/family from the default wallet, so even though it has the direct private key for the output on chain, it doesn't yet sweep it itself.
ok I read #4778 and as far as i understood lnd cant yet sweep those funds but they are safu? so is there anything I can do? can i hack some code to get private key to those coins, using https://github.com/bitcoinjs/aezeed for example?
ok I read #4778 and as far as i understood lnd cant yet sweep those funds but they are safu?
Correct.
you can use the genimportscript --lndpaths
command of chantools
to generate the private keys of those funds from your seed.
success! i was able to get a priv key for those coins.
question tho: why it was in 18th index?
m/1017'/0'/3'/0/18/
Nice! The indices are increased for each attempted channel open negotiation. I'm assuming there some successful or unsuccessful channels opened before the one in question.
another question:
i noticed that chantools
shows several typical paths, like purpose 44,49 & 84, which are typical HD wallets.
but there is also purpose 1017
, under which account 3'
is static keys from channels (to sweep funds from).
quick googling showed that m/1017'/0'/6'/0/0
is responsible for node's identity (pubkey & priv key).
what's the responsibility of other accounts 0-9 ?
See keychain/derivation.go
, all key families are described there.
Background
--enable-upfront-shutdown
is it possible for client to recover his coins? as far as I know, after an initial delay for unilateral close (say, 144 blocks) each client has to claim (aka "sweep") his half to his regular onchain wallet. and the key to this intermediate address that has to be sweeped is stored where? only in SCB?