Maybe it will be more correct to change ConnectionResult enum from:

public enum ConnectionResult
{
	Ok,
	CouldNotConnect
}

to

public enum ConnectionResult
{
	Unknown = 0,
	Ok = 1,
	CouldNotConnect = 2
}

In current implementation

connectionResult.HasFlag(ConnectionResult.Ok)

for CouldNotConnect will return true

Source:
https://github.com/lightningnetwork/lnd/blob/master/lnrpc/lightning.swagger.json

For example, paging parameters for the "listinvoices" function are missing:

{
"/v1/invoices": {
      "get": {
        "summary": "lncli: `listinvoices`\nListInvoices returns a list of all the invoices currently stored within the\ndatabase. Any active debug invoices are ignored. It has full support for\npaginated responses, allowing users to query for specific invoices through\ntheir add_index. This can be done by using either the first_index_offset or\nlast_index_offset fields included in the response as the index_offset of the\nnext request. By default, the first 100 invoices created will be returned.\nBackwards pagination is also supported through the Reversed flag.",
        "operationId": "Lightning_ListInvoices",
        "responses": {
          "200": {
            "description": "A successful response.",
            "schema": {
              "$ref": "#/definitions/lnrpcListInvoiceResponse"
            }
          },
          "default": {
            "description": "An unexpected error response.",
            "schema": {
              "$ref": "#/definitions/rpcStatus"
            }
          }
        },
        "parameters": [
          {
            "name": "pending_only",
            "description": "If set, only invoices that are not settled and not canceled will be returned\nin the response.",
            "in": "query",
            "required": false,
            "type": "boolean"
          },
          {
            "name": "index_offset",
            "description": "The index of an invoice that will be used as either the start or end of a\nquery to determine which invoices should be returned in the response.",
            "in": "query",
            "required": false,
            "type": "string",
            "format": "uint64"
          },
          {
            "name": "num_max_invoices",
            "description": "The max number of invoices to return in the response to this query.",
            "in": "query",
            "required": false,
            "type": "string",
            "format": "uint64"
          },
          {
            "name": "reversed",
            "description": "If set, the invoices returned will result from seeking backwards from the\nspecified index offset. This can be used to paginate backwards.",
            "in": "query",
            "required": false,
            "type": "boolean"
          }
        ],
        "tags": [
          "Lightning"
        ]
      }
}

Currently e.g. Acinq is generating invoices in their Phoenix wallet that advertises with a placeholder feature bit 149 for trampoline support.

Parsing a Bolt11 invoice with this feature bit set will overflow in the Bolt11PaymentRequest.FeatureBits field, as it makes use of an enum that does not support that many distinct features. In fact due to the overflow it will set the (unrelated) feature bit 21 instead.

See here for a live-demo of the overflow where a Bolt11 invoice containing feature bit 149 will overflow to set feature bit 21.

One possible solution that does not break back-wards compatibility could be to limit the existing FeatureBits field to only the first 62 feature bits ensuring it does not overflow, and then add a RawFeatureBits field that uses a BitArray as backing allowing for more distinct feature bits.

I can work on a PR for this but just want to make sure that the general approach has a chance of being accepted by the maintainers.

Hey 👋

How can I safely create new macaroons for my lnd btcpay instance?

How logic on https://github.com/btcpayserver/BTCPayServer.Lightning/blob/master/src/BTCPayServer.Lightning.LND/LndClient.cs#L431 is wrong, we should use limbo_balance instead.

Look lightningnetwork/lnd#8436

It seems this package has no SourceLink support.
Might be helpful if it did, any plan?

@NicolasDorier I agree this should be default if the feedback we get is good, good idea.

Originally posted by @pavlenex in btcpayserver/btcpayserver#1843 (comment)

User name is not required by Eclair, but it could be useful for users using eclair-rpc-proxy.

Wallet providers with outsized view of the network (custodial wallets such as Wallet of Satoshi, or providers that handle routing, such as Phoenix Wallet -> acinq) can determine a btcpayserver's e-shop turnover and number of transactions by scanning and saving public keys. There is no need to give these providers this information.

BTCPayServer could implement a mechanism similar to LNProxy to create random public keys and proxy the payments to make this type of surveillance a little bit more difficult.

https://github.com/lnproxy/lnproxy

For btcpayserver/btcpayserver#3663 we need to retrieve the balance of a Lightning node.

The individual implementations supports this via these API calls:

• LND: Balance Blockchain, Balance Channels
• Core Lightning: listfunds
• Eclair: GlobalBalance, UsableBalances

The interface could look like this:

Task<LightningNodeBalance> GetBalance(CancellationToken cancellation = default);

And the properties of the returned LightningNodeBalance could contain:

• OnchainBalance
  • Confirmed
  • Unconfirmed
  • Reserved ("locked" in LND / not supported by Eclair, would be 0 there)
• OffchainBalance
  • Opening- Local balance of pending channel openings
  • Local - Local channel balances / available outbound liquidity
  • Remote - Remote channel balances / available inbound liquidity
  • Closing- Local balance of pending channel openings

GetBalance functionality for LND implementation returns incorrect OnChainBalance. LND REST API Reference in /v1/balance/blockchain gets balance in sats, but in src/BTCPayServer.Lightning.LND/LndClient.cs Ln 418 amount returned from SwaggerClient is not converted properly to LightMoney, causing amount in sats is passed directly as amount in BTC.

According to @araspitzu the eclair api has changed again and we need to fix before we can support it fully in btcpay

@nayuta-kohei pTarmigan was breaking the CI: https://circleci.com/gh/btcpayserver/BTCPayServer.Lightning

I removed the tests on 7cf06ca .

Please fix the bug and make it works again.

When I tried to run test, I encountered the issue that EnsureConnectedToDestinations function never finishes.
taking look closely, I discovered that when the destination is lnd, PayResult will always be CouldNotFindRoute but OpenChannleResult is always AlreadyExists
lnd returns empty list when I called listpeers manually, and when I try to connect to sender manually with connect RPC, it returns following error

[lncli] rpc error: code = Unknown desc = chain backend is still syncing, server not active yet

block count of lnd and bitcoind is same.
All I could come up with as a reason was this bug (lightningnetwork/lnd#2195)
If this is the case, I suppose bumping the btcpayserver/lnd docker version is necessary.
(It might be nice if there are guidelines about lnd fork of btcpayserver. e.g. why it requires the fork in the first place, what is the difference from upstream.)

Looks like this broke something - it instructs the users to drop the certfilepath argument which is definitely wrong and it fails to connect. However it still works in some other instance on regtest so I'm not really sure what's going on. Do you see anything obvious?

To be precise, BTCPay now can create invoice but can't see that it was paid.

Originally posted by @Kixunil in btcpayserver/btcpayserver#5422 (comment)

Some methods in ILightningClient do not have CancellationToken as parameter:

    Task<BitcoinAddress> GetDepositAddress();
    Task<ConnectionResult> ConnectTo(NodeInfo nodeInfo);
    Task CancelInvoice(string invoiceId);

Is that Ok ? Because in some cases they can became an issue for client and backend responsiveness.

Describe the problem/bug

I'm trying to connect to an existing lightning + charge node that's running on another box, but the charge port has been forwarded over SSH to the btcpayserver one.

Your environment

• Version of BTCPay Server: 1.0.4.4
• Deployment method: independent containers running btcpayserver, nbxplorer and bitcoin RPC port-forwarded
• Other relevant environment details: in order to get around the https requirement for connecting to charge, I've added a https reverse proxy that's listening on 8080 and proxy_passing to the charge port (9112) and a self-signed localhost cert

Logs (if applicable)
Nothing relevant, just New Block events.

Setup Parameters
If you're reporting a deployment issue run . btcpay-setup.sh -i and paste your the paremeters by obscuring private information.
btcpay-setup.sh not used

To Reproduce
Steps to reproduce the behavior:

1. Go to Store
2. Click on Lightning BTC Modify
3. Scroll down to Url and enter type=charge;url=https://localhost8080;api-token=xxxx
4. See error Error while connecting to the API (The SSL connection could not be established, see inner exception.)

It'd be great if there's an allowinsecure=true option for charge as well, in order to skip https validation.

Currently you can only integrate an existing onchain electrum bitcoin wallet to your BTCPayServer. When enabling segwit, one must account for both the lnd wallet and bitcoin (electrum) wallet.

From an accounting perspective, leveraging Electrum's Lightning implementation in BTCPayServer would make a lot of sense

Hey @araspitzu @Kukks , it seems eclair tests do not work with 0.19.0.1.
We need to update Bitcoin Core for BTCPayServer, so this will break Eclair if not fixed.

Describe the problem/bug
BTC + LTC (lightning) nodes can not work simultaneously on the same btcpay instance

Your environment

• Version of BTCPay Server: v1.0.3.94
• Deployment method: Lunanode

Logs (if applicable)
Basic logs can be found in Server Settings > Logs.

Recreating btcpayserver_lnd_litecoin ... error

ERROR: for btcpayserver_lnd_litecoin  Cannot start service lnd_litecoin: driver failed programming external connectivity on endpoint btcpayserver_lnd_litecoin (91916bc6ca15d6f83d74412e164dd74e2c2915d881b9abf4eec66d3a9f40365e): Bind for 0.0.0.0:9736 failed: port is already allocated

ERROR: for lnd_litecoin  Cannot start service lnd_litecoin: driver failed programming external connectivity on endpoint btcpayserver_lnd_litecoin (91916bc6ca15d6f83d74412e164dd74e2c2915d881b9abf4eec66d3a9f40365e): Bind for 0.0.0.0:9736 failed: port is already allocated

To Reproduce
Steps to reproduce the behaviour:

1. Deploy with lunanode BTC+LTC (lightning)
2. Wait for sync
3. Only btc (lightning) works

Expected behaviour
Allocate a different port to use LTC (lightning)
Actual behaviour
BTC (lightning) uses the port 9736 and therefore LTC (lightning) can not use the same one.

Screenshots/Links

I'm calling LndSwaggerClient.CloseChannelAsync. The response I'm getting from lnd is:

{"result":{"close_pending":{"txid":"WlbkadALmDboZFa94uXU/g2IhANqirhx2QlLeMlytFw=","output_index":0}}}
{"result":{"chan_close":{"closing_txid":"WlbkadALmDboZFa94uXU/g2IhANqirhx2QlLeMlytFw=","success":false}}}

The swagger client fails to parse this response and throws an exception:

   System.AggregateException : One or more errors occurred. (Could not deserialize the response body.)
  ----> BTCPayServer.Lightning.LND.SwaggerException : Could not deserialize the response body.
  ----> Newtonsoft.Json.JsonReaderException : Additional text encountered after finished reading JSON content: {. Path '', line 2, position 0.

Clearly it's not happy that lnd returned multiple results. A look at the code shows that the entire response body is passed to a single call to JsonConvert.DeserializeObject, which fails because the response contains multiple objects.

A look at the lnd swagger API spec says that this is expected behaviour (annotated):

"operationId": "CloseChannel",
"responses": {
  "200": {
    "description": "A successful response.(streaming responses)",       // <- "streaming responses"
    "schema": {
      "type": "object",
      "properties": {
        "result": {
          "$ref": "#/definitions/lnrpcCloseStatusUpdate"
        },
        "error": {
          "$ref": "#/definitions/runtimeStreamError"
        }
      },
      "title": "Stream result of lnrpcCloseStatusUpdate"                // <- "Stream result"
    }
  },
  "default": {
    "description": "An unexpected error response",
    "schema": {
      "$ref": "#/definitions/runtimeError"
    }
  }
},

I'm not sure how to fix this since the LndSwaggerClient code is automatically generated from the API spec. Closing a channel takes time and happens in stages, so CloseChannelAsync needs to return some kind of stream or event source that the user can use to monitor the progress of the operation. It seems like it's already supposed to do that since LnrpcCloseStatusUpdate inherits from System.ComponentModel.INotifyPropertyChanged, so maybe CloseChannelAsync is correct to return a single LnrpcCloseStatusUpdate and that value should then be getting updated when new responses come in. But it's not clear to me whether or how that's implemented, and either way it's not working correctly.

Eclair requires an update, as the version we're currently using was released over a year ago. They've recently released an updated latest image, which you can find here: https://hub.docker.com/r/acinq/eclair/tags.

With the LND 0.17.4 update, we've started encountering flaky tests related to channel connections.

During the process of updating LND to version 0.17.4 (see the pull request here: #158), I noticed these problems. Despite this, I opted to proceed with the update due to the critical bug fixes it includes, instead of waiting for the Eclair issues to be resolved.

As far as I can see, the signature is not verified by the constructor. Why not call VerifySignature iff ExplicitPayeePubKey != null and throw an exception if the signature does not match explicit pubkey?

Alternatively, the signature could also be verified in Parse/TryParse.

Version used: BTCPayServer.Lightning.Common; 1.1.0.16

lnbc9678785340p1pwmna7lpp5gc3xfm08u9qy06djf8dfflhugl6p7lgza6dsjxq454gxhj9t7a0sd8dgfkx7cmtwd68yetpd5s9xar0wfjn5gpc8qhrsdfq24f5ggrxdaezqsnvda3kkum5wfjkzmfqf3jkgem9wgsyuctwdus9xgrcyqcjcgpzgfskx6eqf9hzqnteypzxz7fzypfhg6trddjhygrcyqezcgpzfysywmm5ypxxjemgw3hxjmn8yptk7untd9hxwg3q2d6xjcmtv4ezq7pqxgsxzmnyyqcjqmt0wfjjq6t5v4khxxqyjw5qcqp2rzjq0gxwkzc8w6323m55m4jyxcjwmy7stt9hwkwe2qxmy8zpsgg7jcuwz87fcqqeuqqqyqqqqlgqqqqn3qq9qs4x9qlmd57lq7wwr23n3a6pkayy3jpfucyptlncs2maswe3dnnjy3ce2cgrvykmxlfpvn6ptqfqz4df5uaulvd4hjkckuqxrqqkz8jgphputwh

paymentRequest = BOLT11PaymentRequest.Parse(invoice, NBitcoin.Network.Main);
aymentRequest.MinimumAmount.MilliSatoshi.ToString();
paymentRequest.MinimumAmount.ToString();

Prints "9678785340" and "0.0967878534".

The correct result would have been
"967878534" and "0.00967878534".

So there seems to be an error when parsing the p unit specifier. p is 10^(-12) BTC and not 10^(-11) BTC.