Move pending-HTLC-updated ChannelMonitor from ManyChannelMonitor #474

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.

Sign up for GitHub

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

Jump to bottom

Merged

TheBlueMatt merged 2 commits into lightningdevkit:master from TheBlueMatt:2020-02-htlc-updated-in-monitors

Feb 21, 2020

Collaborator

TheBlueMatt commented Feb 4, 2020

This is important for a number of reasons:

Firstly, I hit this trying to implement rescan in the demo
bitcoinrpc client - if individual ChannelMonitors are out of
sync with each other, we cannot add them all into a
ManyChannelMonitor together and then rescan, but need to rescan
them individually without having to do a bunch of manual work.
Of the three return values in ChannelMonitor::block_connected,
only the HTLCsource stuff that is moved here makes no sense to
be exposed to the user.
Secondly, the logic currently in ManyChannelMonitor cannot be
reproduced by the user! HTLCSource is deliberately an opaque
type but we use its data to decide which things to keep when
inserting into the HashMap. This would prevent a user from
properly implementing a replacement ManyChannelMonitor, which is
unacceptable.
Finally, by moving the tracking into ChannelMonitor, we can
serialize them out, which prevents us from forgetting them when
loading from disk, though there are still other races which need
to be handled to make this fully safe (see TODOs in
ChannelManager).

This is safe as no two entries can have the same HTLCSource across
different channels (or, if they did, it would be a rather serious
bug), though note that, IIRC, when this code was added, the
HTLCSource field in the values was not present.

We also take this opportunity to rename the fetch function to match
our other event interfaces, makaing it clear that by calling the
function the set of HTLCUpdates will also be cleared.

CC @ariard. I dont think this should conflict too much with your existing work, as its a pretty straightforward on-its-own change.

TheBlueMatt force-pushed the 2020-02-htlc-updated-in-monitors branch from ff12ea9 to 3946b2a Compare

February 4, 2020 05:25

ariard commented Feb 4, 2020

Thanks for tackling this, IIRC when I did implement first htlc updates we agreed than the API was temporary so this should be a good improvement.

Conflicts are quite minor that's fine.

Collaborator Author

TheBlueMatt commented Feb 4, 2020 via email

Right, this design made sense pre-HTLCSource, now it makes none.

On Feb 4, 2020, at 02:36, Antoine Riard ***@***.***> wrote: Thanks for tackling this, IIRC when I did implement first htlc updates we agreed than the API was temporary so this should be a good improvement. Conflicts are quite minor that's fine. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

TheBlueMatt force-pushed the 2020-02-htlc-updated-in-monitors branch from 3946b2a to e4a7efd Compare

February 5, 2020 01:37

This was referenced Feb 6, 2020

Move to a Monitor-Update return from copying around ChannelMonitors #387

Closed

Track the full list of outpoints a chanmon wants monitoring for #455

Merged

TheBlueMatt force-pushed the 2020-02-htlc-updated-in-monitors branch from e4a7efd to 380c822 Compare

February 12, 2020 20:55

ariard reviewed

View reviewed changes

ariard left a comment

IMO a good occasion to add more reorg test coverage.

lightning/src/ln/channelmonitor.rs Outdated

		@@ -628,6 +593,8 @@ pub struct ChannelMonitor<ChanSigner: ChannelKeys> {

		payment_preimages: HashMap<PaymentHash, PaymentPreimage>,

		pending_htlcs_updated: HashMap<PaymentHash, Vec<(HTLCSource, Option<PaymentPreimage>)>>,

ariard Feb 14, 2020

"Buffer of reorg-safe(ANTI_REORG_DELAY) solved htlcs waiting to be passed upstream to the off-chain state machine. Note hash of HTLC may be duplicated on the network the real_id of HTLC should be short_channel_id+htlc_id+payment_hash".

lightning/src/ln/channelmonitor.rs Outdated

               		}
               	}
