--- Log opened Fri Mar 19 00:00:00 2021 00:10 -!- vincenzopalazzo [~vincenzop@host-79-46-92-180.retail.telecomitalia.it] has quit [Ping timeout: 264 seconds] 00:10 -!- vincenzopalazzo [~vincenzop@host-79-30-9-166.retail.telecomitalia.it] has joined #c-lightning 01:42 -!- swissmoney69 [496f167f@c-73-111-22-127.hsd1.il.comcast.net] has quit [Quit: Connection closed] 03:10 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 03:35 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has left #c-lightning [] 03:35 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has joined #c-lightning 06:25 -!- gleb8 [~gleb@178.150.137.228] has joined #c-lightning 06:33 -!- Netsplit *.net <-> *.split quits: gleb 06:33 -!- gleb8 is now known as gleb 06:53 < warren> multifundchannel is a batch method to open channels with one onchain tx. Is there a similar method to batch multiple cooperative closings? 07:01 < warren> vincenzopalazzo: so you had a cooperative close? I think what you're seeing is not an actual error, the bug is the plugin shouldn't think it is an error. 07:01 < warren> 2021-03-18T14:09:15.790Z UNUSUAL plugin-btcli4j-gen.sh: Response from server: sendrawtransaction RPC error: {\"code\":-27,\"message\":\"Transaction already in block chain\"} 07:01 < warren> 2021-03-18T14:09:15.794Z **BROKEN** plugin-btcli4j-gen.sh: Error during the request method Transaction already in block chain 07:03 < vincenzopalazzo> : Yes I found the mistake the problem it what you are saying, I don't need to crash but it is a good option for c-lightning 07:03 < vincenzopalazzo> it is running right now over java https://1ml.com/testnet/node/03b1330add0c75e0b2e1401dc61028a3d2351b9fef439d703f7ff71f3a182f9192/channels 07:12 <@cdecker> warren: regarding multiclose, no that's not currently possible in the spec, since the closing negotiation is limited to the single funding output being an input in the closing tx 07:19 < warren> vincenzopalazzo: file an issue? 07:20 < warren> cdecker: does the timing of cooperaive close matter if we want a cheaper fee rate? 07:25 <@cdecker> Yes, both endpoints will have current fee estimates, and they'll negotiate based on those estimates, unlike unilateral which uses estimates that use estimates * multiplier at the time the signature was created. 07:32 -!- jonatack_ [~jon@37.166.79.41] has joined #c-lightning 08:06 < vincenzopalazzo> warren: Any issue at the moment :) 08:15 <@cdecker> Yep, clarified that on TG already yesterday: the error is just a log entry, not escalated, because it is actually quite normal for a broadcast to fail. In this case both endpoints negotiated a collaborative close, and both immediately broadcast the close tx once the negotiation finishes. Since both broadcast, whoever broadcasts later might already 08:15 <@cdecker> find its peers broadcast in progress, which logs an error. 08:15 <@cdecker> We track transaction confirmation progress and should we notice that an urgent transaction is not getting confirmed, we start escalating 08:16 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection] 08:17 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning 08:50 < vincenzopalazzo> cdecker: very clear, thank you! To understand more on how the c-lightning managed the channel I think I will make some analysis over this plugin and track all the calls 09:09 <@cdecker> Oh, I was just summarizing the discussion on TG for those that haven't seen it ^^ 09:19 < vincenzopalazzo> cdecker: Oh, I'm sorry :-P I didn't catch the intend 09:20 <@cdecker> No problem, just didn't want you to think I was lecturing you ^^ 09:23 -!- jonatack_ [~jon@37.166.79.41] has quit [Read error: Connection reset by peer] 09:36 < vincenzopalazzo> cdecker: Oh, a lecture is welcome in any case :-) 09:38 < vincenzopalazzo> p.s: I'm working on an issue with esplora API that you commented and give some additional details here https://github.com/lightningamp/esplora_clnd_plugin/issues/39#issuecomment-749111098 and I think that is possible work around the exception 10:48 -!- csknk [~csknk@unaffiliated/csknk] has joined #c-lightning 10:58 -!- jonatack_ [~jon@37.166.79.41] has joined #c-lightning 11:30 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 12:02 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has left #c-lightning [] 12:03 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has joined #c-lightning 12:06 -!- belcher_ is now known as belcher 12:25 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 12:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning 12:57 -!- jonatack_ [~jon@37.166.79.41] has quit [Remote host closed the connection] 12:58 -!- jonatack_ [~jon@37.166.79.41] has joined #c-lightning 13:07 -!- jonatack__ [~jon@37.165.139.59] has joined #c-lightning 13:10 -!- jonatack_ [~jon@37.166.79.41] has quit [Ping timeout: 256 seconds] 13:39 -!- jonatack__ [~jon@37.165.139.59] has quit [Quit: jonatack__] 13:41 -!- jonatack [~jon@37.165.139.59] has joined #c-lightning 14:18 -!- jonatack [~jon@37.165.139.59] has quit [Ping timeout: 240 seconds] 15:00 -!- jonatack [~jon@37.165.139.59] has joined #c-lightning 15:03 -!- jonatack [~jon@37.165.139.59] has quit [Read error: Connection reset by peer] 15:04 -!- jonatack [~jon@37.165.139.59] has joined #c-lightning 15:07 -!- jonatack [~jon@37.165.139.59] has quit [Read error: Connection reset by peer] 15:07 -!- jonatack_ [~jon@37.165.139.59] has joined #c-lightning 15:11 -!- dongcarl5 [~dongcarl@unaffiliated/dongcarl] has joined #c-lightning 15:12 -!- dongcarl5 [~dongcarl@unaffiliated/dongcarl] has quit [Client Quit] 15:12 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Write error: Connection reset by peer] 15:16 -!- rubikputer [~rubikpute@unaffiliated/rubikputer] has quit [Ping timeout: 264 seconds] 15:51 < grubles> i've been running lightningd on openbsd 6.8 for a couple days now without issues. i was able to sync the gossip data from a peer successfully. haven't tried opening a channel yet though. 16:00 -!- jonatack_ [~jon@37.165.139.59] has quit [Read error: Connection reset by peer] 16:37 < vincenzopalazzo> grubles: If you are on testnet maybe can you try to open a channel with my node https://1ml.com/testnet/node/03b1330add0c75e0b2e1401dc61028a3d2351b9fef439d703f7ff71f3a182f9192 I'm making some tests too :-D 17:16 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #c-lightning 19:40 < grubles> vincenzopalazzo: i'll sync a testnet node and ping you once i'm done 20:18 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has left #c-lightning [] 20:18 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-iyngssqtppxfqsbk] has joined #c-lightning 21:20 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning 21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 21:53 < openoms> the issue of my peer is that he is running CentOS 7 where Clightning v0.9+ does not compile. 21:56 < openoms> I presume running a binary compiled on a different version of the system (CentOS 8) cannot be recommended for a system in production. There is no OS update path either. 22:00 < openoms> The 2016 block since my attempted funding will pass in two days. Do you think that in the future there will be a chance to extract them? https://github.com/ElementsProject/lightning/issues/4416#issuecomment-802955473 22:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 22:13 < warren> Is there already a signet LN? That might be more reliable than testnet as an underlying network. 22:18 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 268 seconds] --- Log closed Sat Mar 20 00:00:01 2021