--- Log opened Thu Nov 12 00:00:14 2020
00:09 <@cdecker> ark56: if you run two instances against the same DB only one will get access to the DB and kill the other one, so I don't suggst running them concurrently, but they are safe, yes
00:12 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
00:45 -!- early [~early@static.38.6.217.95.clients.your-server.de] has quit [Quit: Leaving]
00:47 -!- early [~early@static.38.6.217.95.clients.your-server.de] has joined #c-lightning
01:06 -!- Spacerik [8fb1499f@159-73-177-143.ftth.glasoperator.nl] has joined #c-lightning
01:13 < Spacerik> Hi all, I need some help getting my LN node up-and-running again. I use lightningd (v0.9.1). My first issue is the alias name. I am running lightningd with the attribute --alias=Bitlinq.space but this name does not appear on the public record (https://1ml.com/node/024f7a4d154886c3d161c8e50f5a624e11a85d4cca2e810285ab52f3efba263009)
01:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 240 seconds]
01:25 < m-schmoock> cdecker: thx, will run your patch on my node... gimme some days for feedback
01:27 < Spacerik> The 2nd problem I had is that my node couldn't find a route. After some consultatio I found out it was not really about the routing but the fact that my spendable and receivable limits were set to 0. I understood this had to do with the rise of BTC on-chain transaction fees lately (and apparently they are down again). I felt a bit misguided about
01:27 < Spacerik> the routing message so I added an extra channel but that clearly didn't help. Instead, I should have upped the funds for my existing channel. 
01:28 < Spacerik> How could I prevent this situation in the future? Is the only option to put extra funds into my existing channels?
01:30 < m-schmoock> about 1  this is the explorer thats not yet up2date   see https://explorer.acinq.co/n/024f7a4d154886c3d161c8e50f5a624e11a85d4cca2e810285ab52f3efba263009 it shows an alias
01:31 < Spacerik> So my node works again but I don't really want it to be dependent on the BTC fee market. I also don't want to add any funds to it as I am paying small amounts (like 10-20 satoshis) per day. So a channel funded with 100.000 satoshis should be good enough from this perspective.
01:32 -!- Spacerik [8fb1499f@159-73-177-143.ftth.glasoperator.nl] has quit [Remote host closed the connection]
01:32 < m-schmoock> The spendable/receivable can be a problem, but if you opened the channel you should be able to spend it, because all the balance is on your side at the begining. if the other one opened it its vice versa, you have 100% receivable but nothing to spend (yet)
01:33 < m-schmoock> if you have 2 channels, one that you opened, one that was opened to you, the easies way would be to rebalance them 50/50 so you can send and receive on both
01:33 < m-schmoock> e.g. by using the rebalance plugin https://github.com/lightningd/plugins/tree/master/rebalance
01:34 -!- Spacerik [8fb1499f@159-73-177-143.ftth.glasoperator.nl] has joined #c-lightning
01:35 < Spacerik> Thanks. The alias shown here is JUNIORARTIST. When I started, I didn't use an alias so that was automatically picked. Then I restarted my node with the alias Bitlinq.space but that never appeared
01:36 < m-schmoock> it will appear after they updated their DB... which will take some time I guess
01:36 < m-schmoock> maybe tomorrow
01:36 < m-schmoock> but we cant know, as its their implementation that does this
01:36 < Spacerik> But this is already more than a month ago
01:37 < Spacerik> The strange thing is also, that my alias name on 1ml.com did get a change. It is now 024f7a4d154886c3d161c which is the first part of the node's public key
01:40 < m-schmoock> its really what this site implements. as long as your alias is shown elsewhere, its their implementation that does it
01:41 < m-schmoock> check this https://ln.bigsun.xyz/node/024f7a4d154886c3d161c8e50f5a624e11a85d4cca2e810285ab52f3efba263009
01:42 < m-schmoock> it shows you have one very tiny channel and one very big
01:42 < m-schmoock> ah mom
01:42 < m-schmoock> nope
01:42 < m-schmoock> they are both small :D
01:43 < m-schmoock> if you have an IP address for me I can connect to you and open one up to you
01:43 < Spacerik> Yes, but does that hamper my alias to be included?
01:43 < m-schmoock> hamper in what way?
01:43 < m-schmoock> privacy?
01:44 < Spacerik> I mean that I have 2 small channels. Does this affect that my alias is not updated?
01:44 < m-schmoock> nope
01:44 < m-schmoock> :D
01:44 < m-schmoock> theres nothing wring with your alais, just with 1ML not updating it...
01:45 < m-schmoock> your channels are very tiny :D thats a problem
01:45 < m-schmoock> you should load up some BTC make a decent channel, then I connect to you and do the same to you. I can rebalance them for you and your good to go
01:46 < Spacerik> The reason my channels are small is that they should be big enough from my spending perspective. I am paying 10-20 sats per day so two channels with 50.000 and 100.000 satoshis should be sufficient. I understand that I don't count the colleteral risk in a high fee market, in this argument.
01:47 < m-schmoock> the thing is theres (currently) still some reserve requirement (not shure about actualy size) but it margins your spendable/receivable amounts
01:48 < m-schmoock> and yes, thats what affects spendable/receivable
01:48 < m-schmoock> I recomment opening a bit bigger channels, even thoug you just want tini tiny amounts
01:48 < Spacerik> Actually, the node is working again (with my tiny channels). I didn't want to up the funds in the high BTC fee market. I think the error messaging of 'not being able to find a route is correct. THe real reason is that it was closed of because of too low funds in the channels.
01:49 < m-schmoock> I think this is incorrect. Your LN fees are (when the channels are already opened) decoupled from onchain fee market
01:49 < m-schmoock> (thats the reasin for LN in the first place)
01:50 < m-schmoock> if spendable_msat and receivable_msat shows too little or zero, your channels are drained or full and / or too small
01:50 < Spacerik> Ok.understood. But I was misguided in my head because of the routing error. My solution was to add another tiny channel.
01:51 < Spacerik> I should have upped my existing channel instead
01:51 < m-schmoock> what do you mean by upped ?
01:51 < Spacerik> add funds
01:51 < m-schmoock> anyway, if you want bigger inbound liquidity, I can help you with that
01:51 < zmnscpxj__> m-schmoock: the the ability to add an HTLC on a channel is affected by the onchain fee market, unfortunately
01:51 < m-schmoock> ahhh sure
01:52 < m-schmoock> yes
01:52 < m-schmoock> -.-
01:52 < zmnscpxj__> if the cost of adding an HTLC (onchain) is too high, the HTLC cannot be added to the channel and we will reach a "route not found"
01:52 < Spacerik> ok thanks! I will first need to get things working again with my python code
01:52 < zmnscpxj__> currently we cannot add funds to existing channels, or make additional channels to the same node
01:53 < Spacerik> oh really. Ok. So will have to add a third channel....
01:53 < m-schmoock> Spacerik: you will  be able to get onchain TX with less than 10sats. If you open bigger channels that would not hurt much
01:53 < zmnscpxj__> in view of devs of C-Lightning, we consider adding more channels to other points of the network "better" for general network health
01:53 < zmnscpxj__> and with MPP, the "splitting" should be a little better (once we implement path diversity in MPP, that is....)
01:53 < m-schmoock> because alls that fees, be it (temporary)  HTLC fees or reserve margings add up and lock up your channels
01:54 < zmnscpxj__> m-schmoock yes
01:54 < Spacerik> I also need to read up a bit more. Lots of lingo I don't get....
01:54 < zmnscpxj__> sorry
01:54 < zmnscpxj__> you can ask me directly if there is something you do not understand
01:55 < Spacerik> no blame here. Just trying to get up to speed with this complicated but beautiful beast....
01:56 < zmnscpxj__> yes, just offerring, as I may be able to explain better interactively rather than you having to go search through various articles etc.
01:58 < Spacerik> And another issue I have is the fact that my LN node runs on this old Linux computer. I first tried the LND implementation but couldn't get it to work in the end. But the nice thing was that I could create a wallet and have a back-up phrase. At least that gave me the impression that in case my old Linux computer would suddenly die, I could retrieve
01:58 < Spacerik> my funds again. With the lightningd implementation, I don't have such a back-up phrase. What do I do when my computer dies?
01:59 < Spacerik> I mean, this is the other reason for me having tiny channels
01:59 < zmnscpxj__> Note that Lightning requires continuous backups.  And when we say "continuous" as in "backups of a minute ago are potentially dangerous and you can lose funds"
02:00 < zmnscpxj__> the "big boy" solution is to set up `lightningd` on a PostgreSQL cluster, which cdecker is probably better at guiding
02:00 < zmnscpxj__> Alternately, you can look at the `backup` plugin, lemme finds its link
02:00 < m-schmoock> the "small boy" solution is to use the backup plugin (currently being updated)
02:00 < m-schmoock> :]
02:01 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
02:01 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
02:01 < zmnscpxj__> https://github.com/lightningd/plugins/tree/master/backup
02:01 < zmnscpxj__> set up something like an NFS mount, then point the backup plugin at that NFS mount
02:01 <@cdecker> Spacerik: notice that the backup phrase in lnd also only covers the on-chain funds, not the ones in channels
02:02 <@cdecker> We'd rather have a complete backup solution (replicated postgres DB, or the backup plugin) than offering multiple partial solutions that tend to confuse users
02:02 < zmnscpxj__> we also recently added the ability to use a backup phrase list with the same coverage, in `hsmtool` that is installed with recent `lightningd`, though I think that will appear in 0.9.2
02:02 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
02:03 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has joined #c-lightning
02:03 < Spacerik> So when my Linux computer dies today, the tiny funds in my channels are lost?
02:03 < zmnscpxj__> Yes.
02:04 < zmnscpxj__> Another thing you can do: partition off a 30Gb partition in your HDD, add a 32Gb USB flash disk, then BTRFS RAID-1 the 30Gb partition and the flash disk
02:04 < zmnscpxj__> and symlink the .lightning directory there
02:04 < zmnscpxj__> this is a local backup and thus totally worthless in case of fire or massive disaster, but for hardware failures, is better than nothing
02:05 < Spacerik> When this small boy becomes a big boy, I read all kinds of solutions I should implement... Thanks for the guidance.
02:05 <@cdecker> For the on-chain funds you can make an (encrypted) copy of the `hsm_secret` file in the lightning-dir, on-chain funds are difficult, and are covered by DB replication an backup plugins
02:05 < zmnscpxj__> s/on-chain funds are difficult/off-chain (in channel) funds are difficult/
02:06 <@cdecker> Spacerik: it can be daunting to get started, but you're on a good track to become a pro ^^
02:06 < zmnscpxj__> also, btrfs sucks, zfs is better, just the damn license problems....
02:07 < Spacerik> Is there an estimate for the minimum channel capacity (funds put in a channel from my side) to be independent of the on-chain BTC fee market? A 100.000 satoshis channel was not enough the last weeks, but works again.
02:08 < zmnscpxj__> 1000000sats is the minimum that clboss tries to use
02:08 < zmnscpxj__> (and is the minimum it can usefully manage, below that, it will just pester you to add more funds onchain)
02:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
02:09 <@cdecker> Hard to say, we need to carve out the potential on-chain fees from the channel just in case we need to react, and with the fees going crazy lately it's become hard to predict
02:09 < zmnscpxj__> yes
02:09 < zmnscpxj__> but if you only make one payment at a time, I believe 1,000,000 sats "should" be good enough
02:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
02:12 -!- vasild_ is now known as vasild
02:16 <@cdecker> Oh, yeah, I miscounted the 0s :-) 160USD is enough ^^
02:19 < Spacerik> ok thanks all for your usefull insights. Have to run. You can check my progress here: www.bitlinq.space if you are interested. 
02:19 <@cdecker> Will do ^^ Have a good one
02:22 < m-schmoock> cdecker: small issue, if we got a caus 'onchain' closure (e.g. while we have been offline) currently the "closer" will "null". This is in theory correct as there is 'just' a 99.999% chance this was caused by the remote side. In practice this may be a bit dump and we should sed "closer" to "remote" incase we discovered and onchain close that was not initiate by us, right?
02:23 < m-schmoock> - all the typos :D
02:23 < m-schmoock> if you want I fix that quickly for RC2
02:25 < m-schmoock> see this test that (currently) fails) https://github.com/m-schmoock/lightning/commit/d05453a0f7dc8202bdee8d2baacab3de38b7b10d
02:32 -!- Spacerik [8fb1499f@159-73-177-143.ftth.glasoperator.nl] has quit [Remote host closed the connection]
02:55 -!- yang_ is now known as yang
03:24 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
03:31 -!- jasan [~j@n.bublina.eu.org] has joined #c-lightning
03:34 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
03:34 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
04:02 -!- belcher_ is now known as belcher
04:21 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
04:24 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
04:50 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
04:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
06:28 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
06:51 -!- kexkey [~kexkey@static-198-54-132-137.cust.tzulo.com] has joined #c-lightning
07:27 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning
08:41 < m-schmoock> niftynei: cdecker: its not a big change, can we still have it for RC2 ?    https://github.com/ElementsProject/lightning/pull/4198
08:42 < m-schmoock> I will fix the remaining 'protocol' closure causes after 0.9.2
09:38 -!- jasan [~j@n.bublina.eu.org] has quit [Quit: Bye!]
09:47 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
09:47 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
10:19 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
10:19 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
10:42 -!- polydin [~george@136.49.254.169] has quit [Quit: Leaving]
10:51 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
11:11 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:11 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
11:42 <@niftynei> cdecker: can you explain the thread stack traces in the `test_plugin_command` failure? it seems to be flaking out in the same way fairly consistently
11:44 <@niftynei> gonna guess it's a 'killed by timeout' symptom
12:37 -!- polydin [aef6c255@85.sub-174-246-194.myvzw.com] has joined #c-lightning
12:58 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 256 seconds]
13:04 < polydin> hey y'all i'm going through BOLT3 specs and ran into `option_anchor_outputs` and can seem to find a good description anywhere.  it says to refer to BOLT3 in BOLT9 but can't seem to find an explanation, just references to it?
13:05 < polydin> cay anyone tell me the option changes?
13:06 < polydin> what* the option changes?
13:10 < polydin> never mind i found an article on anchor outputs, sorry!
13:10 < polydin> look pretty cool
13:33 -!- polydin [aef6c255@85.sub-174-246-194.myvzw.com] has quit [Remote host closed the connection]
14:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
14:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
14:12 -!- vasild_ is now known as vasild
14:33 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
14:34 -!- sr_gi [~sr_gi@static-120-201-229-77.ipcom.comunitel.net] has joined #c-lightning
15:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
15:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
15:21 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
15:26 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
15:57 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]
16:02 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #c-lightning
16:22 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:22 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
16:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:25 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
16:28 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Quit: Leaving]
16:29 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:30 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
16:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
16:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
16:40 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
16:41 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds]
16:49 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
17:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
17:18 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
17:18 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
17:19 < darosior> polydin: from the c-lightning point of view what in means in practice is: "you can get your coins out of data from the hsm_secret --without the database-- after an unilateral close from your peer"
17:19 < zmnscpxj__> does it?
17:20 < darosior> The to_remote i mean, "the big part"
17:21 < zmnscpxj__> peer can always route an HTLC to that channel and unilateral it under you with the `to_remote` near 0
17:21 < darosior> Yeah not always true but in practice.. Anyways they're gone
17:21 < darosior> Ooh i misread
17:21 < darosior> Sorry
17:21 < darosior> nevermind, i just confused with static_remotekey
17:21  * darosior goes to bed
17:21 < zmnscpxj__> haha yes
17:22 < zmnscpxj__> good night!
17:35 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
17:41 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection]
17:42 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #c-lightning
17:52 -!- kristapsk_ is now known as kristapsk
18:28 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
18:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
18:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
18:49 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
19:15 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
19:49 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
19:50 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
19:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
19:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
20:12 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
20:12 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
20:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:01 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning
21:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
21:46 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 240 seconds]
22:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
22:38 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
22:40 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
22:41 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
22:50 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
23:09 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
23:10 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #c-lightning
23:10 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
23:13 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 246 seconds]
23:20 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has joined #c-lightning
23:23 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 264 seconds]
23:24 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #c-lightning
23:27 -!- cltrbreak_MAD2 [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 256 seconds]
23:55 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
--- Log closed Fri Nov 13 00:00:15 2020