Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setCredentials should be able to support connection w/o TLS cert #3

Open
bucko13 opened this issue Jan 15, 2020 · 3 comments
Open

setCredentials should be able to support connection w/o TLS cert #3

bucko13 opened this issue Jan 15, 2020 · 3 comments

Comments

@bucko13
Copy link

bucko13 commented Jan 15, 2020

This should enable support for connecting with a BTCPay Server node. Since they just use port 443 and https for connections, there is no TLS cert for connecting to the node. Just the macaroon and the socket.

Being able to connect to BTCPay Server nodes adds a lot more flexibility of what node people can use for chianpoint, especially since these are nodes that can be run relatively cheaply and can be setup with very little coding experience.

I imagine it would be a pretty simple change to this line:
https://github.com/Tierion/lnrpc-node-client/blob/master/src/index.js#L43

If these seems reasonable, I can put together a PR for this change.

@jacohend
Copy link
Collaborator

Seems like just a matter of detecting the case when the socket is a https url and the provided tlscert variable is null.

@bucko13
Copy link
Author

bucko13 commented Jan 16, 2020

Yep, that's a possibility. Also just making TLS optional could do it too. I guess it depends on what use cases you want to allow vs. ones you want to block. It's possible to have a lightning node with no TLS and not behind https for example. From what I could gather from clients like Zap, when connecting to a BTCPay Server, it just ignores the TLS when setting the grpc client. This is what I added to boltwall too (in order to support btcpay)

@jacohend
Copy link
Collaborator

I think we might want to avoid the specific case of no TLS and no https, but I don't see a problem with supporting any other case. I think in general we should encourage encrypted connections if the connection is nonlocal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants