A PSBT funding flow consists of multiple steps. We add new RPC
messages that can trigger the underlying state machine to transition
to a new state. We also add new response messages that tell the
API user what the current state is.
In case the funding manager detects that a funding flow is requested
to be executed with the help of a PsbtIntent, the normal channel
negotiation with the remote peer is interrupted, as soon as the
accept_channel message was received. With the remote peer's funding
multisig key and our local key, we can derive the funding output
script and its address. This is enough to start the PSBT funding
and signing process which the user will do externally to the daemon.
We add a new funding assembler and intent type that handle channel
funding through the use of a PSBT. The PsbtIntent is in itself a
simple state machine that can be stepped through the process of
assembling the required information for the funding output, verifying
a user supplied PSBT for correctness, accepting a fully signed PSBT
and then assembling the funding wire message.
There was a recent change merged into btcd that isn't backward
compatible with older RPC clients. To make sure our docker quick
start example still works, we need to pin down btcd to the version
that is still compatible with lnd.
There are different versions of clang-format being installed on
different versions of ubuntu that apparently produce different
results when formatting the proto files. This is likely too much
of a hurdle for new contributors to also manually install the
correct version of a command line tool just to format stuff.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
We now use the jsonpb marshaler to convert the RPC responses to
JSON in lncli and REST. The jsonpb has a setting to use the
original name as defined in the proto file and the explicit
json_name definition is not necessary any more.
The jsonpb setting is called OrigName and needs to be true.
Because we now use printRespJSON everywhere where we print RPC
responses as JSON, we can simply instruct the jsonpb marshaler to
use the original snake_case name specified in the proto file for
the JSON field names and not the default camelCase.
The synchronous call to get all channel backups also include
channels that are pending at the moment of the call. A previous
commit added pending channels to the file based backup as well. So
this is the last backup method that needs to be adjusted to also
contain unconfirmed channels.
To fix the discrepancy between getting the channel backups via
RPC where all pending channels are included, we also update the
channel.backup file on disk whenever we get a pending channel
event notification.
By default, Travis-CI does `git clone --depth=50` which limits the
repo to the last 50 commits. Because we do linting against an old
commit, it cannot be found any more. We remove the limit completely
to not run into this problem again.
To be able to write a new channel backup file for pending channels,
we need to include the channel configuration in the pending channel
notification event.
This change instructs the REST proxy server to overwrite its default
JSON marshaler settings. That allows us to set EmitDefaults to true
which will result in all JSON fields returned in REST responses to
be fully populated, even if their values are falsey.
With this commit we add the ability to create a shared DH key by using
a custom node private key instead of the node's identity private key.
If no key locator is specified the node's identity private key will be
used as a fallback.
This change makes sure that all macaroons are stored in the same
folder. This makes it possible to use the lntest package in external
projects that use loop's lndclient library which currently assumes
that the admin macaroon and subserver macaroons are in the same sub
folder of lnd's data directory.
Integration tests in external projects might not have the same folder
structure as lnd does. Therefore we want to allow the path to the
lnd itest binary to be configurable.
When using the lntest package for itests in external projects, it
is necessary to access a harness node's configuration, for example
to get its data directory on disk. This commit exports that
configuration.
To allow signing of messages with any key in the key chain
we add two new methods to the signer RPC. These behave differently
to the methods with the same name in the main RPC as described
in the documentation comment.
With this PR we deprecate fields that have been specifically added to
to work around a bug in the gRPC/REST gateway that didn't allow bytes
fields to be encoded in REST requests.
That bug has now been fixed so the fields are no longer required.
To make it more clear how bytes fields have to be used in REST,
comments have been added to all those fields.
Oliver Gugger