Handle receiving payments via Trampoline #3670

arik-so · 2025-03-17T11:36:32Z

This PR implements handling payment receives from Trampoline onions, but does not yet implement forwarding payments through Trampoline. It also adds tests for end-to-end payment scenarios, including both for single-hop Trampoline receives, as well as for multi-hop Trampoline forwards, thus also providing sufficient coverage to remove the cfg gating.

The overall set of Trampoline components can be tracked here.

ldk-reviews-bot · 2025-03-17T11:36:35Z

👋 Thanks for assigning @TheBlueMatt as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

lightning/src/ln/onion_payment.rs

valentinewallace · 2025-03-18T19:42:02Z

lightning/src/ln/onion_payment.rs

 			{
 				log_info!(logger, "Failed to accept/forward incoming HTLC: {}", $msg);
-				let (sha256_of_onion, failure_code) = if msg.blinding_point.is_some() {
+				let (sha256_of_onion, failure_code) = if $force_blinding_error || msg.blinding_point.is_some() {


Would it work to check the failure code for INVALID_ONION_BLINDING instead of having the extra argument?

yes, provided we never ever want to use that error code with non-zeroed data

If we always want to use it with zeroed data, why would the sha256 field for INVALID_ONION_BLINDING then be in the spec?

Right, hence my question :)

We'll only ever want to use zeroed data with this error code, which I think is just a special exception for update_malformeds for blinded HTLCs.

I modified it to infer the onion hash from the error code instead of adding an extra field.

valentinewallace · 2025-03-18T21:03:12Z

lightning/src/ln/onion_utils.rs

 					Ok((_, None)) => Err(OnionDecodeErr::Malformed {
 						err_msg: "Non-final Trampoline onion data provided to us as last hop",
-						// todo: find more suitable error code
-						err_code: 0x4000 | 22,
+						err_code: INVALID_ONION_BLINDING,
+						trampoline_onion_blinding: true,
 					}),
 					Ok((_, Some(_))) => Err(OnionDecodeErr::Malformed {
 						err_msg: "Final Trampoline onion data provided to us as intermediate hop",
-						// todo: find more suitable error code
-						err_code: 0x4000 | 22,
+						err_code: INVALID_ONION_BLINDING,
+						trampoline_onion_blinding: true,
 					}),


Somewhat annoying, but if we want to be accurate to the spec I believe we shouldn't be returning INVALID_ONION_BLINDING for non-blinded trampoline forward/receives, or for blinded receives where the intro blinding point is set. Apologies if I misunderstood some context on this when we discussed offline. I think if we matched on the specific variants instead of _ this change should be doable?

yeah, I was wondering about that lol. Trivial fix, no worries

valentinewallace · 2025-03-18T21:04:22Z

lightning/src/ln/msgs.rs

@@ -2080,7 +2080,7 @@ mod fuzzy_internal_msgs {
 	pub struct InboundTrampolineEntrypointPayload {
 		pub amt_to_forward: u64,
 		pub outgoing_cltv_value: u32,
-		pub multipath_trampoline_data: FinalOnionHopData,
+		pub multipath_trampoline_data: Option<FinalOnionHopData>,


Is this the discussion you're referring to in the commit message? lightning/bolts#836 (comment)

yup, exactly! @t-bast and I discussed it a bit offline, and I believe they're assessing Eclair code viability for not mandating it outside of MPP scenarios. Alternatively, I can also make it mandatory on the sending side (right now we have an internal mismatch), but I think this approach makes more sense for now.

I'd think that for simplicity, it may be better to just always set this field? One code path.

I'd agree, although it's all cfg-gated for now anyway I suppose... @arik-so was the reason for doing this now for ease of testing?

Partially. The other option would require us deciding on a mechanism to convert the prng_seed into a pseudo-random payment secret in the outgoing onion construction method, that's about it.

But generating that secret is something to be looked at when implementing the forwarding part isn't it? Isn't it best for now to stick with the proposed spec?

The spec did actually get updated this morning to make it optional for the outer onion.

Maybe should update the commit message then?

joostjager

I've been gathering more background knowledge on blinded paths and trampoline and did my best to review this PR. I feel I am still missing quite a few pieces, so wouldn't count me as a full reviewer.

joostjager · 2025-03-19T12:54:57Z

lightning/src/ln/msgs.rs

@@ -2080,7 +2080,7 @@ mod fuzzy_internal_msgs {
 	pub struct InboundTrampolineEntrypointPayload {
 		pub amt_to_forward: u64,
 		pub outgoing_cltv_value: u32,
-		pub multipath_trampoline_data: FinalOnionHopData,
+		pub multipath_trampoline_data: Option<FinalOnionHopData>,


I'd think that for simplicity, it may be better to just always set this field? One code path.

lightning/src/ln/onion_payment.rs

joostjager · 2025-03-19T13:11:33Z

lightning/src/ln/onion_payment.rs

 			{
 				log_info!(logger, "Failed to accept/forward incoming HTLC: {}", $msg);
-				let (sha256_of_onion, failure_code) = if msg.blinding_point.is_some() {
+				let (sha256_of_onion, failure_code) = if $force_blinding_error || msg.blinding_point.is_some() {


If we always want to use it with zeroed data, why would the sha256 field for INVALID_ONION_BLINDING then be in the spec?

joostjager · 2025-03-19T13:15:18Z

lightning/src/blinded_path/payment.rs

@@ -514,6 +514,24 @@ impl Writeable for ForwardTlvs {
 	}
 }

+#[cfg(trampoline)]
+impl Writeable for TrampolineForwardTlvs {


Add to commit msg why we need to serialize blinded trampoline fwds in the future and not yet now?

I adjusted the message.

Ah I meant explain why this code is needed now, besides unit tests? I got that it encodes tlv data.

If it's only for the unit test, maybe squash with the test? Or just leave as is, non blocking.

lightning/src/ln/onion_payment.rs

lightning/src/ln/blinded_payment_tests.rs

joostjager · 2025-03-19T13:38:04Z

lightning/src/ln/onion_payment.rs

+					InboundHTLCErr {
+						err_code: INVALID_ONION_BLINDING,
+						err_data: vec![0; 32],
+						msg: "Amount or cltv_expiry violated blinded payment constraints",


Mention trampoline in the msg?

Changed the message to mention Trampoline.

lightning/src/ln/blinded_payment_tests.rs

lightning/src/ln/onion_utils.rs

valentinewallace · 2025-03-25T20:24:26Z

lightning/src/ln/onion_utils.rs

@@ -1828,15 +1831,34 @@ where
 							trampoline_shared_secret,
 						),
 					}),
-					Ok((_, None)) => Err(OnionDecodeErr::Malformed {
+					Ok((msgs::InboundTrampolinePayload::BlindedForward(_), None)) => {


I'm not sure how much correct error handling actually matters here, but to be accurate to the spec we'd want to return Relay if the intro node blinding point is set IIUC. Looks pretty easy though:

diff --git a/lightning/src/ln/onion_utils.rs b/lightning/src/ln/onion_utils.rs index 45a9e7a09..eeb513319 100644 --- a/lightning/src/ln/onion_utils.rs +++ b/lightning/src/ln/onion_utils.rs @@ -1831,13 +1831,33 @@ where trampoline_shared_secret, ), }), - Ok((msgs::InboundTrampolinePayload::BlindedForward(_), None)) => { + Ok((msgs::InboundTrampolinePayload::BlindedForward(hop_data), None)) => { + if hop_data.intro_node_blinding_point.is_some() { + return Err(OnionDecodeErr::Relay { + err_msg: "Non-final intro node Trampoline onion data provided to us as last hop", + err_code: INVALID_ONION_BLINDING, + shared_secret, + trampoline_shared_secret: Some(SharedSecret::from_bytes( + trampoline_shared_secret, + )), + }) + } Err(OnionDecodeErr::Malformed { err_msg: "Non-final Trampoline onion data provided to us as last hop", err_code: INVALID_ONION_BLINDING, }) },

Good catch; I think in this scenario it should also be an invalid payload, so I adjusted it accordingly.

Ah since we're the intro node to the blinded path I believe we should still blind the error but just do Relay instead of Malformed, no?

adjusted the error code for being the intro node to a multi-hop blinded path

valentinewallace · 2025-03-25T20:26:19Z

lightning/src/ln/onion_utils.rs

+							err_code: INVALID_ONION_BLINDING,
+						})
+					},
+					Ok((msgs::InboundTrampolinePayload::BlindedReceive(_), Some(_))) => {


Somewhat similarly here -- if the intro node blinding point is set we want to return an unblinded error, because if we're a receiver and the intro node, the blinded path only had 1 hop to begin with so no need to blind the error:

diff --git a/lightning/src/ln/onion_utils.rs b/lightning/src/ln/onion_utils.rs index 45a9e7a09..a6a28ff3d 100644 --- a/lightning/src/ln/onion_utils.rs +++ b/lightning/src/ln/onion_utils.rs @@ -1837,7 +1837,17 @@ where err_code: INVALID_ONION_BLINDING, }) }, - Ok((msgs::InboundTrampolinePayload::BlindedReceive(_), Some(_))) => { + Ok((msgs::InboundTrampolinePayload::BlindedReceive(hop_data), Some(_))) => { + if hop_data.intro_node_blinding_point.is_some() { + return Err(OnionDecodeErr::Relay { + err_msg: "Final Trampoline intro node onion data provided to us as intermediate hop", + err_code: 0x4000 | 22, + shared_secret, + trampoline_shared_secret: Some(SharedSecret::from_bytes( + trampoline_shared_secret, + )), + }) + } Err(OnionDecodeErr::Malformed { err_msg: "Final Trampoline onion data provided to us as intermediate hop",

valentinewallace · 2025-03-25T20:27:40Z

lightning/src/ln/blinded_payment_tests.rs

+		).unwrap()
+	};
+
+


nit: extra newline

valentinewallace · 2025-03-25T20:36:14Z

lightning/src/ln/blinded_payment_tests.rs

+	nodes[0].node.send_payment_with_route(route.clone(), payment_hash, RecipientOnionFields::spontaneous_empty(), PaymentId(payment_hash.0)).unwrap();
+
+	let replacement_onion = {
+		// create a substitute onion where the last Trampoline hop is a forward


I think this is outdated now?

modified comment to apply to both the invalid onion and the unblinded receive

valentinewallace · 2025-03-25T20:48:59Z

lightning/src/ln/blinded_payment_tests.rs

+		// pop the last dummy hop
+		trampoline_payloads.pop();
+
+		trampoline_payloads.push(msgs::OutboundTrampolinePayload::Receive {


Maybe note that we don't support sending to unblinded trampolines which is why we need to do all this manual stuff

added a comment at the top of the replacement_onion block

valentinewallace · 2025-03-25T20:56:53Z

LGTM after last feedback is addressed. Fine with a squash

arik-so · 2025-03-25T23:54:35Z

I addressed your feedback, @valentinewallace, and squashed most things, but left two fixup commits where I suspect you might have further thoughts. Also a bit unsure about the last commit, which combines all the unit tests into one, but happy either way.

lightning/src/ln/onion_payment.rs

joostjager · 2025-03-26T18:13:23Z

lightning/src/ln/channelmanager.rs

@@ -5984,7 +5984,7 @@ where
 													onion_packet.hmac, payment_hash, None, &*self.node_signer
 												) {
 													Ok(res) => res,
-													Err(onion_utils::OnionDecodeErr::Malformed { err_msg, err_code }) => {
+													Err(onion_utils::OnionDecodeErr::Malformed { err_msg, err_code, .. }) => {


No longer necessary change?

indeed, removed

joostjager · 2025-03-26T18:21:26Z

lightning/src/ln/onion_utils.rs

+							err_code: INVALID_ONION_BLINDING,
+						})
+					},
+					Ok((_, None)) => Err(OnionDecodeErr::Relay {


Probably more clear to be explicit with these final two arms?
Ok((msgs::InboundTrampolinePayload::Forward(_) | msgs::InboundTrampolinePayload::Receive(_), None)) => Err(OnionDecodeErr::Relay {

you mean like this?

Ok(( msgs::InboundTrampolinePayload::Forward(_) | msgs::InboundTrampolinePayload::BlindedForward(_), None, )) => Err(OnionDecodeErr::Relay { err_msg: "Non-final Trampoline onion data provided to us as last hop", err_code: 0x4000 | 22, shared_secret, trampoline_shared_secret: Some(SharedSecret::from_bytes( trampoline_shared_secret, )), }), Ok(( msgs::InboundTrampolinePayload::Receive(_) | msgs::InboundTrampolinePayload::BlindedReceive(_), Some(_), )) => Err(OnionDecodeErr::Relay { err_msg: "Final Trampoline onion data provided to us as intermediate hop", err_code: 0x4000 | 22, shared_secret, trampoline_shared_secret: Some(SharedSecret::from_bytes( trampoline_shared_secret, )), }),

Yes. I was wondering what cases I was looking at, what was left. I think explicit makes it easier?

joostjager · 2025-03-26T18:26:30Z

lightning/src/ln/blinded_payment_tests.rs

@@ -127,7 +130,7 @@ pub fn fail_blinded_htlc_backwards(
 				let unblinded_node_updates = get_htlc_update_msgs!(nodes[i], nodes[i-1].node.get_our_node_id());
 				assert_eq!(unblinded_node_updates.update_fail_htlcs.len(), 1);
 				nodes[i-1].node.handle_update_fail_htlc(
-					nodes[i].node.get_our_node_id(), &unblinded_node_updates.update_fail_htlcs[i-1]
+					nodes[i].node.get_our_node_id(), &unblinded_node_updates.update_fail_htlcs[0]


This change looks like a bug fix, or is it part of the new functionality?

it is a bug fix I noticed in passing, shall I move it into a separate commit? I think since I stopped using this method for the test, I can remove it from the PR entirely and open a separate one

If it is independent, I think it is helpful to isolate in a commit or pr with some explanation.

removed the change from this PR

joostjager · 2025-03-26T18:35:17Z

lightning/src/ln/blinded_payment_tests.rs

@@ -2081,29 +2088,44 @@ fn do_test_trampoline_single_hop_receive(success: bool) {

 	check_added_monitors!(&nodes[0], 1);

-	if success {
+	if matches!(scenario, TrampolineSingleHopReceiveCheck::SuccessfulBlindedReceive) {


Hmm yes the scenario value seems to push this to the point where it becomes hard to read. I'd say: just acceptable? There are probably other ways to compose a test from reusable building blocks, but maybe not worth it now.

Yeah perhaps I should just drop the final commit.

Dropped the scenario commit.

joostjager · 2025-03-26T18:36:48Z

lightning/src/ln/blinded_payment_tests.rs

-	// Simulate a payment failure of A (0) -> B (1) -> C(Trampoline (blinded forward)) (2)
-	do_test_trampoline_single_hop_receive(false);
-}
+	do_test_trampoline_single_hop_receive(TrampolineSingleHopReceiveCheck::SuccessfulBlindedReceive);


Is there currently a test covering the forwarding operation of trampoline node? It's not yet implemented, but to assert that nothing weird happens if we receive a forward?

Especially without the cfg flag.

there isn't, but then again, what should happen if we receive it prior to supporting it? I think this is actually a good argument to simply remove it in the subsequent PR instead.

Added a test ensuring sane behavior when receiving a Trampoline forward hop.

lightning/src/ln/onion_utils.rs

lightning/src/ln/blinded_payment_tests.rs

joostjager · 2025-03-26T22:02:32Z

Add something as a PR description - or maybe the title is self-explanatory?

arik-so · 2025-03-26T22:05:18Z

Hm, I need to think of what description would be more than just a rephrasing of the title, but I can probably come up with something.

joostjager · 2025-03-26T22:09:52Z

Perhaps something about what is and isn't supported yet and a link to a follow up issue or the parent issue? That's something at least...

TheBlueMatt

LGTM, I think? I mean nothing stands out.

TheBlueMatt · 2025-03-27T14:50:51Z

lightning/src/ln/msgs.rs

@@ -2080,7 +2080,7 @@ mod fuzzy_internal_msgs {
 	pub struct InboundTrampolineEntrypointPayload {
 		pub amt_to_forward: u64,
 		pub outgoing_cltv_value: u32,
-		pub multipath_trampoline_data: FinalOnionHopData,
+		pub multipath_trampoline_data: Option<FinalOnionHopData>,


Maybe should update the commit message then?

valentinewallace · 2025-03-27T17:00:27Z

ci/ci-tests.sh

@@ -134,8 +134,6 @@ RUSTFLAGS="--cfg=taproot" cargo test --verbose --color always -p lightning
 [ "$CI_MINIMIZE_DISK_USAGE" != "" ] && cargo clean
 RUSTFLAGS="--cfg=splicing" cargo test --verbose --color always -p lightning
 [ "$CI_MINIMIZE_DISK_USAGE" != "" ] && cargo clean
-RUSTFLAGS="--cfg=trampoline" cargo test --verbose --color always -p lightning


I'm not following the commit message here in 908c6bf since we don't support trampoline forwarding yet?

ah, it ensures that receiving forwarding onions results in a rejection, but not a panic or some undefined behavior. I'll rephrase.

Ok Joost explained that we test that we don't support forwarding basically

joostjager · 2025-03-27T17:21:54Z

lightning/src/ln/blinded_payment_tests.rs

+	}
+	{
+		let payment_failed_conditions = PaymentFailedConditions::new()
+			.expected_htlc_error_data(0x4000 | 10, &[0; 0]);


Add comment what this error code is?

added comment

valentinewallace

Nothing blocking :)

valentinewallace · 2025-03-27T17:37:19Z

lightning/src/ln/channelmanager.rs

-			#[cfg(trampoline)]
 			onion_utils::Hop::TrampolineReceive { .. } | onion_utils::Hop::TrampolineBlindedReceive { .. } => {
 				// OUR PAYMENT!


Can we DRY this now with the other OUR PAYMENT! case?

good point. CI's far from finished anyway, so I pushed the squashed fixup

valentinewallace · 2025-03-27T17:53:38Z

lightning/src/ln/msgs.rs

@@ -3391,7 +3361,6 @@ impl<NS: Deref> ReadableArgs<(Option<PublicKey>, NS)> for InboundOnionPayload wh
 	}
 }

-#[cfg(trampoline)]
 impl<NS: Deref> ReadableArgs<(Option<PublicKey>, NS)> for InboundTrampolinePayload where NS::Target: NodeSigner {


It's kind of a shame to keep this duplicated with InboundOnionPayload since the code is complex and ~identical, but might be best to save this consideration for follow-up so we can get this in

ah, that one saw a lot of back and forth, and I agree, but the alternative is clunky, too, and loses the benefit of semantic distinction

valentinewallace · 2025-03-27T17:57:31Z

lightning/src/ln/onion_utils.rs

+							err_code: INVALID_ONION_BLINDING,
+						})
+					},
+					Ok((msgs::InboundTrampolinePayload::Forward(_), None)) => {


I like that these variants are spelled out explicitly now, reads more obviously correct 👍

valentinewallace · 2025-03-27T18:07:24Z

lightning/src/ln/blinded_payment_tests.rs

+
+	check_added_monitors!(&nodes[0], 1);
+
+	// Check that we've queued the HTLCs of the async keysend payment.


nit: I don't think this is a keysend payment?

In this PR, we add end-to-end tests for Trampoline receive and forwarding behavior (specifically rejection of payments for the latter), ensuring sanity, no unexpected errors, and obviating the cfg-gating.

Per the resolution of the spec discussion regarding the requirement of this field outside MPP scenarios, we are now marking this field as optional.

Trivial fix where the Trampoline hop TLV inside blinded contexts differs from un-blinded ones.

It does not need to be a macro, so we convert it into a simple lambda.

When a blinded hop fails to decode, we send a special malformed error. However, we previously simply checked the presence of a blinding point within the `UpdateAddHTLC` message, which is not necessarily applicable to Trampoline, so now we additionally return a flag if the error stemmed from an inner onion's blinded hop decoding failure.

We will need the ability to serialize blinded Trampoline forwards to construct their encrypted TLV data from its unencrypted state using `construct_blinded_hops`, which initially we only do in unit tests.

Handle payment receives with payment details located inside an inner onion.

In the next PR, we will be adding support for forwarding payments between Trampoline hops. Until we do that, forwarding payments need to be rejected, which we test in this commit.

joostjager

LGTM with the remark that my mental model of LDK still isn't complete enough to be fully confident

valentinewallace

With Matt's LGTM we should be good to land when CI passes!

arik-so mentioned this pull request Mar 17, 2025

Trampoline #2299

Open

30 tasks

ldk-reviews-bot requested a review from valentinewallace March 17, 2025 11:47

joostjager reviewed Mar 17, 2025

View reviewed changes

lightning/src/ln/onion_payment.rs Show resolved Hide resolved

joostjager reviewed Mar 17, 2025

View reviewed changes

lightning/src/ln/onion_payment.rs Show resolved Hide resolved

arik-so force-pushed the arik/trampoline/receive branch 2 times, most recently from e7f6810 to 52497a2 Compare March 17, 2025 20:42

arik-so requested a review from joostjager March 18, 2025 21:02

valentinewallace reviewed Mar 18, 2025

View reviewed changes

arik-so force-pushed the arik/trampoline/receive branch from 52497a2 to b7f927e Compare March 18, 2025 21:56

joostjager reviewed Mar 19, 2025

View reviewed changes

arik-so force-pushed the arik/trampoline/receive branch 2 times, most recently from 3574d7d to 8e70d5e Compare March 24, 2025 16:47

joostjager reviewed Mar 24, 2025

View reviewed changes

lightning/src/ln/blinded_payment_tests.rs Outdated Show resolved Hide resolved

arik-so force-pushed the arik/trampoline/receive branch 2 times, most recently from 4e07aff to 6df45ce Compare March 25, 2025 19:23

valentinewallace reviewed Mar 25, 2025

View reviewed changes

arik-so force-pushed the arik/trampoline/receive branch from 6df45ce to 6132b1b Compare March 25, 2025 23:52

arik-so requested review from joostjager and valentinewallace March 26, 2025 17:05

joostjager reviewed Mar 26, 2025

View reviewed changes

lightning/src/ln/onion_payment.rs Show resolved Hide resolved

joostjager reviewed Mar 26, 2025

View reviewed changes

arik-so force-pushed the arik/trampoline/receive branch from 6132b1b to 07d7640 Compare March 26, 2025 18:54

joostjager reviewed Mar 26, 2025

View reviewed changes

lightning/src/ln/onion_utils.rs Show resolved Hide resolved

arik-so force-pushed the arik/trampoline/receive branch 2 times, most recently from 40c7e03 to 32a35a1 Compare March 26, 2025 21:41

arik-so requested a review from joostjager March 26, 2025 21:43

joostjager reviewed Mar 26, 2025

View reviewed changes

lightning/src/ln/blinded_payment_tests.rs Outdated Show resolved Hide resolved

arik-so force-pushed the arik/trampoline/receive branch from 32a35a1 to 65bdb4e Compare March 26, 2025 22:00

arik-so requested a review from TheBlueMatt March 26, 2025 22:03

TheBlueMatt reviewed Mar 27, 2025

View reviewed changes

arik-so force-pushed the arik/trampoline/receive branch from 65bdb4e to 7f5cd2b Compare March 27, 2025 16:51

valentinewallace reviewed Mar 27, 2025

View reviewed changes

joostjager reviewed Mar 27, 2025

View reviewed changes

arik-so force-pushed the arik/trampoline/receive branch from 7f5cd2b to a827324 Compare March 27, 2025 17:27

valentinewallace previously approved these changes Mar 27, 2025

View reviewed changes

arik-so dismissed valentinewallace’s stale review via 2b6a6d7 March 27, 2025 18:22

arik-so force-pushed the arik/trampoline/receive branch from a827324 to 2b6a6d7 Compare March 27, 2025 18:22

arik-so added 9 commits March 27, 2025 11:24

Remove Trampoline config flag

4741892

In this PR, we add end-to-end tests for Trampoline receive and forwarding behavior (specifically rejection of payments for the latter), ensuring sanity, no unexpected errors, and obviating the cfg-gating.

Make Trampoline inbound MPP data optional

0c82cc2

Per the resolution of the spec discussion regarding the requirement of this field outside MPP scenarios, we are now marking this field as optional.

Fix blinded Trampoline TLV IDs

a293d21

Trivial fix where the Trampoline hop TLV inside blinded contexts differs from un-blinded ones.

De-macro return_malformed_err

313f344

It does not need to be a macro, so we convert it into a simple lambda.

Implement Writeable for TrampolineForwardTlvs

dc14f26

We will need the ability to serialize blinded Trampoline forwards to construct their encrypted TLV data from its unencrypted state using `construct_blinded_hops`, which initially we only do in unit tests.

Handle Trampoline receives

35ff142

Handle payment receives with payment details located inside an inner onion.

Test unblinded Trampoline receives

a6f4c7f

Test rejection of Trampoline forwards

3970f1d

In the next PR, we will be adding support for forwarding payments between Trampoline hops. Until we do that, forwarding payments need to be rejected, which we test in this commit.

arik-so force-pushed the arik/trampoline/receive branch from 2b6a6d7 to 3970f1d Compare March 27, 2025 18:25

joostjager approved these changes Mar 27, 2025

View reviewed changes

valentinewallace approved these changes Mar 27, 2025

View reviewed changes


		check_added_monitors!(&nodes[0], 1);

		// Check that we've queued the HTLCs of the async keysend payment.

Handle receiving payments via Trampoline #3670

Are you sure you want to change the base?

Handle receiving payments via Trampoline #3670

Conversation

arik-so commented Mar 17, 2025 • edited Loading

ldk-reviews-bot commented Mar 17, 2025 • 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

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

joostjager 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

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

valentinewallace commented Mar 25, 2025

arik-so commented Mar 25, 2025

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

joostjager Mar 26, 2025 • 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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager commented Mar 26, 2025

arik-so commented Mar 26, 2025

joostjager commented Mar 26, 2025

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

valentinewallace 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

arik-so commented Mar 17, 2025 •

edited

Loading

ldk-reviews-bot commented Mar 17, 2025 •

edited

Loading

joostjager Mar 26, 2025 •

edited

Loading