When signing a message, a fixed-size LN wire format encoded signature is returned, but I haven't figured out how to decode it. Is there some helper functions in lndclient or do I have to use btcd or something similar to parse it?

Hello,

I'm trying to Subscribe to Lnd incoming invoices
After bootstrapping some code using lnrpc.LightningClient & NewBasicClient, I switched to GrpcLndServices and I found out SubscribeInvoices is not in LightningClient.

Are we not meant to use the LightningClient for that or is it just missing?

Would like to connect with a custom signet

Is there any official documentation for lndclient apart from the one on pkg.go.dev?

Are we still encouraged to use GrpcLndServices as opposed to LightningClient or BasicClient?

When sending a payment with the parameters request.Invoice set to a 0 amount invoice as well as request.Amount set it will still submit it without the amount as opposed to what is expected for a dynamic value invoice.

I tried it with this invoice. This will result in rpc error: code = Unknown desc = amount must be specified when paying a zero amount invoice

Or is this expected and I have to replace the 0 amount invoice myself first?

In the call AddInvoice, the parameter Value that is in mSat is rounded to a full sat in order to be sent in the Value field of the Invoice.

I see that the Invoice structure has the field ValueMsat, I think this would be a better fit, the loss of precision will be avoided and the parameters will match the invoice.

I'm trying to implement channel closure functionality with ´lndclient` and I'm facing an issue when trying to force close an inactive channel.

The API requires a confTarget int32 argument, but attempting to force close a channel leads to an RPC error due to the fact that a custom fee was set.

lndService.Client.CloseChannel(m.ctx, outPoint, true, 5, address)

results in:

rpc error: code = Unknown desc = force closing a channel uses a pre-defined fee

Is there a way to not pass a pre-defined fee that I haven't found yet or does lndclient need to be updated in order to support closing inactive channels?

Apparently due to some version incompatibilities between LND, lndclient, and Loop, it's impossible to use all 3 successfully inside a single Go module (I'm not sure it's a supported use case, in case if not, I'd like to set a precedent then 😀).

Reproduce:

mkdir lnd-all
cd lnd-all
go mod init lnd-all
cat > main.go <<EOF
package main

import (
	"fmt"

	_ "github.com/lightninglabs/lndclient"
	_ "github.com/lightninglabs/loop"
	_ "github.com/lightningnetwork/lnd"
)

func main() {
	fmt.Println("Hello")
}
EOF
go mod tidy
go run ./

This fails with:

# github.com/lightninglabs/loop/sweep
../../../go/pkg/mod/github.com/lightninglabs/[email protected]/sweep/sweeper.go:61:14: undefined: lndclient.SignDescriptor
../../../go/pkg/mod/github.com/lightninglabs/[email protected]/sweep/sweeper.go:74:26: undefined: lndclient.SignDescriptor

It seems like this repo depends a lot on the main LND repo and reuses a lot of its packages (some of which are even separate Go modules). Could it be reasonable for this module to belong inside the main LND repository, so that breaking changes could be fixed immediately?

With that, Loop and other projects could depend on the main LND module and avoid having incompatible LND and lndclient in their dependencies. Any project depending on LND and lndclient at the same time could be having hard times integrating them.

Feature request

Add ability to supply raw certs and macaroons as []byte, instead of specifying a path.

Motivation

When working with nodes and services running in containers, we do not necessarily have (easy) access to the underlying file system used by a container. Instead, it is easier to read specific files (certs and macaroons) out of the container. Being able to supply these would simplify my work flow.

github.com/lightninglabs/lndclient imports
github.com/btcsuite/btcd/btcec: cannot find module providing package github.com/btcsuite/btcd/btcec

How can this be solved?

It seems lndclient only implements this RPC call for message signing and not the main RPC implementation. Am I correct?

This doesn't seem to work for message signing (for Amboss authentication for example). I presume Im using the wrong key.

keyLocator := &keychain.KeyLocator{
		Family: keychain.KeyFamilyNodeKey,
	}

	// Call the SignMessage function
	signature, err := m.lndService.Signer.SignMessage(m.ctx, []byte(messageToSign),
		*keyLocator, lndclient.SignCompact())