Bitcoin Forum
June 25, 2024, 01:10:54 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: lightning point-of-sale on: January 08, 2023, 12:39:09 AM
thanks for your help!
makes sense now.
2  Bitcoin / Development & Technical Discussion / Re: lightning point-of-sale on: January 07, 2023, 02:16:18 AM
Hello!

Thank you for your answers.

Why would I need an LN node running on the mobile device with the app?  Or did I misunderstand your answer? 
Why can't the mobile app make json-rpc calls remotely to any LN node available?  Preferably to a node which is closest to the mobile user's location or route?

I don't talk about LN to LN communication but rather about a client (app) / server (LN node) setup.

When you tell to use the invoice RPC command, this is exactly the part I want to do through an API remotely, not by using the lightning-cli command on an LN node.


If I configure 1 LN node with a grpc plugin, then I'm only sure that that specific LN node is running that plugin.  This kind of forces me to only use that node or a cluster of nodes which I configured.  Although a cluster would help it still would reduce the decentralisation aspect by a lot.

I thought the BOLTs were meant to keep standards for alternative lightning implementations such as c-lightning and LND, my bad.

I will look into Breez, I didn't know about this.





Those plugins aren't installed and configured by default which means we loose the benefit of decentralisation.  If I want my app to use one of those plugins I will be limited to nodes which have the plugin installed?!
How's that? Would this mean that you believe decentralization relies on what's 'configured by default'? I.e. Bitcoin as a network is not decentralized because it's not preinstalled on Windows 10? This seems absurd.

I do believe Bitcoin and Lightning are decentralised.  But if only a part of the nodes support grpc calls through a plugin which needs to be installed by its admin, then the remaining part of the nodes become useless to apps requiring grpc.

