forked from lightningnetwork/lnd
-
Notifications
You must be signed in to change notification settings - Fork 23
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Small nits on a few comments.
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.
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.