Lnd: noencryptwallet does not display seed

Created on 3 Sep 2018  路  4Comments  路  Source: lightningnetwork/lnd

Background

when creating a lnd environment with noencryptwallet set, the wallet gets created without displaying a seed.

Your environment

  • lnd v0.5-beta-rc1
  • windows 10 64-bit
  • bitcoind as backend

Steps to reproduce

start a new lnd with --noencryptwallet

Expected behaviour

the wallet should wait for lncli create

Actual behaviour

the wallet creates a wallet.db without showing a seed

Most helpful comment

It's not exactly obvious to users that this is expected behavior. Especially first-time users like me who read https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md#disabling-wallet-encryption and dismiss the this argument must only be used for testing purposes as being overly careful. My expectation was that --noencryptwallet just does what it says without affecting backupability. I only realized much later that I've never seen and therefore never backed up the seed. Maybe it would make sense to stress that part in the documentation to reduce a footgun opportunity.

All 4 comments

That is expected behavior, remove the --noencryptwallet flag if you require a seed.

It's not exactly obvious to users that this is expected behavior. Especially first-time users like me who read https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md#disabling-wallet-encryption and dismiss the this argument must only be used for testing purposes as being overly careful. My expectation was that --noencryptwallet just does what it says without affecting backupability. I only realized much later that I've never seen and therefore never backed up the seed. Maybe it would make sense to stress that part in the documentation to reduce a footgun opportunity.

@jonasnick agreed that we can modify the documentation (even just remove the documentation for that option) to make it less of a foot gun. A related issue to this is: #899, which is to allow the user to input an "empty" passphrase rather than force them to use a non-empty one.

@jonasnick 100% agree that the naming and docs could be improved. I recall bringing this up in the past that the name does not suit the behavior, though the naming stuck and it was not revisited. I've made a PR to help address the confusion as we flesh out a full plan for deprecation.

1843

Was this page helpful?
0 / 5 - 0 ratings