-              	fn block_connected(&mut self, txn_matched: &[&Transaction], height: u32, block_hash: &Sha256dHash, broadcaster: &BroadcasterInterface, fee_estimator: &FeeEstimator)-> (Vec<(Sha256dHash, Vec<TxOut>)>, Vec<SpendableOutputDescriptor>, Vec<(HTLCSource, Option<PaymentPreimage>, PaymentHash)>) {
+              	fn append_htlc_updated(&mut self, mut htlc_updated_infos: Vec<(HTLCSource, Option<PaymentPreimage>, PaymentHash)>) {
+              		// ChannelManager will just need to fetch pending_htlcs_updated and pass state backward

ariard Feb 14, 2020

Update comment.

lightning/src/ln/channelmonitor.rs Outdated

+              				hash_map::Entry::Occupied(mut e) => {
+              					// In case of reorg we may have htlc outputs solved in a different way so
+              					// we prefer to keep claims but don't store duplicate updates for a given
+              					// (payment_hash, HTLCSource) pair.

ariard Feb 14, 2020

Hmmmm in fact comment isn't that much accurate, if we assume ANTI_REORG_DELAY is safe, the only reason we have this logic is because block-rescan else we shouldn't get the update thanks to onchain_events_waiting_threshold_conf.

lightning/src/ln/channelmonitor.rs Outdated

+              					// (payment_hash, HTLCSource) pair.
+              					let mut existing_claim = false;
+              					e.get_mut().retain(|htlc_data| {
+              						if htlc.0 == htlc_data.0 {

ariard Feb 14, 2020

"If HTLC is already solved...and we have preimage don't update...if we have a timeout update...if hash1 == hash2 keep hash1 solution"

lightning/src/ln/channelmonitor.rs Outdated

    
            @@ -2560,7 +2581,7 @@ impl<ChanSigner: ChannelKeys> ChannelMonitor<ChanSigner> {
          
              					},

              					OnchainEvent::HTLCUpdate { htlc_update } => {

              						log_trace!(self, "HTLC {} failure update has got enough confirmations to be passed upstream", log_bytes!((htlc_update.1).0));

              						htlc_updated.push((htlc_update.0, None, htlc_update.1));

              						self.append_htlc_updated(vec![(htlc_update.0, None, htlc_update.1)]);

ariard Feb 14, 2020

The buffer onchain_events_waiting_threshold_conf is design such than it should be reorg-safe to pass unfriendly state backward, but I think we don't test the first-seeing-timeout-but-then-a-preimage case (check test pair test_htlc_on_chain_success/test_htlc_on_chain_timeout). If so would be great to add test.

TheBlueMatt added this to the 0.0.10 milestone

TheBlueMatt force-pushed the 2020-02-htlc-updated-in-monitors branch from 380c822 to 26aafd0 Compare

February 19, 2020 05:21

Collaborator Author

TheBlueMatt commented Feb 19, 2020

Right, good points - as you pointed out having an HashMap for it is now completely useless, so I just dropped that whole complexity and added a (somewhat) basic test. Let me know if this solved all your comments.

TheBlueMatt force-pushed the 2020-02-htlc-updated-in-monitors branch from 26aafd0 to 0d0558a Compare

February 19, 2020 18:57

TheBlueMatt mentioned this pull request

Move to a Monitor-Update return from copying around ChannelMonitors #489

Merged

ariard reviewed

View reviewed changes

ariard left a comment

Code is good but I think some new tests are redundant

lightning/src/ln/reorg_tests.rs

+              		}
+              		header = BlockHeader { version: 0x20000000, prev_blockhash: Default::default(), merkle_root: Default::default(), time: 42, bits: 42, nonce: 42 };
+              		nodes[1].block_notifier.block_connected(&Block { header, txdata: claim_txn }, CHAN_CONFIRM_DEPTH + 1);

ariard Feb 20, 2020

Why no connect just one block here ? should be enough

Collaborator Author

TheBlueMatt Feb 21, 2020

We do only connect one block here? We just connect it at height CHAN_CONFIRM_DEPTH + 1.

lightning/src/ln/reorg_tests.rs

+              	} else {
+              		// Confirm the timeout tx and check that we fail the HTLC backwards
+              		header = BlockHeader { version: 0x20000000, prev_blockhash: header.bitcoin_hash(), merkle_root: Default::default(), time: 42, bits: 42, nonce: 42 };
+              		nodes[1].block_notifier.block_connected_checked(&header, CHAN_CONFIRM_DEPTH + ANTI_REORG_DELAY, &vec![], &[0; 0]);

ariard Feb 20, 2020

Why not connect ANTI_REORG_DELAY blocks here?

Collaborator Author

TheBlueMatt Feb 21, 2020

We already connected ANTI_REORG_DELAY - 1 blocks above, this is just the last one to get it to ANTI_REORG_DELAY.

lightning/src/ln/reorg_tests.rs

+              	do_test_onchain_htlc_reorg(true, true);
+              }
+              #[test]
+              fn test_onchain_htlc_timeout_delay_local_commitment() {

ariard Feb 20, 2020

I think both local/remote cases are already covered by test_htlc_on_chain_timeout?

Collaborator Author

TheBlueMatt Feb 21, 2020

Hmm, probably. I still like checking that the one-block-difference is exactly the same but does something different. If you really feel strongly I can remove it.

TheBlueMatt force-pushed the 2020-02-htlc-updated-in-monitors branch from 0d0558a to bc52283 Compare

February 21, 2020 00:44

TheBlueMatt added 2 commits

February 20, 2020 20:31


          Move pending-HTLC-updated ChannelMonitor from ManyChannelMonitor

5e43070

This is important for a number of reasons:
 * Firstly, I hit this trying to implement rescan in the demo
   bitcoinrpc client - if individual ChannelMonitors are out of
   sync with each other, we cannot add them all into a
   ManyChannelMonitor together and then rescan, but need to rescan
   them individually without having to do a bunch of manual work.
   Of the three return values in ChannelMonitor::block_connected,
   only the HTLCsource stuff that is moved here makes no sense to
   be exposed to the user.
 * Secondly, the logic currently in ManyChannelMonitor cannot be
   reproduced by the user! HTLCSource is deliberately an opaque
   type but we use its data to decide which things to keep when
   inserting into the HashMap. This would prevent a user from
   properly implementing a replacement ManyChannelMonitor, which is
   unacceptable.
 * Finally, by moving the tracking into ChannelMonitor, we can
   serialize them out, which prevents us from forgetting them when
   loading from disk, though there are still other races which need
   to be handled to make this fully safe (see TODOs in
   ChannelManager).

This is safe as no two entries can have the same HTLCSource across
different channels (or, if they did, it would be a rather serious
bug), though note that, IIRC, when this code was added, the
HTLCSource field in the values was not present.

We also take this opportunity to rename the fetch function to match
our other event interfaces, makaing it clear that by calling the
function the set of HTLCUpdates will also be cleared.


          Test basic HTLC claim behavior from monitor -> manager on reorg

d296360

TheBlueMatt force-pushed the 2020-02-htlc-updated-in-monitors branch from bc52283 to d296360 Compare

February 21, 2020 01:32

ariard commented Feb 21, 2020

TheBlueMatt merged commit 697b479 into lightningdevkit:master

TheBlueMatt mentioned this pull request

Rewrite lightning-net-tokio using async/await and tokio 0.2 #472

Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11

TheBlueMatt mentioned this pull request

Move events into ChannelMonitor from ManyChannelMonitor #520

Merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet