-
Notifications
You must be signed in to change notification settings - Fork 412
Handle sizeable push msat (fix #195) + handle two first per_commitment_point + keys interface tests #230
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
Merged
TheBlueMatt
merged 13 commits into
lightningdevkit:master
from
ariard:handle_sizeable_push_msat
Nov 20, 2018
Merged
Handle sizeable push msat (fix #195) + handle two first per_commitment_point + keys interface tests #230
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
04e6be9
Implement spendable output to_local output on local commitment tx
8c638ff
Track local_commitment_tx at funding_created
f88f826
Add TxOut in DynamicOutput
f053169
Add test_claim_sizeable_push_msat
1b33064
Split provide_their_next_commitment_point from provide_secret
3518f1f
Add test_static_spendable_outputs_preimage_tx
1255885
Add check_spend_closing_transaction ChannelMonitor
e22220d
Add test_claim_on_remote_sizeable_push_msat
73415a8
Add test_static_spendable_outputs_justice_tx_revoked_commitment_tx
b6b5dec
Add test_static_spendable_outputs_justice_tx_revoked_htlc*
394b11c
Add key_storage selection in ChannelMonitor insert_combine
890d176
Add test_dynamic_spendable_outputs_local_htlc_*
3a7b40e
Add test_static_output_closing_tx
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think this split may be simpler by just moving the their_next_revocation_point tracking into provide_latest_remote_commitment_tx_info. We only ever use the revocation point in case we have remote_tx_info available corresponding to it, so it should be way simpler to just move it there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure for this one... firstly we get per_commitment_point from remote at time we don't/didn't have generate remote commitment tx (accept_channel/new_from_req/funding_locked) and secondly we may use revocation point to generate pubkeys without per_commitment_option (htlcs_outputs) in case of sizeable push_msat?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm? You mean you intend to add some use for their_cur_revocation_points beyond what its used for now, right now its only ever used in conjunction with remote_claimable_outpoints data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes exactly, see deacb3f, in case of to_remote ouput you don't need remote_claimable_outpoints but you still need per_commitment_point to derive your remoteprivatekey. If I get derivation scheme right, but please review it thoroughly, that's easy to mess this part