Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring in upstream v0.11 #103

Merged
merged 441 commits into from
Oct 13, 2020
Merged

Bring in upstream v0.11 #103

merged 441 commits into from
Oct 13, 2020

Conversation

fguisso
Copy link
Member

@fguisso fguisso commented Jun 10, 2020

No description provided.

@matheusd matheusd marked this pull request as ready for review September 15, 2020 12:41
wpaulino and others added 28 commits October 12, 2020 16:13
This is meant to handle a quirk in which key descriptors obtained
through walletrpc.DeriveKey don't result in the derived key being
persisted to the wallet's database, unlike with DeriveNextKey. Due to
this and some fallback logic in the wallet with regards to empty key
locators, if a request only specified the compressed public key, the
signature returned would be over a different key, namely the one derived
from (family=0, index=0).
This commit replaces reflect.DeepEqual tests and spew.Dump prints with
testify's require.Equal to make diffs smaller and test outputs more
readable.
Update our current tests to include lookup of duplicate payments. We
do so in preparation for changing our lookup to be based on a new
payments index. We add an append duplicate function which will add a
duplicate payment with the minimum information required to successfully
read it from disk in tests.
Add an entry to a payments index bucket which maps sequence number
to payment hash when we initiate payments. This allows for more
efficient paginated queries. We create the top level bucket in its
own migration so that we do not need to create it on the fly.

When we retry payments and provide them with a new sequence number, we
delete the index for their existing payment so that we do not have an
index that points to a non-existent payment.

If we delete a payment, we also delete its index entry. This prevents
us from looking up entries from indexes to payments that do not exist.
In our current invoice pagination logic, we would not return any
invoices if our offset index was more than 1 off our last index and we
were paginating backwards. This commit adds a test case for this
behaviour before fixing it in the next commit.
We now use the same method of pagination for invoices and payments.
Rather than duplicate logic across calls, we add a pagnator struct
which can have query specific logic plugged into it. This commit also
addresses an existing issue where a reverse query for invoices with an
offset larger than our last offset would not return any invoices. We
update this behaviour to act more like c.Seek and just start from the
last entry. This behaviour change is covered by a unit test that
previously checked for the lack of invoices.
With our new index of sequence number to index, it is possible for
more than one sequence number to point to the same hash because legacy
lnd allowed duplicate payments under the same hash. We now store these
payments in a nested bucket within the payments database. To allow
lookup of the correct payment from an index, we require matching of the
payment hash and sequence number.
Use the new paginatior strcut for payments. Add some tests which will
specifically test cases on and around the missing index we force in our
test to ensure that we properly handle this case. We also add a sanity
check in the test that checks that we can query when we have no
payments.
This addresses a panic when a notification is canceled after its been
detected as included in a block and before its confirmation notification
is dispatched.
This ensures proper coin selection synchronization between lnd and users
of the RPC to avoid potential double spend errors.
Introduces a new chancloser package which exposes a ChanCloser
struct that handles the cooperative channel closure negotiation
and is meant to replace chancloser.go in the lnd package. Updates
all references to chancloser.go to instead use chancloser package.
Modifies syncer.replyChanRangeQuery method to use the LastBlockHeight
method on the query. LastBlockHeight safely calculates the ending
block height and prevents an overflow of start_block + num_blocks.

Prior to this change, query messages that had a start_block +
num_blocks that overflows uint32_max would return zero results in the
reply message.

Tests are added to fix the bug and ensure proper start and end values
are supplied to the channel graph filter.
This was initially done as there were a few assertions throughout the
codebase requiring a channel's policy to be known. Now that these have
been addressed, we no longer need to store restored channels in the
graph, as their policies where incomplete anyway.
guggero and others added 28 commits October 12, 2020 16:14
To allow the macaroon service to be used in other projects, we want the
location to be passed in as a parameter instead of being hard coded.
When external subservers register themselves to be served through the
same gRPC interface as the main lnd RPC, their requests are also
intercepted by the main lnd macaroon interceptor.
If the external subservers want to use their own macaroons that are
independent of lnd's, they need a way to overwrite the default validator
of the macaroon interceptor. We add this mechanism with the concept of
external validators.
Give the external subservers the possibility to also use their own
validator to check any macaroons attached to calls to their registered
gRPC URIs.
This allows them to have their own root key ID database and permission
entities.
To be able to properly delegate requests to the correct component in LiT we
need to know all URIs of lnd and the other subservers.
To be spec compliant, we require the initiator to not pay the anchor
values into fees on coop close. We extract the balance calculation into
commitment.go, and add back the value of the anchors to the initiator's
balance.
Also modify the test to check for this condition.
Due to a misunderstanding about how the entities/actions are encoded
inside the macaroon, only the first action was printed per entity.
Even though we add them as separate pairs in the macaroon service (for
example "offchain:read" and "offchain:write"), they are grouped in the
serialized macaroon ("offchain:read,write").
This commit adds a shutdown logger which will send a request for
shutdown on critical errors. It uses the signal package to request safe
shutdown of the daemon. Since we init our logs in config validation,
we add a started channel to the signal package to prevent the case where
we have a critical log after the ShutdownLogger has started but before
the daemon has started listening for intercepts. In this case, we just
ignore the shutdown request.
Add a new health check package which will periodically poll health
check functions and shutdown if we do not succeed after our set number
of attempts. The first check that we add is one for our chain backend,
to ensure that we are connected to a bitcoin node.
The disk availability health check is less critical than our chain
access check, and may break existing setups (particularly mobile) if we
enable it by default. Here we disable by default, but leave our other
default values in so that it can easily be flipped on.
- let users specify their MAXIMUM WUMBO with new config option which sets the maximum channel size lnd will accept
- current implementation is a simple check by the fundingManager rather than anything to do with the ChannelAcceptor
- Add test cases which verify that maximum channel limit is respected for wumbo/non-wumbo channels
- use --maxchansize 0 value to distinguish set/unset config. If user sets max value to 0 it will not do anything as 0 is currently used to indicate to the funding manager that the limit should not be enforced. This seems justifiable since --maxchansize=0 doesn't seem to make sense at first glance.
- add integration test case to ensure that config parsing and valiation is proper. I simplified the funding managers check electing to rely on config.go to correctly parse and set up either i) non wumbo default limit of 0.16 BTC OR ii) wumbo default soft limit of 10 BTC

Addresses: lightningnetwork#4557
Without these changes, the disk check portions won't compile on these
platforms.
When we cancel a confirmation request, we should remove the request from
the height map regardless of the current height. Otherwise we end up in
the situation when the height is reached, the notification is attempted
sent which results in a crash.
This test addition would cause the txnotifier to crash prior to the
previous commit.
This adds in a new boolean flag that when set, prevents LND from writing the system hostname and network interface IPs to the TLS certificate. This will ensure privacy for those that don't want private IP addresses to be exposed on a public facing LND node.
As a preparation to also allow the final TX to be specified in the raw
wire format, we extract the check of the final transaction into its own
method.
With this commit we allow the final transaction of a PSBT funding flow
to also be specified as a raw wire format transaction.
As we already create two channels in our PSBT funding flow itest we can
easily just submit the final transaction for the second channel in the
raw wire format to test this new functionality.
In this commit, we disable the chain backend health checks by default,
as it seems for bitcoind there might be some lingering false positives.
However, those that wish to opt into the new safety features are still
free to toggle them on.
@matheusd matheusd merged commit 379b29f into decred:master Oct 13, 2020
@matheusd matheusd deleted the v0.11 branch October 13, 2020 18:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.