--- Log opened Thu Dec 27 00:00:04 2018 00:39 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 250 seconds] 00:41 -!- ott0disk [~smuxi@134.28.68.51.rdns.lunanode.com] has joined #c-lightning 01:26 -!- ott0disk [~smuxi@134.28.68.51.rdns.lunanode.com] has quit [Ping timeout: 250 seconds] 01:47 -!- ott0disk [~smuxi@134.28.68.51.rdns.lunanode.com] has joined #c-lightning 02:42 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 03:04 < ott0disk> Hi all! I've been digging into the issue with sorting HTLC outputs https://github.com/lightningnetwork/lightning-rfc/pull/491 , I have a fix for eclair and wanted to manual test it with c-lightning. I tried playing with regtest but the c-lightning RPC (rightfully) prevents me from creating 2 invoices with the same preimage so i guess it's almost impossible to manual test it that way. However it seems that the issue was successfully 03:04 < ott0disk> reproduced and i would like to have some test vectors if possible :) 03:06 < ott0disk> Also what about putting the test vectors in the BOLTs? This kind of issues are quite hard to test within 1 implementation (if the sorting is wrong but deterministic your 'toRemote' will still be able to validate the incoming commit_sig) 03:07 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 03:25 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 03:38 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 03:47 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning 04:02 -!- ott0disk [~smuxi@134.28.68.51.rdns.lunanode.com] has quit [Remote host closed the connection] 04:04 -!- farmerwampum [~farmerwam@104.129.28.202] has quit [Quit: farmerwampum] 04:04 -!- farmerwampum [~farmerwam@104.129.28.202] has joined #c-lightning 04:08 -!- farmerwampum [~farmerwam@104.129.28.202] has quit [Client Quit] 04:09 -!- farmerwampum [~farmerwam@104.129.28.202] has joined #c-lightning 04:15 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 04:15 -!- farmerwampum [~farmerwam@104.129.28.202] has quit [Ping timeout: 250 seconds] 05:11 -!- ott0disk [~smuxi@134.28.68.51.rdns.lunanode.com] has joined #c-lightning 06:34 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 06:38 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Client Quit] 06:39 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 07:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds] 07:02 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning 07:09 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Quit: farmerwampum] 07:09 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 07:11 < blockstream_bot> [Christian Decker, Blockstream] The usual trick here is to have two separate endpoints that share a partial route, e.g., have a-b-c and a-b-d, then the a-b channel would end up with the duplicate secret 07:11 < blockstream_bot> [Christian Decker, Blockstream] Alternatively you can route in a cycle, e.g., a-b-a-b, this can easily be done by manually creating a route and then using the sendpay command 07:13 < blockstream_bot> [Christian Decker, Blockstream] The latter option is also way less timing sensitive since it requires both HTLCs to be active at the same time, while in the former the first htlc may have been settled before the second one is added. 07:13 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Client Quit] 07:14 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 07:48 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 07:48 -!- booyah_ [~bb@193.25.1.157] has joined #c-lightning 07:49 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Quit: farmerwampum] 07:49 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 07:53 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Client Quit] 07:54 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 07:58 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 07:59 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 246 seconds] 08:21 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds] 08:22 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 08:24 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Quit: farmerwampum] 08:26 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 08:28 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Client Quit] 08:29 -!- farmerwampum [~farmerwam@184.75.215.178] has joined #c-lightning 08:31 -!- ott0disk [~smuxi@134.28.68.51.rdns.lunanode.com] has quit [Remote host closed the connection] 08:37 -!- farmerwampum [~farmerwam@184.75.215.178] has quit [Quit: farmerwampum] 08:39 -!- farmerwampum [~farmerwam@cpe-107-9-138-59.neo.res.rr.com] has joined #c-lightning 09:00 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 268 seconds] 09:45 -!- farmerwampum_ [~farmerwam@162.219.178.98] has joined #c-lightning 09:47 -!- farmerwampum [~farmerwam@cpe-107-9-138-59.neo.res.rr.com] has quit [Ping timeout: 244 seconds] 09:47 -!- farmerwampum_ is now known as farmerwampum 10:19 -!- farmerwampum [~farmerwam@162.219.178.98] has quit [Quit: farmerwampum] 10:19 -!- farmerwampum [~farmerwam@162.219.178.98] has joined #c-lightning 10:24 -!- farmerwampum [~farmerwam@162.219.178.98] has quit [Client Quit] 10:24 -!- farmerwampum [~farmerwam@162.219.178.98] has joined #c-lightning 10:59 -!- farmerwampum [~farmerwam@162.219.178.98] has quit [Quit: farmerwampum] 10:59 -!- farmerwampum [~farmerwam@162.219.178.98] has joined #c-lightning 11:04 -!- farmerwampum [~farmerwam@162.219.178.98] has quit [Client Quit] 11:04 -!- farmerwampum [~farmerwam@162.219.178.98] has joined #c-lightning 11:08 -!- booyah_ is now known as booyah 11:10 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 11:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.2] 11:26 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 11:44 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 12:30 -!- cubancorona [cubancoron@gateway/vpn/privateinternetaccess/cubancorona] has joined #c-lightning 13:18 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 14:10 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 14:34 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 14:36 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 246 seconds] 14:46 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 18:18 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 240 seconds] 18:35 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 18:39 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 18:51 -!- spinza [~spin@155.93.246.187] has joined #c-lightning 20:09 -!- warren [~warren@fedora/wombat/warren] has joined #c-lightning 20:10 -!- deusexbeer [~deusexbee@093-092-180-106-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!] 20:11 < warren> I'm sure this question has already been asked prior, but had anyone considered an option for Core pruned mode that waits to prune only after an RPC command says it no longer needs some height anymore? That way a pruned bitcoind could be a little safer with c-lightning where it won't discard the older blocks until lightningd said it is OK? 20:21 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds] 20:25 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #c-lightning 20:27 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds] 20:36 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 20:45 < gwillen> warren: hmmmmm, the kind of interface for this that feels familiar to me is "pinning", perhaps RPC calls to pin and unpin blocks, and only unpinned blocks can be pruned? 20:45 < gwillen> I guess you still need a flag or some way to say that new blocks start pinned 20:51 < warren> gwillen: is such granularity more useful than "it's OK to prune prior to this height"? 21:09 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 250 seconds] 21:13 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has joined #c-lightning 21:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 21:34 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 21:37 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-muhzynlsjblcoded] has left #c-lightning [] 21:37 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-muhzynlsjblcoded] has joined #c-lightning 21:40 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #c-lightning 21:43 < gwillen> warren: mmmm, probably not 21:44 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Ping timeout: 268 seconds] 21:53 -!- grubles [~grubles@unaffiliated/grubles] has joined #c-lightning 22:09 < warren> gwillen: any idea of an appropriate name for this RPC? 22:11 < warren> Maybe a bitcoin.conf option like "prunebefore=" and RPC of the same name? If prunebefore is enabled it won't prune anything unless the conf or RPC told it to do so. It also will respect the prune= as minimum recent blocks to keep. 22:14 < gwillen> hmmm, I'm not sure --- Log closed Fri Dec 28 00:00:05 2018