--- Day changed Thu Jun 30 2016
00:20 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
00:46 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
01:21 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
01:22 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
01:28 -!- p15 [~p15@168.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 250 seconds]
01:33 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]
01:34 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #lightning-dev
01:50 -!- p15 [~p15@193.138.228.32] has joined #lightning-dev
02:04 -!- roasbeef_ [~root@104.131.26.124] has joined #lightning-dev
02:05 -!- aj_ [aj@cerulean.erisian.com.au] has joined #lightning-dev
02:08 -!- Netsplit *.net <-> *.split quits: aj, roasbeef, whphhg, luke-jr
02:08 -!- Netsplit over, joins: luke-jr
02:10 -!- whphhg [whphhg@gateway/vpn/mullvad/x-lasdmhsjpgkxasgv] has joined #lightning-dev
02:32 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 260 seconds]
02:37 -!- afk11 [~afk11@109.255.154.81] has joined #lightning-dev
02:37 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
02:37 -!- afk11 [~afk11@unaffiliated/afk11] has joined #lightning-dev
02:51 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
02:59 -!- MaxSan_ [~one@h88-150-240-8.host.redstation.co.uk] has quit [Ping timeout: 264 seconds]
03:15 -!- MaxSan_ [~one@185.103.96.139] has joined #lightning-dev
03:29 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 276 seconds]
03:37 -!- afk11 [~afk11@109.255.154.81] has joined #lightning-dev
03:37 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
03:37 -!- afk11 [~afk11@unaffiliated/afk11] has joined #lightning-dev
03:59 -!- MaxSan_ [~one@185.103.96.139] has quit [Ping timeout: 276 seconds]
04:06 -!- MaxSan_ [~one@91.214.169.69] has joined #lightning-dev
04:10 -!- giuseppegalano [~giuseppeg@151.73.104.83] has joined #lightning-dev
04:22 -!- giuseppe_ [~giuseppeg@151.73.104.83] has joined #lightning-dev
04:22 -!- giuseppegalano [~giuseppeg@151.73.104.83] has quit [Read error: Connection reset by peer]
04:25 -!- giuseppe_ [~giuseppeg@151.73.104.83] has quit [Remote host closed the connection]
04:50 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
04:57 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 244 seconds]
05:55 -!- p15 [~p15@193.138.228.32] has quit [Ping timeout: 260 seconds]
07:22 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev
08:10 -!- MaxSan_ [~one@91.214.169.69] has quit [Ping timeout: 240 seconds]
08:30 -!- MaxSan_ [~one@www17.redstation.co.uk] has joined #lightning-dev
08:31 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
08:35 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev
08:37 -!- wraithm [~textual@205.197.160.100] has quit [Client Quit]
08:38 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev
08:40 -!- wraithm [~textual@205.197.160.100] has quit [Client Quit]
08:41 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev
09:09 -!- jtimon [~quassel@LAubervilliers-656-1-271-230.w193-248.abo.wanadoo.fr] has joined #lightning-dev
09:20 -!- jtimon [~quassel@LAubervilliers-656-1-271-230.w193-248.abo.wanadoo.fr] has quit [Remote host closed the connection]
09:48 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds]
09:53 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #lightning-dev
10:27 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
10:39 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds]
10:45 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #lightning-dev
10:57 -!- roasbeef_ is now known as roasbeef
11:29 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev
11:30 -!- MaxSan_1 [~one@185.103.96.151] has joined #lightning-dev
11:32 -!- MaxSan_ [~one@www17.redstation.co.uk] has quit [Ping timeout: 272 seconds]
11:33 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 250 seconds]
11:56 -!- jtimon [~quassel@2a01cb0407fe74008c885ec7d8adc95c.ipv6.abo.wanadoo.fr] has joined #lightning-dev
12:24 -!- laurentmt [~Thunderbi@LCaen-656-1-123-117.w80-13.abo.wanadoo.fr] has joined #lightning-dev
12:33 -!- laurentmt [~Thunderbi@LCaen-656-1-123-117.w80-13.abo.wanadoo.fr] has quit [Quit: laurentmt]
13:04 -!- giuseppegalano [~giuseppeg@151.73.104.83] has joined #lightning-dev
13:04 -!- giuseppegalano [~giuseppeg@151.73.104.83] has quit [Remote host closed the connection]
13:55 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #lightning-dev
13:58 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
14:16 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev
14:18 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:20 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
14:26 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
14:26 -!- wraithm [~textual@205.197.160.100] has joined #lightning-dev
14:36 -!- jtimon [~quassel@2a01cb0407fe74008c885ec7d8adc95c.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 260 seconds]
14:43 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
14:45 -!- Netsplit *.net <-> *.split quits: Taek
14:59 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has quit [Ping timeout: 252 seconds]
15:01 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has joined #lightning-dev
15:12 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 244 seconds]
15:12 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 276 seconds]
15:20 -!- afk11 [~afk11@109.255.154.81] has joined #lightning-dev
15:20 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
15:20 -!- afk11 [~afk11@unaffiliated/afk11] has joined #lightning-dev
15:22 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
--- Log closed Thu Jun 30 16:00:49 2016
--- Log opened Thu Jun 30 16:32:04 2016
16:32 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #lightning-dev
16:32 -!- Irssi: #lightning-dev: Total of 60 nicks [0 ops, 0 halfops, 0 voices, 60 normal]
16:37 -!- ybit [~ybit@unaffiliated/ybit] has quit [Ping timeout: 250 seconds]
--- Log closed Thu Jun 30 16:42:16 2016
--- Log opened Thu Jun 30 16:42:57 2016
16:42 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #lightning-dev
16:42 -!- Irssi: #lightning-dev: Total of 60 nicks [0 ops, 0 halfops, 0 voices, 60 normal]
16:44 -!- ybit [~ybit@unaffiliated/ybit] has quit [Ping timeout: 276 seconds]
16:45 -!- ybit [~ybit@unaffiliated/ybit] has joined #lightning-dev
--- Log closed Thu Jun 30 16:50:53 2016
--- Log opened Thu Jun 30 16:51:58 2016
16:51 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #lightning-dev
16:51 -!- Irssi: #lightning-dev: Total of 59 nicks [0 ops, 0 halfops, 0 voices, 59 normal]
16:52 -!- ybit [~ybit@unaffiliated/ybit] has joined #lightning-dev
17:01 -!- ybit [~ybit@unaffiliated/ybit] has quit [Ping timeout: 260 seconds]
17:01 -!- ybit [~ybit@unaffiliated/ybit] has joined #lightning-dev
17:05 -!- molz [~molly@unaffiliated/molly] has joined #lightning-dev
17:08 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
17:13 -!- Irssi: Join to #lightning-dev was synced in 1378 secs
17:16 -!- wraithm [~textual@205.197.160.100] has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
17:29 -!- MaxSan_1 [~one@185.103.96.151] has quit [Ping timeout: 260 seconds]
17:45 -!- MaxSan_ [~one@www17.redstation.co.uk] has joined #lightning-dev
18:35 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hnvatvcgrfuscujh] has quit [Quit: Connection closed for inactivity]
18:36 -!- Taek [~quassel@ks36119.kimsufi.com] has joined #lightning-dev
18:40 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:44 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
19:34 -githubby:#lightning-dev- [lightning] rustyrussell pushed 62 new commits to master: https://git.io/vohSS
19:34 -githubby:#lightning-dev- lightning/master 9046597 Rusty Russell: daemon: tighten check for invalid IDs....
19:34 -githubby:#lightning-dev- lightning/master b820f5a Rusty Russell: Makefile: fix submodule....
19:34 -githubby:#lightning-dev- lightning/master 43db903 Rusty Russell: daemon: fix case where commit has nothing to do....
20:14 -!- rusty2 is now known as rusty
21:00 < roasbeef> rusty: are you considering switching c-lightning's p2p encryption to use BIP 151? 
21:00 < rusty> roasbeef: yeah... but it won't be precisely the same.
21:01 < rusty> roasbeef: was just looking at it now.
21:01 < rusty> roasbeef: I mean, we kind of need authentication.
21:02 < rusty> roasbeef: but hey, stealing other people's crypto makes sense.  That's why I'm nitpicking 151.
21:02 < rusty> roasbeef: We could just insist the first message be encinit, the second be auth.
21:03 < rusty> roasbeef: what are your thoughts?
21:03 < roasbeef> I was considering switch to lnd to use a particular handshak from the noise framework: noiseprotocol.org/noise.html
21:04 < roasbeef> pariticularly the Noise_XK handshake 
21:04 < roasbeef> it provides a degree of identity hiding, meaning if the initiator doesn't know the responder's static public key then the communication is terminated 
21:04 < roasbeef> the auth is based purely off of ECDH, AEAD ciphers are used by default
21:05 < roasbeef> if either side can't decrypt a payload during the initial handshake, then auth has failed 
21:06 < roasbeef> trevor also gave a talk at stanford a few months back: https://noiseprotocol.org/docs/noise_stanford_seminar_2016.pdf
21:07 < roasbeef> so in a nut shell, noise is authentiated key agreement that doesn't rely on signatures. security is based mostly on the constructed HKDF: https://tools.ietf.org/html/rfc5869 + https://eprint.iacr.org/2010/264.pdf
21:07 < gmaxwell> rusty: there will be a seperate bip for authentication. BIP151 is designed to hook into it.
21:07 < rusty> gmaxwell: yeah, I read an early draft of that.
21:08 < roasbeef> rusty: also I should have an ML post up by this weekend but during a white board session with joseph, we re-designed the commitment update protocol a bit
21:09 < gmaxwell> roasbeef: the auth for BIP151 (well after on of my revisions) was responder identity private.
21:09 < roasbeef> it's similar to the comitment update protocol you've implemented, but allows multiple outstanding unrevoked commitments by both side 
21:09 < roasbeef> s
21:09 < rusty> roasbeef: my draft does allow that, my implementation does not.
21:10 < rusty> roasbeef: (as in, it won't do it, but the other side could)
21:10 < roasbeef> ahh gotcha, I haven't read the draft too closeley 
21:11 < gmaxwell> (initator sends H(session_id||expected_responder_pubkey)  to the responder)
21:11 < rusty> roasbeef: yeah, the draft is kinda a mess.  It describes the protocol in terms of queues of changes, but it's actually much nicer to implement as htlc states.  They're isomorphic...
21:11 < roasbeef> I've adopted the terminology of "commitment chains" in my head to describe an LN transcript. so there's essentially a local+remote commitment chain, and then local+remote HTLC logs, new commitments index into the log marking up to what they've included
21:12 < roasbeef> when you get a new sig, you essentially create a "commitment view" which tells which HTLC's you've included. it lends well to a binlog-like system for keeping the state on-disk
21:12 < roasbeef> gmaxwell: I see, do you have a link to the latest draft handy?
21:13 < roasbeef> "was" so isn't anymore?
21:13 < rusty> roasbeef: assuming in-order inclusion, so it boils down to a counter, right?
21:14 < roasbeef> yeah assumes in-order inclusion, both sides have a "counter" (though I think of it as a log-index)
21:14 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds]
21:14 < gmaxwell> no current BIP for it, but the kind of design I was suggesting for auth is http://people.xiph.org/~greg/auth0.txt  .. in general I prefer a design where authenticated encrypion is totally seperate from authentication, because authentication is highly application specific... (also oppturnistic encryption is valuable even when authentication isn't possible)
21:15 < roasbeef> in the current version we banged out, before starting state updates, both sides send out a "revocation window" of length N, N determins how many un-revoked commitments are allowed
21:15 < rusty> roasbeef: you don't need that, AFAICT.
21:16 < roasbeef> the look ahead? 
21:16 < roasbeef> it's kinda like flow-control
21:16 < rusty> roasbeef: Why would you need that?
21:17 < roasbeef> allows a greater degree of de-synchronization, I can send multiple sigs adding new links to your commitment chain without waiting for you to respond to the initial sig with a sig+revocation 
21:17 < rusty> We use a model where you propose changes (add/fulfill/fail) to the other side.  Then a commit (which has the sig of their commit tx with all those changes), which they respond with an ack including the previous tx's revocation preimage.
21:17 < rusty> The ack also implies "add those same changes to your own commit tx" when you receive it.
21:17 < rusty> AFAICT that's the minimal design.
21:18 < rusty> You can have as many of those as you want outstanding, I simply process them one at a time.
21:18 < roasbeef> so each sig only covers a HTLC update?
21:18 < roasbeef> a single* 
21:18 < rusty> roasbeef: no, the whole batch.
21:18 < rusty> roasbeef: eg. ADD ADD FULFILL FAIL COMMIT.
21:19 < rusty> You can only fail/fulfill HTLCs originally offered by the other side, so there's no actual need for synchronization.
21:19 -!- afk11 [~afk11@109.255.154.81] has joined #lightning-dev
21:19 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host]
21:19 -!- afk11 [~afk11@unaffiliated/afk11] has joined #lightning-dev
21:21 < roasbeef> rusty: the "ack" isn't preceeded by a new signature to the other side over your new commit tx (with the changes)?
21:21 < rusty> roasbeef: nope, the two sides are decoupled.
21:23 < rusty> roasbeef: ie. you send ADD-HTLC#1.  Now I have HTLC#1 pending.
21:23 < rusty> You send  COMMIT(sig-for-rusty's-commit-tx-with-HTLC#1-added).
21:23 < rusty> I send ACK(revocation for rusty's previous commit tx).  Now you have HTLC #1 pending.
21:23 < rusty> I send COMMIT(sig-for-roasbeed's-comit-tx-with-HTLC#1-added).
21:24 < rusty> You send ACK(revocation fir roasbeef's previous commit tx).
21:24 < rusty> Of course, I could also add my own changes in there  for you before I COMMIT.
21:25 < rusty> Then my commit would cover those, too, and your ack would make them pending for me, and I'd COMMIT again.
21:28 < roasbeef> hmmm sounds similar although we send sig before revoke 
21:29 < roasbeef> do your revokes include the revoke hash to be used for the next commit txn the remote side constructs for you
21:29 < roasbeef> ?
21:29 < roasbeef> or "adds to your commit chain" (using my preffered terminology :) )
21:31 < rusty> Yep!
21:33 < rusty> Oh, and we discard all uncommitted updates on reconnect.  This saves us having to commit them to disk (we still have to sync when we send/receive an update or a revocation of course).
21:33 < roasbeef> also instead of revocation hashes for commitment transactions, we use revocation keys now derived via a P2CH-like derivation based on the revocation pre-image. ended up makings the scripts smaller, and only requiring a single check-sig in either case
21:34 < roasbeef> yeh sounds similar although we allow multiple un-revoked commitments, it complicates the HTLC book-keeping a bit but decouples the transcripts even further
21:34 < rusty> roasbeef: oh, cute!
21:35 < rusty> roasbeef: what does it gain, however?  If you don't add a sig when you send a revoke you get the same deal, without complexity AFAICT.
21:38 < roasbeef> but if you don't add a sig, then the remote node doesn't gain a broadcastable commitment tx immediately, I'd have to wait for you to catch up 
21:38 < rusty> roasbeef: hmm, are you still using hash preimages for the HTLC R values?  Otherwise you still need the hash compare case AFAICT...
21:38 < rusty> roasbeef: no, just send your own commit msg.
21:38 < roasbeef> yeh hash preimages for HTLC's still 
21:39 < roasbeef> the initiator of the new state transition send a new commit msg?
21:40 < rusty> roasbeef: not that clear, there may be multiple transitions going on.  But both schemes require 1 1/2 round trips for both sides to be completely committed, which is optimal, so I would say simplicity wins.
21:42 < rusty> It's also nice because if a fancy implementation wants to do multiple commits in flight without waiting for my acks, it doesn't effect me at all.
21:44 < roasbeef> how can they do multiple commits in flight if they don't have revocation hashes from you for the new commits they're creating in your chain? 
21:45 < rusty> roasbeef: the same way they do a single commit in flight before they've received the revocation hash?
21:45 < roasbeef> yeah 1.5 RTT's to "slide" the chain down by one
21:45 < roasbeef> or err up I guess :p 
21:46 < rusty> roasbeef: hmm, chains hang down, so I think down is the correct nomenclature?  Blocks stack up...
21:46 < roasbeef> but we speak of block height in bitcoin :) 
21:47 < rusty> roasbeef: it also turns out you don't need any id numbers / counters over the wire (except for the reconnect case). You can even number HTLCs sequentially if you want, and make HTLC ids implicit (I didn't though)
21:47 < roasbeef> i don't follow though, how can I create multiple commitment updates for you without you responding first with revocation hashes for me
21:47 < rusty> roasbeef: ah, erm, good point :)
21:47 < rusty> roasbeef: I can add changes, but not commit.
21:48 < roasbeef> yeah so both sides have an "HTLC Log" essentially, our numbering is just monotonically increasing like indexes in a log
21:48 < roasbeef> gotcha yeah that's why we send an "initial revocation window" on connection, or after the channel is open if one not already established 
21:49 < rusty> roasbeef: I think we're better adding an UNADD command, and keeping commitments one-at-a-time.
21:49 < roasbeef> unadd? 
21:49 < roasbeef> as in like a rollback?
21:49 < rusty> roasbeef: not really, just cancels a previous (uncommitted!) ADD HTLC.
21:50 < roasbeef> gotcha
21:50 < rusty> roasbeef: if you also add an advisory "I'm going to fail this HTLC once you commit, BTW" message, it allows HTLCs to fail faster.
21:50 < rusty> roasbeef: because you can add them to the next hop before it's committed to you.
21:51 < rusty> roasbeef: and if I want to commit the next hop before confirmed, I can simply UNADD, commit.
21:51 < rusty> roasbeef: doesn't help speed up the success case, of course.
21:51 < rusty> roasbeef: and I'm avoiding it in the current spec because we have enough toys so far :)
21:52 -!- roidster [~chatzilla@71-95-217-105.static.mtpk.ca.charter.com] has joined #lightning-dev
21:52 -!- roidster is now known as Guest27612
21:52 -!- p15 [~p15@193.138.228.13] has joined #lightning-dev
21:52 -!- Guest27612 is now known as roidster
21:59 < roasbeef> rusty: how's the unadd message different from just sending a fail HTLC message as soon as I decide I want to fail the HTLC?
21:59 < rusty> roasbeef: (1) I don't fail my own HTLCs, you do.  (2) You can't do that until I've committed, so there's a window.
22:01 < roasbeef> er yeh I mean fail _your_ HTLC
22:01 < roasbeef> why can't I? I just create a new commit in your chain
22:09 < rusty> Not until it's committed, otherwise the "fail" would be a noop.
22:09 < roasbeef> in my mind, it's "stop and wait" (window size 1) vs a sliding window (of N) where it may be possible for both sides never to stop sending and/or wait 
22:09 < rusty> (Sorry, AFK on hot-chocolate-related emergency.  Back now)
22:10 < rusty> roasbeef: if you can fail something uncommitted, now we have a synchronization problem.
22:10 < rusty> roasbeef: because I can also commit to it.
22:10 < rusty> roasbeef: this keeps things simple.
22:11 < rusty> (And that's why "I'm gonna fail this" is advisory; you have to recv it in time and do UNADD)
22:12 < gmaxwell> That sounds like the best kind of emergency.
22:18 < roasbeef> hmm? I can't fail something uncomitted, I wouldn't recognize it nor forward it before it's committed. once it's in both our chains I foward 
22:19 < roasbeef> or do you allow cut-through? seems like it could happen in that scenario 
22:19 < roasbeef> we disallow cut-through atm FWIW, meaning forwarding before an update is fully comitted 
22:19 < rusty> roasbeef: yeah, you have to do that.
22:19 < roasbeef> mmMMM hot-chocolate :) 
22:19 < rusty> roasbeef: if you have UNADD, you can do cut-through.
22:19 < roasbeef> have to do cut-through? 
22:19 < roasbeef> hmm
22:20 < rusty> roasbeef: (but you can't *commit*)
22:20 < roasbeef> so as soon as I send you an "add" you forward immediatley? 
22:21 < roasbeef> or rather add+sig I guess
22:21 < rusty> roasbeef: No!  Jsut add.
22:21 < rusty> roasbeef: cannot send sig.
22:21 < rusty> roasbeef: if you want to send sig and the incoming HTLC is not commited yet, you have to UNADD.
22:22 < roasbeef> why can't I send a sig immediately after add? 
22:22 < roasbeef> I need to wait for your sig first? 
22:22 < rusty> roasbeef: because then I can drop to blockchain and you are committed to an HTLC you don't have an upstream commitment for.
22:23 < rusty> roasbeef: you can queue the change before you have upstream commitment, but not commit to it.
22:23 < rusty> roasbeef: which is only useful if the HTLC routing is going to fail.
22:26 < roasbeef> but in this case, A -> B .. (other stuffs), if I A does add+sig, then B has the new commitment in their chain. B can broadcast, but that would be foolish, in either case A sweeps after the timeout 
22:27 < roasbeef> (this assumes A is able to add+sig without any interaction from Bob) 
22:30 < rusty> roasbeef: A -> B -> C.  B has HTLC-X in its commitment with A, A doesn't have HTLC-X.   B sends HTLC-X to C anyway, plus sig.  C and A drop their commitment txs to the blockchain.  C then redeems the HTLC using preimage(X). 
22:30 < rusty> roasbeef: ?
22:36 < roasbeef> yeh that can happen with cut-thru, we don't allow cut-thru. When B gets the add+sig from A, B immediately sends sig+revoke so A gets the next commit in their chain 
22:36 < roasbeef> cut-thru seems dangerous
22:36 < rusty> Yes, exactly.
22:37 < rusty> roasbeef: But you B can still queue a pending change to C, as long as it can undo it ebfore commit if it has to.
22:38 < rusty> roasbeef: And even with your model, B still requires another packet from A to get their previous commit revocation, otherwise A can still pull the same trick.
22:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lmtosqfecaezoaiz] has joined #lightning-dev
22:43 < roasbeef> only if you allow cut-thru though
22:43 < rusty> roasbeef: no, I'm saying if B doesn't wait for the response from A, it *is* doing cutthrough and it *is* broken.
22:45 < roasbeef> yeh B waits to get revoke before he forwards. but hea's also able to update A's chain with updates coming from the other direction 
22:46 < rusty> Sure...
22:47 < roasbeef> if he has an available revoation window from A
22:48 < rusty> roasbeef: even without that B can add changes, just can't send sig.
22:50 < roasbeef> permitting the sig allows B to progress the workflow though
22:51 < rusty> roasbeef: yeah, but it's not entirely clear to me that latency gets significantly better.
22:52 < roasbeef> but as I said, it does complicate book-keeping since you need to track the add/remove heights of the HTLC's w.r.t both chains
22:52 < rusty> roasbeef: yeah, and bookkeepign already scares me for this stuff.
22:53 < roasbeef> latency: prob not, but this targets bi-directional throughput
22:53 < roasbeef> hehe :) 
22:53 < roasbeef> do you allow multiple open channels with a single peer atm?
22:53 < rusty> roasbeef: well, throughput isn't effected, it's just the commit delayed.
22:54 < rusty> roasbeef: no.  Well, I could, but it'd get weird.
22:55 < roasbeef> why would it get weird? w.r.t to the way your code is architected atm, or something else? 
22:55 < rusty> roasbeef: well, it would be two separate comms pipes between the peers, and routing would always pick the first-established one, for example.
22:55 < roasbeef> we track channels by "ChannelPoint" atm, or just the outpoint of the funding tx
22:56 < rusty> roasbeef: ah, I just route by peerkey.
23:48 -!- roidster [~chatzilla@71-95-217-105.static.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]]