adds node_id to Event::Payment{Received, Claimed} #1766

tee8z · 2022-10-12T18:20:21Z

adds 'our_node_id' to 'Event::Payment{Received,Claimed}' and includes updates to functional test cases

Hopefully we were looking for 'our_node_id' and not the counterparty, but please correct me if that assumption is wrong. Also, right now the node_id is wrapped in an Option just to make the default easier, but can look into making it so it is not wrapped. Thank you for any review.

TheBlueMatt · 2022-10-12T18:27:16Z

lightning/src/util/events.rs

@@ -631,6 +635,7 @@ impl Writeable for Event {
 					(4, amount_msat, required),
 					(6, 0u64, required), // user_payment_id required for compatibility with 0.0.103 and earlier
 					(8, payment_preimage, option),
+					(10, node_id, required),


New fields should (generally) be odd and generally an , option rather than , required. required implies we'll reject existing data (as we fail to deserialize if its missing) and even id implies old versions of LDK will refuse to read the data serialized by new versions, whereas odd allows them to ignore it.

TheBlueMatt · 2022-10-12T18:27:46Z

lightning/src/util/events.rs

@@ -249,6 +249,8 @@ pub enum Event {
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	/// [`ChannelManager::fail_htlc_backwards`]: crate::ln::channelmanager::ChannelManager::fail_htlc_backwards
 	PaymentReceived {
+		/// The received node, ie whether the node was a phantom node or not.
+		node_id: Option<PublicKey>,


I feel like we could communicate more details with the name here - something like our_received_node_id or something like that that communicates that its our node_id rather than the node_id of the peer that forwarded the payment to us.

codecov-commenter · 2022-10-12T18:44:44Z

Codecov Report

Base: 90.70% // Head: 90.58% // Decreases project coverage by -0.11% ⚠️

Coverage data is based on head (69dbad1) compared to base (53eb0d7).
Patch coverage: 81.63% of modified lines in pull request are covered.

❗ Current head 69dbad1 differs from pull request most recent head babde3a. Consider uploading reports for the commit babde3a to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1766      +/-   ##
==========================================
- Coverage   90.70%   90.58%   -0.12%     
==========================================
  Files          91       91              
  Lines       47967    48009      +42     
  Branches    47967    48009      +42     
==========================================
- Hits        43508    43489      -19     
- Misses       4459     4520      +61

Impacted Files	Coverage Δ
lightning/src/util/events.rs	`25.36% <37.50%> (-0.14%)`	⬇️
lightning/src/ln/channelmanager.rs	`85.06% <80.95%> (-1.28%)`	⬇️
lightning-invoice/src/utils.rs	`95.20% <100.00%> (-0.01%)`	⬇️
lightning/src/ln/chanmon_update_fail_tests.rs	`97.61% <100.00%> (+0.02%)`	⬆️
lightning/src/ln/functional_test_utils.rs	`93.65% <100.00%> (-0.07%)`	⬇️
lightning/src/ln/functional_tests.rs	`97.02% <100.00%> (ø)`
lightning/src/ln/onion_route_tests.rs	`97.49% <100.00%> (ø)`
lightning/src/ln/payment_tests.rs	`98.77% <0.00%> (-0.13%)`	⬇️
... and 14 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

tee8z · 2022-10-12T19:00:17Z

Both very valid points, updated code based on feedback

tnull

Generally looks good.

Also, right now the node_id is wrapped in an Option just to make the default easier, but can look into making it so it is not wrapped.

Are you referring to a default value for serialization? If so, you should be able to make the field a PublicKey and use the Option<PublicKey> wrapping only in a temporary variable in the serialization logic.

tee8z · 2022-10-12T19:48:29Z

Generally looks good.

Also, right now the node_id is wrapped in an Option just to make the default easier, but can look into making it so it is not wrapped.

Are you referring to a default value for serialization? If so, you should be able to make the field a PublicKey and use the Option<PublicKey> wrapping only in a temporary variable in the serialization logic.

I changed the logic to follow this, it seems I either need to make the 'our_node_Id' be an Option<> and mark it as 'option' in write_tlv_fields! & read_tlv_fields! or have it not be wrapped and set it as 'required'. Please let me know what the preferred approach is here, I can see a case for either.

tnull · 2022-10-12T20:16:22Z

I changed the logic to follow this, it seems I either need to make the 'our_node_Id' be an Option<> and mark it as 'option' in write_tlv_fields! & read_tlv_fields! or have it not be wrapped and set it as 'required'. Please let me know what the preferred approach is here, I can see a case for either.

Ugh, I think you're right. We're probably just should to make it an Option, even if it's kind of unfortunate for a field that will always be there going forward. Sorry for the confusion.

tee8z · 2022-10-13T12:51:22Z

Reverted the last commit to keep the 'our_node_id' as optional to not break existing clients of the library.

tnull · 2022-10-14T14:46:03Z

lightning/src/util/events.rs

@@ -249,6 +249,8 @@ pub enum Event {
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	/// [`ChannelManager::fail_htlc_backwards`]: crate::ln::channelmanager::ChannelManager::fail_htlc_backwards
 	PaymentReceived {
+		/// The node that recieved the payment, ie our node


nit:

Suggested change

/// The node that recieved the payment, ie our node

/// The node that received the payment, i.e., our node.

Is this field always going to be populated with "our" node id?

I was wondering if there is merit in the "our" prefix here if that's the case.

Good point, also the variable name should therefore maybe be called receiver_node_id?

maybe I should drop the i.e., our node part of the comment as well as change the variable name to receiver_node_id?

Yeah, seems reasonable, otherwise you could change it to something along the lines of e.g., our local node or a phantom node.

tnull · 2022-10-14T14:51:11Z

lightning/src/ln/functional_test_utils.rs

@@ -1380,9 +1380,10 @@ macro_rules! expect_payment_received {
 		let events = $node.node.get_and_clear_pending_events();
 		assert_eq!(events.len(), 1);
 		match events[0] {
-			$crate::util::events::Event::PaymentReceived { ref payment_hash, ref purpose, amount_msat } => {
+			$crate::util::events::Event::PaymentReceived {ref payment_hash, ref purpose, amount_msat, our_node_id } => {


nit:

Suggested change

$crate::util::events::Event::PaymentReceived {ref payment_hash, ref purpose, amount_msat, our_node_id } => {

$crate::util::events::Event::PaymentReceived { ref payment_hash, ref purpose, amount_msat, our_node_id } => {

tnull · 2022-10-14T14:52:15Z

lightning/src/util/events.rs

@@ -273,6 +275,8 @@ pub enum Event {
 	///
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	PaymentClaimed {
+		/// The node that recieved the payment, ie our node


nit:

Suggested change

/// The node that recieved the payment, ie our node

/// The node that received the payment, i.e., our node.

jurvis · 2022-10-14T15:40:58Z

lightning/src/util/events.rs

 				19u8.write(writer)?;
 				write_tlv_fields!(writer, {
 					(0, payment_hash, required),
 					(2, purpose, required),
 					(4, amount_msat, required),
+					(6, our_node_id, option),


I believe this should be 7

jurvis · 2022-10-14T15:44:28Z

lightning/src/util/events.rs

@@ -249,6 +249,8 @@ pub enum Event {
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	/// [`ChannelManager::fail_htlc_backwards`]: crate::ln::channelmanager::ChannelManager::fail_htlc_backwards
 	PaymentReceived {
+		/// The node that recieved the payment, ie our node


Is this field always going to be populated with "our" node id?

I was wondering if there is merit in the "our" prefix here if that's the case.

tee8z · 2022-10-14T19:09:30Z

renamed our_node_id to receiver_node_id and updated the comments to reflect that change, along with addressed the nit comments.

jurvis

Non-blocking nit for me

jurvis · 2022-10-15T16:57:49Z

lightning/src/util/events.rs

@@ -612,7 +616,7 @@ impl Writeable for Event {
 				// We never write out FundingGenerationReady events as, upon disconnection, peers
 				// drop any channels which have not yet exchanged funding_signed.
 			},
-			&Event::PaymentReceived { ref payment_hash, ref amount_msat, ref purpose } => {
+			&Event::PaymentReceived { ref payment_hash, ref amount_msat, ref purpose, receiver_node_id } => {


nit: receiver_node_id doesn't need an explicit ref here, but may be nice for consistency.

tnull

Two tiny nits, LGTM otherwise.

tnull · 2022-10-16T06:44:35Z

lightning/src/util/events.rs

@@ -249,6 +249,8 @@ pub enum Event {
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	/// [`ChannelManager::fail_htlc_backwards`]: crate::ln::channelmanager::ChannelManager::fail_htlc_backwards
 	PaymentReceived {
+		/// The node that received the payment


nit:

Suggested change

/// The node that received the payment

/// The node that received the payment.

tnull · 2022-10-16T06:44:47Z

lightning/src/util/events.rs

@@ -273,6 +275,8 @@ pub enum Event {
 	///
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	PaymentClaimed {
+		/// The node that received the payment


nit:

Suggested change

/// The node that received the payment

/// The node that received the payment.

TheBlueMatt · 2022-10-17T16:35:41Z

lightning/src/ln/channelmanager.rs

@@ -3360,6 +3360,7 @@ impl<Signer: Sign, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelMana
 										} else if total_value == $payment_data.total_msat {
 											htlcs.push(claimable_htlc);
 											new_events.push(events::Event::PaymentReceived {
+												receiver_node_id: Some(self.our_network_pubkey),


I don't think we want our_node_pubkey universally. If we are receiving a phantom payment (see further up in this function for the phantom_shared_secret) we actually want to use the pubkey equivalent to self.keys_manager.get_node_secret(Recipient::PhantomNode);

We need to do something here like you did below. I think it probably makes sense to move the code block you have below up above and then you can just use the receiver_node_id in both places.

TheBlueMatt

The above goes for, I think, basically all the sites where we generate the event. We'll need to figure out if the payment is phantom based on the ClaimableHTLC object itself, I believe.

tnull

Did a quick pass, mostly some formatting nits.

tnull · 2022-11-18T17:08:07Z

lightning/src/util/events.rs

 					});
 					if purpose.is_none() { return Ok(None); }
+


nit: this line can be removed.

Suggested change

tnull · 2022-11-18T17:10:09Z

lightning/src/util/events.rs

 					read_tlv_fields!(reader, {
 						(0, payment_hash, required),
 						(2, purpose, ignorable),
 						(4, amount_msat, required),
+						(7, receiver_node_id, option),


This also probably should be the first available odd type, i.e., 1?

tnull · 2022-11-18T17:12:16Z

lightning/src/util/events.rs

 					let mut _user_payment_id = None::<u64>; // For compatibility with 0.0.103 and earlier
 					read_tlv_fields!(reader, {
 						(0, payment_hash, required),
 						(2, payment_secret, option),
 						(4, amount_msat, required),
 						(6, _user_payment_id, option),
 						(8, payment_preimage, option),
+						(11, receiver_node_id, option),


I have to eat my own words from above: This probably should be the first available odd type, i.e., 1? Sorry for any confusion here!

tnull · 2022-11-18T17:13:37Z

lightning/src/ln/channelmanager.rs

 											htlcs.push(claimable_htlc);
+											let mut receiver_node_id = self.our_network_pubkey;
+											if phantom_shared_secret.is_some(){


nit: add space

Suggested change

if phantom_shared_secret.is_some(){

if phantom_shared_secret.is_some() {

tnull · 2022-11-18T17:26:59Z

lightning/src/ln/channelmanager.rs

 														e.insert((purpose.clone(), vec![claimable_htlc]));
+														let mut receiver_node_id = Some(self.our_network_pubkey);
+														if phantom_shared_secret.is_some(){


nit: add space

Suggested change

if phantom_shared_secret.is_some(){

if phantom_shared_secret.is_some() {

tnull · 2022-11-18T17:28:40Z

lightning/src/ln/channelmanager.rs

+					let phantom_shared_secret = claimable_htlcs[0].prev_hop.phantom_shared_secret;
+					if phantom_shared_secret.is_some(){
+						let phantom_pubkey = args.keys_manager.get_node_id(Recipient::PhantomNode)
+										.expect("Failed to get node_id for phantom node recipient");


nit: remove space.

Suggested change

.expect("Failed to get node_id for phantom node recipient");

.expect("Failed to get node_id for phantom node recipient");

tnull · 2022-11-18T17:28:53Z

lightning/src/ln/channelmanager.rs

@@ -7487,6 +7510,13 @@ impl<'a, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref>
 				if let Some((payment_purpose, claimable_htlcs)) = claimable_htlcs.remove(&payment_hash) {
 					log_info!(args.logger, "Re-claiming HTLCs with payment hash {} as we've released the preimage to a ChannelMonitor!", log_bytes!(payment_hash.0));
 					let mut claimable_amt_msat = 0;
+					let mut receiver_node_id = Some(our_network_pubkey);
+					let phantom_shared_secret = claimable_htlcs[0].prev_hop.phantom_shared_secret;
+					if phantom_shared_secret.is_some(){


nit: add space.

Suggested change

if phantom_shared_secret.is_some(){

if phantom_shared_secret.is_some() {

tnull · 2022-11-18T17:29:22Z

lightning/src/ln/functional_test_utils.rs

@@ -1433,20 +1433,22 @@ macro_rules! expect_pending_htlcs_forwardable_from_events {
 		}
 	}}
 }
-
+// expect_payment_received!(&nodes[fwd_idx], payment_hash, payment_secret, payment_amt, payment_preimage_opt);


This line should probably be removed?

Suggested change

// expect_payment_received!(&nodes[fwd_idx], payment_hash, payment_secret, payment_amt, payment_preimage_opt);

tnull · 2022-11-18T17:42:09Z

lightning/src/util/events.rs

@@ -758,6 +770,7 @@ impl Writeable for Event {
 					(4, amount_msat, required),
 					(6, 0u64, required), // user_payment_id required for compatibility with 0.0.103 and earlier
 					(8, payment_preimage, option),
+					(11, receiver_node_id, option),


See other comments: should likely be 1.

tnull · 2022-11-18T17:42:14Z

lightning/src/util/events.rs

 				19u8.write(writer)?;
 				write_tlv_fields!(writer, {
 					(0, payment_hash, required),
 					(2, purpose, required),
 					(4, amount_msat, required),
+					(7, receiver_node_id, option),


See other comments: should likely be 1.

TheBlueMatt

This basically looks good to me! Can you squash the commits down into one or two logical commits and ensure your commit descriptions contain a bit more detail and dont have lines longer than 70-ish characters. Then we can get a second reviewer on this and land it!

TheBlueMatt · 2022-11-18T17:43:28Z

lightning/src/ln/channelmanager.rs

 											htlcs.push(claimable_htlc);
+											let mut receiver_node_id = self.our_network_pubkey;


Can you pull this and the next hunk out into code above the macro to DRY it up?

TheBlueMatt · 2022-11-18T17:43:42Z

lightning/src/ln/channelmanager.rs

+				let phantom_shared_secret = htlc.prev_hop.phantom_shared_secret;
+				if phantom_shared_secret.is_some(){
+					let phantom_pubkey = self.keys_manager.get_node_id(Recipient::PhantomNode)
+										.expect("Failed to get node_id for phantom node recipient");


nit: no need to indent this far.

tnull

Generally looks good and pretty close to being good to go.

One suggestion and a some formatting nits from my side, feel free to squash any additional changes you make right away so we can land this soon!

tnull · 2022-11-19T08:36:28Z

lightning/src/ln/channelmanager.rs

+								if phantom_shared_secret.is_some() {
+									receiver_node_id = self.keys_manager.get_node_id(Recipient::PhantomNode)
+										.expect("Failed to get node_id for phantom node recipient");
+								}


nit: Could re-add the blank line before the macro.

tnull · 2022-11-19T08:50:28Z

lightning/src/ln/channelmanager.rs

@@ -3526,8 +3532,16 @@ impl<M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelManager<M, T, K, F
 												match channel_state.claimable_htlcs.entry(payment_hash) {
 													hash_map::Entry::Vacant(e) => {
 														let purpose = events::PaymentPurpose::SpontaneousPayment(preimage);
+														let phantom_shared_secret = &claimable_htlc.prev_hop.phantom_shared_secret.clone();


The clone() and mut can be avoided here like so:

let is_phantom = claimable_htlc.prev_hop.phantom_shared_secret.is_some(); e.insert((purpose.clone(), vec![claimable_htlc])); let receiver_node_id = if is_phantom { let phantom_pubkey = self.keys_manager.get_node_id(Recipient::PhantomNode) .expect("Failed to get node_id for phantom node recipient"); Some(phantom_pubkey) } else { Some(self.our_network_pubkey) };

tnull · 2022-11-19T08:52:17Z

lightning/src/ln/functional_test_utils.rs

 				assert_eq!($expected_payment_hash, *payment_hash);
 				assert_eq!($expected_recv_value, amount_msat);
+				assert_eq!($expected_receiver_node_id, receiver_node_id.unwrap());
+


nit: Remove blank line.

tnull · 2022-11-19T08:55:27Z

lightning/src/util/events.rs

+		/// The node that received the payment.
+		/// This is useful to identify payments which were received via [phantom node payments].
+		/// This field will always be filled in when the event was generated by LDK versions 0.0.113 and above.
+		/// 


nit: Remove trailing whitespace.

Suggested change

///

///

tnull · 2022-11-19T08:57:17Z

lightning/src/util/events.rs

@@ -342,6 +342,12 @@ pub enum Event {
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	/// [`ChannelManager::fail_htlc_backwards`]: crate::ln::channelmanager::ChannelManager::fail_htlc_backwards
 	PaymentReceived {
+		/// The node that received the payment.
+		/// This is useful to identify payments which were received via [phantom node payments].
+		/// This field will always be filled in when the event was generated by LDK versions 0.0.113 and above.


We have a 100 character line width formatting guideline.It's not enforced strictly everywhere right now, but we try to improve the codebase where we touch it. So feel free to break at 100 chars. :)

tnull

LGTM, one tiny, non-blocking nit.

tnull · 2022-11-21T07:28:26Z

lightning/src/util/events.rs

@@ -342,6 +342,13 @@ pub enum Event {
 	/// [`ChannelManager::claim_funds`]: crate::ln::channelmanager::ChannelManager::claim_funds
 	/// [`ChannelManager::fail_htlc_backwards`]: crate::ln::channelmanager::ChannelManager::fail_htlc_backwards
 	PaymentReceived {
+		/// The node that received the payment.
+		/// This is useful to identify payments which were received via [phantom node payments].
+		/// This field will always be filled in when the event was generated by LDK 


Super-tiny nit: pushing versions to the next line here and below looks a bit off (and introduced trailing whitespaces again). Feel free to leave as is though, if no other changes are requested.

hmm, so maybe I just keep it as one long line? not sure where else in that sentence to break on to keep it under the desired character limit

Huh? If you'd keep "versions" on the previous line, my editor shows a line width of 92?

I was trying to follow this guideline: #1766 (review) but will update to move versions to the line below, no biggie

Ah, there is a difference for commit messages (the ones you enter when creating new commits in git), which should be shorter than 80 characters and the code line width, which should be shorter than 100 characters. I believe Matt was referring to the former in his comment, while I meant the latter. All just minor details/nits however :)

TheBlueMatt

When you squash, please shorten your commit title to no longer than ~70 chars, and any commit text should be wrapped around the same.

TheBlueMatt · 2022-11-21T17:47:58Z

lightning/src/ln/channelmanager.rs

+									receiver_node_id = self.keys_manager.get_node_id(Recipient::PhantomNode)
+										.expect("Failed to get node_id for phantom node recipient");
+								}
+


nit: excess whitespace on this line.

No, my point was that this line isn't actually blank, its got lots of whitespace (spaces/tabs) in it, ideally keep the line but make it blank.

TheBlueMatt · 2022-11-21T17:53:00Z

lightning/src/ln/channelmanager.rs

 														e.insert((purpose.clone(), vec![claimable_htlc]));
+														let mut receiver_node_id = Some(self.our_network_pubkey);


You should be able to entirely remove this hunk of code - the receiver_node_id calculated in the above hunk is still accessible here and can be reused.

Errr, I meant the entire if phantom_shared_secret.is_some() and everything hunk - we don't need to have any of that we already did it.

TheBlueMatt · 2022-11-25T19:40:44Z

I think this just needs #1766 (comment) addressed and it should be good to go!

tee8z mentioned this pull request Oct 12, 2022

Event::Payment{Received,Claimed} should have the node which received it #1750

Closed

TheBlueMatt reviewed Oct 12, 2022

View reviewed changes

tee8z requested a review from TheBlueMatt October 12, 2022 19:01

tnull linked an issue Oct 12, 2022 that may be closed by this pull request

Event::Payment{Received,Claimed} should have the node which received it #1750

Closed

tnull reviewed Oct 12, 2022

View reviewed changes

tee8z requested review from tnull and TheBlueMatt and removed request for TheBlueMatt and tnull October 12, 2022 19:50

tee8z requested review from tnull and TheBlueMatt and removed request for TheBlueMatt and tnull October 13, 2022 12:49

tnull reviewed Oct 14, 2022

View reviewed changes

jurvis reviewed Oct 14, 2022

View reviewed changes

tee8z force-pushed the event-node-received branch from 36bf056 to d474665 Compare October 14, 2022 19:08

tee8z requested review from tnull and removed request for TheBlueMatt October 14, 2022 19:09

tee8z force-pushed the event-node-received branch from d474665 to 674b0d2 Compare October 14, 2022 19:11

jurvis previously approved these changes Oct 15, 2022

View reviewed changes

tnull reviewed Oct 16, 2022

View reviewed changes

TheBlueMatt reviewed Oct 17, 2022

View reviewed changes

tee8z force-pushed the event-node-received branch 2 times, most recently from a40f5b3 to 9911e81 Compare November 18, 2022 17:04

tnull reviewed Nov 18, 2022

View reviewed changes

TheBlueMatt reviewed Nov 18, 2022

View reviewed changes

tee8z force-pushed the event-node-received branch 3 times, most recently from dd09b2d to 56851a0 Compare November 18, 2022 19:38

tee8z requested a review from tnull November 18, 2022 21:57

TheBlueMatt added Seeking Code Review and removed Seeking Code Review labels Nov 18, 2022

TheBlueMatt assigned tnull and TheBlueMatt Nov 18, 2022

tnull reviewed Nov 19, 2022

View reviewed changes

tee8z force-pushed the event-node-received branch 3 times, most recently from 0f956da to 242adaf Compare November 19, 2022 15:37

tnull previously approved these changes Nov 21, 2022

View reviewed changes

TheBlueMatt reviewed Nov 21, 2022

View reviewed changes

tee8z dismissed tnull’s stale review via e5fa4aa November 21, 2022 19:15

tee8z force-pushed the event-node-received branch 3 times, most recently from 69dbad1 to dd1e69c Compare November 21, 2022 19:19

tnull mentioned this pull request Nov 21, 2022

Expose the channel via which we received a payment #1856

Merged

tee8z force-pushed the event-node-received branch from dd1e69c to 9b3aa62 Compare November 28, 2022 13:35

adds 'receiver_node_id' to 'Event::Payment{Received,Claimed}'

babde3a

tee8z force-pushed the event-node-received branch from 9b3aa62 to babde3a Compare November 28, 2022 13:36

tnull approved these changes Nov 28, 2022

View reviewed changes

TheBlueMatt approved these changes Nov 28, 2022

View reviewed changes

TheBlueMatt merged commit 64b9e83 into lightningdevkit:main Nov 28, 2022

	/// The node that recieved the payment, ie our node
	/// The node that received the payment, i.e., our node.

	$crate::util::events::Event::PaymentReceived {ref payment_hash, ref purpose, amount_msat, our_node_id } => {
	$crate::util::events::Event::PaymentReceived { ref payment_hash, ref purpose, amount_msat, our_node_id } => {

	/// The node that received the payment
	/// The node that received the payment.

	if phantom_shared_secret.is_some(){
	if phantom_shared_secret.is_some() {

	.expect("Failed to get node_id for phantom node recipient");
	.expect("Failed to get node_id for phantom node recipient");

		htlcs.push(claimable_htlc);
		let mut receiver_node_id = self.our_network_pubkey;

		e.insert((purpose.clone(), vec![claimable_htlc]));
		let mut receiver_node_id = Some(self.our_network_pubkey);

adds node_id to Event::Payment{Received, Claimed} #1766

adds node_id to Event::Payment{Received, Claimed} #1766

Conversation

tee8z commented Oct 12, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov-commenter commented Oct 12, 2022 • edited Loading

Codecov Report

tee8z commented Oct 12, 2022

tnull left a comment

Choose a reason for hiding this comment

tee8z commented Oct 12, 2022

tnull commented Oct 12, 2022

tee8z commented Oct 13, 2022

tnull Oct 14, 2022 • edited Loading

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

tnull Oct 16, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tnull Oct 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tee8z commented Oct 14, 2022

jurvis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tnull 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

TheBlueMatt left a comment

Choose a reason for hiding this comment

tnull left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tnull Nov 18, 2022 • edited Loading

Choose a reason for hiding this comment

tnull Nov 18, 2022 • edited Loading

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

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

tnull 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

tnull 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

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

TheBlueMatt commented Nov 25, 2022

codecov-commenter commented Oct 12, 2022 •

edited

Loading

tnull Oct 14, 2022 •

edited

Loading

tnull Oct 16, 2022 •

edited

Loading

tnull Oct 14, 2022 •

edited

Loading

tnull left a comment •

edited

Loading

tnull Nov 18, 2022 •

edited

Loading

tnull Nov 18, 2022 •

edited

Loading