CLN configuration help using bitcoin RPC password and username

[openoms]

Running CLN with the plugin from the latest PeerSwap commit using RPC password and username. The plugin exits right after starting. What the problem could be?

logs:

INFO    plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
INFO    lightningd: --------------------------------------------------
INFO    lightningd: Server started with public key 03b2b374a259d2ec8ca46f7db079fbb12b6e307dbb319b1d2f911500e332e41d41, alias BIZARREARK (color #03b2b3) and lightningd v0.11.2
INFO    plugin-peerswap-plugin: PeerSwap Initialized, running PeerSwap commit baf6e4c38d16dcd922f94e777bcd892db5b0bc5f
INFO    plugin-peerswap-plugin: Liquid swaps disabled
DEBUG   plugin-peerswap-plugin: connecting with RPC_USER, RPC_PASSWORD to :0
INFO    plugin-peerswap-plugin: Killing plugin: exited during normal operation

config:

# lightningd configuration for bitcoin testnet
network=testnet
log-file=cl.log
log-level=debug:plugin-peerswap-plugin
plugin-dir=/home/bitcoin/tcl-plugins-enabled

# Tor settings
proxy=127.0.0.1:9050
bind-addr=127.0.0.1:19736
addr=statictor:127.0.0.1:9051/torport=19736
always-use-proxy=true

peerswap-bitcoin-rpcuser=RPC_USER
peerswap-bitcoin-rpcpassword=RPC_PASSWORD
peerswap-elementsd-enabled=false
peerswap-bitcoin-rpchost=localhost
peerswap-bitcoin-rpcport=18332

[wtogami]

Any different if you comment out this line? peerswap-bitcoin-rpchost=localhost?

2022-06-26T07:48:30.270Z DEBUG   plugin-peerswap-plugin: connecting with __cookie__, b0379b8a9cd0b7bbb59e846c4b5ede87786b400e31511ab5f192fb8089054e58 to http://127.0.0.1:8332

Your :0 looks suspicious when it looks like this on my host. :0 made me think IPv6? I have no idea if PeerSwap is trying NS lookup if you have a hostname there. For security reasons we should probably be sure that's turned off and insist upon IP addresses there only? We could special case localhost to be valid and always 127.0.0.1? (It is weird and rare but valid to have other 127.0.0.0/24 addresses be also localhost ...)

[openoms]

Tried with peerswap-bitcoin-rpchost=127.0.0.1 and with the line removed, but the output remains the same:

DEBUG   plugin-peerswap-plugin: connecting with RPC_USER, RPC_PASSWORD to :0
INFO    plugin-peerswap-plugin: Killing plugin: exited during normal operation

[wtogami]

Is IPv6 enabled on that host? I just noticed my main peerswap environments don't have IPv6. Could you disable it temporarily and see if the behavior changes?

[openoms]

IPv6 was not used on any related interface, but in any case disabled everywhere and also restarted, but no change,

[grubles]

Not sure how valuable this feedback is but I've run into this before too. I had a few different plugin config parameters set so I couldn't determine which was causing the plugin to crash/exit. On a separate box with nothing explicitly set -- basically using whatever peerswap expects -- it worked fine.

I'm not sure if it's related to ipv6 necessarily since I was not using that on the box where the plugin was crashing.

[nepet]

Not sure how valuable this feedback is but I've run into this before too. I had a few different plugin config parameters set so I couldn't determine which was causing the plugin to crash/exit. On a separate box with nothing explicitly set -- basically using whatever peerswap expects -- it worked fine.

I'm not sure if it's related to ipv6 necessarily since I was not using that on the box where the plugin was crashing.

I also ran into this issue helping shahana to configure her plugin. My guess is that the peerswap- prefix in the docs is not necessary.

https://github.com/ElementsProject/peerswap/blob/abe90935afcff70f4c5d1e85be7ae28e4d2cad46/cmd/peerswap-plugin/main.go#L438-L446

This should be the broken code that does not set the bitcoin config if the peerswap- config is set, but takes the cln bitcoind connection parameters when unset.

This needs to be fixed but in the meantime the workaround would be: Do not set the peerswap- configs for the connection parameters.

[openoms]

ok, can confirm this. The rpc connection settings were not set as running with the same user lightningd can read them from the bitcoin.conf.

Working CLN config:

# lightningd configuration for bitcoin testnet

network=testnet
log-file=cl.log
log-level=debug:plugin-peerswap-plugin
plugin-dir=/home/bitcoin/tcl-plugins-enabled

# Tor settings
proxy=127.0.0.1:9050
bind-addr=127.0.0.1:19736
addr=statictor:127.0.0.1:9051/torport=19736
always-use-proxy=true

bitcoin-rpcuser=RPC_USER
bitcoin-rpcpassword=RPC_PASSWORD
bitcoin-rpcconnect=localhost
bitcoin-rpcport=18332

peerswap-elementsd-enabled=false

Logs now:

INFO    plugin-peerswap-plugin: PeerSwap Initialized, running PeerSwap commit baf6e4c38d16dcd922f94e777bcd892db5b0bc5f                                                                                       
INFO    plugin-peerswap-plugin: Liquid swaps disabled
DEBUG   plugin-peerswap-plugin: connecting with RPC_USER, RPC_PASSWORD to http://localhost:18332
INFO    plugin-peerswap-plugin: Bitcoin swaps enabled
INFO    plugin-peerswap-plugin: using policy:
INFO    plugin-peerswap-plugin: reserve_onchain_msat: 0
INFO    plugin-peerswap-plugin: allowlisted_peers: []
INFO    plugin-peerswap-plugin: accept_all_peers: true
INFO    plugin-peerswap-plugin: CAUTION: Accept all incoming swap requests
INFO    plugin-peerswap-plugin: peerswap initialized

[nepet]

Help me out here: Is there any reasonable scenario where I would want to override the bitcoin connection config that we collect from cln? Else we could just drop these fields. Separate bitcoind for swaps?

[openoms]

Using a separate bitcoind sounds exciting! Would that need another CLN wallet connected also?

Anyway if the connection details are not configured PeerSwap expects the auth cookie despite CLN using the RPC user and password automatically.

[wtogami]

Using a separate bitcoind sounds exciting! Would that need another CLN wallet connected also?

But why!? =)

