The Lightning Network FAQ

[darkv0rt3x]

You need to remove all '$' signs from the command.

Code:

usermod -a -G debian-tor bitcoin

Done and restarted C-Lightning. The error remains. Something tells me that I have to reinstall C-Lightning for the 4th time. Any tutorials recommended besides n0nce's that I have to also install openSUSE?

Do you have any incoming connections in Bitcoin Core? Does it run behind Tor as well?

Yes and yes.

Have you managed to make it work? I also struggled with this. And I did so many things that I can't even say what was wrong!

If you still haven't managed it to work, we can try to go step by step, check config files, check services, check logs, etc!

[1714286241]

1714286241

[1714286241]

1714286241

[1714286241]

1714286241

[1714286241]

1714286241

[1714286241]

1714286241

[1714286241]

1714286241

[BlackHatCoiner]

Have you managed to make it work?

Hi, thanks for your persistence!

I think that my node should be working fine. This is my getinfo:

Code:

admin@raspibolt:~/.lightning/testnet $ lightning-cli --testnet getinfo
{
   "id": "0261f00131d87b1bb2b02e6d96ad31d72e33c1c9e8a87583f734c000e9a0155144",
   "alias": "LightningVortex",
   "color": "0261f0",
   "num_peers": 1,
   "num_pending_channels": 0,
   "num_active_channels": 1,
   "num_inactive_channels": 0,
   "address": [
      {
         "type": "torv3",
         "address": "xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion",
         "port": 9735
      }
   ],
   "binding": [
      {
         "type": "ipv4",
         "address": "127.0.0.1",
         "port": 9735
      }
   ],
   "version": "v0.10.2",
   "blockheight": 2138884,
   "network": "testnet",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat",
   "lightning-dir": "/home/admin/.lightning/testnet"
}

Code:

0261f00131d87b1bb2b02e6d96ad31d72e33c1c9e8a87583f734c000e9a0155144@xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion:9735

Try to connect with me, we'll most likely connect properly. Electrum doesn't, though:

At least it gives me a message now. Could I have a context of what does that mean?

[darkv0rt3x]

Have you managed to make it work?

Hi, thanks for your persistence!

I think that my node should be working fine. This is my getinfo:

Code:

admin@raspibolt:~/.lightning/testnet $ lightning-cli --testnet getinfo
{
   "id": "0261f00131d87b1bb2b02e6d96ad31d72e33c1c9e8a87583f734c000e9a0155144",
   "alias": "LightningVortex",
   "color": "0261f0",
   "num_peers": 1,
   "num_pending_channels": 0,
   "num_active_channels": 1,
   "num_inactive_channels": 0,
   "address": [
      {
         "type": "torv3",
         "address": "xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion",
         "port": 9735
      }
   ],
   "binding": [
      {
         "type": "ipv4",
         "address": "127.0.0.1",
         "port": 9735
      }
   ],
   "version": "v0.10.2",
   "blockheight": 2138884,
   "network": "testnet",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat",
   "lightning-dir": "/home/admin/.lightning/testnet"
}

Code:

0261f00131d87b1bb2b02e6d96ad31d72e33c1c9e8a87583f734c000e9a0155144@xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion:9735

Try to connect with me, we'll most likely connect properly. Electrum doesn't, though:

At least it gives me a message now. Could I have a context of what does that mean?

I still couldn't connect to you!

[n0nce]

I still couldn't connect to you!

Interesting. What about using ID + IP / onion address? Sometimes it's not propagated correctly (either misconfiguration or gossip protocol shortcomings). If it doesn't work with address, then it has to be firewall rule or something like that.

@BlackHatCoiner can you check that the onion address is correct?

[darkv0rt3x]

I still couldn't connect to you!

Interesting. What about using ID + IP / onion address? Sometimes it's not propagated correctly (either misconfiguration or gossip protocol shortcomings). If it doesn't work with address, then it has to be firewall rule or something like that.

@BlackHatCoiner can you check that the onion address is correct?

I used his URI! Not the pub key alone! But I also try the pubkey alone after the URI failed!

[BlackHatCoiner]

@BlackHatCoiner can you check that the onion address is correct?

Sure.

Code:

admin@raspibolt:~ $ sudo cat /var/lib/tor/lightningd_hidden_service/hostname
xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion

My configuration file:

Code:

HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8334
# uncomment:

