--- Log opened Tue Mar 09 00:00:51 2021
00:42 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 276 seconds]
00:42 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined #c-lightning
01:38 -!- jonatack_ [~jon@37.167.192.44] has joined #c-lightning
01:42 -!- jonatack [~jon@37.166.110.136] has quit [Ping timeout: 260 seconds]
01:46 -!- raucao [~raucao@kip.pe] has joined #c-lightning
01:47 < raucao> hi. this may be a dumb question: i'm unable to find the on-chain txid of a channel that is stating it's waiting for a unilateral close
01:48 < raucao> (the opening txid i mean)
01:48 < raucao> anyone knows the command for that?
01:49 <@cdecker> lightning-cli listpeers should list it as funding_txid
01:52 < raucao> ah, thx!
01:58 <@cdecker> np
02:14 < openoms> i have now set a logfile in the config which works, but when i set daemon=true (in line 7) it errors with 'config line 7: daemon: doesn't allow an argument'
02:16 < openoms> all my config is:
02:16 < openoms> # c-lightningd configuration for signet
02:16 < openoms> network=signet
02:16 < openoms> announce-addr=127.0.0.1:97362
02:16 < openoms> #daemon=true
02:16 < openoms> log-file=cl.log
02:16 < openoms> log-level=debug
02:16 < openoms> # Tor settings
02:16 < openoms> proxy=127.0.0.1:9050
02:16 < openoms> bind-addr=127.0.0.1:97362
02:16 < openoms> addr=statictor:127.0.0.1:9051
02:16 < openoms> always-use-proxy=true
02:17 < openoms> running multiple c-lightning services if that counts
02:17 <@cdecker> Never tried setting `--daemon` in a config, setting it from the command line should work though
02:18 < openoms> I see I try to put it to the service, but if all it does is suppress the output it might be not needed
02:23 -!- raucao [~raucao@kip.pe] has left #c-lightning ["Leaving"]
02:33 < openoms> it does not seem to like the daemon setting with multiple processes, complaining about left-overs and unable to lock the pidfile
02:34 < openoms> is there any problem with running with running without daemon=true?
02:37 <@cdecker> Nope, `--daemon` just detaches from the terminal and runs in the background, so if you're using systemd, init, supervisor, or any other service/process manager it won't change anything (well except a bit more work forking the process in `--daemon` mode)
02:46 < openoms> thank you for the explanation. I was only curious because @darosior mentioned that it would deafult to create a logfile in daemon mode, but I rather just use log-file= option in the config.
02:55 -!- isenough [~isenough@irc.21isenough.me] has joined #c-lightning
03:13 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
03:14 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
04:24 < openoms> the logfile of the peer of my stale channel is log-level=debug and almost 3GB. What would be the best  thing to look for when trying to find the funding pubkeys? 
04:24 < openoms> tried: 'tail -n 100000 ~/.lightning/debug.log | grep $CHANNEL_ID -ab5' so far, but no hits. Will try to look in  a bit deeper, but wonder if there is anything better too look for?
04:24 < openoms> The peer has the channel pending as well with ligthning-cli listpeers. Status:
04:24 < openoms>  "CHANNELD_AWAITING_LOCKIN:Reconnected, and reestablished.",
04:24 < openoms>   "CHANNELD_AWAITING_LOCKIN:Funding needs 3 more confirmations for lockin."
04:41 < darosior> Yes i corrected afterwards though
04:54 -!- belcher_ is now known as belcher
05:05 < openoms> simulating on signet with two nodes I got this in the log:
05:05 < openoms> 2021-03-09T12:49:17.546Z DEBUG   02595b0c2cc60d23c21fbeca3774d669ac93b1fd0ae183a647b24ac5eb4453610a-channeld-chan#11: init REMOTE: remote_per_commit = 03b2f37181947386b0ac47d36eae9fb20133a3df08f427d8739608ac2cacce8f5d, old_remote_per_commit = 03b2f37181947386b0ac47d36eae9fb20133a3df08f427d8739608ac2cacce8f5d next_idx_local = 1 next_idx_remote = 1 revocations_received = 0 feerates { RCVD_ADD_ACK_REVOCATION:326 } range 253-4294967295
05:05 < openoms> Can extracting a mesage like this be useful for recovery?
05:08 < darosior> openoms: no you want the 'funding' pubkeys here :/
05:10 < openoms> apart from logging the actions, the connecting nodeID and the watched transaction ID this is all in the logs, so I presume the pubkeys are not logged then.
05:12 < openoms> the only way then is to run a modified hsmtool on both nodes as I understand
05:13 < openoms> would be useful to have it for any other past and future locked funds. Will continue to discuss in: https://github.com/ElementsProject/lightning/issues/4416
05:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
05:15 < darosior> Yes, i believe so too, will take a look at your issue soon ™️
05:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
05:18 < openoms> thank you! There is no urgency since the transaction is confirmed and both nodes will be preserved.
05:18 < darosior> Either we add a signing command to sign to hsmtool, or one to dump the pk (reminds me of the xpriv descriptors that we dropped..)
05:19 < darosior> I think the former would probably take a psbt.. And would probably bloat hsmtool
05:20 < darosior> i'd rather go with dumping the privkey and using an external signer to sign the transaction
05:20 -!- jonatack_ [~jon@37.167.192.44] has quit [Ping timeout: 264 seconds]
05:30 -!- jonatack [~jon@37.167.192.44] has joined #c-lightning
06:21 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-wunnawwznmddxkzr] has left #c-lightning []
06:21 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-wunnawwznmddxkzr] has joined #c-lightning
06:57 -!- jtimon [~quassel@90.166.158.146.dynamic.jazztel.es] has joined #c-lightning
07:47 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
07:54 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined #c-lightning
07:56 -!- andytosh1 is now known as andytoshi
07:57 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
07:58 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
08:04 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #c-lightning
08:54 -!- belcher_ is now known as belcher
09:02 < spinza> is autopilot plugin working at this point?
09:10 < jasan> spinza: have a look at LNBOSS repository
09:12 < jasan> or how was it called /me doesn't us it
09:13 < jasan> clboss
09:13 < jasan> spinza: https://github.com/ZmnSCPxj/clboss
09:31 -!- jasan [~j@n.bublina.eu.org] has quit [Quit: jasan]
09:35 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 276 seconds]
09:36 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #c-lightning
09:41 -!- jonatack [~jon@37.167.192.44] has joined #c-lightning
09:56 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
09:57 < az0re> Is someone attacking my node?
09:57 < az0re> In my `listforwards` I see a bunch of failed forwards with payment hash `aaaaaaa....aaa`
09:57 < az0re> Obviously there is no known preimage for that hash
09:58 < az0re> Maybe my node is being used to route a DoS to some other node?
09:59 < az0re> And is there anything I can do here? I could install circuit breaker that rejects HTLCs with low-entropy payment hashes but that's easily circumvented by using properly random hashes
10:00 < az0re> <az0re> Maybe my node is being used to route a DoS to some other node?
10:01 < az0re> (which would also have the effect of DoSing me to a lesser extent, or at least using up an HTLC slot)
10:04 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined #c-lightning
10:06 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Quit: ZNC 1.8.2 - https://znc.in]
10:37 -!- jonatack_ [~jon@37.167.192.44] has joined #c-lightning
10:37 -!- jonatack [~jon@37.167.192.44] has quit [Read error: Connection reset by peer]
10:40 -!- jonatack_ [~jon@37.167.192.44] has quit [Read error: Connection reset by peer]
10:41 -!- jonatack_ [~jon@37.167.192.44] has joined #c-lightning
10:41 -!- jonatack_ [~jon@37.167.192.44] has quit [Client Quit]
10:42 -!- jonatack [~jon@37.167.192.44] has joined #c-lightning
10:57 < spinza> jasan, thanks looks useful
11:02 <@niftynei> az0re they might be probing to figure out how big payment channels are
11:04 <@niftynei> you could write a plugin for the `htlc_accepted` hook to look for low entropy hashes, and reject htlc's that don't pass your filter
11:04 < spinza> So is clboss > autopilot?
11:04 <@niftynei> see https://github.com/ElementsProject/lightning/blob/master/doc/PLUGINS.md#htlc_accepted
11:04 <@niftynei> spinza: it's certainly more fully featured
11:05 <@niftynei> for example, it implements auto-rebalancing using an on-chain swap provider
11:05 < spinza> i had a bug on launching autopilot on a new node.  wiped my previous install due to it dating from 2018 and having weird issues due to being offline for long periods
11:05 <@niftynei> :/
11:06 <@niftynei> you didn't have any open channels on that offline node did you?
11:07 < spinza> i had one which magically refunded once my node caught up.  was surprised i didn't lose more funds
11:08 < spinza> the others had been refunded years before.
11:09 < spinza> i think i was lucky
11:09 < spinza> should i add watchtower with clboss?
11:13 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 246 seconds]
11:16 < az0re> niftynei: thanks for the tip, and I might, but again, that's easily circumvented by not being so dumb :)
11:16 < az0re> I'm guessing there's really not much else I can do?
11:17 < az0re> Ultimately we can't distinguish random data from hashes with valid, known preimages, so I don't really see what else there is to do
11:18 < az0re> s/by not/by the attacker-slash-prober/ just in case that wasn't clear
11:19 < az0re> fuck, s/by not/by the attacker-slash-prober not/
11:19 <@niftynei> spinza, a watchtower is a good idea but tbh i'm not really sure what the options are on that front currently
11:19 -!- jonatack [~jon@37.167.192.44] has joined #c-lightning
11:19 <@niftynei> az0re: you're welcome to try tuning parameters and see what kind of stuff you reject
11:20 < az0re> which parameters should I tune?
11:21 <@niftynei> hard to say without seeing the type of payments you're trying to prevent! the low-entropy hash value seems straightforward enough
11:22 <@niftynei> there might be other indicators like htlc expriy times etc that would give you some level of signal, but tbh i'm not really well versed in routing parameter details. cdecker's a much better resource on this topic
11:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
11:32 < az0re> oooh
11:32 < az0re> wait, so I can reject HTLCs will to far-dated expiry?
11:32 < az0re> with*
11:32 < az0re> that's super cool
11:33 < az0re> thanks for the tips, I will definitely investigate further
11:33 < az0re> and sorry for my complete inability to type today
12:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
12:46 -!- jonatack [~jon@37.167.192.44] has quit [Ping timeout: 264 seconds]
12:55 < HelloShitty> I'm always missing jasan here. :\
12:55 < HelloShitty> I replied in github issue!
12:55 < HelloShitty> I hope he doesn't think I'm ignoring him! :\
13:01 < HelloShitty> A noob question. Bare with me please. If I want to move fund from c-lightning node on-chain address to another address out of my c-lightning node, what is the command I need to use to perform the transaction?
13:48 -!- jtimon [~quassel@90.166.158.146.dynamic.jazztel.es] has quit [Remote host closed the connection]
14:07 < t0mix_> HelloShitty: lightning-cli withdraw destination satoshi [feerate] [minconf] [utxos]
14:07 -!- t0mix_ is now known as t0mix
14:32 < HelloShitty> t0mix: thank you
14:33 < HelloShitty> What is used for, the option `txprepare` ?
14:34 < t0mix> The txprepare RPC command creates an unsigned transaction which spends funds from c-lightning’s internal wallet to the outputs specified in outputs.
14:34 < t0mix> https://github.com/ElementsProject/lightning/blob/master/doc/lightning-txprepare.7.md
14:34 < t0mix> so.. for unsigned transaction build
14:36 < HelloShitty> but what would be the usage of unsigned transactions?
14:36 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-wunnawwznmddxkzr] has left #c-lightning []
14:36 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-wunnawwznmddxkzr] has joined #c-lightning
14:36 < HelloShitty> maybe as a means of using online nodes to create transactions and then move them to offline nodes to sign them?
14:38 < t0mix> sounds about right :)
14:41 < HelloShitty> ok
14:41 < HelloShitty> thanks again
14:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
15:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
15:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
15:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
15:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
16:18 < rubikputer> theoretical question: would it be possible to write a c-lightning plugin that exposes an new RPC interface that's a subet of the lnd RPC interface?
16:38 -!- Ed0 [~edouard@2001:41d0:401:3100::4897] has quit [Ping timeout: 264 seconds]
17:05 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 276 seconds]
17:06 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has joined #c-lightning
17:10 < rusty> rubikputer: definitely.
17:12 < rubikputer> I've been looking for a way to use Lightning Pool with and Zap as a remote control for c-lightning, do you think it's worth the effort to look into?
17:18 < rusty> rubikputer: it'll be interesting.  Note that you need a modification to use Pool, since they change the commitment transaction to add an extra lockup term I believe, but it's not specified anywhere?
17:18 < rubikputer> I believe I read somewhere that isn't implemented in the alpha version yet
17:19 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 264 seconds]
17:19 < rusty> rubikputer: ah, interesting
17:21 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has joined #c-lightning
17:40 -!- spinza [~spin@102.132.245.16] has quit [Quit: Coyote finally caught up with me...]
17:50 < az0re> > since they change the commitment transaction to add an extra lockup term I believe
17:50 < az0re> To prevent the opener from closing the channel before the contractual term expires?
17:50 < rusty> az0re: yeah, that was the intent.
17:50 < az0re> That's rad
17:51 < rusty> I mean, they can just not use the channel, but they can't get their money back until the timeout.
17:51 < az0re> Right, I was just gonna say
17:55 < az0re> They can still just reject HTLCs, or even unilaterally send a `shutdown` message and irreversibly transition the channel state to what C-Lightning calls `CHANNELD_SHUTTING_DOWN` and thus make the channel useless according to BOLT 2, right?
17:57 < rubikputer> there's a few things you can do like that yeah, but the idea is that it creates an incentive for them to keep the channel open and active because they won't be able to get their funds back until after the lease would expire and in the meantime they'd be able to collect routing fees
17:57 < rubikputer> so they'd be griefing themselves too
17:58 < az0re> And probably get punished by Lightning Labs, maybe even banned from the platform
17:58 < az0re> But yeah, makes sense
17:59 < az0re> Maybe it's just some basic Script but I think genuine "blockchain tech" applications like this are so cool
18:01 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has left #c-lightning ["WeeChat 3.0.1"]
18:01 -!- rny [~rny@gateway/tor-sasl/renlord] has joined #c-lightning
18:02 < rubikputer> yeah it's a pretty key part in making it possible for users to be able to interact with bitcoin *only* over lightning
18:03 < az0re> Well, they still need to fund at least one channel, right?
18:04 < az0re> And presumably once LN-enabled merchants accrue lots of fully-spent channels, they'll get closed on them and they'll have to interact with the blockchain to spend their funds
18:05 < rubikputer> if you use channel factories, once those are a thing, then you and a clique of other nodes can cooperatively do a lot of work like that to cut down on the overhead
18:06 < az0re> But you still need a blockchain transaction to enter and to exit, right?
18:06 < az0re> Don't get me wrong, I totally see the value
18:06 < az0re> But it seems impossible for some users to avoid ever working with the blockchain
18:07 < rusty> My plan (well, niftynei's plan) is for dual-funding to decentralize the funding marketplace, but it's still a WIP.
18:08 <@niftynei> #someday
18:16 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined #c-lightning
18:34 -!- spinza [~spin@102.132.245.16] has joined #c-lightning
18:58 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
19:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection]
19:01 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
19:04 < rubikputer> az0re: it's totally possible for "average" users to "almost never" have to interact with the chain if counterparties don't screw up if the things that are in the works get adopted
19:05 < az0re> Understood
19:07 -!- rubikputer [~rubikpute@paphos.tr3y.io] has quit [Changing host]
19:07 -!- rubikputer [~rubikpute@unaffiliated/rubikputer] has joined #c-lightning
22:06 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
22:07 -!- sr_gi [~sr_gi@static-57-159-230-77.ipcom.comunitel.net] has joined #c-lightning
22:32 < rusty> openoms: good news: I have a pull request.  BAd news: the remote peer will time out after 2016 blocks, and it won't work after that...
22:32 < rusty> https://github.com/ElementsProject/lightning/pull/4421
22:32 < rusty> Other bad news: only lightly tested!
22:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
22:39 < openoms> @rusty thank you, will be building shortly
22:41 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-wunnawwznmddxkzr] has left #c-lightning []
22:41 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-wunnawwznmddxkzr] has joined #c-lightning
22:48 < openoms> @rusty are both peers need to run with the version in the PR to be able to use it?
--- Log closed Wed Mar 10 00:00:53 2021