--- Log opened Fri Jun 26 00:00:01 2020 00:00 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev 00:38 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection] 00:59 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 01:08 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 01:09 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-56-253.adslplus.ch] has joined #lightning-dev 01:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 01:35 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 01:43 < lndbot> Hi, is an `update_fulfill_htlc` message is sent before or after a `commitment_signed` message? 01:44 < zmnscpxj_> Depends on how you view things, but you *might* say it is "before" the `commitment_signed` that includes the update 01:45 < zmnscpxj_> so, assuming no other updates at all, you could say if A is doing the fulfilling 01:46 < lndbot> thanks, i have a few more questions about the details of HTLCs. here in this figure, there are 3 `update_add_htlc` messages. Why? 01:46 < zmnscpxj_> A->update_fulfill_htlc->B, A<-commitment_signed<-B, A->commitment_signed->B, A->revoke_and_ack->B, A<-revoke_and_Ack<-B 01:47 < zmnscpxj_> sorry, from IRC, cannot see figures 01:47 < zmnscpxj_> can you link? 01:47 < lndbot> okay 1 sec 01:47 < lndbot> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#normal-operation 01:48 < zmnscpxj_> that is an example 01:48 < lndbot> https://lightningcommunity.slack.com/archives/C6CNQDH3R/p1593161214336800 got it 01:48 < zmnscpxj_> basically, it shows that *any number* of updates can be queued up before anybody even sends a `commitment_signed` 01:48 < lndbot> that makes sense, i thought for a sec that it was part of the protocol 01:49 < lndbot> new question: is an HTLC included in the `update_add_htlc` message? 01:49 < zmnscpxj_> Each `update_add_htlc` *adds* an HTLC, as the name implies 01:49 < zmnscpxj_> so each one provides a new unique HTLC offer 01:50 < lndbot> so the contract itself is included in this message? 01:50 < zmnscpxj_> the direction is from the one making the offer to the one who (might) accepts it 01:50 < zmnscpxj_> contract details 01:50 < zmnscpxj_> i.e. hash, lock time, and onion 01:51 < lndbot> okay contract details, how about the signatures, is an HTLC signed before sending the `update_add_htlc` 01:51 < zmnscpxj_> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#adding-an-htlc-update_add_htlc 01:51 < zmnscpxj_> No, HTLCs are signed with `commitment_signed` 01:51 < zmnscpxj_> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#committing-updates-so-far-commitment_signed has `num_htlcs` 01:51 < lndbot> got it. 01:51 < zmnscpxj_> and `num_htlcs * signature` 01:52 < lndbot> you are being really helpful, would love to learn who I am talking to rn :slightly_smiling_face: 01:52 < zmnscpxj_> Thank you, I am a randomly-generated Internet person, and a human being of indeterminate statistics, and definitely not an AI of some sort 01:53 < lndbot> hahah i mean maybe you wrote the protocol itself if you know this much about it 01:53 < zmnscpxj_> no, the state machine protocol existed before I started participating 01:54 < zmnscpxj_> from the design, it looks like a lot of headache went into it before it stabilized and exists as it is now 01:54 < lndbot> yea maybe i was not that good at understanding the protocol 01:54 < zmnscpxj_> it makes an effort to reduce latency (1.5 roundtrips!), within the constraints of the channel mechanism 01:55 < lndbot> thanks again, i will hit you if I have any more messages 01:55 < zmnscpxj_> I do remember there were differing interpretations of the text in the early days, that is why the "requirements" lists are so long 01:56 < zmnscpxj_> because it turns out "obvious interpretation" is different between different teams LOL 01:56 < lndbot> lol that is why RFC exists now I think 01:56 < lndbot> i mean BOLTs 01:57 < zmnscpxj_> no, I mean even with the RFC, some of the things were implied early on, turns out it was not a good idea to imply 01:57 < zmnscpxj_> like the text "MUST NOT send a `commitment_signed` message that does not include updates", early on some interpretations meant only `update_*_htlc`, others included also `update_fee` 01:57 < lndbot> okay 1 more question 01:58 < zmnscpxj_> That is why the text "MAY send a `commitment_signed` message that only alters the fee" was added 01:58 < lndbot> https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#to_remote-output 01:58 < zmnscpxj_> yes, that is a simple P2WPKH 01:58 < lndbot> here there is `to_remote` output 01:58 < lndbot> then comes the `offered HTLC outputs` 01:59 < zmnscpxj_> ok 01:59 < lndbot> does offered HTLC outputs are a part of `to_remote` output? 01:59 < lndbot> sorry if this is too dumb to ask 01:59 < zmnscpxj_> No 01:59 < zmnscpxj_> Each output is a separate output on the commitment tx 01:59 < lndbot> so there are 4 outputs? 02:00 < zmnscpxj_> variable 02:00 < zmnscpxj_> at the start, there is only one output, the one that goes to the original single funder of the channel 02:00 < zmnscpxj_> an output is created at each `update_add_htlc`, an HTLC output 02:01 < lndbot> hmm 02:01 < lndbot> all these started to make more sense now 02:01 < zmnscpxj_> When HTLCs are fulfilled or failed, the value in that HTLC output is put back to whoever got (fulfilled) or gave (failed case) it 02:01 < zmnscpxj_> and in the long run, usually there are now 2 outputs, one for us (to_local) and one for our counterparty (to_remote) 02:01 -!- laptop [~laptop@212.203.87.198] has joined #lightning-dev 02:03 < lndbot> okay these `offered` and `received` outputs are for second-stage HTLCs? 02:03 < lndbot> second-stage HTLCs are pretty confusing 02:03 < zmnscpxj_> no, these are directly on the commitment txes 02:03 < zmnscpxj_> 2nd-stage HTLC transactions are what spend the on-commitment HTLCs 02:04 < zmnscpxj_> the HTLC is on the commitment 02:04 < zmnscpxj_> the 2nd-stage transaction spends those HTLC outputs 02:04 < zmnscpxj_> because of the need under Poon-Dryja to make sure outputs are revocable 02:05 < zmnscpxj_> You might want to learn about the concept of a "revocable output" first 02:05 < lndbot> okay the HTLCs that are being spent are on the commitment, second-stage HTLCs spend the 1st-stage HTLCs but are still on the commitment TX 02:05 < zmnscpxj_> they are not *on* the commitment tx, they *spend from* the commitment tx HTLC outputs 02:05 < lndbot> revocable outputs are done using timelocks right? i think I know those even if not fully 02:05 < zmnscpxj_> I guess it depends on what you mean by "on" 02:06 < zmnscpxj_> I use the term "on" to mean "this contract/SCRIPT is directly committed to as a P2WSH output of this tx" 02:06 < lndbot> okay then commitment TX only has 1st-stage HTLCs 02:06 < zmnscpxj_> yes, revocable outputs use a relative locktime and providing a privkey 02:07 < zmnscpxj_> yes that is correct 02:07 < lndbot> by privkey i think you mean the revocation private keys? 02:07 < zmnscpxj_> yes, that is the revocation privkey 02:07 < lndbot> okay cool i am getting there 02:07 < zmnscpxj_> :) 02:08 < zmnscpxj_> I believe the original Poon-Dryja paper used hashlocks for the revocation, i.e. reveal preimages, but revealing privkeys turns out to be more efficient and takes up just as much space anyway 02:09 < lndbot> i am working on an interesting idea, where we are trying to add a 3rd signature to control and manage LN channels for devices that cannot run LN (resource constrained devices) to be able to control an LN channel through a gateway 02:09 < zmnscpxj_> that might start to look like my "nodelets" idea 02:09 < zmnscpxj_> just how much trust is the device supposed to take in the "gateway"? 02:10 < lndbot> we want to make the protocol so that IoT does not need to trust the gateway "at all" 02:10 < lndbot> gateway is trying to cheat by all means 02:11 < zmnscpxj_> Can the gateway lie about blockheight? 02:11 < zmnscpxj_> Can the gateway lie about whether a channel has been spent already? 02:11 < lndbot> good question 02:11 < zmnscpxj_> Indeed 02:11 < zmnscpxj_> You might want to discuss about HSMs, with ksedgwic and cdecker 02:11 < zmnscpxj_> which have similar problems 02:12 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-56-253.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 02:12 < lndbot> HSM=? hardware security modules? 02:12 < zmnscpxj_> hardware *signing* modules, yes 02:12 < zmnscpxj_> which is basically your IoT device minus a lot of stuff, reduced only to a signer 02:12 < zmnscpxj_> and maybe a display 02:13 < zmnscpxj_> something like a Trezor or Ledger or KeepKey, but for Lightning 02:13 < zmnscpxj_> The thinking currently is that the HSM stores most of its state in a larger software device 02:13 < lndbot> yes we assume that IoT cannot do anything other than running basic crypto algos. essentially it can go online and sign transactions but not more 02:14 < zmnscpxj_> in an encrypted blob that only the HSM can decrypt 02:14 < zmnscpxj_> so the software device cannot corrupt the HSM state 02:14 < zmnscpxj_> and the HSM does not have to store a lot of data 02:14 < zmnscpxj_> the thinking is that the HSM stores only a single sequence number 02:14 < lndbot> i mean if this can be done using software changes only, that is more preferable. but your points on block height is concerning 02:15 < zmnscpxj_> Yes, that is still the problem with HSMs 02:15 < zmnscpxj_> you still trust the software to respond to onchain events 02:15 < zmnscpxj_> you *could* try to get to watchtowers 02:15 < lndbot> how to check if gateway is really running a full BTC node properly and fully synced. 02:16 < zmnscpxj_> but presumably the software can simulate a watchtower that does not actually watch the chain 02:16 < zmnscpxj_> yes, a lot of things devolve down to "run your own non-eclipsed BTC node" LOL 02:16 < lndbot> that is the point of this research :) to find a solution without having to run your own nodes and stuff 02:17 < zmnscpxj_> It is easy to prove that some blockheight is reached, not so easy to prove "this is the highest blockheight as of this time" 02:17 < lndbot> maybe IoT device have to connect to some legit BTC nodes to learn about the most recent block height 02:17 < zmnscpxj_> so a BTC fullnode just goes around asking "what is the highest blockheight you have?" 02:17 < zmnscpxj_> yes, it looks at minimum you need headers sync at least 02:17 < zmnscpxj_> then there is the other issue 02:18 < zmnscpxj_> can the gateway lie to you about whether anyone has posted old state? 02:18 < lndbot> or maybe get it from some APIs from like btc.com i do not know if they have the API for it but someone should have 02:18 < zmnscpxj_> which starts to make you wonder if you need to do block sysnc as well 02:18 < zmnscpxj_> Hopefully btc.com has a known pubkey 02:19 < lndbot> gateway cannot post a revoked state, since it needs IoT's signature for that 02:19 < zmnscpxj_> no no no 02:19 < lndbot> i forgot to tell you that the channels are 3-of-3 multisig now instead of 2-of-2 02:19 < zmnscpxj_> I mean, what if the counterparty in the channel bribes the watchtower, then *that* counterparty posts old state 02:19 < zmnscpxj_> bribes the gateway I mean 02:19 < zmnscpxj_> 3-of-3 can be easily reduced to 2-of-2 by bribery :) 02:20 < lndbot> you mean the remote LN node that gateway connected to? 02:20 < zmnscpxj_> then the gateway sees the old state but turns a blind eye 02:20 < zmnscpxj_> yes 02:20 < lndbot> i see what you are trying to say 02:20 < lndbot> maybe it can be done like this 02:20 < zmnscpxj_> ") 02:21 < lndbot> if remote LN node wants to broadcast a state, it needs to ask gateway for IoT's signature 02:21 < lndbot> but i doubt remote node will do that lol 02:21 < zmnscpxj_> yes 02:21 < zmnscpxj_> because the entire point of passing around signatures is so that even if one party is offline, everyone can still recover funds 02:21 < zmnscpxj_> what happens if the gateway goes down? 02:21 < lndbot> it may not want to open a channel like this in the first place 02:22 < lndbot> we assumed that gateway is always online 02:22 < zmnscpxj_> How can the channel participants recover their money if they need to ask permission from the gateway? 02:22 < zmnscpxj_> Also, what if the remote participant bribes the gateway so it can post old state? 02:22 < lndbot> yes these are problekms 02:22 < zmnscpxj_> "Hey look, your IoT device has all of the money in this channel, but I have an old state where I own all the funds, let us split it 50-50, k?" 02:23 < zmnscpxj_> yes 02:23 < lndbot> we might tell at the beginning, hey these are our assumptions and leave the rest for future work 02:23 < zmnscpxj_> that is why 2-of-2 channels is such a Schelling point, every other n-of-n can be reduced to a 2-of-2 by one of the other participants buying out everyone else other than you 02:23 < lndbot> you are right, colluding is a problem here 02:24 < zmnscpxj_> i.e. you can only trust that yourself is yourself, and the rest of the world might be the machinations of an all-powerful Veil of Lies 02:24 < zmnscpxj_> so there are really just two participants, yourself and the Veil of Lies 02:24 < zmnscpxj_> LOL 02:24 < lndbot> true ,:) 02:24 < lndbot> well it looks like i need to work more on this :) 02:25 < lndbot> thanks for your inputs though, i appreciate it 02:25 < zmnscpxj_> np 03:23 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-56-253.adslplus.ch] has joined #lightning-dev 03:49 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds] 03:51 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev 03:55 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] 03:58 -!- reallll is now known as belcher 03:59 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] 04:09 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 04:26 < lndbot> question. you said: "Hey look, your IoT device has all of the money in this channel, but I have an old state where I own all the funds, let us split it 50-50, k?" 04:27 < lndbot> but why would gateway give remote node the half of it while it can get all the money when remote note broadcasts the old state 04:31 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 04:34 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds] 04:34 -!- __gotcha1 is now known as __gotcha 04:36 < zmnscpxj_> Because if the gateway does not give half, the counterparty will never broadcast the old state 04:38 < zmnscpxj_> I think they can trustlessly prearrange this; I know I made some attacks before on proposed sidechains that did a similar trustless arrangement between a thief and cooperating miners who help them steal funds 04:39 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-56-253.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 04:49 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-56-253.adslplus.ch] has joined #lightning-dev 04:54 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 04:57 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev 04:57 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 04:58 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 04:58 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 04:58 -!- __gotcha1 is now known as __gotcha 05:49 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] 06:15 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev 06:18 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 06:21 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-56-253.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 06:25 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Ping timeout: 264 seconds] 06:26 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 06:42 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 06:44 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 06:53 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev 06:59 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 07:02 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 07:02 -!- __gotcha1 is now known as __gotcha 07:16 -!- laptop [~laptop@212.203.87.198] has quit [Ping timeout: 258 seconds] 07:54 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 07:56 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 07:58 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 07:59 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev 08:03 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev 08:10 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 08:11 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds] 08:12 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds] 08:16 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev 08:17 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex] 08:20 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds] 08:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 08:47 -!- alko89 [~alko@cpe-85-10-28-138.static.amis.net] has joined #lightning-dev 08:50 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev 08:52 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 09:01 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 09:03 -!- fiatjaf [~fiatjaf@2804:7f2:2a82:8ad2:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 260 seconds] 09:04 -!- molz_ [~mol@unaffiliated/molly] has quit [Remote host closed the connection] 09:04 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev 09:05 -!- fiatjaf [~fiatjaf@2804:7f2:2984:8276:ea40:f2ff:fe85:d2dc] has joined #lightning-dev 09:06 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 09:27 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 09:41 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 09:44 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex] 09:44 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 09:45 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 09:46 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 09:49 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 09:51 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 256 seconds] 09:52 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 09:52 -!- laptop [~laptop@85-195-244-64.fiber7.init7.net] has joined #lightning-dev 09:57 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 10:01 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev 10:10 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 10:12 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 10:20 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 10:22 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 10:22 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 10:23 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 10:27 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 10:27 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 260 seconds] 10:38 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 10:38 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 10:39 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 10:39 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 10:40 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 10:40 -!- proofofk_ [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 10:40 -!- proofofk_ [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 10:40 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 10:41 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 10:41 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex] 10:45 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 260 seconds] 10:47 -!- alko89 [~alko@cpe-85-10-28-138.static.amis.net] has quit [Quit: Konversation terminated!] 10:48 -!- alko89 [~alko@cpe-85-10-28-138.static.amis.net] has joined #lightning-dev 10:49 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 10:52 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Client Quit] 11:12 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev 11:15 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 11:34 -!- vincenzopalazzo [~vincent@153.33.4.26] has joined #lightning-dev 12:22 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 265 seconds] 12:28 -!- nicolasburtey [~nicolasbu@c-73-93-86-177.hsd1.ca.comcast.net] has joined #lightning-dev 12:35 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev 12:35 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev 12:36 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Client Quit] 12:46 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 13:32 -!- nicolasburtey [~nicolasbu@c-73-93-86-177.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 13:33 -!- nicolasburtey [~nicolasbu@c-73-93-86-177.hsd1.ca.comcast.net] has joined #lightning-dev 13:35 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 13:36 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 13:38 -!- nicolasburtey [~nicolasbu@c-73-93-86-177.hsd1.ca.comcast.net] has quit [Ping timeout: 264 seconds] 13:40 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds] 13:40 -!- nicolasburtey [~nicolasbu@c-73-93-86-177.hsd1.ca.comcast.net] has joined #lightning-dev 13:44 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection] 13:53 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 14:00 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev 14:13 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 14:13 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 14:18 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds] 14:54 -!- marcoagner [~user@2001:8a0:6a5e:bd00:ffc1:99f7:23a:1565] has quit [Ping timeout: 272 seconds] 15:10 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 15:35 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 15:35 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 15:37 < lndbot> but gateway giving the half happens after counterparty broadcasts it :thinking_face: 15:40 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds] 15:43 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 15:43 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection] 15:44 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 15:48 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 265 seconds] 16:20 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 16:24 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer] 16:24 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds] 16:25 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 16:29 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 16:30 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 265 seconds] 16:32 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 265 seconds] 16:41 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev 16:45 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev 16:45 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds] 16:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:03 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 17:08 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 17:18 -!- nicolasburtey [~nicolasbu@c-73-93-86-177.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 17:30 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer] 17:31 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev 17:53 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 240 seconds] 17:57 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 18:09 < zmnscpxj_> ahmetkurt95: this can be done in a trust-minimized way by ensuring that the gateway is paid only if the old-state commitment is not revoked 18:10 < zmnscpxj_> ahmetkurt95: for example, use a `local_delayedpubkey` that is mathematically derived from the gateway pubkey and a secret the counterparty knows 18:11 < zmnscpxj_> ahmetkurt95: `local_delayedpubkey` uses a basepoint `delayed_payment_basepoint` 18:12 < zmnscpxj_> ahmetkurt95: use `delayed_payment_basepoint = h(thief_secret * G) * gateway_pubkey + h(gateway_pubkey) * thief_secret * G` 18:12 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev 18:13 < zmnscpxj_> ahmetkurt95: the thieving counterparty then initiates the channel but does *NOT* reveal this fact about the `delayed_payment_basepoint` yet 18:13 -!- arij [uid225068@gateway/web/irccloud.com/x-qrxecfxfcqlonmof] has quit [Quit: Connection closed for inactivity] 18:14 < zmnscpxj_> ahmetkurt95: the thieving counterparty then transfers all funds out of that channel (except for reserve) 18:14 < zmnscpxj_> ahmetkurt95: and *then* reveals the fact of this special basepoint to the gateway as enticement 18:15 < zmnscpxj_> ahmetkurt95: if the gateway accepts the implicit offer to steal the funds by broadcasting the initial state where the thief owns all the funds .... 18:16 < zmnscpxj_> ahmetkurt95: ...the gateway should pay out to a PTLC, which we can implement today with 2p-ECDSA Scriptless Script, that demands the secret `thief_secret` behind `thief_secret * G` 18:16 < zmnscpxj_> ahmetkurt95: This is where the gateway gives half of the funding amount to the thief, trustlessly. 18:17 < zmnscpxj_> ahmetkurt95: If the thief does not broadcast the theft transaction, the gateway can recover its funds due to the timelock in the PTLC 18:18 < zmnscpxj_> ahmetkurt95: If the gateway does broadcast the theft transaction, but reports it, the enticing thief/mastermind gets its payout from the gateway PTLC, and the gateway loses out 18:19 < zmnscpxj_> ahmetkurt95: The gateway presumably knows its own privkey behind its own pubkey, and to determine the secret behind the basepoint, only needs `thief_secret` 18:19 < zmnscpxj_> ahmetkurt95: Basically it is a Succinct Atomic Swap, with the stolen fund as one of the swapped funds 18:20 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 18:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 18:21 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 18:26 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 18:45 -!- sparks202 [~parky@173.245.217.166] has joined #lightning-dev 18:45 -!- sparks202 [~parky@173.245.217.166] has left #lightning-dev [] 18:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 19:17 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 19:17 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev 19:18 -!- slivera [~slivera@103.231.88.30] has joined #lightning-dev 19:19 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 19:19 -!- shesek [~shesek@5.22.128.126] has joined #lightning-dev 19:19 -!- shesek [~shesek@5.22.128.126] has quit [Changing host] 19:19 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev 20:00 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep] 20:08 -!- arij [uid225068@gateway/web/irccloud.com/x-jlrxnurufrcoudrd] has joined #lightning-dev 20:26 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 246 seconds] 20:40 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev 20:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 20:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev 20:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 21:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds] 22:47 -!- arij [uid225068@gateway/web/irccloud.com/x-jlrxnurufrcoudrd] has quit [Quit: Connection closed for inactivity] 22:54 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 22:57 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev 23:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 23:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 23:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 23:57 -!- vincenzopalazzo [~vincent@153.33.4.26] has quit [Remote host closed the connection] 23:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev --- Log closed Sat Jun 27 00:00:02 2020