--- Day changed Mon Aug 31 2015
00:27 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []
00:44 -!- richardkiss [~richardki@173-228-123-155.dsl.dynamic.fusionbroadband.com] has quit [Quit: richardkiss]
01:50 -!- jtimon_ [~quassel@m952736d0.tmodns.net] has quit [Ping timeout: 265 seconds]
02:07 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 240 seconds]
05:00 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #lightning-dev
06:07 -!- vendu [~vendu@dsl-kpobrasgw1-58c16f-4.dhcp.inet.fi] has joined #lightning-dev
06:07 < vendu> hello guys
06:07 < vendu> i was just wondering if i forgot to give you guys operator flags here :)
06:07 < vendu> sorry if so :)
06:07 < vendu> been trying to enjoy the little of summer we have had in finland :P
08:51 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has joined #lightning-dev
09:07 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
09:19 < mjerr> just had a look into the htlc scripts, and it seems the sender can not reliably claim funds after the timeout. is this intended? the script only specifies a relative (and absolute) delay in the case of a timeout for the sender, but the receiver can still claim it, even if the timeout is ages ago already
09:58 -!- jtimon [~quassel@md42736d0.tmodns.net] has joined #lightning-dev
09:58 -!- richardkiss [~richardki@173-228-123-155.dsl.dynamic.fusionbroadband.com] has joined #lightning-dev
10:00 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
10:00 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer]
10:11 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds]
10:18 -!- ftlio [~ftlio@ftlio.com] has quit [Remote host closed the connection]
10:22 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has joined #lightning-dev
11:16 -!- jtimon [~quassel@md42736d0.tmodns.net] has quit [Ping timeout: 264 seconds]
11:18 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
12:17 < aj> mjerr: the sender has to claim the funds once the timeout hits, they shouldn't leave it unclaimed for an extended period
12:18 < mjerr> aj, yea I thought so. Currently I am also using that technique, however I think it would be really nice to not have to force-close the channel when one payment timeouts
12:19 < aj> mjerr: you don't have to close the channel, you just update the commitment txns with the htlc removed and the funds going back to the payer
12:19 < mjerr> aj, I'm talking about times where you cannot reach the other node. It relaxes the requirement to be online most of the times
12:20 < mjerr> Of course that would imply that the receiver would need to wait for X days aswell, even if he can provide the secret
12:20 < aj> mjerr: if you can't reach the node, then you have to close the channel anyway?
12:22 < mjerr> No you don't, thats the beauty. You can wait for the other node to come online again... If he broadcasts the channel and the payment timed out, you can just claim it anyways, but it also allows to remove the htlc without broadcasting it
12:26 < mjerr> the script would be quite complicated to accomodate for all the different possibities.. something along this: ( hash secret + CSV 2 day + sign ) OR ( hash revocation + sign ) OR ( cltv timeout + CSV 1 day + sign )
12:26 < mjerr> it would allow for instant revocation, if the payment timeouted you can claim the funds after one day, and the receiver can claim his payments after 2 days
12:27 < aj> mjerr: err, that is how the scripts go though?
12:28 < mjerr> in the latest doc pdf there is no 'CSV 2 day' for claiming the funds?
12:28 < aj> mjerr: R + A + CSV | CLTV + B | REVOKE + B   //  R + A | CLTV + CSV + B | REVOKE + A
12:28 < mjerr> at least not in the script of the sender
12:29 < mjerr> yea the R + A in the second one
12:29 < mjerr> means that the sender cannot enforce the timeout
12:31 < aj> mjerr: right, there's a potential conflict if closing the channel at TIMEOUT +/- DELAY
12:31 < mjerr> yea, thats an additional issue
12:31 < mjerr> that the 'absolute timestamp' of the cltv is not the actual timeout
12:31 < aj> mjerr: if you close it prior to TIMEOUT-DELAY, you're fine -- they claim it with R up to TIMEOUT, and at TIMEOUT you can claim it
12:32 < mjerr> but we don't want to close it? ;P
12:32 < mjerr> at least not if we could help it
12:33 < mjerr> adding a CSV that is longer than the one for B would eliminate the requirement to close the channel in time
12:33 < mjerr> while the CLTV makes sure the sender cannot claim it before the timeout
12:34 < aj> mjerr: so, if they forwarded it, they should have chosen something like TIMEOUT-1day right? which means they should be happy to close the txn as failed at TIMEOUT-1day which is < TIMEOUT-DELAY presumably
12:35 < mjerr> you mean if we forwarded that payment towards another receipment? that shouldn't change much, only the absolute CLTV will be -1 day.. this change does not mean a payment hangs in limbo when the other node cannot be reached in time
12:36 < aj> mjerr: adding the CSV just moves the problem from me not being able to claim until potentially TIMEOUT+DELAY to them potentially not being able to claim from TIMEOUT-DELAY
12:37 < aj> mjerr: if they discovered R at TIMEOUT-DELAY, and revealed it to you hoping to keep the channel open; you could say "aha!" and claim the funds that were forwarded to you, but close the channel and not pay them forward
12:38 < aj> mjerr: (C tells B: R; B tells A: R, A pays B, B closes channel, C can't claim funds due to DELAY, B claims funds at TIMEOUT)
12:38 < mjerr> but this is the way it should work.. because the CLTV TIMEOUT is not the real timeout for the payment, as TIMEOUT-DELAY is the point at which the receiver cannot claim the funds via blockchain anymore.. it's just a problem of defining the term TIMEOUT
12:38 < aj> mjerr: (if you're not forwarding the payment, you should know R immediately)
12:39 < mjerr> TIMEOUT-DELAY-BUFFER is the latest point at which the receiver of the payment should disclose R at the latest
12:40 < mjerr> as he cannot be sure to either settle the payment with the other node, nor enforce it on the blockchain after that point anymore
12:40 < aj> mjerr: hmm, good point!
12:40 < mjerr> =)
12:41 < mjerr> you really got back to me right as I wanted to leave ^^ brb for a while
12:42 < mjerr> but I think we really should change it somewhere along that line, as there are all sorts of reasons why a node might not be reachable, and it might even lead to DoS attacks, forcing the closure of many channels - unnecessary
12:53 -!- nullbyte [NSA@gateway/vpn/mullvad/x-pfwdhvcuaquketbq] has joined #lightning-dev
12:58 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has quit [Read error: Connection timed out]
13:19 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
13:51 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Ik ga weg]
13:52 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has joined #lightning-dev
15:11 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has quit [Ping timeout: 250 seconds]
16:50 -!- nullbyte [NSA@gateway/vpn/mullvad/x-pfwdhvcuaquketbq] has quit [Read error: Connection reset by peer]
18:36 -!- richardkiss [~richardki@173-228-123-155.dsl.dynamic.fusionbroadband.com] has quit [Quit: richardkiss]
19:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
19:17 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-ivmwjyzzmbarleix] has quit [Quit: Connection closed for inactivity]
20:08 -!- CodeShark_ [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 240 seconds]
20:55 -!- CodeShark [~androirc@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds]
21:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
21:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
22:10 -!- CodeShark [~androirc@108-90-230-162.lightspeed.sndgca.sbcglobal.net] has joined #lightning-dev
22:32 -!- richardkiss [~richardki@173-228-123-155.dsl.dynamic.fusionbroadband.com] has joined #lightning-dev
23:29 < mjerr> rusty, you around?
23:30 < rusty> mjerr: I am!
23:31 < mjerr> rusty, I looked over the scripts again yesterday, and I think it would be nice to add a CSV to the sender redeemscript, such that the sender does not need to close the channel, in case he can't reach the other node
23:31 < mjerr> something along this: ( hash secret + CSV 2 day + sign ) OR ( hash revocation + sign ) OR ( cltv timeout + CSV 1 day + sign )
23:32 < rusty> mjerr: which redeemscript are we talking about here?
23:32 < mjerr> the HTLC Sender Redeemscript, page 12 
23:33 < mjerr> there is no way to enforce the refund for the sender, if he does not broadcast the transaction in time
23:34 < rusty> mjerr: if someone is unresponsive with an active HTLC, you really do want to close the channel to them.
23:35 < rusty> mjerr: how would you redeem an HTLC at all without talking to them, except on the bitcoin blockchain?  I'm obviously missing something.
23:35 < mjerr> but there could be all reasons of unresponsiveness, and I thought you really just want to close the channel when the other channel is blatant uncoorporative.. these channels can grow huge, and there can be many reasons why a node might not be reached in time, like ddos... the two nodes can still close the payment in a friendly manner after the timeout, without the need of closing it
23:37 < rusty> mjerr: how do you close the payment without closing it?
23:37 < mjerr> closing the payment != closing the channel
23:37 < mjerr> ^^
23:37 < mjerr> the usual way to close the payment should be negotiation with the other party
23:38 < mjerr> and only the receiver of the money should be in a situation, where he HAS TO close the channel to enforce his rights
23:38 < rusty> mjerr: right, so you leave an expired htlc output lying around.
23:40 < rusty> mjerr: I see your point, but I'm not sure it helps.  You've given an extra day's grace, basically, at cost of doubling the timeout.
23:40 < mjerr> yea I have not thought about a timeout, how long you would want to wait in case the other party disapears.. probably depends on the money in htlc/channel as well.. but it also removes the risk of stolen funds if you don't publish your transaction in time.. and the states of the htlc are much clearer aswell.. it's either ACTIVE or TIMEOUT, independend whether either party broadcasted it
23:40 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds]
23:42 < mjerr> and it would further mitigate the full-block-attack as well
23:46 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-kjoryacxoksdlykg] has joined #lightning-dev
23:47 < rusty> mjerr: so, A offers an HTLC to B with a 1 day timeout, it would look like: ( hash secret + CSV 2 day + sigB ) OR ( hash revocation + sigB ) OR ( cltv timeout + CSV 1 day + sigA ).  The CSV 2 day is new.
23:48 < rusty> mjerr: Now, if A were to drop that on the blockchain after the timeout, they could spend it before B, which is nice.
23:50 < mjerr> yea we have to be careful with the term timeout here, as the payment timeout is not the same as the absolute timestamp of the cltv anymore.. for a real payment timeout of one day, I guess you would have: ( hash secret + CSV 12 hours + sigB ) OR ( hash revocation + sigB ) OR ( cltv 36 hours + CSV 6 hours + sigA )
23:50 < rusty> mjerr: I think it's overkill for the moment, but please post to the ml so the idea (and credit!) doesn't get lost.
23:51 < mjerr> after 24 hours the receiver would not reveal R anymore, as he would have no way to enforce it from that point
23:52 < mjerr> sure! I guess i'll implement it in thunder as well, as you have to time one thing less this way and you are watching the blockchain anyways
23:56 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev