Bring in upstream v0.10.0-beta #99
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
Add a balance at height lookup function which can be used to obtain local/remote balance at a given height. The current in memory commits and revocation log are used to source this information.
In this commit, we add a new channel type bit: a frozen channel. A frozen channel is one that can only be cooperatively closed by the responder, but not the initiator. This channel type is useful for certain classes of channel factory like protocols. We then add a new key on the channel bucket level to store the height after which this restriction no longer applies.
…dAssembler As frozen channels can only be created via the non-default channel assembler, we extend both the ShimIntent and CannedAssembler to also accept and expose this new channel status along with the thaw height.
In this commit, we make the internal channel funding flow aware of frozen channels. We also update the testSingleFunderReservationWorkflow method to ensure that the created channels have the proper type bit set.
To make it possible to run the for close test for multiple commit types, we extract it into a subtest, where the two nodes get passed in.
Now that the force closure test has been extracted, spin up new nodes for each commit type, and ensure the test succeed for all types.
This is a port of the upstream commit 4b5d91d. This was done independently instead of cherry-picked to preserve local changes to these tests. This is purele a code move commit.
To make clear whcih sweep scenarios are actually being tested
This improves some multi-hop test flakiness by ensuring Alice and Bob are connected before creating the three hop networks and by also asserting the clean slate after tests.
This will let us set their commitment type for the subtest.
The message in the response stream changed. Rename the calls themselves, to prevent older applications from getting decode errors. Especially troublesome is the case where the request is executed (send payment), but the application can't read the outcome (payment sent or not?)
To soften the transition for routerrpc users to the V2 messages.
This enforces the _actualized_ fee rate of the commitment transaction, rather than the fee floor used for estimation. The new value of 250 sat/kw corresponds to 1 sat/byte, rather than 253 which is only rounded up during estimation to account for the fact that BOLT 3 rounds down to the nearest satoshi and that the vbyte fee estimation is lossy. Previously we would incorrectly fail to sign the next commitment even though the fee was technically high enough. Restarting with this commit should solve the issue as long as the channel hasn't already gone to chain. Note(decred): Due to not having a different size units (weight+byte vs only byte) we don't need the additional var and updated conditional check. The test has been brought in for completeness.
Modifies some of the older mailbox tests that were left untouched as of PR lightningnetwork#4174 to use the new mailbox test context. This ensures that the config members of each mailbox's config are properly initialized. In certain instances where travis is slow, this would cause test panics.
In this commit, we move to clamp down somewhat on the max invoice size after the limit was removed as part of the mpp changes. In lightningnetwork#4210, it was reported that a value of -1, would underflow and end up as 18 million BTC, which would trip checks w.r.t the max expressible value in mSAT. In this commit, we clamp things down to 100k BTC, which should be more than enough for anybody. Fixes lightningnetwork#4210.
This is a preparation for enabling the REST interface on routerrpc. It provides REST clients that don't support server-side streaming via keep-alive connections to use the streaming endpoint in the typical request/response pattern. The url just needs to contain ?no_inflight_updates=true and only the terminal response is sent back before the connection is closed.
Don't introduce a new term and align with the P in MPP.
This allows the older max number of accepted htlcs so that new nodes can open channels to older nodes.
This returns the older values of constants fixed by earlier commits, allowing nodes running the new code to open channels and complete payments through older nodes. Previously we had fixed some off-by-one errors in estimating the sizes of scripts and transactions. However this causes nodes using the new (correct) size estimates to be unable to open new channels to nodes running the older version. It also causes any payment attempts to fail due to invalid htlc signatures. This is caused by the size estimates changing the output amounts and therefore changing the transaction hash independently signed by individual nodes. We introduce a special constant that marks all instances where this happened.
Now that we've returned the older size estimates these can be re-enabled.
This makes the backends and the miner used in itests reject orphan transactions when they are relayed via the p2p network. This makes SPV tests similar to RPC ones, since RPC-submitted transactions are rejected when they are orphans.
This makes it so the store won't panic if a nil tx is specified in NotifyPublishTx(). In that situation, the last tx is deleted from the store.
Double spends of an input when we have already published a tx for them cause that previously published tx to become invalid. Dcrwallet in SPV mode however does not have a way of detecting that the tx has become invalid and would keep that tx in its store forever. Upon restarting the last published tx is sent through the wallet again, prompting its addition as an unconfirmed wallet, causing dcrwallet to maintain an erroneous balance forever. This improves the situation by making sure that upon receiving a spend notification of some swept input, we remove the last tx from the dcrlnd sweep store, ensuring that on the next restart this tx won't be republished.
This adds the AbandonDoubleSpends function to the WalletController interface and its implementations. This function will be used by the sweeper to remove transactions which have been made invalid by other transactions also getting confirmed.
This change makes the sweeper instruct wallet implementations to abandon any unconfirmed transactions which have become double spends due to some input being swept by some other transaction. This is necessary for dcrwallet's SPV implementation, which does not remove transactions from its store of unconfirmed txs when an input to an orphan tx gets double spent. This situation originated with commit anchor outputs which get swept by two different transactions at the same time. One of those two transactions gets confirmed, rendering the other one invalid. However, dcrwallet in SPV mode does not detect this situation, causing it to hold onto the (now invalid) transaction forever, bugging it's balance and utxo list forever. More technically, in non-SPV wallets, publishing the second transaction fails due to being an orphan, while in SPV mode the wallet ignores such errors from remote hosts and instead keeps the transaction in its store forever. This fixes the issue by using the previously introduced AbandonDoubleSpends API call to have the sweeper remove any transaction which it knows have now become invalid from the wallet store.
This makes it so that the test correctly waits for bob's commitment anchor sweep before proceeding, to reduce the possibility of a flake in the following mempool checks.
Hopefully this prevents a flake on this test when running on the CI. This was prompted by a unit-race failure for the following test: [error] TestMailBoxAddExpiry: mailbox_test.go:497: did not receive fail for index 0 --- FAIL: TestMailBoxAddExpiry (0.10s)
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 brings in the upstream lnd changes between v0.9.0-beta and v0.10.0-beta.
139 upstream PRs (plus a few non-PR'd commits) were considered for inclusion.
For reference, the upstream v0.10.0 release listed 26 named contributors.
This is currently rebased on top of PR #95 (with some not yet pushed changes). This has new itest flakes, some tests need to be re-enabled after being disabled during the porting process and it needs manual testing, specially of the new features.
I'm pushing it now so that it can be tracked by other devs and to mark the release of the new upstream version.