Add support for swaps

- Also fix a bug where we wouldn't reject payments with non-matching rgb
  amounts

Co-Authored-By: Alekos Filini <alekos.filini@gmail.com>
Co-Authored-By: Daniela Brozzoni <danielabrozzoni@protonmail.com>

Author: 3 people

lightning/src/ln/channelmanager.rs

@@ -3157,15 +3157,15 @@ where
 				return_err!(err_msg, err_code, &[0; 0]);
 			},
 		};
-		let (outgoing_scid, outgoing_amt_msat, outgoing_cltv_value, next_packet_pk_opt) = match next_hop {
+		let (outgoing_scid, outgoing_amt_msat, outgoing_cltv_value, next_packet_pk_opt, outgoing_amount_rgb) = match next_hop {
 			onion_utils::Hop::Forward {
 				next_hop_data: msgs::InboundOnionPayload::Forward {
-					short_channel_id, amt_to_forward, outgoing_cltv_value, ..
+					short_channel_id, amt_to_forward, outgoing_cltv_value, rgb_amount_to_forward, ..
 				}, ..
 			} => {
 				let next_packet_pk = onion_utils::next_hop_pubkey(&self.secp_ctx,
 					msg.onion_routing_packet.public_key.unwrap(), &shared_secret);
-				(short_channel_id, amt_to_forward, outgoing_cltv_value, Some(next_packet_pk))
+				(short_channel_id, amt_to_forward, outgoing_cltv_value, Some(next_packet_pk), rgb_amount_to_forward)
 			},
 			// We'll do receive checks in [`Self::construct_pending_htlc_info`] so we have access to the
 			// inbound channel's state.
@@ -3187,7 +3187,8 @@ where
 					// phantom or an intercept.
 					if (self.default_configuration.accept_intercept_htlcs &&
 						fake_scid::is_valid_intercept(&self.fake_scid_rand_bytes, outgoing_scid, &self.chain_hash)) ||
-						fake_scid::is_valid_phantom(&self.fake_scid_rand_bytes, outgoing_scid, &self.chain_hash)
+						fake_scid::is_valid_phantom(&self.fake_scid_rand_bytes, outgoing_scid, &self.chain_hash) ||
+						fake_scid::is_valid_swap(outgoing_scid)
 					{
 						None
 					} else {
@@ -3249,6 +3250,20 @@ where
 				if let Err((err, code)) = chan.htlc_satisfies_config(&msg, outgoing_amt_msat, outgoing_cltv_value) {
 					break Some((err, code, chan_update_opt));
 				}
+				match (msg.amount_rgb, outgoing_amount_rgb) {
+					(Some(_), None) | (None, Some(_)) => {
+						// using amount_below_minimum error because there is no better error available
+						break Some(("Refusing to forward a non-authorized swap.", 0x1000 | 11, chan_update_opt));
+					},
+					(None, None) => {},
+					(Some(x), Some(y)) if x == y => {
+						log_trace!(self.logger, "Forwarding RGB payment of value: {}", x);
+					},
+					_ => {
+						// using amount_below_minimum error because there is no better error available
+						break Some(("Refusing to forward a payment with non-matching RGB amount", 0x1000 | 11, chan_update_opt)); // amount_below_minimum
+					}
+				}
 				chan_update_opt
 			} else {
 				if (msg.cltv_expiry as u64) < (outgoing_cltv_value) as u64 + MIN_CLTV_EXPIRY_DELTA as u64 {
@@ -3459,7 +3474,7 @@ where
 		let rgb_payment_info_hash_path = self.ldk_data_dir.join(htlc_payment_hash);
 		let path = if rgb_payment_info_hash_path.exists() {
 			let rgb_payment_info = parse_rgb_payment_info(&rgb_payment_info_hash_path);
-			if !rgb_payment_info.override_route_amount {
+			if rgb_payment_info.override_route_amount {
 				let mut path = path.clone();
 				for hop in &mut path.hops {
 					hop.rgb_amount = Some(rgb_payment_info.amount);

lightning/src/ln/onion_utils.rs

@@ -166,10 +166,26 @@ pub(super) fn construct_onion_keys<T: secp256k1::Signing>(secp_ctx: &Secp256k1<T
 }
 
 /// returns the hop data, as well as the first-hop value_msat and CLTV value we should send.
+// NOTE: This function is slightly different from the rust-lightning one, as we had to modify
+// it in order to support RGB swaps. More details:
+// We now split up the bitcoin amount into a fee part and a payment part: in non-RGB nodes the
+// bitcoin amount is always monotonically increasing when constructing the route in reverse
+// (notice the .rev() in the function): the receiver gets x, the previous hop gets
+// `x + <fee to fwd to receiver>`, the previous one gets `x + <fee to fwd to next> +
+// <fee to fwd to receiver>` and so on. So the original function could get away with only
+// having one accumulator cur_value_msat that would always increase.
+// Now with RGB, and specifically RGB swaps, we have scenarios where this assumption doesn't hold
+// true: for example, when we send a payment that is initially RGB and then bitcoin (i.e. the
+// user is buying an asset) this doesn't work. At some point in the route the bitcoin amount
+// will suddenly need to decrease, because one node in the path (the user's node) is
+// sending more bitcoin than it's actually receiving.
+// So the new logic splits fees and payment_amount. We only accumulate fees, and for every node in the "bitcoin side"
+// of the path we also set the payment_amount, while for the other nodes it will be 0.
 pub(super) fn build_onion_payloads(path: &Path, total_msat: u64, mut recipient_onion: RecipientOnionFields, starting_htlc_offset: u32, keysend_preimage: &Option<PaymentPreimage>) -> Result<(Vec<msgs::OutboundOnionPayload>, u64, u32, Option<u64>), APIError> {
-	let mut cur_value_msat = 0u64;
 	// The rgb_amount at the last hop
 	let mut last_amount_rgb = None;
+	let mut last_msat_amount = 0;
+	let mut cur_accumulated_fees = 0;
 	let mut cur_cltv = starting_htlc_offset;
 	let mut last_short_channel_id = 0;
 	let mut res: Vec<msgs::OutboundOnionPayload> = Vec::with_capacity(
@@ -180,8 +196,10 @@ pub(super) fn build_onion_payloads(path: &Path, total_msat: u64, mut recipient_o
 		// First hop gets special values so that it can check, on receipt, that everything is
 		// exactly as it should be (and the next hop isn't trying to probe to find out if we're
 		// the intended recipient).
-		let value_msat = if cur_value_msat == 0 { hop.fee_msat } else { cur_value_msat };
-		let value_rgb = hop.rgb_amount;
+		let (value_msat, value_rgb) = if last_msat_amount == 0 { (hop.fee_msat, hop.rgb_amount) } else {
+			cur_accumulated_fees += hop.fee_msat;
+			(last_msat_amount, last_amount_rgb)
+		};
 		let cltv = if cur_cltv == starting_htlc_offset { hop.cltv_expiry_delta + starting_htlc_offset } else { cur_cltv };
 		if idx == 0 {
 			if let Some(BlindedTail {
@@ -190,7 +208,6 @@ pub(super) fn build_onion_payloads(path: &Path, total_msat: u64, mut recipient_o
 				let mut blinding_point = Some(*blinding_point);
 				for (i, blinded_hop) in hops.iter().enumerate() {
 					if i == hops.len() - 1 {
-						cur_value_msat += final_value_msat;
 						cur_cltv += excess_final_cltv_expiry_delta;
 						res.push(msgs::OutboundOnionPayload::BlindedReceive {
 							amt_msat: *final_value_msat,
@@ -231,18 +248,19 @@ pub(super) fn build_onion_payloads(path: &Path, total_msat: u64, mut recipient_o
 				rgb_amount_to_forward: value_rgb,
 			});
 		}
-		cur_value_msat += hop.fee_msat;
-		if cur_value_msat >= 21000000 * 100000000 * 1000 {
+		last_amount_rgb = hop.rgb_amount;
+		last_msat_amount = hop.payment_amount + cur_accumulated_fees;
+
+		if last_msat_amount >= 21000000 * 100000000 * 1000 {
 			return Err(APIError::InvalidRoute{err: "Channel fees overflowed?".to_owned()});
 		}
 		cur_cltv += hop.cltv_expiry_delta as u32;
 		if cur_cltv >= 500000000 {
 			return Err(APIError::InvalidRoute{err: "Channel CLTV overflowed?".to_owned()});
 		}
 		last_short_channel_id = hop.short_channel_id;
-		last_amount_rgb = hop.rgb_amount;
 	}
-	Ok((res, cur_value_msat, cur_cltv, last_amount_rgb))
+	Ok((res, last_msat_amount, cur_cltv, last_amount_rgb))
 }
 
 /// Length of the onion data packet. Before TLV-based onions this was 20 65-byte hops, though now