--- Log opened Thu Dec 05 00:00:28 2019 00:34 -!- Netsplit *.net <-> *.split quits: rotarydialer, tigermousr, adam3us, @niftynei 00:38 -!- Netsplit over, joins: rotarydialer, adam3us, tigermousr, @niftynei 00:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 00:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 01:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 01:54 -!- Netsplit *.net <-> *.split quits: jonatack, rotarydialer, tigermousr, adam3us, kabaum, @niftynei 01:55 -!- Netsplit *.net <-> *.split quits: afk11, GAit, nothingmuch, m-schmoock, RubenSomsen, berndj, belcher, RonNa, lowentropy, harding, (+49 more, use /NETSPLIT to show all of them) 02:04 -!- Netsplit over, joins: @niftynei, tigermousr, adam3us, rotarydialer, k3tan, m-schmoock, kabaum, RubenSomsen, darosior, kanzure (+44 more) 02:04 -!- Netsplit over, joins: belcher, orlovsky, jonasschnelli, nothingmuch, wallet42, cubancorona, @cdecker, Kostenko, blockstream_bot, raucao 02:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 02:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 02:46 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 02:52 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning 03:08 -!- orlovsky [~dr-orlovs@2a02:1205:500f:2e90:44e8:6142:feef:d44f] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 03:16 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 276 seconds] 03:25 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning 03:40 -!- lxer [~lx@ip5f5bd69b.dynamic.kabel-deutschland.de] has joined #c-lightning 03:43 <@cdecker> I resent the implication ;-) 04:22 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-nfufoseoysnzgsxq] has left #c-lightning [] 04:22 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-nfufoseoysnzgsxq] has joined #c-lightning 05:00 -!- ironbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning 05:03 < ironbutt> Hey, people. I got CHANNELD_AWAITING_LOCKIN after several iterations when playing with tx fee. It shows channel with capacity == output amount which leads me to conclusion that actual fee was 0. I suggest it created tx and it stuck in mempool and can't go forward through the network. Should I reboot my node and ask my counterparty to do what? Because when I got similar situations in Electum I must do full reboot of all 05:03 < ironbutt> related services in order to wipe transaction. 05:32 < ironbutt> "Cannot afford transaction with 1191sat sats of fees" does it mean it is too expensive or does it mean it is too cheap? 05:33 < ironbutt> Ah, ok. It means there is insufficient output value, probably 05:50 < darosior> ironbutt: what's your funding txid ? 05:52 < darosior> Ah it's lockin! What iterations are you talking about ? 05:53 < darosior> "It shows channel with capacity == output amount which leads me to conclusion that actual fee was 0. I suggest it created tx and it stuck in mempool and can't go forward through the network" ==> C-lightning would never create a transaction below the minrelayfee 05:58 < willcl_ark> cdecker: I wonder if you can see why my createonion RPC calls seem to be crashing c-lightning when I make them? https://bpaste.net/show/G2VCW 05:59 < willcl_ark> hmmm, does createonion do any check to ensure that this peer is not ourself, because my first hop is myself!... I wonder if that could be tripping it up 06:00 < willcl_ark> the onion tool was pretty agnostic about that though 06:03 <@cdecker> willcl_ark: yes, it assumes the first hop is actually our peer, I'll add a validation for it 06:04 < willcl_ark> oh no! 06:04 < willcl_ark> wait ok, so woudl it accept itself as the first hop? Or shoudl I revert to the onion tool my my use case 06:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 06:14 -!- jamaljsr [uid406503@gateway/web/irccloud.com/x-jrvmnuvgbvootuzp] has joined #c-lightning 06:19 < ironbutt> darosior: thanks, i fixed that 06:20 < ironbutt> darosior: yes, i also familiar with min fee floor. Apparently it has created transaction with 0 fee 06:20 < ironbutt> probably, i can show it 06:21 < ironbutt> here is my listfunds log https://pastebin.com/HnNPFJXH 06:23 < ironbutt> output was 4b3a6a37e68a3ae0036787bf68f71ecfe5b6e6320231a652068f8631958c07ca:0 06:24 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #c-lightning 06:24 < ironbutt> How I iterated through options https://pastebin.com/RR3fRVR2 06:26 < ironbutt> I may be confused sats and msats amounts since I used LND before and isn't comfortable with things like 100sat yet 06:50 <@cdecker> willcl_ark: createonion should be agnostic to the node_ids you pass in, sendonion is a bit more picky 06:50 <@cdecker> But conceptually the createonion call should contain the payload for your peer, not yourself 06:54 -!- trobjo [troels@bitcoinfundamentals.org] has joined #c-lightning 06:56 < trobjo> Hello. It seems like there isn't a way to negotiate a bilaterally funded channel in the cli interface. How do people usually open such channels? 06:56 < trobjo> I'd like to be able to receive payments as well :-) 07:17 < darosior> ironbutt: so https://blockstream.info/tx/41028bf53ab4bad2c5b24aa46fea600d96e36ec9d73ccc11b3d29d4cad9cb934 seems to be your funding tx ? It has more than ten confs now so your channel should be in "NORMAL" state ? 07:20 < darosior> Hi trobjo, it's not supported by the protocol for now but niftynei has been working hard on it and it should land in the spec in the (near?) future. Opening channels then making payments will rebalance these channels and allow you to receive payments. 07:20 < ironbutt> darosior: right, I canceled channel funding and re-approached whole process with 'normal' fee parameter adjusting channel capacity 07:25 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning 07:42 < jamaljsr> hi, im trying to use c-lightning in a regtest environment. I am trying to decrease the bitcoin poll timer, so I compile lightningd with DEVELOPER=1 and run it with --dev-bitcoind-poll=2. This works as expected but when I try to open a channel, I get a "Cannot estimate fee" error. I am able to open a channel with no error if I compile with DEVELOPER=0. 07:43 < jamaljsr> anyone know how I can prevent the fee error in developer mode? 07:46 < jamaljsr> I've narrowed down the source of the error to 'bitcoin-cli estimatesmartfee 6' but I can't seem to figure out why this lightningd behavior changes depending on the developer mode. I am using the same bitcoind node in both cases 08:04 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 265 seconds] 08:07 -!- jonatack [~jon@134.19.179.179] has joined #c-lightning 08:09 -!- ironbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 246 seconds] 08:17 < sword_smith> I would like some ingoing liquidity on 03ac388eaf01314c302d9469b1c291b95702276ad5d6c32ab40fc59677dff4329d@34.90.45.3:19735. Can anyone help? 08:33 < darosior> HI jamaljsr: most of the time you cannot estimate smart fees on regtest as there are not enough transactions made 08:33 < darosior> You need to use the feerate parameter of fundchannel 08:34 < darosior> jamaljsr: You can checkout https://github.com/darosior/regtest-manager/blob/f406e5e25cd1e057c0f14ee072fb47d6834e6221/regtest_manager#L72 for an example 08:35 -!- vincenzopalazzo [~vincenzop@2.226.158.237] has joined #c-lightning 08:36 -!- mdunnio [~mdunnio@38.126.31.226] has joined #c-lightning 08:39 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has joined #c-lightning 08:42 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 268 seconds] 08:42 -!- vincenzopalazzo [~vincenzop@2.226.158.237] has quit [Quit: Leaving] 08:44 < jamaljsr> darosior: doh! makes total sense to specify the fee so that it doesn't have to estimate. it works!! thank you 08:46 < jamaljsr> is 253perkw the minimum required for the txn? 08:59 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 08:59 < darosior> The infamous min relay fee, yes ;-) 09:19 -!- MrHash [~mrhash@host31-54-194-75.range31-54.btcentralplus.com] has joined #c-lightning 09:36 <@niftynei> cdecker, is there a 'blessed' list of sqlite3 commands that work well with your postgres translation engine? 09:37 <@niftynei> or is it more "write the sql, see what breaks" strategy 10:08 <@cdecker> Currently it's the latter :-) 10:19 <@cdecker> The biggest differences are however in the DDL (CREATE, ALTER statements) not in the query or update syntax 10:27 <@niftynei> ok gtk! 10:31 -!- Kostenko [~Kostenko@2001:8a0:729a:a200:441b:4a77:d26e:1e56] has quit [Read error: Connection reset by peer] 10:31 < MrHash> hey there. i'm trying to create a hodl invoice plugin, but not sure how to respond to the invoice_payment hook. If i return an empty object the payment is settled, but is there a way to respond with a failure code to detach the plugin and the sender connection will still accepting the payment for later cancelling or settling? 10:32 < MrHash> *while 11:41 -!- Kostenko [~Kostenko@2001:8a0:729a:a200:441b:4a77:d26e:1e56] has joined #c-lightning 12:08 -!- jonatack [~jon@134.19.179.179] has quit [Ping timeout: 240 seconds] 12:08 < willcl_ark> cdecker: thanks for the confirmation. Because I am receiving HTLC with no onion, I am making an onion with (myself + next_hop) to add onto the message, before passing it into C-Lightning (otherwise I assume it will complain/reject the message). Once C-Lightning outputs the message to (what it thinks is) the next hop, the onion is again stripped from the mesage before broadcast, and the process repeated. 12:20 <@cdecker> MrHash: are you using pyln-client (formerly known as pylightning)? In that case what you want is register the function as `@plugin.async_hook('invoice_payment')` and the function should have a `request` argument 12:21 <@cdecker> That `request` argument can be stashed somewhere and returning from the function will not send a result to `lightningd` 12:22 <@cdecker> You can then later pick up the `request` object again and call `request.set_result(YOUR_JSON_RESULT)` to actually return the result to `lightningd` and release the invoice 12:22 < MrHash> ok so when releasing the invoice is there a command to send it back to the sender? 12:22 <@cdecker> Careful though, don't hold on to the payment for too long, the liquidity along the entire path doesn't get freed until you do 12:23 < MrHash> right 12:23 < MrHash> i think i understand this has to be done within a single thread 12:23 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has joined #c-lightning 12:24 <@cdecker> I think in order to fail the payment you need to use the `htlc_accepted` hook instead, which gives you even more control 12:24 <@cdecker> It doesn't have to be single threaded, pyln synchronizes internally 12:24 < MrHash> ok i was using clightningjs at the moment 12:24 <@cdecker> As long as you can get a hold to the request you can return a result 12:25 <@cdecker> Oh, I'm not familiar with the internals of clightningjs, but I'd expect it to have comparable abstractions 12:27 <@cdecker> darosior might be able to help though ^^ 12:27 < darosior> ... Or that the maintainer will push it asap ^^ 12:27 < MrHash> ok thanks i'll cross reference and see what i can do. the intermediate state of the htlc remains unpaid right? 12:27 < darosior> async_* is a great feature of pyln, I'll integrate it to clightningjs 12:29 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-nfufoseoysnzgsxq] has left #c-lightning [] 12:29 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-nfufoseoysnzgsxq] has joined #c-lightning 12:30 -!- wpaulino [~wpaulino@unaffiliated/wpaulino] has joined #c-lightning 12:30 <@cdecker> Hehe, took me a while to realize just how to implement it without mandating multi-threading (the futures model won out in the end) 12:31 <@cdecker> MrHash: yes, the HTLCs remain unsettled (you could say "stuck") until the recipient settles 12:31 < wpaulino> does c-lightning ignore query_channel_range requests from genesis? 12:31 < MrHash> thanks 12:33 < darosior> wpaulino: No, iirc we cap the number of blocks 12:33 < darosior> Will check though 12:36 < wpaulino> was doing some manual interop between lnd & c-lightning, started a fresh lnd node and connected to a few c-lightning nodes and got nothing back 12:36 < wpaulino> nothing as in it responded with no channels 12:38 <@cdecker> wpaulino: how long were the nodes running? c-lightning doesn't respond immediatelybut queues responses to be flushed at the next gossip flush timeout 12:39 <@cdecker> Should be only 30-60 seconds though 12:40 < darosior> Ah I confused, we cap just in case of unreasonably large requests (more than we actually know of) https://github.com/ElementsProject/lightning/blob/a30ee2b7cd08053a2269712150204e9007976b04/gossipd/queries.c#L610 12:41 <@cdecker> Notice also that lnd seems to have some quirks around the channel range regarding the `complete` flag: https://github.com/ElementsProject/lightning/blob/edbcb6fa15c1929b72cfa89758d0f94d41d9f1ef/gossipd/queries.c#L724-L732 12:41 <@cdecker> That workaround is not yet in a release if I'm not mistaken 12:48 < darosior> Hmm looks like I'm just going to C/P pyln's `background` member ^^ 12:49 < MrHash> btw if anyone is interested i made an amqp relay plugin for spooling clightning notifications onto a durable queue 12:50 < darosior> MrHash: feel free to share it! You can also contribute it to https://github.com/lightningd/plugins/ (or contribute a link to it) 12:51 < MrHash> ok yeh i can fork your repo and add it in i guess 12:51 < willcl_ark> cdecker: Just an FYI as it won't matter to anyone else but me :) But something about rpc.createonion() is def checking (and killing) my clightning if the node is using _its own_ pubkey in the onion. The same code is working ok with Onion Tool but not with rpc.createonion(). 12:52 < darosior> willcl_ark: could you share the backtrace ? 13:01 < willcl_ark> darosior: sorry my plugin is currently swallowing exceptions, and not sure how to get a C-lightning backtrace :( is it easy? 13:02 < darosior> debug.log ? But maybe I misunderstood, is it crashing your lightningd ? 13:09 < willcl_ark> darosior: something like this seems to kill it (lightnignd): https://bpaste.net/show/NKC5W 13:13 < wpaulino> cdecker: thanks it's related to that issue indeed 13:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 13:27 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds] 13:27 <@cdecker> Great, thanks wpaulino, so it should work once we release the next version (next week btw) 14:16 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 14:32 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning 14:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 14:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 15:07 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning 15:44 < MrHash> ok i got the hold invoice plugin basically working. the problem is that any observer doesn't know what the current state of the invoice is so i'll try to integrate my amqp relay into this and emit a custom 'invoice_held' event 15:47 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has quit [Read error: Connection reset by peer] 15:48 -!- orlovsky [~dr-orlovs@194.230.155.171] has joined #c-lightning 15:55 < MrHash> looks like i'll need to be able to create an invoice without a preimage first tho, not sure if that's possible 15:55 < darosior> MrHash: That's basically how I was implemented async hooks (you can return a not-yet-resolved Promise, which you can resolve with for example an event)...... 15:55 < darosior> ......... when I soptted a bad json in my tests 15:55 < darosior> On the db_write hook (investigating) 15:56 < darosior> I think you cant, in what would be useful an invoice without preimage? 15:57 < MrHash> darosior: i impl'd this prototype with pylightning but i think it would be easier for me in node. anyway i have to work out if it's possible to create an invoice with a payment_hash and not a preimage.. 15:57 < darosior> MrHash: you can pass the preimage yourself 15:58 < darosior> However since the payment_hash is the hash of the preimage... 15:58 < MrHash> that's how hold invoices work in prinicple - the invoice issuer is not supposed to know the preimage 15:58 < darosior> Ah then you need to send an HTLC without an invoice 15:58 < MrHash> i mean, that's one of the use cases 16:01 < darosior> I think you want sendonion https://lightning.readthedocs.io/lightning-sendonion.7.html 16:02 < MrHash> yeh i think this is something that probably needs to be supported in the core, otherwise it's non standard behaviour 16:03 < MrHash> issue holdinvoice with payment_hash and null preimage, then don't settle on invoice_payment if preimage is null, then settle when preimage received 16:05 < MrHash> the current impl is ok if you just want to verify something on issuer side before settling, but the other workflow supports more sophisticated use cases 16:06 < MrHash> obviously with some risks 16:11 -!- lxer [~lx@ip5f5bd69b.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds] 16:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 16:30 -!- orlovsky [~dr-orlovs@194.230.155.171] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 16:31 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has joined #c-lightning 16:38 < fiatjaf> have anyone experimented with https://syncthing.net/ for backing up lightningd.sqlite3? 16:38 < fiatjaf> it seems to work pretty well 16:51 < fiatjaf> MrHash, I've had success creating an invoice without a preimage that triggers the 'htlc_accepted' hook with this: https://github.com/fiatjaf/lightningd-gjson-rpc/blob/4e73275bc05342e674bf4519cfdc1ddaa26aa01f/cmd/notifierbot/helpers.go#L65-L177 17:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 18:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 18:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 19:00 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 19:52 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 19:52 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning 19:56 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 20:38 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-nfufoseoysnzgsxq] has left #c-lightning [] 20:38 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-nfufoseoysnzgsxq] has joined #c-lightning 21:41 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] --- Log closed Fri Dec 06 00:00:29 2019