--- Log opened Mon Apr 05 00:00:16 2021 01:39 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 260 seconds] 02:09 -!- rny [~rny@gateway/tor-sasl/renlord] has quit [Ping timeout: 240 seconds] 02:18 -!- rny [~rny@gateway/tor-sasl/renlord] has joined #c-lightning 03:21 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning 03:32 -!- jasan [~j@2001:470:1f1b:365:4ad7:5ff:fec0:6beb] has joined #c-lightning 03:33 < jasan> C-Lightning meeting tonight at 20:00 UTC (in 9 hours and half from now) 03:33 < jasan> $ TZ=UTC date 03:33 < jasan> Mon Apr 5 10:32:52 UTC 2021 03:34 < jasan> (note that EU is now UTC+2) 03:50 -!- _rny [~rny@gateway/tor-sasl/renlord] has joined #c-lightning 03:50 -!- rny [~rny@gateway/tor-sasl/renlord] has quit [Quit: watering my plants] 03:58 -!- _rny [~rny@gateway/tor-sasl/renlord] has quit [Ping timeout: 240 seconds] 03:59 -!- rny [~rny@gateway/tor-sasl/renlord] has joined #c-lightning 04:44 -!- belcher_ is now known as belcher 04:48 -!- jasan [~j@2001:470:1f1b:365:4ad7:5ff:fec0:6beb] has quit [Quit: What a sunny day!] 04:59 -!- Sebubu [b9ec9b48@185.236.155.72] has joined #c-lightning 05:00 < Sebubu> Hey Hey 05:07 < Sebubu> I just found this chat. I opened a Github issue recently but I believe it is better discussed here. It is probably not an actual software bug but rather a misconfiguration on my side. 05:07 < Sebubu> When I want to send a payment, I get an `WIRE_TEMPORARY_CHANNEL_FAILURE` error and I am not sure why. 05:07 < Sebubu> Issue: https://github.com/ElementsProject/lightning/issues/4467 05:07 < Sebubu> Would be grateful if somebody could help. 05:08 < Sebubu> Happy Eastern! 05:45 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-appjcgjzwowenres] has left #c-lightning [] 05:45 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-appjcgjzwowenres] has joined #c-lightning 05:47 < nibbier> Sebubu: as the getblock command fails constantly (I assume for the same block) your lighting node is not synced. I don't know the details, but this surely is a grave problem. what happens if you execute the command that fails on the commandline? after all c-lightningis just calling bitcoin-cli to get the block. 05:48 < darosior> getblock failures are non fatal for historical blocks (to support pruning) 05:50 < Sebubu> nibbier Here is the output: 05:50 < Sebubu> ```bitcoin-cli getblock 00000000000000000003ca8a7f65d708e1848bea621da9b0d9a5da4af08702c1 05:50 < Sebubu> error code: -1 05:50 < Sebubu> error message: 05:50 < Sebubu> Block not available (pruned data) 05:50 < Sebubu> ``` 05:50 < Sebubu> As darosior mentioned, theoretically a pruned node is supported. 05:50 < darosior> It's fine then and probably not related to your issue (didn't read it though) 05:53 < nibbier> why does c-lightning request this data, if it does not actually need it? (just trying to learn) 05:53 < nibbier> 2021-04-04T14:50:52.744Z INFO 0217890e3aad8d35bc054f43acc00084b25229ecff0ab68debd82883ad65ee8266-chan#7: htlc 366 failed from 0th node with code 0x1007 (WIRE_TEMPORARY_CHANNEL_FAILURE) 05:53 < nibbier> 2021-04-04T14:50:52.750Z INFO plugin-pay: cmd 63 partid 10: failed: WIRE_TEMPORARY_CHANNEL_FAILURE (reply from remote) 05:54 < darosior> It does need it but is not critical, it's to proof check that a channel exists when it's gossiped to us 05:54 < nibbier> As this is repeated for all attempts, with the same chan#7 part, I assume that the all payments are tried via the same outgoing channel from you, and this first node doesnot have the capacity required? 05:54 < nibbier> darosior: ah, interesting! thanks. 05:57 < nibbier> okay, the capacit is just another guess, but anyway the issue seems to be with the first hop 06:00 < Sebubu> Let me check the capacities again 06:04 < Sebubu> According to 1ml.com, the capacities should be no problem. 06:07 < Sebubu> Shouldn't lightning try both paths in case one node is broken? Both my channels have a path to the destination node. 06:08 -!- qubenix [~qubenix@66.172.11.228] has quit [Quit: quit] 06:15 -!- qubenix [~qubenix@66.172.11.228] has joined #c-lightning 06:18 < nibbier> Sebubu: just to note, I'm not way an expert, just trying to put thought into it :D capacity is only shown in total for foreign nodes, channel balance is crucial. 06:19 < Sebubu> Ohhh, you are right. This is the node capacity. This is pretty misleading on 1ml.com! 06:19 < Sebubu> Aren't we are just trying to learn hereĀ =D 06:21 < Sebubu> Also, if this is the case then a better error message than `WIRE_TEMPORARY_CHANNEL_FAILURE` would help enormously 06:27 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has joined #c-lightning 06:29 < nibbier> Sebubu: WIRE_TEMPORARY_CHANNEL_FAILURE /* These are an indication that the capacity was insufficient. 06:30 < Sebubu> I am now in the process of opening a channel to the wallet directly. Let's see what happens then 06:30 < nibbier> but this seems to be only one possible reason for this 06:31 < Sebubu> Channel capacities should be public IMO. It's really had to debug the problem without 06:33 -!- qubenix [~qubenix@66.172.11.228] has quit [Quit: quit] 06:36 < nibbier> Sebubu: public capacitys would tremendously help routing, debugging, planning, but it would be horrible for privacy 06:36 < Sebubu> nibbier Absolutely agree. I am just saying this from a developers point of view 07:03 < Sebubu> Ok, I opened up a direct channel to the wallet and the payments worked now. It is very interesting that one of the biggest nodes doesn't have capacity to one of the biggest wallets. Rebalancing must be still a big issue if it doesn't work between two major services. 07:06 -!- qubenix [~qubenix@66.172.11.228] has joined #c-lightning 07:11 < nibbier> set the fees for this channel high enough ro close/reopen the channel if it depletes :) 07:13 < Sebubu> Good idea 07:28 -!- Sebubu [b9ec9b48@185.236.155.72] has quit [Quit: Connection closed] 07:45 -!- Sebubu [b9ec9b48@185.236.155.72] has joined #c-lightning 08:22 <@niftynei> nibbier: if you're certain that the funding tx is not mined and is not going to be mined and you're running your node as DEVELOPER=1, then you can remove the channel using dev-forget-channel 08:22 <@niftynei> the best way to ensure that the funding tx will not be mined is to double-spend its input elsewhere 08:23 <@niftynei> this is why i said "it depends", btw -- your options of what to do when your channel is in state CHANNELD_AWAITING_LOCKIN depends very much on the state of the funding tx 08:23 < ctrlbreak> warren : I too was just stung by using 'slow' when sweeping one of my CL nodes. It appears to have generated a TX with a fee of just a hair above 4sat/vbyte... which I fear may not ever get confirmed. Unfortuantely, I also used 'all' so I don't believe I can leverage RBF either. It's destined for another core wallet I have running, so I'm curious about attempting a CPFP TX, but I lack the knowledge to construct the required raw TX (at the 08:23 < ctrlbreak> moment). 08:25 -!- Sebubu [b9ec9b48@185.236.155.72] has quit [Quit: Connection closed] 08:26 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal] 08:41 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined #c-lightning 09:13 < nibbier> niftynei: okay, thanks. thing is I'm scared of losing funds, so i run $ lightning-cli listtransactions | grep cbfe985a5214e057570b5e7a30fe60ccae8451755f606d711ee5e64e2a97d149 -c 09:15 < nibbier> with cbfe... being the "funding txid" of the channel in question, the result is 0 (no transaction like this known to c-lightning?) 09:16 < nibbier> does this confirm that this transaction did not execute? I'd like to spend the relevant inputs to be safe, but as I can't find the transaction, I don't know which inputs it spent 09:29 <@niftynei> did you open the channel? 09:29 < nibbier> niftynei: I initiated it, unsuccessfully as it seems 09:30 <@niftynei> how long ago? your logs would have better info 09:30 <@niftynei> *probably have better info; i'm not sure what non-debug level logs look like haha 09:30 < nibbier> weeks... looking for logs 09:38 < nibbier> logfile just enabled now :( 09:41 <@niftynei> does the funding txid show up in listfunds? 09:41 < az0re> FWIW: 09:41 < az0re> user@host:~$ bitcoin-cli getmempoolentry cbfe985a5214e057570b5e7a30fe60ccae8451755f606d711ee5e64e2a97d149 09:41 < az0re> error code: -5 09:41 < az0re> error message: 09:41 < az0re> Transaction not in mempool 09:42 < az0re> user@host:~$ bitcoin-cli getrawtransaction cbfe985a5214e057570b5e7a30fe60ccae8451755f606d711ee5e64e2a97d149 09:42 < az0re> error code: -5 09:42 < az0re> error message: 09:42 < az0re> No such mempool or blockchain transaction. Use gettransaction for wallet transactions. 09:42 <@niftynei> thanks az0re 09:42 < az0re> Maybe it's chilling at 1sat/byte or something and it's just been evicted from my mempool 09:42 < az0re> But it looks like the network has forgotten it 09:43 <@niftynei> there's a few possibilities here. 1) it entered the mempool at too low a feerate and has since been evicted 09:43 <@niftynei> 2) it never made it into the mempool 09:43 <@niftynei> the logs would confirm; nibbier have you tried getlogs 09:43 <@niftynei> where is the id of the node you're trying to make the channel to? 09:44 <@niftynei> also, what version of clightning are you running? 09:44 < nibbier> now on 0.10 09:45 < nibbier> lightning-cli getlog | grep 0341f639f7d87aa78d4c1962480c4c11c6e096ebb1618ab6a7400d37e7cb72f70a <-- yields no result 09:47 <@niftynei> i'd feel a lot more confident about forgetting the channel if you could figure out what inputs were in that tx (and confirm they've been spent elsewhere) 09:48 < nibbier> niftynei: okay... guess I'll ignore the channl for now, and spend all my utxos before getting rid of it... at best while creating new channels :) 09:48 < az0re> Can't you just look in the 'outputs' field of 'listfunds' and look for UTXOs with '"reserved": true'? 09:49 <@niftynei> az0re: maybe? 09:49 < nibbier> all outputs are reserved: false 09:49 <@niftynei> reservations expire though; it's possible that the reservation expired and it got spent elsewhere in the intervening weeks 09:49 < az0re> I see 09:49 < az0re> In any case it looks like that channel funding tx is long gone 09:50 < az0re> It's possible someone saved it and will re-broadcast it once feerates deflate 09:50 < az0re> But I doubt it :) 09:50 < nibbier> thanks niftyne, az0re 09:51 <@niftynei> the expiration, in theory, is meant to help with this problem -- a channel open gets 'cancelled' automatically (via a double-spend) if it doesnt get mined/confirmed before the expiration/respend 09:51 <@niftynei> np! 09:51 < nibbier> ah, that sounds like this might have resolved it anyway 09:51 < az0re> Could be.. 09:51 < nibbier> just like the channel was left in the database 09:52 < az0re> niftynei: is the double-spend at the same feerate the user specified for the fundchannel? 09:52 <@niftynei> right. it'd be a lot easier to confirm if we knew what that funding tx looked like. 09:53 <@niftynei> well the double-spend is more in practice than intentional -- if you don't use your funds after the expiration is up then it won't get re-spent 09:54 <@niftynei> az0re, the feerate would be at whatever you've specified for the fundchannel, that's correct 09:54 < az0re> Oh I see 09:54 < az0re> Wait 09:54 < az0re> Now I'm confused 09:54 < az0re> The funds are double-spent by C-Lightning to prevent the channel open from succeeding/funds getting stranded? 09:55 < az0re> Or they're double spent incidentally by people doing regular withdraw or funding operations? 09:56 < az0re> The reserved flag expires after a timeout, then those funds are *available* for double-spending but not actually double-spent unless the user does some on-chain operation that chooses that/those UTXO(s)? 09:56 <@niftynei> Ah. Not exactly. When you go to open a channel the utxos are marked as reserved. At some point, that reservation expires and the utxos become marked as available for being used elsewhere by the wallet/utxo selection mechanism 09:56 <@niftynei> az0re, yeah that's right 09:56 < az0re> OK cool gotcha 09:57 < az0re> Can funds get stranded with a super delayed channel point? 09:57 <@niftynei> rusty's working on re-working how we handle these types of problems, fwiw 09:57 < az0re> Or do we always have a commitment tx to recover our funds? 09:57 <@niftynei> what's a "super delayed channel point" 09:57 <@niftynei> You always have a commitment tx to recover funds 09:58 <@niftynei> As long as you don't "dev-forget-channel" haha 09:58 < az0re> I fundchannel now, the channel point isn't confirmed for 6 months 09:58 <@niftynei> Why would the channel point not be confirmed for 6 months 09:58 < az0re> Suppose the channel peer disappears 1 month after opening, before confirmation 09:59 < az0re> Suppose it's at 1sat.byte and the mempool is filled up to 10sat/b with 300MB 09:59 < nibbier> some other questions on my quest to understand ln: why can i specify an onion or an IP, but not a dns name to specify my announce-address? 09:59 <@niftynei> If the channel peer disappears but the funding tx gets mined, you'd broadcast the commitment tx to force close the channel/recover your funds 10:00 <@niftynei> if the funding tx is never confirmed, you'd respend the inputs elsewhere to ensure the channel never opens 10:00 < az0re> So there is no state where I rely on the other party to move the funds, even during the channel opening process? 10:00 <@niftynei> you might have to wait til the tx falls out of the mempool (or follow the RBF feerate rules for it) but that'd be how you'd handle the mempool stuck problem 10:00 < az0re> Right, that's fine 10:04 <@niftynei> you can also, presently, use CPFP to get a mempool-stuck funding tx pulled through, provided you've got a change output on it (which is very likely) 10:04 < az0re> Makes sense 10:04 <@niftynei> v2 of opens will let you (attempt) to RBF. i say "attempt" because it relies on cooperation with your channel peer 10:05 < az0re> I guess the answer is yes, I just wanted to make sure that in the channel opening process, we get a valid peer signature on the initial commitment tx *before* even sending any sats to the channel point 10:27 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 10:28 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 10:56 -!- early` [~early@static.38.6.217.95.clients.your-server.de] has quit [Quit: Leaving] 10:57 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Quit: jonatack] 11:06 -!- early [~early@static.38.6.217.95.clients.your-server.de] has joined #c-lightning 11:23 -!- jasan [~j@2001:470:1f1b:365:4ad7:5ff:fec0:6beb] has joined #c-lightning 11:32 -!- jasan [~j@2001:470:1f1b:365:4ad7:5ff:fec0:6beb] has quit [Quit: brb] 11:32 -!- jasan [~j@2001:470:1f1b:365:4ad7:5ff:fec0:6beb] has joined #c-lightning 11:32 -!- jasan [~j@2001:470:1f1b:365:4ad7:5ff:fec0:6beb] has quit [Client Quit] 11:47 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #c-lightning 12:00 -!- jasan [~j@n.bublina.eu.org] has joined #c-lightning 12:10 -!- belcher is now known as belcher_ 12:11 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 12:48 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds] 13:00 < jasan> cdecker: is there a meeting tonight? 13:02 < jasan> niftynei: ^^ ? 13:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 13:02 < jasan> yes 13:03 <@niftynei> oh. yes 13:03 < jasan> :) 13:04 < rusty> https://meet.jit.si/CLightning-Open-Meeting 13:04 < rusty> For anyone who wants to join us! 13:34 -!- jasan [~j@n.bublina.eu.org] has quit [Quit: Night here.] 13:38 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 13:47 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer] 13:54 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #c-lightning 14:05 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-appjcgjzwowenres] has left #c-lightning [] 14:06 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-appjcgjzwowenres] has joined #c-lightning 14:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 14:23 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 14:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 14:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 15:11 -!- qubenix [~qubenix@66.172.11.228] has quit [Quit: quit] 15:13 -!- qubenix [~qubenix@66.172.11.228] has joined #c-lightning 17:08 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning 17:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 20:21 -!- reallll [~belcher@unaffiliated/belcher] has joined #c-lightning 20:24 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 21:05 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection] 21:06 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #c-lightning 22:05 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection] 22:16 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-appjcgjzwowenres] has left #c-lightning [] 22:16 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-appjcgjzwowenres] has joined #c-lightning --- Log closed Tue Apr 06 00:00:18 2021