--- Log opened Thu Jul 08 00:00:00 2021
00:32 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
00:43 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 252 seconds]
00:47 -!- gioyik [~gioyik@gateway/tor-sasl/gioyik] has quit [Quit: WeeChat 3.1]
01:04 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Ping timeout: 252 seconds]
01:46 -!- cdecker6 [~cdecker@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
01:50 -!- cdecker [~cdecker@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 272 seconds]
01:50 -!- cdecker6 is now known as cdecker
02:16 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
02:45 -!- aechu [~major@gateway/tor-sasl/major] has joined #lightning-dev
03:03 < fiatjaf> _aj_: 
03:03 < fiatjaf> `cltv_expiry_delta` needs to take the `to_self_delay` into account
03:03 < fiatjaf> I don't follow why that's the case though
03:06 < _aj_> fiatjaf: suppose you're sending an HTLC across 4 channels A->B B->C C->D D->E ; each of those channels happen to not be very actively maintained so there's a one week "to_self_delay" on each of them, so everyone has plenty of time to sync up the block chain and do justice txs or eltoo-newer-state txs if there's a problem
03:07 < fiatjaf> ok
03:07 < _aj_> fiatjaf: if your tx has a 4h (or, more generally, less than 4 weeks) locktime, what happens?
03:08 < _aj_> fiatjaf: without layered commitments, the C->D channel gets closed, then it takes a week to actually be able to claim the HTLC by which time the timeout is passed, so even if Dave knows the preimage, he's out of luck because Carol can reclaim the funds
03:08 < fiatjaf> you broadcast the update transaction
03:08 < fiatjaf> oh
03:09 < fiatjaf> why? I thought you could broadcast the settlement transaction, and the HTLC is an output from that, no?
03:09 < _aj_> fiatjaf: with layered commitments, as soon as the C->D state gets dropped to the chain, Dave can reveal the HTLC preimage, at which point Carol can only get the funds if she can do a justic tx (or eltoo newer-state update)
03:09 < fiatjaf> nevermind, I get it, you can't broadcast the settlement transaction
03:09 < fiatjaf> what do you mean by "state"?
03:09 < fiatjaf> update transaction or settlement transaction? (I think these are the terms used in the eltoo paper)
03:09 < _aj_> update transaction
03:10 < _aj_> with layered commitments, the update+settlement txs are effectively combined i think
03:10 < fiatjaf> but how?
03:10 < _aj_> that's what the email describes?
03:10 < fiatjaf> you have a script in there with everything mixed?
03:10 < fiatjaf> haha
03:10 < fiatjaf> ok, I'll try again
03:10 < fiatjaf> to read the email
03:11 < _aj_> iirc, the initial "hey let's close the channel to state X" looks like a 1-input n-output
03:11 < _aj_> you can then claim any of the n-2 HTLC outputs by revealing a preimage or demonstrating the locktime has passed, but can't *actually* take the funds for any of the n outputs until the "1 week" is up
03:11 < _aj_> so there's n UTXOs sitting in the utxo db
03:13 < _aj_> so if you want to go from state X to X+Y, you then have an n-input m-output tx that spends all the n outputs, including the ones that were claimed by revealing a HTLC preimage/etc, and creating m new outputs for state X+Y, and you can then claim any of those HTLCs where the preimage is known, etc
03:19 < fiatjaf> ok, I'm trying but I can't even ask questions at this point
03:21 < _aj_> state X=100 is [Carol: 5000 sat, Dave: 6000 sat, HTLC(2000sat, hash, time, C->D), HTLC(1000sat, hash2, time2, D->C)] say
03:22 < _aj_> so to unilaterally close to that with eltoo layered commitment as i proposed (if i'm remembering it right), you post a tx with 1-input, ie the channel funding tx from way back when, right?
03:22 < fiatjaf> right, but then state Y=101 is [Carol: 5000 sat, Dave: 9000 sat], how do we make state Z=102? does it spend two outputs from Y or 4 outputs from X?
03:23 < fiatjaf> _aj_: right
03:23 < _aj_> and there's immediately 4 outputs: Carol, Dave, and the two HTLCs. None of those can be 100% claimed for another week yet. But the layered commitment says that Dave should be able to reserve the 2000 sat output immediately if he knows the preimage for "hash" to prevent Carol from claiming it in case "time" will have passed before the 1 week does
03:24 < fiatjaf> where do you post the preimages though?
03:24 < _aj_> so Dave reveals the preimage for hash and semi-claims that output immeditely
03:24 < fiatjaf> you edit the presigned transaction to add the preimages? can you do that with anyprevout?
03:24 < _aj_> so 1-input, 1-output, so there's still 4 utxos with values 5000 6000 2000 1000, but the 2000 one is going to Dave or to state 101 or 102 etc
03:25 < _aj_> so suppose Carol has state 102
03:25 < _aj_> and state 102 is [Carol: 8000, Dave: 6000] for simplicity
03:26 < _aj_> so Carol makes a 4-input, 2-output tx, claiming each of the 5000, 6000, 2000, 1000 outputs, and creating 8000 and 6000 outputs
03:26 < _aj_> those outputs have a new relative time lock of a week probably (at least in general if there's more than 2 parties in the eltoo channel)
03:27 < _aj_> but eventually the week passes, and Carol and Dave claim their balances and all is good
03:27 < fiatjaf> ok, but doesn't Carol have to have that tx beforehand? signed by Dave?
03:27 < _aj_> she needs the _signature_ beforehand
03:27 < fiatjaf> no way, this is magic
03:27 < _aj_> but with ANYPREVOUTANYSCRIPT a single signature can sign all those utxos to a single new output despite them having different values
03:28 < _aj_> (where the magic fails is being able to include fees in any of this)
03:28 < fiatjaf> but you can still include fees with anyonecanpay|single, right?
03:29 < fiatjaf> ok, so Dave signs _once_?
03:29 < _aj_> for 1-in 1-out SINGLE works great -- so when Dave's revealing the preimage that works
03:29 < fiatjaf> and then Carol can use Dave's signature for anything?
03:29 < _aj_> Dave signs once per state, and Carol keeps the signature for the most recent state
03:29 < _aj_> and that signature's valid for any prior state
03:31 < fiatjaf> I still don't get where did Dave reveal the preimage
03:31 < _aj_> well, needs a signature for each active HTLC as well, and it might be like 3 rather than 1)
03:31 < fiatjaf> also why can't Carol, having Dave's signature that is valid for anything, rewrite Dave's output to her
03:32 < _aj_> Dave posted state 100, [input: funding tx; output: carol_100, dave_100, htlc1_100, htlc2_100]
03:32 < _aj_> Dave then revealed the preimage for htlc1, by posting a tx: [input: htlc1_100, output: htlc1_100_for_dave]
03:33 < _aj_> Carol has a signature that's ANYPREVOUTANYSCRIPT | ALL so it's only valid for the outputs corresponding to state 102
03:34 -!- RubenSomsen [sid301948@user/rubensomsen] has joined #lightning-dev
03:35 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Ping timeout: 272 seconds]
03:39 < fiatjaf> ok, I think I get it
03:39 < fiatjaf> maybe
03:41 < fiatjaf> but what if Carol has state 102 but Dave publishes state 100 + the HTLC he had in there?
03:42 < fiatjaf> that means each state needs to know how to spend each previous HTLC ever created in the channel
03:42 < _aj_> Carol's tx is either [input: carol_100, dave_100, htlc1_100, htlc2_100, output: carol_102, dave_102] _or_ [input: _, _, htlc1_100_for_dave, _; output: _, _]   (_ = same)
03:42 < _aj_> yes, it doesn't work with HTLCs, only PTLCs
03:42 < _aj_> well it works with HTLCs, but you have to remember every HTLC
03:43 < fiatjaf> ok, I see this is mentioned in the email
03:43 < fiatjaf> how is it different with PTLCs? I don't follow
03:44 < fiatjaf> PTLCs aren't each their own transaction that spends from the state also?
03:45 < _aj_> with PTLCs you reveal the preimage via a signature that you negotiate out of band, you don't need to encode the point/hash into the scriptPubKey
03:45 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
03:49 < fiatjaf> thank you very much
03:49 < _aj_> no worries; glad i'd refreshed on this earlier today...
04:18 < _aj_> rusty: fyi https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
04:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:38 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.]
04:38 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
04:54 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 258 seconds]
05:33 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
06:06 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Ping timeout: 268 seconds]
08:33 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
08:44 -!- gioyik [~gioyik@gateway/tor-sasl/gioyik] has joined #lightning-dev
09:07 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Ping timeout: 252 seconds]
10:04 -!- ryanthegentry [~ryanthege@2605:a601:ab05:f800:8847:b0f7:baea:de97] has quit [Quit: Client closed]
10:07 -!- VzxPLnHqr_ [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has joined #lightning-dev
10:08 -!- VzxPLnHqr [VzxPLnHqr@gateway/vpn/protonvpn/vzxplnhqr] has quit [Ping timeout: 252 seconds]
10:42 -!- roasbeef [~roasbeef@172.92.21.52] has joined #lightning-dev
10:53 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
12:31 -!- stonefox [~stonefox@user/stonefox] has quit [Quit: The Lounge - https://thelounge.chat]
12:32 -!- stonefox [~stonefox@user/stonefox] has joined #lightning-dev
12:42 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Remote host closed the connection]
12:51 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
12:51 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 244 seconds]
13:17 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
13:39 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 244 seconds]
13:40 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
13:46 -!- nathanael [~nathanael@user/nathanael] has quit [Excess Flood]
13:46 -!- nathanael [~nathanael@user/nathanael] has joined #lightning-dev
13:47 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Ping timeout: 252 seconds]
13:55 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has quit [Ping timeout: 268 seconds]
13:55 -!- BlueMatt [~BlueMatt@ircb.bluematt.me] has joined #lightning-dev
14:05 -!- valwal [~valwal@96.224.58.144] has quit [Ping timeout: 240 seconds]
14:05 -!- dongcarl [~dongcarl@96.224.58.144] has quit [Ping timeout: 272 seconds]
14:11 -!- roasbeef [~roasbeef@172.92.21.52] has quit [Remote host closed the connection]
14:24 -!- roasbeef [~roasbeef@172.92.21.52] has joined #lightning-dev
15:29 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
15:29 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 244 seconds]
15:34 -!- dongcarl [~dongcarl@96.224.58.144] has joined #lightning-dev
15:45 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
16:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
16:25 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 244 seconds]
16:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
16:58 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Remote host closed the connection]
17:22 -!- reallll [~belcher@user/belcher] has joined #lightning-dev
17:25 -!- belcher_ [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:41 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
17:55 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Ping timeout: 255 seconds]
19:19 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
19:49 -!- AaronvanW [~AaronvanW@45.161.24.65] has quit [Ping timeout: 252 seconds]
20:04 -!- rusty [~rusty@203.221.41.134] has joined #lightning-dev
20:08 -!- Enki[m] [~enkimatri@2001:470:69fc:105::382c] has joined #lightning-dev
21:59 -!- roasbeef [~roasbeef@172.92.21.52] has quit [Remote host closed the connection]
22:46 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 265 seconds]
22:50 -!- gioyik [~gioyik@gateway/tor-sasl/gioyik] has quit [Quit: WeeChat 3.1]
23:36 -!- reallll is now known as belcher
23:37 -!- AaronvanW [~AaronvanW@45.161.24.65] has joined #lightning-dev
--- Log closed Fri Jul 09 00:00:01 2021