Add support for phantom node payments #1199

valentinewallace · 2021-12-01T23:29:32Z

Based on #1177

Some open questions left as TODOs

A phantom node payment is a payment made to a phantom invoice, which is an invoice that can be
paid to one of multiple nodes. This works because we encode the invoice route hints such that
LDK will recognize an incoming payment as destined for a phantom node, and collect the payment
itself without ever needing to forward to this fake node.

Phantom node payments are useful for load balancing between multiple LDK nodes. They also
provide some fault tolerance, because payers will automatically retry paying other provided
nodes in the case that one node goes down.

Note that multi-path payments are not supported in phantom invoices for security reasons.

lightning/src/ln/channelmanager.rs

jkczyz · 2021-12-15T18:20:13Z

At a high-level, could you describe what is meant by "multi-node receive" and what properties it is meant to achieve vs a single node?

valentinewallace · 2022-01-03T18:57:37Z

Will push docs updates and some more tests next, wanted to get the code out there.

valentinewallace · 2022-01-05T00:18:20Z

At a high-level, could you describe what is meant by "multi-node receive" and what properties it is meant to achieve vs a single node?

Updated the docs, hopefully this is answered!

TheBlueMatt

One high level comment.

lightning/src/ln/onion_utils.rs

TheBlueMatt · 2022-01-05T20:15:15Z

lightning/src/ln/channelmanager.rs

-				amt_to_forward: next_hop_data.amt_to_forward,
-				outgoing_cltv_value: next_hop_data.outgoing_cltv_value,
-			})
+				let phantom_secret_res = self.keys_manager.get_phantom_secret(short_channel_id);


Hmmmmmmm, I do wonder if we should care about "any third party can identify if a hop is a phantom node or not". If its too hard to do, we can probably call it a wash and not bother, but I'd ideally like to at least try to obfuscate it first. I think it should be pretty reasonable here - instead of decoding the second onion here immediately we instead push the HTLC through PendingHTLCStatus::Forward first, which means we wait until we've gotten it fully committed in the channel and then do this second-step decode in process_pending_htlc_forwards where we look up the SCID in the loop.

Added passing it through process_pending_htlc_forwards rather than decoding the second onion immediately.

"any third party can identify if a hop is a phantom node or not"

To be clear, this is a timing attack?

To be clear, this is a timing attack?

Yes. Hopefully pushing it through the normal forward-batching, in theory, implies timing is similar across forward-one-hop's and no-forward, but its probably still wide enough just with the skipping of network RTTs and disk updates that we should tell users they can expect a counterparty to detect the difference.

joostjager · 2022-01-17T12:36:00Z

lightning/src/chain/keysinterface.rs

@@ -1094,6 +1131,11 @@ impl KeysInterface for KeysManager {
 	fn sign_invoice(&self, invoice_preimage: Vec<u8>) -> Result<RecoverableSignature, ()> {
 		Ok(self.secp_ctx.sign_recoverable(&hash_to_message!(&Sha256::hash(&invoice_preimage)), &self.get_node_secret()))
 	}
+
+	fn get_phantom_secret(&self, _scid: u64) -> Result<SecretKey, ()> {
+		let hkdf = hkdf_extract_expand(b"LDK Phantom Node Secret Key Expansion", &self.inbound_payment_key.0, 1);


Is it the idea to later include the fake scid as a term in the generation of the phantom node key?

Idea is that it's up to the implementer of KeysInterface. Adding the scid parameter adds the flexibility if they want to do it that way

joostjager · 2022-01-17T12:46:11Z

lightning-invoice/src/utils.rs

+					base_msat: 0,
+					proportional_millionths: 0,
+				},
+				cltv_expiry_delta: MIN_CLTV_EXPIRY_DELTA,


If I understand this right, the phantom hop will increase the total time lock across the whole route. Is that necessary?

True. One priority is that we don't want to make it obvious at-a-glance that an invoice is for a phantom node, so this does help with that I think

Makes sense

TheBlueMatt

Few quick comments will continue review later.

lightning/src/ln/channelmanager.rs

TheBlueMatt · 2022-01-18T16:36:35Z

lightning/src/ln/channelmanager.rs

+			let scid_namespace = self.as_u8();
+			let rand_bytes = keys_manager.get_secure_random_bytes();
+
+			let valid_block_range = highest_seen_blockheight - segwit_activation_height(genesis_hash);


I don't think we should include block heights all the way up to the current height - I believe there's a race for users connecting blocks via Access - they can tell us about a new block before telling us about all the transactions in the block. Technically we don't have any constraints on the user at all (ie they could provide the transactions 1000 blocks later), but in practice its probably fine to just subtract, like, a day (1008) and assume we won't select a fake SCID for a channel that we haven't seen the confirmation for yet.

TheBlueMatt · 2022-01-18T17:14:15Z

lightning/src/ln/channelmanager.rs

 		});
