--- Log opened Wed Jan 12 00:00:28 2022 00:20 -!- TT2 [~TT2@2601:5cc:4402:4ce0:a908:a7bc:32aa:a851] has joined #c-lightning 01:33 < willcl_ark> julescomte: have you tried `make distclean; git submodule update --init --recursive` from the CL source directory and then running `./configure` and `make` again? 02:03 -!- kexkey [~kexkey@static-198-54-132-121.cust.tzulo.com] has quit [Ping timeout: 240 seconds] 02:05 -!- kexkey [~kexkey@static-198-54-132-89.cust.tzulo.com] has joined #c-lightning 02:49 < plant-boy[m]> I have some questions about backing up a c-lightning node and what the risks involved might be if it is not done. I have read https://lightning.readthedocs.io/BACKUP.html but everything seems a bit hacky and complicated (sorry). 02:53 < plant-boy[m]> Backing up the hsm_secret file seems easy enough, but as I understand it this only ensures on-chain funds. I was wondering, say my c-lightning sqlite database gets corrupted or lost, and I have just the hsm_secret file, will I then be able to receive funds once my channel partners close the channels they had with my node? 02:56 < plant-boy[m]> If so, it seems like backing up the hsm secret and setting up a watchtower would be enough to ensure funds (although, I am not sure if setting up a watchtower is easier than a backup database). 02:58 < cdecker[m]> Assuming the channel has been recently created (~last year) and the peer is also recently up to date it is likely to have `option_upfront_shutdown_script` which sets a close address for your side to an address directly derived from the seed, so yes you'd get part of your funds back. 02:59 < plant-boy[m]> Also, while the above link describes different strategies for backups, I don't exactly understand what the recovery process would be like, if my node were to be corrupted somehow. Would it just be to reconstruct the c-lightning database from the backup, and that's it? 03:00 < cdecker[m]> I say part because the peer may cheat and use a prior state where he owned more of the channel balance, and you are unable to retaliate (having lost your DB). This can be mitigated by watchtowers. 03:01 < cdecker[m]> Yep, backups can be used to restore the node's database, and then just start the node normally 03:11 < plant-boy[m]> Say I go for hsm_secret backup + watchtower solution, and my db is lost. Would there be system for me to request that my channel partners close the channels? 03:24 < mschmoock> cdecker[m]: whats the proper way to debug bad wire massages? 03:24 < mschmoock> I get something like this: 03:25 < mschmoock> **BROKEN** lightningd: Connectd gave bad CONNECT_PEER_CONNECTED message 03:25 < mschmoock> 07d20266e4598d1d3c415f572a8488830b60f7e744ed9235eb0b1ba93283b315c0351804017f000001901800000001000000000000000200000000000000023eaf87eb78dc2bc70dc4d075874a5998f3744f6ac4cb480aa1e81408ec9df60deddf778bb52486f08e0de952009382da850039d7f3dcb20aba691d86c42bc5e72c6139256c91459096f9843ba38a1efc79f281ff66bcd0c2e4f41d604fe0cb4c2c6139256c91459096f9843ba38a1efc79f281ff66bcd0c2e4f41d604fe0cb4c0000058808226aa2 03:25 < mschmoock> is there an easy way to spot the parsing error? 03:25 < cdecker[m]> Uff, that's hardish, how reproduciblwe is the error? If it is reproducible in a test the easiest way is to set a pdb breakpoint in the test, attach to the process that'll fail using gdb and then step through the code until youi hit the failure 03:26 < cdecker[m]> I'm afraid it isn't really easy to find the spot, since good/bad is returned as a binary outcome 03:31 < mschmoock> yeah, thats the wy I currently do it 03:33 < mschmoock> it happens not on master but in my remote_addr branch when I change from wireaddr_internal to just wireaddr when the data is passed back to lightningd 03:33 < mschmoock> (not yet commited, dont try on the github code) 03:35 < cdecker[m]> Oh, yeah those are compeltely different types, with completely different serialization, so no wonder it fails if only one side changed (presumably you're missing on part where it's still using the old one). The internal addr is a superset of the non-internal, so you're unlikely to want to change that anyway, if you extended the non-internal just also extend the internal one 04:21 < mschmoock> yes I know its a different type. Rusty wanted me to change to wireaddr (just for remote_addr) that is passed back 04:21 < mschmoock> I changed both side 04:22 < mschmoock> will debug it. its just so time consuming :D 04:22 < cdecker[m]> Hm, ok, strange. In that case I'd suggest attaching with `gdb` on both sides and step through 04:26 < mschmoock> nvm, 04:51 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 07:42 < julescomte[m]> "julescomte: have you tried `make..." <- I have tried it before, and just tried it again just now and still the same error. That being said the git submodule command is totally quiet - nothing to stdout should I expect something different? 08:21 < mschmoock> cdecker[m]: I fixed it. will cleanup my work and forcepush into the PR 08:22 < mschmoock> The trick was to use an optional pointer for remote_addr in connectd/connectd_wire.csv msgdata,connectd_peer_connected,remote_addr,?wireaddr 09:10 -!- jb55 [~jb55@user/jb55] has joined #c-lightning 09:48 -!- TT2 [~TT2@2601:5cc:4402:4ce0:a908:a7bc:32aa:a851] has quit [Quit: Client closed] 09:48 < julescomte[m]> "I have tried it before, and just..." <- little update: everytime I run `make`, I have a binary blob placed at like 287 in `external/x86_64-linux-gnu/libwally-core-build/src/secp256k1/libtool` 09:49 < julescomte[m]> s/like/line/ 09:49 < julescomte[m]> this i believe is causing the mismatch in \" characters 10:08 < cdecker[m]> Weird, that's in libwally, so an upstream dependency. Either we are configuring it wrong or there is some cornercase that isn't handled in libwally. 10:10 < julescomte[m]> right - ive been chatting with devrandom, who has a very similar setup as mine, and he can build c-lightning no problem, so far haven't been able to reproduce it on another machine 10:35 -!- Netsplit *.net <-> *.split quits: jonasschnelli_, face, plant-boy[m], RubenSomsen, vincenzopalazzo, berndj, belcher, roasbeef, BlueMatt[m], achow101, (+44 more, use /NETSPLIT to show all of them) 10:39 -!- DeanGuss- [~dean@nonplayercharacter.me] has joined #c-lightning 10:39 -!- Netsplit over, joins: pink_sarco 10:39 -!- mschmooc1 [~will@schmoock.net] has joined #c-lightning 10:39 -!- orionwl [~laanwj@user/laanwj] has joined #c-lightning 10:39 -!- sandipndev [sandipndev@2600:3c00::f03c:92ff:fe8e:dce6] has joined #c-lightning 10:39 -!- yakshaver123 [yakshaver@2600:3c00::f03c:92ff:fe8e:dce6] has joined #c-lightning 10:39 -!- Netsplit over, joins: RubenSomsen, sgiath, _aj_, michaelfolkson, kanzure, _0x0ff, ghost43, warren, achow101, darosior (+38 more) 10:40 < julescomte[m]> could you help me understand how you think this leads to a binary placed in the libtool file at the path above? that path to be clear is relative to the c-lightning root 10:40 < willcl_ark> is the blob also in `lightning/external/x86_64-linux-gnu/libwally-core-build/src/secp256k1/config.status`? 10:41 < julescomte[m]> yes 10:42 < julescomte[m]> not sure if it's the exact same, but at line 682 i encounter one 10:43 < julescomte[m]> im on the master branch, with latest commit `52b1f5a8` 10:44 < willcl_ark> how curious 10:44 < willcl_ark> sry I have to go now, hope you can work it out! 10:45 < julescomte[m]> no problem thanks for the help i'll be online for the next few days 10:57 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 240 seconds] 11:19 -!- sr_gi [~sr_gi@47.61.62.163] has joined #c-lightning 11:35 -!- Jackielove4u [uid43977@user/jackielove4u] has quit [Quit: Connection closed for inactivity] 12:39 -!- kexkey [~kexkey@static-198-54-132-89.cust.tzulo.com] has quit [Ping timeout: 240 seconds] 12:41 -!- kexkey [~kexkey@static-198-54-132-91.cust.tzulo.com] has joined #c-lightning 13:55 -!- DeanGuss- is now known as DeanGuss 13:55 -!- DeanGuss [~dean@nonplayercharacter.me] has quit [Changing host] 13:55 -!- DeanGuss [~dean@user/deanguss] has joined #c-lightning 14:23 -!- jb55 [~jb55@user/jb55] has joined #c-lightning 16:18 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 16:56 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 16:57 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 18:23 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 276 seconds] 18:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 18:59 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 276 seconds] 19:00 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 22:13 -!- jb55 [~jb55@user/jb55] has quit [Ping timeout: 256 seconds] 23:08 -!- jonatack [jonatack@user/jonatack] has quit [Ping timeout: 256 seconds] --- Log closed Thu Jan 13 00:00:29 2022