Implement claiming of revoked HTLC transactions by ChannelMonitor #163

ariard · 2018-09-08T02:39:40Z

Still working on others parts of #137. Implement claiming of revoked HTLC-Success/HTLC-timeout transactions in check_spend_remote_transaction that as I understand the TODO was all about ?
Will add/finish test in ChannelManager with others commits tomorrow.

ariard · 2018-09-08T02:40:27Z

src/ln/channelmonitor.rs

+						total_value += tx.output[0].value;
+					}
+
+					key_materials.push((redeemscript, per_commitment_key));


Buffering key materials to create only one transaction even if inputs are from unrelated commitment_tx

I'm not sure this is necessary - there cant be two inputs pointing to two different remote_commitment_txn_on_chain as the commitment txn would be double-spends.

TheBlueMatt

At first glance looks good, maybe replace the TODO comment with a comment describing what we're doing here, but definitely needs tests (All the claim stuff needs more tests, but at least adding new cases should get tested).

TheBlueMatt · 2018-09-08T14:38:55Z

src/ln/channelmonitor.rs

+
+
+					if tx.output[0].script_pubkey == revokeable_p2wsh { //HTLC transactions have one txin, one txout
+						inputs.push(TxIn {


You should try to honor the CLTV_SHARED_CLAIM_BUFFER here - splitting out inputs into separate transactions if they expire too soon.

Hmmmm in case of HTLC-Success/Timeout transactions aren't we more affected by CSV delay ? If so I think we want to follow the same delay buffer as for a CLTV but we maybe need to update comment of CLTV_SHARED_CLAIM_BUFFER. And here, if it's HTLC-Success/Timemout transactions, I think we can only have one input so no case of multi-inputs to separate ?

TheBlueMatt · 2018-09-08T14:40:41Z

src/ln/channelmonitor.rs

+						total_value += tx.output[0].value;
+					}
+
+					key_materials.push((redeemscript, per_commitment_key));


I'm not sure this is necessary - there cant be two inputs pointing to two different remote_commitment_txn_on_chain as the commitment txn would be double-spends.

ariard · 2018-09-11T02:00:27Z

src/ln/channelmanager.rs

 		let mut node_txn = node.tx_broadcaster.txn_broadcasted.lock().unwrap();
-		assert!(node_txn.len() >= if commitment_tx.is_some() { 0 } else { 1 } + if has_htlc_tx == HTLCType::NONE { 0 } else { 1 });
+		assert!(node_txn.len() >= if has_htlc_tx == HTLCType::NONE { 0 } else { 1 } + if has_penalty_tx == PenaltyType::NONE { 0 } else { 1 });


I removed the commitment_tx ternary has it's wasn't making sense on revoked_tx case, but tell me on this and other changes of test_txn_broadcast, maybe more assert! needed

ariard · 2018-09-11T02:01:43Z

src/ln/channelmonitor.rs

 		}

 		(txn_to_broadcast, (commitment_txid, watch_outputs))
 	}

+	/// Attempst to claim a remote HTLC-Success/HTLC-Timeout s outputs using the revocation key
+	fn check_spend_remote_htlc(&self, tx: &Transaction, commitment_number: u64) -> Vec<Transaction> {


Was refactored mainly to avoid double-locking of remote_commitment_tx_on_chain as block_connected has only them to match HTLC transactions, so a part of old commit was moved there.

ariard · 2018-09-11T02:05:30Z

With set_their_delayed_payment_base_key as I think Channel passing it to monitor at channel opening is the only way to get it ?
ChannelMonitor still needs more tests, for example the ones on remote ouputs from revoked commit tx I believe, will open a checked box on #137 to map all cases.

TheBlueMatt

Awesome! Nice work!

TheBlueMatt · 2018-09-12T15:25:17Z

src/ln/channel.rs

@@ -563,6 +563,7 @@ impl Channel {
 		                                              &chan_keys.htlc_base_key,
 		                                              BREAKDOWN_TIMEOUT, our_channel_monitor_claim_script);
 		channel_monitor.set_their_htlc_base_key(&msg.htlc_basepoint);
+		channel_monitor.set_their_delayed_payment_base_key(&msg.delayed_payment_basepoint);


Why not just merge this with set_their_htlc_base_key? They're always called together anyway...

Good idea, done

TheBlueMatt · 2018-09-12T15:38:40Z

src/ln/channelmonitor.rs

+
+		let mut txn_to_broadcast = Vec::new();
+
+		let commitment_txid = tx.txid(); //TODO: This is gonna be a performance bottleneck for watchtowers!


Its not a commitment tx :p

TheBlueMatt · 2018-09-12T15:39:17Z

src/ln/channelmonitor.rs

 		}

 		(txn_to_broadcast, (commitment_txid, watch_outputs))
 	}

