The many LN wallets (BLW, LND 0.11) cannot pay invoices from LND 0.12. the payer gets "Incorrect payment details" error.
0.12.0-beta.rc1 commit=v0.12.0-beta.rc1-18-gcc0321d1881ed23c9608cf898af2e2a7b347304a version)lncli listpayments: {
"payment_hash": "2afe589d90d5cb04bf4aaa36ec4640e7d37455d6c9a502a942ae9fefb6972b59",
"value": "2760547",
"creation_date": "1609935486",
"fee": "0",
"payment_preimage": "0000000000000000000000000000000000000000000000000000000000000000",
"value_sat": "2760547",
"value_msat": "2760547000",
"payment_request": "",
"status": "FAILED",
"fee_sat": "0",
"fee_msat": "0",
"creation_time_ns": "1609935486113115701",
"htlcs": [
{
"status": "FAILED",
"route": {
"total_time_lock": 664825,
"total_fees": "0",
"total_amt": "2760547",
"hops": [
{
"chan_id": "624397260287639553",
"chan_capacity": "16777215",
"amt_to_forward": "2760547",
"fee": "0",
"expiry": 664825,
"amt_to_forward_msat": "2760547000",
"fee_msat": "0",
"pub_key": "035f5236d7e6c6d16107c1f86e4514e6ccdd6b2c13c2abc1d7a83cd26ecb4c1d0e",
"tlv_payload": true,
"mpp_record": null,
"custom_records": {
}
}
],
"total_fees_msat": "0",
"total_amt_msat": "2760547000"
},
"attempt_time_ns": "1609935486149741125",
"resolve_time_ns": "1609935489796925389",
"failure": {
"code": "INCORRECT_OR_UNKNOWN_PAYMENT_DETAILS",
"channel_update": null,
"htlc_msat": "0",
"onion_sha_256": null,
"cltv_expiry": 0,
"flags": 0,
"failure_source_index": 1,
"height": 664792
},
"preimage": null
}
],
"payment_index": "68603",
"failure_reason": "FAILURE_REASON_INCORRECT_PAYMENT_DETAILS"
},
For example i have some nodes under the LND 0.12.0-beta.rc1 commit=v0.12.0-beta.rc1-18-gcc0321d1881ed23c9608cf898af2e2a7b347304a and I have the auto-rebalancing scripts for a rebalance between my own nodes channels through invoice-pay mechanism. It broken between LND 0.11 and LND 0.12. Before I could not pay to the merchant from BLW with same error: merchant had LND 0.12 but i had BLW.
I know it's because you ask keysend/payment_addr feature as required now but you will make many problems for merchants by this update!
To some backward compatability. You will break > 50% of Lightning Network by this update...
The failed payment above in example was made at the LND-13 (0.12.0-beta.rc1 commit=v0.12.0-beta.rc1-18-gcc0321d1881ed23c9608cf898af2e2a7b347304a) and at LND-13 side looks like as:
{
"memo": "Rebalance from lnd-42 to lnd-13 2760547 sats through 624397260287639553 channel",
"r_preimage": "4cf4e35f3bf05e6ac2a458e557b9193437293946291334a4680807890a3a3be3",
"r_hash": "2afe589d90d5cb04bf4aaa36ec4640e7d37455d6c9a502a942ae9fefb6972b59",
"value": "2760547",
"value_msat": "2760547000",
"settled": false,
"creation_date": "1609935485",
"settle_date": "0",
"payment_request": "lnbc27605470n1p0lt2napp59tl938vs6h9sf0624gmwc3jqulfhg4wkexjs922z4607ld5h9dvsdrl2fjkyctvv9hxxefqveex7mfqd3hxgtf5xgs8gmeqd3hxgtf3xvsrydekxq6ngdeqwdshgueqw358ymm4va5zqd3jxsenjdejxccrywphxcenjdf4xvsxx6rpdehx2mqcqp7sp5cp7uzhfq52c2pznggrwefhllhdsxtem8vk5dnj43pd5wam7hr27q9qyyssqca0v3avh0szkrf
"description_hash": null,
"expiry": "3600",
"fallback_addr": "",
"cltv_expiry": "30",
"route_hints": [
],
"private": false,
"add_index": "203366",
"settle_index": "0",
"amt_paid": "0",
"amt_paid_sat": "0",
"amt_paid_msat": "0",
"state": "OPEN",
"htlcs": [
],
"features": {
"9": {
"name": "tlv-onion",
"is_required": false,
"is_known": true
},
"14": {
"name": "payment-addr",
"is_required": true,
"is_known": true
},
"17": {
"name": "multi-path-payments",
"is_required": false,
"is_known": true
}
},
"is_keysend": false,
"payment_addr": "c07dc15d20a2b0a08a6840dd94dfffbb6065e76765a8d9cab10b68eeefd71abc"
},
The BLW repo showed the project is now "archived" meaning it's no longer developed. If it can't parse an invoice properly with a payment addr, then it can't even do MPP payments. It's been _over a year_ since this feature was introduced to the protocol and any wallet that's still being developed should support it. This feature also makes the network much more secure, a recent vulnerability that was discovered becomes impossible at the protocol level due to this feature.
I have the auto-rebalancing scripts for a rebalance between my own nodes channels through invoice-pay mechanism. It broken between LND 0.11 and LND 0.12
You need to either use the full invoice, or set the payment_addr field in SendPaymentRequest if you're doing a "raw" request instead.
@Roasbeef , You are doing wrong by shifting attention from the main problem (yours) to someone else's. I was describing a completely different problem. The LND to 0.11 cannot pay to LND 0.12. I mentioned the BLW as additional example not main problem. I didn't test other mobile wallets but the Blixt will not work (it based at lnd 0.11), the Breeze based at lnd 0.11 and will not too. There are Bluewallet and Eclair mobile wallet yet...
The LND to 0.11 cannot pay to LND 0.12.
@LNBIG-COM How are you sending from 0.11 to 0.12? Are you using a plain invoice, or specifying the payment details manually?
If the sending wallet supports MPP, then it should be able to also specify this payload since it's the very same payload.
The issue isn't lnd 0.11 or not, it's: wallets should use the invoice when sending payments as the invoice contains additional information that's used to make sure the payment succeeds.
Summarizing:
payment_addr) since before 0.11, the only change is 0.12 now requires this value payment_addr field in the existing APIs@LNBIG-COM How are you sending from 0.11 to 0.12? Are you using a plain invoice, or specifying the payment details manually?
I pay invoices by the following code:
let res = await nodeStorage.nodes[command.invoiceFrom.key].client.addInvoice({
memo: `Rebalance from ${command.payWho.key} to ${command.invoiceFrom.key} ${command.amount} sats through ${command.chanId} channel`,
value: command.amount,
})
command.decodedPayReq = await nodeStorage.nodes[command.payWho.key].client.decodePayReq({pay_req: res.payment_request})
debug("袪械蟹褍谢褜褌邪褌 褋芯蟹写邪薪懈褟 懈薪胁芯泄褋邪: %o (泻芯屑邪薪写邪 %o)", res, command)
let resPayment = await nodeStorage.nodes[command.payWho.key].client.sendPaymentSync({
dest_string: command.decodedPayReq.destination,
payment_hash_string: command.decodedPayReq.payment_hash,
amt: command.decodedPayReq.num_satoshis,
final_cltv_delta: command.decodedPayReq.cltv_expiry,
fee_limit: {fixed: 0},
outgoing_chan_id: command.chanId,
})
So i understand now that i use a non-standard way may be...
I think now it's my case:
if you were makign payments by manually specifying the details (destination, pay hash, etc), then you should switch to either generating and paying full invoices, or specifying the new payment_addr field in the existing APIs
So i am sorry! I will patch my rebalance scripts
* if you were makign payments by manually specifying the details (destination, pay hash, etc), then you should switch to either generating and paying full invoices, or specifying the new `payment_addr` field in the existing APIs
@Roasbeef , can you help me to understand how can I use the call SendPaymentSync with payment_addr field? I think is it the TLV field (dest_custom_records fields)? The DecodePayReq returns the payment_addr bytes from invoice but how can I set this in SendPaymentSync/SendPayment gRPC methods?
Most helpful comment
The BLW repo showed the project is now "archived" meaning it's no longer developed. If it can't parse an invoice properly with a payment addr, then it can't even do MPP payments. It's been _over a year_ since this feature was introduced to the protocol and any wallet that's still being developed should support it. This feature also makes the network much more secure, a recent vulnerability that was discovered becomes impossible at the protocol level due to this feature.