--- Log opened Mon May 24 00:00:04 2021
00:01 -!- Rath_ [594a4662@89-74-70-98.dynamic.chello.pl] has quit [Quit: Connection closed]
01:58 < urza> is there and easy way how to increase fees on channel that is already being open - tx is submited to mempool, but not mined and fees are probably too low..
01:58 < urza> ?
02:00 < vincenzopalazzo> urza do you mean the fee of the transaction to open the channel?
02:02 < vincenzopalazzo> <Rath_ "Hi. Is there any detailed docume"> looks like that the doc is missing, I'm not able to see the doc in any place, you can find all the doc available here https://github.com/ElementsProject/lightning/tree/master/doc maybe I made a wrong check and it is there
02:04 < urza> vincenzopalazzo yes, I used the feerate=slow and it ended being 4 sats/vB wich seems somewhat risky now, if mempool increases I am worried that it might stay unconfirmed..
02:05 < vincenzopalazzo> urza yes, it look like it a little bit low for the actual mempool status https://twitter.com/CoreFeeHelper/status/1396741480258015233?s=20
02:08 < vincenzopalazzo> I think your transaction will go confirmed in any case, as cdecker said in some issue on lightningd, the miners have no reason to maintain the transaction on the mempool
02:11 < vincenzopalazzo> but any way this issue can met your situation right? https://github.com/ElementsProject/lightning/issues/4515#issuecomment-845859857
02:25 < urza> Is it possible to use openchannel_bump to increase fee in this case?
02:31 < jasan> urza: Last time I was trying to openchannel_bump a multi-fund transaction (in the end funded only by me) lead to this: https://github.com/jsarenik/clightning-dual-crash-logs/issues/1
02:34 < urza> Did it work for you in the end?
02:39 < vincenzopalazzo> urza No experience with that and not enouth knowlgene to say somethings, but jasan play with that :-p
02:39 < jasan> urza: No, the other node already forgot about the channel and the unhandled case was worked on in https://github.com/ElementsProject/lightning/pull/4521 though now I doubt the results as the channel was not properly one-side closed (yet, I am waiting for further instructions).
02:39 < jasan> (sorry, I forgot to press ENTER)
02:40 < vincenzopalazzo> <jasan "(sorry, I forgot to press ENTER)"> :-D
02:40 < jasan> That's why I am trying to make people comment on https://github.com/ariard/L2-zoology/pull/7
02:41 < vincenzopalazzo> I'm reading, slowly but I'm reading :)
02:53 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Quit: k3tan]
02:53 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
03:09 < urza> LND ma jednoduchý příkaz kterým se dá díky RBF bumnout fee u otevrení kanaálu.. to by chtělo i do c-lightning..
03:10 < urza> ups, wrong chat.. it translates as: "LND has a command that can RBF bump fee on opening channel tx, I wish there is something like that in c-lightning"
03:11 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds]
03:17 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning
03:25 -!- opsec_x12 [~opsec_x12@44-25-143-42.ip.hamwan.net] has joined #c-lightning
03:26 -!- opsec_x122 [~opsec_x12@44-25-143-42.ip.hamwan.net] has quit [Ping timeout: 246 seconds]
04:49 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-tcmhyidyotayoduh] has left #c-lightning []
04:49 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-tcmhyidyotayoduh] has joined #c-lightning
04:54 -!- belcher_ is now known as belcher
07:51 <@niftynei> you can't RBF an open tx using the v1 protocol, which LND uses. their 'bump' command most likely does a CPFP
07:51 < jasan> urza: ^^
07:52 <@niftynei> Rath: there is no documentation on `funderupdate` yet, you are correct. it's in master but it hasn't been included in a release yet
07:52 <@niftynei> the API for it might change before the next release
07:53 <@niftynei> urza: what state is the channel in that you're looking to RBF?
07:53 <@niftynei> the best way to increase the fee would be to figure out what the change address is on the funding tx and spend it as a CPFP
07:55 <@niftynei> `openchannel_bump` is only eligible for use for v2 opens. i'd strongly suggest you use the latest master for doing any openchannel_bumps however, as the last released version has several bugs in it (as jasan has discovered)
07:56 < urza> niftynei thanks, unfortunately it has no change address, it spends the whole utxo
07:56 < urza> state of the channel is  "state": "CHANNELD_AWAITING_LOCKIN",
07:58 <@niftynei> that state means it's a v1 open, the only option you'd have for that is a CPFP
07:58 <@niftynei> but sounds like that's not an option
08:01 < urza> What is the worst that can happen if it stays unconfirmed for long time? There are some issues on gihtub with channels being forgotten by counterparty and then confirming and becoming in some bad state..?
08:05 < urza> Stupid me, I should have tought more about fees when opening the channel. I just passed feerate=slow, but with mempool relativle low I didnt realized that it is actually risky because slow on already low mempool means too low and then mempool started filling up.. oh well..
08:05 <@niftynei> well let's think about this. you've broadcast a tx that spends some coins. when that tx gets mined, it will lock the funds to the funding point.
08:06 <@niftynei> if your peer has forgotten about the channel, they will never confirm that it's been mined so the channel will never be usable (as it requires cooperation from your peer)
08:06 <@niftynei> in that case, you have a unilateral close tx that you can broadcast. the close tx spends the funding outpoint to a timelocked output, which you can claim back to your wallet after it expires
08:07 <@niftynei> in listpeers this txid is listed in the `scratch_txid`
08:07 < urza> to make things worse I also pushed half of the channel balance to other side (it is a friend and we agreed on that)
08:09 < urza> Would it be possible to abandon the channel and then double spend the funding utxo with higher fees?
08:09 <@niftynei> you can 'cancel' the open by double-spending the utxo
08:11 < urza> Any instructions how to do that safely? I mean c-lightning must probably first be instructed to forgot about the channel so it allows for double spend, right?
08:11 <@niftynei> i would not recommend forgetting a channel that you have funds locked in that might still confirm
08:12 <@niftynei> how long as it been since you attempted to open the channel?
08:13 <@niftynei> you should be able to call `close` on the channel and broadcast a close tx, then attempt to double-spend the funding tx
08:13 <@niftynei> hopefully your friend's node hasn't forgotten it and will sign a mutual close with you, in which case they'll be able to recover the funds you've pushed them
08:14 < urza> Just one day, but it is 4.4 sats/vB..
08:14 <@niftynei> ah ok then they should still remember it
08:14 <@niftynei> right, so the close won't make it confirm any faster but it will mean that the funds wont be lost if the double-spend attempt doesnt work
08:14 <@niftynei> or if it gets confirmed 
08:15 <@niftynei> actually i should have just said 'if it gets confirmed'
08:17 < urza> How would do the doublespending?
08:18 <@niftynei> after you've closed the currently open channel, you should be able to call fundchannel_start with your peer's node to initiate a new open
08:21 <@niftynei> well hmm
08:21 <@niftynei> this is assuming that you want to double-spend the utxo into another funding tx for the same channel
08:21 <@niftynei> the easiest thing to do is just straight double-spend it
08:22 <@niftynei> i cant remember if funding tx's in v1 signal for RBF (i suspect they dont)
08:22 < urza> yeas, the tx has RBF opted in
08:23 < urza> but c-lightning will not let me doublespend it (as long as the funding tx is in mempool), will it?
08:24 <@niftynei> well c-lightning's marked it as 'reserved' in the database and wont voluntarily put it into a new tx unless you tell it to
08:26 <@niftynei> you can use `utxopsbt` to build a new psbt that spends the utxo (you'll need to say reservedok=true)... but the API's not really great for adding the funding output to the resulting PSBT lol
08:27 <@niftynei> you're into manual land now haha
08:28 < urza> ok, so unreserve the input and then just create new onchain tx with high fee.. I will wait day or two and if the fundung tx is not confirmed I will probably try this
08:28 < urza> thanks a lot for your help
08:29 <@niftynei> sure, np
08:31 < Ademan> dumb question but why the bcli plugin instead of directly making rpc calls?
08:31 < Ademan> (I mean it could still live in a plugin, but why bitcoin-cli rather than making the calls itself)
08:32 <@niftynei> Ademan: it lets you swap out bcli for a different plugin, if you wanted to use a different blocksource 
08:33 <@niftynei> for ex i think there's bitcoin backend plugins that use a blockexplorer as the blocksource rather than bitcoind; or have fallbacks in case bitcoind doesnt have a block etc
08:37 < Ademan> well sure I understand why it's a plugin, but I don't understand why it uses bitcoin-cli (Why did they write "plugins/bcli.c" instead of "plugins/brpc.c" )
08:38 < Ademan> unless you're saying there's like a blockchain-info-cli command that is a drop-in-replacement for bitcoin-cli, which is pretty cool if true
08:38 < darosior> Ademan: because nobody got to implement an HTTP + JSONRPC client
08:39 < darosior> It would be a nice improvement though, but might be tricky as we rely on bitcoin-cli specific stuff. At least it's contained in bcli 
08:40 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has joined #c-lightning
08:40 < darosior> And then if you do that, do you write raw hacky HTTP headers ala https://github.com/apoelstra/rust-jsonrpc or do you bring a whole dependency just for HTTP ?..
08:40 <@niftynei> Ademan: bcli is a wrapper for bitcoin-cli, hence the name. you replace bcli the plugin with a different plugin.
08:41 < Ademan> darosior: ah that's a good point, a lot of extra complexity to "do it right"
08:42 < darosior> Exactly, right now it's not The Right Way :tm: but is kinda simple :)
08:43 < darosior> Note however than doing it right would bring nice benefits, like being able to see bitcoin-cli credentials by `ps`ing from another process ..
08:56 < jasan> Ademan: see this for few bcli hacks using public explorers https://github.com/lightningd/plugins/issues/112#issuecomment-818789990
09:00 < Ademan> jasan: that's neat, thanks
09:14 -!- jasan [~j@n.bublina.eu.org] has quit [Quit: reboot]
09:14 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has joined #c-lightning
09:29 -!- urza [2e27accb@ip4-46-39-172-203.cust.nbox.cz] has quit [Quit: Connection closed]
10:43 -!- urza [2e27accb@ip4-46-39-172-203.cust.nbox.cz] has joined #c-lightning
11:14 -!- deusexbeer [~deusexbee@093-092-176-212-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 265 seconds]
11:16 -!- deusexbeer [~deusexbee@093-092-179-195-dynamic-pool-adsl.wbt.ru] has joined #c-lightning
12:12 < m-schmoock> ... couple of weeks of and everything is bugged :) 
12:12 < m-schmoock> >  INFO    plugin-pay: Killing plugin: exited during normal operation
12:13 < m-schmoock> >  **BROKEN** plugin-pay: Plugin marked as important, shutting down lightningd!
12:17 < m-schmoock> The pay plugin didnt log anything suspicous before the crash. Is this addressed by #4555 ?
12:25 -!- urza [2e27accb@ip4-46-39-172-203.cust.nbox.cz] has left #c-lightning []
12:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
13:06 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-tcmhyidyotayoduh] has left #c-lightning []
13:06 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-tcmhyidyotayoduh] has joined #c-lightning
14:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]
14:39 -!- Norrin [~Joe@2605:2700:0:5::4713:9659] has joined #c-lightning
17:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
18:05 -!- Netsplit *.net <-> *.split quits: rusty, deusexbeer
18:15 -!- Netsplit over, joins: rusty, deusexbeer
19:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
20:14 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has quit [Ping timeout: 258 seconds]
20:58 -!- jasan [~j@adsl-dyn20.78-98-38.t-com.sk] has joined #c-lightning
21:09 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
21:11 -!- jasan [~j@adsl-dyn20.78-98-38.t-com.sk] has quit [Ping timeout: 252 seconds]
21:12 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
21:27 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-tcmhyidyotayoduh] has left #c-lightning []
21:28 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-tcmhyidyotayoduh] has joined #c-lightning
21:34 -!- jasan [~j@78.98.61.72] has joined #c-lightning
22:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 268 seconds]
23:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
23:39 < jasan> m-schmoock: Welcome back! :-)
--- Log closed Tue May 25 00:00:05 2021