--- Day changed Mon Jan 29 2018 00:38 < mlz> i opened a channel with someone on testnet a few hours ago, found out the tx was never broadcasted because the fee is only 178 satoshis, i just pushed the tx but not sure if it will be mined, how can i set the tx fee next time? 00:45 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 02:04 -!- mn3monic [~mn3@unaffiliated/mn3monic] has joined #c-lightning 02:10 -!- bloxton [76d047ed@gateway/web/freenode/ip.118.208.71.237] has joined #c-lightning 02:42 -!- ravanga [492a7dac@gateway/web/freenode/ip.73.42.125.172] has joined #c-lightning 02:42 < rusty> ravanga: try lightning-cli listpeers : what state is channel in? 02:43 < ravanga> Thanks rusty. State is in CHANNELD_NORMAL 02:43 < rusty> ravanga: Ah, is connected=true? 02:44 < ravanga> Yessir. "connected" : true 02:44 < rusty> Wow, that *is* weird! 02:45 < rusty> OK, can you dump listpeers and the getroute cmd and output? 02:47 < ravanga> Where do you want it? 03:32 -githubby:#c-lightning- [lightning] cdecker opened pull request #838: contrib: Updated bitcoind in CI builder image to 0.15.1 (master...bitcoind-bump) https://git.io/vNy1d 03:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 268 seconds] 04:12 -!- AmikoPay_CJP [~AmikoPay_@a83-163-77-195.adsl.xs4all.nl] has joined #c-lightning 04:14 < AmikoPay_CJP> Anyone willing to help debugging C-lightning issues? 04:19 < AmikoPay_CJP> At the very minimum, it should pass its own checks, right? 04:29 -githubby:#c-lightning- [lightning] cdecker pushed 1 new commit to master: https://git.io/vNy9T 04:29 -githubby:#c-lightning- lightning/master 0d9a749 Christian Decker: github: Added issue template 04:37 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Remote host closed the connection] 04:38 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 04:42 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Ping timeout: 264 seconds] 04:45 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-xavieucymdtpcvrr] has quit [Quit: Connection closed for inactivity] 05:02 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 05:08 -!- ebx [~ebx@12.226.6.52] has quit [Ping timeout: 240 seconds] 05:18 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Remote host closed the connection] 05:18 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 05:21 -!- DrOlmer [~DrOlmer@unaffiliated/drolmer] has quit [Quit: Leaving] 05:22 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Ping timeout: 240 seconds] 05:26 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 05:26 -!- askmike [9182fd85@gateway/web/freenode/ip.145.130.253.133] has joined #c-lightning 05:31 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Ping timeout: 252 seconds] 05:44 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 05:49 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Ping timeout: 268 seconds] 05:52 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 05:54 -!- Alex_ [~Alex@46.217.109.125] has quit [Quit: Leaving] 06:02 < askmike> hey, my c-lightning doesn't seem to connect to my bitcoin node (running on the same server, all default ports). 06:02 < askmike> lightningd crashes with the message `bitcoin-cli exited with code 1: error: couldn't connect to server: unknown (code -1) (make sure server is running and you are connecting to the correct RPC port)` 06:03 < askmike> wheras the RPC connection works for other applications and I am able to use `bitcoin-cli` without any problems 06:03 < fizzwont> make sure your btc node is fully syncd 06:03 < AmikoPay_CJP> When I run "make check", it runs into "TimeoutError: Unable to find "[re.compile('Done loading')]" in logs." 06:04 < AmikoPay_CJP> I can increase the time-out number, but then it runs into another time-out. When I increase that one, I get a different error. 06:04 < askmike> fizzwont fully synced at block 506654 06:06 < fizzwont> do you have server=1 in bitcoin.conf ? 06:06 < askmike> yep 06:07 < fizzwont> i'm out of ideas then :/ 06:07 < askmike> the rpc connection works for another application running on the same server 06:07 < askmike> cool, thanks anyway 06:07 < fizzwont> what is your command line to start up ln ? 06:09 < fizzwont> if you are trying to use mainnet make sure it has --network=bitcoin 06:10 < askmike> ahh will try that 06:10 < askmike> fizzwont genius that works, thanks. Didn't find this anywhere in the docs (tried "mainnet" before, didn't work) 06:11 < fizzwont> cool. yes they like to hide stuff about mainnet 06:12 < askmike> understandably 06:22 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Remote host closed the connection] 06:22 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 06:23 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Remote host closed the connection] 06:24 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 06:28 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Ping timeout: 248 seconds] 06:29 -!- ruby32 [~ruby32@158.106.219.26] has quit [Ping timeout: 256 seconds] 06:29 -!- ruby32 [~ruby32@158.106.219.26] has joined #c-lightning 06:37 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has joined #c-lightning 06:39 -!- litch [~litch@135.84.167.43] has joined #c-lightning 06:40 -!- litch [~litch@135.84.167.43] has quit [Remote host closed the connection] 06:40 -!- litch [~litch@135.84.167.43] has joined #c-lightning 06:45 -!- ruby32 [~ruby32@158.106.219.26] has quit [Remote host closed the connection] 06:47 -!- ruby32 [~ruby32@158.106.219.26] has joined #c-lightning 06:49 -!- ruby32_ [~ruby32@158.106.219.26] has joined #c-lightning 06:51 -!- ruby32__ [~ruby32@158.106.219.26] has joined #c-lightning 06:52 -!- ruby32 [~ruby32@158.106.219.26] has quit [Ping timeout: 268 seconds] 06:55 -!- askmike [9182fd85@gateway/web/freenode/ip.145.130.253.133] has quit [Quit: Page closed] 07:40 < AmikoPay_CJP> In tests/utils.py, the BitcoinD class has a start method but not a stop method. How is is supposed to be stopped? 07:41 < AmikoPay_CJP> I'm sometimes running into trouble when one (failed) test run leaves a bitcoind running, causing a different failure on the next test run: Bitcoind fails to set up a HTTP thing. 07:42 < AmikoPay_CJP> My guess is it has a (RPC?) port conflict with the bitcoind from the previous test run. 07:44 < AmikoPay_CJP> ... ah, I see tearDownBitcoind() in tests/test_lightningd.py. Maybe it should be refactored into a stop method? 07:47 < AmikoPay_CJP> ... and the base class TailableProc actually has a stop method. I wonder how it is different from tearDownBitcoind(). 07:48 -!- ruby32__ [~ruby32@158.106.219.26] has quit [Quit: Leaving] 07:48 -!- ruby32_ [~ruby32@158.106.219.26] has quit [Quit: Leaving] 07:48 -!- ruby32 [~ruby32@158.106.219.26] has joined #c-lightning 07:51 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #c-lightning 07:51 < AmikoPay_CJP> Ah, apparently TailableProc.stop() does a SIGTERM, while tearDownBitcoind() asks bitcoind to stop through the RPC. 07:52 < AmikoPay_CJP> .. and SIGKILLs it if it doesn't listen to the RPC command. 08:08 < nothingmuch> SIGKILL is the new eventual consistency 08:08 < nothingmuch> wait no, the old one... wait, is it in cycles? 08:09 < AmikoPay_CJP> What do you mean? 08:10 < nothingmuch> sorry just shitposting about how humanity is consistent (no pun intended) in its approaches for abstracting over irreducible complexity 08:10 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has quit [Ping timeout: 255 seconds] 08:11 < nothingmuch> there's no way an rpc stop action in a script can account for all the reasons why bitcoind might be taking indefinitely long to respond to that imperative, choosing an arbitrary timeout is a very crude way of predicting the likelyhood of that transpiring 08:12 < AmikoPay_CJP> True, and I've run into a "not enough killing" problem because of that, actually. 08:13 < AmikoPay_CJP> Apparently, bitcoind is slower on my computer than on the C-Lightning devs systems. 08:13 < AmikoPay_CJP> So the test code thinks (after a time-out) "It hasn't finished starting yet, so let's abort the test". It does so without killing bitcoind. 08:14 < AmikoPay_CJP> The next test run, bitcoind fails immediately because it bumps into the already-running bitcoind. 08:16 < AmikoPay_CJP> In my view, all software (including test scripts) should clean up its mess on termination, no matter what the circumstances are. This includes killing your own bitcoind instances. 08:16 < nothingmuch> is it even reasonable for regtest bitcoind to fail startup? 08:16 < nothingmuch> i'm not experienced enough to know, but intuitively I would guess a fully compartmentalized, new instance would likely succeed, so if I were writing such a harness I'd put in indefinite waits 08:17 < AmikoPay_CJP> In my case it was just too slow for the time-out. That is reasonable, since I don't think there is an explicit timing requirement on Bitcoind. 08:17 < AmikoPay_CJP> So yeah, the unreasonable part is the time-out. 08:17 < nothingmuch> yeah but delays in lieu of synchronization is always asking for trouble, it's essentially taking a race condition and making it arbitrarily unlikely for the original author 08:17 < nothingmuch> yep 08:18 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 256 seconds] 08:20 < AmikoPay_CJP> The log shows that it took 11..12 secs on my system, while the timeout was set to 10 s. So, quite likely that it does actually work on other systems. 08:22 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #c-lightning 08:22 < AmikoPay_CJP> But I guess the best fix in this particular case would be to remove the time-out completely, and just wait indefinitely until either BitcoinD start-up has finished, or it has died of natural causes. 08:27 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 260 seconds] 08:33 -!- ravanga [492a7dac@gateway/web/freenode/ip.73.42.125.172] has quit [Ping timeout: 260 seconds] 08:37 < nothingmuch> AmikoPay_CJP: looking at blamelog, I can't find a good reason for a timeout, and it's quite recent additions so i'm inclined to agree, but then again what do I know 08:37 < windsok> Im sure test improvements / refactoring PR's would be appreciated 08:51 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 08:58 -!- mn3monic [~mn3@unaffiliated/mn3monic] has quit [Remote host closed the connection] 09:02 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has joined #c-lightning 09:10 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-meihvxlillhpkdwn] has joined #c-lightning 09:36 < provoostenator> I'm getting "Could not find a route" between two of my own (mainnet) nodes, which have a channel and are "connected". 09:37 < provoostenator> I did notice the node appears twice under "listpeers" with one of them marked as disconnect and still showing "state": "OPENINGD". 09:50 < provoostenator> Mmm, I restarted one with an --ipaddr flag because it looked like it was broadcasting an IPv6 address instead of an IPv4 address. Now it's going through a few days worth of "Adding lobkc 5*****" 09:50 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has joined #c-lightning 10:00 < provoostenator> Mmm, I don't think that node was the problem. On my other node, I ended up manually reconnecting to every node that it has a channel with, by looking up the IP on recksplorer. Once I connect to the super-well-connected lnd.rompert.com a whole bunch of channel gossip started flooding in. 10:06 -!- tan90 [605261ee@gateway/web/freenode/ip.96.82.97.238] has joined #c-lightning 10:15 -!- tan90 [605261ee@gateway/web/freenode/ip.96.82.97.238] has quit [Ping timeout: 260 seconds] 10:16 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 10:25 -!- llou [~textual@85.152.158.239] has joined #c-lightning 10:36 < grubles> how many confirms does it take to close a channel? 10:38 < windsok> I think it depends on what type of close 10:40 < grubles> i just did: lightning-cli close id 10:40 < windsok> what is the state of the channel now, from listpeers 10:41 < grubles> "state" : "ONCHAIND_MUTUAL" 10:45 < windsok> that should close quickly, but I don't know the exact number of confirms 10:46 < windsok> if it's anything like opening, there is be something in the logs tracking the "depth" of the confirmations 10:46 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has quit [Read error: Connection reset by peer] 10:48 < grubles> yeah it's up to depth 9 now 10:48 < grubles> TRACE: FUNDING_TRANSACTION/FUNDING_OUTPUT->MUTUAL_CLOSE depth 9 10:55 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has joined #c-lightning 11:17 < grubles> up to 12 blocks now. hm. 11:26 -!- llou [~textual@85.152.158.239] has quit [Ping timeout: 240 seconds] 11:33 < windsok> and listfunds is not showing it? 11:54 < grubles> windsok, it does 11:55 < windsok> oh right, so yeah it is spendable again now 11:55 < windsok> you can withdraw, or open another channel with iut 11:55 < windsok> it* 11:55 < grubles> but what is curious is my previous channel shows up in listchannels 12:02 -!- litch_ [~litch@135.84.167.43] has joined #c-lightning 12:05 -!- litch [~litch@135.84.167.43] has quit [Ping timeout: 240 seconds] 12:09 -!- jb55 [~jb55@d108-172-210-7.bchsia.telus.net] has quit [Ping timeout: 240 seconds] 12:14 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #c-lightning 12:19 -!- litch__ [~litch@135.84.167.43] has joined #c-lightning 12:19 -!- litch_ [~litch@135.84.167.43] has quit [Read error: Connection reset by peer] 12:25 -!- redstorm [cb56cc58@gateway/web/freenode/ip.203.86.204.88] has joined #c-lightning 12:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 12:26 < redstorm> Startblocks works for me now, 4hops with one channel opened. pulled the latest code and all now works. Good work team keep it up. 12:36 -githubby:#c-lightning- [lightning] rustyrussell closed pull request #838: contrib: Updated bitcoind in CI builder image to 0.15.1 (master...bitcoind-bump) https://git.io/vNy1d 12:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 12:51 -!- jb55 [~jb55@2605:8d80:4c0:d820:a2af:bdff:fef0:c102] has joined #c-lightning 12:52 < grubles> ok my previous channel does not show up in listchannels now 12:54 < grubles> but if i try to open a channel again i get { "code" : -1, "message" : "Peer already ONCHAIND_MUTUAL" } 12:57 < provoostenator> "Could not connect to 03cb...fe1 after 10 seconds and 1346 attempts" (lnd.rompert.com) 13:02 < provoostenator> Mmm, I haven't seen this one before (trying to pay): "first peer not ready: WIRE_TEMPORARY_CHANNEL_FAILURE" 13:03 < provoostenator> (with the debug log going wild with lots of gossip) 13:05 < grubles> yes i've seen that recently as well 13:06 < provoostenator> grubles: any incantations that helped? 13:08 < provoostenator> If it doesn't behave by tomorrow morning I'll just try closing all channels, emptying out the wallet and reinstalling. 13:11 < grubles> provoostenator, not that i know of. 13:16 < provoostenator> Whenever I restart it also seems to do repeat a bunch of "Adding block 50*....", so I think my nodes are just completely borked. 13:16 < mlz> how can i set a tx fee when creating a tx to open a channel? 13:17 < provoostenator> Oh wait, "pay" worked! Windows style... 13:18 < provoostenator> mlz: use cli/lightning-cli dev-setfees 13:21 < mlz> ok let me try 13:24 -!- AmikoPay_CJP [~AmikoPay_@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Leaving] 13:32 -!- jb55 [~jb55@2605:8d80:4c0:d820:a2af:bdff:fef0:c102] has quit [Ping timeout: 246 seconds] 13:47 < rompert> provoostenator: hi, i'm just about to run out, but i saw you had some problems connecting to lnd.rompert.com . send private query if you still have problems and we can hopefully solve it later. 13:50 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 13:51 -!- litch__ [~litch@135.84.167.43] has quit [Ping timeout: 256 seconds] 14:02 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 14:04 < provoostenator> rompert: it's probably my node being in a messed up state. I'll try again from a blank slate some other time and will let you know if that causes difficulties. 14:06 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Ping timeout: 240 seconds] 14:08 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 14:14 -!- jb55 [~jb55@216-71-192-56.dyn.novuscom.net] has joined #c-lightning 14:29 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 14:43 < windsok> LOL, just noticed this in the makefile 14:43 < windsok> NAME=Bitcoin Savings & Trust Daily Interest II 14:43 < grubles> yeah me too 14:43 < grubles> :< 14:44 < windsok> I _knew_ lightning was a scam all along! 14:44 < grubles> lol 14:44 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 14:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 14:52 < provoostenator> TIL: unwinding channels is pretty tedious. Perhaps just when nodes are in a weird state. I had to resort to manually broadcasting the last commitment. In addition one channel with myself is now in the state ONCHAIND_CHEATED, not sure which side "cheated" 14:53 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 14:54 < mlz> I sent 1 tbtc to my wallet, the tx has confirmations but the coin isn't showing 14:54 < mlz> $ lightning-cli listfunds 14:54 < mlz> { "outputs" : 14:54 < mlz> [ ] } 14:55 < rusty> mlz: is lightningd caught up with the chain? lightning-cli getinfo shows the blockheight... 14:56 < provoostenator> Now there's a small UTXO on a regular bech32 address that neither of my nodes node seems to have access to. 14:56 < provoostenator> I also managed to extract 1.1 mBTC more than I initially sent to my lightning node wallets, despite buying a T-Shirt. 14:57 < rusty> provoostenator: cool! Um, manually broadcasting is interesting. The logs on the ONCHAIND_CHEATED side should be enlightening, look for messages from onchaind about what it's doing... 14:57 < rusty> provoostenator: that sounds very much like you broadcast an old transaction (perhaps the initial one?) 14:58 < rusty> provoostenator: the other side should be taking your money... 14:58 < provoostenator> I used dev-sign-last-tx and then broadcast that a while after "close" didn't seem to do anything. 15:00 < rusty> provoostenator: erk, dev-fail would have been better. But if you're closing, it should have the same effect. 15:00 < provoostenator> As in, after calling close the state changed to "CHANNELD_SHUTTING_DOWN" but there was nothing in the mempool spending the funding UTXO's. 15:01 < rusty> provoostenator: OK, there are several possibilities. But basically, shutting_down does nothing if we're not connected. 15:01 < rusty> (it's trying to negotiate with the peer, which requires connection) 15:01 < provoostenator> Yeah and the whole reason I was unwinding the channels was that my nodes were in a totally confused state 15:02 < provoostenator> They would connect, but not find routes to transactions, not even to eachother. 15:03 < rusty> provoostenator: hmm,what's your node id? 15:03 < rusty> (Can pm if you prefer) 15:05 < mlz> rusty, yes "blocks": 1261165, 15:06 < rusty> mlz: OK, it's something subtler then. Do you have the address and the txid? 15:08 < mlz> TXID: 5126265c5e7f81285f27b978e8cc219f3da619c9d6fa663cd7698f99fa4983d2 ADDRESS: 2Mscf53imPZjTbVhufGU3WxZyw11Dw8ERfi 15:09 < mlz> rusty, when we take an address from lightningd wallet and make a tx, the log doesn't say anything 15:14 < mlz> hm.. or maybe if i run it with --log-level=trace i can see more details? 15:15 -!- jb55 [~jb55@216-71-192-56.dyn.novuscom.net] has quit [Ping timeout: 260 seconds] 15:19 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning 15:21 -!- tan90 [605261ee@gateway/web/freenode/ip.96.82.97.238] has joined #c-lightning 15:22 < rusty> mlz debug is enough... 15:22 < rusty> mlz: it needs to see the tx in a block. 15:23 < mlz> yea just found out it doesn't have "trace" :P 15:23 < mlz> rusty the coin is missing 15:23 < mlz> im going to restart lightningd to see if it will show up 15:25 < mlz> ah hah 15:25 < mlz> $ lightning-cli listfunds 15:25 < mlz> { "outputs" : 15:25 < mlz> [ 15:25 < mlz> { "txid" : "5126265c5e7f81285f27b978e8cc219f3da619c9d6fa663cd7698f99fa4983d2", "output" : 1, "value" : 100000000 } ] } 15:26 < ianthius> rusty: glad to see you back post-yourTalk 15:26 < rusty> ianthius: thanks! yeah, bad timing with this at the same time as that... 15:26 < ianthius> my node is jacked up and not synced to block height. hoping to fix it soon 15:26 < rusty> mlz: weird, how did it miss it the first time? 15:26 < rusty> ianthius: chewing CPU? 15:26 < mlz> rusty, why can't we have some communication in the log about the tx? 15:27 < ianthius> i haven't noticed that 15:27 < rusty> mlz: we do, see "owning output" 15:27 < mlz> rusty, i have no clue how it missed the first time, maybe because of my internet disconnection now and then? 15:27 < ianthius> rusty: i've had it down for days and all my outputs are disappering. lol. I filed a bug, but cdecker's fix didn't help me 15:27 < ianthius> can't work on it now, but i 15:28 < ianthius> i'll check in later today after some meetings 15:28 < ianthius> i might have to spin up a non-pruned node to try it out, but someone else posted on my github issue saying even on a non-pruned node that it wasn't working.. 15:28 < mlz> rusty, hm.. "owning output" only shows up after i restarted the node 15:29 < rusty> mlz: that's weird... it's added to the filter before it shows it to you, so you can't possibly have sneaked the tx in before it saw it. 15:33 < rusty> mlz: have you opened an issue? If not, please do... I'll point cdecker at it. 15:36 < mlz> rusty, hm i think there's some disconnection between lightningd and bitcoind, my tx was mined in block 1261162 but the last block the log recored before i restarted the node was block 1261160 15:37 < rusty> mlz: Ah! 15:37 < rusty> mlz: You've joined ianthius in the "not kept up with bitcoind" club, it seems. If you have debug logs from when it was stuck, I'd love them... 15:39 * rusty finds some old commits he forgot to push... 15:40 < mlz> where can i find the log besides what's on my terminal screen? 15:47 < rusty> mlz:L when it's running you can do getlog, but otherwise I recommend --log-file= (or redirect). 15:47 < rompert> so..... i have a bunch of peers in "OPENINGD" state... many to the same id... i can close them to get rid of them, but when i restart clightning those bastards are back... is that a known issue? 15:48 < rompert> hello everybody btw 15:51 < tan90> do u guys have any good article to explain the incentives of hosting a LN node? how much fee should set, how many channels should open, etc 15:53 < mlz> rusty, i'm going to give you the log in pm, sec 15:54 < jojeyh> tan90, that is a much broader problem that can be addressed with game theory 15:54 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #c-lightning 15:54 < rusty> rompert: yes... we should never be putting them in the db in the first place. You can shutdown your node and blow them away if you want meanwhile... 15:56 < rompert> rusty: thanks... how hard should i blow and with what? i'd like to keep those that are working 15:59 -!- redstorm [cb56cc58@gateway/web/freenode/ip.203.86.204.88] has quit [Quit: Page closed] 16:00 < rusty> rompert: OK, shut down, then do 'sqlite3 ~/.lightningd/lightningd.sqlite3' then 'DELETE FROM channels WHERE state = 1;' 16:00 < rusty> ie. lightning-cli stop first! 16:07 < rompert> roger that 16:17 < rompert> rusty: thanks that got rid of those. i have a few other in annoying states. i can find number from the peer_state enum and remove those too i guess. a bunch of CHANNELD_AWAITING_LOCKIN and one interesting ONCHAIND_CHEATED should be ok to remove as well. i wonder who cheated on me though.... 16:18 < rompert> HOPPINGMAESTRO around by any chance ? 16:19 < rusty> rompert: OK, so awaiting_lockin can be valid, the cheated one should have onchaind collecting funds for you though... what does listpeers give for that one? 16:28 < rompert> { "id" : "03bd3466efd4a7306b539e2314e69efc6b1eaee29734fcedd78cf81b1dde9fedf8", "connected" : false, "channels" : [ { "state" : "ONCHAIND_CHEATED", "short_channel_id" : 16:28 < rompert> "503914:676:0", "funding_txid" : "9404cceaa8ec5a59342c8d3f14c8263c97d060421c1039e8258ab6fd78b6aed1", "msatoshi_to_us" : 98787999, "msatoshi_total" : 100000000, "dust_limit_satoshis" : 546, "max_htlc_value_in_flight_msat" : 18446744073709551615, "channel_reserve_satoshis" : 0, "htlc_minimum_msat" : 0, "to_self_delay" : 144, "max_accepted_htlcs" : 483 } ] }, 16:28 < rompert> rusty: ^ 16:30 < rusty> rompert: OK, there's no "owner" field there, so onchaind isn't running for some reason. The reason why should be in the logs... 16:30 < rusty> rompert: let's try "lightning-cli getlog debug | grep onchaind"... might be big though. 16:32 < rompert> rusty: grep didn't find a single row... even tried grep -i 16:32 < rusty> rompert: cool! 16:32 < rompert> yeah totally awesome! 16:33 -!- tan90 [605261ee@gateway/web/freenode/ip.96.82.97.238] has quit [Ping timeout: 260 seconds] 16:33 < litch> Is there a way to see what transactions you've routed / what fees you've collected? I've noticed some money going back and forth in my channels, but would like to see what info I keep 16:33 < rompert> rusty: i got a few lines if i greped after the id though 16:33 < rusty> rompert: heh... I mean, it's a useful clue :) 16:33 < rusty> rompert: cool, what are they? 16:34 < rompert> https://www.irccloud.com/pastebin/zXQ9ADDj/ 16:34 < rusty> Huh, that's people gossiping about you :) 16:34 < windsok> I've got one channel in CLOSINGD_SIGEXCHANGE state for many days. I am guessing that is a transient state, that it's only meant to be in for a very short time, so something must have gone wrong during the closing operation? 16:35 < rompert> i wish ppl stopped gossiping about me. don't believe a word they say 16:35 < rusty> windsok: yeah... you can dev-fail the peer if you want to force it. There are some sigexchange issues. 16:35 < windsok> i'll try that, thanks rusty 16:35 < rusty> windsok: or just wait for me to fix them :) 16:36 < windsok> well in this case, all the funds are on the other side, so whoover that person is might appreciate their satoshis back :) 16:36 < windsok> will dev-fail force a tx to be broadcast? 16:37 < rusty> windsok: should do... 16:38 < rusty> rompert: OK, I would have expected you to have a "Funding transaction spent" msg. Can you send me complete logs? Email to rusty@rustcorp.com.au works... 16:39 < windsok> dev-fail does not seem to do anything in this case. don't worry about it, it can wait for sigexchange fixes 16:40 < rompert> rusty: sure... if it helps you in any way and isn't too big problem. i can probably just delete it :) 16:40 < windsok> the other side is disconnected, if that makes a different for dev-fail 16:41 < rusty> windsok: no, dev-fail permenantly fails them, broadcasts last tx. 16:42 < windsok> ahh, I can see in the logs it tries to broadcast the TX 16:42 < windsok> then gets 16:42 < windsok> lightningd(30692): sendrawtx exit 26, gave error code: -26 16:42 < windsok> error message: 16:42 < windsok> 16: bad-txns-vout-empty 16:44 < windsok> this is the TX: https://gist.github.com/windsok/5c10286e2589b41d83284d8146023b38 16:47 < windsok> it might be due to all the satoshis being on the other side of the channel? 16:49 < windsok> as in, someone opened this channel to me, no lightning payments were ever sent, then they tried to close it and something went wrong and got stuck in SIGEXCHANGE 16:51 -!- ebx [~ebx@unaffiliated/ebex] has quit [] 16:53 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 16:54 -githubby:#c-lightning- [lightning] rustyrussell opened pull request #841: Better handling unexpected msgs (master...better-handling-unexpected-msgs) https://git.io/vN9G4 16:55 < rusty> windsok: ah! So, this is a weird corner case. Fees were so high it trimmed both outputs. 16:56 < rusty> windsok: which is kinda OK, I guess, except that bitcoind considers zero outputs nonstandard. 16:57 < rusty> windsok: https://github.com/ElementsProject/lightning/issues/632 16:58 < windsok> ah! thanks 16:58 < windsok> I'll see if I can get anywhere using --override-fee-rates 16:58 < windsok> and add my example the the issue 16:59 < rusty> windsok: no, because the only spend you have is that one they sent you. Bug is in the past... 16:59 < windsok> ohhh I see 16:59 < windsok> it's the TX that was signed before 17:01 < rusty> ianthius: found the "stopped tracking blocks" bug. mlz provided the clue, with logs... 17:05 -!- ebx [~ebx@unaffiliated/ebex] has joined #c-lightning 17:05 < windsok> yay for finding bugs :D 17:10 -githubby:#c-lightning- [lightning] rustyrussell opened pull request #842: bitcoind: mark request no longer running, even if it fails. (master...fix-bitcoind-comms-stop) https://git.io/vN9ZE 17:18 -!- lugg_ [uid274294@gateway/web/irccloud.com/x-lwfypvsdkwxjphva] has quit [Quit: Connection closed for inactivity] 17:24 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has quit [Ping timeout: 256 seconds] 17:30 -!- mn3monic [~xxwa@unaffiliated/mn3monic] has joined #c-lightning 17:56 -!- grafcaps [325a53e5@gateway/web/freenode/ip.50.90.83.229] has joined #c-lightning 18:04 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has joined #c-lightning 19:06 -!- tan90 [4c66fa14@gateway/web/freenode/ip.76.102.250.20] has joined #c-lightning 19:08 < tweaks> how do you re-open a channel with a peer you've previously closed out? you can't fund them, you can't remove from peer list to connect again with a fresh state. i guess you'd need to generate a newaddr... 19:11 < rusty> tweaks: open issue... you currently have to wait for them to forget about you, at least 100 blocks. 19:12 < tweaks> rusty: "open an issue" or "it's an open issue" 19:12 < grubles> i ran into that today 19:13 < grubles> closed a channel with SLEEPYARK, tried again, and was hit with "funding tx already spent" or something similar. 19:13 < grubles> tried again <- as in tried to open a channel again 19:14 < tweaks> yep, happen to me with a couple peers 19:14 -!- beeteecee [~beeteecee@S010608bd43d0655d.vc.shawcable.net] has joined #c-lightning 19:15 < tweaks> rusty: i was asking if you were saying to open an issue on github, or just that it's an open issue 19:21 < rusty> tweaks: sorry, I was unclear. No, it's an open issue :) 19:26 < grafcaps> what's the appropriate method for communicating with a c-lightning node programatically on a remote server? 19:27 < grafcaps> more specifically, I've got a c-lightning node at my office. I can ssh in and run commands directly with lightning-cli, but I've written a litte desktop app that lists lightning payments and I'd like to wire it up to my node 19:28 < grafcaps> with bitcoind I would just use RPC over HTTP 19:28 < rusty> grafcaps: Hmm, I've not tried it, but ssh can forward Unix domain sockets.... 19:29 < rusty> grafcaps: then use --rpc-file to point to the ssh'd one. 19:29 < rusty> (Please tell me if this works! :) 19:29 < grafcaps> will do! 19:57 -!- beeteecee [~beeteecee@S010608bd43d0655d.vc.shawcable.net] has quit [Ping timeout: 256 seconds] 20:11 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Remote host closed the connection] 20:19 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 20:26 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Remote host closed the connection] 20:29 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection] 20:29 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has joined #c-lightning 20:34 -!- litch [~litch@cpe-72-182-55-95.austin.res.rr.com] has quit [Ping timeout: 260 seconds] 21:04 -!- beeteece_ [beeteecee@gateway/vpn/mullvad/x-apnwopxdgdrrgwue] has joined #c-lightning 21:29 < ianthius> rusty: I went ahead and made the change from your commit. However, it didn't solve my problem with my current .lighting directory. 21:29 < ianthius> rusty: perhaps it's because of the pruned node? 21:30 < rusty> ianthius: hmm, maybe, but is it not catching up with the current block height? OR is this a different problem? 21:31 < ianthius> yes, it's behind the current block height. that has been the problem for a while 21:31 < ianthius> also it was at one point slowly moving backwards :) 21:32 < ianthius> it is however above my pruneheight 21:34 < mlz> what does this mean? $ lightning-cli dev-setfees 21:34 < mlz> { "immediate" : 254, "normal" : 254, "slow" : 254 } 21:41 < windsok> "Set feerate in satoshi-per-kw for {immediate}, {normal} and {slow} (each is optional, when set, separate by spaces) and show the value of those three feerates" 21:41 < windsok> I am assuming it's for on-chain fee rates, different modes you can set 21:41 < windsok> I think they map to bitcoind modes? 21:42 < windsok> I also could be totally wrong :) 21:49 < rusty> ianthius: hmm, can you send debug logs please? Maybe soemthing else is going on... 21:49 < ianthius> rusty: i can send, what way do you prefer I send? 21:50 < rusty> mlz: yes, those are the fee in satoshi/ksipa for immediate/normal/slow service. These are derived from estimatesmartfee with different settings. 21:50 < rusty> ianthius: rusty@rustcorp.com.au?> 21:50 < ianthius> k 21:56 < mlz> rusty, hm yesterday i had a testnet tx that would not confirm until i used blockcypher to push it because the fee was too low, 1 sat/byte, so im wondering why 21:56 < mlz> this was my tx yesterday: https://testnet.smartbit.com.au/tx/5d39eaaa2496d3e187265d26ba2edb56eaf19970d1f6702dc659f85e3ba8e2c4 21:57 < mlz> 254 sat/kw is quite high even for mainnet tx fees right now 21:58 < mlz> oh wait.. it's not 21:58 < mlz> i was thinking 254 sat/byte lol 21:59 < mlz> so how can we set the fees to avoid txs getting stuck in opening channels? 22:03 < rusty> mlz: Well, you can use dev-setfees, but it seems pretty nasty. 22:04 < mlz> rusty, how do you use dev-setfees? 22:05 < rusty> mlz: there have been proposals to allow RBF of opening tx. We could implement that simply by abandoning the channel and re-spending the opening tx, though our "no two live peers" rule would hit us there. 22:07 < rusty> mlz: dev-setfees immediate normal slow, each in satoshi/ksipa. we use "normal" for opening 22:15 < tan90> so "lightning-cli dev-setfees" is the fee for opening or closing channel? 22:19 < mlz> rusty, we can't set the fee something like "lightning-cli --dev-setfees=25400" ? 22:20 < rusty> mlz: no, but you can fire up lightningd with --override-feerates=a/b/c... 22:21 < rusty> tan90: internally we use three feerates. IMMEDIATE is designed toget into next block (ie. commitment txs). NORMAL is for normal spends. and SLOW is for the minimum we accept from the peer. 22:25 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 252 seconds] 22:26 < tan90> i have funded some channels, i didnt use the "lightning-cli dev-setfees", so which one is the default speed, immediate, normal or slow? 22:29 < mlz> lightningd --network=testnet --log-level=debug --override-feerates=50000/40000/30000 22:29 < mlz> lightningd: --override-feerates=50000/40000/30000: unrecognized option 22:29 < windsok> --override-fee-rates 22:31 < windsok> "Force a specific rates (immediate/normal/slow) in satoshis per kb regardless of estimated fees" 22:31 < windsok> should that be satoshis per kw (ksipa :) ) 22:31 < rusty> windsok: patch welcome :) 22:33 < windsok> I'll change to kw, not sure there is consensus on ksipa yet :) 22:33 < mlz> this works: lightningd --network=testnet --log-level=debug --override-fee-rates=50000/40000/30000 22:33 < mlz> thanks, windsok, rusty :D 22:38 < tan90> so whats the difference between "lightning-cli dev-setfees" and "lightningd --overide-fee-rates"? 22:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 22:41 < mlz> ok i just made an opening channel tx with that --overide-fee-rates command and the fee is 28 sat/byte: https://live.blockcypher.com/btc-testnet/tx/a717ad91913a013a1e5c38687987416fd8ca435976517c9bfa8620cb5d891f0e/ 22:55 -!- Matt__ [4408332b@gateway/web/freenode/ip.68.8.51.43] has joined #c-lightning 22:55 < Matt__> Anyone know how I can see confirmations after I fund a channel? 23:03 -githubby:#c-lightning- [lightning] windsok opened pull request #845: Fix references to kb/sat feerates (master...fix-docs) https://git.io/vN9Vb 23:09 -!- tan90 [4c66fa14@gateway/web/freenode/ip.76.102.250.20] has quit [Ping timeout: 260 seconds] 23:11 -!- tan90 [4c66fa14@gateway/web/freenode/ip.76.102.250.20] has joined #c-lightning 23:12 -!- simlay [~simlay@gateway/tor-sasl/simlay] has quit [Ping timeout: 255 seconds] 23:18 < p3tr> Matt__: you mean confirmations for the channel funding tx? you got a tx id when you funded the channel afaik so check that on a block explorer 23:18 < p3tr> iirc you can also see the channel funding tx in "listpeers" 23:19 -!- bryan_w [~is@2600:2108:9:8a90:5a69:d114:68b8:dae2] has quit [Ping timeout: 240 seconds] 23:21 < Matt__> ah good point p3tr 23:21 < Matt__> thank you 23:24 < p3tr> np :) 23:34 -!- tan90 [4c66fa14@gateway/web/freenode/ip.76.102.250.20] has quit [Ping timeout: 260 seconds] 23:43 -!- Matt__ [4408332b@gateway/web/freenode/ip.68.8.51.43] has quit [Quit: Page closed]