Block the mon update removing a preimage until upstream mon writes #2169
Conversation
This file contains hidden or 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
Codecov ReportPatch coverage:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2169 +/- ##
==========================================
+ Coverage 90.45% 92.23% +1.77%
==========================================
Files 112 111 -1
Lines 58566 69661 +11095
Branches 58566 69661 +11095
==========================================
+ Hits 52977 64253 +11276
+ Misses 5589 5408 -181
☔ View full report in Codecov by Sentry. |
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
304d811 to
c382bfd
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
3 times, most recently
from
70684b1 to
f17550b
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
f17550b to
428d162
Compare
|
Could you fix the build? thanks! |
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
428d162 to
720d840
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
720d840 to
e8cec7f
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
2 times, most recently
from
b30d299 to
a1517aa
Compare
|
Rebased on #2362 |
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
2 times, most recently
from
a78d620 to
e590021
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
e590021 to
8b53997
Compare
This was referenced Jul 5, 2023
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
8b53997 to
6dd2155
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
6dd2155 to
b247241
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
b247241 to
98dbe43
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
98dbe43 to
183e904
Compare
|
This should be good to go now. There's some followups that will be required for 117, but they're noted in the comments for now. |
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
c54b7b3 to
d48e624
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
d48e624 to
17bc1ee
Compare
|
Rebased. |
|
Generally LGTM. Will have another look after squash |
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
17bc1ee to
ca130b9
Compare
|
Squashed without further changes. |
When we need to rebroadcast a `commitment_signed` on reconnect in response to a previous update (ie not one which contains any updates) we previously hacked in support for it by passing a `-1` for the number of expected update_add_htlcs. This is a mess, and with the introduction of `ReconnectArgs` we can now clean it up easily with a new bool.
|
Rebased without changes. |
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
ca130b9 to
42536d2
Compare
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
42536d2 to
2754eb2
Compare
jkczyz
reviewed
Sep 12, 2023
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
2754eb2 to
5d9c602
Compare
jkczyz
reviewed
Sep 12, 2023
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
5d9c602 to
5b0ebdb
Compare
|
LGTM |
When we forward a payment and receive an `update_fulfill_htlc` message from the downstream channel, we immediately claim the HTLC on the upstream channel, before even doing a `commitment_signed` dance on the downstream channel. This implies that our `ChannelMonitorUpdate`s "go out" in the right order - first we ensure we'll get our money by writing the preimage down, then we write the update that resolves giving money on the downstream node. This is safe as long as `ChannelMonitorUpdate`s complete in the order in which they are generated, but of course looking forward we want to support asynchronous updates, which may complete in any order. Thus, here, we enforce the correct ordering by blocking the downstream `ChannelMonitorUpdate` until the upstream one completes. Like the `PaymentSent` event handling we do so only for the `revoke_and_ack` `ChannelMonitorUpdate`, ensuring the preimage-containing upstream update has a full RTT to complete before we actually manage to slow anything down.
`expect_payment_forwarded` takes a bool to indicate that the inbound channel on which we received a forwarded payment has been closed, but then ignores it in favor of looking at the fee in the event. While this is generally correct, in cases where we process an event after a channel was closed, which was generated before a channel closed this is incorrect. Instead, we examine the bool we already passed and use that.
Because some of these tests require connecting blocks without calling `get_and_clear_pending_msg_events`, we need to split up the block connection utilities to only optionally call sanity-checks.
Also allowing us to pass the event manually.
This adds a test for monitor update actions being completed on startup if a monitor update completed "while we were shut down" (or, really, the manager didn't get persisted after the update completed).
TheBlueMatt
force-pushed
the
2023-03-monitor-e-monitor
branch
from
5b0ebdb to
9f3e127
Compare
|
Squashed without further changes. |
jkczyz
approved these changes
Sep 12, 2023
valentinewallace
approved these changes
Sep 12, 2023
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.
When we forward a payment and receive an
update_fulfill_htlcmessage from the downstream channel, we immediately claim the HTLC
on the upstream channel, before even doing a
commitment_signeddance on the downstream channel. This implies that our
ChannelMonitorUpdates "go out" in the right order - first weensure we'll get our money by writing the preimage down, then we
write the update that resolves giving money on the downstream node.
This is safe as long as
ChannelMonitorUpdates complete in theorder in which they are generated, but of course looking forward we
want to support asynchronous updates, which may complete in any
order.
Thus, here, we enforce the correct ordering by blocking the
downstream
ChannelMonitorUpdateuntil the upstream one completes.Like the
PaymentSentevent handling we do so only for therevoke_and_ackChannelMonitorUpdate, ensuring thepreimage-containing upstream update has a full RTT to complete
before we actually manage to slow anything down.
This completes the work started in #2167 and depends on (and older version of) #2111 and #2112. This completes much of the work required for fully async ChannelMonitorUpdates. It introduces #2168, though I may try to fix that prior to marking ready, but its not super critical as even after this PR we do not "officially support" async ChannelMonitorUpdates.