Paying to SBW testnet leads to routing failure
Closed this issue · 9 comments
Setup:
- LDK sample on desktop
- SBW testnet wallet on android
- SBW opened towards LDK a channel.
The SBW side info:
Channel details
Remote peer node ID
02ba6795ff89159b58dd95305569355cbad23301e286468410bbb65c5c2f20fd28
Local wallet node ID
023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
Channel short ID
2578902323927449600
Funding txid
7cf45c3be6f231f8a60c10716a4048806508705eccf0c0c4b073a2480dfb9dc1
Channel started
2 hours ago
The LDK info:
> listchannels
[
{
channel_id: c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c,
funding_txid: 7cf45c3be6f231f8a60c10716a4048806508705eccf0c0c4b073a2480dfb9dc1,
peer_pubkey: 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201,
short_channel_id: 2578902323927449600,
is_channel_ready: true,
channel_value_satoshis: 650000,
local_balance_msat: 800000,
available_balance_for_send_msat: 150000,
available_balance_for_recv_msat: 642700000,
channel_can_send_payments: true,
public: false,
},
]
> listpeers
{
pubkey: 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
},
Payment of invoice produced by LDK is ok. But, when I try to pay invoice produced by SBW, I got:
> sendpayment lntb500n1p33v9sxpp532xw4h2utv0dx8rm0q37kc288crv555evq5sqtpxv22v8w2ar4zqdqqsp57dg9y0fest04hfgs6we7kvxu0wqy7teqxn7csqjtvtnhcsj0dhcsxqy9gcqcqzys9qyysgqrzjq2ax090l3y2ekkxaj5c926f4tjadyvcpu2rydpqshwm9chp0yr7jsg72rgqqqgqqqqqqqqlgqqqqqqqqfq0l22mmx258r0cfgwzqusjjl76zmwyhchum52496snmakalevhkxnk7m5hv0pdvllyd49js50qjpm78634k7xzhxwr9u8gsjc37gjhlsqjywpza
ERROR: failed to find route: Failed to find a path to the given destination
The example of invoice produced by LDK (that is ok):
lntb7u1p33v9dfdqud3jxktt5w46x7unfv9kz6mn0v3jsnp4q2ax090l3y2ekkxaj5c926f4tjadyvcpu2rydpqshwm9chp0yr7jspp5s64ap9480lpxh4tcf6ufcumjx8qy28xelwfg3fy7nhnvgpylhnmssp5llyfacaaefmxdjauqv3s8g7mujhujedx8gsz2ghh0u3ps6ye3qns9qyysgqcqpcxqzjcyr049wn9qwh93mya66ak75c0e6untgr5fyr2fnqu8pe7k8q8rqlz8qn420r2ewv2g07t32sla2fgdnx28m0st9cs30d75pmej9upy8spqn2rr6
Can you share the LDK logs?
Actually, even better, can you apply the following diff, reproduce, and then send the LDK logs?
diff --git a/Cargo.toml b/Cargo.toml
index 74ce48b..c113278 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -8,7 +8,7 @@ edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
-lightning = { version = "0.0.109", features = ["max_level_trace"] }
+lightning = { version = "0.0.109" }
lightning-block-sync = { version = "0.0.109", features = [ "rpc-client" ] }
lightning-invoice = { version = "0.17" }
lightning-net-tokio = { version = "0.0.109" }
diff --git a/src/cli.rs b/src/cli.rs
index 6c0b756..7e44547 100644
--- a/src/cli.rs
+++ b/src/cli.rs
@@ -492,6 +492,7 @@ fn list_channels(channel_manager: &Arc<ChannelManager>, network_graph: &Arc<Netw
println!("\t\tavailable_balance_for_recv_msat: {},", chan_info.inbound_capacity_msat);
}
println!("\t\tchannel_can_send_payments: {},", chan_info.is_usable);
+ println!("\t\tnext_htlc_limit_msat: {},", chan_info.next_outbound_htlc_limit_msat);
println!("\t\tpublic: {},", chan_info.is_public);
println!("\t}},");
}I applied the patch. Actually, I needed to patch the patch to use 0.0.110 version. Here are the logs:
2022-09-06 03:19:34.079 INFO [lightning::ln::channelmanager:6965] Successfully loaded channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:34.081 TRACE [lightning::chain::chainmonitor:596] Got new ChannelMonitor for channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:34.084 TRACE [lightning::chain::chainmonitor:603] Finished persisting new ChannelMonitor for channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:34.085 TRACE [lightning_background_processor:318] Calling ChannelManager's timer_tick_occurred on startup
2022-09-06 03:19:40.553 DEBUG [lightning::ln::peer_handler:973] Finished noise handshake for connection with 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
2022-09-06 03:19:40.553 TRACE [lightning::ln::peer_handler:851] Enqueueing message Init { features: [170, 81, 10, 8, 0, 160, 8], remote_network_address: Some(IPv4 { addr: [184, 22, 79, 207], port: 36300 }) } to 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
2022-09-06 03:19:41.100 INFO [lightning::ln::peer_handler:1096] Received peer Init message from 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201: DataLossProtect: supported, InitialRoutingSync: not supported, UpfrontShutdownScript: not supported, GossipQueries: supported, VariableLengthOnion: supported, StaticRemoteKey: supported, PaymentSecret: supported, BasicMPP: supported, Wumbo: supported, ShutdownAnySegwit: supported, ChannelType: not supported, SCIDPrivacy: not supported, ZeroConf: not supported, unknown flags: supported
2022-09-06 03:19:41.100 DEBUG [lightning::ln::channelmanager:6169] Generating channel_reestablish events for 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
2022-09-06 03:19:41.100 TRACE [lightning::ln::channel:5325] Enough info to generate a Data Loss Protect with per_commitment_secret 8b43fdb784d62df50997c5e518a5bfc6ae00848d80dc0e4429e06edf3892523f for channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:41.100 DEBUG [lightning::ln::peer_handler:1542] Handling SendChannelReestablish event in peer_handler for node 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201 for channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:41.100 TRACE [lightning_background_processor:352] Persisting ChannelManager...
2022-09-06 03:19:41.101 TRACE [lightning::ln::peer_handler:851] Enqueueing message ChannelReestablish { channel_id: [193, 157, 251, 13, 72, 162, 115, 176, 196, 192, 240, 204, 94, 112, 8, 101, 128, 72, 64, 106, 113, 16, 12, 166, 248, 49, 242, 230, 59, 92, 244, 124], next_local_commitment_number: 7, next_remote_commitment_number: 6, data_loss_protect: Present(DataLossProtect { your_last_per_commitment_secret: [139, 67, 253, 183, 132, 214, 45, 245, 9, 151, 197, 229, 24, 165, 191, 198, 174, 0, 132, 141, 128, 220, 14, 68, 41, 224, 110, 223, 56, 146, 82, 63], my_current_per_commitment_point: PublicKey(02020202020202020202020202020202020202020202020202020202020202ffcee50f772e0a9972250d4b61b3e5beb95de897c73b4ed1cc35ed013accf1c840) }) } to 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
2022-09-06 03:19:41.101 TRACE [lightning::ln::peer_handler:851] Enqueueing message GossipTimestampFilter { chain_hash: 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, first_timestamp: 1661224781, timestamp_range: 4294967295 } to 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
2022-09-06 03:19:41.104 TRACE [lightning_background_processor:354] Done persisting ChannelManager.
2022-09-06 03:19:41.608 TRACE [lightning::ln::peer_handler:1135] Received message ChannelReestablish(ChannelReestablish { channel_id: [193, 157, 251, 13, 72, 162, 115, 176, 196, 192, 240, 204, 94, 112, 8, 101, 128, 72, 64, 106, 113, 16, 12, 166, 248, 49, 242, 230, 59, 92, 244, 124], next_local_commitment_number: 7, next_remote_commitment_number: 6, data_loss_protect: Present(DataLossProtect { your_last_per_commitment_secret: [49, 58, 51, 184, 239, 3, 245, 235, 37, 95, 190, 91, 154, 67, 8, 71, 136, 247, 81, 101, 142, 236, 249, 120, 11, 57, 117, 223, 75, 156, 183, 97], my_current_per_commitment_point: PublicKey(3aa42a1dcaa84b806ab1bb440861729d38f8711898da08a5389933bdae323504da9e55ea46c119a786c15d6ef75f9daaf4b9997cd1e15b8a4d63344c194a53f9) }) }) from 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
2022-09-06 03:19:41.609 TRACE [lightning::ln::channel:5221] Creating an announcement_signatures message for channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:41.609 TRACE [lightning::ln::channel:5225] Cannot create an announcement_signatures as channel is not public.
2022-09-06 03:19:41.609 DEBUG [lightning::ln::channel:3940] Reconnected channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c with no loss
2022-09-06 03:19:41.609 TRACE [lightning::ln::channelmanager:2384] Attempting to generate channel update for channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:41.609 TRACE [lightning::ln::channelmanager:2393] Generating channel update for channel c19dfb0d48a273b0c4c0f0cc5e7008658048406a71100ca6f831f2e63b5cf47c
2022-09-06 03:19:41.610 TRACE [lightning::ln::peer_handler:1577] Handling SendChannelUpdate event in peer_handler for node 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201 for channel 2578902323927449600
2022-09-06 03:19:41.610 TRACE [lightning_background_processor:352] Persisting ChannelManager...
2022-09-06 03:19:41.610 GOSSIP [lightning::ln::peer_handler:849] Enqueueing message ChannelUpdate { signature: 3044022075eecc1adfd402cb594f580eda368a446fb753ab77c6f6bcfa30b1da714d89200220148faac5a276abe45984c52aa4559d8a501371ebcaae278cbedfc22557698855, contents: UnsignedChannelUpdate { chain_hash: 000000000933ea01ad0ee984209779baaec3ced90fa3f408719526f8d77f4943, short_channel_id: 2578902323927449600, timestamp: 1662433623, flags: 1, cltv_expiry_delta: 72, htlc_minimum_msat: 1000, htlc_maximum_msat: 585000000, fee_base_msat: 1000, fee_proportional_millionths: 0, excess_data: [] } } to 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201
2022-09-06 03:19:41.613 TRACE [lightning_background_processor:354] Done persisting ChannelManager.
2022-09-06 03:19:56.458 TRACE [lightning::routing::router:867] Searching for a route from payer 02ba6795ff89159b58dd95305569355cbad23301e286468410bbb65c5c2f20fd28 to payee 027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf with MPP and 1 first hops overriding the network graph
2022-09-06 03:19:56.458 TRACE [lightning::routing::router:971] Building path from 027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf (payee) to 02ba6795ff89159b58dd95305569355cbad23301e286468410bbb65c5c2f20fd28 (us/payer) for value 75000 msat.
2022-09-06 03:19:56.458 TRACE [lightning::routing::router:1464] Starting main path collection loop with 0 nodes pre-filled from first/last hops.
2022-09-06 03:19:56.458 TRACE [lightning::routing::router:1464] Starting main path collection loop with 0 nodes pre-filled from first/last hops.
2022-09-06 03:19:56.458 TRACE [lightning::routing::router:1631] Have now collected 0 msat (seeking 225000 msat) in paths. Last path loop did not find a new path.
Hmm, that log says you're trying to pay 027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf, but the peer the channel is with is 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201. Thus, because 027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf does not have any public channels we of course have no route to that peer?
Is SBW trying to be too-clever and signing invoices with a random key? That won't work for your channel counteraprty being the one to pay you - obviously a route hint that says "hey, I have a channel with you" is/should be ignored if we don't actually have a channel with the node in the invoice.
Hmm, that log says you're trying to pay
027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf, but the peer the channel is with is023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201. Thus, because027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bfdoes not have any public channels we of course have no route to that peer?
The 027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf can have a private channel to 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201. So if there are hints in the route should we build path via the dead end?
Is SBW trying to be too-clever and signing invoices with a random key? That won't work for your channel counteraprty being the one to pay you - obviously a route hint that says "hey, I have a channel with you" is/should be ignored if we don't actually have a channel with the node in the invoice.
I found related part of SBW. It indeed creates random 32 bytes and derive one-time key to sign the invoice.
val prExt = LNParams.cm.makePrExt(toReceive = manager.resultMsat, description, allowedChans = cs, Crypto.sha256(preimage), randomBytes32) def makePrExt(toReceive: MilliSatoshi, description: PaymentDescription, allowedChans: Seq[ChanAndCommits], hash: ByteVector32, secret: ByteVector32): PaymentRequestExt = {
val hops = allowedChans.map(_.commits.updateOpt).zip(allowedChans).collect { case Some(usableUpdate) ~ ChanAndCommits(_, commits) => usableUpdate.extraHop(commits.remoteInfo.nodeId) :: Nil }
val pr = PaymentRequest(LNParams.chainHash, Some(toReceive), hash, secret, LNParams.secret.keys.fakeInvoiceKey(secret), description.invoiceText, LNParams.incomingFinalCltvExpiry, hops.toList)
PaymentRequestExt.from(pr)
}I see that Eclair has the same behavior in the setup. I need to check another setup:
- SBW Alice
- LDK Kevin
- LDK Charlie
- SBW Bob
Alice has a private channel to Kevin. Kevin has a public channel to Charlie. Bob has private channel to Charlie.
Alice -> LDK -> Bob payments should work normally.
The 027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf can have a private channel to 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201. So if there are hints in the route should we build path via the dead end?
No, that is not what the hints in the invoice say. The invoice hint says that we (the LDK node trying to pay) has a direct channel with 027055478b3545fae61415803dd234aabafbb3e35545a29ff5a802090f616270bf. This is not true, we don't have such a channel, we only have a channel with 023488cfb58a6b46f83bbeb185b4b4b6087de62a5a5141425dd83f37a3a8041201. Thus, LDK looks at the invoice and correctly concludes it has no way to pay the target node.
The invoice could, instead, include a route hint that is two-hops, and terminates at the random node, and then we'd pay it happily.
Indeed, this should only be an issue when trying to pay directly from the node that has a channel with SBW, any other node doesn't care that the channel in question doesn't exist. Its ultimately an issue with SBW, but I get what they're going for here, and I doubt they'll want to change it as ultimately you're rarely getting paid by your direct counterparty (and they encourage users to use their custodial service anyway).
Eventually this should be fixed by using BOLT 12 + blinded paths, as it will be a much cleaner way to get the privacy they want, and even better privacy.
Closing this as its ultimately a bug in SBW.