--- Day changed Tue Feb 27 2018 00:00 -!- Mark__ [5bd4cf04@gateway/web/freenode/ip.91.212.207.4] has quit [Ping timeout: 260 seconds] 00:03 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has joined #c-lightning 00:18 -!- Mark__ [5bd4cf04@gateway/web/freenode/ip.91.212.207.4] has joined #c-lightning 00:43 < hkjn0> hey, I'm seeing c-lightning periodically "forget" blocks; logs report "Adding block N" for last ~5000 blocks, during which time lightning-cli getinfo's reported blockheight also drops 00:44 < hkjn0> this can be seen here, might be expected but I'd like to understand why: https://ln.hkjn.me/graph?g0.range_input=12h&g0.expr=lightningd_blockheight&g0.tab=0 00:44 < hkjn0> ah, might be related to when the node was stopped? does it lose some state on restart that it rescans historical blocks for? 00:45 < lxer> it rescans some afaik 00:58 < lxer> Do you know when it happens? 01:01 < hkjn0> I only started paying attention (i.e. exposing metric so I can graph it) yesterday, but on second look it does seem to be on restart, seeing it back up ~5k blocks each time 01:14 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has joined #c-lightning 01:18 < lxer> I cant see the graph. but if you have any examples, pls add it to https://github.com/ElementsProject/lightning/issues 01:21 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has quit [Ping timeout: 245 seconds] 02:01 < rompert> hkjn0: it rescans from the block of the oldest channel when you restart the daemon. thus if you close your oldest channels it will be faster. work is in progress to make this work better. which i hope will happen soon because i have some ancient channels that i'd like to keep for nostalgic reasons. 02:01 < bitonic-cjp> The new "test_bitcoin_failure" test fails for me. It even fails when I go back to the commit that added it, so it doesn't seem to be a regression in later commits. 02:04 < bitonic-cjp> And yes, I tried a complete clean-up and rebuild, and it still fails. 02:06 < bitonic-cjp> I find it hard to believe Rusty would commit&push a test that doesn't work for him, so I guess it must be some difference between our systems. 02:12 < bitonic-cjp> The last line in the log of the test says lightningd(26341): FATAL SIGNAL 6 RECEIVED 02:16 < lxer> is that the dev-crash function? 02:16 -!- icota [~igor@cm-2230.cable.globalnet.hr] has joined #c-lightning 02:16 -!- shesek [~shesek@bzq-84-110-60-168.cablep.bezeqint.net] has joined #c-lightning 02:16 -!- shesek [~shesek@bzq-84-110-60-168.cablep.bezeqint.net] has quit [Changing host] 02:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 02:17 < bitonic-cjp> Hmm, the test searches for getblockhash, but the log contains getblock... 02:31 < bitonic-cjp> Signal 6 = SIGABRT. Someone pressed the red button? 02:39 < lxer> is that the dev-crash function? 02:41 < bitonic-cjp> It seems that bcli_failure() in bitcoind.c calls the fatal() function. 02:43 < bitonic-cjp> ..and fatal() in log.c calls abort(). Gotcha. 02:43 < lxer> "dev-crash", "description" : "Crash lightningd by calling fatal()" 02:43 < bitonic-cjp> Yes, but I think nothing in this test is calling dev-crash. 02:44 -!- almkglor_ [9258463b@gateway/web/freenode/ip.146.88.70.59] has quit [Ping timeout: 260 seconds] 02:48 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection] 02:49 < bitonic-cjp> I'm just going to change getblockhash to getblock in this test (so it will probably pass) and see what else breaks. 02:55 < bitonic-cjp> Well, test_bitcoin_failure succeeds now, so far so good. 03:01 < lxer> Is it not possible to fund a channel from both sides atm? 03:05 < bitonic-cjp> What you can do now is fund it from one side, and ask the other side to perform a Lightning payment over it. If you want, you can compensate the other side with a regular BTC tx. 03:06 < bitonic-cjp> AFAIK, trustless two-sided funding is not yet possible. I think C-Lightning doesn't even support multiple channels to a single peer yet. 03:09 < lxer> well, it doesn work... 03:09 < bitonic-cjp> What doesn't work? 03:09 < lxer> A (funded) can pay to B, but B can not pay A 03:10 < lxer> I can not fund a channel from the side of B, 03:10 < lxer> and even after A paid B a few times, B can still not pay A 03:10 < lxer> "Could not find a route" , even though there is a direct connection 03:10 < bitonic-cjp> Oh, sorry, I meant the other way around. 03:11 < lxer> I mean, payments can only go 1 way, as far as I see 03:11 < bitonic-cjp> So, the funding party (of course) initially owns all the funds in the channel. So *that* party has to transfer some of the funds to the peer to balance the channel. 03:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 03:12 < bitonic-cjp> So, do a Lightning payment from *funder* to the other side, and maybe compensate the funder for that with a regular BTC tx. 03:14 < lxer> no, that is not the point. I should be able to make LN payment back 03:15 < bitonic-cjp> So far, I have experienced two issues with C-Lightning: 03:16 < bitonic-cjp> 1: it doesn't recognize its own channel as a possible route, even though it is fully established and connected. 03:17 < bitonic-cjp> I don't know what causes this, but the issue sometimes disappears. Maybe waiting until it is synced with the block chain (see log file) helps? 03:18 < bitonic-cjp> 2: if you only have a small balance on one side of a channel, it refuses txes in the other direction, even though the small amount should be enough. 03:19 < bitonic-cjp> I think this issue has to do with having to fund the on-chain tx fee; I don't know. I don't fully understand it either, since the RFC says the on-chain fee is paid by the funder. 03:20 < bitonic-cjp> Anyway, if you're just testing between two of your own nodes, you could just try first balancing the channel a bit more, and then re-try a tx in the opposite direction. 03:20 < lxer> about 1: I think you need to check the blockheight (getinfo) ; after a crash it starts checking from 0, and that does not show in the logs when loglevel is not 'debug' and takes hours to finish 03:23 < lxer> No, the opposite direction does not work. I always get a 'route not found' error. 03:25 < bitonic-cjp> If you really(!) have plenty of funds, then maybe one peer knows a route to the other, but not the other way around? 03:26 < Bunnyh> that was my error too every time I tried to return the 25k satoshi I was sent 03:26 < Bunnyh> it's still sitting in the channel 03:27 < Bunnyh> I tried to close it, but the sender is offline 03:27 < Bunnyh> (wasn't offline when I tried returning) 03:39 < lxer> bitonic-cjp: i'm on testnet, so I have enough funds. I have two peers: Home(1000000) and Remote(0) , there is a direct channel between them. I can pay Home->Remote , but not Remote->Home and I can not fund the channel from the Remote side. 03:40 < bitonic-cjp> Of course you can't pay Remote->Home yet: Remote has no funds. 03:41 < bitonic-cjp> BTW the rest of the test suite succeeded. 03:42 < bitonic-cjp> But if you first make a large payment Home->Remote (e.g. half the channel capacity), can you then make a small payment in the opposite direction? 03:42 < lxer> right, so I created some invoices on Remote, and Home paid them. After that Home creates an invoice, but somehow Remote can not pay it (even though it has funds now) 03:42 < bitonic-cjp> How much funds? 03:43 < lxer> enough 03:45 < lxer> is there a minimum? 03:45 < bitonic-cjp> Yes, but I don't know the exact minimum 03:46 < lxer> I tried 100 10000 100000 ... 03:47 < bitonic-cjp> On my node, 100 000 satoshi (100 000 000 mSatoshi) turned out to be sufficient. 03:47 < bitonic-cjp> Maybe much less is OK too, but I don't know. 03:50 < lxer> ok.. I give up :/ 03:55 -githubby:#c-lightning- [lightning] bitonic-cjp opened pull request #1116: test_lightningd.py: lightningd currently calls getblock, not getblockhash. (master...patch0) https://git.io/vA69A 03:57 -githubby:#c-lightning- [lightning] cdecker opened pull request #1117: WIP: Track output confirmations, spends and maintain an internal UTXO set (master...trackblocks) https://git.io/vA6Ha 04:13 -!- almkglor [b4be2eb3@gateway/web/freenode/ip.180.190.46.179] has joined #c-lightning 04:25 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning 04:33 -githubby:#c-lightning- [lightning] cdecker closed pull request #1106: Update INSTALL.md with Android instructions (master...patch-1) https://git.io/vAotq 04:34 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 04:38 -17WAAUR9J:#c-lightning- [lightning] cdecker pushed 3 new commits to master: https://git.io/vA6dA 04:38 -17WAAUR9J:#c-lightning- lightning/master 6c9d81e ZmnSCPxj: payalgo: Remove reporting PAY_TRY_ANOTHER_ROUTE and PAY_UNPARSEABLE_ONION.... 04:38 -17WAAUR9J:#c-lightning- lightning/master 21cfec8 ZmnSCPxj: payalgo: Report number of tries on failure. 04:38 -17WAAUR9J:#c-lightning- lightning/master 73cda2f ZmnSCPxj: payalgo: Report route, and result of trying route. 04:38 -18WAAJXJR:#c-lightning- [lightning] cdecker closed pull request #1100: payalgo: Improve telemetry (master...payalgo-telemetry) https://git.io/vArgq 04:59 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #c-lightning 05:29 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 05:58 -githubby:#c-lightning- [lightning] bitonic-cjp opened pull request #1118: json-rpc: translate NULL into "null" instead of "(null)". (master...patch1) https://git.io/vAiJ0 06:07 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Ping timeout: 255 seconds] 06:08 -!- simlay [~simlay@gateway/tor-sasl/simlay] has joined #c-lightning 06:21 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-kfelopzwthnrworp] has quit [Quit: Connection closed for inactivity] 06:37 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Ping timeout: 255 seconds] 06:42 -!- simlay [~simlay@gateway/tor-sasl/simlay] has joined #c-lightning 07:07 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has joined #c-lightning 07:37 -!- grafcaps [~haroldbr@50.90.83.229] has quit [Ping timeout: 245 seconds] 07:50 -!- ruby32 [~ruby32@158.106.219.26] has joined #c-lightning 07:54 -!- bitonic-cjp [~bitonic-c@92-111-70-106.cable.dynamic.v4.ziggo.nl] has quit [Quit: Leaving] 08:27 -githubby:#c-lightning- [lightning] icota opened pull request #1120: Store invoice bolt11 in case an RPC client needs it later (master...store-invoice-bolt11) https://git.io/vAiuk 08:47 -githubby:#c-lightning- [lightning] practicalswift opened pull request #1121: Adjust log level for logging disconnected RPC users ("Abandoning command" + "Command returned result after jcon close") (master...adjust-log-level-for-disconnected-json-consumers) https://git.io/vAi2B 08:52 -githubby:#c-lightning- [lightning] icota opened pull request #1122: Add specific external libs to the makefile clean recipe (master...fix-external-make-clean) https://git.io/vAi2b 09:01 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Ping timeout: 260 seconds] 09:07 -!- grafcaps [~ben@104.137.194.255] has joined #c-lightning 09:19 -!- hop3y [1000@valtio.org] has quit [Quit: leaving] 09:29 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has quit [Ping timeout: 276 seconds] 09:39 < mlz> what does this mean: ""max_htlc_value_in_flight_msat": 18446744073709552000," ? (testnet) 09:49 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 09:52 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 10:08 -!- mdrollette [~mdrollett@feynman.drollette.com] has joined #c-lightning 10:51 -githubby:#c-lightning- [lightning] jsarenik opened pull request #1125: Fix libtool error (master...jasan/test_fixes) https://git.io/vAiQY 10:52 < lxer> mlz: 64-bit unsigned integer. However, should it not be 18446744073709551615 ? 10:53 < mlz> what is it? i'm wondering why it's such a long number and what is it for :D 10:55 < lxer> I don't know what it is for :) I guess they just wanted the highest possible value for now. 11:05 -githubby:#c-lightning- [lightning] jsarenik opened pull request #1127: test_lightningd.py: Enable bech32 test for DEVELOPER (master...jasan/bech32_test) https://git.io/vAi5I 11:11 -!- Mark__ [5bd4cf04@gateway/web/freenode/ip.91.212.207.4] has quit [Ping timeout: 260 seconds] 11:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 11:37 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 11:41 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 11:47 -!- icota [~igor@cm-2230.cable.globalnet.hr] has joined #c-lightning 11:51 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 248 seconds] 11:53 -githubby:#c-lightning- [lightning] rustyrussell opened pull request #1128: test_lightningd.py: repair flaky test_bitcoin_failure (master...bitcoin_failure-test-fix) https://git.io/vAix6 11:55 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Remote host closed the connection] 11:56 -!- icota [~igor@cm-2230.cable.globalnet.hr] has joined #c-lightning 11:56 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 12:11 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds] 12:13 -!- jb55 [~jb55@216-71-192-56.dyn.novuscom.net] has joined #c-lightning 12:14 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Ping timeout: 252 seconds] 12:25 -githubby:#c-lightning- [lightning] rustyrussell opened pull request #1129: Minor gossip cleanups (master...minor-gossip-cleanups) https://git.io/vAPep 12:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 12:30 -!- jb55 [~jb55@216-71-192-56.dyn.novuscom.net] has quit [Ping timeout: 260 seconds] 13:37 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-rsxvrohytyresqbp] has joined #c-lightning 14:28 -!- icota [~igor@cm-2230.cable.globalnet.hr] has joined #c-lightning 15:08 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 15:14 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has quit [Read error: Connection reset by peer] 15:22 < almkglor> @mlz it's the maximum amount total, in millisatoshi, of all offered HTLCs on the channel. As lxer says, it's the highest possible value for now 15:22 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning 15:23 < mlz> almkglor, what's "all offered HTLCs on the channel"? sorry i'm still clueless about "HTLCs" 15:24 < almkglor> payments are first offered as HTLC, that's a hashlocked timelocked contract 15:24 < almkglor> in a single-hop payment, you offer some money in exchange for a preimage (the proof-of-payment) 15:25 < almkglor> that's the hashlock (it only gets released to the payee if the payee can provide the preimage) 15:25 < almkglor> there's a timeout involved (we don't want our money locked indefinitely if the payee disappears) 15:25 < almkglor> that's the timelock 15:25 < almkglor> hence, hashlocked timelocked contract (HTLC) 15:25 < almkglor> when a payment is initiated, you first offer an HTLC spending some of your funds 15:26 < almkglor> the payee can accept the offer in exchange for giving you the preimage, which solidifies the transfer of your funds, and converts the HTLC amount to the payee's funds 15:27 < almkglor> the payee can reject the offer and fail the HTLC early (before the timeout), which solidifies the HTLC back to your funds 15:27 < almkglor> or the HTLC can timeout, in which case you wait for the payee to reject, or if the payee attempts to accept after the timeout you drop it onchain and claim it using the timelock 15:28 < almkglor> in effect, the HTLC funds are in a "liquid" state that transfers between you and the other side 15:28 < almkglor> the max thingy thingy limits how much of the channel funds are in that liquid transferable state 15:29 < almkglor> DISCLAIMER: Lightning Network is not affiliated with Blockstream Liquid 15:29 < almkglor> LOL 15:30 < almkglor> it is a security parameter, since theft attempts can only punish using the "solidified" funds that are definitely yours or definitely the other side's 15:31 < almkglor> HTLC funds are judged using the HTLC contract terms 15:31 < mlz> ok so, the max of fund for each channel is 18446744073709552000 msat? 15:31 < mlz> that's a lot isn't it? 15:31 < almkglor> no, the max that can be converted to HTLC, i.e. "all of it" 15:32 < almkglor> think of the large number as an approximation of infinity 15:32 < almkglor> channels can only have 16777215000 msat 15:33 < mlz> right 15:33 < almkglor> the max htlc-in-flight of that ridiculously large value is just an approximation of infinity i.e. "all of the funds could be in HTLCs" 15:33 < almkglor> (note that this is not quite accurate as there is still the channel reserve to think of) 15:34 -!- icota [~igor@cm-2230.cable.globalnet.hr] has quit [Ping timeout: 252 seconds] 15:34 < almkglor> them guys should probably reduce it LOL but I think they've got a bunch of crashes they want to fix first 15:35 < mlz> oh this this the max of htlc-in-flight between all channels that come in contact via routing at any given time? 15:35 < almkglor> it's a per-channel parameter, not all channels 15:35 < almkglor> it kinda limits routes though 15:35 < aj> mlz: that's 184 million bitcoin, so yeah, it's a lot... 15:35 < mlz> aj, yup this is still confusing me :D 15:36 < almkglor> the maximum you can transfer is limited by the max htlc-in-flight along the channel, minus other htlcs on the channel 15:36 < almkglor> and so on 15:43 -!- almkglor [b4be2eb3@gateway/web/freenode/ip.180.190.46.179] has quit [Ping timeout: 260 seconds] 16:10 -!- grafcaps [~ben@104.137.194.255] has quit [Quit: Lost terminal] 16:23 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Ping timeout: 248 seconds] 16:35 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning 17:51 -githubby:#c-lightning- [lightning] rustyrussell closed pull request #1122: Add specific external libs to the makefile clean recipe (master...fix-external-make-clean) https://git.io/vAi2b 17:51 -githubby:#c-lightning- [lightning] rustyrussell pushed 1 new commit to master: https://git.io/vAPVM 17:51 -githubby:#c-lightning- lightning/master c7718aa Rusty Russell: test_lightningd.py: repair flaky test_bitcoin_failure... 17:53 -githubby:#c-lightning- [lightning] rustyrussell pushed 1 new commit to master: https://git.io/vAPV7 17:53 -githubby:#c-lightning- lightning/master 54b8562 Jan Sarenik: Fix libtool error... 17:54 -githubby:#c-lightning- [lightning] rustyrussell closed pull request #1121: Adjust log level for logging disconnected RPC users ("Abandoning command" + "Command returned result after jcon close") (master...adjust-log-level-for-disconnected-json-consumers) https://git.io/vAi2B 17:59 -!- almkglor [9258463b@gateway/web/freenode/ip.146.88.70.59] has joined #c-lightning 18:10 -!- jojeyh [~delphi@2602:306:b8b6:b970:95bb:4f0c:32d5:60d] has joined #c-lightning 18:10 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has joined #c-lightning 18:22 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has quit [Remote host closed the connection] 19:43 -!- windsok [~windsok@unaffiliated/windsok] has quit [Remote host closed the connection] 19:43 -!- windsok [~windsok@rarepepe.cash] has joined #c-lightning 19:43 -!- windsok [~windsok@rarepepe.cash] has quit [Changing host] 19:43 -!- windsok [~windsok@unaffiliated/windsok] has joined #c-lightning 19:53 -!- almkglor [9258463b@gateway/web/freenode/ip.146.88.70.59] has quit [Ping timeout: 260 seconds] 21:20 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 21:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds] 21:35 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 21:53 -!- almkglor [9258463b@gateway/web/freenode/ip.146.88.70.59] has joined #c-lightning 22:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 22:41 -!- justan0theruser is now known as justanotheruser 22:47 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has quit [Ping timeout: 245 seconds] 22:48 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has joined #c-lightning 23:20 -!- Mark__ [5bd4cf04@gateway/web/freenode/ip.91.212.207.4] has joined #c-lightning 23:37 -!- CubicEarths [~cubiceart@50-0-95-188.dsl.dynamic.fusionbroadband.com] has joined #c-lightning