--- Day changed Tue Feb 21 2017 00:02 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 00:06 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 01:37 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 01:39 -!- moli_ [~molly@unaffiliated/molly] has joined #lightning-dev 01:42 -!- aalex [~aalex@64.187.177.58] has joined #lightning-dev 02:07 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 02:08 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #lightning-dev 02:16 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds] 02:17 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 02:46 -!- lclc_ [~lclc@unaffiliated/lclc] has joined #lightning-dev 02:46 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 255 seconds] 02:50 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 03:05 -!- lclc_ [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] 03:33 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 04:03 -!- lclc [~lclc@unaffiliated/lclc] has joined #lightning-dev 05:18 -!- takayaimai [~takayaima@em119-72-193-198.pool.e-mobile.ne.jp] has joined #lightning-dev 05:43 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 255 seconds] 06:02 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #lightning-dev 06:05 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 06:12 -githubby:#lightning-dev- [lightning] cdecker opened pull request #120: Refactoring timers and adding them to gossip (master...timers-ref) https://git.io/vDNaf 06:54 -!- aalex [~aalex@64.187.177.58] has joined #lightning-dev 06:58 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds] 07:27 -githubby:#lightning-dev- [lightning] cdecker opened pull request #121: bugfix: Assert was killing daemon (master...fix-82) https://git.io/vDNyg 07:29 -!- takayaimai [~takayaima@em119-72-193-198.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 07:31 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 07:33 -!- moli_ [~molly@unaffiliated/molly] has joined #lightning-dev 07:34 -!- aalex [~aalex@64.187.177.58] has quit [Quit: Connection reset by beer] 07:55 -githubby:#lightning-dev- [lightning] cdecker pushed 1 new commit to master: https://git.io/vDNF4 07:55 -githubby:#lightning-dev- lightning/master b901c68 Christian Decker: libwally: Re-adding missing gen_context file... 08:38 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 08:39 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 08:40 -!- mol [~molly@unaffiliated/molly] has quit [Remote host closed the connection] 08:40 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 08:44 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 08:51 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #lightning-dev 08:54 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] 08:57 -githubby:#lightning-dev- [lightning] cdecker pushed 1 new commit to master: https://git.io/vDALZ 08:57 -githubby:#lightning-dev- lightning/master 597687d Christian Decker: Fix CI build... 08:59 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #lightning-dev 10:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 10:15 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 10:50 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev 10:55 -!- molz_ [~molly@unaffiliated/molly] has joined #lightning-dev 10:58 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 255 seconds] 11:23 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 11:26 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 11:30 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 11:48 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 12:10 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 12:11 -!- mol [~molly@unaffiliated/molly] has quit [Remote host closed the connection] 12:12 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 12:12 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 12:23 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds] 12:44 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 12:50 -!- moli_ [~molly@unaffiliated/molly] has joined #lightning-dev 12:52 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 12:53 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev 12:56 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 13:10 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 255 seconds] 13:55 -!- maaku [~mark@173.234.25.100] has joined #lightning-dev 14:14 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 15:02 -!- jtimon [~quassel@199.116.72.155] has joined #lightning-dev 15:10 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 15:22 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds] 15:24 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 15:26 -!- jtimon [~quassel@199.116.72.155] has quit [Ping timeout: 240 seconds] 15:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds] 15:29 -lightningrfc:#lightning-dev- [lightning-rfc] rustyrussell closed pull request #107: Fix test vectors minor (master...fix-test-vectors-minor) https://git.io/vDVHR 15:30 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has quit [Remote host closed the connection] 15:33 -!- jtimon [~quassel@199.116.72.155] has joined #lightning-dev 15:41 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 16:09 < roasbeef> amiller: so finished a read through of the paper have a few questions and comments 16:09 < roasbeef> am I correct that with sprite, each payment requires the reciver to write to the global pre-iamge storage contract? 16:10 < roasbeef> which would mean that each payment requires an on-chain transaction? 16:10 < amiller> roasbeef: no, you only need to write to the PreimageManager contract in a dispute 16:11 < roasbeef> gotcha, in the case of a dispute with sprite are the intermdaite nodes away from the point of dispute required to claim on chain? or can they continue their normal operation? 16:12 < amiller> in the case of a "dispute" they can keep using their channel like normal 16:12 < amiller> basically someone will only write to the preimage manager contract if there is *some* link that has failed in the path 16:12 < amiller> the other parties wait (passively) to see what happens to the preimagemanager contract 16:13 < roasbeef> gotcha, that's the same case with lightning as the incrementing time-locks give the intermdaite nodes an opporunity to cancel/settle off-chain, the paper seems to argue the opposite. i'd say the worst-case tie delay is only suffered by the link that fails rather than the entire chain 16:13 < amiller> then they typically either "complete" or "cancel" off chain based on how it ended 16:13 < roasbeef> I see, with point #2 it's possible for all other on the intermdaite path to redeem off-chain as soon as the pre-image is available in the blockchain by any party 16:13 < roasbeef> and it's possible to add funds to or pay out of a channel with a single on-chain transaction for ln 16:14 < roasbeef> my understanding of ethereuem isn't the best, but it seems that even though you can zero out the contracvt storage for those at the tip of the chain, if you do a historical sync, then w/o state trie pruning the space can never truely be re-claimed 16:16 < roasbeef> also in the current version every revocatoin key/hash doesnt need to be stored the generator has O(1) state but the reciver can collapse them to O(logn) state. the htlcs are the issue that currnetly need to be rememered for the duration of the channel 16:16 < roasbeef> if we get something like MAST, then we can have a separate clause for HTLC claiming, so state can be logn for all 16:16 < amiller> roasbeef: thanks, those are really interesting corrections. 16:17 < amiller> how do you add funds to a LN with a single on-chain transaction? 16:17 < roasbeef> I think that you can emulate the sprite "same tiem lock for entire path" in bitcoin, but then that would eliminate the ability to cancel/settle off-chain for the others in the case of a dispute 16:17 < roasbeef> you create a new transaction spending the old multis-sig, then add another input(s) of funds from either or both sides. the outputs are then the new channel multis-ig and possible change addresses 16:18 < amiller> hm i see 16:18 < amiller> that seems like it would be one transaction, but still kind of messy, like it would be a transaction with potentially a lot of outputs... especially if you are trying to withdraw/deposit from a channel with multiple active in-flight payments 16:19 < roasbeef> assumign nodes can watch the chain, then as soon as the pre-image is available they can all go on-chain to claim it. this reduces the "collateral" as described in the paper, but then they _must_ write to the chain for every dispute. the decremtngin time locks are a feature taht allow only the channel in disput to go on-chain, the others can either cancel or use the pre-iamge to claim 16:19 < roasbeef> mhmm, atm we have a "shutdown" cool off perdiod where they try to wait until all the HTLC's are settled, then attempt to do a cooperative closure 16:20 < roasbeef> hyphetically, maybe you could thread throuhg all the pending HTLC's w/o distrupting them or requiring them to be claim on-chain, something something convenant? 16:20 < roasbeef> this paper is very cool! first formal treatment of payment/state channels i've seen 16:21 < roasbeef> for the signature establishment: if the channel is single funder (only one party puts in funds), then only 2 x1 sigs are required: 2 for the funding and only 1 commitment transaction 16:22 < roasbeef> about the commentary for point #2: if we move to "decorellating" the hash-lock values, then we can't do the "anyone can claim after anyone else" as doing that introduces causality as in the reveal _must_ flow backwards 16:25 < roasbeef> with sprite, can you only have a single pending conditional payment at once? 16:25 < roasbeef> (within a single channel) 16:29 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 268 seconds] 16:48 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev 16:54 < rusty2> Yes, decorrelation was my concern too, but I've not been paying attention because ethereum. 16:56 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has joined #lightning-dev 16:59 -!- maaku [~mark@173.234.25.100] has quit [Quit: Lost terminal] 17:00 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:04 < amiller> i haven't followed what you're suggesting about decorrelation 17:04 < roasbeef> w/o decorrelation the payment hashes are all the same along the path 17:04 < roasbeef> so anyone in the middle with two or mode nodes can see it's the same payment 17:04 < roasbeef> w/ decorrelation the hashes differ, and hash_N must be presented before hash_N-1 can be construced and use to redeem, so there's an actual casual depencany when it comes to redemption 17:05 < amiller> oh i see 17:05 < roasbeef> it's a privacy feature, but seems using that in sprite wouldn't allow for the pre-image manager construction nor would it allow for the "anyone can claim after the pre-iamge" is revealed in bitcoin 17:06 < roasbeef> unless there's some other clause or backdoor or something, dunno 17:06 < amiller> yeah that is a problem for sure, we decided to punt on privacy to keep things simple/tractable but it does seem clear that the global preimage thing seems hard to reconcile with that 17:08 -!- maaku [~mark@173.234.25.100] has joined #lightning-dev 17:08 < roasbeef> mhmm, it also seems that in the event of a dispute, then the payment path is revealed to the entire world. as each of the contracts would need to query the global preimage contract right? can you see a stack-trace in contracs in etheruem? as in who was the original caller? 17:08 < amiller> i can imagine doing something with ring signatures maybe 17:09 < roasbeef> to not reveal _who_ place the preimage in the global contract? 17:11 < roasbeef> sprite question: if a payment it outsnding in a channel, can another one be extended w/o distrupting the pending one? 17:13 < amiller> that is easy in principle, technically the formalism and the github sample only cover 1 at a time 17:14 < amiller> not 1 at a time, 1 ever actually 17:14 < amiller> but there is no complexity there, the 'state' you agree on will just be an array or a merkle tree of inflight payments 17:14 < roasbeef> ah yeh, you'd just have a map/arry or something of pending payments in solidity I guess 17:16 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 17:21 -!- cbits [~cbits@2607:f380:a61:650:1c60:9bd6:3cd3:3130] has joined #lightning-dev 17:22 -!- maaku [~mark@173.234.25.100] has quit [Ping timeout: 255 seconds] 17:22 -!- maaku [~mark@173.234.25.100] has joined #lightning-dev 17:25 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has joined #lightning-dev 17:28 < amiller> to answer your question yes you can see a stack trace of what called what, so it would be clear what address was the initial caller, in principle you submit a preimage through tor or with the help of a miner or something 17:30 < amiller> also, it is similar to lightning, only the links that fail have to go on chain 17:33 < amiller> so even if someone disputes and sends a preimage to the contract, the remaining parties can just observe that x has been put there, and then complete/cancel the transaction offchain 17:33 < amiller> which doesn't reveal the path 17:45 -!- cbits [~cbits@2607:f380:a61:650:1c60:9bd6:3cd3:3130] has quit [Ping timeout: 240 seconds] 17:50 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 276 seconds] 17:51 -!- jtimon [~quassel@199.116.72.155] has quit [Ping timeout: 255 seconds] 17:58 -!- jtimon [~quassel@199.116.72.155] has joined #lightning-dev 18:02 -!- stonecoldpat [48247152@gateway/web/freenode/ip.72.36.113.82] has joined #lightning-dev 18:03 < stonecoldpat> @rosabeef for the single funder case- it isn't clear to me how there are only three 3 signatures? (i.e. co-operatively sign the funding tx, and then 1 commitment transaction) 18:06 -!- ThomasV_ [~ThomasV@x4e37d086.dyn.telefonica.de] has joined #lightning-dev 18:10 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds] 18:16 -!- jtimon [~quassel@199.116.72.155] has quit [Remote host closed the connection] 18:16 -!- spolu [~textual@2607:fb90:9c37:7a38:cda6:7b08:55b1:1f6c] has joined #lightning-dev 18:21 < roasbeef> stonecoldpat: actually, there's just 2 in that case opstimisically: initiator signs input into transaction, responder signs commitment transactions for iniaitor, initiator broadcasts 18:22 < roasbeef> what's the "2x2" mean in that table? 18:27 < stonecoldpat> @roasbeef ah ok. so the non-depositor doesn't get a commitment transaction (since they dont need to close it). I get it now. the 2x2 means - the funding transaction is co-operatively signed - and each party signs the counterparties commitment transaction (so A signs B's commitment, and gives it to him, B signs Alice's commitment and gives it to her). so 4 signatures in total. 18:27 < stonecoldpat> I think (1 x 2) + 2 is better way to describe that on hindsight. so 1 co-operative sign. 18:27 < roasbeef> stonecoldpat: yeh they can do that optionally, for generality atm the non-depositor gets one also atm 18:27 < roasbeef> gotcha 18:28 < roasbeef> about about "1x2" on the payment and transfer? 18:28 < roasbeef> what abuout* 18:28 < roasbeef> about8 18:28 < roasbeef> about* 18:28 < roasbeef> kek, can't type 18:28 < stonecoldpat> both parties co-operate to sign new commitment transactions 18:28 < stonecoldpat> so again, A signs bob's commitment, B signs Alice's commitment, and then they both revoke old one. 18:29 < roasbeef> that's just two though? ah, I guess written that way to be consistent with the rest of the row? 18:29 < stonecoldpat> yeah 18:30 < stonecoldpat> just to show they are co-operating 18:30 < roasbeef> gotcha 18:30 -!- ThomasV_ [~ThomasV@x4e37d086.dyn.telefonica.de] has quit [Ping timeout: 240 seconds] 18:31 -!- ThomasV_ [~ThomasV@x4e37d086.dyn.telefonica.de] has joined #lightning-dev 18:32 -!- spolu [~textual@2607:fb90:9c37:7a38:cda6:7b08:55b1:1f6c] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 18:33 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 18:40 -!- ThomasV_ [~ThomasV@x4e37d086.dyn.telefonica.de] has quit [Quit: Quitte] 18:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-jljakbxkxrhbqyyv] has quit [Quit: Connection closed for inactivity] 18:55 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has joined #lightning-dev 19:06 -!- cbits [~cbits@2607:f380:a61:650:d9a7:6afa:6dbe:5a6] has joined #lightning-dev 19:07 -!- stonecoldpat [48247152@gateway/web/freenode/ip.72.36.113.82] has quit [Ping timeout: 260 seconds] 19:08 -!- Guest47306 [~socrates1@li175-104.members.linode.com] has joined #lightning-dev 19:08 -!- Guest47306 [~socrates1@li175-104.members.linode.com] has quit [Changing host] 19:08 -!- Guest47306 [~socrates1@unaffiliated/socrates1024] has joined #lightning-dev 19:08 -!- Guest47306 is now known as amiller 19:09 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 19:14 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has joined #lightning-dev 19:25 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 19:34 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has joined #lightning-dev 19:34 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 19:38 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 19:51 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has joined #lightning-dev 20:02 -!- cbits_ [~cbits@139.182.205.184] has joined #lightning-dev 20:06 -!- cbits [~cbits@2607:f380:a61:650:d9a7:6afa:6dbe:5a6] has quit [Ping timeout: 255 seconds] 20:07 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 20:15 -!- takayaimai [~takayaima@em119-72-199-20.pool.e-mobile.ne.jp] has quit [Remote host closed the connection] 20:35 -!- shesek [~shesek@bzq-84-110-60-48.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 21:20 < roasbeef> amiller: actually you wouldn't need to disrupt HTLC's at all if you did a splice in/out, you'd just shift them all over to the new commitment transaction. with something like sighash_noinput you wouldn't even need to make a new commitment transaction if the multi-sig re-used the same keys 21:22 -!- koshii [~w@c-50-151-108-105.hsd1.in.comcast.net] has quit [Ping timeout: 258 seconds] 21:27 -!- cbits [~cbits@139.182.205.184] has joined #lightning-dev 21:29 -!- cbits_ [~cbits@139.182.205.184] has quit [Ping timeout: 240 seconds] 22:15 -githubby:#lightning-dev- [lightning] rustyrussell pushed 4 new commits to master: https://git.io/vDxAA 22:15 -githubby:#lightning-dev- lightning/master 1c4c874 Christian Decker: refactor: Making timers independent of the lightningd_state... 22:15 -githubby:#lightning-dev- lightning/master 83f51fe Christian Decker: gossip: Add timer support to the io_loop 22:15 -githubby:#lightning-dev- lightning/master fccab64 Christian Decker: gossip: Add timer and normal queue for messages... 22:18 -githubby:#lightning-dev- [lightning] rustyrussell pushed 1 new commit to master: https://git.io/vDxxq 22:18 -githubby:#lightning-dev- lightning/master 26d4042 Christian Decker: bugfix: Assert was killing daemon... 22:22 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds] 22:28 -!- cbits_ [~cbits@139.182.205.184] has joined #lightning-dev 22:32 -!- cbits [~cbits@139.182.205.184] has quit [Ping timeout: 240 seconds] 22:53 -!- cbits_ [~cbits@139.182.205.184] has quit [Ping timeout: 240 seconds] 23:17 -!- lclc [~lclc@unaffiliated/lclc] has joined #lightning-dev 23:23 -!- takayaimai [~takayaima@em1-115-197-252.pool.e-mobile.ne.jp] has joined #lightning-dev 23:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]