Anyway if the connection details are not configured PeerSwap expects the auth cookie despite CLN using the RPC user and password automatically.

Sane default should be for PeerSwap to use whatever CLN is using. There may be complication though if CLN is using one of the alternative plugins for backend lookup that isn't the default bcli. For this and other possible reasons retaining explicit config options may be a good idea.

[wtogami]

Help me out here: Is there any reasonable scenario where I would want to override the bitcoin connection config that we collect from cln?

If it isn't a maintenance burden we should keep these config fields as a last resort. While "Separate bitcoind for swaps?" seems useless I wouldn't be surprised if arbitrary lookup plugins that replace bcli work for CLN but don't work for PeerSwap.

We should have sane defaults in this order:

• Try whatever CLN is currently using.
• Try the default cookie path.
• Try the specified cookie path (but no other options are provided).
• If the other rpc options are provided they override all the above because the user asked for it for whatever reason.

Documentation should explain this clearly. Docs should show all the config options but with a leading # character on each so they are not used if copy & pasted into a config file.

[openoms]

I agree with all above.

The separate wallet used for funding swaps is offtopic here and surely not a priority. I can see a privacy benefit there when there is a separate pool of funds used for peerswap, different from what the channels are being funded and closed to (force closes always return to the internal wallet). It can be further complicated by using liquidity ads / dual funded channels which are funded from the same onchain wallet.

[nepet]

I suggest we drop the peerswap- prefix for now, clean up the broken config generator and have a separate discussion about overriding the cln connection config in the future.

[openoms]

be aware of peerswap-bitcoin-rpchost=localhost (not working) vs bitcoin-rpcconnect=127.0.0.1 (working)

[wtogami]

I can see a privacy benefit there when there is a separate pool of funds used for peerswap, different from what the channels are being funded and closed to (force closes always return to the internal wallet).

Good point. Could you start a new ticket on that?