HiddenServiceDir /var/lib/tor/hidden_service_electrs/
HiddenServiceVersion 3
HiddenServicePort 50002 127.0.0.1:50002
HiddenServicePort 60002 127.0.0.1:60002

HiddenServiceDir /var/lib/tor/lightningd_hidden_service/
HiddenServiceVersion 3
HiddenServicePort 9735 127.0.0.1:9735

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

I used his URI! Not the pub key alone! But I also try the pubkey alone after the URI failed!

Maybe it's not my fate to get involved into Lightning. 

[darkv0rt3x]

@BlackHatCoiner can you check that the onion address is correct?

Sure.

Code:

admin@raspibolt:~ $ sudo cat /var/lib/tor/lightningd_hidden_service/hostname
xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion

My configuration file:

Code:

HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8334
# uncomment:

HiddenServiceDir /var/lib/tor/hidden_service_electrs/
HiddenServiceVersion 3
HiddenServicePort 50002 127.0.0.1:50002
HiddenServicePort 60002 127.0.0.1:60002

HiddenServiceDir /var/lib/tor/lightningd_hidden_service/
HiddenServiceVersion 3
HiddenServicePort 9735 127.0.0.1:9735

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

I used his URI! Not the pub key alone! But I also try the pubkey alone after the URI failed!

Maybe it's not my fate to get involved into Lightning. 

Show again your lightning-cli getinfo

Check your PMs.

[BlackHatCoiner]

Show again your lightning-cli getinfo

Code:

admin@raspibolt:~ $ lightning-cli --testnet getinfo
{
   "id": "0261f00131d87b1bb2b02e6d96ad31d72e33c1c9e8a87583f734c000e9a0155144",
   "alias": "LightningVortex",
   "color": "0261f0",
   "num_peers": 1,
   "num_pending_channels": 0,
   "num_active_channels": 1,
   "num_inactive_channels": 0,
   "address": [
      {
         "type": "torv3",
         "address": "xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion",
         "port": 9735
      }
   ],
   "binding": [
      {
         "type": "ipv4",
         "address": "127.0.0.1",
         "port": 9735
      }
   ],
   "version": "v0.10.2",
   "blockheight": 2139359,
   "network": "testnet",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat",
   "lightning-dir": "/home/admin/.lightning/testnet"
}

[darkv0rt3x]

Show again your lightning-cli getinfo

Code:

admin@raspibolt:~ $ lightning-cli --testnet getinfo
{
   "id": "0261f00131d87b1bb2b02e6d96ad31d72e33c1c9e8a87583f734c000e9a0155144",
   "alias": "LightningVortex",
   "color": "0261f0",
   "num_peers": 1,
   "num_pending_channels": 0,
   "num_active_channels": 1,
   "num_inactive_channels": 0,
   "address": [
      {
         "type": "torv3",
         "address": "xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion",
         "port": 9735
      }
   ],
   "binding": [
      {
         "type": "ipv4",
         "address": "127.0.0.1",
         "port": 9735
      }
   ],
   "version": "v0.10.2",
   "blockheight": 2139359,
   "network": "testnet",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat",
   "lightning-dir": "/home/admin/.lightning/testnet"
}

