In a previous PR we added a Memo field for channels that could be
specified when opening a channel. This was a reference note-to-self
with no bearing on the functioning of the channel. In that PR, the
memo value was returned only through ListChannels. This commit builds
upon that PR by also returning the Memo field for channels returned by
PendingChannels RPC.
This corrects the documentation for the `amt_paid` and `amt_paid_msat`
fields on the `Invoice` message to indicate that the fields will be set
if the state of the invoice is either accepted or settled, not only
settled. This reflects the actual behavior of lnd, as demonstrated in
the below `lncli` output:
```
"amt_paid": "10000",
"amt_paid_sat": "10",
"amt_paid_msat": "10000",
"state": "ACCEPTED",
```
The storage of final htlc resolutions is a safety-critical feature. By
exposing it through the GetInfo call, connected applications can
ensure that the feature is turned on and avoid relying on the assumption
that lnd was configured correctly.
Add additional comment to `lnclic addinvoice`'s `--private` flag warning
about including a large number of private channel hints when using zero
ammounts.
Also added a comment to the `private` field in the `Invoice` proto
message.
Lists with non-primitive members aren't supported in the query string of
a GET request with the current version of the grpc-gateway library. To
allow route_hints to be set through REST, we also offer a POST endpoint
for that call where the encoding of the request parameter can be
specified as JSON.
This updates the RPCAcceptor to send the correct commitment type
even if the zero-conf or scid-alias channel types are set. This also
adds two bools to the ChannelAcceptRequest struct that denotes whether
the funder set the zero-conf and scid-alias channel types.
In this commit, we change the flow of the rpc middleware registration
a bit. In order to allow a client to add rpc middleware interceptors in
a deterministic order, we now make the server send a "registration
complete" message to the client after compeleting the registration
process so that the client knows when it can go ahead and register the
next client.
feature-bit channels
This allows opening zero-conf chan-type, scid-alias chan-type, and
scid-alias feature-bit channels. scid-alias chan-type channels are
required to be private. Two paths are available for opening a zero-conf
channel:
* explicit chan-type negotiation
* LDK carve-out where chan-types are not used, LND is on the
receiving end, and a ChannelAcceptor is used to enable zero-conf
When a zero-conf channel is negotiated, the funding manager:
* sends a FundingLocked with an alias
* waits for a FundingLocked from the remote peer
* calls addToRouterGraph to persist the channel using our alias in
the graph. The peer's alias is used to send them a ChannelUpdate.
* wait for six confirmations. If public, the alias edge in the
graph is deleted and replaced (not atomically) with the confirmed
edge. Our policy is also read-and-replaced, but the counterparty's
policy won't exist until they send it to us.
When a scid-alias-feature channel is negotiated, the funding manager:
* sends a FundingLocked with an alias:
* calls addToRouterGraph, sends ChannelUpdate with the confirmed SCID
since it exists.
* when six confirmations occurs, the edge is deleted and re-inserted
since the peer may have sent us an alias ChannelUpdate that we are
storing in the graph.
Since it is possible for a user to toggle the scid-alias-feature-bit
to on while channels exist in the funding manager, care has been taken
to ensure that an alias is ALWAYS sent in the funding_locked message
if this happens.
