Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 14:09

    t-bast on emoji-encoding

    (compare)

  • 14:05

    t-bast on rework-tx-publisher

    WIP (compare)

  • Jun 14 09:29

    sstone on bitcoin-kmp

    Validate payment secret when de… Merge branch 'master' into bitc… (compare)

  • Jun 11 16:11

    t-bast on payment-secret-refactor

    (compare)

  • Jun 11 16:11

    t-bast on master

    Validate payment secret when de… (compare)

  • Jun 11 15:49

    t-bast on rework-tx-publisher

    WIP (compare)

  • Jun 10 14:58

    t-bast on payment-secret-refactor

    Remove payment_secret mismatch … Clean up PaymentInitiator reque… (compare)

  • Jun 09 16:29

    sstone on bitcoin-kmp

    Include routing hints in parsei… Expose eclair datadir to plugin… Fix eventually statements (#183… and 4 more (compare)

  • Jun 09 13:56

    sstone on upgrade-bitcoin-lib

    (compare)

  • Jun 09 13:56

    sstone on master

    Use bitcoin-lib 0.19 (#1839) T… (compare)

  • Jun 09 12:20

    t-bast on bitcoin-21

    (compare)

  • Jun 09 12:20

    t-bast on master

    Udpate to Bitcoin Core 0.21.1 (… (compare)

  • Jun 09 10:21

    t-bast on tx-publisher-unlock-utxos

    Ensure commitTx is published be… (compare)

  • Jun 09 08:34

    t-bast on tx-publisher-unlock-utxos

    Enrich isTransactionOutputSpend… (compare)

  • Jun 08 13:25

    t-bast on bitcoin-21

    Udpate to Bitcoin Core 0.21.1 … (compare)

  • Jun 08 13:04

    t-bast on payment-secret-refactor

    fixup! Validate payment secret … (compare)

  • Jun 08 12:58

    t-bast on payment-secret-refactor

    Validate payment secret when de… (compare)

  • Jun 07 14:28

    sstone on upgrade-bitcoin-lib

    Use bitcoin-lib 0.19 There are… (compare)

  • Jun 07 13:50

    sstone on upgrade-bitcoin-lib

    Use bitcoin-lib 0.19 There are… (compare)

  • Jun 07 12:55

    t-bast on unannounced-channel-error-update

    (compare)

Dave Scotese
@dscotese
Computer Management | Services shows that Tor Win32 Service is running.
Dave Scotese
@dscotese
I added port forwarding rules for 9050 and 9051 and restarted the service but I still get the same error.
Dave Scotese
@dscotese
My channel partner using Umbrel sees that the channel between us is active, so it doesn't make sense to me that Eclair can't establish a connection, or say "already connected."
xbukorg
@xbukorg
@dscotese Try to connect to my node with name "herobrain" throught my torr address. I have also Win10 with Eclair configured and torr running without problem.
Dave Scotese
@dscotese
@xbukorg Tried it. RTL says "Peer Connection Failed" but I don't even see log entries related to it, so I tried Eclair-cli and that created log entries:
2021-06-07 13:42:55,456 INFO  f.a.e.io.Switchboard - creating new peer current=16
2021-06-07 13:42:55,485 INFO  f.a.e.i.ReconnectionTask CON n:033a83907e818490946627b44f889cce154c90dd5c0f5a7ff47f517b49f4836c02 - connecting to n62jysymbduafppek7a5fm5fs5glj3ragfayew4kpwgh2dnngtqfcpad.onion:9735
2021-06-07 13:42:55,485 INFO  f.a.e.io.ClientSpawner - initiating new connection to nodeId=033a83907e818490946627b44f889cce154c90dd5c0f5a7ff47f517b49f4836c02 origin=Actor[akka://eclair-node/deadLetters]
2021-06-07 13:42:55,486 INFO  f.acinq.eclair.io.Client CON n:033a83907e818490946627b44f889cce154c90dd5c0f5a7ff47f517b49f4836c02 - connecting to n62jysymbduafppek7a5fm5fs5glj3ragfayew4kpwgh2dnngtqfcpad.onion:9735
2021-06-07 13:42:55,492 INFO  f.acinq.eclair.io.Client CON n:033a83907e818490946627b44f889cce154c90dd5c0f5a7ff47f517b49f4836c02 - connection failed to n62jysymbduafppek7a5fm5fs5glj3ragfayew4kpwgh2dnngtqfcpad.onion:9735
Dave Scotese
@dscotese
Tor Service PTE.PNG
This is how the Win32 Tor Service looks. @xbukorg does your service have the same "Path to Executable"? Specifically, I'm wondering if the quotation marks around the -f might be causing a problem.
xbukorg
@xbukorg
@dscotese Contact me through mail herobrain_lightning_network_node@protonmail.com I try to help you.
viaj3ro
@viaj3ro
I switched my node to a new IP address and now I have 98 peers that my node can't connect to
I have to lookup the IP of each offline peer on 1ml and manually reconnect.
Why is that? Shouldn't my node be able to reconnect automatically?
And why are my peers also not reconnecting? I'm advertising the new IP since more than 2 hours now. Is it fully up to me to reconnect or should they not be able to also reconnect due to me advertising the new IP?
viaj3ro
@viaj3ro
Ok, I think I found the reason:
2021-06-09 07:07:16,838 INFO  f.acinq.eclair.io.Client CON n:0260fab633066ed7b1d9b9b8a0fac87e1579d1709e874d28a0d171a1f5c43bb877 - connection failed to 54.245.57.153:9735
2021-06-09 07:07:16,839 INFO  f.a.e.i.ReconnectionTask CON n:0260fab633066ed7b1d9b9b8a0fac87e1579d1709e874d28a0d171a1f5c43bb877 - connection failed (reason=connection failed to /54.245.57.153:9735), next reconnection in 3600 seconds
the IP address my node is trying to connect to, isn't valid since more than a year ago and has changed 3 times since
why doesn't have my node the latest correct IP?
Bastien Teinturier
@t-bast
@viaj3ro if you change your IP address, your peers won't reconnect to you. They'll wait for you to connect to them and then will store your new IP address for future reconnections (ie they don't trust the new IP address from node_announcement alone). I don't understand why you cannot connect to old peers though, changing your IP address shouldn't change anything here...
Try manually connecting to these nodes specifying the valid IP address, and it should be saved for future reconnections
Bastien Teinturier
@t-bast
If they changed their IP address and never connected back to you, it's indeed an issue. Maybe in that case we could try the IP address we have in node_announcement if the last one we tried didn't work.
But ideally it should be them connecting to you, so that you can fully validate their IP address.
viaj3ro
@viaj3ro
it seems like only a handful of the 98 peers are on clear net. was able to manually reconnect to most.
The vast majority are TOR peers, which I cannot reconnect myself
If they wait for a re-connection from my node, but my node can't connect to them, how is this supposed to be resolved?
all of my ~80 TOR peers are still disconnected after more than 10 hours now
viaj3ro
@viaj3ro
Maybe in that case we could try the IP address we have in node_announcement if the last one we tried didn't work.
I'd say this is a good strategy regardless
Bastien Teinturier
@t-bast
But it shows that this is not what other implementations do, otherwise these peers would have reconnected to you...
viaj3ro
@viaj3ro
indeed.
but what do I do now, to solve the issue?! Seems like this is a deadlock!
Bastien Teinturier
@t-bast
It's surprising, your node_announcement should have been broadcast to the network with your new IP address.
The only way for them to be aware of your new IP address is to receive that node_announcement (which is re-emitted every time your restart your node).
And then once they've received it, they should eventually try this IP address when they see that the old one doesn't work (unless their implementation doesn't do that).
You can check 1ML to see when they receive your node_announcement and update your IP, other nodes in the network should receive it shortly after that.
viaj3ro
@viaj3ro
yeah, 1ml updated the IP minutes after the switch
but if every client follows the strategy you described above (namely distrusting the node_announcement and relying on the old IP or reconnection from my side) the issue I have now is pretty much expected
seems to me like using node_announcement as a fallback after the first couple reconnection failures should be standard for all clients and maybe even part of the spec?!
viaj3ro
@viaj3ro
and it's not like those channels are slowly coming back online. it's now almost another 2 hours later and the number of disconnected peers is still exactly the same
viaj3ro
@viaj3ro
well... giving it some more time is all I can do anyway. Definitely seems like even irregular IP address changes are something LN can handle at the moment
xbukorg
@xbukorg
Hm... maybe the better strategy is to close all channels before changing of IP address, change IP address and reopen channels again??? Or what is a preferred steps of IP address changing?
Bastien Teinturier
@t-bast
Changing IP addresses should work, that's why we have them in node_announcement, but I don't know how other implementations handle it...
I guess you cannot contact any of these node operators to ask them what software they're running to help troubleshoot why they don't connect back?
viaj3ro
@viaj3ro
well, the way you described eclairs behavior it doesn't really work. from what I can tell, LND behaves the same way and the deadlock doesn't get resolved
I can't contact those peers but I checked on https://hashxp.org/lightning/ and the ones I checked are running LND
a small number has finally managed to reconnect (no idea which implementation they run) but the vast majority is still disconnected and seems mostly (or maybe exclusively) to be running LND
viaj3ro
@viaj3ro
I'd argue falling back to node_announcement should be standard behavior across implementations. Should I open an issue in https://github.com/lightningnetwork/lightning-rfc/ ?
Bastien Teinturier
@t-bast
I agree with you, and we have a comment on our code to fix that (it's been there for ages).
It's not a spec issue, it's an implementation issue, so please open an issue in eclair and one in lnd.
If some of your peers finally reconnected, I'd guess that they're running c-lightning and they implemented this fallback.
viaj3ro
@viaj3ro
will do
viaj3ro
@viaj3ro
Bastien Teinturier
@t-bast
:+1:
Dave Scotese
@dscotese

Eclair on my Windows 10 machine has a tor address but all attempts I make to connect to someone else's tor address produce Connection failed to [redacted].onion:9735 What might be the problem?

"All attempts to connect to someone else's..." makes this sound like I didn't follow Eclair's instructions: "To route them through Tor you can use Tor's SOCKS5 proxy. Add this line in your eclair.conf: eclair.socks5.enabled = true"

Indeed, @xbukorg showed me his eclair.conf and I saw that he has the SOCKS5 proxy enabled and I didn't, so I added those lines (we are also randomizing credentials) and now I am able to connect to other nodes through Tor.

Dave Scotese
@dscotese

This bit of the Tor file (https://github.com/ACINQ/eclair/blob/master/docs/Tor.md) is a bit confusing, given the behavior:

By default, all incoming connections will be established via Tor network, but all outgoing will be created via the clearnet.

When you use connect, you provide a URI which either is or is not a Tor address (ending in .onion). It seems that there is a certain-to-fail attempt to do as the guide explains, create the connection via the clearnet. It's certain to fail because "the .onion TLD is not in the Internet DNS root." It would be handy for Eclair to reject such attempts with "No SOCKS5 Proxy available" if the eclair.socks5.port configuration setting is false (the default), as it was for me.