Lnd: LND 0.11 cannot pay lnd 0.12 due to required payment_addr

Created on 6 Jan 2021  路  8Comments  路  Source: lightningnetwork/lnd

Background

The many LN wallets (BLW, LND 0.11) cannot pay invoices from LND 0.12. the payer gets "Incorrect payment details" error.

Steps to reproduce

  1. To Generate invoice from LND 0.12 (for example i used 0.12.0-beta.rc1 commit=v0.12.0-beta.rc1-18-gcc0321d1881ed23c9608cf898af2e2a7b347304a version)
  2. Try to pay from LND 0.11 for example. In my example i see a following bad payment in 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!

Expected behaviour

To some backward compatability. You will break > 50% of Lightning Network by this update...

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.

All 8 comments

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:

  • lnd 0.11 is able to pay 0.12 (just tested this freshly as well with new instance)
  • lnd has supported the MPP payload (includes payment_addr) since before 0.11, the only change is 0.12 now requires this value
  • 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

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sunnya97 picture sunnya97  路  3Comments

stevenroose picture stevenroose  路  3Comments

alexbosworth picture alexbosworth  路  3Comments

AnthonyRonning picture AnthonyRonning  路  3Comments

ealymbaev picture ealymbaev  路  3Comments