+	/// Attempst to claim a remote HTLC-Success/HTLC-Timeout s outputs using the revocation key
+	fn check_spend_remote_htlc(&self, tx: &Transaction, commitment_number: u64) -> Vec<Transaction> {
+


nit: why the space here?

a mine dumb copy-paste!

TheBlueMatt · 2018-09-12T15:40:46Z

src/ln/channelmonitor.rs

-						broadcaster.broadcast_transaction(tx);
+				} else {
+					let remote_commitment_txn_on_chain = self.remote_commitment_txn_on_chain.lock().unwrap();
+					for (txid, commitment_number) in remote_commitment_txn_on_chain.iter() {


remote_commitment_txn_on_chain is a HashMap, so you should be able to do a get instead of an iter() over the whole thing.

TheBlueMatt · 2018-09-12T15:42:13Z

src/ln/channelmonitor.rs

 		for tx in txn_matched {
 			for txin in tx.input.iter() {
 				if self.funding_txo.is_none() || (txin.previous_output.txid == self.funding_txo.as_ref().unwrap().0.txid && txin.previous_output.vout == self.funding_txo.as_ref().unwrap().0.index as u32) {
-					let (mut txn, new_outputs) = self.check_spend_remote_transaction(tx, height);
+					let (mut remote_txn, new_outputs) = self.check_spend_remote_transaction(tx, height);
+					txn.append(&mut remote_txn);


Why append instead of just txn = remote_txn? Are you accidentally calling broadcast_transaction for txn from multiple ChannelMonitors multiple times? Maybe move txn into the per-tx loop?

Modified, but you mean broadcasting in per-tx loop ? Does it change something for broadcaster?

TheBlueMatt · 2018-09-12T16:51:50Z

src/ln/channelmanager.rs

@@ -3108,9 +3108,11 @@ mod tests {

 	#[derive(PartialEq)]
 	enum HTLCType { NONE, TIMEOUT, SUCCESS }
-	fn test_txn_broadcast(node: &Node, chan: &(msgs::ChannelUpdate, msgs::ChannelUpdate, [u8; 32], Transaction), commitment_tx: Option<Transaction>, has_htlc_tx: HTLCType) -> Vec<Transaction> {
+	#[derive(PartialEq)]
+	enum PenaltyType { NONE, COMMIT, HTLC }


Is COMMIT PenaltyType unused? Looks like its somewhat duplicative with the revoked_tx option?

Drop it for now but I think I'm gonna use in a next commit to test spending of remote outputs on revoked commitment tx

TheBlueMatt · 2018-09-12T17:03:28Z

src/ln/channelmanager.rs

@@ -3126,7 +3128,9 @@ mod tests {
 				}
 			}
 		}
-		assert_eq!(res.len(), 1);
+		if revoked_tx.is_none() {


Why not just check against revoked is_none() and PenaltyType is HTLC so you check the call is doing something (and doesn't change existing logic).

Modified, but you mean against revoked_is_some() right?

TheBlueMatt · 2018-09-12T17:03:42Z

src/ln/channelmanager.rs

@@ -3145,6 +3149,21 @@ mod tests {
 			}
 			assert_eq!(res.len(), 2);
 		}
+
+		if has_penalty_tx == PenaltyType::HTLC {
+			if let Some(revoked_tx) = revoked_tx {


Maybe just unwrap() to make sure the caller is sane? This is a test.....

Needed to build redeemscript on HTLC-Success/HTLC-Timeout tx from remote revoked commitment tx

Refactor check_spend_remote_transaction in part to check_spend_remote_htlc to avoid lock mess in block_connected. We need remote_commitment_txn_on_chain to match remote HTLC tx

tx

Optimize some ChannelMonitor stuff after #163

ariard commented Sep 8, 2018

View reviewed changes

TheBlueMatt reviewed Sep 8, 2018

View reviewed changes

ariard force-pushed the claim_revoked_htlc_tx branch 3 times, most recently from 7d07498 to f52f666 Compare September 11, 2018 01:58

ariard commented Sep 11, 2018

View reviewed changes

TheBlueMatt reviewed Sep 12, 2018

View reviewed changes

Antoine Riard added 3 commits September 12, 2018 23:17

Implement set_their_delayed_payment_base_key in ChannelMonitor

d84c084

Needed to build redeemscript on HTLC-Success/HTLC-Timeout tx from remote revoked commitment tx

Implement claiming of revoked HTLC transactions by ChannelMonitor

3e149b1

Refactor check_spend_remote_transaction in part to check_spend_remote_htlc to avoid lock mess in block_connected. We need remote_commitment_txn_on_chain to match remote HTLC tx

Add test of claiming HTLC-Timeout outputs based on a revoked commitment

383bd90

tx

ariard force-pushed the claim_revoked_htlc_tx branch from f52f666 to 383bd90 Compare September 12, 2018 23:57

TheBlueMatt merged commit 01c8e4f into lightningdevkit:master Sep 13, 2018

TheBlueMatt mentioned this pull request Sep 13, 2018

Optimize some ChannelMonitor stuff after #163 #177

Merged

TheBlueMatt added a commit that referenced this pull request Sep 14, 2018

Merge pull request #177 from TheBlueMatt/2018-09-163-cleanups

e323c13

Optimize some ChannelMonitor stuff after #163

TheBlueMatt mentioned this pull request Sep 21, 2021

Include total fee paid in PaymentSent #999

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement claiming of revoked HTLC transactions by ChannelMonitor #163

Implement claiming of revoked HTLC transactions by ChannelMonitor #163

ariard commented Sep 8, 2018

ariard Sep 8, 2018

TheBlueMatt Sep 8, 2018

TheBlueMatt left a comment

TheBlueMatt Sep 8, 2018

ariard Sep 9, 2018

TheBlueMatt Sep 8, 2018

ariard Sep 11, 2018

ariard Sep 11, 2018

ariard commented Sep 11, 2018

TheBlueMatt left a comment

TheBlueMatt Sep 12, 2018

ariard Sep 12, 2018

TheBlueMatt Sep 12, 2018

TheBlueMatt Sep 12, 2018

ariard Sep 12, 2018

TheBlueMatt Sep 12, 2018

TheBlueMatt Sep 12, 2018

ariard Sep 13, 2018

TheBlueMatt Sep 12, 2018

ariard Sep 13, 2018

TheBlueMatt Sep 12, 2018

ariard Sep 13, 2018

TheBlueMatt Sep 12, 2018



		if tx.output[0].script_pubkey == revokeable_p2wsh { //HTLC transactions have one txin, one txout
		inputs.push(TxIn {


		let mut txn_to_broadcast = Vec::new();

		let commitment_txid = tx.txid(); //TODO: This is gonna be a performance bottleneck for watchtowers!

Implement claiming of revoked HTLC transactions by ChannelMonitor #163

Implement claiming of revoked HTLC transactions by ChannelMonitor #163

Conversation

ariard commented Sep 8, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ariard commented Sep 11, 2018

TheBlueMatt left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment