--- Day changed Sun Feb 07 2016 00:35 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-axcjrqwpegejyucb] has joined #lightning-dev 01:54 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev 05:51 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev 05:51 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 06:55 -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has joined #lightning-dev 06:55 -!- roidster is now known as Guest38492 06:55 -!- Guest38492 is now known as roidster 07:32 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev 10:29 -!- Guest41062 [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Quit: Page closed] 13:10 -!- Netsplit *.net <-> *.split quits: sugarpuff 13:12 -!- sugarpuff [sid92283@gateway/web/irccloud.com/x-fyoevqrijkvgkvgf] has joined #lightning-dev 13:15 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has joined #lightning-dev 13:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer] 13:45 -!- Psztorc [~Psztorc@ool-4575fa8d.dyn.optonline.net] has joined #lightning-dev 13:46 < Psztorc> Can anyone tell me if this document is up to date: https://lightning.network/lightning-network-technical-summary.pdf ? 13:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 13:48 < Psztorc> Specifically, I am a little confused by this sentence: "If either party incorrectly broadcasts an old transaction state, the counterparty may take all the funds in the channel as a penalty." 13:49 < Psztorc> I do not understand how blame is assigned, if a transaction changes from "hidden" to "broadcast". 13:49 < Psztorc> Thank you. 13:51 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 13:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds] 14:03 < roasbeef> Psztorc: blame is assigned according to which version of the commitment transaction was broadcast. There are two commitment transactions, they are asymmetric. The version belonging to "me" has a relative delay on the output paying to "self" (ignoring uncleared payments for a second). This delay is required in order to introduce a contestation period allowing the other party to claim my settled balance if I broadcast a previously revoked state. 14:11 < Psztorc> roasbeef: I still don't get it. Say we start with 5 in from me, and 6 in from you. We have (apparently not one, but) two ouputs, in "version 1", 5 back to me and 6 back to you. Then we update both, updating locktime / sequence / whatever. You are saying that I don't have a copy of all of these transaction versions? 14:12 < Psztorc> By "outputs" I meant "transactions". 14:12 < Psztorc> "two different transactions paying 'out' of the channel" 14:13 < Psztorc> It would seem that I would always need the latest version, to know that I am being paid. And I would then know all "old" versions, and could pretend to be you and broadcast them and thereby steal all of your money. 14:15 < roasbeef> you're unable to broadcast "my" old commitment versions because you don't have my signature for the particular txn required to spend from the 2-of-2, txns are half-signed until either side wants to broadcast 14:16 < roasbeef> yes you need the latest version, but only the neccessary state required to be able to reconstruct old versions (revoke hash, timeout, balances, etc) 14:16 < Psztorc> Ok, if that is the case, how is the penalty enforced? It seems that no conflicts will be signed by both parties, so there will be nothing to broadcast? 14:16 < roasbeef> broadcasted commitment versions may contain "hints", to allow both sides to quickly re-derive which version was broadcast since the outputs are p2sh 14:17 < roasbeef> which penalty? 14:17 < Psztorc> There is this claim, which I had never heard before: "If either party incorrectly broadcasts an old transaction state, the counterparty may take all the funds in the channel as a penalty." 14:17 < Psztorc> I've never heard anyone bring this up. 14:18 < roasbeef> how is that enforced? via the "revocation" hashes. Before I agree on a new state, I require you to hand over the pre-image for a revocation hash which will allow be to take the funds if the revoked commitment state is broadcast 14:19 < roasbeef> we use a verifiable psuedo-random function of sorts to allow each side to properly verifiy and re-derive the necessary revocation pre-images effiecntly in both space+cpu 14:19 < Psztorc> Ok, so we not only set up "refund" transactions, but also "punative" transactions. 14:20 < Psztorc> I start saying "5 in from me...if we set up the 5 back from me" and then I also separately say "all of my 5 to you, if you guess the password". 14:20 < roasbeef> Yeah, you could say that. The "base" commitment transactions has 1 "unencumbered" output that can be claimed immediately, and a "punative" clause in the second output 14:23 < Psztorc> Ok, so I put in 5 and you put in 6, then we update from "refund" to "sequence #1" which is 5.1 to me and 5.9 to you. What are the outputs of the 2 of 2? 14:24 < Psztorc> I assume they were just 5.1 to me and 5.9 to you, but you seem to be saying that they are actually something like 0.1 to me, 5 to you ; 5.9 to you ? 14:24 < Psztorc> Or are their two mutually exclusive sets of outputs? 14:25 < Psztorc> there* (God..) 14:25 < roasbeef> by "of the 2 of 2" do you mean the funding transaction? That remains unchanged, it has been stamped within the chain 14:26 < Psztorc> No, I mean the "out" transaction. 14:26 < Psztorc> Let me try again. 14:26 < Psztorc> What do you have to do, to get my 5? 14:27 < roasbeef> for that update, there would now be 3 outputs until we clear: 5 to you, 0.1 to you (pending you reveal the secret), and 5.9 to me 14:27 < roasbeef> for me to get your 5, we need to move one update into the future, then you broadcast this past state 14:28 < Psztorc> Then we update again: 3 to me, 2 to you, and 6 back to you "sequence #2". 14:28 < Psztorc> Then I decide I want my 2 back, so I broadcast "sequence #1" and then set fire to my computer. 14:30 < roasbeef> So at that point, get my 6 back immediately. You don't really have your 3 or 2, since there's a CSV delay before you can redeem the outputs. So during that delay period, I use the revocation pre-image you told me when we went to "sequence 2", and claim your settled 3, and the HTLC 2 14:33 < Psztorc> I don't understand at all. 14:33 < Psztorc> You already have "sequence 1" and this revocation pre-image. 14:34 < Psztorc> Why don't you just broadcast "sequence 1"? 14:34 < roasbeef> :/ are you familiar with the way the output scripts are constructed? 14:34 < roasbeef> after you have? 14:34 < roasbeef> let's say yours immedately makes it into a block, so I can't, that would be double spending 14:35 < Psztorc> We have just privately constructed Sequence2. 14:35 < Psztorc> At this point, you have a revocation pre-image. 14:36 < roasbeef> yes I have the pre-image for your version of sequence 1 now 14:36 < Psztorc> However, moments ealier, you had Sequence1, which you signed (because I need to know that I am getting 0.1). 14:37 < Psztorc> So, say I do nothing wrong, and you broadcast Sequence1, and "during that delay period, I use the revocation pre-image you told me w..." 14:40 < roasbeef> Ok? So at that point I messed up. By giving you the revocation pre-image I promised never to broadcast that old state, since I violated our latest contract, you get my funds 14:41 < Psztorc> It would seem that, instead _you_ get _my_ funds. 14:42 < Psztorc> I don't understand what knowledge is imparted to miners, which is different if one of us broadcasts seq1 or the other. 14:42 < roasbeef> No, when I broadcast my version of the revoked sequence 1, you have the pre-image I gave you for that state, so you can take the funds 14:42 < roasbeef> the two transactions are different 14:42 < roasbeef> I have a version, and you have a version 14:42 < roasbeef> there are always two versions of the state 14:42 < Psztorc> I see, so we don't update a single 2of2 transaction. 14:43 < roasbeef> my version has: pay your balance to you immediately, and pay my balance to me after a delay, before that delay you can use the pre-image to claim if you know it 14:43 < Psztorc> We update two completely different 2of2 transactions which happen to have the same accounting. 14:43 < roasbeef> yeah the fudning transaction is never updated, it's in the chain 14:43 < roasbeef> what's updated is the transaction _spending_ from that 2-of-2 output 14:43 < Psztorc> I know I know I don't care about the funding transaction. 14:44 < Psztorc> I think I understand now. 14:44 < roasbeef> yep, they functionally the same, but are different w.r.t to the outputs in order to ascribe blame 14:44 < roasbeef> nice! 14:44 < Psztorc> Thank you! 14:44 < roasbeef> no problem :) 14:44 < Psztorc> Strange I groked LN very very quickly but never crossed my mind that there are redundant transactions. 14:45 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev 14:45 < Psztorc> If we agree to close the channel, we converge to one transaction? 14:46 < Psztorc> For a grand total of 2 transactions, including the funding transaction? Or three? 14:47 < roasbeef> Yeah, if we agree to close, then we create one transaction that divvies out our balances to the agreed upon "delivery" addresses. That hits the chain and our agreement is complete 14:47 < roasbeef> Or, I can say "hey i'm closing this, but opening another one with someone else", and we can get that done in 1 txn instead of two 14:48 < roasbeef> at that point, two including the funding transaction 14:48 < Psztorc> A grand total of 1 + N transactions, assuming perfect agreement, where N is the total number of rollovers. 14:48 < roasbeef> those two are the only ones that ever hit the chain 14:49 < roasbeef> by rollover do you mean update? 14:50 < roasbeef> N transactions that have never existed since we entered the contract? it would be 2N + 1, each update results in two new transactions (my version, your version) 14:50 < Psztorc> No, I mean close a channel while opening one. 14:50 < Psztorc> That appear on chain. 14:51 < roasbeef> Ah, yeah that sounds right. Where "rollover", can either be me adding more funds to the channel, or closing my channel with you and opening with another party 14:54 < Psztorc> Ok, thanks again! 14:57 < roasbeef> No problem! Now it's time for some good ol' football :) 15:12 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 15:59 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt] 16:05 -!- jouke [~jouke@unaffiliated/komkommer] has quit [Ping timeout: 256 seconds] 16:07 -!- jouke [~jouke@a83-163-42-163.adsl.xs4all.nl] has joined #lightning-dev 16:55 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev 16:56 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit] 17:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 17:48 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-axcjrqwpegejyucb] has quit [Quit: Connection closed for inactivity] 17:59 < aj> rusty: hey, https://www.youtube.com/watch?v=dIageYT0Vgg is probably interesting (rust community automation) 18:15 < rusty> aj: thanks, will watch! 18:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev [] 18:31 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:31 -!- roidster [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]] 18:45 -!- Guest1585 [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has joined #lightning-dev 18:46 -!- Guest1585 is now known as roidster 19:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 19:46 -!- NewLiberty_ [~NewLibert@107-142-8-22.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 276 seconds] 19:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 248 seconds] 20:49 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 245 seconds] 21:53 -!- NewLiberty_ [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has joined #lightning-dev 23:06 -!- Psztorc [~Psztorc@ool-4575fa8d.dyn.optonline.net] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 23:36 -!- NewLiberty_ [~NewLibert@2602:306:b8e0:8160:b8e2:1c9c:fe32:8ba2] has quit [Ping timeout: 260 seconds] 23:43 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nygtowczsdnvwwnk] has joined #lightning-dev