mirror of
https://github.com/lightningnetwork/lnd.git
synced 2025-06-05 04:30:16 +02:00
docs: update remote signing doc and release notes
This commit is contained in:
Oliver Gugger
parent
bab807a57d
commit
5282c9acf9
@ -1,12 +1,22 @@
|
||||
# Release Notes
|
||||
|
||||
## Remote signing
|
||||
|
||||
The [remote signing](../remote-signing.md) setup was simplified in that the
|
||||
signing node now [does not need to be hooked up to its own chain
|
||||
backend](https://github.com/lightningnetwork/lnd/pull/6006). A new mock chain
|
||||
backend can be specified with `--bitcoin.node=nochainbackend`. That way a wallet
|
||||
will be created and all signing RPCs work but the node will not look at any
|
||||
chain data. It can therefore be fully offline except for a single incoming gRPC
|
||||
connection from the watch-only node.
|
||||
|
||||
## Wallet
|
||||
|
||||
* A bug that prevented opening anchor-based channels from external wallets when
|
||||
the internal wallet was empty even though the transaction contained a
|
||||
sufficiently large output belonging to the internal wallet
|
||||
[was fixed](https://github.com/lightningnetwork/lnd/pull/5539)
|
||||
In other words, freshly-installed LND can now be initailized with multiple
|
||||
[was fixed](https://github.com/lightningnetwork/lnd/pull/5539).
|
||||
In other words, freshly-installed LND can now be initialized with multiple
|
||||
channels from an external (e.g. hardware) wallet *in a single transaction*.
|
||||
|
||||
## Build System
|
||||
@ -29,10 +39,11 @@
|
||||
* [We now _always_ set a channel type if the other party signals the feature
|
||||
bit](https://github.com/lightningnetwork/lnd/pull/6075).
|
||||
|
||||
* [Add json flag to
|
||||
trackpayment](https://github.com/lightningnetwork/lnd/pull/6060)
|
||||
* [Add `--json` flag to
|
||||
`trackpayment`](https://github.com/lightningnetwork/lnd/pull/6060).
|
||||
|
||||
* [Clarify invalid config timeout
|
||||
constraints](https://github.com/lightningnetwork/lnd/pull/6073)
|
||||
constraints](https://github.com/lightningnetwork/lnd/pull/6073).
|
||||
|
||||
* [Fix memory corruption in Mission Control
|
||||
Store](https://github.com/lightningnetwork/lnd/pull/6068)
|
||||
|
||||
@ -9,7 +9,7 @@ the **private** keys.
|
||||
|
||||
The advantage of such a setup is that the `lnd` instance containing the private
|
||||
keys (the "signer") can be completely offline except for a single inbound gRPC
|
||||
connection and the outbound connection to `bitcoind` (or `btcd` or `neutrino`).
|
||||
connection.
|
||||
The signer instance can run on a different machine with more tightly locked down
|
||||
network security, optimally only allowing the single gRPC connection from the
|
||||
outside.
|
||||
@ -31,40 +31,14 @@ xxx xx
|
||||
v | |
|
||||
+----------------+ gRPC | +----------------+ |
|
||||
| watch-only lnd +--------------+-->| full seed lnd | |
|
||||
+-------+--------+ | +------+---------+ |
|
||||
| | | |
|
||||
+-------v--------+ | +------v---------+ |
|
||||
| bitcoind/btcd | | | bitcoind/btcd | |
|
||||
+----------------+ | +----------------+ |
|
||||
| |
|
||||
+----------------------------------+
|
||||
+-------+--------+ | +----------------+ |
|
||||
| | |
|
||||
+-------v--------+ +----------------------------------+
|
||||
| bitcoind/btcd |
|
||||
+----------------+
|
||||
|
||||
```
|
||||
|
||||
NOTE: Offline in this context means that `lnd` itself does not need to be
|
||||
reachable from the internet and itself doesn't connect out. If the `bitcoind`
|
||||
or other chain backend is indeed running within this same firewall/offline zone
|
||||
then that component will need at least _outbound_ internet access. But it is
|
||||
also possible to use a chain backend that is running outside this zone.
|
||||
|
||||
## Restrictions / limitations
|
||||
|
||||
The current implementation of the remote signing mode comes with a few
|
||||
restrictions and limitations:
|
||||
|
||||
- Both `lnd` instances need a connection to a chain backend:
|
||||
- The type of chain backend (`bitcoind`, `btcd` or `neutrino`) **must**
|
||||
match.
|
||||
- Both instances can point to the same chain backend node, though limits
|
||||
apply with the number of `lnd` instances that can use the same `bitcoind`
|
||||
node over ZMQ.
|
||||
See ["running multiple lnd nodes" in the safety guide](safety.md#running-multiple-lnd-nodes)
|
||||
.
|
||||
- Using a pruned chain backend is not recommended as that increases the
|
||||
chance of the two wallets falling out of sync with each other.
|
||||
- The wallet of the "signer" instance **must not be used** for anything.
|
||||
Especially generating new addresses manually on the "signer" will lead to the
|
||||
two wallets falling out of sync!
|
||||
|
||||
## Example setup
|
||||
|
||||
In this example we are going to set up two nodes, the "signer" that has the full
|
||||
@ -80,8 +54,8 @@ opened to this node from the host on which the node "watch-only" is running.
|
||||
Recommended entries in `lnd.conf`:
|
||||
|
||||
```text
|
||||
# No special configuration required other than basic "hardening" parameters to
|
||||
# make sure no connections to the internet are opened.
|
||||
# We apply some basic "hardening" parameters to make sure no connections to the
|
||||
# internet are opened.
|
||||
|
||||
[Application Options]
|
||||
# Don't listen on the p2p port.
|
||||
@ -93,6 +67,19 @@ nobootstrap=true
|
||||
# Just an example, this is the port that needs to be opened in the firewall and
|
||||
# reachable from the node "watch-only".
|
||||
rpclisten=10019
|
||||
|
||||
# The signer node will not look at the chain at all, it only needs to sign
|
||||
# things with the keys contained in its wallet. So we don't need to hook it up
|
||||
# to any chain backend.
|
||||
[bitcoin]
|
||||
# We still need to signal that we're using the Bitcoin chain.
|
||||
bitcoin.active=true
|
||||
|
||||
# And we're making sure mainnet parameters are used.
|
||||
bitcoin.mainnet=true
|
||||
|
||||
# But we aren't using a "real" chain backed but a mocked one.
|
||||
bitcoin.node=nochainbackend
|
||||
```
|
||||
|
||||
After successfully starting up "signer", the following command can be run to
|
||||
@ -151,6 +138,21 @@ Input an optional address look-ahead used to scan for used keys (default 2500):
|
||||
Alternatively a script can be used for initializing the watch-only wallet
|
||||
through the RPC interface as is described in the next section.
|
||||
|
||||
## Migrating an existing setup to remote signing
|
||||
|
||||
It is possible to migrate a node that is currently a standalone, normal node
|
||||
with all private keys in its wallet to a setup that uses remote signing (with
|
||||
a watch-only and a remote signer node).
|
||||
|
||||
To migrate an existing node, follow these steps:
|
||||
1. Create a new "signer" node using the same seed as the existing node,
|
||||
following the steps [mentioned above](#the-signer-node).
|
||||
2. In the configuration of the existing node, add the configuration entries as
|
||||
[shown above](#the-watch-only-node). But instead of creating a new wallet
|
||||
(since one already exists), instruct `lnd` to migrate the existing wallet to
|
||||
a watch-only one (by purging all private key material from it) by adding the
|
||||
`remotesigner.migrate-wallet-to-watch-only=true` configuration entry.
|
||||
|
||||
## Example initialization script
|
||||
|
||||
This section shows an example script that initializes the watch-only wallet of
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user