+		if phantom_scid_namespace.is_none() {
+			phantom_scid_namespace = Some(fake_scid::Namespace::phantom(&args.keys_manager));


Shouldn't we store a u8 offset instead of picking a value for phantoms specifically. Instead of storing a value for each namespace, we store one "offset" and then when we want to know a namespace's value, we just add the offset and mod by MAX_NAMESPACES.

Do you mean we should store the 32-byte random value that we got the namespace from (in fake_scid::Namespace::phantom), and use it for all namespaces?

I think we should just store the 3-bit modulo value, no? Like, instead of phantom namespace being a specific value, we define phantom to be 0 and others to increment by 1, with a random offset for the whole thing (mod 8)

TheBlueMatt

All quite straightforward now, I love this.

TheBlueMatt · 2022-01-18T19:49:37Z

lightning/src/chain/keysinterface.rs

 	fn get_inbound_payment_key_material(&self) -> KeyMaterial;
+
+	/// Get the phantom node secret key for use in receiving a [phantom node payment].


I found this a bit confusing, can we explicitly say "aka node_id or network_key" like we do for get_node_secret and describe how this is the secret key which signs invoices?

lightning/src/chain/keysinterface.rs

TheBlueMatt · 2022-01-18T19:54:04Z

lightning/src/chain/keysinterface.rs

-				let mut inbound_pmt_key_bytes = [0; 32];
-				inbound_pmt_key_bytes.copy_from_slice(&inbound_payment_key[..]);
+				let inbound_payment_key = if let Some(key) = inbound_payment_key_opt {
+					key


bleh, quite the layer violation - if we're returning the key material to ChannelManager as-is and letting ChannelManager do derivation magic on it, we should definitely not be doing some derivation on it ourselves. Instead, lets pass in a cross_node_seed or something that is then derived into both a inbound_payment_key and a phantom_secret directly. This avoids any (ok, admittedly far-fetched, but still) use of the same derivation in ChannelManager leading to key re-use (eg if ChannelManager decides to derive a key called "LDK Phandom Node Secret Key Expansion).

Hmm, seems like it may be awkward to change the derivation of the inbound_payment_key given it's already used in the wild. Is it fine if some payments fail due to this change?

Ah, right, hmmmmm, no that wouldn't be great. Maybe we should separate out how it works based on the constructor used? For the new constructor we can just refuse to generate phantom secret?

Implemented this

lightning/src/ln/channelmanager.rs

rloomba · 2022-01-20T00:13:41Z

lightning-invoice/src/utils.rs

+///
+/// `channels` contains a list of tuples of `(phantom_node_scid, real_node_pubkey,
+/// real_channel_details)`, where `phantom_node_scid` is unique to each `channels` entry and should
+/// be retrieved freshly for each new invoice from [`ChannelManager::get_phantom_scid`].


So let's say there are 3 nodes that would like to accept a single invoice, each time create_phantom_invoice (on a single node) is called, would the caller need to ping the other two nodes to get fresh phantom scids + usable channels to include in this channels list? So channel list would be a concatenated list of channels from the three nodes? If each of the 3 nodes had 2 open channels, the list size could be a size of 6?

Trying to make this as clear as possible:

/// `channels` contains a list of tuples of `(phantom_node_scid, real_node_pubkey, /// real_channel_details)`, where `phantom_node_scid` is unique to each `channels` entry and should /// be retrieved freshly for each new invoice from [`ChannelManager::get_phantom_scid`]. /// `real_channel_details` comes from [`ChannelManager::list_channels`]. For multiple nodes, /// `channels` will be a concatenated list of entries from each node, as each node must provide a fresh /// `phantom_scid` and `real_channel_details` for all usable channels on each new invoice generation.

Thanks, sorry the docs are pretty WIP. Will prioritize shoring them up.

each time create_phantom_invoice (on a single node) is called, would the caller need to ping the other two nodes to get fresh phantom scids + usable channels to include in this channels list?

You don't have to retrieve fresh phantom scids on each invoice. Doing so provides more privacy, but it's optional! Fine to cache them.

If some of the provided real channels aren't usable, that could obviously result in failed payment attempts, but since channels don't close too frequently it should be fine to just poll and cache, not fetch freshly on each invoice.

So channel list would be a concatenated list of channels from the three nodes? If each of the 3 nodes had 2 open channels, the list size could be a size of 6?

Yup! The parameters could probably be a little cleaner (suggestions welcome here) though somewhat limited by our bindings generator

Fine to cache them

sweet, good to know!

Yup! The parameters could probably be a little cleaner (suggestions welcome here) though somewhat limited by our bindings generator

List of tuples makes sense to me. I think if we clarify what can be cached + the fact that the list of tuples can be formed from multiple nodes that would be good.

Maybe also a warning about including too many channels, as that might make the invoice string too long for QR codes?

codecov-commenter · 2022-01-21T21:57:07Z

Codecov Report

Merging #1199 (710954f) into main (963f8d9) will increase coverage by 0.00%.
The diff coverage is 88.46%.

@@           Coverage Diff            @@
##             main    #1199    +/-   ##
========================================
  Coverage   90.51%   90.51%            
========================================
  Files          71       72     +1     
  Lines       39210    39560   +350     
========================================
+ Hits        35490    35809   +319     
- Misses       3720     3751    +31

Impacted Files	Coverage Δ
lightning-invoice/src/lib.rs	`88.25% <0.00%> (+0.83%)`	⬆️
lightning/src/ln/channel.rs	`89.33% <0.00%> (ø)`
lightning/src/chain/keysinterface.rs	`93.58% <77.35%> (-2.29%)`	⬇️
lightning/src/util/test_utils.rs	`82.44% <83.33%> (+0.18%)`	⬆️
lightning/src/ln/channelmanager.rs	`84.45% <84.24%> (-0.14%)`	⬇️
lightning-invoice/src/utils.rs	`88.14% <91.48%> (+4.07%)`	⬆️
lightning/src/ln/onion_utils.rs	`95.33% <92.30%> (-0.31%)`	⬇️
lightning/src/util/scid_utils.rs	`98.37% <97.87%> (-1.63%)`	⬇️
lightning-background-processor/src/lib.rs	`93.04% <100.00%> (ø)`
lightning/src/ln/functional_test_utils.rs	`95.23% <100.00%> (ø)`
... and 7 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 963f8d9...710954f. Read the comment docs.

joostjager · 2022-01-22T14:24:59Z

lightning-invoice/src/utils.rs

+			_ => panic!("Unexpected event"),
+		}
+		match events[1] {
+			Event::PaymentReceived { payment_hash: ref hash, ref purpose, amt } => {


The way this is set up, does that work too for multi-part payments to a phantom invoice where the parts come in via distinct real nodes?

No. In theory we could adapt it to work with users doing the work to claim across nodes, but I'm not sure what the use-case there is? All the nice "node offline -> seamless fallback to other nodes" stuff suddenly doesn't work. You still get shared liquidity, but that feels like it could just as easily be done with a single node at that point, no?

Senders are free to choose routes right? So they may decide to use a different final hop towards the phantom node for some of the parts. I don't think you can force them not to, and they also won't be aware that they shouldn't.

One thing that I can think of is when node A doesn't have enough (cheap) liquidity and the sender decides to split the payment to also use up some of node B's liquidity.

An alternative design is to make the phantom node a stand-alone process that communicates with each of the gateway nodes and is backed by a replicated database?

No, you can't force them not to, but you can disable MPP, which accomplishes the same :)

The sender may be short on liquidity towards their peers and might only be able to complete the payment via MPP.

If you run a business that is big enough to require a multi-node setup, I'd think it is undesirable to force all customers to pay in single shots only?

It depends entirely on the amount being sent. Indeed, it may not be desirable to use phantom nodes for large value payments, but public stats on lightning usage seem to point to very small payments being the norm, which I'd think are more than fine. Further, it depends a lot on the user - if someone is running a full-fledged node they may have less liquidity in individual channels, but presumably that will be less and less common as mobile-lightning-against-LSP ticks up, where you have much less of a concern given you usually just have one channel in that model. Finally, future lightning with trampoline will allow intermediate nodes to split payments, with them being recombined before they reach the destination, at least in theory, so it becomes even less of a concern if we get there.

lightning-invoice/src/utils.rs

lightning/src/chain/keysinterface.rs

TheBlueMatt · 2022-01-23T17:26:51Z

lightning-invoice/src/utils.rs

+			_ => panic!("Unexpected event"),
+		}
+		match events[1] {
+			Event::PaymentReceived { payment_hash: ref hash, ref purpose, amt } => {


It depends entirely on the amount being sent. Indeed, it may not be desirable to use phantom nodes for large value payments, but public stats on lightning usage seem to point to very small payments being the norm, which I'd think are more than fine. Further, it depends a lot on the user - if someone is running a full-fledged node they may have less liquidity in individual channels, but presumably that will be less and less common as mobile-lightning-against-LSP ticks up, where you have much less of a concern given you usually just have one channel in that model. Finally, future lightning with trampoline will allow intermediate nodes to split payments, with them being recombined before they reach the destination, at least in theory, so it becomes even less of a concern if we get there.

lightning/src/ln/channelmanager.rs

lightning-invoice/src/utils.rs

TheBlueMatt · 2022-01-23T18:11:30Z

Needs rebase.

TheBlueMatt · 2022-02-12T22:27:48Z

I'm happy to see this squashed and do one more once-over, @jkczyz?

…add_htlc This will be used in upcoming commit(s) to facilitate decoding multiple onion layers for multi-node payment receive

Will be used in upcoming commit(s) where it may be desirable to cache ChannelDetails routehints

To support the feature of generating invoices that can be paid to any of multiple nodes, a key manager need to be able to share an inbound_payment_key and phantom secret key. This is because a phantom payment may be received by any node participating in the invoice, so all nodes must be able to decrypt the phantom payment (and therefore must share decryption key(s)) in the act of pretending to be the phantom node. Thus we add a new `PhantomKeysManager` that supports these features. To be more specific, the inbound payment key must be shared because it is used to decrypt the payment details for verification (LDK avoids storing inbound payment data by encrypting payment metadata in the payment hash and/or payment secret). The phantom secret must be shared because enables any real node included in the phantom invoice to decrypt the final layer of the onion packet, since the onion is encrypted by the sender using the phantom public key provided in the invoice.

We want LDK to be able to retrieve the phantom secret key when we see that a payment is destined for a phantom node.

Will be used to facilitate decoding multiple onion layers for phantom payment receive

…cid module See method and module docs for more details

See PhantomKeysManager and invoice util's create_phantom_invoice for more info

This commit also adds additional checks for the second-to-last (phantom) hop for phantom payments.

TheBlueMatt

Two tiny nits that you don't need to bother to fix if you prefer not to, and one actual issue (ugh, sorry), which also should get a test or five (presumably in lightning/src/ln/onion_route_tests or so).

TheBlueMatt · 2022-02-14T21:56:19Z

lightning/src/ln/channelmanager.rs

+	///
+	/// [phantom node payments]: crate::chain::keysinterface::PhantomKeysManager
+	pub fn get_phantom_scid(&self) -> u64 {
+		let mut channel_state = self.channel_state.lock().unwrap();


nit: I'd prefer to push down locks in this kinda situation - the loop should only run once so we're not rapidly relocking, and the top of the loop is a crypto operation (even if a cheap one) now, so its not completely free and we're needlessly holding a lock in it.

TheBlueMatt · 2022-02-14T22:50:22Z

lightning/src/ln/channelmanager.rs

+															fail_forward!(err_msg, err_code, Vec::new());
+														},
+														Err(onion_utils::OnionDecodeErr::Relay { err_msg, err_code }) => {
+															fail_forward!(err_msg, err_code, Vec::new());


Oops, we need to handle this and the above case differently. I think the above case may be correct, but here we may end up failing due to a "final node" error but encrypting it as if it came from the second-to-last-hop, which the sender may treat as a bogus failure. Here we should onion_utils::encrypt_failure_package(onion_utils::build_failure_packet(..)) and then set the forwarding reason to HTLCFailReason::LightningError. We also should have a test for "tried to send something bogus, eg wrong amount, to a phantom node, and got back a failure that we decrypted correctly".

Sg. I assume we'll want to handle the case 10 lines down (where construct_recv_pending_htlc_info errors) similarly as well

Edit: oops the next comment literally addresses this, disregard

I think the above case may be correct,

Hmm, I think this case needs to use the phantom shared secret as well? Since we're pretending the phantom is the one creating this error

Hmm, I think this case needs to use the phantom shared secret as well? Since we're pretending the phantom is the one creating this error

Yea, we'll want to encrypt it twice, but we already do the second one, so I think we just need to encrypt here with the phantom shared secret. Tests should show up what's up, though.

TheBlueMatt · 2022-02-14T22:50:54Z

lightning/src/ln/channelmanager.rs

+														onion_utils::Hop::Receive(hop_data) => {
+															match self.construct_recv_pending_htlc_info(hop_data, shared_secret, payment_hash, amt_to_forward, outgoing_cltv_value) {
+																Ok(info) => phantom_receives.push((prev_short_channel_id, prev_funding_outpoint, vec![(info, prev_htlc_id)])),
+																Err(ReceiveError { err_code, err_data, msg }) => fail_forward!(msg, err_code, err_data)


jkczyz

Nothing major on my end. Think we're close other than what @TheBlueMatt mentioned.

jkczyz · 2022-02-14T22:47:13Z

fuzz/src/full_stack.rs

@@ -390,6 +390,7 @@ pub fn do_test(data: &[u8], logger: &Arc<dyn Logger>) {
 		best_block: BestBlock::from_genesis(network),
 	};
 	let channelmanager = Arc::new(ChannelManager::new(fee_est.clone(), monitor.clone(), broadcast.clone(), Arc::clone(&logger), keys_manager.clone(), config, params));
+	keys_manager.counter.fetch_sub(1, Ordering::AcqRel);


A comment here would be useful for posterity.

jkczyz · 2022-02-14T23:10:39Z

lightning/src/util/scid_utils.rs

+			let rand_bytes = keys_manager.get_secure_random_bytes();
+
+			let segwit_activation_height = segwit_activation_height(genesis_hash);
+			let mut valid_block_range = if highest_seen_blockheight > segwit_activation_height {


Little confused by the use of "range" in this variable name. Wondering if this instead could be:

let mut blocks_since_segwit_activation = highest_seen_blockheight.saturating_sub(segwit_activation_height); // ... let fake_scid_height = segwit_activation_height + rand_for_height % (blocks_since_segwit_activation + 1);

jkczyz · 2022-02-14T23:12:43Z

lightning/src/util/scid_utils.rs

+		if BlockHash::from_hex(MAINNET_GENESIS_STR).unwrap() == *genesis {
+			MAINNET_SEGWIT_ACTIVATION_HEIGHT


Do we care if this isn't accurate for other Networks? Guessing no.

Worst case it means (very marginally) less privacy, so dunno why we would, really.

TheBlueMatt

I'm also fine landing this as-is and fixing error returning in a followup. What do you think @jkczyz?

jkczyz · 2022-02-15T17:40:42Z

I'm also fine landing this as-is and fixing error returning in a followup. What do you think @jkczyz?

SGTM. Generally, I'd prefer to land everything together. But merging and reviewing a fresh PR has its advantages to avoid blocking others or holding things up, etc. So happy to have the fix in a follow-up before releasing.

TheBlueMatt · 2022-02-15T20:48:18Z

Tracking followups at #1308, so that we can get the bulk of this landed.

jkczyz · 2022-02-15T21:45:34Z

@valentinewallace Would you mind updating the PR description for posterity, especially if this gets some more visibility in the near future. Copy-paste summarizing the feature from comments / design doc / commit message should be fine.

#1199 Followup

joostjager mentioned this pull request Dec 2, 2021

External invoice registry lightningnetwork/lnd#6036

Closed

jkczyz self-requested a review December 2, 2021 21:23

TheBlueMatt added Optech Make Me Famous blocked on dependent pr labels Dec 3, 2021

TheBlueMatt reviewed Dec 6, 2021

View reviewed changes

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

TheBlueMatt added Seeking Code Review and removed blocked on dependent pr labels Dec 19, 2021

valentinewallace force-pushed the 2021-11-phantom-node branch from ca12473 to 8c00bb2 Compare January 3, 2022 18:52

valentinewallace force-pushed the 2021-11-phantom-node branch 2 times, most recently from 8aa6743 to d178795 Compare January 5, 2022 00:17

valentinewallace force-pushed the 2021-11-phantom-node branch from d178795 to 06fd868 Compare January 5, 2022 00:30

valentinewallace marked this pull request as ready for review January 5, 2022 00:34

TheBlueMatt reviewed Jan 5, 2022

View reviewed changes

valentinewallace force-pushed the 2021-11-phantom-node branch 2 times, most recently from 980b1c9 to 2c4a6df Compare January 11, 2022 17:41

joostjager reviewed Jan 17, 2022

View reviewed changes

TheBlueMatt reviewed Jan 18, 2022

View reviewed changes

rloomba reviewed Jan 20, 2022

View reviewed changes

valentinewallace force-pushed the 2021-11-phantom-node branch from 2c4a6df to 17d6bbe Compare January 21, 2022 21:56

valentinewallace force-pushed the 2021-11-phantom-node branch from 17d6bbe to eff64aa Compare January 21, 2022 22:10

joostjager reviewed Jan 22, 2022

View reviewed changes

TheBlueMatt reviewed Jan 23, 2022

View reviewed changes

valentinewallace force-pushed the 2021-11-phantom-node branch from eff64aa to 2b1c12f Compare January 23, 2022 20:16

valentinewallace force-pushed the 2021-11-phantom-node branch 2 times, most recently from e9cc2b1 to 9ba0cc8 Compare February 14, 2022 18:21

valentinewallace added 11 commits February 14, 2022 14:22

Refactor out decode_next_hop util from ChannelManager::decode_update_…

de1b62e

…add_htlc This will be used in upcoming commit(s) to facilitate decoding multiple onion layers for multi-node payment receive

Implement serialization for ChannelDetails

f254bb4

Will be used in upcoming commit(s) where it may be desirable to cache ChannelDetails routehints

DRY shared hkdf_extract_expand code to new module

329ecdf

KeysInterface::sign_invoice: indicate whether invoice is a phantom

f6c75d8

keysinterface: adapt get_node_secret for phantom payments

adeec71

We want LDK to be able to retrieve the phantom secret key when we see that a payment is destined for a phantom node.

scid_utils: add utils for retrieving txindex and vout

e1c33d4

channelmanager: DRY PendingHTLCInfo creation for receives

70f7db9

Will be used to facilitate decoding multiple onion layers for phantom payment receive

Add get_phantom_scid and get_phantom_route_hints + scid_utils::fake_s…

410eb05

…cid module See method and module docs for more details

Support phantom payment receive in ChannelManager, with invoice util

c417a51

See PhantomKeysManager and invoice util's create_phantom_invoice for more info

Don't send channel updates for private chans on error

710954f

This commit also adds additional checks for the second-to-last (phantom) hop for phantom payments.

valentinewallace force-pushed the 2021-11-phantom-node branch from 9ba0cc8 to 710954f Compare February 14, 2022 19:26

TheBlueMatt reviewed Feb 14, 2022

View reviewed changes

jkczyz reviewed Feb 14, 2022

View reviewed changes

TheBlueMatt approved these changes Feb 15, 2022

View reviewed changes

TheBlueMatt mentioned this pull request Feb 15, 2022

Fix (+test) phantom node onion error returning #1308

Closed

jkczyz approved these changes Feb 15, 2022

View reviewed changes

jkczyz merged commit 8e7f241 into lightningdevkit:main Feb 15, 2022

valentinewallace changed the title ~~Add support for multi-node receive~~ Add support for phantom node payments Feb 19, 2022

valentinewallace added a commit to valentinewallace/rust-lightning that referenced this pull request Feb 19, 2022

Follow-up nits from lightningdevkit#1199 (phantom node support)

1a9e872

valentinewallace added a commit to valentinewallace/rust-lightning that referenced this pull request Feb 19, 2022

Follow-up nits from lightningdevkit#1199 (phantom node support)

f486514

valentinewallace added a commit to valentinewallace/rust-lightning that referenced this pull request Feb 19, 2022

Follow-up nits from lightningdevkit#1199 (phantom node support)

1cd98ed

valentinewallace added a commit to valentinewallace/rust-lightning that referenced this pull request Feb 22, 2022

Follow-up nits from lightningdevkit#1199 (phantom node support)

1f6700c

TheBlueMatt added a commit that referenced this pull request Feb 28, 2022

Merge pull request #1324 from valentinewallace/2022-02-phantom-followup

99073c7

#1199 Followup

		fn get_inbound_payment_key_material(&self) -> KeyMaterial;

		/// Get the phantom node secret key for use in receiving a [phantom node payment].

		if BlockHash::from_hex(MAINNET_GENESIS_STR).unwrap() == *genesis {
		MAINNET_SEGWIT_ACTIVATION_HEIGHT

Add support for phantom node payments #1199

Add support for phantom node payments #1199

Conversation

valentinewallace commented Dec 1, 2021 • edited Loading

jkczyz commented Dec 15, 2021

valentinewallace commented Jan 3, 2022

valentinewallace commented Jan 5, 2022

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

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 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

codecov-commenter commented Jan 21, 2022 • edited Loading

Codecov Report

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 commented Jan 23, 2022

TheBlueMatt commented Feb 12, 2022

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

valentinewallace Feb 16, 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

jkczyz 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

jkczyz commented Feb 15, 2022

TheBlueMatt commented Feb 15, 2022

jkczyz commented Feb 15, 2022

valentinewallace commented Dec 1, 2021 •

edited

Loading

codecov-commenter commented Jan 21, 2022 •

edited

Loading

valentinewallace Feb 16, 2022 •

edited

Loading