Add an onion message-based DNSSEC HRN Resolver #6
Conversation
TheBlueMatt
commented
Jun 29, 2025
TheBlueMatt
commented
TheBlueMatt
force-pushed
the
2025-06-onion-resolution
branch
from
8258114 to
8264cc1
Compare
|
This crate depends on the LDK |
Hmm, that's a bit unfortunate. I had hoped that we might eventually get around to splitting out BOLT12 types into a dedicated crate, in parallel to |
|
@chuksys Mind checking out this PR as part of lightningdevkit/ldk-node#521 as we now decided to handle HRN resolution in LDK Node directly, based on the changes here? |
Sure! On it! |
Yea, I mean in general I'm not a fan of crate-smashing, but in this case it would have been useful...oh well. |
Previously I was hoping we could swap the dependency order between LDK and `bitcoin-payment-instructions`, but that turned out to be untennable, so instead we should reuse the LDK `HumanReadableName`.
Doing HRN resolution natively over the normal internet tends to be horrendous for privacy. One of the main motivations for BIP 353 was to limit the impacts of this by allowing for easier proxying of DNS requests. Here we add one such proxied request, specifically using lightning onion messages to do the DNS requests.
TheBlueMatt
force-pushed
the
2025-06-onion-resolution
branch
from
8264cc1 to
543c909
Compare
|
Rebased: diff --git a/src/onion_message_resolver.rs b/src/onion_message_resolver.rs
index 9e7fa33bc..39f42bbfd 100644
--- a/src/onion_message_resolver.rs
+++ b/src/onion_message_resolver.rs
@@ -243,9 +243,16 @@ where
}
}
- fn resolve_lnurl<'a>(&'a self, _: String, _: Amount, _: [u8; 32]) -> LNURLResolutionFuture<'a> {
- let err = "resolve_lnurl shouldn't be called when we don't resolve LNURL";
- debug_assert!(false, "{}", err);
+ fn resolve_lnurl<'a>(&'a self, _url: &'a str) -> HrnResolutionFuture<'a> {
+ let err = "DNS resolver does not support LNURL resolution";
+ Box::pin(async move { Err(err) })
+ }
+
+ fn resolve_lnurl_to_invoice<'a>(
+ &'a self, _: String, _: Amount, _: [u8; 32],
+ ) -> LNURLResolutionFuture<'a> {
+ let err = "resolve_lnurl_to_invoice shouldn't be called when we don't resolve LNURL";
+ debug_assert!(false, "{err}");
Box::pin(async move { Err(err) })
}
} |
| let mut dns_resolvers = Vec::new(); | ||
| for (node_id, node) in self.network_graph.read_only().nodes().unordered_iter() { | ||
| if let Some(info) = &node.announcement_info { | ||
| // Sadly, 31 nodes currently squat on the DNS Resolver feature bit |
There was a problem hiding this comment.
:(
(cc @chuksys, we'll need to do the same when we discover resolvers from the network graph).
TheBlueMatt
force-pushed
the
2025-06-onion-resolution
branch
from
2e04f2c to
45e53e2
Compare
| fn poll(self: Pin<&mut Self>, context: &mut Context) -> Poll<HrnResolution> { | ||
| let mut state = self.0.lock().unwrap(); | ||
| if let Some(res) = state.result.take() { | ||
| state.waker = None; |
There was a problem hiding this comment.
Why are we setting this None here? Wouldn't this already be unset by ChannelRecv::complete? Couldn't this rather be a debug_assert to make sure it already is always None here?
| let counter = self.next_id.fetch_add(1, Ordering::Relaxed) as u64; | ||
| let mut payment_id = [0; 32]; | ||
| payment_id[..8].copy_from_slice(&counter.to_ne_bytes()); | ||
| let payment_id = PaymentId(payment_id); |
There was a problem hiding this comment.
Hmm, just to be clear: even though this is reusing the same type, it's completely decoupled from the LDK-internal payment_id now, no? I wonder if it would make sense to create a separate ResolutionId / RequestId type to reflect this.
