Port upstream PRs #36
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
|
Updated up to upstream master as of 2019-07-08 (commit a6e7781 PR 3251). |
|
Throughout most of July I ran a dcrlnd build from this with auotpilot enabled and had no crashes. I built on commit c8d7e6a |
|
FYI, as of the end of July we're pretty much in sync with the upstream lnd master on my private branch. I've checked up to commit lightningnetwork@add905d from upstream (PR 3346). I've gone over 377 PRs since our branching point, with 1177 commits done from the original 1614 upstream commits. |
This moves the cmd_reset_mission_control from the orignal (upstream) lncli command to dcrlncli. This is done as a move to facilitate future merges.
We do this to ensure the node announcement propagates to our channel counterparty. At times, the node announcement does not propagate to them when opening our first channel due to a race condition between IsPublicNode and processing announcement signatures. This isn't necessary for channel updates and announcement signatures as we send those to our channel counterparty directly through the reliable sender.
Previously the migration would fail if the source node was not set in the database. Since we know that the source node must have been set before making any payments, we check whether there actually are any payments to migrate, and return early if not.
This adds a new constant to hold the last defined key family. This is required in certain places in the wallet, so using a constant (instead of having to tweak the usage every time a new keyfamily is introduced) is more future-proof.
This moves the newly added watchtower files from lncli to dcrlncli dir. This is done as a move so that future merges are easier.
…gacy onion In this commit, we add a new build tag protected sub-config for legacy protocol features. The goal of this addition is to be able to default to new feature within lnd, but expose hooks at the config level to allow integration tests to force the old behavior to ensure that we're able to support both the old+new versions.
… pay test In this commit, we force Dave to use the legacy onion payload for the multi-hop test to ensure that we're able to properly mix the old and new formats, and have all nodes properly decode+forward the HTLC.
This commit modifies paymentLifecycle so that it not only feeds failures into mission control, but successes as well. This allows for more accurate probability estimates. Previously, the success probability for a successful pair and a pair with no history was equal. There was no force that pushed towards previously successful routes.
The server was kept alive long after it stopped being used. This caused problems for services using long-lived GRPC connections which might be created before wallet unlocked. They got stuck connected to the wallet unlock service needing a restart.
htlcs config: Adding RejectHTLC field in config struct This commit adds a RejectHTLC field in the config struct in config.go. This allows the user to run lnd as a node that does not accept onward HTLCs. htlcswitch/switch: Adding a field RejectHTLC to the switch config This commit adds a field RejectHTLC to the switch config. When the switch receives an HTLC it will check this flag and if the HTLC is not from the source hop, the HTLC will be rejected. htlcswitch/switch: adding check for RejectHTLC flag and incomingChanID This commit adds a check when receiving UpdateAddHTLC. The check looks for the RejectHTLC flag set and whether the HTLC is from the sourceHop (the local switch). If the HTLC is not from the sourceHop, then we reject the HTLC and return a FailChannelDisabled error. server: adding RejectHTLC field to initialization of switch lnd_test: adding test for RejectHTLC This commit adds a test which tests that a node with the --rejecthtlc flag will reject any onward HTLCs but still can receive direct HTLCs and can send HTLCs.
A height hint not being set would cause lnd to scan for the confirmation/spend of a txid/outpoint/address from genesis. The number of confirmations not being set within a confirmation request would cause the internal TxNotifier to deadlock when dispatching updates.
This prevents a deadlock while tearing down the TxNotifier if it's currently blocked delivering a notification. By closing the quit chan first, we ensure blocked sends/reads can exit and allow the TxNotifier to proceed tearing down.
These fields are only relevant for spent transaction outputs.
The cache wasn't really serving a purpose as FetchInputInfo isn't known to be a hot path. Also, with a planned addition of returning the confirmation status of an output within FetchInputInfo in a later commit, caching won't be useful as we'll have to go to disk anyway to determine the confirmation status.
We already have all of the information required for the outputs from the ListUnspent method.
In this commit, we address an issue that would cause us to scan from the genesis block for the spend of an output that we wish to use to raise the fee of a transaction through CPFP. This was due to setting a 0 height hint when constructing the input required by the sweeper and was discovered due to the recently added validation checks at the chain notifier level. We'll now use the current height as the height hint instead as the sweeper will end up creating a new transaction that spends the input.
matheusd
force-pushed
the
upstream-updt
branch
from
56c0d7f
to
8cdc900
Compare
|
This has now been updated up to commit lightningnetwork@d08721b My public test node is running this version. I'm also running a watchtower server at the following address, in case anyone wants to try it out:
Log from the tower for a breached channel: |
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.
This is the first batch of upstream commits made since our last merge point. It includes the upstream PRs: 2454, 2445, 2289, 2430, 2452, 2431, 2446, 2462, 2275, 2397, 2471, 2198.
They mostly deal with bugfixes and refactorings for upcoming features.
The import paths and APIs in the individual commits were adjusted as needed. A few extra commits were done when the changes were significant enough.
This is currently rebased on top of a branch that includes all currently outstanding PRs, to facilitate later merging, so I'm leaving this as a draft PR until the older ones are reviewed, approved and merged.