Well, apparently there is some issues when trying to connect to nodes in different networks. So, for the sake of testing, I would suggest either someone on the testnet trying to connect to you or you change to mainnet and try to connect to me (or I connect to you when you're in the mainnet).

After that we can try to keep searching for the problem/solution!

[n0nce]

After that we can try to keep searching for the problem/solution!

I have a new theory: maybe simply too small amount of Tor nodes on Testnet? Without enough, gossip doesn't really work well.
Back when I ran a testnet node, it ran through normal IP and even there, it was hard to find routes and stuff due to low amount of nodes, bad liquidity and unbalanced channels (because there is no financial incentive).

[BlackHatCoiner]

Without enough, gossip doesn't really work well.

But, there's no use of the gossip protocol. When you're connecting with me, I'm handing you over my URI which contains the onion address. (Unless that's not what you're talking about)

Anyway, I've forgotten to mention about @darkv0rt3x. They voluntarily assisted me through Telegram and I hadn't even asked for it. We were searching of what was causing this problem for an hour, trying different commands, retrying them, exchanging screenshots etc. They even invited me in a c-lightning Telegram channel to discuss it with others. Thank you dark! This is the kind of people the crypto space needs. Willing to spent a spare of their time to encourage others continue.

Back to my issue. This is my getinfo:

Code:

admin@raspibolt:~ $ lightning-cli --testnet getinfo
{
   "id": "0261f00131d87b1bb2b02e6d96ad31d72e33c1c9e8a87583f734c000e9a0155144",
   "alias": "LightningVortex",
   "color": "0261f0",
   "num_peers": 1,
   "num_pending_channels": 0,
   "num_active_channels": 1,
   "num_inactive_channels": 0,
   "address": [
      {
         "type": "torv3",
         "address": "cj5syu6qa6s2oft4vmh3wlyyvmr4naa7b34ah5f75moibt3i3awkz5ad.onion",
         "port": 9735
      },
      {
         "type": "torv3",
         "address": "xixzo67fevmab7wytj5qp7mowvbildpbr7xgaj4hp5dbqgr36termcyd.onion",
         "port": 9735
      }
   ],
   "binding": [
      {
         "type": "ipv4",
         "address": "127.0.0.1",
         "port": 19735
      }
   ],
   "version": "v0.10.2",
   "blockheight": 2140851,
   "network": "testnet",
   "msatoshi_fees_collected": 0,
   "fees_collected_msat": "0msat",
   "lightning-dir": "/home/admin/.lightning/testnet"
}

So, apparently, I now have two onion addresses and the second one definitely not works. According to dark, the cj5sy...onion works on main net, but not on test net. Any clues?

[n0nce]

Without enough, gossip doesn't really work well.

But, there's no use of the gossip protocol. When you're connecting with me, I'm handing you over my URI which contains the onion address. (Unless that's not what you're talking about)

Oh right, gossip would only be a potential issue if the URI was not available and I'd try connecting with node ID alone.

So, apparently, I now have two onion addresses and the second one definitely not works. According to dark, the cj5sy...onion works on main net, but not on test net. Any clues?

I will look into this again in the next few days (busy times ); one random idea would be to maybe recreate the onion services (since then you get new addresses).

[BlackHatCoiner]

Each time there's a commitment transaction, the "committer" (self) sends a per_commitment_secret so that the other party (remote) can punish them in the future, in case they cheat. Once the other party receives it, from the committer's revoke_and_ack, they can use it to construct the revocation signing key for the old commitment, which will allow them to spend both theirs and the committer's funds.

The committer is safe as long as they don't publish that old signed transaction. What I don't understand is what will they reveal if they do broadcast it. According to my understanding, the other party needs to somehow work out the private key of revocation_pubkey, which is revocation_priv.

Code:

revocation_priv = (revocationbase_priv * sha256(revocation_basepoint || per_commitment_point)) + (per_commitment_secret * sha256(per_commitment_point || revocation_basepoint)) mod N

They lack knowledge of revocationbase_priv, right? So how can they calculate it?

[dkbit98]

Anyone used this silent.link website for purchasing anonymous eSIM and getting burner phone number?
It looks interesting, pricing is reasonable and most important thing is they accept payments in Bitcoin and Lightning Network, without using any kyc or email address registration.
This could be a good option for privacy if your smartphone is supporting eSIM option, or just for testing and using LN payments


https://silent.link/

I see they are using BTCPay Server for accepting paments.

[DaveF]

Anyone used this silent.link website for purchasing anonymous eSIM and getting burner phone number?
It looks interesting, pricing is reasonable and most important thing is they accept payments in Bitcoin and Lightning Network, without using any kyc or email address registration.
This could be a good option for privacy if your smartphone is supporting eSIM option, or just for testing and using LN payments

https://silent.link/

I see they are using BTCPay Server for accepting paments.

Interesting, but it's an esim so unless you can get one of the listed phones anonymously it can still be tied back to you.

I would thing that it's probably more anonymous to just walk into a local store and pick up a cheap phone with for cash and then use Bitrefill or similar service to keep it topped up if needed.

Nice find. If I had one of those phones I would give it a try, but since they are all more expensive units I'll stick to my old OnePlus

-Dave

[Rath_]

They lack knowledge of revocationbase_priv, right? So how can they calculate it?

revocationbase_priv = revocation_basepoint_secret

Commitment transactions are asymmetrical. Here's what happens when A wants to update.

A constructs B's commitment transaction. Let's assume that it has only 2 outputs ("to_local" and "to_remote"). "to_local" output is delayed. "to_remote" output can be spent immediately.

In B's commitment transaction, "to_local" can be spent by B after a delay and "to_remote" refunds A their coins. In this case, A uses their "revocation_basepoint" and B's "per_commitment_point" to calculate the revocation public key.

A sends "commitment_signed", which includes the signatures for that transaction, to B. Once B verifies if the signature is valid, they can send "revoke_and_ack" which includes "per_commitment_secret" used to generate "per_commitment_point" for the previous commitment transaction, and "next_per_commitment_point" which A will need in the future to construct the next B's commitment transaction.

Code: (https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#completing-the-transition-to-the-updated-state-revoke_and_ack)

    type: 133 (revoke_and_ack)
    data:
        [channel_id:channel_id]
        [32*byte:per_commitment_secret]
        [point:next_per_commitment_point]

A is now able to generate revocation private key for B's previous commitment transaction as they know B's "per_commitment_secret". B repeats the same process for A's commitment transaction. They use B's "revocation_basepoint" and A's "per_commitment_point" for the revocation public key to lock the "to_local" output.

If A broadcasts their previous commitment transaction, B can spend A's "to_local" output immediately using their revocation private key, which includes A's "per_commitment_secret" and B's "revocation_basepoint_secret".

Note that A and B don't send (un)signed transactions between each other. They only need to exchange signatures as they can construct each other's commitment transaction at any time.

The committer is safe as long as they don't publish that old signed transaction. What I don't understand is what will they reveal if they do broadcast it. According to my understanding, the other party needs to somehow work out the private key of revocation_pubkey, which is revocation_priv.

Nothing is really revealed at that moment. Both parties can reconstruct both commitment transaction at any time. However, they can't publish the other party's commitment as they don't have all signatures. Once the commitment transaction is broadcast, it can't be replaced*. Both parties have everything they need to  broadcast a penalty transaction before the outdated commitment transaction is broadcast.

* - it doesn't make sense to replace the current commitment transaction using RBF with some old one paying a higher fee as its "to_local" output can be spent immediately by one of the parties anyway.

[dkbit98]

Interesting, but it's an esim so unless you can get one of the listed phones anonymously it can still be tied back to you.

You can just buy any used smartphone that supports eSIM, for example Google Pixel 2, or newer models, some Huawei, Samsung, Oppo or other models.
Even some computers are supporting eSIM, like Microsoft Surface, Acer Swift, HP Elitebook, some Lenovo Yoga models, etc.
I never used it myself but I think it's great for privacy and good use case for Lightning.

[BlackHatCoiner]

Nothing is really revealed at that moment.

I mean when one tries to cheat by broadcasting an outdated commitment transaction. As far as I've understood, the cheater needs both signatures to spend from the force-closed multi-sig address.

I'm typing this example to ensure that I get it.

1. Alice opens a 0.1 BTC channel with Bob.
2. Alice wants to send him 0.02 BTC, so she signs a transaction with two outputs: A) to_local (that can be spent by her after x blocks) and B) to_remote that can be spent by Bob instantly.
3. Alice sends him the commitment_signed message, which contains her signature.
4. Bob responds with revoke_and_ack, where he's inserted his new commitment point (for the next revocation public key) and the secret for the previous commitment so that Alice can punish him in case he cheats. (Which wouldn't make sense in our case as he'd earn 0 sats)
5. Bob sends her the commitment_signed message, which contains his signature.
6. Alice responds with revoke_and_ack where she's inserted her new commitment point and her secret for the previous commitment.

Is it correct? I confess that the terminology is hard to grasp.

[DaveF]

Stupid question:

Is there a way to choose what inputs you use when opening channel?

I just opened a channel and instead of using the 1 large input it consolidated about 8 small ones.
Not a big deal since I don't care when it opens and I have the fee set to 1 sat/b but had I taken the default / suggested 15 sat/b I would have spent a fair amount of BTC.

-Dave

[Rath_]

Is there a way to choose what inputs you use when opening channel?

Yes. However, I believe that you need to construct the funding transaction manually when using either LND or c-lightning.

c-lightning: lightning-utxopsbt, lightning-openchannel_init, lightning-openchannel_update, lightning-signpsbt, lightning-openchannel_signed

I have never tested it, so you might want to check the documentation more carefully to see if I am correct before trying it out.

-snip

I have been slightly busy lately with some private affairs and my research on Ethereum L2 projects, but I still have in mind to reply to your post.