--- Day changed Wed Jul 26 2017 00:10 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Read error: Connection reset by peer] 00:11 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #lightning-dev 00:27 -!- hukkinj1 [hukkinj1@gateway/shell/tkk.fi/x-eerqnwtwzudaljcm] has quit [Ping timeout: 255 seconds] 00:34 -!- hukkinj1 [hukkinj1@gateway/shell/tkk.fi/x-fkioioyfwvkxtgwk] has joined #lightning-dev 00:43 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has quit [Ping timeout: 246 seconds] 01:02 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has joined #lightning-dev 02:22 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-xleptcrytlxbyoxz] has quit [Ping timeout: 276 seconds] 02:23 -!- Guest75836 [~socrates1@li175-104.members.linode.com] has quit [Ping timeout: 240 seconds] 02:26 -!- amiller [~socrates1@li175-104.members.linode.com] has joined #lightning-dev 02:26 -!- amiller is now known as Guest71980 03:02 -!- aj_ is now known as aj 03:34 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has quit [Ping timeout: 246 seconds] 03:41 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has joined #lightning-dev 03:59 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Quit: Quitte] 04:11 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-eheggqfguhohzmsj] has joined #lightning-dev 04:24 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has quit [Ping timeout: 255 seconds] 04:29 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wzjstymtsyoqkyrp] has joined #lightning-dev 04:32 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has joined #lightning-dev 04:37 -!- akrmn [~akrmn@62.red-83-56-226.dynamicip.rima-tde.net] has joined #lightning-dev 05:03 -!- moctos_ [~moctos@cpe-107-9-138-59.neo.res.rr.com] has quit [Ping timeout: 255 seconds] 05:03 -!- moctos_ [~moctos@cpe-107-9-138-59.neo.res.rr.com] has joined #lightning-dev 05:10 -!- moctos_ [~moctos@cpe-107-9-138-59.neo.res.rr.com] has quit [Ping timeout: 248 seconds] 05:23 -!- moctos_ [~moctos@cpe-107-9-138-59.neo.res.rr.com] has joined #lightning-dev 05:29 -!- moctos_ [~moctos@cpe-107-9-138-59.neo.res.rr.com] has quit [Ping timeout: 248 seconds] 05:38 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 248 seconds] 05:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 06:07 -!- windsok [~windsok@45.63.59.8] has joined #lightning-dev 06:11 -!- marcoagner [~user@187.113.157.206] has quit [Ping timeout: 255 seconds] 06:24 -!- marcoagner [~user@187.113.148.71] has joined #lightning-dev 06:55 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has quit [Ping timeout: 240 seconds] 07:17 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has joined #lightning-dev 07:41 -!- JackH [~laptop@host86-187-170-222.range86-187.btcentralplus.com] has quit [Ping timeout: 255 seconds] 07:50 -!- Deadlyelder [~Thunderbi@ip-213-135-240-50.static.luxdsl.pt.lu] has quit [Ping timeout: 248 seconds] 07:56 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has joined #lightning-dev 08:00 -!- Deadlyelder [~Thunderbi@ip-213-135-240-50.static.luxdsl.pt.lu] has joined #lightning-dev 08:01 -!- moctos_ [~moctos@cpe-107-9-138-59.neo.res.rr.com] has joined #lightning-dev 08:03 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has quit [Ping timeout: 260 seconds] 08:09 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has joined #lightning-dev 08:14 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has quit [Ping timeout: 248 seconds] 08:29 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #lightning-dev 08:42 -!- Deadlyelder [~Thunderbi@ip-213-135-240-50.static.luxdsl.pt.lu] has quit [Quit: Deadlyelder] 09:19 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has joined #lightning-dev 10:08 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #lightning-dev 10:09 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit] 10:31 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has joined #lightning-dev 10:33 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 10:37 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has quit [Ping timeout: 255 seconds] 10:40 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 10:40 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has joined #lightning-dev 10:46 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has quit [Ping timeout: 260 seconds] 10:52 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 10:59 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has joined #lightning-dev 11:04 -!- JackH [~laptop@host-80-43-142-175.as13285.net] has quit [Ping timeout: 240 seconds] 11:04 -!- JackH [~laptop@host-80-43-140-108.as13285.net] has joined #lightning-dev 11:08 -!- JackH_ [~laptop@host-80-43-140-111.as13285.net] has joined #lightning-dev 11:09 -!- JackH [~laptop@host-80-43-140-108.as13285.net] has quit [Ping timeout: 240 seconds] 11:13 -!- abbitcryptic [18fe50ac@gateway/web/freenode/ip.24.254.80.172] has joined #lightning-dev 11:16 < abbitcryptic> roasbeef: just watched this https://www.youtube.com/watch?v=8WJeCXqKg9I and it sounded like you're pro-BCC? but i couldn't quite tell if you were joking or not. Could you elaborate where you fall on the subject? 11:19 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds] 11:30 < stevenroose> lol, abbitcryptic, considering roasbeef implemented segwit in btcd with his own hand and bitcoin cash refusing to include segwit, I think he would be the very last supporter of bitcoin cash :D 11:34 < abbitcryptic> stevenroose: yes, that was my assumption as well...i was mostly impressed he was able to hold a straight face while discussing his BCC views (he cracked up at other times) 11:35 < stevenroose> well, I don't know him personally, but I watched enough talks of him to know he has a sense of humor :) 11:35 < abbitcryptic> stevenroose: yes, he does...i honestly assumed he was joking, but hadn't talked to him in over a year and you never know...sometimes people go to the dark side, lol 11:36 < stevenroose> :D true 11:37 < abbitcryptic> someone had privately sent me a link to that video claiming that he had changed to BCC and my initial response (without even watching the video at first) was -- "I highly doubt it." But then I watched the video and couldn't quite tell, lol. Hence, asking here. 11:40 < stevenroose> well, I'm only in the process of watching it :p 11:40 < stevenroose> it's kinda clear they are joking with the bitcoin cash narrative :D 11:41 < abbitcryptic> on a different (and more relevant) topic though: if I have a LN channel with open with party A but the balance is almost entirely depleted (ie: it's in party A's favor), the only way to "top up" the channel would be if A sent me some of the balance (for whatever reason, presumably because A received a different tx that gave them confidence to do so), right? 11:42 < abbitcryptic> stevenroose: yah, i feel dumb for even considering that he wasn't joking ;) 11:43 < stevenroose> hmm, that's not the only way 11:43 < abbitcryptic> back to my other question: it seems that LN will be great (i've fiddled with it using eclair so far) as long as you don't have to open/close channels too often. But in real life it seems that most "channels" are unidirectional and would hit their limit quickly. 11:44 < stevenroose> you could indeed send him money over different channels in return for money on your channels 11:44 < stevenroose> f.e. you sent money over Y -> B -> C -> A, while A sends to you 11:44 < abbitcryptic> for example: i almost always pay the grocery store, but only occasionally receive cash back... 11:44 < stevenroose> so basically, you send to yourself over the route Y -> B -> C -> A -> Y 11:44 < stevenroose> you can do that yourself automatically 11:45 < stevenroose> but that of course requires there to be a suitable alternative path between you and A 11:45 < abbitcryptic> ah ha! that's what i was missing 11:45 < stevenroose> it is possible to "top up" a channel with one on-chain transaction 11:45 -!- moctos_ [~moctos@cpe-107-9-138-59.neo.res.rr.com] has quit [Quit: moctos_] 11:46 < abbitcryptic> stevenroose: does it "top up" the exact same channel or does it close the previous and start a new one? 11:46 < lndbot> close+open in one tx 11:46 < stevenroose> I guess it's in the protocol specs, I heard it on #lnd here, but there is a standardized way to use a single transaction to close and reopen a channel by adding or removing funds from it 11:47 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 11:47 < abbitcryptic> interesting 11:47 < stevenroose> but if done in some standardized way, the other party would recognize this and just considers it a refresh of the channel 11:47 < stevenroose> betawaffle: is it in the spec? 11:47 < betawaffle> dunno, the specs are still being written 11:48 < abbitcryptic> yah, it's hard to keep all this straight, but it's exciting times nonetheless ;) 11:49 < betawaffle> but yeah, if i understand correctly, assuming you have multiple different channels, you can re-balance one channel using another one 11:49 < betawaffle> so you're not even necessarily doomed in the worst-case of becoming fully unbalanced 11:50 < betawaffle> sorta like moving money from one bank account to another 11:50 < abbitcryptic> so back to your example of sending to yourself (off-chain)...so you have a channel with your employer and a channel with the grocery store...when your grocery channel depletes (or gets close), you're saying that you could generate a "grocery request" and then pay that request from your employee channel? 11:50 < betawaffle> (except that the banks can't see it's you) 11:50 < abbitcryptic> right 11:50 < betawaffle> abbitcryptic: i think so, yes 11:51 < betawaffle> it'd be just like some rando deciding to pay you money via your grocery channel 11:51 < betawaffle> except the rando would be you 11:51 < abbitcryptic> so, in that scenario, as long as the grocery store "plays along" and allows money to flow in reverse, it works 11:51 < betawaffle> yep 11:52 < abbitcryptic> right, so as long as safe policies can be enforced algorithmically by the grocery store's lightning node (whether its their own or some service they use), then all good 11:52 < betawaffle> safe policies? 11:53 < abbitcryptic> sorry...just meant that the grocery store doesn't want to pay a random customer money unless they have in fact been paid for doing so (made whole)...obviously that's what the LN is for in the first place though, so i guess it's "safe by default" 11:53 < betawaffle> yep, that's how LN works though 11:53 < betawaffle> yep 11:54 < abbitcryptic> i more meant that there is nothing preventing a grocery store from doing a small "advance" if need be too...but it probably isn't worth the underwriting headache of doing so 11:54 < betawaffle> lol, nah 11:54 < betawaffle> it's entirely unnecessary 11:54 < betawaffle> no trust needed 11:54 < betawaffle> no loans 11:55 < abbitcryptic> yep, it's beautiful ;) 11:55 < betawaffle> it's really pretty amazing 11:56 < abbitcryptic> depending on the size and duration of a channel there is underwriting risks of whether to open a channel in the first place -- mostly due to time-preference, but that's different than a standard loan 11:56 < betawaffle> your primary channels could be like checking accounts 11:56 < betawaffle> and non-channelled btc just savings 11:57 < abbitcryptic> right, and you really could just have a small amount spread across a few channels and just top them up when necessary 11:57 < betawaffle> yeah, like imagine getting paid via LN 11:58 < abbitcryptic> exactly 11:58 < betawaffle> you'd be golden ;) 11:58 < betawaffle> just the occasional channel open/close to move money in and out of cold storage if you needed to 11:59 < stevenroose> it's amazing how people can get enthousiastic about this over and over again :D 11:59 < stevenroose> including myself :) 12:02 < abbitcryptic> right...so if you take the example of someone/entity that has, on average, net inflows slightly greater than net outflows (ie: profit), if they want to move that profit over to "savings" (on-chain), they would need to close out (or close and immediately reopen) a channel 12:05 < abbitcryptic> has anyone done any work on whether/how it might be profitable for a reasonably well-connected lightning node to earn enough in relay fees to offset the costs of running both the LN node itself and the also required btc full node? 12:11 < stevenroose> abbitcryptic: you could always send it in lightning to someone who is willing to send on-chain coins to you 12:12 < stevenroose> I imagine on-to-off-chain convertion services will exist, a simple transfer tx is a lot cheaper than a channel close+open tx 12:18 < betawaffle> a lot cheaper? 12:23 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds] 12:46 -!- abbitcryptic [18fe50ac@gateway/web/freenode/ip.24.254.80.172] has quit [Quit: Page closed] 14:02 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 14:37 -!- JackH_ [~laptop@host-80-43-140-111.as13285.net] has quit [Ping timeout: 260 seconds] 14:42 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 14:59 -!- JackH [~laptop@host-80-43-140-111.as13285.net] has joined #lightning-dev 15:44 -!- JackH [~laptop@host-80-43-140-111.as13285.net] has quit [Quit: Leaving] 16:02 -!- coredump_ [~quassel@vpn-qld171.vpnsolutions.com.au] has joined #lightning-dev 16:52 -!- jtimon [~quassel@14.29.134.37.dynamic.jazztel.es] has joined #lightning-dev 17:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wzjstymtsyoqkyrp] has quit [Quit: Connection closed for inactivity] 18:06 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 18:23 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #lightning-dev 18:27 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 276 seconds] 18:39 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 18:41 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Ping timeout: 240 seconds] 18:41 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #lightning-dev 19:18 -!- murchandamus [~murchghos@ghostdub.de] has quit [Ping timeout: 276 seconds] 19:21 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 19:30 -!- murchandamus [~murchghos@ghostdub.de] has joined #lightning-dev 20:00 < instagibbs> throw-away idea: use anyonecanpay sighash to allow you to fee bump without counter-party cooperation, cheaper than CPFP. 20:00 * instagibbs has no idea how much stuff this breaks 20:44 < aj> instagibbs: requires you to spend a whole output to fees and your counterparty to have used anyonecanpay sighash? also doesn't seem terribly much cheaper? 20:57 -!- CubicEarth [~cubiceart@host-69-144-45-132.static.bresnan.net] has joined #lightning-dev 21:27 < renlord> single & anyonecanpay so you can produce your output for change? 21:55 < instagibbs> aj, yes, less utility if it requires adding change. 21:56 < instagibbs> s/less/no 22:03 <+roasbeef> instagibbs: also can be used to (w/ single) to coalesce transitioning the state of all outgoing htlc convenant transactions to claim+delay in a single tx 22:05 < aj> renlord: there's a single multisig output funding the channel that needs to sign at least two outputs (yours and theirs), so single can't be used afaics? 22:11 -!- CubicEarth [~cubiceart@host-69-144-45-132.static.bresnan.net] has quit [] 22:16 <+roasbeef> also as it's your commitment transaction, you can't use CPFP until the timeout on an outgoing htlc (if any) has elapsed. at that point if what I mentioned above, can use that to add another input into the htlc timeout transaction to try and anchor the commitment transaction 22:19 <+roasbeef> which would be the case if you're broadcasting due to an HTLC timeout, so can potentially be useful 22:20 < instagibbs> roasbeef, I understood some of those words :) 22:21 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 22:22 <+roasbeef> instagibbs: so as is now, HTLC's have a two-stage claim process, this gets around some issues that coupled the csv delay and absolute timeout. For each HTLC we create a transaction that spends a clause in the HTLC output that's a 2-of-2 multi-sig and maybe a pre-image (if you're trying to claim) 22:23 <+roasbeef> it's essentially an off-chain covenant, as this transaction is the only way you can spend that HTLC output (for that particualr clause), and then I also enforce that you MUST send to an ouput that has a CSV delay clause 22:24 <+roasbeef> as is, you'd need an on-chain transaction for each outgoing HTLC when you'd go to broadcast your commitment transaction (for w/e reason). using non-routine sighash flags, we can allow combinding those 1-in-1-out second-level transactions into one mega transaction 22:24 <+roasbeef> or it might not be mega, but in either case you'll be able to add additional inputs if you wanna sweep NAO 22:25 <+roasbeef> implements a state-machine for the HTLC essentially: locked-in and delay+claim 22:26 <+roasbeef> w/ two states* 22:27 <+roasbeef> instagibbs: this is kinda desribed in the 3rd doc, but gets str8 to the what, not why (how htlc's work, not this sighash stuff) 22:30 <+roasbeef> stevenroose: you could send someone money over LN, and in the onion, instruct them to make the final hop on-chain (using the same payment hash ofc). it's a bit slower, but still makes the claim atomic, so mixing on-chain and off-chain swaps 22:31 < renlord> aj: the funding transaction only has one output? so I assume if only 1 input is used to fund, then single & anyonecanpay is ok? 22:33 <+roasbeef> renlord: it has many, he's referring to the commitment transaction, which may have up to two outputs 22:33 <+roasbeef> well I guess it may have one if you don't make any change at all 22:34 * roasbeef raises a fist and chants "ELIMINATE THE DUST, DOWN WITH UTXO SET BLOAT" 22:39 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 258 seconds] 22:50 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 23:19 -!- Deadlyelder [~Thunderbi@ip-213-135-240-50.static.luxdsl.pt.lu] has joined #lightning-dev 23:29 -!- Deadlyelder [~Thunderbi@ip-213-135-240-50.static.luxdsl.pt.lu] has quit [Remote host closed the connection] 23:39 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-syysxujgxlmyybpu] has joined #lightning-dev