[moderator's note: consecutive posts merged]
3  Bitcoin / Development & Technical Discussion / lightning point-of-sale on: January 06, 2023, 05:38:55 PM
Hello,

I would like to build a mobile point-of-sale which supports lightning payments.
Still a bitcoin/lightning newbie so I'm reading and experimenting to try and figure out the best architecture.

Bitcoin allows to access its api through json-rpc natively.
I don't really understand why this isn't true for Lightning.

Here are a few questions I have related to lightning:

-Why isn't there a BOLT standard requiring the same API interfacing for both c-lightning and LND?
-For C-lightning there are plugins like cln-grpc and the rest API which can be configured to allow programmatic API access but... 
Those plugins aren't installed and configured by default which means we loose the benefit of decentralisation.  If I want my app to use one of those plugins I will be limited to nodes which have the plugin installed?!

What are my best options If I would use e.g Swift and would like to process payments from the app to the lightning network?

Thanks,
Martin
4  Bitcoin / Bitcoin Technical Support / Re: why does lightningd reset http connection? on: December 09, 2022, 07:24:17 PM
I'm trying to connect to the json-rpc interface remotely through another means than through lightning-cli, the cln-prc plugin, pycln library or charge REST API.
Just by sending an http POST request in order to get back the json answer.  No dependencies to modules, services etc. 

Also the objective is to run my code on a separate web server and keep the bitcoin/lightning config as standard as possible.  Both hosts would run on the same local network and traffic would be secured/encrypted for production.

I can do this without any issues when targeting bitcoind but run into the error described when targeting lightningd.

Same output when using 127.0.0.1 instead of localhost...

curl --user username:password --data-binary '{"jsonrpc":"2.0","id":"curltext","method":"listpeers","params":[]}'  -H 'content-type:text/plain;' http://127.0.0.1:19735 -v
*   Trying 127.0.0.1:19735...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 19735 (#0)
* Server auth using Basic with user 'username'
> POST / HTTP/1.1
> Host: 127.0.0.1:19735
> Authorization: Basic cnBjdXNlcjpycGN1SSSS
> User-Agent: curl/7.68.0
> Accept: */*
> content-type:text/plain;
> Content-Length: 66
>
* upload completely sent off: 66 out of 66 bytes
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

Hopefully I was able to clarify my question.

5  Bitcoin / Bitcoin Technical Support / why does lightningd reset http connection? on: December 09, 2022, 04:36:49 AM
Hello,

I can successfully execute the following curl command locally on a bitcoin-core/lightning node targeting the bitcoin daemon:

input:

curl --user username:password --data-binary '{"jsonrpc":"2.0","id":"curltest","method":"getblockchaininfo","params":[]}'  -H 'content-type:text/plain;' http://localhost:18332 -v

output:

:[]}'  -H 'content-type:text/plain;' http://localhost:18332 -v
*   Trying 1.2.3.4:18332...
* TCP_NODELAY set
* Connected to localhost (1.2.3.4) port 18332 (#0)
* Server auth using Basic with user 'username'
> POST / HTTP/1.1
> Host: localhost:18332
> Authorization: Basic cnBjdXNlcjp3cm9uZ3Bhc312344
> User-Agent: curl/7.68.0
> Accept: */*
> content-type:text/plain;
> Content-Length: 74
>
* upload completely sent off: 74 out of 74 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Fri, 09 Dec 2022 04:11:58 GMT
< Content-Length: 480
<
{"result":{"chain":"test","blocks":2410457,"headers":===removed===="}
* Connection #0 to host localhost left intact


But when trying to target the lightning daemon the connection is being reset by the server:

input:

curl --user username:password --data-binary '{"jsonrpc":"2.0","id":"curltest","method":"listpeers","params":[]}'  -H 'content-type:text/plain;' http://localhost:19735 -v

output:

*   Trying 1.2.3.4:19735...
* TCP_NODELAY set
* Connected to localhost (1.2.3.4) port 19735 (#0)
* Server auth using Basic with user 'username'
> POST / HTTP/1.1
> Host: localhost:19735
> Authorization: Basic cnBjdXNlcjpycGN1234
> User-Agent: curl/7.68.0
> Accept: */*
> content-type:text/plain;
> Content-Length: 66
>
* upload completely sent off: 66 out of 66 bytes
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

I'm using all default settings for lightningd (no config file)

What is the reason the host is resetting the connection?
Do I need to configure anything to make this work?  
Can I use the same RPC credentials as the bitcoin-core node?  Changing the credentials doesn't modify behaviour, same reset error.

Any tip or link to documentation would be greatly appreciated.

Martin
6  Bitcoin / Development & Technical Discussion / Re: how to access lightning json-rpc remotely on: December 08, 2022, 04:53:13 AM
I found the answer on
https://github.com/ElementsProject/lightning/blob/master/doc/lightningd-config.5.md

If 'PORT' is not specified, the default port 9735 is used for mainnet (testnet: 19735, signet: 39735, regtest: 19846). If we can determine a public IP address from the resulting binding, the address is announced.

For testnet I must use 19735 instead of 9735.






bumping into another error

Authorization: Basic cnBjdXNlcjpxxxzEE
> User-Agent: curl/7.79.1
> Accept: */*
> content-type:text/plain;
> Content-Length: 66
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer



this seems to be a better fit for what I need.
https://github.com/ElementsProject/lightning/blob/ee3f059e800b7ffcd7f0ffc6e5037899132b05cd/cln-grpc/README.md

[moderator's note: consecutive posts merged]
7  Bitcoin / Development & Technical Discussion / how to access lightning json-rpc remotely on: December 07, 2022, 10:48:38 PM
Hello,

I'm able to connect to bitcoind remotely from my laptop using following CURL command:

curl --user user:password --data-binary '{"jsonrpc":"2.0","id":"curltest","method":"getblockchaininfo","params":[]}'  -H 'content-type:text/plain;' http://1.2.3.4:18332 -v

but I'm not able to call the lightingd remotely from my laptop using following CURL command:

curl --user user:password --data-binary '{"jsonrpc":"2.0","id":"curltest","method":"listpeers","params":[]}'  -H 'content-type:text/plain;' http://1.2.3.4:9735 -v

Trying 1.2.3.4:9735...
* connect to 1.2.3.4 port 9735 failed: Connection refused
* Failed to connect to 1.2.3.4 port 9735 after 517 ms: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 1.2.3.4 port 9735 after 517 ms: Connection refused

Lightningd is running and I opened 9735 on the firewall.  I can successfully run "lightning-cli -testnet listpeers" on the node locally.

When running "netstat -anpe | grep "9735" | grep "lightning"" I see there's already an established session on 9735.  

tcp         0      0 1.2.3.4:34918        5.6.7.8:9735       ESTABLISHED 1000       41663      1508/lightning_conn
tcp6       0      0 :::19735                :::*                    LISTEN      1000       40773      1508/lightning_conn

Should I use another port for json-rpc access and leave 9735 for node/peer communication?

I already added 0.0.0.0/0 as rpcallow for testing in the bitcoin.conf file.

Anyone know how I should access lightning json-rpc remotely?

thanks,
Pecheur



Also, I know there's "lightning-cli connect" to connect remotely using the CLI.
But I would like to use JSON-RPC calls instead.  First using CURL then using a nodejs request.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!